Our team was a newbie team of students from Montana State University, consisting of Colleen Rothe and Kylie Webb, self-dubbed the “KC Power Team”. As first year participants, we are writing about what we learned, and how we’d do things differently after our first year’s experience with Battlecode.
The objective of the game this year was to survive attacks from the other team, and non-user controlled robots, referred to as “zombies”.
There were 7 types of player robots, as described below:
- Mobile HQ.
- No attack
- Spawns other robots
- Sends message signals
- Mediocre attack
- Melee unit.
- Mediocre attack
- High health
- Bonus damage against zombies
- Infects non-zombie units (including your own, if you’re not careful)
- Weak attack
- Mid-level attack
- Long range
- Strong attack
- Can’t move
- Mobile mode of Turrets
- Must spend turns to become TTMs
- Fast with no rubble constraints
- No Attack
- Able to send messages
There were also many types of zombies spawned by dens, which were our biggest enemy in just about every map. The dens were settled at least 30% closer to one player or the other, and spawned zombies in waves, starting with a few standard zombies and maybe a ranged, and then slowly growing to be all fast and big zombies, which were devastating to us. We prioritized protecting against the zombies before the other player, as a wave of zombies was a lot harder to deal with than the other team managing to make it across the map and attack us before time ran out, or they got destroyed first.
The kinds of zombies are as follows:
- Mediocre HP (60 points)
- Mid-power attack
- Mid-level range
- Mediocre HP (60 points)
- Long range
- Mid-level attack
- Higher HP (80 points)
- Low-level attack
- Short range
- Highest health at 500 points
- Highest attack
- Short range
- Generally terrifying
Bytecode also needed to be considered when we were programming our ‘bots. Each robot used bytecode by performing actions. Using up too much bytecode would result in delays. Archons and Scouts had a 20,000 bytecode limit per turn, and the rest, a limit of 10,000.
In addition, maps could start with neutral robots. When activated by an Archon, these robots would join that player’s team and run their team’s code for the rest of the game. Zombies did not attack neutral robots unless they were blocking their path.
Each game was played on a map of unknown size (somewhere between 30×30 and 80×80). Squares on the map could have a certain amount of rubble, giving most robots action delays if they moved onto a spot with rubble between 50-100. Most robots could try to clear the rubble from adjacent squares. When robots were destroyed, but not turned into zombies, the square would gain rubble equal to the robot’s maximum health at the time of destruction.
In Battlecode, distance was expressed using the squared value of the distance in order to make things simpler. This was important for the signaling, sensing, and attack radius. Robots were able to send basic signals to each other about their location, ID, etc.
If the game ever had to end with a tiebreak, it was decided by, in order:
- Number of controlled Archons
- Archon health
- Sum of parts and part costs of surviving robots
- Highest Archon ID
Our Team Experience
Coming into the competition, neither of us really had any concept of what Battlecode was. Being newbies, we didn’t start working on our bot until after the sprint tournament, the first tournament of the year, when our MSU classes started. Now that we have more experience, we’d definitely start working once the tournament started, in order to have ample time to build and test our bot.
The lectures were invaluable to learn what Battlecode was all about. Following along with the them produced a lot of valuable code that we would end up re-using and editing for use in our own bot. Being able to move and modify the existing code, while adding pieces of our own strategy, was a great learning tool. Really, the lectures were the main source of information and the pool of knowledge that we’d draw from throughout the month to better our bot in order to beat the reference.
In the beginning, we had no concept of how important parts, signaling, and sensing were. We also focused way too much on being able to beat another team’s player, almost completely forgetting about the zombies, which could be a just as, if not more, formidable of an opponent. In the interest of time, we pretty much also ignored any bytecode/delay issues from the start. Fortunately, they did not seem to greatly impact our play, as we didn’t do anything too wild or crazy that could have mattered in that sense anyway.
In the beginning our strategy was fairly simple: get stuff to work.
Originally, we worked off the lecture player bot built from following the online videos. We knew there were two basic strategies: go on the offense, or protect yourself and turtle-up. We decided that the more manageable strategy would be to build a lot of protection around the Archons, and not go after the other team or the zombie dens.
Eventually, we ended up building off of a different player provided on the battlecode website that was a little simpler to understand and change to our needs. We decided for our strategy that we would protect the Archons with lots of Turrets, intermixed with some Guards.
Our first step, we decided, would be to create a sort of spawning timetable.
We were initially building Turrets for a few hundred rounds, would take a break to spawn Guards for a few hundred more, and then go back to building Turrets for the rest of the game.
In the process of trying to beat the reference player, however, we found that replacing the Soldiers with Guards would lead to better results, as Guards would only work if they moved a bit more, and were able to circle the Archon/Turret mosh pit we were going for. Soldiers’ attacks were more ranged, and they seemed to interact better with the ranged attacks of the Turrets. We sacrificed, ultimately, the higher health and bonus damage against zombies for the lower health but longer attacks of the Soldier bot.
When building, we found that the area around our Archons would get too congested, and we would not be able to build any more robots, severely disabling our player, and essentially allowing ourselves to be swarmed by the zombies.
We then implemented some code to turn the Turrets into TTMs, and move away a certain number of squares. In addition to that, we gave the Soldiers a radius from the Turrets that they had to stay out of. This helped to alleviate most of our build problems in terms of congestion. A lot of this also had to do with the maps we used.
When scrimmaging the reference player, we found that we performed the best on maps where we were fairly boxed in. In maps where we were out in the open without much surrounding us, we were more likely to be overrun by the zombie hordes quickly.
The other team really never seemed to be the main problem in maps, no matter the size. On bigger maps, the problem was openness, and on smaller maps, the problem was the build congestion that came with being a little more blocked in. We experimented a lot with several maps, and figured out the best combination of strategy plus map terrain. Ideally, Battlebots should be able to function and adapt on any kind of map, but ideally we’d both have years of Battlebot-ing under our belts and an intense understanding of game strategy and the intricacies of the robots that came with it. So, for this year, we figured out what worked best, and we ran with it.
Looking forward, we’d recommend scrimmaging more players, and watching the games to improve and modify our strategy. We were so focused on getting a working bot this year, that this was something we neglected. Coming into the tournament more prepared in the future, we will have more time to make these adjustments. We really didn’t scrimmage anyone until it was time to try and beat the reference player.
So, we didn’t do so great, but we learned a lot.
First and foremost? To be a worthwhile competitor in Battlecode, you have to start early, as soon as it opens. Mostly because the earlier you start building a bot, the earlier you can figure out everything that’s working well, and more importantly, everything that isn’t. We lost some time with neither of us having built a bot for the sprint tournament, and then some more time to figuring out what we wanted out strategy to be, and how to make that strategy come to life.
Second, Battlebot takes a lot of time, more than I think either of us were prepared for. As students, we had a lot on our plates, and it was hard to find the time to meet, and the time to code, especially since Battlecode happens right at the beginning of the semester, coinciding with new classes starting, and criminal amounts of homework for the first week of class.
This year was all about figuring out what Battlecode was. We didn’t expect to place super well. Rather, it was all about figuring out what worked for us as a team and how to structure our development for the coming years. Now that we have a general idea about the schedule and gameplay, we’ll be ready to be true competitors in Battlecode, 2017.
In the end, it was worth it. We learned a lot about game programming and Battlebot-ing. And, on top of learning about Java and the nuances of game code, we had fun, and we can’t wait to participate in next year’s tournament, where we’ll do a lot better now that we’ve got the basics figured out.
Check out our code on github (team368): https://github.com/ColleenRothe/KC-Power-Team.git
(A picture of the client with some teams ready to play against one another on the map “wormy”)
(A snapshot of the statistics for the two teams. The red and blue sections are player controlled. The gray section is neutral, and the green section is for zombies.)
(A picture of an active game on the map “wormy”. All of the yellow dots are the “parts” that fuel building in the game. The green circles are zombie dens. The blue and red shapes are player controlled bots. Dark grey squares represent spots with >100 rubble on it.)
(All of the bots but Archons and TTMs. In order of appearance from top to bottom, Scouts, Soldiers, Guards, Vipers, Turrets.)
(Destroyed Archons on the left, and Alive Archons on the right. When all Archons are destroyed, the game ends automatically.)