BattleCode was the best thing I did while at MIT, and one of the most unique and rewarding experiences of my life.
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.
Working on Battlecode was the same way for me, most intense time I've ever spent at MIT. Lots of teams were really into it which made it all the more competitive and fun.
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.
Yeah navigation via A* / other traditional algorithms is almost always a no-go in Battlecode because of the way the bytecode limitation works. You almost always have to create some extremely custom pathfinding algorithm tuned to the constraints of the engine.
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[1]
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.
I think the last time we played, one of my teammates came up with 'detractors'; i.e. 'stay away from here, it's bad news', once a bot was sure that a place was not good for pathing, they would drop one and it would make its way around to the other bots.
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.
I highly, highly recommend any current MIT undergrad who is serious about starting a company to compete to win in Battlecode during IAP. It's as close to starting a company as you can get.
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.)
Battlecode (RoboCraft!) taught me a whole lot about the sorts of tradeoffs you have to make as an engineer in the real world in a way that nothing else at MIT really did. It definitely put freshman-year me in my place, too. Pretty sure it was my first MIT all-nighter.
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.
Now I feel old! I participated in the first two Battlecode's ever, but that was back when it was simply 6.370. The first year was a board game and we stared at ASCII graphics all IAP long. By my M.Eng year, Aaron Iba and co. turned everything around and kicked off the golden age of 6.370.
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 am curious- what was the atmosphere at the finals like when you were a contestant?
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.
I believe 2004 was the turning point when the audience was very engaged -- that was the first year spectating was lots of fun, 34-101 was packed, cheering all around, etc.
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....
Battlecode is actually also open to the public and the two years some friends and I did it (09 and 10 I believe) we came in #1 and #2 outside of the MIT teams (since we didn't have it as a class and it was only free time it was a bit harder to compete) but I agree with all the points, it was a great experience and I encourage everyone to give it a go at least once!
I participated in the public competition a few years back with a few other classmates. We had a blast, but definitely underestimated the amount of time required to reach the upper echelon in the tournaments (finished middle of the pack). As a side benefit, we were actually able to convince our university to honor this class as a directed study and pick up a few credit hours as well.
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.
For those that are interested, the new 2013 release is now live[1]. Should be a fun game this year -- enough spec changes that even seasoned Battlecode veterans will have to sit down and think quite carefully about how to write a bot.
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[2] and hg[3] flavors.
This reminded me of the last AIChallenge (http://ants.aichallenge.org) it was a great experience and made me choose between adding features, improve existing ones or fix hard to find problems with a relatively short time remaining since I found it near the end.
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.
Really awesome post. I'd also strongly recommend 6.470 (Web Design) to any current MIT undergrads. I competed in both 6.370 and 6.470 and had a different take than the author of this piece -- I found that 6.470 was a much more startup-y experience, although the emphasis is much more on product rather than pure software development. That said, both are excellent.
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.
From a curious alum, and excuse the inside baseball: Long ago, there used to be a 6.270 contest. I noticed this is a 6.370 contest. Anyone know the history if they're related?
I'm pretty sure 6.370 was inspired by 6.270. It was intended to be a more "pure" programming competition, without all the intrusions of finicky physical reality.
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.
There's a whole series of them now actually. 6.470 is a web programming competition, 6.570 is an Android App competition, and we (MakeGamesWithUs YCW12) are helping set up 6.670, an iPhone game programming competition. I'll be giving the first lecture to 80 students tomorrow :)
It is 3D. In recent years, both a 3D and 2D view has been available - the 3D view (complete with the "circle of awesome", an automated camera which analyzes the match to figure out where the action is - at least, they had that a few years ago) is flashy for the spectators, while you can get a much better sense of the overall strategy by watching the 2D view. Both views are displayed onscreen at the final tournament.
Ah, the mythical man-month. Or student-month, as the case may be.
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."
This. There are a variety of different backgrounds regarding programming experience in Battlecode, and just as varied levels of commitment to the competition. There are those teams just looking to play around with the game and possibly try their hand at beating the reference player. Still other teams have their eyes set on the eternal glory of winning first place.
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.
Well when one coder reaches 5 000 LOC of Java in one day, even if there are a few bugs in there, it still indicates some hardcorness. I've seen my ex CTO do that and it was fascinating. Hardcore startup style: "get the feature out as soon as possible because one of our first client badly needs it".
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.
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.