Matthew Jannace

4/1/2011
Masters Degree Project


Multi Agent Systems & Robocode



Introduction
The power of the masses derived from communication and cooperation is the foundation
of Multi Agent Systems. A Multi Agent System, in its simplest form is a group of autonomous
agents that can interact with the world and each other. Multi Agent Systems are advantageous
by design because they allow a group of communicating and cooperating agents to perform a
task that no single agent could and/or perform a task faster than any single agent could. The
advantage of agents working together to achieve some goal that would be beyond the ability of
any single agent can be seen in nature. For example, ants are a great example of agents in nature.
An ant colony is made up of many ants. Each ant is an agent in the colony. The colony thrives
because the ants interact with one another and cooperate to perform tasks that would be beyond
the abilities of any single ant.
In Multi Agent Systems, there are two basic ways of performing decision-making
operations: centralized and distributed. Centralized Systems are systems in which a single agent
is in command, and it dictates the actions of the other agents. The military is an example of a
Centralized System in which a commander dictates the actions of the subordinates. On the other
hand, Decentralized Systems are systems in which no single agent is in control but rather agents
autonomously communicate with each other to find and contract other agents to assist them at
completing some job. Decentralized Systems are more common in nature. The ant colony is an
example of a Decentralized System in which no one ant controls the action of all the other ants.
Thus, decisions are made from the sum of all the interactions between the ants. In addition to
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> =?
ants, schools of fish are an example of Decentralized System. In a school of fish, there is no
single leader but rather all the fish interact with their environment and with each other. The
interactions allow the fish to avoid hitting each other and being singled out by predators. Fish
autonomously perform actions and interactions with the fish around them, allowing a school of
fish to travel from one location to another while being protected by their swarming action.
When it comes to Multi Agent Systems analyses, there are several software products to
facilitate the simulation and analyses of the agent systems; Robocode is one of these software
products that allows the simulation and analysis of agent systems. Robocode was originally
designed for oneon-one robot competitions. However, with the inclusion of a team
competition, Robocode allows for Multi Agent System analyses.

!"#$%& ( ) / 1"4@-% A.%& 7> " 6787*79% B"##-%
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?@
Robocode is a Java programming simulation game, where the goal is to develop a robot battle
tank to battle against other tanks. The battles can be run in real-time and rendered on the screen,
or run in the background and provide only results. The Robot battles can be one-on-one or team
based. The ability to fight in teams allows multiple agents to work together to fight opposing
enemies.

Objective
The objective of my Masters Degree project is to use Robocode as a tool to demonstrate the
utility of cooperative Multi Agent Systems. To do so, I will use Robocode to simulate the battles
between two types of agent teams: unified and non-unified. In the simulation, each robot will be
considered an agent. Many agents will make up a team. A unified team is a team of cooperating
agents that will work together to defeat the other agents in the battle. The non-unified team will
be a collection of independent agents that will fight all other agents on the field. The goal is to
demonstrate that those agents that work together as a team are better able to defeat and win
against an opponent team of non-unified agents.





!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?@

Project Background
Before we can dive into the Multi Agent aspects of the project, we must first understand
how Robocode works. In Robocode, a robot tank is made up of three parts, the body, the gun
turret, and the radar. All three parts of the robot are able to move independently of each other.
In the game, Robocode enforces specific game physics to simulate real world physics to some
degree.

!"#$%& ( ) 6787# &.#$ A":# .9%)#.>.%9 *+,%-./0 (1123
However, because the game is discrete and the real world is continuous, the physics of the game
are based on the game clock. The game is based in turns, and measured in ticks, where at every
clock tick each robot is able to take in information about the world and dictate actions to be
performed in the world before its next turn. The world consists of a two-dimensional Cartesian
plane measured in pixels. The exterior of the Cartesian plane consists of a field-bounding wall.
Robots are able to move about the field but cannot leave the field because of the bounding wall.
A robot moves around the field by choosing a heading and choosing a negative or positive
velocity. A robot accelerates 1 pixel per turn and decelerates 2 pixels per turn and its velocity
can never exceed 8 pixels per turn. The amount a tank can rotate its body is equal to (10 - 0.75 *
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?@
abs (velocity)) degrees per turn. Thus, the rotation of the robot body is a function of its velocity
such that a robot can rotate faster when it has a low velocity and rotate slower at a high velocity.
The gun turret can rotate at a maximum of 20 degrees per turn and the radar can rotate at a
maximum of 45 degrees per turn. Though the radar can only rotate 45 degrees per turn there is
no limit to the distance it can detect other robots. In the game, damage results in the robot losing
energy. A robot can incur damage in three ways, by being hit by a bullet, colliding with another
robot, or colliding with a wall. The resultant loss of energy from being hit with a bullet is a
function of the firepower of the bullet. Thus, a bullet hit incurs 4 * firepower in damage and if
firepower is greater than 1 it does an additional damage = 2 * (firepower - 1). The resultant loss
of energy for colliding with another robot is 0.6 and the energy loss for colliding with a wall is
abs (robots velocity) * 0.5 1. The energy loss is never less than zero. The objective is to
destroy enemy robots; to do so opponent robots must use their radar to target enemies and shoot
at them with their guns. When a robot fires its gun, it must specify the firepower of the shot.
The fired bullet travels at a velocity of 20 3 * firepower, thus the stronger the firepower the
slower the bullet. In addition, when a robot fires its gun, the gun generates heat, and the robot
will be unable to fire again until the heat dissipates back to zero. The amount of heat a gun
generates equals 1+firepower/5.
1

