I find the run loop to be fairly confusing. In step 2 of the tutorial we have<p><pre><code> s1.move(star_zxq.position);
s1.energize(s1);
if (s1.energy == s1.energy_capacity) {
s1.move(base.position)
s1.energize(base);
}
</code></pre>
What's confusing is that it seems like my sprite should execute all four of these actions. So it's surprising to see that it only does one of these things at a time.<p>There seem to be at least a couple hidden assumptions:<p>1. If multiple `move` commands are issued in one loop it will only do the last. Ditto(?) for all other commands<p>2. A sprite can only be doing on thing at a time. If you order it to do something that it can't do it will simply ignore it. So the `energize` command is simply ignored when it can't energize, and when it can, the `move` command is ignored<p>While this does help keep the game syntax much more tidy, it's fairly confusing since it doesn't seem to match how a script would normally be read.
That's nice.<p>A sandbox mode would be nice, where there's just an indestructible enemy base, where you can test and debug your code without the pressure of being attacked.<p>Also in the tutorial the use of for-of would be better in my opinion, as it is better understandable and has less clutter.
Very nice so far.<p>I noticed a small problem in the tutorial. On step 3 or 4, when the suggested code is<p>if (s1.energy == s1.energy_capacity){<p>memory[s1.id] = "charging";<p>} else if (s1.energy == 0){<p>memory[s1.id] = "harvesting";<p>}<p>if (memory[s1.id] == "charging"){<p>s1.move(base.position);<p>s1.energize(base);<p>} else if (memory[s1.id] == "harvesting"){<p>s1.move(star_zxq.position);<p>s1.energize(s1);<p>}<p>My spirit had already transferred a bit of energy to the base, so it entered neither of the states. It was a pretty easy fix to make, but strictly following along the instructions, I would have been stuck there.
I like the concept, but there seems to be a lot of problems for a "beta":<p><pre><code> - The documentation doesn't mention what merging and dividing is for. This is not covered in the tutorial and I don't know what kind of advantage this gives. Additionally the details for "divide()" are a copy of the details for "move()" (bad copy/paste)
- The documentation doesn't mention anything about ranges (how far can I be from base or star to transfer energy?)
- The documentation doesn't mention anything about rates (how fast is energy harvested/transferred?)
- There are dead links e.g. https://yare.io/j2m.cz/~jm/, consider using a link checker
- The game is very slow! Debugging a program takes a very long time. It's not slow enough that I can reasonably make any adjustment during gameplay though
- The console is undocumented and behaves differently from the browser one (e.g. it only prints its first argument)
- The other shapes are undocumented (triangles seem to not have the ability to merge, what is the flip side?)
- "my_spirits" keep references to dead spirits which is VERY confusing. The tutorial introduces code that specifically seems designed for the opposite behavior
- There are bugs in the match-making, where sometimes it will join a just-finished game from other people (so I see a score screen for people I don't know and I have to start match-making again)
- A way to show information on the canvas would be very helpful. Simply adding a field "caption" to spirits, that would be shown next to it on the canvas, would already go a long way
- "Game cancelled" errors
- It seems that while my script is already loaded at the start of the game, it won't start executing until I click "update script", causing a variable delay between players. The bots also don't have this issue.
- There is a 1 in 4 chance that both players will pick the same color, which leads to a very confusing match. Consider removing the manual selection and always making one red one blue</code></pre>
I have always been trying to make an Elixir version of a screeps-like game. Every unit is just an actor, sending messages to other units, based on the GenServer behavior. You can upload a new version of the unit controller with Beam hot code reload.
It would be really nice if there was some indication of errors in your script. I typo'd some of the tutorial code and it took me a minute to see what was going wrong (no errors in the console?). Also auto-complete on game functions is really needed. It will apparently auto-complete regular/core JS stuff but not game-specific methods. It looks like the starfield is limited to original browser size and resizing the browser window will not resize the starfield (which sucks if you load up the page with a small window, lots of panning around to see stuff).
Slightly reminded me of Elevator Saga[0], a much simpler game in which you use JS to move people with elevators<p>[0] <a href="https://play.elevatorsaga.com/" rel="nofollow">https://play.elevatorsaga.com/</a>
Awesome work! Glad to see more programming / hacking games out there.<p>For others interested in the genre, my old school JS hacking favorite is: <a href="https://alexnisnevich.github.io/untrusted/" rel="nofollow">https://alexnisnevich.github.io/untrusted/</a><p>And for those interested in Go, I made: <a href="https://andybrewer.github.io/operation-go/" rel="nofollow">https://andybrewer.github.io/operation-go/</a>
Reminds of Omega--you wrote scripts to operate autonomous tanks, and pitted your tanks against others' in an obstacle-filled arena. Omega didn't have the realtime scripting component though.<p><a href="https://en.wikipedia.org/wiki/Omega_(video_game)" rel="nofollow">https://en.wikipedia.org/wiki/Omega_(video_game)</a>
reply
Cool! I'll play with it more... when I'm not at work.<p>Suggestion: more keyboard shortcuts: find/replace, delete line to name a few. Eventually you could allow customization and/or selecting different pre-configs (e.g. Vim, VS Code).
Great idea, and very cool game. Probably going to mess around with it later, but a few early observations after going through the tutorial and reading the docs:<p>* It's perfect information (even the locations of the bases and stars are fully known ahead of time). So there's no need to create scouts like you would in other RTS' AIs.<p>* There's definitely some merge / divide tactic for attacking that can be exploited. If a merged spirit gets divided, is its remaining energy split between all of the original spirits?<p>* Jump seems incredibly powerful for both resource gathering and ambush hit-and-run attacks given that its cost is always constant.
This looks awesome! A buddy and I made a very similar turn based 'game' a while back, but never added accounts etc for public matches: <a href="https://ikottman.com/apps/slime-mind/" rel="nofollow">https://ikottman.com/apps/slime-mind/</a><p>Yours looks much more polished, I'll give it a try!
Even the API we see in the tutorial is, well, problematic:<p>s1.energize(s2) has the s1 entity transfer energy to the s2 entity ... except that if s2 == s1 (or s2 === s1), s1 tries to harvest energy from somewhere.<p>... that would not pass my code review.
Seems like there's a lot of potential in code-based games, not just for learning but for a creative outlet. Wish the contrast was a bit higher on this one though!
You need to visually show when the entered code is loading.
So often I click "run code" and then nothing happens I it feels like the code is broken.
It looks nice and I like the core gameplay loop, but after uploading a few snippets of code the spirits are constantly moving backwards and forwards (even in the tutorial after just uploading some code that I literally copied off there).<p>I was very excited about coding in a state machine, but if I have to figure out if I'm bugged or the game is that's not a great time for me :)