Slide 1

Winning Strategy in the Programming Game Robocode A Project by Daniel L. Rappdrapp1@pride.hofstra.eduAugust, 2010

Hello everyone, My name is Daniel Rapp and this the presentation for my Graduate Thesis.For my research I have Worked within the programming environment called Robocode. Here I analyzed the performance of a particular robotand developed a Winning strategy based upon a predefined set of metrics.1What is Robocode?An environment consisting of several independently functioning robots.Each robot has certain attributes.Robots are comprised of three important parts:VehicleRadarGun

Every robot has a distinct movement pattern.Battles are over when there is one robot remaining.

To begin, let me first describe exactly what makes up the environment called Robocode.In a nutshell, Robocode is a giant battle arena in which pre-compiled, independently functioning robots face-off against one another in a battle for supremacy.Robots are coded in Java and each is comprised of three important parts, a vehicle, a radar and a gun.The vehicle is responsible for maneuvering the battlefield and evading enemy attacks.The radar detects enemy combatants and passes the information to the gun.The gun will perform any necessary calculations and subsequently fire based on the algorithm in place.It should be noted that ammunition is not unlimited and comes at a cost.Every shot that is fired depletes the robots health, but every successful shot will replenish health too.Each robot has a distinct way of detecting enemies, moving around the board and firing at their enemy combatants.Battles are over when there is one robot remaining. 2Research GoalAchieve each of three metrics.Winning Percentage = 100%!!Health Percentage > 80 Points.Accuracy Rating >= 90%.

The overall goal of my research was to develop a robot named WallsKiller that would achieve each of three separate metrics used for determining success.The first metric is a winning percentage of 100%. Basically, the robot can never lose!The next objective is to end each and every battle with a health percentage of over 80 points.Since each robot starts with 100 points of health, an effective shooting algorithm will help replenish health and keep this value high.Lastly, the developed robot must have a very effective shooting algorithm. The successful strike to total shot percentage needs to be at least 90% to be considered successful.3The Competitors - WallsWalls is one of the precompiled robots that are packaged within the Robocode environment.When matched up against all default robots, Walls is the top performer. Movement pattern follows perimeter of battle area in a clockwise fashion.Radar always faces forward.Bullet always fired directly at enemy.

The Walls robot is the most successful pre-compiled robot in the game. In a battle amongst all standard robots, its approximate win percentage was around 75%.When observing this robot it can be seen that the movement pattern follows the perimeter of the battle arena in a clockwise fashion.Also, both the radar and gun for Walls always face toward the center of the battle arena. Upon the detection of an enemy, a bullet is fired immediately, and it is directed at the location in which the enemy was located.4

Walls Robot Radar and Movement PatternThe Competitors - Walls

Here is a depiction of the movement pattern of the Walls robot.This robot will move along the perimeter as pictured, firing when an enemy robot crosses the path of the radar.Another shot will be fired when this robot is in the corner of the battle field. This happens because the radar will sweep across the entire battle arena and fire at any enemy that is detected.5The Competitors - WallsKillerRadar spins freely, regardless of tank heading.Movement of vehicle is in the shape of a diamond.Travels in a counter-clockwise direction.Smart firing mechanism accomplishes:Calculates anticipated position of enemy.Not firing shot if target is stationary.Suppress fire if anticipated position not in battle arena.

The robot being created to defeat the Walls robot is aptly named WallsKiller. WallsKillers radar spins independent of the heading of the body or direction of the gun. The movement pattern of the radar is very similar to that of a submarine radar, or a police light.This robot moves in a counter-clockwise, diamond shaped pattern which will be discussed further on the next slide. As for the firing mechanism, several computations will be made with respect to the data provided upon an enemy detection from the radar.These calculations include an anticipated position in which the bullet and enemy will collide, whether or not that position is within the battle arena, and several other computations that are necessary to help achieve success.6The Competitors - WallsKillerWallsKiller Movement Pattern

This is an example of the movement pattern of the WallsKiller robot.The counter-clockwise, diamond-shaped movement pattern was chosen for two reasons.Considering that the Walls robot moves in a clockwise fashion, the counter-clockwise direction of WallsKillers movement will allow for more frequent intersections of their paths.Additional logic was also implemented in the movement pattern to keep this robot toward the center of the battle arena. This will help avoid collisions between the two robots, as well as collisions with the wall. Both of these types of collisions will cause health to be lost.

