Wednesday, September 30, 2009

Ant: Project Building Made Easy

Ant is one of the best java programming tool I've used to date. Before Ant, it was just about writing the code, manually checking it for errors, then be done with it. Ant gives us the ability to create better software and automated quality assurance tools. This homework assignment allowed us to experience working with Ant by using robocode-pmj-dacruzer system as a template for our robots.

Getting Ant to run on my machine didn't go so well. After downloading the latest version of Ant and setting up the paths for it, I still couldn't get it to run. After some time, I came across a page that says Ant is installed with XCode tools for mac. I had XCode installed on my machine so I went ahead and check if there is a version of Ant installed by removing the new one that I just downloaded. After invoking the command ant -version, I was presented with a 1.7.0 version of Ant. I then removed that version and tried to install the newest build and the error disappeared. I then ran the ant invocations for the robocode-pmj-dacruzer system and passed all of it.

The second task of the homework was to use robocode-pmj-dacruzer as a template to implement on our own robocode project. I found that the best way to understand how Ant works is by tracing the xml files. It gave me an idea of how the build system worked. After modifying the build files, I was able to invoke ant and have a successful build.

The third task involves automated quality assurance on our project. The tools that we used for this project are Checkstyle, PMD, and FindBugs. As you all know, Checkstyle helps us developers to write codes that adhere to coding standards. In the past, I would do this manually by going through each line of the code. This quality assurance is automated by Checkstyle. After invoking ant -f checkstyle.build.xml for the first time, it flagged my code with two errors. The first error involves my use of "@date" which is not a valid Javadoc tag name. I simply removed that tag and replaced it with an @version tag instead. The other error was due to the lack of package-info.java file. I made a simple html file with the appropriate information. I rant the checkstyle build again and it flagged five more errors in my code. The first error was because I missed a period in my sentence. The other error was a missing Javadoc comment. The rest of the errors was due to missing @param tags for my methods. Checkstyle passed with no errors after my last fix. PMD reported no errors in my code which is good news. FindBugs however found one error. The error was URF_UNREAD_FIELD: Unread field. I had a variable that wasn't being used. This is a performance type of warning. All is good after removing that variable.

I may become very dependent with these quality assurance tools. They would make my future software development much more easier to debug. Also, utilizing these tools greatly cuts down the debugging time so we can focus more on making our software better.

Click here for my robocode-djl-DaBeast system.

-David Joel Lazaro

Monday, September 21, 2009

Robot's First Shot at Glory

My last entry was about deciphering the enemies' strategy. Now it's time to implement what I learned and build my first competitive robot. My first shot at glory is probably the most basic robot out there. But don't let it fool you. It was able to beat five out of the eight sample robots that I reviewed in my last blog.

DaBeast
When I was trying to figure out the movement of this robot, my main concern was to avoid being hit by a bullet. I figured I might was well keep it simple for now and just move back and forth in the battle field. The movement was actually quiet effective for most of the sample robots. I also made it so that when it hits a wall, it turns around and move forward a bit to avoid hitting the wall again. DaBeast also borrowed some move from RamFire. When it hits an enemy robot, it turns to face it, then fires hard. For targeting, I simply made my robot's gun go 360 each turn to track the enemy. I made this robot so that it comes out guns blazing. It really goes for the kill as it fires a hard shot every time.

DaBeast can reliably beat Crazy, Fire, Corners, Tracker, and SittingDuck. In reality, as much as we want to, we can't really win them all. DaBeast has a hard time defeating Walls, RamFire, and SpinBot. I think I'm going to take a different route next time and modify what I believe is the best sample robot which is the Walls. The Walls robot is the most elusive one to defeat and tweaking it could make it even more deadly.

Click here if you guys want to try out DaBeast.

-David Joel Lazaro

Wednesday, September 16, 2009

Robocode: Studying the Enemy

In Robocode, learning the way of the enemy can help in building the ultimate robot. By understanding how the sample robots work, we can combine all the good parts and come up with an awesome robot. I will be reviewing eight sample robots that came with the Robocode package. I'll review their strategy in terms of movement, targeting, and firing.

Walls
This robot's strategy is simple yet very effective. It simply moves along the walls of the battlefield. If it scans an enemy, it fires right at it. It is also smart enough to move to the opposite wall when it hits an enemy.

Ramfire
This robot clearly has destruction on its agenda. It scans the battlefield for an enemy by spinning around. Once it finds one, it goes towards the enemy and rams it. It then starts shooting at the enemy but it doesn't kill it right way. It scans the enemy's health to lower its firing power because it wants to destroy by ramming into it.

