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.
http://www.rpscontest.com/ is a rock paper scissor competition. All contestants are readable; very fascinating stuff.
[1] http://www.retroprogramming.com/2009/09/history-of-programmi... [2] https://en.wikipedia.org/wiki/RoboWar
I ended up never finishing it because I found myself inventing Google Wave (in 1997, in DOS). But it was a fun project.
What was the project? Something you ever released?
I'd like to find a community to share these with but have no idea what these things are even called.
Also, we open sourced our winning 2012 bot on bitbucket here if you want to see the type of code that goes into it: https://bitbucket.org/Cixelyn/bcode2012-bot
In any case here is a link to the finals on YouTube which works with mobile devices:
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. :)
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.
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.
So yes, you could probably use Jython or Jruby, but you wouldn't be competitive against the people writing straight Java.
I guess that working for free food is pretty amazing for a future employer.