"Building" Quality Code: An Ant Experience

Working with Robocode for almost a month now, you begin to see the tediousness of some of the tasks. Some of which include, waiting for a battle to end, making sure your code is up to standards, and importing another persons Robocode robot. The current topic for this week in my Software Engineering class is Quality Assurance and Build Technology. This past week I have become familiar with the build technology - Apache's Ant in combination with Apache's Ivy - Library-Level Dependency Management Tool, to eliminate the tedious tasks.

Together with Ivy's ability to download and store the necessary libraries, and the automated build technology that is Ant, I can battle, standardize my code, and package my robot for distribution, all without ever opening Eclipse or Robocode.

Although Ant is Java-based, the build files are written completely in the XML format which means 1) No Compilers and 2) Each file can be read as source code. By using Prof. Johnson's Da-Cruzer build, I adapted it to work with my robot, StrafeNShoot.

By using the following tools:

• PMD
• Checkstyle
• FindBugs
• jUnit

I can eliminate long hours of staring at code looking for any rules that might have been broken by using PMD, Checkstyle, and FindBugs tools. I also can eliminate waiting for a battle to end by creating a test to see if my robot can beat another by creating a jUnit test and asserting that it has done so. In my case, I adapted Prof. Johnson's jUnit test to assert that my robot will always beat SittingDuck.

The other tools such as "jar" and "dist" make it easy to distribute my robot so other's can easily extract and battle/examine my robot. Compared to the long and painful way of importing a new project into Eclipse, and making sure all the paths are set before you can Roborumble.

Once you get Ant and Ivy set-up, this is indeed an incredible tool to automate tasks. However, the initial set-up was not so pretty. The errors that I encountered were mostly from adapting Prof. Johnson's DaCruzer build. I had not replaced all instances of his initials with my own, and same for his robot name, therefore Ant was so kind to tell me what types of problems I had and I quickly made the corrections.

I did run into some Environment Variable problems. I kept getting a "Unable to find tools.jar" error message when trying to build. Ant also gave some feedback saying it was looking for tools.jar in "C:\Program Files\Java\jre6". After searching the web for solutions, I can across the solution at this thread: http://forums.sun.com/thread.jspa?threadID=757039 Essentially I needed to declare my JAVA_HOME variable to point to the jdk folder, and the folder itself, NOT the bin, and I also remembered Ant does not work well with spaces, so I relocated my Java file directly into the C:\. So my JAVA_HOME ultimately was defined as "C:\Java\jdk1.6.0_16".

When I finally got it to run, I did the all the tests as described by the assignment and ended up with just 1 error:

• Checkstyle - 1 error
• PMD - 0 errors
• FindBugs - 0 errors

I was amazed to read that my error was:

[checkstyle] C:\robocode-etm-strafenshoot\src\etm\StrafeNShoot.java:78: First sentence should end with a period.

My first sentence of the javadoc was missing a period. Something so simple, yet hard to spot, the Checkstyle tool found it in 3 seconds. The fact that I don't have to use a resource heavy IDE like Eclipse to run these tools, and can do so easily with just the command prompt, I find these tools extremely helpful and efficient. Not only can you check the quality of your work, but you can also fix your code so that it is quality based on informative feedback. Although it takes effort to set-up, once everything is set all you have to do is invoke a simple command and Ant will do the rest. =)

My automated packaged, version 1.1 StrafeNShoot can be downloaded here.

Enter StrafeNShoot - My First Competitive Robocode Robot

After two weeks of introduction to Robocode, it was time to create a competitive robot. Even looking at sample robots and collaborating with fellow classmates, it was hard to find a place to start. What type of movement, targeting, or firing strategies will be effective against other robots? For starters, it began with developing a single robot that can counter as many of the following eight sample robots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck.

---

After much toil, I implemented this strategy:

StrafeNShoot
(Source code)

Movement: Essentially uses the 4 corners movement as a method of getting around the map. Starts to go to the upper left, and then lower right, upper right, lower left, and back to upper left; going in a perpetual cycle throughout the match.
Targeting: As it moves to each corner, the robot tries to keep the gun pointed either at the center of the battlefield, or at the enemy.
Firing: As soon as it sees another robot, it will reposition the gun and fire with a power of 2. I used power of 2 because throughout trial runs, the points gained outweighed the energy used. However, when it gets shot at or collides with another robot, it will immediately realign the gun and shoot with a power of 3. Since the robot is moving most of the time, it was difficult for other robots to hit, so it was feasible to use maximum power.

---

Trial Runs:

Consistently Defeated: RamFire, Crazy, Fire, Corners, Tracker, SittingDuck

I noticed that with my strategy I had an advantage over stationary/tracking type robots. Because my robot moves at drastic lengths from one side of the battlefield to the other, stationary type robots will continually keep firing and missing; expending their energy and ultimately disabling themselves.

