Using Software Tools. Less Grunt Work.

This week I had my first experience with Ant a software tool developed by Apache to help with the software build process. It has sub-processes that checks for syntax errors, errors in run time, and also makes sure your source code is up to Java coding standards. The initial learning curve is not that steep. I think with a little determination, most programmers can be comfortable with this tool in a short time. This tool was used for my robocode robot and it helped to check my source code. There are quite a few things that Ant does with just a simple command typed into the command line. I will detail the requirements for installation and also how to use Ant.

Ant is a open source software available at (http://ant.apache.org/). I found it somewhat difficult to set up on my computer particularly because there are not a lot guides that give you a step by step explanation of the process. Most of the sites I visited showed guides that were inadequate. Here is my take on how to set it up on a windows vista HP Laptop.

1. Download Ant and unzip. Move it to the C:/ directory. Or try to move the Ant file to a directory that has no spaces in the name. It can be problematic later on.

2. Now click start, right-click computer, and click properties. If you are running on a Vista OS, then you should see a window opened. Click on "advanced system settings" under Task on the left side.

3. Click on Environmental Settings. This is where you will enter two variables.

4. The first variable will be called JAVA_HOME. Under the variable value, enter the system path that leads to your latest sdk version of Java. For example, this my path. C:\Program Files\Java\jdk1.6.0_16.

5. The second variable will be called ANT_HOME. The variable value of this variable will contain the path to the same directory as the above variable. So just enter the same thing.

6. Now open dos. Go to the directory which contains your build.xml and type ant.

Those are the basic steps to setting up Ant and checking if it works. There are many utilities within Ant that are quite helpful.

• ant
• ant -f checkstyle.build.xml
• ant -f junit.build.xml
• ant -f findbugs.build.xml
• ant -f pmd.build.xml
• ant -f jar.build.xml
• ant -f verify.build.xml
• ant -f dist.build.xml

Each one has their use. Checkstyle and findbug for example check for irregularities in your code and byte code. While jar and dist on the other hand are used to package your source code. And verify is the special command that does it all. It pretty much does everything on the list.

On this occasion Ant was used to improve my source code for Bato, a robocode robot created about two weeks ago. I made some improvements on the movement of Bato and after compiling it, I used the commands checkstyle, pmd and findbugs. I was surprised that there were many errors. I mean it compiled didn't it? What could be wrong?

It turns out that there were some small coding standard violations, like leaving no white space between a while declaration and the "{" bracket. Another problem was declaring a variable and not using it. Findbugs made sure I changed it before letting me get a "Build successful."

Finally after going through that, I used the verify command to make sure I was able to get a successful build as well. Verify is the command in which you can use to check if everything has been done.

In terms of quality assurance, I found the program to be quite helpful. I didn't even know about some of the errors that checkstyle and findbugs found. It drastically shortened my work time. The one complaint I have about some these programs were how they alerted you to an error. The messages were kind of ambiguous and not very helpful. It took me awhile to figure out what was wrong with my code.

JUnit is plugin that tests your program in order to make sure that your program works in all cases. This was the most difficult of the programs to learn. I found that JUnit can be helpful and downright essential if you want to know what works and what doesn't.

This is a good tool to have for programmers. It makes things so much easier during the entire coding process and generally makes a better experience for users.

Check out my robot source code here along with the build files.

Update
I've revised my package

(robocode-wcm-Bato-1.1.1003)

Building your own robot.

Robocode is a open source software available on sourceforget.net. This is my attempt creating a robot implementation using their package. I'm at a point now where I have a basic understanding of the structure and techniques for controlling a robot. My past blogs have detailed my studies into other sample robots provided by the Robocode program. Now I'll give a brief overview of how my robot works in the same format. I have christened my robot Bato.

Movement:
The robot moves in a circle in order to dodge bullets fired at it. During every iteration, it moves 36 degrees to the left and ahead 20 pixels. I chose 36 pixels because I did not want the robot to move in a perpendicular way. If it moved at 36 degrees or some degree which did not add up to 360 every time, there would be a certain randomness to it. It has proven effective against robots like Corners, Fire, RamFire, Crazy and of course SittingDuck. I did have difficulty with Wall, SpinBot, and Tracker however.

Targeting:
The targeting for Bato lies in using something similar to Tracker. Bato keeps its sights on one target and attempts to maintain the focus in order to fire continuously at this target. While this was effective against the aforementioned robots, Wall, SpinBot and Tracker were not so easy to beat. With Corners, Fire, RamFire, Crazy and SittingDuck, I had a nearly 100% winning streak. But with the other three robots, the statistics were lower. It appears that Bato's movements are so similar to SpinBot that it does not have an advantage with it. It was the same with Tracker, the targeting strategy of Bato was so similar to Tracker that the results were almost always 50:50. And the Wall robot remains dominant.

Fire:
My strategy for this was simple. I had observed that most of these robots only fired at certain times. Therefore, I chose to fire as frequently and use the most power fire I could. The only drawback was that Bato is frequently disabled if it cannot hit the target if it is moving too fast.

I've learned a little bit about project development through this robot building process. When the time came for coding, it was pretty simple. The problem was to find an idea that worked. This is a classic problem for developers. When I had this problem, I knew I was on a good path because I did not have many problems with syntax or knowing how to do something. That part of development should have been handled by now, and sure enough I had more problems with working at the performance side of the program.

When I look at my robot now, I definitely see flaws in it's strategy. I think if I had a lot more to development this robot I would add in a lot more small details to tweak it and give it more functionality. The project was very helpful in learning how to develop a competitive piece of code.
Here is the robot package. It is entitled "Competitive robot: Bato 1.0."
(http://www2.hawaii.edu/~wingma/)

Robot Strategies

Now that I've learned the basics to Robocode, there are also strategies to consider. What are some strategies out there that work and that can provide me with some insight to how a robot is successful in the battle field? I was assigned to look at the sample code provided in the Robocode directory. Here's what I found:

• Walls

Movement- The main strategy of this robot is to find the closest wall, and run around in straight lines.
It's one of the simplest and most effective strategies. Because when it goes to the side of the wall it covers a big area in which the robot can now no longer be hit.
The robot can only be hit at other are from 180 degrees. This is a dominant robot amongst the sample robots.
Targeting-Uses a boolean variable to scan when the robot is moving, but not when it's turning.
Firing-It shoots at anything it sees.

• RamFire

Movement-This robot always moves toward the target. It wants to collide with robots to deal damage for a ram bonus.
Targeting-The first robot it sees.
Firing-It fires at any robot, but it does not shoot to kill. It wants to ram robots to death.

• SpinBot

Movement-It turns right as much as it can during one turn.
Targeting-No targeting.
Firing-Fire if it sees another robot.

• Crazy

Movement-It moves in an unpredictable fashion so a robot that uses a repetitive algorithm will not hit it twice at the same spot. It will also move crazy even when backing up.
Targeting-No targeting.
Firing-Fires on sight of any robot. It's the same fire power every time.

• Fire

Movement-This robot moves a little and most of the strategy is in running away when it's been hit.
Targeting-It has really bad tracking. It's very ineffective since it doesn't keep it's gun trained on the target.
Firing-Fire power is determined by whether the target is 50 pixels away or within 50 pixels.

• Sitting Duck

Movement-None. This robot is basically a target for all the robots.
Targeting-None
Firing-None

• Corners

Movement-It goes to the corner. It also keeps battle data to determine whether to switch corners next round, if 75% of other robots are still alive at the time of it's death.
Targeting-Once it's at a corner, the robot turns it's gun around to search for targets.
Firing-Fire power is determined by the enemies distance away from it. The closer the target is, the stronger the bullet.

• Tracker

Movement-It follows one target constantly. If it hasn't been seen for 11 turns, then it finds a new target.
Targeting-The gun is trained on the one target.
Firing-Constantly fires on the one target, since it's mostly in tracker's sights.

I learned that simplicity and a good idea can go a long way. The Wall robot for example was very successful in both avoiding bullets and dealing out damage to other robots. The Tracker on the other hand worked in a completely different way. It's main goal was to damage and destroy as many robots as possible. In that aspect it was successful, but in surviving it was not. When it stopped to shoot at its target, enemies had time to shoot back. Another aspect of the Wall robot strategy that was extremely effective was in using the wall as a shield. When you hug the wall the enemy knows where you are, but it cannot come from behind you.

Robocode has some realities to consider. Cover, speed, and nonstop movement is key. When other robots have a hard time hitting you, and you are hitting successfully the damage ratio amongst robots will be in your favor. Nonstop movement is important because I've only observed robots that shoot after they have found a target. If you were to constantly move, the chances are also in your favor.

All these elements are not unlike guerrilla warfare. You perform hit and run tactics, and take advantage your enemies weaknesses and avoid your own. This is my favorite part of the process of doing something competitive. I get to find the best ways to do something and look at my own capabilities.

Adhering to coding standards. It's not that bad.

It's easy to talk about writing in the correct style and following the standards for coding. But when it's time to actually edit your code and make sure it's correct, there is a lot of work involved. I was assigned to correct my source code from my robocode project and it allowed me to look at the codes of my peers. That was good because I found that there were other implementations out there I hadn't thought of or failed to implement.

One of my weaknesses as a programmer is in mathematics. When I looked at another classmates code today, I realized how easy an implement the program was when he just wrote a formula to compute a value. What I did in my implementation was a big bunk of a mess. Trigonometry was a big help to that classmate. When I had tried that kind of implementation in my own program it was very hard. This is one aspect of programming I need to work on.

However, I also realized that I also have some strengths. I have a very strict way of coding and I always look for exceptions and problems to the program. For example, I included a HitRobotEvent method that specified what to do in case there was a robot collision. I included them in all my simple robots that needed it. Some of my classmates didn't do that, so I think I have a different perspective for how a program should work. I kind of think in terms of a overall program and it really bothered me that a collision could happen, so I look for all the cases in which thing could happen. The assignment didn't specify what to do in that kind of situation, but I think it's a good mindset to have. In professional coding, you need to have test cases in mind in order to prevent any type of bugs.

When I read "The Elements of Java Style" it showed me that I had been doing at least some things right. I already include white space and good variable names in my code to improve understanding. These things just made sense. They were guidelines set not because someone said so. They were things worth doing and benefited all programmers. Although I have to admit it is very tedious at times. For example, hard tabs are used by most beginning programmers. But it's prohibited by Coding guidlines. It's a bad habit that creeps in because ICS101 doesn't really warn you about this, but it would be a good idea to inform beginners about that sort of thing. Most of what I know about programming standards and are congruent with Java standards I learned back in ICS101.

Overall, these guidelines aren't difficult to follow. It's like writing a sentence in a paper. If you want to sound professional, you better improve your grammar.
Here is a link to my page for the revised robocode source code.

(http://www2.hawaii.edu/~wingma/)

These are coding standards set by my professor.

• ICS Coding Standards
• ICS Robocode Standards

Robocode. Let the battle begin!

When was the last time you had some fun programming? Robocode is an open source software program that provides some fun and experience with writing code in java. You download a program that builds an environment in which you write code to create a robot that will follow your instructions ultimately to smash the other robots. This was an IBM program that was meant as an exercise in programming. But now 8 years after the release, the software is still strong. It's being maintained by volunteers and could very well go for another 8 years in my opinion. Why? Well I've had a taste of the software and how it works. After going through a short installation process, you'll be absorbed in programming your own robot for hours. It might be a guy's thing with building the most violent robot or just being competitive. You should also take a look at this wiki page volunteers have made for this program. They are a VERY dedicated bunch. (http://robowiki.net/wiki/Main_Page) Well, without sounding like I'm their advertising representative, let the battle begin!

This post will have a few stages to it. First I'll give a quick note about installation and go on to the things I've learned.

Installation:

Go to the link provided above to robowiki.net. It has a very thorough guide to installing robocode and programming it in the Eclipse IDE. Inside the basic tutorial page there will be five links for:

• Using Eclipse as IDE
• Add robot project from an IDE into Robocode
• Creating a robot in Eclipse
• Running your robot from Eclipse
• Debugging your robot with Eclipse

These are the five essential guides that will set you on the course to becoming a Robocoder. Follow through the instructions and you should be fine. They even got pictures and everything.

Basics functions:

I had twelve small programs to build. They were meant to challenge my knowledge and force me to learn the rudimentary skills of Robocode and coding in general. I won't bore you with a long explanation of what to do. Read it and I give a brief about it afterwards. My source code provided will give you an explanation of how I implemented.

1. Movement01. Compile the Robocode and check if you are able to run it.

2. Movement02. Move 50 pixels each turn and be able to turn around when the robot hits a wall.

3. Movement03. Move n pixels per turn and increment n by 10 each turn. n+=10.

4. Movement04. Move the robot to the center of the battle field.

5. Movement05. Move the robot in order from upper left corner, to lower right corner, to upper right corner and then to the lower left corner. You must move diagonally when you can.

6. Movement06. Move the robot to the center and then in a complete circle with the robot ending up in the same position from where it started from, the center.

7. Tracking01. Follow exactly one robot around.

8. Tracking02. Follow the robot and keep at least 20 pixels between it and your robot.

9. Tracking03. Each turn, determine the closest enemy around your robot and move 100 pixels away from it.

10. Firing01. Spin constantly and fire bullets at any of the targets when your robot detects them. The robot cannot move.

11. Firing02. Only target one enemy while spinning and fire on this target alone. The robot cannot move.

12. Firing03. Fire at any targets, but the fire power must be proportional to the distance from your robot. The farther away, the weaker the fire power. The robot cannot move.

13. Firing04. Track a target with your robots gun, always pointing at it. Although you don't actually fire.

I had a lot of problems with some of these programs. For example, movement05 required the robot to move diagonally rather than from wall to wall. Therefore, I had to find the angle to turn the robot and the length to move it. First I found the length using the pythagorean theorem, but finding the angle proved more difficult. In the end I found a compromise. I moved the robot to a certain point that was always 200 pixels away from the walls. That way I knew that the angle was always 45 degrees and the hypotenuse would be 282.

Fear not programmers, it may sound bleak but there are a lot of materials and samples you can rely upon to get you through this. The Robocode package itself has sample robots that you can try out and that have source codes to reference on. Look around and you'll find something to solve your problem. That's what I did.

Conclusion:

This particular exercise made me realize something that was inevitable. Mathematics is really important in programming. I need to know fundamental formulas in order to produce practical code. I actually look forward to studying math now, because I think it will be useful. These 13 programs were useful. Without it, there's not much you can do with Robocode if you don't know the basics.

Once you've gotten the basics out of the way, that's when you can actually built your own robot that will defeat the rest. Over the course of coding and testing these robots, I always had ideas coming up about how to change little details or how to use what already worked. Robocode is very exciting. (except at 1:00 in the morning and you're neck is aching from working on a bug all night)
Go to my UH website to download my source code for all thirteeen exercises. (http://www2.hawaii.edu/~wingma/)