In Robocode, there are several popular methodologies used for controlling the robot. The
two big movement methodologies are anti-gravity movement and minimum risk movement.
Anti-gravity is based on the concept of vector summation to calculate a direction and velocity.
The concept of anti-gravity is similar to gravity between planets in the solar system that all have
attractive forces that pull objects close to them, except antigravity works in the opposite.

A
B6787*79%CD"4% ;$23.*3+ ?EAEF
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?=

!"#$%& ( ) @$% 87-9 A:%2 -.)% B7.)#.)0 97&)&":9 .)9.*"#%3 #$% /)#.CA:"D.#2 E%*#7:
Instead of the robots being attracted to each other with gravity, they are repelled from each other
by antigravity. Thus, movement comes from computing a resultant vector of all the antigravity
forces acting on the robot and moving in the resultant vector direction.
Minimum risk movement is similar to anti-gravity but its implementation is different. In
minimum risk, the robot creates a concentric circle of some radius R with itself in the center, and
then it randomly selects N points pseudo evenly distributed in the circle. The robot then
evaluates every selected point by passing it to a minimum risk function. The minimum risk
function usually evaluates the enemys distances from the point or any other dangers the
developer wants the robot to avoid.
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?@

!"#$%& ( ) A$% :%9 ")9 8-,% 97#3 3,::7,)9.)0 #$% #$:%% :787#3 .) #$% 0:%%) 3B,":%3 ":% #$% #%3# C7.)#3D E-,% 97# $"F% -%33 :.3G
#$") #$% :%9 97#3D

The goal of minimum risk is for the agent to find the point that has the least risk and to move to
that point. Anti-gravity and minimum risk are not the only movement methodologies. However,
they are the most commonly used and fundamental methodologies, where other movement
strategies are largely modifications of anti-gravity and minimum risk.
There are many methodologies in Robocode when it comes to targeting. The
fundamental targeting strategies are head-on, linear, circular, and guess factor. Head-on
targeting is the simplest of all the targeting methods. In head-on targeting, you simply shoot at
your target when you see them; head-on targeting is a simple reactive targeting method. Linear
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?@
targeting is more advanced than the head-on targeting. In linear targeting, the robot uses
information about its opponents velocity, direction, and distance to calculate a firing direction.
The goal is to calculate a direction, that if the opponent continues to move in a straight line at a
constant speed then the fired bullet will intercept and hit the opponent. Circular targeting is the
same as linear targeting except the robot assumes the opponent is moving in a circular pattern.
Guess factor targeting is the most complex of the fundamental targeting systems. In guess factor
targeting, the robot assumes that the opponent is moving randomly and that it should shoot in
some guess factored offset from the current opponents bearing.
Guess factor shots are tracked so that the correct offset can be determined for each shot.
These corrected offsets are stored in a data structure that is segmented on the possible subsets of
the enemys observed movement behavior when the shot was fired. The tracking and updating
of guess factor shots results in future shots being more accurate. When a robot goes to take a
guess factor shot the robot will first compare the current enemys information against the
segmented data structure. If there is an entry of an offset that was successful at hitting the target,
when the target exhibited the same heading and velocity then the robot will use that offset again
to try to hit the enemy. Thus, guess factor targeting is random at the beginning but as more shots
data is segmented and stored; the performance of the gun improves.
When it comes to radar in Robocode, there are two fundamental methodologies: spin
radar and perfect lock radar. Spin Radar is simply the continuous rotation of the radar in one
direction giving a complete picture of the entire field every 8 ticks. However, this can cause a
delay in the retrieval of robot locations discovered in the 1
st
tick to the 8
th
tick, meaning that an
opponent found in the 1
st
tick could move up to 64 pixels between being seen in the 9
th
tick. This
lack of information between scans can be problematic with advanced movement and targeting
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% = 7> ?@
methods as the targeting and movement methods are using inaccurate information. The
alternative to spin radar is perfect lock radar. In perfect lock radar, when an opponent is
detected, the robot focuses its radar on the opponent and only moves the radar to track the
movement of the opponent. Therefore, perfect lock radar always provides up-to-date
information on an opponents position. This up-to-date information improves the performance
of advanced targeting and movement methodologies. However, the tradeoff for the up-to-date
information on the target is that the robot does not scan the rest of the battlefield. Thus, when
the robot has a lock on the target, the robot cannot gather information about the rest of the
opponents on the field. Therefore, many bots use various combinations of the two radar
methodologies to get the best results and mitigate the disadvantages of one with the other.
Lastly, communication is central to the notion of teams. There are three basic types of
communication, centralized where all robots in a team speak only to the commander and the
commander speaks to everyone, distributed where robots can speak to each other and a hybrid of
the two. In teams, communication effectively determines how decision-making will be
processed, by either centralized decision-making or distributed decision-making. Centralized
decision-making means that one robot is the leader and it gives out orders. Alternatively, in
distributed decision making each robot makes decisions based on the information available to
them.