Tracking type robots have a hard time repositioning themselves. By the time they reposition and start moving to my location, I’ve already moved onto a different heading and the tracker is just trying to keep up. Meanwhile I’m firing as I’m moving to each corner.

Although Crazy is neither a tracker nor a stationary robot, its random movements work to its disadvantage, often times it runs into my bullets, and since it only shoots when it sees a target without any type of tracking, my robot will have moved on by the time it fires.

The Troublesome Two: Walls and SpinBot

Examining all the sample robots, it was hard to come up with a solid movement strategy. Robots such as Crazy, SpinBot, and Walls, make it hard to create a standard pattern of attack, even tracking their movements makes it difficult. When it comes to these two robots, my win/lose ratio is about split 50/50.

For Walls, the initial placement of the robots seems to play a significant role. When the robots are initially placed, sometimes my movements are exactly in-line with Walls so every time Walls fires, my robot will get hit and the converse is the same. Sometimes Walls’ movement is in-line with mine, so every time I fire, Walls will get hit.

For SpinBot, because it keeps moving in a circle, it can seemingly dodge all of my shots. Sometimes I’ll run out of energy just trying to shoot at it, or at rare occasions I’ll collide with it and I’ll fire at maximum power to take the win. Also, at times SpinBot will use up all of its energy just trying to shoot and I’ll take the win when it becomes disabled.

---

Here are my final results, 100 matches for each of the 8 robots:

Walls: score percent: 53; 47 wins; 53 losses
RamFire: score percent: 57; 77 wins; 23 losses
SpinBot: score percent: 53; 53 wins; 47 losses
Crazy: score percent: 68; 65 wins; 35 losses
Fire: score percent: 84; 97 wins; 3 losses
Corners: score percent: 83; 100 wins; 0 losses
Tracker: score percent: 82; 98 wins; 2 losses
SittingDuck: score percent: 100; 100 wins; 0 losses

---

Lessons Learned

During the creation process, I came across many contradictions. What worked to defeat one did not work against another. For predictable movements, it seemed that a blunt strategy like RamFire would be a sure win. But for robots with completely random movements, the only way to combat it was to move randomly as well.

Creating a single robot that could defeat all eight of the sample robots would be no easy feat, and by doing so would increase success in real competitive battle. However, the only way to test it out is to put it in actual battle. Talking with a few classmates, I found that I could easily defeat a specific sample robot while theirs could not, and vice versa.

When I was designing my robot, I was only thinking of survivability. Meaning, I thought that if I outlasted my opponent I would win. However, survivability is only one part of your total score. Even if a robot is defeated, it can still out rank your opponent, so even a blunt robot like RamFire can still out rank you because it will gain a lot of ram points. I will keep these things in mind when I make upgrades to StrafeNShoot.

Trial Version Robots: Learning Simple Behaviors

In order to create a competitive robot jutsu I need to come up with a baseline for my robot design. The robots that I have previously coded was an introduction to Robocode, in order to become familiar with the basic Robocode mechanics. For a robot to be competitive, it should have strategy and countermeasures. Although I need to look at this more in depth as I progress with Robocode, looking at the pre-packaged Robocode Sample robots will hopefully shed some light on creating a competitive robot.

In this blog entry I will examine and offer my thoughts on 8 of the sample robots, these include; Walls, RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, and Tracker. For each robot I will evaluate criteria based on:

1. Movement: How does the robot move? Does it have an avoidance or following strategy?
2. Targeting: How does it find a target to fire?
3. Firing: What is its criteria for firing?

Robot #1: Walls
Movement
Operates a very simple movement strategy that goes to the nearest wall, and just traces the wall. There is no follow strategy as this just traces the outline of the stage.The only avoidance strategy this robot exhibits is if it runs into another robot, if just reverses direction 100 pixels, and changes back to its original heading.

Targeting
Keeps gun perpendicular to the wall at all times. Only sees a target if one passes in the direction of its radar.

Firing
Fires with a power of 2 at any robot it sees.

Robot #2: RamFire
Movement
Probably the most blunt robot in movement. Rushes towards any robot it sees to point blank range in an attempt to ram it.

Targeting
This robot just rotates its whole body until it finds a target, does not go for any specific target or hold any targets in memory. Once it looses track of a target, has to swing its whole body to find another target. This is very inefficient since the robot is moving its body to scan, it will take a longer time rotating rather than just using the radar.

Firing
After it rushes to point blank range, fires the gun once it rams into another robot. The power of the shot is proportional to the enemy’s energy level. Essentially tries to out damage the target by ramming and shoot at the same time.

Robot #3: SpinBot
Movement
Spins in a clock-wise circle…that’s it. No avoidance or follow strategy whatsoever, but probably the most mesmerizing to watch. However, it does make it hard for other robots to shoot at it since it's in constant motion. Robots that are stationary have the hardest time against this robot.

