Short Essay
Last January, I participated in Battlecode, a competition run by MIT where participants write computer programs to play a game against each other. At the end of the month, there’s a big tournament with prize money, which in any other year would take place at MIT, and finalists would be flown in for a dinner with sponsors. There are also a few smaller ones with smaller prizes, including one just for high school students. It’s primarily for college students, and MIT students can even get credit for it, but students from colleges across the world, as well as high school students like me, also participate. Teams of up to 4 can participate, but many people also do it alone like I did. This year, 265 teams entered the competition.
The game consisted of a map with a bunch of “robots” belonging to each team. You start with a headquarters or two, which can build other robots that you can use to make money (to build more robots), attack the opponent, or defend against their attacks. Each unit is controlled individually, and they can only communicate and coordinate by showing a single number as a “flag” each turn, which nearby units, as well as headquarters at any distance, can read. So a large part of the game is the technical challenge of coordinating many units (up to hundreds) without much communication, and also efficiently communicating important information.
"By the skin of my teeth, I made it into the finals, getting in the top 16 in the qualifying tournament."
- Sam D.
For me, the technical challenges were what made this one of the most fun things I’ve ever done. When I started Battlecode, I didn’t think I would do very well. But I knew it would be fun, and I wanted to challenge myself. I knew it was just one month, so I decided to go for it, dedicating all the free time I had on it. The first week happened to overlap with my winter break, so I got started then, able to spend the whole day on it. Then the next week, even on weekdays I stayed up late programming, spending probably five hours a day on Battlecode, and more on weekends. I had a four-day weekend again right before the deadline for the qualifying tournament, so I spent almost all my waking hours programming. I wouldn’t have been able to keep up that pace indefinitely – there are other things I have to do, after all – but I found that I was able to for a month, especially since I had just finished my college applications.
I didn’t expect to do very well – I was a high school student, working alone, against teams of MIT and Carnegie Mellon computer science majors. But I kept going, because the problem was compelling and because I felt like I could do better; and I did better and better. At the end of the first week, I was something like 40th place, which itself isn’t too bad. But a week later, I was in the 30s; and at the end of the competition, I was hovering between 15-20th place (the ratings were pretty volatile at that point). By the skin of my teeth, I made it into the finals, getting in the top 16 in the qualifying tournament. I lost the first round of the finals, but that’s still incredible, much better than I thought I would do. I was surprised to learn that being a finalist was even enough to earn me some prize money. Of course, my program’s performance wasn’t terribly consistent: I didn’t actually make it to the final game of the high school tournament, even though I’d won against those teams before.
"It was a challenge, but I pushed through and had fun."
- Sam D.
I learned a lot over the course of my participation, so hopefully next time I can do even better. The first thing I learned was that reading the game specification thoroughly, and more than once, is very important. I did read it thoroughly at the beginning when I was just learning about it and consulted it often when working, but I forgot about an important detail that I didn’t notice until halfway through, which meant I was making the game harder for myself for the first week and a half.
Second, I realized I hadn’t been prioritizing enough. There are mostly three phases of development: writing new code and exploring big-picture strategies, debugging and making sure your code can handle edge cases, and tweaking the small stuff like constants and build order. You don't want to be writing new code an hour before the deadline, because it will have bugs, and it might not be an improvement since you didn’t test it much; and you don't want to spend much time tweaking constants halfway through week one, because that’s not going to improve your performance that much and it’s better to spend that time trying out new strategies. I made both of those mistakes: overall, I didn't explore enough early on and didn't do quite enough testing right before tournaments.
Last, I didn’t test my code well enough. In both of the sprint tournaments, which happen at the end of weeks one and two and are for getting to know the metagame, my program encountered edge cases in the map that I hadn’t tested on and did poorly because of it. In the first sprint tournament, it just crashed because of the location of the starting headquarters next to the enemy’s, and in the second it waited 50 turns before doing anything, giving the opponent a head start, again because the starting headquarters was next to something, a neutral headquarters in this case. They were two different bugs, but I could have found them both by making weird maps to test on.
Overall, Battlecode was a great experience that showed me what I’m actually capable of. It was a challenge, but I pushed through and had fun. I learned and improved throughout, and next year I’ll probably do even better. I hope to apply the same passion to whatever new challenges appear in my life, whether in programming or any other endeavor.
- Sam D.
