Distributed AI BattleCode Player

Screenshot of a BattleCode game between an unintelligent player (red) and my distributed AI player (blue)

This project sought out to implement a distributed artificial intelligence game-playing system for the real-time strategy game BattleCode. The following is a description from the BattleCode website:

Two teams of robots roam the screen managing resources and attacking each other with different kinds of weapons. However, in BattleCode each robot functions autonomously; under the hood it runs a Java virtual machine loaded up with its team’s player program. Robots in the game communicate by radio and must work together to accomplish their goals.

A BattleCode game is divided into individual rounds, or timesteps, in which each unit can perform actions. There is a restriction on the amount of code each unit can execute during each round, in the form of a hard limit on the Java bytecode that can be executed. Once this limit is reached, the execution of an individual unit’s code is suspended and is resumed the following round. Because of the uncertainty on when this break will occur, the code for the units must be robust in ensuring that outdated or incorrect information is handled appropriately when making decisions.

Furthermore, the BattleCode game itself contains a variety of different resources, items, weapons, and types of terrain. The game is played on a discretized grid populated with such objects. Units have hit points which can be reduced due to weapon fire, or regenerated through special items or a teammate equipped with a Medic item. The object of the game is to eliminate the enemy units.

Distributed AI concepts were implemented in the domain by utilizing the agents’ local sensing capabilities along with their message passing capabilities. These two capabilities allow agents to detect friendly and enemy agents and adjust their behavior accordingly, while also relaying important information to nearby teammates so that effective group behavior is achieved.

System Description

This project was primarily concerned with various types of group navigation within the BattleCode domain. Given that in general the team with more units in a particular area will likely defeat the other team for control in that area, efficient group navigation is an important aspect of making a competitive BattleCode player. Challenges related to navigation that this work hoped to address include:

  • The group behavior should be fluid rather than congested, especially during battles
  • Leaders should be able to manage a local area of robots for high level navigation orders
  • A group engaged in battle should be able to enlist other soldier robots to help fight
  • Worker units should act defensively to prevent themselves from dying when encountering enemy robots

In order to address these challenges, this work focused on three primary areas:

  • Low-level group movement behavior via flocking algorithms
  • Higher-level navigation objectives that are communicated between groups
  • Safety and communication behaviors of worker units

For the first area, several flocking algorithms were explored but in the end the Boids algorithm proved to have the best combination of functionality, ease of implementation, and runtime efficiency.

The Boids algorithm operates by using a set of rules that govern how an individual responds to neighbors. These rules govern the behavior to ensure that members move toward the group’s center of mass while also maintaining distance between members. Additionally, members will attempt to match the velocity of nearby members. The algorithm was extended in order to provide additional behaviors such as the ability for a group to tend toward a particular location. The Boids algorithm also allows for perching (in which members temporarily hold position) and scattering (in which the members rapidly disperse). In this way, units only need to share high-level navigation information, while the details of individual robot motion are left to the swarming algorithm.

The Boids algorithm was implemented into game player with the following tunable movement rules. Each rule has a scaling parameter to control that rule’s contribution to the individual agent’s movement.

  • Moving toward center of mass of flock (clustering)
  • Moving away from nearby robots (collision avoidance)
  • Moving toward objective location specified by leader
  • Moving toward leader

In addition to the flocking algorithms to govern low-level agent movement, high-level navigation and communication algorithms were implemented as well. These algorithms calculate and share navigation objectives based on the following protocol.

Based on a configurable parameter, robots periodically perform a detailed survey of their surroundings to determine nearby enemy and friendly robots. From this survey, the robots calculate information such as the size and center of mass of the visible enemy swarm and the concentration of friendly robots in the area.

This information is used to create an estimate of priority, which is then broadcasted to friendly robots nearby. Nearby worker units will flee in the opposite direction of the enemy swarm, while also repeatedly rebroadcasting the swarm information they received so that any soldier robots encountered while fleeing will be made aware of the enemy swarm position and size.

Nearby robots will use the priority estimate along with the distances from their current location to their existing objective and the new incoming objective to determine whether to split off from their current path or continue as planned. Soldier units will also rebroadcast the objective information if the priority is higher than their current objective. Leaders will store multiple objective locations at a time in order to create a running priority-ordered list of destinations. Robots who decide to join forces and fight alongside the original broadcaster will form a new group under a new elected leader.

Future Work

There are a number of improvements that could be made to the player AI that would necessitate a rewrite of the navigation and communication schemes. Initially the vision for this project was that low-level protocols for these tasks could be implemented as layers, on top of which the leaders could communicate and form high-level plans. It would be interesting to retry this approach a second time to see how feasible it would be given all of the restrictions of the domain.

There are also a number of refinements to the flocking algorithm that would be interesting to implement, such as dynamically-adjusted weights for the different movement rules. For example, a group could act with the defensive strategy until enough group members are collected, at which point the group switches to a more aggressive strategy to hunt and destroy nearby enemies.


This project developed a player AI for the BattleCode domain. A number of schemes were explored for creating a competitive player, and this project focused on various types of navigation algorithms. Flocking behavior, objective sharing, and high-level prioritization were explored as part of this process, and various player profiles were developed using different combinations of parameters for those tasks.

Experimental results were obtained by creating matchups between all of the different profiles. The results indicated that high-level navigation had a greater impact on performance than flocking, and that clustering together is an important aspect of destroying enemies effectively. The results also indicated that the performance benefits obtained from more intelligent behavior can be more than offset by their additional bytecode cost.