Sunday, March 15, 2015

Hey there!  This is my simple blog post about this year's Battlecode competition!  This blog, while covering points about the competition as a whole, will primarily focus on Team 413 or Team NPHard.

GitHub Repo for NPHard

BATTLECODE 2015


For those who don't know what Battlecode is, it is essentially a programming competition where teams program the AI (artificial intelligence) of robots that compete against each other!  Each year the rules, maps, and objectives change however the game is generally played like a RTS (real time strategy) game.  As such, the game usually consists of gathering resources to build troops or other useful structures to overpower and beat your opponent.

This year's objective was to destroy your opponent's head quarters or HQ.  However, to do so you had to get past several turrets placed on the map to weaken your opponents HQ.  The "bots" this year varied from simple miners to powerful Commanders.

Below are a picture taken from the Battlecode website of a summary of this year's mechanics and units!























UNITS:


Beaver
The Beaver was the handy-man bot.  It was designed to do almost anything really
  • Spawned at HQ
  • Only unit that can build structures
  • One of two units that could mine ore
  • Has a weak attack at short range
Miner
The miner mines.  It's that simple.
  • Spawned at miner factory
  • Has a weak attack at short range
  • One of two units that could mine ore
Computer
The computer was a unit that was used for heavy bytecode consumption.
  • Spawned at Technology Institute
  • Extremely low HP
  • No attack
  • Moves very slowly
  • Higher bytecode limit
Basher
The basher is a unit that attacks while moving.  Pretty cool huh?
  • Spawned at barracks
  • Slightly better and more expensive than the Soldier
  • Has a decent attack that hits all enemies adjacent to it (up to 8)
  • Throwback to Battlecode 2013
Soldier
The soldier was the basic combat unit.  It moves and shoots, pretty simple.
  • Spawned at barracks
  • Has a mediocre attack at short range
  • Can attack often
Drone
The drone is a fast and mobile unit that could quickly scout out the map.
  • Spawned at Helipad
  • Has a mediocre attack at short range
  • Moves quickly
  • Can move over VOID terrain (but at half its normal speed)
Commander
  • Spawned at Training Field
  • Each team can only control one COMMANDER at a time
  • Ore cost doubles for each friendly COMMANDER that has been produced
  • Very high HP
  • Has a mediocre attack at decent range
  • Has special abilities
  • Gains experience from nearby defeated enemy units
  • Regenerate(passive) - COMMANDER gains 1 health per turn
  • Flash (20 turn delay) - Teleports to any valid location within 10 squares.  Can only be used when the core is ready and adds a movement delay of 1.
  • Leadership(passive @ 1000 exp) - All allied units within range 24 deals 1 additional damage.  If exp is at 2000, the additional damage is 2 instead.
  • Heavy Hands( unlocked @ 1500 exp) - COMMANDER attacks set the target's weapon and core delay to 3, if the delays are below 3.  Does not work on enemy Tower, Commander, or HQ
Tank
The tank was a powerful and expensive combat unit.
  • Spawned at Tank Factory
  • High HP
  • Has a strong attack at long range
Launcher / Missile
The launcher was a unit that could launch missile.  
  • Spawned at Aerospace Lab
  • Very high HP
  • No attack
  • Moves slowly
  • Generates a MISSILE every 8 turns and can store up to 5
Missile
  • Can be launched from its parent LAUNCHER
  • Dies after 3 attacks from any source, 5 turns after being launched, or when it calls explode()
  • Damages all adjacent units upon death, including allied units
  • Moves fast
  • Can move over VOID terrain
  • Cannot broadcast messages
  • Very very low bytecode limit

Game plan

First we needed to come up with a strategy. The wide unit diversity made it difficult in this years competition to say the least.  Last year, very aggressive strategies won due to the limit of unit options you had to respond with.  This year, there were so many dynamic strategies we could quickly think up, that it almost seemed that it was impossible for us to code in AI to recognize and respond to every different strategies.  So instead, we decided to go with the easiest strategy we could come up with and could make efficiently: swarm.  We figured if we could create an army of units that could attack and defend simultaneously we would have a better time of competing.  However, this was after we saw how effective drone swarms were in the sprint tournament before their nerf.

POST SPRINT TOURNAMENT BALANCE CHANGES
  • Drones now incur double the normal movement and loading delays if they move onto a VOID square.
  • Drone cooldown and loading delays increased from 0 to 1
  • Drone range decreased from 10 to 5
  • Drone supply upkeep increased from 5 to 10
  • Helipad turn cost increased from 50 to 100

 We had to come up with another unit to replace drones.  We ended up choosing soldiers.  They were cheap, effective, and a large enough group could take down a tower very quickly.  It was also easy to spawn soldiers indefinitely early on with only a single miner factory and a few miners.  Throw in the Commander's ability to increase the strength of nearby units, we decided our strategy could be effective to beat the reference player in the competition.  Since we both agreed that it would have taken too much time to make an army of tanks or launchers, we felt making soldiers was obvious choice.  We considered possibly implementing bashers, but we felt that with so many units having ranged attacks that our bashers would just be destroyed.  Even after bashers got a few buffs we felt it still was too much of a risk.

Getting Started

So the first thing we did was to create a template.  This served as an easier way for our team of two to organize our code and make it simpler to see changes.  It also made it much easier to see where code was going wrong or where the actual logic was failing.


