The way David and I were able to win it in 2003: at that time, robot positions were stored as two doubles (x,y). You could move yourself by a precise amount or read the precise x,y position of another robot, each in only 1 bytecode. So instead of using broadcastMessage(String), checking that no other team was trying to screw with our messages, all of which took lots of bytecodes to get right. Instead of that, our robots communicated through the low bits of double values in their positions. Kind of like bees dancing for each other. This gave us enough of an edge to beat out all the other players. This was 100% David Greenspan's idea, by the way. I just worked hard to help code it up.
MIT classes are supposedly a lot of hard work, but at that point I had never worked as hard on anything as I did on our BattleCode player.
In 2009 one of our rivals was a solo coder who was in the top 8 of the previous year (we became friends through the competition and still hang out to this day). He relayed to me a story of how one of the other teams had tried to sabotage his efforts. They sent a female member of their team over to his room to convince him to drink with her. It didn't work, although that was mostly because he already liked to drink and code.
I'll echo what skates and iba said -- battlecode was probably one of the most productive things I did in school. when everyone else is trying to teach you how to properly to document your preconditions, battlecode is purely about GSD (get s* done) - an extremely valuable lesson for an aspiring young entrepreneur.
my favorite battlecode hack: we used to assign a fixed "cost" to certain methods, namely Arrays.hashCode(). one of the more experienced players figured out that everyone was using this to checksum their radio broadcasts. he then proceeded to reverse engineer the hash code algorithm and spam teams with enormous messages that had legitimate checksums but were actually just megabytes of trash! the poor opponents would just sit there chewing cpu until the engine finally killed them for using too much heap :)
edit: actually read through cory's post - glad to see he already mentioned this one!
Communication via entity position is genius. Awesome! I wish my team had thought of that.
I have to say that being a contestant in 6.370 (robocraft/battlecode/etc) was easily the most fun, and the best practical experience I had while attending MIT. So, hats off to you and your partners for turning it from fun into excellent.
What I especially enjoyed about the 6.370 experience was the instructions constraint. With it being as low as it was, you really had to get smart about stuff like pathfinding - you could write a respectable AI using more normal approaches, but I suspect most contestants throw away traditional algorithms pretty quickly.
Less loved was that Java's compiler appears to hate (or maybe hated, at the time) efficiency. My teams usually wound up disassembling in order to find places where java was being stupid at compile time, and finding ways to get it to be less so. It makes a pretty big difference when every instruction counts. But, if it hadn't been for that, I might not have taken Compilers subsequently, so...
In any case. Thank you for your contribution to an enduring and truly excellent tradition in the MIT lexicon.
The simple algorithms are stuff like bugnav (walk in your desired direction until you see a wall then attempt to trace around it), but you'll find that even in something as simple as bugnav, there are a _ton_ of edgecases you have to account for in a discrete implementation that results in robots tracing around each other / stuck in infinite loops, etc.
Our 2012 bot uses a special implementation of the discrete tangentbug algorithm that allows us to precompute squares during rounds which we have extra bytecodes to spare
It's probably _the_ most complex part of our codebase, and the person who wrote it doesn't even really understand how it works anymore.
That actually worked surprisingly well. Our implementation had briefly stupid behavior in a few scenarios, but after a lot of testing it was clearly our winner.
It looks like this year isn't as big on the pathing, as 'every square on the map is traversable, and there is no longer any distinction between ground and air units.'
That's mighty unfortunate. I thought that was one of the more interesting challenges.
Watching your bots win and lose while trying to prioritize fixes is exactly what prioritizing things in your startup is like, without all of the downsides of taking forever to get traction.
There's also a long legacy of alums going on to found successful YC startups (Dropbox and Etherpad being the best examples). You also get to say you've won MIT's biggest programming competition, which gives you a huge amount of credibility.
Also feel free to reach out to me if you're interested in starting a company/doing Battlecode and currently an undergrad at MIT! (My team won in 2009 and 2010 and I'd be happy to help.)
It's an awesome experience for the directors as well, as the competition itself is basically a small startup. 3 or 5 students responsible for coming up with an idea (for that year's game objective), pitching to investors (sponsor companies), shipping a product (game engine + docs + online scrimmages), supporting several hundred users (contestants), keeping servers up, orchestrating a live tournament, placing an order for $2500 worth of pizza, getting up and speaking in front of a thousand contestants/spectators/sponsors, fixing bugs in the tournament bracket viewer in the middle of the tournament... Not something that every undergrad gets to do, that's for sure.
Amazingly, they still have the final prizes posted from 2002 and most years in between. Our team won the hilarious gag prize: "greatest design mismatch between document and code." First place that year was $500. Last year when I went, some of the gag prizes were $1000, including prizes like "last team to submit a jar before the submission deadline"
I remember when I first went in 2008, it felt like the superbowl for nerds. Competitors would get up on stage and provide commentary while their swarms of virtual robots would duke it out on screen. There would be a bunch of oohs and aahs from the audience as each team of robots tried to gain the upper hand. The entire auditorium would erupt in cheers at the end of the match for the winner. I remember thinking Albert Ni was a coding god after seeing his team walk off stage as champions of the tournament.
In 2001 and 2002, spectating was not fun at all, partly due to technical issues mid-contest. To make things more entertaining, Prof. Daniel Jackson asked Guy Steele to get up and talk about the new features in Java 1.4, and discuss when generics in java.util would be fully supported. Not joking....
I highly recommend this competition to anyone even remotely interested. You're at a disadvantage entering with no experience from previous years, but it's still a very worthwhile experience.
Meanwhile, here are some programming battle games you can play at home!
Core War (Redcode, assembly dialect): http://www.corewar.info/
Robocode (Java/.NET): http://robocode.sourceforge.net/
BitBath (Java): http://bitbath.org/
Shared sensor data now makes higher-level strategies a ton more viable, so it'll be fun to see what contestants come up with.
There's a quick start available if you want to just clone and hack some things together in git and hg flavors.
I didn't even knew about BattleCode, now I plan to keep an eye on it and if it is possible to people outside MIT to participate I will try to.
"Do I have to be an MIT student to participate?
Nope! Non-MIT students are welcome."
Additionally, the ratio of number of teams to prize money was (historically) more favorable for the Web Design competition, although my information is out of date and things have likely changed.
Similarly, 6.186 (better known now as MASLab) was also inspired by 6.270, but diverged in the opposite direction: more ambitious physical designs (no legos), more computational capacity, richer sensors (it's mostly vision-based), etc.
The three competitions span a pretty nice continuum.
Thanks to all the answers in this subthread for the current info.
The memory is the first thing to go, etc etc.
EDIT: It was indeed robots from the beginning (1987).
And slightly less retro, if your on mitt challenge make it 3d
You can't measure productivity in klocs, and you're also not taking into account the distribution of effort across those 350 contestants. Plenty of people sign up, poke around with the API for a bit, and submit a half-assed bot (or none at all)... but those who do well? They're spending quite a bit of time on this. I think it's safe to call them "hardcore."
I was on Cory's (the author of the post) team last year and, as he alluded to in the article, we were a team of 4 bro-coding it up in my dorm room with practically nothing else on our mind during the month (we tried to eat and bathe occasionally). Though it was a lot of fun (some of the most fun I've had during my time at MIT), it was pretty intense.
Then, when you take a 100 KLOC codebase in Java/C+/Obj-C/whatever and trim it down to 10K LOC of some Lisp dialect, it kinda indicates some hardcoreness too.
I know it's a "false" metric, but once you take sufficiently big values, it still serves a purpose.