I find the run loop to be fairly confusing. In step 2 of the tutorial we have
s1.move(star_zxq.position);
s1.energize(s1);
if (s1.energy == s1.energy_capacity) {
s1.move(base.position)
s1.energize(base);
}
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.
There seem to be at least a couple hidden assumptions:
1. If multiple `move` commands are issued in one loop it will only do the last. Ditto(?) for all other commands
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
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.
1. Is correct, whatever is the last command is used
2. This is not true, spirits can move and energize at the same time. But yes, if the object it tries to energize is out of reach (200 units), it will simply ignore the command.
It seems like there is an implied command buffer, which probably made the implementation much more simple to code and I think makes the scripting language more simple once you get the hang of it.
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.
Also in the tutorial the use of for-of would be better in my opinion, as it is better understandable and has less clutter.
I noticed a small problem in the tutorial. On step 3 or 4, when the suggested code is
if (s1.energy == s1.energy_capacity){
memory[s1.id] = "charging";
} else if (s1.energy == 0){
memory[s1.id] = "harvesting";
}
if (memory[s1.id] == "charging"){
s1.move(base.position);
s1.energize(base);
} else if (memory[s1.id] == "harvesting"){
s1.move(star_zxq.position);
s1.energize(s1);
}
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":
- 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
Thanks so much for writing all this down, this is extremely useful!
You are right, the documentation is incomplete and there are still lots of issues, the next week's update will fix some of the above and make it a more stable and proper 'beta'.
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).
This thread seems like an appropriate place to link a simple JS battle game I made a while back, as an experiment in embedding VS Code's editor (with full code completion support via TypeScript definitions):
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.
Cool! I'll play with it more... when I'm not at work.
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:
* 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.
* 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?
* 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: https://ikottman.com/apps/slime-mind/
Yours looks much more polished, I'll give it a try!
Even the API we see in the tutorial is, well, problematic:
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.
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!
Thanks! No plans for mouse-less control, yet. If anything, I'm considering adding more mouse controls for simple actions (e.g. selecting multiple spirits, right-click to move or attack, ...)
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).
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 :)
There are a bunch but it depends on whether you want to use a “reall language or a custom in-game language (usually visual programming). For example Baba is You is a great programming game but it’s very different from regular programming. There’s also games with high level visual languages like Autobots, all the way to games about assembly languages like TIS-100 and Shenzen-IO
Replying to this one since that was my first impression. On closer look they did seem quite different.
Gameplay, goals, all of that is similar to screeps. But the game board and therefore the mental model itself is quite different. Where screeps feels like an endless multiverse along the lines of old school browser games like oGame, yare carries a feel of a more quick starcraft battle. Definitely not a copy even though it carries similar mechanics.
Basically, I feel like I could do games on yare randomly whereas screeps has always felt like a long term investment I need to make.
EDIT: Also also, yare seems to be far more simple for the moment in terms of environments and resources but that could change in the future and I'm looking forward to developments there.
Could you expand on the hypothetical? What would you program?
In particular (asking anyone, not just you) what would satisfy the same "needs" as these coding strategy games? Programming here is not an end in itself, but a means to encode your tactics and strategy, that you can then observe facing the "real world".
Rephrasing this a bit, I do also find myself to enter my "work-mode" playing these types of brains, and I too would rather do paid work if it's going to be like that. It's not fun for me knowing that I'm essentially exploiting myself for no reason. I'd love a game like this however that developed niche skills. Maybe a game where you move your unit by writing a weird, complex bash script for something.
Or a game where you have to rewrite a perl one-liner in python before the bomb explodes or something. That could be sorta fun for me.
I mean, if I I'm understanding what you mean by this, it just feels too much by productivity. Writing a service to read from and endpoint and calculate some probabilities and output some action, that's just work. It's not going to make me a better or worse programmer. Teaching someone bash-fu, helping programmers remember flags for grep or curl, these are useful skills that could be gamified just the same as bot/agent logic.
I think too that these games always kinda fall into a state machine pattern. I don't need the expressiveness of javascript, the bot will end up being a state machine with different states, and it'll just churn through it's inputs. It's always kinda of the same ultimate end pattern.
There seem to be at least a couple hidden assumptions:
1. If multiple `move` commands are issued in one loop it will only do the last. Ditto(?) for all other commands
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
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.