Targeting
Keeps gun stationary at all times, only sees a target if one passes in the front of the radar.

Firing
Shoots at any target it sees, still going in a circle. Fires the gun as maximum power, so waiting for the gun to cool down to shoot again can be a problem if faced with multiple targets.

Robot #4: Crazy
Movement
Erratic and somewhat unpredictable movement. The robot makes a series of right and left turns as it moves ahead. If it hits a wall, reverses direction. This robot makes it hard to target as it keeps moving. I want to note that this robot is an AdvancedRobot, as coding an erratic behavior in a normal Robot would be difficult.

Targeting
Keeps gun stationary at all times, only sees a target if one passes in the front of the radar. This can be a problem if crazy is being followed as it can't see behind and even when it reverses direction, it doesn't turn around, just backs up.

Firing
Shoots at any target it sees, while in its obscure movements. Relies on the fact that a target will be seen, even while moving in obscure motions.

Robot #5: Fire
Movement
For the most part stays stationary, but if a robot gets too close, it moves away. Extremely vulnerable to robots that constantly move, as this robot stays still.

Targeting
Does not target any specific robot, just has its gun spinning all the time. This can be very inefficient as losing sight of a target will result in the robot doing a complete 360 to look for targets.

Firing
Shoots at any target it sees while spinning its gun. Depending on the range of the enemy and current energy, Fire will shoot either at maximum power (3) or just normal power of 1.

Robot #6: Sitting Duck
Movement
Does not move…at all. It may seem like it's waiting for the perfect moment to strike, but it does nothing.

Targeting
A very pacifist robot as it does not target anything.

Firing
Again with the pacifism, does not use its gun or shoot in anyway.

**The Gandhi of all sample robots, just counts the rounds and battles it’s been alive.

Robot #7: Corners
Movement
At the start of first battle, moves to the upper left corner. Stays stationary once it reaches a corner. If it died in the previous battle, will switch to another corner.

Targeting
Once in a corner, the robot continually robots the gun to scan for any targets. However, it does make use of the fact that it's in the corner. The robot does not spin it's gun a whole 360 degrees to scan for an enemy, a maximum of 90 degrees is only necessary.

Firing
Simply shoots at any robot it sees. Uses power proportional to distance, the closer the enemy, the stronger the shot. On the other hand, if current energy is low (> 15) then will use just a power of 1.

Robot #8: Tracker
Movement
Follows the first target it sees and sticks to it until itself or the target gets destroyed. If the target gets destroyed, the robot will find another. If the target is 150 pixels or more away, the robot encloses to 10 pixels. If the target is too close it will back-up. I've noticed that an "efficient" tracking method is to get within only 150 pixels of the enemy, this will keep the target in a larger radar scope without having the gun go a 360 every time it loses track because it's too close.

Targeting
At the beginning of the battle, the robot will rotate its gun until it finds a target. Tracks a single target until itself or the target gets destroyed. If the robot comes into contact with another, it will immediately make that robot its main target, and back up a little.

Firing
This robot only fires at others that have hit it.

My Thoughts
After reviewing these 8 sample robots, I sort of have an idea of different countermeasures that I could implement for simple robots. Some robots are very situational, taking RamFire as an example. In a huge brawl of multiple robots where endurance is key, RamFire is probably not the best choice to throw in, but for 1v1 it would probably perform the best.

I'm still on the fence about tracking robots. Although it seems like a cool idea to track and hunt down a robot, having a 1 track mind isn't always efficient. The really weird ones like SpinBot, Crazy, and Walls I think perform the best overall out of all the robots I've evaluated. The fact that the Corners robot stays stationary is just begging to be mass targeted.

As these robots are "sample" robots and aren't meant for competitive play, they still give you an idea of certain elements that you would want and not want in a robot.

It's What's Inside That Matters - Even For Robots

When it comes to the battlefield, even the messiest coded robots can still win against a well organized and standardized coded robot. So why would someone even bother to create a standard let alone re-code all their robots to fit that standard?

Even if a programmer worked alone, where only he/she would be looking at source code, he/she would not remember every little detail that was changed. Quick fixes and minor updates that don't get documented properly could leave you scratching your head while you try to remember why you made the change. In a worse case scenario, you're working on a software team and you're colleagues can't figure out how or why your code works.

Taking a quote from The Elements of Java Style, "code that is written to style is predictable, robust, maintainable, supportable, and extensible." Even when programming for something like Robocode, this holds very true. Building a competitive robot requires numerous cases, for countless situations. So far, my 13 simple robots only take roughly 1 to 2 kb each and I have no doubt that a competitive one can reach anywhere between 10 to 20 kb. Although using an IDE like Eclipse to manage all code, and no matter how pretty Eclipse makes your code look (by color coding words), all it tells you is what it does, it's up to the programmer to document why it does it.

