We are nearing the half way mark of the semester and now we are beginning to prepare for our upcoming group projects. Our next task is to study how to use Subversion with Google Hosting.
Subversion is a tool that enables you and your group members to upload local copy of your project onto the online repository.
Using Subversion with Google Hosting can never be easier. I was able to upload my project almost issue free. The only problem I had with uploading my project was that I accidentally deleted parts of my project and for a little while I was not able to run verify on it. I was able to determine the source of the problem fairly quickly however. I simply copied down to my local repository the files that were missing in the online repository, and committed the changes. The missing files were back on the repository and the project was back and ready to go.
Throughout this exercise and learning this new Google Hosting functionality, I am now more confident that I will be able to organise a group project. I think that one important feature of Subversion is that we have the option to roll back to previous versions of the project if something goes very wrong in our latest project version. I would like to be able to effectively use all the functionalities provided by Subversion
Wednesday, October 14, 2009
Wednesday, October 7, 2009
Testing Stage
Now that we finished developing our robocode project, it is now time for some testing. Testing a project may sound easy at first, but in fact, it is one of the most difficult tasks when it comes to project development. As a part of our class exercise, we were asked to design some test cases that would be useful when we actually go and create the test cases later on. I must say that it was not easy to come up with an ideal test case for my lab partner's robocode project. It took me a good half an hour of thinking and brainstorming to finally come up with an idea that may work well for his project.
Designing test cases for my own robot also was a difficult task. It seemed to me that in order for my robot to pass an acceptance test, it must at least beat the strongest of the sample robots, that is, Walls. I simply created an acceptance test case where my robot and Walls battle with each other for 5 rounds. If my robot successfully beats Walls 5 matches in a row, then it passes the first phase of my acceptance test. Another acceptance case would be a very similar one, but my robot now has to beat Tracker. I chose to implement Tracker because this robot does not have a set routine movement like Walls and some of the other sample robots. Passing my two acceptance case would mean that the robot is capable of beating a robot that is strong and has a set routine movement, and is also capable of beating a robot that does not have a set routing movement.
My first behavior test was rather simple. Since my robot does somewhat involve random movements, and it is programmed to move forward until it hits a wall, it should at least touch 3 of the 4 walls in the battlefield before the match ends. My first behavior test checks just that. My other behavior test checks to see if the robot is actually moving perpendicular to the enemy. This part of the test was difficult to implement because by the time onTurnEnd() method is called, the target robot may have moved to a another position. I resolved this issue by giving the robot a much larger range for its 'perpendicular movement'. For instance, moving 45 degree angle towards the enemy would still be considered as a 'perpendicular movement'.
For my Unit tests, I basically tested to see if the part of my code that controls the turning of the robot is working correctly. I also had some difficulties implementing this test case because the robot only turns about 10 degrees per turn. This makes it difficult to keep track of the robot's turn rate and how much it had already turned. My other Unit test case checks for the function that takes the robot out of the corners. This is done simply by checking whether the robot does a 90 degree turn sometime during a battle.
After finishing up all of my test cases, I continued to improve my project by using a tool called Emma. Emma is a tool that provides a greater insight to your code, by allowing you to view which part of your code is actually being ran and which part isn't. This tool is helpful especially when it comes to testing and I hope to use this tool for my future projects as needed.
My Robocode project with the above test cases can be downloaded Here.
Designing test cases for my own robot also was a difficult task. It seemed to me that in order for my robot to pass an acceptance test, it must at least beat the strongest of the sample robots, that is, Walls. I simply created an acceptance test case where my robot and Walls battle with each other for 5 rounds. If my robot successfully beats Walls 5 matches in a row, then it passes the first phase of my acceptance test. Another acceptance case would be a very similar one, but my robot now has to beat Tracker. I chose to implement Tracker because this robot does not have a set routine movement like Walls and some of the other sample robots. Passing my two acceptance case would mean that the robot is capable of beating a robot that is strong and has a set routine movement, and is also capable of beating a robot that does not have a set routing movement.
My first behavior test was rather simple. Since my robot does somewhat involve random movements, and it is programmed to move forward until it hits a wall, it should at least touch 3 of the 4 walls in the battlefield before the match ends. My first behavior test checks just that. My other behavior test checks to see if the robot is actually moving perpendicular to the enemy. This part of the test was difficult to implement because by the time onTurnEnd() method is called, the target robot may have moved to a another position. I resolved this issue by giving the robot a much larger range for its 'perpendicular movement'. For instance, moving 45 degree angle towards the enemy would still be considered as a 'perpendicular movement'.
For my Unit tests, I basically tested to see if the part of my code that controls the turning of the robot is working correctly. I also had some difficulties implementing this test case because the robot only turns about 10 degrees per turn. This makes it difficult to keep track of the robot's turn rate and how much it had already turned. My other Unit test case checks for the function that takes the robot out of the corners. This is done simply by checking whether the robot does a 90 degree turn sometime during a battle.
After finishing up all of my test cases, I continued to improve my project by using a tool called Emma. Emma is a tool that provides a greater insight to your code, by allowing you to view which part of your code is actually being ran and which part isn't. This tool is helpful especially when it comes to testing and I hope to use this tool for my future projects as needed.
My Robocode project with the above test cases can be downloaded Here.
Wednesday, September 30, 2009
MistaRoboto Domo Arigato
It has been about 3 weeks since we first implemented Robocode. It is now time to build our Robocode project in a more professional manner. During our class exercise, we have done some practice building/compiling projects on an open source build tool called Ant. Ant is a convenient java build tool that provides you with many differnet features. We also use Ant with other useful tools such as Ivy, Checkstyle, FindBug and PMD. Most of these tools provide means of error and style checking, which is extremely useful when it comes to building and writing a readable code.
Building together my version 1.1 Robocode project was not an easy task. I faced numerous problems trying to get the Junit and PMD to work and succesfully run on my project. The problem associated with Junit turned out to be that the compile command in build.xml file did not place my robot.class file properly into the lib/robocode directory. I was unable to figure out the source of this problem; however, re-downloading and re-installing the package seem to have fixed the issue.
The PMD issue was a tricky one. It turns out that the problem had nothing to do with editing of .xml files or misplacing of files. The issue was within the .java source code. I began to test my source code by commenting out one block at a time to see which line was causing the issue. I pinpointed the problem down to the block of codes involving the override of onHitRobot method. It seems that this block of code was preventing the PMD check to fail for an unknown reason. I have solved the issue by removing the lines of code.
I have learned a lot through this exercise. The use of CheckStyle was what stunned me the most. CheckStyle able to spit out about 50+ style errors in my source code initially. Through looking at the output html file, I was able to improve my code and make it much more readable. I find these build tools to be extremely helpful, and I hope to improvise these tools in the future when I develop more and more complex systems.
My Robocode MistaRoboto is available here
Building together my version 1.1 Robocode project was not an easy task. I faced numerous problems trying to get the Junit and PMD to work and succesfully run on my project. The problem associated with Junit turned out to be that the compile command in build.xml file did not place my robot.class file properly into the lib/robocode directory. I was unable to figure out the source of this problem; however, re-downloading and re-installing the package seem to have fixed the issue.
The PMD issue was a tricky one. It turns out that the problem had nothing to do with editing of .xml files or misplacing of files. The issue was within the .java source code. I began to test my source code by commenting out one block at a time to see which line was causing the issue. I pinpointed the problem down to the block of codes involving the override of onHitRobot method. It seems that this block of code was preventing the PMD check to fail for an unknown reason. I have solved the issue by removing the lines of code.
I have learned a lot through this exercise. The use of CheckStyle was what stunned me the most. CheckStyle able to spit out about 50+ style errors in my source code initially. Through looking at the output html file, I was able to improve my code and make it much more readable. I find these build tools to be extremely helpful, and I hope to improvise these tools in the future when I develop more and more complex systems.
My Robocode MistaRoboto is available here
Monday, September 21, 2009
My Competitive Robot
It is now the time to build our own Competitive Robot, that is, a Robot that can beat all of the sample Robots! Our assignment for this week was to build a Robot that can specifically beat the following sample robots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck.
It certainly was not easy to build a Robot that can beat all of the eight sample robots, as they all have very different strategies. My robot, called MistaRoboto, has the following functionalities.
Movement:
The Robot first searches for nearby targets, and rotates its body so that one of its side faces directly towards the target, and moves back and forth. In other words, my Robot moves perpendicularly to its target while firing.
Targeting:
The Robot initially sweeps the battle field left and right, and once it acquires a target, it tries to keep its gun towards the target for as long as it can.
Firing:
The Robot does not fire until the target is reasonably near, that is, within 400 pixels radius. The Robot will fire with medium fire power for targets within 400 pixels and farther and 200 pixels. The Robot will fire with maximum fire power for targets within 200 pixels.
My Robot can beat RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck pretty consistently. It has trouble with Walls however. Since my Robot is effective only against Robots within close range, it seems to have a difficult time dealing with Walls' strategy.
One mistake I made during this assignment is that I started punching out codes before really thinking deeply about my Robot's combat strategy. It seems that with projects like this, or any other projects for that matter, it is important that I map out the plan beforehand so that I understand exactly where I am headed. I also think that planning ahead actually does reduce the total time spent for coding. Therefore, I believe it is important that I build a solid plan before coding and I hope to practice this with future assignments.
You can download my Robot here
It certainly was not easy to build a Robot that can beat all of the eight sample robots, as they all have very different strategies. My robot, called MistaRoboto, has the following functionalities.
Movement:
The Robot first searches for nearby targets, and rotates its body so that one of its side faces directly towards the target, and moves back and forth. In other words, my Robot moves perpendicularly to its target while firing.
Targeting:
The Robot initially sweeps the battle field left and right, and once it acquires a target, it tries to keep its gun towards the target for as long as it can.
Firing:
The Robot does not fire until the target is reasonably near, that is, within 400 pixels radius. The Robot will fire with medium fire power for targets within 400 pixels and farther and 200 pixels. The Robot will fire with maximum fire power for targets within 200 pixels.
My Robot can beat RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck pretty consistently. It has trouble with Walls however. Since my Robot is effective only against Robots within close range, it seems to have a difficult time dealing with Walls' strategy.
One mistake I made during this assignment is that I started punching out codes before really thinking deeply about my Robot's combat strategy. It seems that with projects like this, or any other projects for that matter, it is important that I map out the plan beforehand so that I understand exactly where I am headed. I also think that planning ahead actually does reduce the total time spent for coding. Therefore, I believe it is important that I build a solid plan before coding and I hope to practice this with future assignments.
You can download my Robot here
Wednesday, September 16, 2009
Sample Robot Strategy Analysis
The Robocode program is packaged with various sample robots. Below are a few list of sample robots with its battle strategy.
Walls
Movement: This robot simply moves along the wall clockwise. It does not have any avoidance or following strategy to speak of, but it seems quite effective when faced with more than 2 robots. The only time the robot moves away from the wall is when it hits another robot along the wall, in which case, it attempts to move to the wall directly across the battlefield and continue its maneuver.
Targeting: Its targeting system is also very simple as it never moves its radar while targeting. It finds a target by pointing its gun towards the battlefield while moving along the wall.
Firing: It only fires when the radar detects the enemy. It never rotates the gun or the radar to scan/lock on to a target.
RamFire
Movement: Rotates until it detects a target, and moves directly towards it. It does not have any avoidance strategy, but its following strategy is to move directly onto the position of a target.
Targeting: It finds its target initially by rotating clockwise. Once it loses the target, it randomly rotates clockwise or counter-clockwise to continuously search for targets.
Firing: It fires only when the robot hits a target. It attempts to maximize the damage by continuously moving (ramming) into the target and by firing with the maximum fire power.
SpinBot
Movement: This robot's avoidance strategy is to move in a very tight circle. It does not have a following strategy.
Target: It finds a target simply by scanning while moving around in a circle.
Firing: Fires only when it detects an enemy with the maximum firepower.
Crazy
Movement: Its avoidance movement is to move in series of half circles and reversing direction when hitting a wall. It does not have any following strategy.
Target: It finds its target by scanning while moving in a series of half circles.
Firing: It attempts to hit the enemy as accurately as possible by using the lowest file power.
Fire
Movement: No movement.
Target: Scans for enemy by rotating its gun clockwise. Keeps the gun towards the target so long as the target does not move out of sight. It continues to scan once it loses its target.
Firing: Fires continuously until the target is destroyed with the minimum fire power.
Sitting Duck
Movement: No movement.
Target: No targeting.
Firing: No Firing. I am guessing its strategy is to sit and wait until everybody else is destroyed or disabled.
Corners
Movement: Moves to upper-left corner as soon as the battle begins, and sits there for the duration of the battle. It has no following strategy.
Targeting: It scans targets through a series of clockwise and counter-clockwise scannings.
Firing: Fires continuously until the target is destroyed.
Tracker
Movement: Moves towards the enemy and holds about 100 pixels away from the target. It has no avoidance strategy.
Targeting: Very similar to ramfire, except this robot rotates its radar to scan for targets. Once the robot loses its target it attempts to re-acquire the target by briefly scanning left and right.
Fire: Attempts to maximize the damage by firing with maximum power. Fires until the target is destroyed.
Walls
Movement: This robot simply moves along the wall clockwise. It does not have any avoidance or following strategy to speak of, but it seems quite effective when faced with more than 2 robots. The only time the robot moves away from the wall is when it hits another robot along the wall, in which case, it attempts to move to the wall directly across the battlefield and continue its maneuver.
Targeting: Its targeting system is also very simple as it never moves its radar while targeting. It finds a target by pointing its gun towards the battlefield while moving along the wall.
Firing: It only fires when the radar detects the enemy. It never rotates the gun or the radar to scan/lock on to a target.
RamFire
Movement: Rotates until it detects a target, and moves directly towards it. It does not have any avoidance strategy, but its following strategy is to move directly onto the position of a target.
Targeting: It finds its target initially by rotating clockwise. Once it loses the target, it randomly rotates clockwise or counter-clockwise to continuously search for targets.
Firing: It fires only when the robot hits a target. It attempts to maximize the damage by continuously moving (ramming) into the target and by firing with the maximum fire power.
SpinBot
Movement: This robot's avoidance strategy is to move in a very tight circle. It does not have a following strategy.
Target: It finds a target simply by scanning while moving around in a circle.
Firing: Fires only when it detects an enemy with the maximum firepower.
Crazy
Movement: Its avoidance movement is to move in series of half circles and reversing direction when hitting a wall. It does not have any following strategy.
Target: It finds its target by scanning while moving in a series of half circles.
Firing: It attempts to hit the enemy as accurately as possible by using the lowest file power.
Fire
Movement: No movement.
Target: Scans for enemy by rotating its gun clockwise. Keeps the gun towards the target so long as the target does not move out of sight. It continues to scan once it loses its target.
Firing: Fires continuously until the target is destroyed with the minimum fire power.
Sitting Duck
Movement: No movement.
Target: No targeting.
Firing: No Firing. I am guessing its strategy is to sit and wait until everybody else is destroyed or disabled.
Corners
Movement: Moves to upper-left corner as soon as the battle begins, and sits there for the duration of the battle. It has no following strategy.
Targeting: It scans targets through a series of clockwise and counter-clockwise scannings.
Firing: Fires continuously until the target is destroyed.
Tracker
Movement: Moves towards the enemy and holds about 100 pixels away from the target. It has no avoidance strategy.
Targeting: Very similar to ramfire, except this robot rotates its radar to scan for targets. Once the robot loses its target it attempts to re-acquire the target by briefly scanning left and right.
Fire: Attempts to maximize the damage by firing with maximum power. Fires until the target is destroyed.
Monday, September 14, 2009
Robocode coding Standards
The simple Robocode design is now complete, and we are now ready for the next step. It is always a good practice to write your code clean and follow some form of standard, so that other people can clearly read your code and understand. It helps if you follow some form of standard, and this precisely is our next task.
I must say that I ran across a numerous trouble trying to get my Robocode to meet the class's coding standards. I decided that I should start with something rather simple, and that is, to change my robocode project name "robocode" to a more appropriate "robocode-danielhcolton". This; however, did not go as smoothly as I initially thought it would.
I was faced with an infamous nullPointerException after refractoring the "robocode" project name to the new "robocode-danielhcolton". Mysteriously, resetting all of VM arguments, classpath, and the development options under the robocode GUI did nothing to solve the issue. I was very close to giving up but turning the assignment in with an inappropriate project name was not an option for me. I finally solved the issue by creating a brand new project under the new name "robocode-danielhcolton" and copying all the necessary .java files to it. Although I was happy I finally got it to work, I sure wish this simple renaming process were a lot more simple.
The rest of the process was rather easy in comparison. The xml document that our professor provided sure did a lot of help in terms of making our code much more readable.
Following a coding standard while programming is very much like writing essays with correct grammar. A reader will have a much difficult time deciphering your writings if your essay is full of spelling and grammar errors. Coding standards must always be followed, especially if you work with a team of programmers.
Here is my revised version of Robocode Project
I must say that I ran across a numerous trouble trying to get my Robocode to meet the class's coding standards. I decided that I should start with something rather simple, and that is, to change my robocode project name "robocode" to a more appropriate "robocode-danielhcolton". This; however, did not go as smoothly as I initially thought it would.
I was faced with an infamous nullPointerException after refractoring the "robocode" project name to the new "robocode-danielhcolton". Mysteriously, resetting all of VM arguments, classpath, and the development options under the robocode GUI did nothing to solve the issue. I was very close to giving up but turning the assignment in with an inappropriate project name was not an option for me. I finally solved the issue by creating a brand new project under the new name "robocode-danielhcolton" and copying all the necessary .java files to it. Although I was happy I finally got it to work, I sure wish this simple renaming process were a lot more simple.
The rest of the process was rather easy in comparison. The xml document that our professor provided sure did a lot of help in terms of making our code much more readable.
Following a coding standard while programming is very much like writing essays with correct grammar. A reader will have a much difficult time deciphering your writings if your essay is full of spelling and grammar errors. Coding standards must always be followed, especially if you work with a team of programmers.
Here is my revised version of Robocode Project
Wednesday, September 9, 2009
Battle with Robocode
Robocode is an interesting piece of code that you can work on to brush up your Java programming skills. I find Robocode challenging, as it requires numerous programming, math, and of course, debugging skills.
We were intructed to download and install the source code to work with Eclipse IDE. Although I barely had an experience working with Eclipse in the past, the installation process went quite smoothly. I find it rewarding to finally see my Robot tank on my screen with my name on it after following series of complex instructions.
I have created various robot tanks that can do certain movements, such as moving in a circle, move to all corners, etc. The following is a list of movements I have produced
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).
All of the movements through 01 to 04 I was able to implement successfully. Movement05 involved many trigonometric computations and I was not able to get the Math functions in Java to work properly, so I ended up dropping the diagonal movements all together. The robot in Movement05 now interestingly reaches all four of the corners without any diagonal movements.
I also had a couple of problems with tracking02. It seems that when I try to code the robot to stop 20 pixels before reaching the target, it does not take the size of the robot itself into account. With the setting Distance - 20(pixels), my robot ended up hitting the target everytime. I solved this problem by adding about 40 pixels to on top of the 20 pixels to compensate for the size of the tank. After applying the change, my robot now seems to follow its target about 20 pixels behind.
Another problem that I had occured while developing tracking03. I programmed the tank so that it would store the name and the distance to the robot who is the closest. I could not fully test if everything was working correctly as Robocode battlefield tend to get pretty chaotic when it has more then 3 robots running around. The robot also does not fully stop after traveling 100 pixels. It only briefly stops after each move and attempts to search again for the nearest robot.
If you would like to download my Robocode, feel free to do so.
I will also also provide a link to the source forge site here:
http://robocode.sourceforge.net/
We were intructed to download and install the source code to work with Eclipse IDE. Although I barely had an experience working with Eclipse in the past, the installation process went quite smoothly. I find it rewarding to finally see my Robot tank on my screen with my name on it after following series of complex instructions.
I have created various robot tanks that can do certain movements, such as moving in a circle, move to all corners, etc. The following is a list of movements I have produced
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).
All of the movements through 01 to 04 I was able to implement successfully. Movement05 involved many trigonometric computations and I was not able to get the Math functions in Java to work properly, so I ended up dropping the diagonal movements all together. The robot in Movement05 now interestingly reaches all four of the corners without any diagonal movements.
I also had a couple of problems with tracking02. It seems that when I try to code the robot to stop 20 pixels before reaching the target, it does not take the size of the robot itself into account. With the setting Distance - 20(pixels), my robot ended up hitting the target everytime. I solved this problem by adding about 40 pixels to on top of the 20 pixels to compensate for the size of the tank. After applying the change, my robot now seems to follow its target about 20 pixels behind.
Another problem that I had occured while developing tracking03. I programmed the tank so that it would store the name and the distance to the robot who is the closest. I could not fully test if everything was working correctly as Robocode battlefield tend to get pretty chaotic when it has more then 3 robots running around. The robot also does not fully stop after traveling 100 pixels. It only briefly stops after each move and attempts to search again for the nearest robot.
If you would like to download my Robocode, feel free to do so.
I will also also provide a link to the source forge site here:
http://robocode.sourceforge.net/
Subscribe to:
Posts (Atom)