Tuesday, September 29, 2009

Build System: Ant

As we progress and improve our robots for the improved robot Robocode rumble, we were introduced to a very useful build tool called Ant and its dependency manager called Ivy. We also got a first hand experience with the Ant code which was provided by our professor. We are to adapt this Ant code with our code and invoke 3 quality assurance tools.
  • ant -f checkstyle.build.xml
  • ant -f pmd.build.xml
  • ant -f findbugs.build.xml

The only problems I had after running checkstyle were with the javadoc and missing package info. The first one was really easy to fix. All I had to do was add the necessary @param that was left out. It is interesting to see how after revising my code to follow our class' java coding standards and having it reviewed by a classmate, that this necessary javadoc information was overlooked. This is where the quality assurances come in handy. The automation of tasks such as looking for coding standard errors helps achieve the 3rd prime directive, which informs an external user by providing a correct java documentation.

The other problem was not as easy to fix like adding the missing javadoc information. After looking at the results of running checkstlye, which I thought didn't help because it displays the same error message, I checked the original system to see what was missing and it turns out that within DaCruzer's directory is an html file that describes the package. So I did created the same file which describes my package.

After running checkstyle, I tried running the other quality assurance, pmd and findbugs, and did not get any errors.

These quality assurance tools are very helpful in producing robust system that corrects coding standards, improve code efficiency and packages easily. I had a hard time understanding what the Ant code does at first but now that we had hands on experience and understanding each line during a class discussion, I feel like this is something I can use in the future to be better programmer.

Updated WallEE can be downloaded here.

Monday, September 21, 2009

Test bout against Sample Robot!

We are getting closer to the big fight and in the process testing and refining our robots against the sample robots we reviewed. Ever since our group discussion on designing counter measures against sample robots, I have been planning a robot that will win against all of the sample robots. My strategy is similar to the sample robot Walls. After reviewing each sample robots, I learned that Walls outlast the other robots by avoiding enemy fires, since it travels a long distance along the perimeter of the wall. I am adopting Walls because of this attribute, hence the name of my robot WallEE. I added some movement where whenever it scans an enemy, it goes back so that it will have another chance to shoot at the enemy. Another thing I added is just a simple avoidance strategy where it changes direction if it gets hit.

My robot did great against each sample robots. I purposely added the avoidance strategy just to defeat Ramfire and Walls itself. Those were the only robots that sometimes would fare better than WallEE. This is one of the things I had to improve on, to get a better percentage of winning. I realized that these two sample robot wins because they cornered mines. So I added a firing criteria where my robot fires a bullet with its power relative to the enemy's distance. This strategy, coupled with the avoidance strategy improved that percentage. I learned that I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions counter the sample robots

I learned from this experience, that adding functions to counter a specific enemy strategy is inefficient. I have to improve my robot's overall functions, movement, tracking and firing, so that it is equipped with different functions to counter the sample robots. This would be something I would've done differently. I would've tried a strategy that works on most enemies since it's too tedious to plan a counter for every strategy.

Download: WallEE

Tuesday, September 15, 2009

Robocode Sample Strategies Reviewed

After creating our own movements and reviewing other people's implementation, it was a nice change of pace to review the sample robots the contributors of Robocode have created. I got an insight to some simple strategies for creating the best robot. Studying their implementation have shown me different methods I would have not known or use otherwise. This have helped me plan a strategy for the upcoming Robocode competition.

Review Tasks:
  • Movement: How does the robot move? Does it have an avoidance or following strategy?
  • Targeting: How does it find a target to fire?
  • Firing: What is its criteria for firing?
Wall
Movement: This robot moves around the perimeter of the wall in a clockwise manner. It does this by turning left and by going ahead to the wall it is facing. It has an avoiding strategy which moves the robot back if the enemy who shot it is in front and ahead if it's behind.
Targeting:
Its targeting mechanism is very basic that it uses the game's call to scan which does it automatically whenever the robot moves or turns its body/gun/radar.
Firing:
It also has a very basic firing system where it fires at an enemy whenever it scans an enemy robot.

RamFire
Movement: This robot searches for an enemy and ram it then when it hits its enemy if fires a bullet with power that depends on the enemy's energy. It does this by relying on the enemy's bearing which in turn determines how the robot turns in which direction.It has no avoidance technique since its primary objective is ram enemies for bonus points.
Targeting:
Its targeting is dependent on how the robot moves when it changes it's direction.
Firing:
The robots firing mechanism depends on the enemy's energy points. It fires a low power bullet if the energy level is low. The robot's purpose seems to use ramming as primary technique instead of firing bullets.

SpinBot
Movement: This robot moves in a circle and fires an enemy when in range. Its avoidance strategy is its circular movement.
Targeting:
Its targeting mechanism is pretty basic, it fires whenever it scans an enemy.
Firing:
Since its targeting is basic, this robot fires a bullet with a power of 3.