This template, a mere 350 lines of code was only the start of our Battlecode 2015 career.  We started off by working on our swarm bot AI.  This entailed us creating a computer to handle the situation of where to send our bots.  Either have them defend a falling structure or attack an exposed one.  This became much more difficult than we anticipated however.

First we had to make sure we only spawned so many of any given unit which took a day to figure out.  We had to use broadcasting to make each bot aware of how many of a specific bot was already created.  This sadly ate more bytecode than we would have liked but it got the job done.  Next, was getting the bots to swarm a specific location.

We originally would take the x and y components of our target swarm position and convert it to a unique integer that could be broken back down into the two original coordinates.  However, due to the limit of what could be broadcasted between the computer and the soldiers with consideration of the map size (where the coordinates would become large) the bots would pile around a spot that wasn't the intended swarm location.  This required a couple days of testing to figure out a value that when used to create the unique integer solved the problem.  As it turned out, our broadcasting was taking so much bytecode, that by the time a signal was sent, all the other bots would have already taken their turn.  This made our bots target a random location specific for each map.  After we tweaked how our broadcasting worked and how our target location was calculated, our bots swarmed like locusts!

Getting the bot off the Ground


The next step we took was how to limit our resource accumulation compared to the rate of which our soldiers spawned.  After scrimming against some opposing teams, we discovered we were too slow off the start of a match.  This made other swarm strategies beat us regardless if our army took better advantage of their exposed tower.  This made us reconsider how we ran the army.  We prioritized spawning a miner factory that gave us enough resources to build a supply depot, then a couple computers, then finally our barracks for soldiers.  This change made our bots take towers much earlier and made them more formidable thanks to the starting supply they received at the start of the round.  However, we had to remove AI in our computer to ease our debugging process. 

Even this wasn't perfect however.  Since we felt that our miners were too slow, we ended up sticking with a supply depot that would speed up miners and beavers.  While this gave us more structures to work with early on, as a result our army came out much slower than we originally designed.  However, we felt it was necessary since our computer needed the extra turns to even calculate where our soldiers needed to be in the first place due to bytecode consumption.

Last minute Additions


The final tweaks were to add stronger units to combat the loss of our early game army.  Since we could generate these structures earlier than before, we agreed that we needed to make use of these structures.  Considering how the tank and launcher did amazing in the skirmishes we saw, we couldn't miss out on the extra damage!  We concluded that if an army of soldiers was strong, than tanks and launchers would be even better!  

However, this took much more time to program than anticipated.  This resulted in the team failing to even efficiently upgrade to their technology institute needed to spawn a Commander as part of the original plan.  It also made necessary changes such as spawning tanks, launchers, and bashers also impossible to make efficient and useful for the bot overall.  While we could spawn them, is wasn't possible for us to find a time for which to start spawning them and how to tweak our miners as a result to the higher resource demand.  This created a poor use of resources and rounds.

Final bot


By the end, our bot was far from complete.  We couldn't even finish our primary strategy since we became overwhelmed with other ideas.  While the ideas were very powerful if implemented, it ended up costing us our rarest resource: time.  As the deadline drew near, we decided to accept our code as is and not risk breaking what we had already accomplished.  As such our bot was unable to beat even the reference player but not without trying.  Our bot had a very strong middle game and was capable of taking down one or two turrets with impressive speed.  

This however revealed the flaw in the swarm plan that we failed to consider to begin with.  If our army couldn't win the game in one swoop, we were left open to attack.  With no army and not enough structures to spawn them quickly, we were just throwing units on a pointless attack.  In the end, our own strategy was our own downfall.  Even if our army made a large dent in the enemy's towers, we were left open to the point not even spawning tanks or launchers could save the HQ.  

What did we learn?


The sad truth was, this year was a rough one.  Due to one of the team members of NPHard being new to battlecode, he had a very hard time coding the bot AI.  This left most of the work to the other team member who now had to find time between school and work to code individually.  This complication made the simple sounding tweaks take a few days instead of a few hours.  This made it impossible for the new team player's great ideas of how to manage specific strategies impossible to implement.  

Yet this taught our team a few things.  First, program in such a way, that additions come quickly and without much time consumed. Also we learned that taking time to have a fuller understanding of the javadocs and to watch the tutorials can teach even a novice how to program in Battlecode.  Lastly, we learned that we should not only look at how to make our strategy stronger and more efficient, but also what strategies would conquer our as well as the flaws in our overall strategy.  With these in mind, our bot next year will mostly likely be simpler, but also more reliable.  

However, the template used in this year's Battlecode is a must include for next years.  It made organization much simpler and is the sole reason why we were able to code as much as we did in the end.  Even the member of NPHard who struggled found it easy to navigate!\

NPHard vs Teh Devs #2           Our fights against the reference player!

You can see our bot lacked in responding to early threats as well as forcing our army back once it got too low in number as we mentioned above.  It also focused the first turret on map instead of the closest turret.  Even our army took much longer to start spawning since we initially expected to be spawning larger and stronger units in a much more optimal way.
These would have been simple changes that were on the to-do list, but sadly this is what happens when these is not enough time.  Overall, the bot could do it's job, but it could have been done better and with more time, I feel that we could have made our bot easily beat the reference player with simple tweaks.

Maybe next year!

No comments:

Post a Comment