It was used during multiple local hacker conferences to keep the guests entertained. For that you would run the server somewhere, then run multiple viewers all over the place (and a big central screen) so everyone could follow the current game. Players would then connect to the server through telnet and upload their Lua code. Code could be updated while the game was running so people kept tweaking their code all the time. It was really fun seeing more than 20 player competing.
The game should still work today and is basically feature complete.
Screeps (https://screeps.com/) is an amazingly great example of this sort of game. It's available online, on steam, and as it works in JavaScript you can use almost any language due to the huge variety of transpilers. It has numerous constraints that make the game more interesting including CPU and memory limits.
Thanks for posting the list. I call these programming games for lack of a better name, some of them go way back (e.g.: Core War) [1]. I remember playing Robowar [2] on toaster macs way back when.
I think it'd be neat to have a coordination service that runs tournaments for AIs playing games like Resistance. People register a URL with the service that exposes an API that lets the coordination service tell them the current state of the game, and responds with their next move, if any. People could then write these AIs in whatever they want (and bear most of the cost of running them for tournament style simulation).
it wouldn't be difficult to adapt my existing codebase for that. It would probably have to involve webhooks or websockets, and games would play out a lot more slowly than doing it locally with gems. As is, playing 10000 games only takes about 45 seconds. Running across the web is going to slow that down significantly
This reminds me of Codingame, they have a similar challenge where you code an AI for a Dice Wars-like game and send it off to the ladder to compete against other people. It's great fun
I love codingame! I looked into it before recommending it to a friend and got all sucked in. I'm currently working on an AI bot there for a competition. It's fun and forcing me to go do research on AI concepts.
If anyone is interested in learning more specifically about the Battlecode competition, I wrote a blog post giving a brief overview of the competition a few years ago: http://cory.li/battlecode-intro/
The "watch" links let you watch the actual battle simulation results in a really old viewing engine written almost 6+ years ago in Adobe Air. It was amazing at the time since you didn't have to install the full Java client just to view the matches.
The devs probably have their hands full implementing the actual game -- pretty sure no one has had time to port the codebase to something more modern. The competition organizers are primarily MIT students doing this in their spare time, so they have classwork and other things to deal with as well. :)
Wow, this reminds me of GISMO from 1991 or so. Teams of 8 tanks, 2 bases, terrain included water, mountains, forests, and plains. Implemented in dos and required a modem to compete.
Neat framework, well before it's time, very few competitors that worked. They resisted the recommendation to support TCP instead of modems and linux, even after it was ported.
It was modeled after the M1 abrams as part of a research project in AI controlled teams.
I tinkered with it, I liked it because the terrain was complicated enough to lend itself to quite a few strategies. I've not seen anything similar since.
Shameful plug: with a few friends we are planning to create another platform for such fun games. If you think it is a good idea, please sign up: https://www.botolympiad.com/
This one: http://ants.aichallenge.org/
I greatly enjoyed it, and it taught me Python. I keep checking back in the hopes someone will get a new competition together.
It's generally custom, although we've had teams use ML strategies to tune their bots in the past. (I'm one of the people who runs this competition).
We impose tight runtime limits on the code your AI can run - generally limiting the number of bytecodes the JVM can execute per turn per robot. This is partly pedagogical; it kinda-sorta simulates embedded programming, like for a real robot. It's also practical; it keeps people from accidentally DOS'ing themselves or our servers with infinitely-looping AI.
On the other hand, 20000 instructions per turn doesn't give you much leeway for, say, matrix multiplication, so most sophisticated ML isn't possible at runtime. You can do simple things, but they have to be tightly written.
Other JVM languages are technically allowed, but AFAIK they generate way too much scaffolding & reflection-based flow such that you end up burning your entire bytecode computation budget just in calling one or two functions.
So yes, you could probably use Jython or Jruby, but you wouldn't be competitive against the people writing straight Java.