Crazy

Movement: This robot's movement just like its name suggest is crazy. Its erratic behavior resembles a chicken with its head cut-off. It has a set amount of pixel movement and changes direction each turn. It changes reverses direction whenever it hits a wall or another robot and then returns to its original behavior. Its erratic behavior is its avoidance strategy and consequently does not follow any following strategy.
Targeting:
Considering its crazy moves, the targeting mechanism lacks the same extremity, it just follows the gun's heading.
Firing:
This robot does not have any criteria for firing. It just fires when an enemy is scanned.

Fire
Movement: This robot mostly sits still and only moves when it is hit. It moves back and fort whenever it gets hit each time. Its avoidance strategy is useless if not close to nothing since it only moves so that it never gets hit in the same place twice consecutively.
Targeting:
Its targeting system is basic. It relies on the gun's turning as a way to scan for enemies.
Firing:
Its firing criteria is to shoot the enemy with a high powered bullet if it's target is close and lower powered bullet when near.

SittingDuck
Movement: This robot does nothing therefore there is no avoidance or following strategy.
Targeting:
It does not find a target.
Firing:
And does not fire.

Corners
Movement: This robot moves to the top left corner and just stays there. It changes corner for the next round whenever it dies.
Targeting:
Its targeting system is average since it first checks to see if there is a robot in it's path and if there is starts it's custom firing method. It also only scans a 90 degrees radius that is adjusted depending on the corner. This however could be a potential flaw that limits the robot's firing range since it stops and fires at an enemy before it even gets to it's corner.
Firing:
This robot's firing criteria is to use a bullet power relative to the enemy target's distance.

Tracker
Movement: This robot's following strategy is to close in at a chosen target and moves within 100 pixels of that target and fires. It moves back a little if gets too close.
Targeting:
Since the robot's strategy is to follow a chosen target and gets close enough to fire, its targeting depends on the gun's turning.
Firing:
This robot doesn't have any special criteria. It mainly shoots a higher powered bullet whenever it gets close to an enemy.

Upon writing my review for each robots, I realized that the best strategy is to balance the movement, targeting, and firing methods. All three aspects have overlapping functions that when combined properly can build one of the best robots.

Monday, September 14, 2009

Conforming to Java Coding Standards

After reading the Elements of Java Style I can't help but admit that my coding style is not that great. I have used one-line comments placed right next to the code, which I thought seemed convenient since it immediately follows the code it refers to. Instead I figured that it is better to add it before the code declaration since we are only allowed 100 characters per line, which is part of our class' own coding standard. Since I imported the Eclipse formatting template I didn't really have any problems reformatting my robots to conform with the assigned coding standards. All of the work was changing the javadoc to third person, making sure it ends with a period. Another thing that I had to do was to add <code>...</code> tags since I included method names in my javadoc.

My updated source code.

Wednesday, September 9, 2009

Practice run in Robocode, gearing up for the Big Fight!

Robocode is an excellent program that lets users design their robot's function and puts it to the test by facing off with other robots. For this assignment, we familiarize ourselves to the program by creating simple functions that teaches us movement, radar control and targeting.
These functions are:
  • Movement01: The minimal robot. Does absolutely nothing at all.
  • Movement02: Move forward a total of 50 pixels per turn. If you hit a wall, reverse direction.
  • Movement03: Each turn, move forward a total of N pixels per turn, then turn left. N is initialized to 10, and increases by 10 per turn.
  • Movement04: Move to the center of the playing field and stop.
  • Movement05: Move to the upper left corner. Then move to the lower right corner. Then move to the upper right corner. Then move to the lower left corner.
  • Movement06: Move to the center, then move in a circle, ending up where you started.
  • Tracking01: Pick one enemy and follow them.
  • Tracking02: Pick one enemy and follow them, but stop if your robot gets within 20 pixels of them.
  • Tracking03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
  • Firing01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
  • Firing02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
  • Firing03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you.
  • Firing04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire.
The problems that I encountered were from Movement04 and Tracking02. I thought that movement04 was pretty hard because it involved trigonometry. After several failed attempts of trying to figure it out on my own, I asked my friend about it and he mentioned a website where he found a code that does what we needed to do for movement04. The code helped me a lot in figuring out how to do movement04 especially with the trigonometry functions. As for tracking02 my problem was getting my robot to stop within 20 pixels away from my enemy. I tried factoring in the sizes of my robot and my enemy into the calculated distance between, since the distance is calculated from the center of each robot, but it never worked. It is one of the problems I still need to work on.

All in all I thought that it was a fun assignment. As challenging as it is, I think that this is a good exercise for us not only to use open source materials but to apply different fields such as Math as tools needed in programming. My ideas for a competitive robot will most definitely involve Math since I plan to focus on movement and targeting.
My sample code can be found here.