!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @A
Implementation
When developing a team of cooperating agents, I spent a great deal of time evaluating
other competitive un-unified robots to see what methodologies were most effective. Then the
task was to take those effective methodologies and implement them in a robot in such a way as to
use the communication available between the robots as an advantage.
The key questions I discovered to effectively create a team of robots are: should robots in
the team be heterogeneous or homogeneous, and should decision-making be centralized or
distributed. There are pros and cons to each decision. In the matter of heterogeneous or
homogeneous, I decided to go with homogeneous robots, with the time constraints it allows more
time to be spent working on all the robots at once versus working on multiple robots separately.
In the matter of centralized versus distributed decision-making I decided to go with distributed
decision-making. There were many significant advantages for choosing distributed decision-
making over centralized decision-making. Distributed decision-making does not require a leader
to be chosen. Therefore, their is no overhead cost, time wasted in communicating to make
decisions, up front for choosing a leader or down the line to choose another leader if one dies.
Second, distributed decision-making allows robots to process data much more quickly since they
are able to communicate with each other and not just the leader. In Robocode the process of
sending a message to the leader and getting a response would take three ticks versus direct
communication with no response takes only one tick. Lastly, distributed decision-making is fault
tolerate, if a leader gets killed in a centralized decision-making team, the whole teams cohesion
is lost and time must be spent choosing a new leader; whereas, in distributed decision-making
when one robot dies the team moves on without having the overhead costs. With these decisions
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% == 7> ?@
made, I created a team interaction behavioral goal; the team would try to simulate the defensive
actions of flocking creatures with a team predation attack strategy.
I started development by using a competitive yet simple open source robot named
HawkOnFire.
2
HawkOnFire was used as the foundation for the team agents. HawkOnFire
used minimum risk movement, head-on targeting, spin radar, and had no communication or team
awareness.
Communication
My initial task was to start with the HawkOnFire source and add basic communication
and team awareness, thereby preventing teammates from targeting and shooting at each other.
With the added awareness, the task became one of deciding what information to share with
teammates. I decided that agents should broadcast information they gather to their teammates. I
choose broadcasting because each robot was autonomously making decisions and the best way to
make a correct decision is with up-to-date information. Therefore, at every turn robots broadcast
to their teammates any information that was learned during their turn. For instance, if a robot
detects another opponent during its turn it broadcasts the detected opponents location and other
information about the detected opponent to its teammates to allow them to make a more
informed decision during their next turn.
In the current implementation, during a robots turn, it creates a TeamMateMessage
Object. The robot then adds to that object information that it collects during its turn. Currently
the robot adds to that message, its own current XY location, the XY location the robot is moving
to, any enemy information that it has received from its radar scan, any information on bullets
that the robot fired during its turn, and any information on bullets that the teammates do not need

?
A67B,+ ?CCDE
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? >@
to track anymore. At the end of the robots turn, it broadcasts the TeamMateMessage Object to
its teammates. Before a robots turn, the received messages are processed. When a robot
receives a TeamMateMessage Object, it processes the information in the message and updates its
current information from the message. The TeamMate Message contains:
Enemy robot locations
Message senders location
Message senders destination,
Message senders active friendly fire.
Message senders inactive friendly fire.

Movement
Movement for the team robot comes from a modified version HawkOnFires minimum
risk movement function. The original HawkOnFires minimum risk function only evaluated risk
of a point based on the energy level/distance of opponents and distance from the robots last
location. The team robot uses a modified version, in addition to the original criteria; the function
also evaluates:
Distance from teammates
Distance from teammates next locations
Distance from friendly fire current positions,
Distance from friendly fire near future positions,
Distance from the centroid of the team,
Distance from the target.

In addition, to keeping away from enemies, the added criteria forces the robot to avoid hitting
teammates, avoid crossing the path of friendly fire, and trying to stay near the centroid of the
team thus trying to keep the group relatively close together for the defensive flocking strategy.
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @A


!"#$%& ( B C$% #%"4 .4D-%4%)#"#.7) 7? !.).4,4 6.3E %F"-,"#.7)

Event Conditions
The minimum risk function does a decent job keeping the robots out of harms way if it
can. However, to decrease the chance of being hit and reduce stuttering movements, the
minimum risk movement chooses a destination point and proceeds to move to that destination in
a straight line. After choosing a point and moving toward it, the minimum risk movement does
not reevaluate the world until it is about to arrive at the destination point. This however leads to
robots traveling into danger blindly. To compensate for the weakness of the minimum risk
movement and to reduce the blind danger, custom event conditions were implemented. Custom
event conditions are special methods that can be implemented in Robocode. These event
conditions are tested before every turn, if an event conditions returns true then a custom event
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @A
flag is raised. In the team robot, there are four custom events, a pair for friendly fire avoidance,
and a pair for other robot avoidance.

