As a software developer that actually likes software development, I find myself doing a lot of “fun” side projects. These projects are often a welcomed excuse to play around with new languages, frameworks, or technologies. It’s an excellent way to learn.
However, the final (more than likely incomplete) product is rarely fun. That is why I chose to go a step farther and participate in the MIT Battlecode competition January 2017.
In this blog, I discuss some of the lessons learned during this competition. I was surprised how much of it could be used as a lesson in the real-world of programming. I suggest to all readers that you should consider challenging yourself and doing something similar to “code for fun.”
About the Competition
The month-long MIT Battlecode competition involves programming a team of virtual robots that compete against another team in a real-time strategy game. In order to win the game, your robots have to carefully navigate, harvest resources, attack, and defend against the other team’s robots.
A fascinating aspect of this programming challenge is the way in which it illustrates many common development problems.
The MIT Battlecode challenge has now been going on for 17 years. Although a new set of game rules is created each year, the general format is always a competitive real-time strategy game. This year’s game was named “Bullet Hell” and involved the farming of bullet trees that could be used to either build more robots, buy victory points, or shoot at enemy robots.
The programming was handled by writing a
run() function for each of the six robot types. These run functions could sense, move around, and interact with the environment through an API that is provided.
Even though this was a “fun” programming challenge, I also believe there are a number of lessons that can be learned which are valuable for programming in the real world.
The first lesson I learned is that taking the time to setup a development environment is important.
When starting the challenge, I was eager to begin coding and did not bother to correctly configure any source control. Unfortunately, when I made a mistake a few hours later and subsequently tried to move code, I lost everything. I quickly set up GIT to make sure I did not repeat the same mistake.
I quickly learned that automated tests would be critical for success.
When writing the robot code and supporting functions, there were really only two ways to test the code. One was to run a full simulation and the other was to program a test. Using the simulation meant waiting/hoping that a given situation would arise. It was often unclear looking at the simulation results to figure out if your code had behaved correctly.
As with any project, whether it is for a client or for fun, an investment in automated tests will help you succeed.
Another lesson learned from this coding challenge was that making code behave expediently in the real world is very difficult.
Often when developing code, we are doing our best to imagine how the code will be expected to interact within a particular environment. For web development, this environment consists primarily of users and their web browsers. In back-end development, it is consumers of your back end and other software.
While running my robot code, I was constantly surprised with the number of situations that seemed simple, but would cause my code to fail.
For example, instead of shooting at enemy robots, my robots would, instead, exclusively target a friendly unit. There were also a number of situations wherein my robots would get stuck trying to get to the same location and stop doing anything else.
The final lesson was the ability to adapt to changing information, like maps.
I did most of my planning and strategy based on a few sample maps that were provided. In the actual competition, a new set of maps were used, which—in most cases—completely broke my robots.
Failing to account for a major part of the problem is a common issue with a lot of code I see (and sometimes build myself). I should have planned from the beginning that a wide range of map layouts will be used and make sure my code had ways to handle this variety.
The MIT Battlecode Challenge was overall a great experience even if my solutions did a lot worse than I had hoped. I plan on participating again next year with a much better understating of writing code for this type of challenge.
We’re in this industry because we love programming and writing code, so keep learning and doing by challenging yourself. I recommend that every developer step outside their comfort zone when coding for fun.
How have you challenged yourself lately?