The second reason this movement pattern was chosen is due to the firing mechanism of the Walls robot. Since the Walls robot only fires straight upon enemy detection, it has a hard time striking a moving enemy. Keeping a distance from Walls will lead to a less successful accuracy rating for the Walls robot.7Event Flow / Terminology UsedAdvancedRobot- Super class inherited by WallsKillerScannedRobotEvent- Occurs when enemy robot crosses the path of the radarBattleData- Contains information at a particular point in time.FireControlSystem- Calculates direction to fire.FireCommand- Directive passed to gun.Bullet- Fired at enemy.

This is some of the terminology necessary to understand when dealing with the RoboCode environment.To start, all robots developed inherit the super class Advanced Robot. This class is responsible for managing the interactions amongst all robots and the environment.A ScannedRobotEvent occurs when a robots radar detects an enemy. This event will gather BattleData, information available concerning the enemys heading, velocity and other various pieces of data concerning the robot that detected the enemy.This data is then passed to a FireControlSystem. In the case of the WallsKiller robot, this calculates the direction the gun must turn to fire a successful strike.The FireControlSystem is also responsible for determining the power to exert and if a shot should or should not be fired.These three pieces, the angle, power and boolean stating whether to take the shot, are grouped into an object called a FireCommand. This fireCommand is passed back to the WallsKiller class. If the shot is to be taken, the super class is called to create a Bullet which is fired at the enemy.8Firing Angle Calculation

To determine the firing angle, several calculations need to be made. Above is a diagram representing a mock ScannedRobotEvent when WallsKillers radar detects Walls.Certain BattleData becomes available as shown above.

Here the heading of the WallsKillerRobot can be seen represented by the orange line.The value of this angle is with respect to the north/south zero degree line shown in grey.The enemy bearing is represented by the value 2 and is with respect to the current heading of WallsKiller.Green represents the current heading of Walls and the blue line is the expected bullet path toward a successful strike.Some other data that is available that is not represented above is the x,y coordinate position of WallsKiller and the speed of Walls.9Firing Angle Calculation cont.The general formula applied here to calculate the Beta value is:

For the example on previous slide, Beta can be represented as:

since WallsHeading = 180.

The first step in the approach of finding the firing angle is to calculate for Beta.Given the previous example, since the heading of Walls is 180, the value of Beta can be pretty simply represented as the sum of the heading of WallsKiller and the bearing of the enemy, Walls.10Firing Angle Calculation cont.Focus on triangle formed by robots and collision point. A = Beta from previous calculation a = Distance between robots b = Derived from enemyvelocity * time c = Derived from bulletvelocity * time

Since the value of the time is shared between b and c, this value must be solved for to represent the two paths.

After deriving the value of Beta, the focus shifts to the triangle formed by the two robots and expected collision position.Although the distance values of the enemy path and bullet path are unknown, both can be represented by their speed component multiplied by the time it takes them to collide.

Since the value of time is shared between b and c and both of their component velocities are known, it is possible to calculate for the value of t.11Firing Angle Calculation cont.Given the following from the previous slide a = Distance between WallsKiller and enemy=d b = Speed of enemy * time= v2 * t c = Speed of bullet * time=v1 * t A = Beta=BetaAnd applying the Law of Cosines

By using the Law of Cosines, we can substitute the distance components as the speed times the time it takes for the bullet and enemy to collide. After factoring the formula, we are left with a quadratic formula in the last line of this slide.12Firing Angle Calculation cont.The final formula,

is in the form,

so we apply the quadratic formula.

and the value used will be the difference in the numerator. This value provides the positive root.

With the formula in the form a x squared plus b x plus c = 0, it is possible to apply the quadratic formula to solve for the appropriate values of t.

One of the important things to note is that there will be two values of t returned by this function. Of the two values that can be returned by this function, the smaller, positive value is the one that is always to be used. This makes sense because the value of time will never be negative in an application to a real world problem.13Firing Angle Calculation cont.Now that all values are known, reapply Law of Cosines. A = Beta from earlier a = Distance between robots b =Distance between enemyand collision point c = Distance between WallsKiller and collision point

When the new value of this angle if determined, the final firing angle is the value of A above added to WallsKillers heading and the enemy bearing. This is the total angle from the zero degree reference.

Now that all distance values are known within the triangle formed between the two robots and the expected collision point, one more angle needs to be determined. This is the angle formed between the path connecting the two tanks, represented in red above, and the path connecting the WallsKiller robot and the collision point, represented in blue. This angle will help determine how far the gun needs to be rotated to shoot a successful shot.

By reapplying the law of cosines that was shown on the previous slide, it is possible to determine this value very easily.

