Battlecode 2015 – AI Programming Competition | Hacker News Reader

Battlecode 2015 – AI Programming Competition

battlecode.org

98 pointsdvorak4223 comments

I do remember back in the day playing AT Bots, it was a similar concept, only you would write the bots in assembly, which was kind of fun, because on top of the strategy, you also had to figure all the ways to profile your code. Like for instance bit shifting instead of dividing, and such. You had to keep the code light because the speed of your bot directly correlated to the how fast the code would be executed. So, each processor cycle counted towards making you faster, but speed up too much by cutting down your code, and your bot would get dumber.

It would be interesting to see a game where only the API for the bot is exposed, and the actual computation takes place on a separate machine (or same machine, but separate processor). That way you can experiment with all kinds of languages, or even possible hardware combinations. For competition your code would be loaded on a VM instance or a physical machine which has identical characteristics to all the other competing machines, and you go at it. This way you are not limited to a given language or a set of libraries, and can really explore all the possibilities.

theaigames.com does this by running the game engine and bots as console apps and communicating by sending simple commands through their input and output streams. They generally provide some "starter bots" for a couple languages, in which the message parsing is already handled for you, but they accept bots in any language.

Looks fun!

    > What are the supported programming languages?
    Java and Scala.

Oh. Nevermind.

What's the most interesting version of a competition like this which doesn't place restrictions on implementation language?

The ICFP programming contest, usually.

We're not happy about the restriction either, and hopefully we'll run a Battlecode that doesn't have a programming language restriction, but we haven't found a way to deal with limited instruction count execution that we are happy with that is machine independent, and counting Java bytecode has worked for us so far.

If there are other JVM languages people want supported, we'd be happy to take pull requests on Github once we make the new gameplay public tomorrow.

How about clojure and jruby? Adding these will be pretty awesome.

Jython could be interesting too.

So any language compiling to Java bytecode is OK?

A majority of them, however since we take source and compile it on the tournament servers, we'd need to get the compile chain and server working with those languages.

Why not just time the execution instead of counting instructions?

Maybe because that would give an advantage to people using faster languages, and they want it to be more about the machine learning algorithms

Can you explain in more detail what you mean by "limited instruction count execution that is machine independent"? For example:

- Is it measuring the count and making sure it doesn't exceed some threshold, or is the client API designed to actually give each client a specific number of instructions and terminate if that is exceeded?

- Does "machine independent" mean it needs to run outside of x86/amd64?

- Would it offend your sensibilities if CPU cycles used by C programs counted the same as those used by JVM programs?

In the past we've had it where where each bot is allowed a certain amount of "computation", with different upgrades giving you more "computation" each turn.

Machine-independent isn't really the write word, more of that we want the same two bots fighting on the same maps to be deterministic regardless of the machine its being run on.

For mechanics like this, we've found that bytecode instruction counts are the best metric we currently have, since anything that is time-based could result in different results depending how the CPU schedules the bots, and doing something like using PIN or another system to count assembly instructions turns it into a competition of who can write the most optimized assembly code.

Why the JVM? Why not run your own bytecode, or even use Redcode straight up?

edit: Perhaps I should explain. I dabbled in rec.games.corewars a few times, and what I found most rewarding was all the tricks you could play with the bytecode. I've never found the Java variants as fun, as one fun part of the game seems lost. I feel like I'm missing something.

While we do allow bytecode tricks, we want the focus of the competition to be on developing high level macro and bot level micro strategy, instead of spending all the time working on optimizing at the bytecode level. Especially since the main competition period is less than a month, we don't want to encourage time being spent on that.

While some of it is open to non-MIT students, it looks like to continue through to the finals you need at least 50% MIT students on your team.

Should be fun anyway.

No, at least 50% of your team must be students.

You can also compete for the top of the scrimmage rankings, and we are considering adding an Open tournament again to allow all teams compete for fame and glory.

I definitely would like to see an open tournament. My friend and I are going to be participating but neither of us are students. Just doing it for the fun and educational value.

Nope

>In order to be eligible to compete in the seeding, qualifying, and final tournaments, at least half of your team members must be current students (any school).

http://www.battlecode.org/tournaments/

This looks awesome. Are the winning bots' source available after the tournament is concluded?

We don't explicitly require teams to open source their bot after the tournament, since sometimes teams have special restrictions on publishing their code. But some of the top teams have published their code or framework online in the past.

Any MIT student not participating in Battlecode here?

Reply on news.ycombinator.com