!"#$%& ( B / C%"4 /0%)# ")9 #$% *7::%3D7)9.)0 %E%)# 8,??%: :.)03
In each pair of custom events one event works opposite of the other, the premise is that one event
in the pair raises a flag and the other removes the raised flag. Events are triggered when objects
on the battlefield violate or respect a set distance from the robot. The event conditions can be
visualized as representing concentric circular buffers drawn around the robot, in which each
condition requires its circle to have a different size radius. The bullet buffers are broken down
into two tested conditions: are bullets respecting the bullet distance buffer and are bullets
violating the distance buffer. The robot buffers are also broken down into two tested conditions:
are other robots respecting the distance buffer and are other robots violating the distance buffer.
The respected buffer's radii are slightly larger than their violated counterparts are and buffer
violations take precedence over respected buffers. The effect of a violation flag being thrown
causes the robot to perform an evasive move and immediately reevaluate the field and chooses a
new destination to avoid the potential threat. The respected conditions are the triggers for the
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @A
all-clear signal and that the robot can return to its normal minimum risk movement. The
conditions help to decrease the chance of the robot taking on damage when it could be avoided.

Targeting
The original HawkOnFire robot used head-on targeting. However, in testing it was
evident that head-on targeting was inefficient at hitting opponent targets. After watching many
battle rounds, it was clear that a new targeting method would be advantageous. The early team
robot with head-on targeting would always miss a target when it was moving in a straight line.
Head-on targeting in the robot was replaced with exact linear targeting. After implementing
exact linear targeting, the battle results were improved. Even though exact linear targeting has
pitfalls when trying to hit targets moving in circles and random stop and go motions, the team
makes up for a single robots targeting deficiencies.

!"#$%& ( B C$:%% C%"4 /0%)#3 C":0%#.)0 ") DEE7)%)#
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @>
When it comes to targeting, the team gangs up on the opponent that is closest to the centroid of
the team. Triangulation of the teammates in respect to the opponents allows for the probability
that at least one out of three shots fired will connect with the target. The premise of the team
targeting is that of the machine gun, if you shoot enough bullets in directions around the target
probabilistically, some of them will hit the target.
In addition, to the team targeting the agents of the team can also demonstrate selfish
behaviors when targeting. If an agent of the team moves to a position, in which the distance
from the team agent to another opponent is less than half the distance from the team agent to the
team target then the team agent will briefly target and shoot at the closer opponent until the team
target is back within range. The ability to have the team agents become selfish at times is a facet
of Multi Agent Systems. In some Multi Agent System designs the utility of the team is not the
goal but rather a mean for each agent to succeed, therefore, agents only participate in the team so
long as it is advantageous for them to do so. Therefore, if an agent has a better opportunity
working on its own, even if just briefly, then the agents will choose the actions that are best for
it.