After this angle is determined, there is one last calculation that must be made. When passing this angle to the Advanced Robot class, the angle is expected to be with respect to the North South zero degree line. Therefore the angle determined above must also be added to the value of the WallsKiller heading and the value of the enemy bearing. This will allow for the proper angle to be passed to the Advanced robot class to fire a successful shot.14Firing MechanismAdditional checks made to determine if a bullet should be fired.If enemy not moving DONT FIRE!!!Enemy is likely in the corner turning. Fired bullet at this position will not likely strike enemy.If bullet out of bounds DONT FIRE!!!Use special triangle formed between WallsKiller positionand battle arena corner gun was calculated to point.If the path from WallsKiller to collision position greaterthan special triangle hypotenuse, dont fire.If less than, collision position expected to be in battlearena, so fire.If all conditions are met, bullet expected to fire.

After the process has been performed to determine the firing angle, there are a few additional calculations that can be made to improve upon the accuracy of the firing mechanism.

One such scenario is when the robot is in the corner. For the short period of time that the enemy is in the corner, its velocity is zero. This means that the expected collision point will be at the same point, in the corner of the board. Although this is true, the robot is not there for long. Once the bullet is fired it is possible that the robot will have enough time to move from the expected collision point and the bullet will miss. Therefore, in the event of an enemy velocity being zero, a bullet will not be fired.

Another scenario in which a bullet should not be fired is when the expected collision point is found to be outside of the battle area. Given the assumption that the enemy robot is travelling the perimeter of the board, special right triangles will be formed using the x and y coordinates of the WallsKiller robot. If it is found that th hypotenuse of this triangle formed is longer than the path between the WallsKiller robot and the expected collision position, the shot will not be taken since it will be outside of the battle area. This calculation is quicker and easier to follow as opposed to calculating the expected point and determining if it lands within the battle field.15WallsKiller ResultsSampled across 15 battles:Winning Percentage = 100%Average Health Points after battle = 118.3666Average Accuracy = 86.5956Failed accuracy metric.

After several test rounds, each taken with 15 battles, the three metrics were calculated and compared to the initial conditions for success.As intended, the robot won all battles against Walls. In fact, this same test was sampled against 300 battles and the winning percentage was still 100%.

At the conclusion of each battle, the average health value was well over 100, the health value of all robots at the start of a battle.This means that the robot was not only well suited to evade attacks, but effective at placing attacks as well.

The last metric, accuracy, was not as successful. The final accuracy calculated to be just short of the 90% goal. 16Future EnhancementsImproving accuracy!Alter shotOutOfRange logic. Attempt solving for actual position of shot.Ensure that enemy robot is against the Wall.Account for enemy accelerationCheck for constant speed across two different ScannedRobotEvents.

Although the robot developed was highly effective in practice, there are a few modifications that could be made to help it achieve the full overall success metrics stated in the project description.

By the standards of the game, the accuracy of the WallsKiller robot was the only area in which some improvement could help make this robot a success.Some suggestions for future enhancements include altering the shotOutOfRange logic. In the scenario where the robot was not travelling the perimeter of the battle field, it was possible for the algorithm to unsuccessfully conclude that the shot was within the confines of the board. This is because the collision path was shorter than the path between WallsKiller and the corner of the board, but the Walls robot was not approaching the corner of the board. It is possible to take shots in this scenario that would hit the wall.

Another scenario to account for is the enemy acceleration out of the corner. As the enemy starts to leave the corner of the board, it accelerates for a small period of time. Since the firing algorithm expects a constant velocity of the detected enemy, it is possible that the calculated value of the collision point could, in reality, be behind the enemy as it gains speed. One way to account for this could be to check for a constant speed across all scannedRobotEvents.17ConclusionNew software design tactics learnedGreat insight to the overall development lifecycleFun!

After completing this research, some great things were learned.I had some great insight in to the software design processes from algorithm development and overall object design to the actual implementation and testing of compiled code. One of the most interesting things I noticed were all of the changes that were made across several iterations of the Back to the drawing board situation, just in the algorithm design phase!I was also impressed with the planning necessary and the documentation created before any actual development could begin. This was necessary because it would help to identify possible problems that would not have been seen until they were encountered.

The best part of the research is that it was fun! With the very visual environment it was possible to see exactly how to improve upon an algorithm through a situational representation of the information present at calculation time.

Overall, even though the project was close to a success, the lessons learned through the process were the biggest goal to be achieved. Thank you to all who helped play a role throughout the various steps of this research, especially Dr. Fu.18Thank you!