[pmlamotte]

When I was at Michigan Tech I was part of the group that would create an annual version of this, and we were actually running all AI in the same Java process (somewhat sandboxed) which of course led to scalability problems and limited you to JVM languages. For us it didn't matter so much since our target audience was new comp sci students at a school where the starting and most used language was Java.

Our other restriction was that we wanted to support hundreds of units per team, and we wanted tens of thousands of computed turns, but be able to compute that within 3-5 minutes.

We did learn from that naive approach though and the next year I believe it was done with a text based API. If performance were an issue, it could be done with protobuffers, since most popular languages have at least some implementation of them. The year we did the java implementation we had replays the size of 250mb+ due to how much data we had, even with deltas, compression, and other pruning. The text API was only feasible due to a massive reduction in the amount of game entities and turns.

The key thing was when you want to offer API commands. We wanted starting freshman to be able to compete, and that required offering things like pathfinding, predefined list filters, etc. This also mattered since it was run like TopCoder where they only knew about the game the day of the competition and had 8 hours to code an AI for it. The least buggy way to support that in multiple languages is to have the API computation happen on the server, then your language specific APIs are just wrappers around the API calls and data and much easier to change as your game changes.

[craftit]

It is a fair point, if you want to keep the playing field level and you want to compete on the basis of coding skill then you need to manage the code on the server. Otherwise simple network latency to the server could skew the playing field, assuming it is real-time.

I must admit I just want to experiment with different AI algorithms like deep learning, genetic programming, rule induction and see how they do. I have much of the code already but I am unlikely to get the time to rewrite it, even if could get it to fit within the game environment. Especially as some of the training is best done on a GPU.

[pmlamotte]

You bring up the real-time component, which is something we didn't do and from what I can tell the OP does not plan to do either. Real time is an entirely different beast and something I haven't seen in these types of competitions yet. I'd love to see one that does do it though.

Another cool competition is MIT's Battlecode, which actually gives you a bytecode limit. If your code executes past the bytecode limit, your AI is paused and will actually resume on the next turn, without notification. Thus you'll be continuing with possibly old/dirty data. That pretty much prevents you from using any standard libraries and doing bytecode level optimizations, as well as manually yielding if you know it will take too long.

Your robots also can only talk to each other through a radio API that has limited bandwidth and possible corruption if I recall correctly. It's a complete opposite of what I worked on, where we focused more on strategy rather than code optimization.