Spinbot
This robot moves in a circle the whole time. It moves away a little when it hits a wall or an enemy so that it can continue to move in circles. Once it scans an enemy, it fires at it while moving in circles. This makes it hard to fire back at it because of its movement.

Crazy
This robot moves in a "crazy" pattern. It's movement loops in left and right turns. It reverses direction when it hits the wall or an enemy. When it scans an enemy, it also fires right at it.

Fire
This robot just sits in one position and rotates its gun to scan for an enemy. If the enemy is within 50 pixels and the Fire robot has at least 50 percent life, it fires a more powerful bullet. When an enemy rams into it, it turns its gun to that enemy and fires strong bullets at it. The only movement this robot does is when it gets hit by a bullet. It turns perpendicular to the bullet and moves out of the way.

Sitting Duck
This robot does absolutely nothing in terms of movement, tracking, and firing.

Corners
This robot goes to a corner of the battlefield then moves its gun back and forth to scan for the enemy. If this robot sees an enemy before getting to the corner, it stops and fires at that enemy. Its firing power is based on the distance from the enemy robot. The closer the enemy, the stronger the bullet gets. Also, if this robot dies before most of the enemy robots, it picks a different corner to go to for the next round.

Tracker
This robot scans the battlefield with its gun for an enemy. Once it sees one, it locks on to it. It then moves closer to the enemy and fires at it. It will continue to follow that enemy until it's destroyed. When this robot runs into an enemy besides the one its tracking, that enemy becomes its new target. It also does a cool victory dance at the end of the round.

-David Joel Lazaro

Monday, September 14, 2009

The Importance of Coding Stadards

Implementing standards in our coding is very important especially in today's open source world. Following the standards doesn't just help you as a developer, it also helps anyone trying to read and understand your code. Readability is probably the main reason why someone should follow coding standards. Imagine having to debug over a thousand lines of codes with no documentation or comments written anywhere. That scenario could be classified as a developer's nightmare. It would be very difficult to follow and understand how everything works. It would be difficult to find someone in the open source world interested in your code because of the lack of documentation. Why would someone waste their time trying to understand and figure out how a program works? They could be using that time to add or fix the software if coding standards were followed.

I have been following most of the coding standards throughout my college career. I'm kind of a neat freak so I want my code to look nice and easy to read. One standard that I tend to break is the use of tabs. Using tabs made everything align for me the way I want it. The problem with this is that a different environment might interpret tabs differently. Using spaces instead of tabs eliminates this problem. My problem is that I'm so used to tabbing my codes as I type them. Thank goodness for the Format option of Eclipse :).

I've edited my robocode assignment to follow the coding standards of my class. You guys can download the .jar file here.

David Joel Lazaro

Wednesday, September 9, 2009

CodingWars with Robocode

In the past, the Java programs that I've worked on usually involves solving problems and implementing the basics of Java. Robocode has to be the most interesting Java programming that I've ever worked on. The main reason is that, it's a GAME that involves robots beating the crap out of each other. The concept is that you build your robot, have it battle one or many robots, and hope that it destroys all of its enemies. In our homework assignment, we had to build 13 robots with the following traits (taken from the assignment page):
  • 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. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
  • 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 (you don't want to kill it).
Creating those robots familiarized us with the basics of Robocode from movement, tracking, and firing. I was able to finish all of the assigned robots with some minor bugs.

One of the things I noticed while working on this assignment was that I had to refer to the Robocode wiki and API a lot because most of the functions that I used were new to me. The robot that gave me the hardest time was Movement05. This robot had to go to each corners of the field diagonally. I was trying to figure out how to make the robot go to a specific coordinate so that I can command it to go to the corners one after the other. A couple of hours later, one of our classmates found this website that shows exactly what we wanted our robot to do. We implemented the code and voila! Movement05 did exactly what I wanted it to do. Of course I cited the website and its author in our code :) .

One thing I learned about how the robots behave is that they can be as flexible as you want them to be, as long as you program them correctly. I also learned that the robot doesn't always behave the way you want it to be :( . I also noticed that there are some kind of physics involved in the game. I noticed this when I was working on the firing robots. Their firing accuracy is higher when their gun turns slowly rather than spinning fast.

My ideal competitive robot would be finely tuned in all ways possible. Pinpoint firing accuracy and bullet evasion would be good. When I work on the advanced robots then I'll have more ideas for what can be done better for competitions.

You guys can download and try my robots by clicking this link.

David Joel Lazaro