Radar
The original HawkOnFire radar was simply spin radar. However, leveraging the team
communication ability the team robots dynamically switch between spin radar and lock radar.
The team robots autonomously choose the opponent that is closest to the centroid of the team.
Then each robot checks to see if they are the closest team robot to the target. If the robot is the
closest, it performs a radar lock on the target and supplies the other members of the team with
constant updates about the targets location, heading, and velocity. The other teammates that are
MaLLhew !annace, MulLl AgenL SysLems & 8obocode MasLers ro[ecL
age 17 of 26
not the closest perform spin radar to supply each other and the locked on robot with up-to-date
information about the other robots on the field.

!"#$%& ( - 1hree AgenLs wlLh Lhe closesL agenL Lo Lhe LargeL performlng a radar lock-on.
This dynamic switching allows robots to move around a target and pass off lock on radar duties
without negotiating. The process of switching off with out communicating the transfer or lock-
on duties results in the target not being picked up by the new agent for a worst-case 4 ticks.
However, the actual loss in precision is negligible and the benefits of autonomous decision-
making make up for the potential loss by reducing pass off overhead and improving the robot
reactiveness.

Implementation Evaluation
The development of the robot team was not a simple task. I intentionally started with a
working competitive source in an attempt to ease the development burden so that I could focus
more on the agent interactions. Starting with a competitive source, however, proved to do little to
reduce the complexity of the work required to effectively create a coherent and competitive
team.
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @A
The first difficulty I ran into was trying to modularize the HawkOnFire source code.
HawkOnFire was a simple robot with its source contained in a single java class. Early on in the
project, I knew that, with all the functionality I was planning to add, it would require a modular
source that would be more manageable to work with rather than one giant class. The process of
trying to determine the best way of modularizing the code was a challenge, and has been a
running challenge the entire development period. It was difficult to determine an effective,
practical, and understandable way of organizing the source code so that others could easily read
it. The result was a structure where the main robot class created instances of the seven primary
modules: communication, custom events, debugging, movement, radar, strategy, and targeting.

!"#$%& ( ) B.3,"- C."0:"4 7? D"3.* /0%)# 1#:,*#,:%
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? @A
Further, each of the seven primary modules contains their own sub classes. In addition, to the
primary modules there are some helper classes that all the modules use and a collection of static
utility classes. The structure of the modules and classes allows for better understanding about
what tasks the modules perform.
Another implementation issue was trying to have the agents move around a common
location that moved with the agents movements and trying to select a target that was closest to
that central point. At first, I was not sure how I was going to solve this problem, I could easily
find the center of two points but trying to find the center of a multiple agents was unclear.
However, with research I was able to find information on how to find the center of mass for a
polygon. This was not exactly what I was originally looking for but it proved to be an effective
solution to the problem. In addition, I was able to locate some open source code that performed
the centroid calculation, which was helpful.
Another issue was trying to determine what movement methodology to use. Minimum
risk is effective but with out having a good risk function it is useless. In early testing, the
minimum risk movement worked poorly at being reactive. Therefore, I invested much work
getting the antigravity moment working. The antigravity movement was easy to understand and
implement. However, even though it was much better at reacting to changes, it was not as
effective as minimum risk for reducing the possibility of getting shot by moving long distances.
Therefore, I attempted to create a hybrid implementation using the custom event conditions. My
intentions were to use minimum risk movement for normal movements and the antigravity for
evasive movements. This plan was good in theory, but the implantation proved to be only
slightly more effective then just the minimum risk movements. That is when I decide to remove
the antigravity and use a modified minimum risk function. The new plan was to have a normal
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? =@
minimum risk movement and an evasive minimum risk movement. The differences between the
two are minor and the two methods are nothing more than wrappers that call the heart of the
minimum risk function.
The implementation of the minimum risk movement is such that, on every turn the
movement method is called. When the movement method is called, it determines if a normal or
evasive move is required. If a normal move is required, the normal minimum risk movement is
called. When the normal minimum risk move method is called it first checks to see if the robots
current location is within 50 pixels of the destination location; If it is, it reevaluates the world
and picks a new destination. However, if the robot's location is not within 50 pixels of the
destination then the robot does not reevaluate the world but blindly continues the destination.
Whereas, if an evasive movement was required then the evasive minimum risk movement
method would be called and the world would automatically be reevaluated to select a new
destination without concern for the robots distance to a destination.
Therefore, the essential difference between the two is that the normal movement only
reevaluates the world when the distance to its destination was less than the threshold. Whereas,
the evasive move immediately reevaluates the world to pick a new destination. In addition, the
radius chosen in the original minimum risk function was changed to be the distance from the
robot to the nearest object on the field whether it is a teammate, enemy, or bullet. This modified
minimum risk function proved much more effective than the original and the antigravity.
Lastly, another issue that was a challenge to over come was to prevent robots from
shooting at the target when their teammates were in the line of fire. When I first tried to tackle
this problem, I knew I could draw a line from the shooting team robot to the target and then test
if any teammates intersected that line. However, a single line would not work because it was too
MaLLhew !annace, MulLl AgenL SysLems & 8obocode MasLers ro[ecL
age 21 of 26
narrow of a firing range to test. I then thought about using an isosceles triangle with the base
line running through the target perpendicular to the team robot and the team robot being the top
point of the triangle. I knew using a triangle would work and the fact that the Java AWT package
contained a triangle class simplified the process.


!"#$%& () - 1hree 1eam AgenLs wlLh Lhelr Lrapezoldal flrlng ranges.
However, through testing, it was determined that the triangle also had too narrow of a firing
range test area when the team robot was far way from the target. I then decided to use an
isosceles trapezoid. The trapezoid shape increased the firing range space needed to prevent
shooting a teammate robot. To create the trapezoid I began by taking the absolute angle of the
gun barrel and adding 90 degrees to it, the resultant angle would be perpendicular to the gun
barrel. I then drew a 60 pixels long line through the team agent with the team robot in the center
of the line. I then took the gun barrels heading and split the angle into plus/minus 0.125
degrees. The 0.125 was determined to be the most effective during testing. With these new
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% == 7> =?
plus/minus angles, the robot projects a point equal to the targets distance away from the robot
and using the plus/minus angles, it generates two new points. The robot then takes the two end
points of the parallel line that runs through the robot and the other two generated point and
creates a java AWT polygon in the shape of an isosceles trapezoid. With the created polygon
object, I test to see if any of the four corners of a teammate's robot body are contained in the
trapezoidal polygon. If any of the four points of a teammate's robot is in the polygon then the
robot does not shoot.

Conclusion
The objective of the project was to build an effective unified team of agents that could
defeat a team of non-unified agents and thus demonstrate the utility of Multi Agents Systems.
The created unified team is an example of Multi Agent Systems in action and successfully
demonstrates the power of cooperating agents working together to achieve a common goal.
To quantify the results I performed two classes of tests. First, I tested the team agents
against the original HawkOnFire robots from which they descend. Second, I tested the team
agents against the top 20 of the single agent melee robots.
In the test between HawkOnFire and the team agents, I matched three HawkOnFire
robots against three team agents for a battle containing one hundred rounds. During this battle, I
had each team agent track and record, to a comma separated file, statistics from each round, and
then the overall battle results. At the completion of the battle, these stats were analyzed and
presented in the, HawkOnFire vs. Agent Team Battle Results. The results from the battle can
be interpreted in two ways, simply in terms of actually winning rounds by destroying opponents
and more advanced by the scoring that Robocode performs. Robocode does not just qualify
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? =@
winning as the team that beat its opponent the most, but by awarding robots points for effectively
attacking opponents and for defending themselves from attack. These earned points determine
rankings. The simple winning results showed that the agent team won 86% of the battles against
the HawkOnFire team. In respect to the Robocode results, the Agent Team received 66% of the
total score thus beating the HawkOnFire Team and taking 1
st
place in the battle. From the one
hundred round sampling, it can easily be seen that the agent team clearly is more competitive
than its predecessor.
In the second-class test, I evaluated the agent team against the top 20 melee robots.
However, currently in the official standings HawkOnFire is ranked 42
nd 3
so in an attempt to
more fairly compare results I matched the agent team against the top 20 of 2005 where
HawkOnFire was ranked 17
th

4
. The results of the matches can be seen in tables under, Top 20
of 2005 vs. Agent Team Battle Results. The battles were based on one hundred rounds for each
of the top 20 match ups. I concluded that the agent team was able to win 75% of the battles
based on the Robocode scoring. To evaluate winning in terms of rounds, I determined how
many battles the agent team won 55% or more of the rounds. I was then able to conclude that
the agent team was able to win 55% or greater rounds in 60% of the battles.
Therefore, through extensive testing via manually running battles between the unified
team and non-unified teams of highly competitive robots, it can be concluded that the unified
team had a higher rate of successfully winning battles than even some of the top non-unified
robots. The advantage demonstrated by the success of the unified team shows that Multi Agents
even in their simplest form gain an advantage on their non-unified counter parts.


>
AB,::%)# :")C.)03 ?7: 0"4% D4%-%%:,48-%D+ =EFFG
H
A/6BIJKLM 6/NOJNP1 QR6 P/!L 4%-%%:,48-%+ =EESG
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? =@
Future Works
The task of building highly competitive robots for Robocode is a never-ending challenge
as the limits of a robot's design and effectiveness are only limited by the developers time and
abilities. The team developed for this project, given the name BlackHoleTeam, is still young
compared to its fellow competitors in the Robocode competitions. The BlackHoleTeam has a lot
of room to grow and become an even more successful team of agents. At this time, the
BlackHoleTeam has the following plans for future work.
First, the team strategy will be replaced with a more advanced strategy. Currently, the
agents work together as a simple distributed sensor network, the next step would be to implement
more advanced maneuvers such as decoys to draw fire, and pincer/flanking moves. If more
military strategies were to be added to the repertoire of the agent teams abilities, it is my
hypotheses that it would result in an even more competitive team.
Secondly, The team is currently a homogeneous carbon copy of the single
BlackHoleTeam agent. I think it would be interesting to see what kind of performance could be
attained from creating a heterogeneous team where some agents are specialized to perform
certain maneuvers and tasks.
Thirdly, the targeting systems currently implemented, though effective is not optimal.
There is a lot of room for improving the targeting systems through implementing new pattern
matching targeting systems. In addition, having the targeting system use a dynamic targeting
selector so that in every battle the agents select from a repository of targeting systems to find the
one that works best for their current opponent.
Lastly, the minimum risk evaluation function could be optimized and extended to support
newer movement strategies such as wave surfing. In Robocode, there is no API for determining
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5 6787*79% !"3#%:3 ;:7<%*#
;"0% => 7? =@
if an opponent has fired a bullet. However, if you track your opponents energy level you can
accurately make a guess if an opponent has fired a bullet by watching for their energy drop.
With this guess of a bullet being fired, you can reasonably guess where the bullet is and where it
is traveling. However, you cannot know for sure, so most robots track the enemy bullets as
waves. The wave concept is like the idea of dropping a stone in a pond in which waves ripple
away from the center of the dropped stone's position. The firing opponent is considered the
stone and the bullet travels away from the opponent like the waves on the pond. The intention of
wave surfing is to reduce the damage incurred from being hit by enemy fire.
The robot team developed for this project is competitive, capable and delivers on the
objective. The suggested future work is merely a path to an even more competitive team of
agents and follows the spirit of Robocode, Build the best destroy the rest!
5














>
A6787*79% 17,:*%?7:0%+ =BCBD
MaLLhew !annace, MulLl AgenL SysLems & 8obocode MasLers ro[ecL
age 26 of 26
!"#$% '()*+

!"#$%&'( "!*+%*,- ./" ,!0' 12322451632. (2003, CcLober 26). 8eLrleved Aprll 12, 2011, from
old.robowlkl.neL:
hLLp://old.robowlkl.neL/robowlkl?8obo8umble/8anklngs_meleerumble_20031026
"7678792 -75482:74;2. (2010, november 4). 8eLrleved !anuary 1, 2011, from Sourceforge:
hLLp://robocode.sourceforge.neL/
"7678792<,=12 >?@AB8A. (2010, november 16). 8eLrleved !anuary 1, 2011, from 8obowlkl:
hLLp://robowlkl.neL/wlkl/8obocode/Came_hyslcs
#5442CD 4=CEBC;A :74 ;=12 F12322451632F. (2011, Aprll 12). 8eLrleved Aprll 12, 2011, from
darkcanuck.neL: hLLp://darkcanuck.neL/rumble/8anklngs?game=meleerumble
Aaron8. (2007, november 28). .B32G!C=D71@HIJ;. 8eLrleved !anuary 1, 2011, from 8oboWlkl:
hLLp://robowlkl.neL/wlkl/llle:AnaLomy.[pg
8ozu. (2009, AugusL 16). $=KE/C.B42. 8eLrleved !anuary 1, 2011, from 8oboWlkl:
hLLp://robowlkl.neL/wlkl/PawkCnllre

!"#$%&'()* ,-. /0*&1 2*"3 4"115* 6*-751-
6"&$ 8-1 9&:
6;<;1 ="3* 45">$!;5*/0*&12*"3 !"#$%&'()*2*"3
2;1"5 ?>;)* @8@A8 B@@CD A89E9 BAFCD
?7),(,"5 AAGGG 89GGG
?7), 4;&7- H8GG @AG
4755*1 I30 9G9E9 8@JK8
4755*1 4;&7- A8J@ 8K9K
6"3 I30 L 9 F8 HA
6"3 4;&7- 99 G
8-1- K@ 8F
9&:- 8F K@
A):- G G
6;<;1 ="3* 45">$!;5*/0*&1L B8D 45">$!;5*/0*&1L B9D 45">$!;5*/0*&1L BAD
6"&$ 8 9 A
?>;)* 9FJEE 8KA98 8JJK8
4755*1 I"3"0* J9AH @HFF @AFF
4755*1 I"3"0* 4;&7- 8AE9 EJ@ JKH
?7),(,"5 8A@HG EFHG EFHG
M"-1 ?7),(,;) 4;&7- 9H9G 89EG 89GG
6"3 I"3"0* 8 AK 8
6"3 I"3"0* 4;&7- G 99 G
/0*&1 ?N*>(O(> 2*"3 4"115* 6*-751-
6;<;>;:* 4"115* 6*-751-
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5676*68% !"3#%93 :96;%*#
!"#$%&'()* ,-. /0*&1 2*"3 4"115* 6*-751-
8739*) :; 6:7&<- =>>
2*"3- ?(@* A
/,0. 8739*) :; 2*"3B"1*- C*;1 "1 D&< :; 6:7&< E.F
8739*) :; 6:7&<- G:& HI
J*)K*&1 :; 6:7&<- G:& HI.>L
/,0. D&*)0M C*,*5 /1 D&< :; 6:7&< EN.O=
/,0. 8739*) :; B"P 27)&- (& 6:7&< )*"KQ*< IOO.>F
/,0. %,*)/55 2:1"5 R"3"0* S&K7))*< ON.T>
/,0. 8739*) :; 4755*1- ?Q:1 =EF.AT
/,0. 8739*) 4755*1- !(1 E=.A=
/,0. J*)K*&1 :; 4755*1- !(1 =F.A=L
/,0. 2:1"5 D&*3M R"3"0* ;):3 4755*1- E>E.TE
/,0. 8739*) :; D&*3M 4755*1- !(1 /0*&1 =E.N
/,0. 2:1"5 /0*&1 R"3"0* ;):3 D&*3M 4755*1- F=.NF
/,0. D&*3M U:55(-(:& U:7&1 >.FH
/,0. D&*3M U:55(-(:& R"3"0* >.OF
/,0. 2*"3B"1* 4755*1 !(1 U:7&1 =.>N
/,0. 2*"3B"1* 4755*1 R"3"0* =>.=O
/,0. 2*"3B"1* U:55(-(:& U:7&1 =.EH
/,0. 2*"3B"1* U:55(-(:& R"3"0* >.FF
/,0. 2:1"5 2*"33"1* R"3"0* =>.T=
/,0. G"55 U:55(-(:& U:7&1 N.I=
/,0. G"55 U:55(-(:& R"3"0* >.>>
2*"3 /0*&1 D&*3M
1eam Agent 1eam Agent
D&*3M 2*"3 /0*&1
6:9:K:<* 4"115* ?1"1(-1(K-
!"##$%& ("))"*%+ !,-#. /0%)# 123#%43 5676*68% !"3#%93 :96;%*#
Top 20 of 2005 vs. Agent Team Battle Results
15 75%
6 60%
9 90%
12 60%
3 30%
9 90%
15 75%
6 60%
9 90%
2005
Rank
Battle
Rank Robot Name
Total
Score % Score Survival
Surv
Bonus
Bullet
Dmg
Bullet
Bonus
Ram
Dmg * 2
Ram
Bonus 1sts 2nds
% Rounds Won By
BlackHoleAgent Team
2nd BlackHoleAgentTeam 29584 27% 8950 450 18826 1356 1 0 8 92
1st ShadowTeam 78049 73% 36050 6240 30054 5703 2 0 92 8
2nd BlackHoleAgentTeam 24617 24% 8200 30 15284 1103 0 0 1 100
1st AlephTeam 77129 76% 36800 6420 28372 5537 0 0 99 1
1st BlackHoleAgentTeam 54797 58% 29400 3390 19841 2115 28 23 49 51
2nd Tron3Team 39977 42% 15600 1770 19555 2994 58 0 51 49
1st BlackHoleAgentTeam 57912 62% 31250 3570 20552 2529 10 0 64 36
2nd Tron2Team 36190 38% 13700 1260 18575 2630 25 0 36 64
1st BlackHoleAgentTeam 50385 58% 29250 2520 16751 1862 1 0 42 58
2nd GlowBlowMeleeTeam 36770 42% 15750 1860 16507 2653 0 0 58 42
2nd BlackHoleAgentTeam 41586 37% 15400 570 23314 2223 79 0 9 91
1st SandboxDTTeam 69681 63% 29600 4650 29783 5541 107 0 91 9
1st BlackHoleAgentTeam 49555 55% 27350 2280 17844 2082 0 0 37 63
2nd CoriantumrTeam 41331 45% 17600 2010 18590 3122 8 0 63 37
1st BlackHoleAgentTeam 61682 63% 33550 4590 20870 2561 62 49 59 41
2nd SandboxLumpTeam 35972 37% 11450 1380 20340 2707 95 0 41 60
1st BlackHoleAgentTeam 61933 68% 33750 4200 20577 3194 121 91 64 36
2nd FloodHTTeam 29563 32% 11250 1200 15203 1761 149 0 36 64
2nd BlackHoleAgentTeam 41728 41% 18650 1470 19159 2424 18 6 31 69
1st NimrodTeam 60661 59% 26300 3570 26314 4449 28 0 70 30
Number of Robocode Score Battle First Place in Top 11-20=
Number of Battes Score Above 55% =
Number of Battes Score Above 55% in Top 1-10 =
Number of Battes Score Above 55% in Top 11-20 =
Number of Battes Won above 55% =
9.00%
37.00%
59.00%
64.00%
31.00%
42.00%
Number of Battes Won Above 55% in Top 1-10 =
Number of Battes Won Above 55% in Top 11-20 =
Number of Robocode Score Battle First Place =
Number of Robocode Score Battle First Place in Top 1-10=
8
7
6
4
8.00%
1.00%
49.00%
64.00%
5
2
3
1
10
9
Matthew Jannace, Multi Agent Systems Robocode Masters Project
Top 20 of 2005 vs. Agent Team Battle Results
2nd BlackHoleAgentTeam 36730 37% 17100 990 16785 1855 0 0 18 82
1st ShizTeam 62826 63% 27850 4530 25891 4530 24 0 82 18
1st BlackHoleAgentTeam 51107 58% 30150 2910 16039 2007 0 0 55 45
2nd StoneGhostTeam 36507 42% 14800 1530 17728 2448 0 0 45 55
1st BlackHoleAgentTeam 58376 65% 32650 4710 18421 2589 6 0 67 33
2nd YuugaoTeam 31331 35% 12350 1110 15877 1966 29 0 33 67
1st BlackHoleAgentTeam 60435 70% 33800 4350 19655 2602 10 19 65 35
2nd DuskTeam 25749 30% 11200 1080 12052 1402 14 0 35 66
1st BlackHoleAgentTeam 59444 65% 32950 4410 19193 2876 14 0 72 28
2nd HebusLeTrollTeam 32326 35% 12050 900 17292 2042 42 0 28 72
1st BlackHoleAgentTeam 59089 61% 30200 3600 22355 2914 7 12 55 45
2nd EntangledTeam 37137 39% 14800 1650 18077 2545 37 27 45 55
1st BlackHoleAgentTeam 61631 66% 33000 5100 20292 3176 41 22 86 14
2nd HawkOnFireTeam 31292 34% 12000 630 16781 1828 53 0 14 86
1st BlackHoleAgentTeam 70358 79% 39600 6540 21252 2950 16 0 85 15
2nd PulsarMaxTeam 18439 21% 5400 450 11548 989 34 17 15 85
1st BlackHoleAgentTeam 68432 73% 38000 5760 21438 3228 6 0 82 18
2nd FermatTeam 24744 27% 7000 540 15716 1473 14 0 18 83
1st BlackHoleAgentTeam 66379 72% 36250 5700 21153 3242 25 9 80 20
2nd TheArtOfWarTeam 25200 28% 8750 750 14141 1519 40 0 20 80
85.00%
18.00%
82.00%
80.00%
55.00%
67.00%
65.00%
72.00%
55.00%
86.00%
20
19
18
17
16
15
14
13
12
11
Matthew Jannace, Multi Agent Systems Robocode Masters Project