One comment I remember from my Prof. in the intro classes to ICS, and that's "comment as if the reader knows where you live." A very funny yet creepy way of remembering on how you should comment your programs, showing how if you don't properly comment your programs, they'll hunt you down. Though, creating a standard and using proper documentation allows others to easily understand the flow of not just your program, but any other. Modification becomes a breeze because you'll know what each section of your code does. It also serves as a reminder, if it's old code you probably won't remember certain details.

For this Software Engineering class, we also have our own ICS standards. Using our own ICS standards, Robocode standards, and Elements of Java Style, I have modified my simple robots to conform to these standards. Even though I had already commented my robots, after reading the aforementioned, I realized some of the documentation is wrong. It was a bit embarrassing to look through my robots only to find that what I thought was right was incorrect documentation. Some comments just said what the code was doing rather than why it was doing it, or something simple like using end-line comments were all over the place. Luckily Prof. Johnson released an XML document that has the basic formats in it that works with Eclipse. It won't properly document your code (haha), but it will give the code basic formats like proper spacing, JavaDoc format, and line lengths.

During modification, I would like to give credit to Kendyll Doi. He had created a very nice formula to augment the Robots firepower in Firing03 robot. This robot is supposed to use firepower proportional to the robots distance, so the farther away the robot, the less power it would use, and the closest, the stronger the fire.

My original formula looked liked this:

 fire(1 / e.getDistance()); 

But the battlefield is already big so no matter how close the robot is, the value of fire would almost always be the lowest.

Kendyll's take looked liked this:

 fire(3.1 - e.getDistance() / 1200 * 3); 

He worked out that with the radar's max distance at 1,200 pixels, he used a ratio between the distance of the target to 1,200. At a max distance of 1,200 the robot will shoot a minimum power of 0.1, and at close range, a power of 3.

My standardized robots can be found here.

Java Style: Robocode No Jutsu!

Programming robots...that is pretty much the highlight of my week. Of course, it may not be what you'll initially think. Just those two words alone makes me think of movies such as iRobot and Terminator. But alas, the types of robots I programmed were on a much smaller, more virtual scale.

This past week, and future weeks to come, I am programming in Robocode, a java based, open source game. Robocode's motto alone "Build the best, destroy the rest" (which appears on the splash page every time Robocode is opened) will put a smile on your face as you code and watch your robot take action on the battlefield.

However, I am just a beginner, so much of the enjoyment will come when I have fully grasped the ways of Robocode. For starters I have developed and completed 12 simple robots that full requirements assigned by Prof. Johnson's - Software Engineering class. These simple robots covered tracking, movement, and firing. Since Robocode is Java based, I had no problem with syntax and using Robocode's API, as it is well laid out and mirrors Java's very own API. The only difficulty is getting to know the different functions each robot has, and any Utility functions that are used to calculate headings/bearings/distances.

My completed robots can be downloaded here

Upon installing Robocode, it comes with a variety of sample robots, each complete with source code so you'll know exactly how they work. I think including sample robots AND source code is an excellent way to dissect and reverse engineer these robots. It also makes learning how to code much more easier and smoother.

Some of the difficulties I encountered was the coordinate system of the battlefield. I'm used to coding Java Applets, so the coordinate system for those start in the upper left, but the coordinate system for Robocode starts as if it's in the First Quadrant, with the origin in the lower left. This was a disorienting fact as my robots would turn in the opposite direction I wanted.

Also was how Robocode handles degrees. When I started to code for turning, I assumed Robocode used the Unit Circle, with 0 degrees pointing to the right. This proved wrong, and later realized that it works just like a clock, where 0 degrees is at the top and moves clock-wise around 360. Calculating bearing and headings and knowing the difference between these two concepts was a bit difficult. Since you can't explicitly tell your robot to move to a specific degree, you have to subtract or add degrees to get it there. Luckily, the sample robots show code on how to reposition your robot given a target.

There is one of my robots that I am concerned about, and that is my Movement05 robot, where it moves to the 4 corners of the battlefield. I managed to use some basic trigonometry to calculate the angle to turn towards each corner. However, going from the upper left to lower right corner doesn't work too well if the battlefield is not a square. The angles become too steep and the robot hits a wall about 20 pixels short of the corner.

Coding in Robocode this week alone, I learned that programming for these robots is just like programming anything else in general. You need to be very specific in your coding. Using robots you can physically see where your code is acting "funny" without using a debugger that would just tell you a very technical wording error, accompanied by the line that cause it. There are also some technical things such as getting a robot to move to a specific place on the grid, whether that be a point such as the center or a corner, or a roaming target which you have to track.