Continuous Integration

Continuous integration is an interesting tool that can be very helpful while developing software. Continuous integration allows for your team to upload the latest versions of the code to a repository (in my case GoogleCode) and then have Hudson automatically build the system for you and notify you when the build is complete and if it failed or completed successfully.

My initial impression of Hudson was that it was a nice way to automatically test your system. I found that the interface was well set up and easy to use and that if continuously gave detailed information about who was currently building, what the queue to build was and information about failed and completed builds. The only downside is that if the build failed there is no information on what caused the build to fail. However, the build shouldn't fail as it is the user's responsibility to run such tests as ant -f verify.build.xml to ensure a passing build before committing the changes.

Midterm Review Questions

Here are some questions I thought would be helpful in reviewing for the midterm:

1. What is the difference between "white box" and "black box" testing?

Black Box: Design a set of test cases to see if inputs match the desired outputs. Can also catch errors of omission. No access to source code required.
White Box: Use of coverage tools (CheckStyle, ect) to find bugs. Can catch code that has been writen.

2. Why is Subversion so helpful to software development?

Allows for multiple versions to be stored in a database.
Supports optimistic locking and all files are available for check out so that multiple users can edit the same file at one time.

3. What is the purpose of Ant?

Ant provides cross platform coverage tools that execute specific xml targets which performs a white box testing of the specified code.

4. What does the task "ant -f verify.build.xml" do?

This command runs all available tools (CheckStyle, FindBugs, JUnit, ect) as well as the build.xml target and fails the build if one of the tools fails.

5. What is emma and what is its output?

Emma outputs statistics about which lines of code were executed and which ones were skipped. Breaks down the statistics by package and source files.

6. What are the 3 prime directives?

1. The system accomplishes a useful task.
2. An external user can successfully install and use the system.
3. An external developer can successfully understand and enhance the system.

7. What is the GNU project?

It is a Linux based open source operating system which strives to function with open and non open source software.

8. What are the difference in implementation of automated and manual quality assurance?

Manual: Actual writing of tests cases with JUnit, manually reviewing source code.
Automated: Uses coverage tools (CheckStyle, PMD, ect) to run tests on code.

9. How do you download someone else's code from Google Hosting?

Under the "Source" tab on Google Hosting you have two options:
1. You are part of the project so you checkout the https:// link to be able to work on and update the code.
2. You are not part of the project so you download the http:// link in order to view and modify the code but not be able to update the actual hosted code.

10. Write the FizzBuzz program.

Code snippet - FizzBuzz on Snipplr

Hosting and Subversion

I found that Google makes hosting open source projects extremely easy. The hardest part of this assignment was actually learning how to get TortoiseSVN to upload my files to Google hosting. However after that it was all downhill and fairly simple.

Overall Results:

I was able to complete this assignment with out omitting any steps. I found that Google's user interface was very straight forth and easy to navigate and execute desired operations. Also I liked how Google Code Hosting has all the project information on one webpage ranging from the Wiki pages to the code for the robot.

Difficulties:

I found that it was hard to use TortoiseSVN to do the initial upload of files to Google Code Hosting. After watching the screencast for the week I thought that TortoiseSVN would have a similar interface for uploading as SmartSVN. However I found that there was so such interface and I had to fool around a little with TortoiseSVN until I finally figured out how to upload the files. In order to upload in TortoiseSVN you follow the same basic steps as SmartSVN in that you create a new folder and copy and paste the files you want into it. Then in TortoiseSVN you have to select the files and folders you want to upload (or the root directory would work too I think), right click and select the TortoiseSVN option. Then you have to click "add" and select the files you would like to add to the project. After that you can right click the root directory of the project and select the "SVN Commit..." button which will then proceed to as you to log in and then will upload all of your files to Google Code Hosting.

BlackMagic Code Site:

The BlackMagic site can be found here.

Robotesting

Creating tests for my robot was actually quite a difficult process. I ran into various problems which all revolved around me placing the test files in the wrong directory. These were easily solved by placing the files in the correctly location.

I created 2 acceptance tests, 1 behavioral test as well as 1 unit test. For my acceptance tests I pit BlackMagic against SittingDuck and Crazy respectively. For the behavioral test I made sure that my robot's first few moves are to the middle of the battlefield. Lastly for my unit test I made sure that the targeting method for BlackMagic was correct.

At first I found the tests hard to create as I have never done Junit testing before. However as I created more tests I became more comfortable with it. Unfortunately I was not able to reach the specified 6 tests due to the design BlackMagic. Because BlackMagic moves in a random fashion it is nearly impossible to test it's movements. Also the targeting is set to fire ahead of the enemy so it is hard to confirm that my bullets will hit every time. Lastly BlackMagic is very simple and uses very few lines of code which made unit testing even harder.

Considering that BlackMagic is such a random robot I believe that my tests were adequate enough to ensure the quality of my robot as I think that my tests covered almost all the possible inputs for my unit test and I ran multiple tests to confirm that my acceptance tests passed consistently (0% failure).

As far as emma goes in my BlackMagic file I used 100% of the methods and classes, however I only used 94% of the blocks and 93% of the lines. This was due to the fact that the lines specifying what to do if a enemy got too close were never executed. As for the test files, all of them were at 100% for all categories.

If I were to redesign BlackMagic to make it easier to test, I would change its movement from random to a pattern form and also I would add in a more extensive response for when an enemy hits BlackMagic. This would allow for more methods to unit test as well as a more rounded robot.

The current distribution for BlackMagic can be found here.

BlackMagic Ver. 1.1.930

The first step that I did to create Ver. 1.1 of the BlackMagic robot was to use a build system (Ant) to run tests and error check it. I used the following commands to ensure my code was up to date and error free:

ant -f checkstyle.build.xml
ant -f pmd.build.xml
ant -f findbugs.build.xml

CheckStyle:

During my first run of CheckStyle I ran into the following errors:

Got an exception - java.lang.IllegalArgumentException: the name [date] is not a valid Javadoc tag name

Missing package-info.java file.

The 2nd error was easily fixed by copying and modifying the package.html into /src/smw from the DaCruzer package.

After fixing that error I ran CheckStyle again and encountered the following errors on multiple occasions:

'{' is not preceded with whitespace.
Missing a Javadoc comment.
'while' is not followed by whitespace.
First sentence should end with a period.
Unused @param tag for 'a'.
Expected @param tag for 'e'.

The spacing error and the Javadoc comment errors were easily taken care of. The @param errors were taken care of by adding in the input variable name to the @param comment. For example a method takes (onHitWall e) so the comment is too look like this @param e .... but my comments were formatted in the following way @param .... with out the variable name.

After fixing these errors I ran CheckStyle again and had the following error remaining:

Missing package-info.java file.

This was easily fixed by adding in the overview.html file to /src.

Upon running CheckStyle again I encountered no errors.

PMD:

Luckily PDM built with no errors.

FindBugs:

Just like PMD this target built with no errors.

Improved Performance:

After loosing in the 2nd round of the Robocode tournament to a walls based robot and seeing how many robots were based on the walls model, I realized that I needed to integrate an anti-walls section to my robot. However this was extremely hard to implement given BlackMagic's current movement scheme, so instead I added a method which increased my victory percentage against walls, but I was still unable to consistently beat walls. My hope is that BlackMagic Ver. 1.1 will be able to beat other non-wall based robots more effectively.

Distribution:

The latest version of BlackMagic can be found here.

Competition Robot

Design:

The design for this robot's movement is stemmed from a math error that I made while attempting another design. At first I hoped the have the robot move to the top middle, then move down in a 45 degrees, turn around go back up and then go down the other side at a 45 degree angle, repeating this movement pattern until the end of the match. However due to a math error, I found that I could make the robot's movement erratic, so I decided to keep this design. The downside is that the robot will sometimes follow it's previous path, thus making it susceptible to being hit from shots that were fired behind it.

The shooting design of this robot is meant to hit moving targets. It seems that this robot is most accurate while making turns, however it does have an ability to hit targets on the run due to a change in turret's position. When up close with the enemy, this robot will fire, move back, turn and fire again then continue moving around the battlefield.

My robot named BlackMagic can be found here.

Victory:

This robot can effectively beat the following sample robots: Corners, Fire, SittingDuck, Crazy, SpinBot and Tracker. This is due to the fact that many of these are stationary, or the fact that the movement pattern of my robot is able to evade most of the shots fired and it was able to return fire with a high rate of success.

Defeat:

My robot is unable to reliably beat the following robots: Walls and RamFire. It seems that walls moves too fast for my distance shots to be effective and also the when my robot repeats it's movements it literally runs into bullets fired by walls. As for RamFire, my robot does not have an effective way to get out of being cornered by RamFire. If the battle is kept in the middle of the field my robot usually can win. However when the battle moves to the sides it usually gets trapped and RamFire is able to take advantage of that and finish off my robot.

Lessons Learned:

After analyzing the battles, I realized that I need a more effective strategy to deal with robots that corner or force my robot to the edges, where they can do huge amounts of damage. Also I learned that an inconsistent movement really works in evading fire from the enemy, however retracing the route that the robot just executed could have disastrous results as it may run into bullets that were previously fired by an enemy robot.

Sample Code Analysis

To better understand the samples provided with the Robocode package, I will be analyzing 8 sample robots in the areas of movement, tracking and firing.

Walls:

Movement: Regardless of starting position this robot will always face the the nearest wall with the least angle movement to face the wall. The robot will then head to that wall and move to the closest corner. From there the robot will move clockwise around the walls of the arena. If this robot hits another it will reverse, do a left turn then head to the nearest wall, move to the corner and continue moving along the walls.
Targeting: There is no targeting algorithm for this robot. Simply if a robot is scanned this robot will open fire on it.
Firing: The only criteria for firing is when a robot is scanned.

RamFire:

Movement: Movement is determined by the enemy robot's position. Once an enemy is scanned the RamFire will then move up to it and ram into it. In the case that the robot has moved, RamFire will follow it.
Targeting: The tank moves until it scans a robot then the gun is pointed at the enemy.
Firing: Firing is initiated once the RamFire has rammed into the robot it is targeting. Firing continues until the enemy moves.

SpinBot:

Movement: SpinBot moves in circles continuously in one spot.
Targeting: There is no targeting algorithm besides scanning.
Firing: SpinBot fires when a enemy robot is scanned.

Crazy:

Movement: This robot will move forward and turn right, but keep moving while making the right turn, then it will turn 180 degrees to the left while still moving, after that the robot makes a 180 degree right turn while moving. This process is repeated forever. When it hits a wall the direction is reversed.
Targeting: There is no targeting algorithm besides scanning.
Firing: Crazy fires when an enemy robot is scanned.

Fire:

Movement: This robot only moves when it is hit in which case it makes a right turn and moves 50 pixels the first time. With each hit the amount moved decreases by 1 pixel.
Targeting: There is no targeting algorithm besides scanning.
Firing: If Fire has more than 50 energy and the enemy is less than 50 pixels away, the robot will fire at power 3, else it only fires at power 1.

Sitting Duck:

Movement: This robot doesn't move.
Targeting: This robot doesn't target other robots.
Firing: This robot doesn't fire on enemy robots.

Corners:

Movement: Regardless of the robots position, it will turn to face the north wall, go to the wall and make a left turn and move all the way to the top left corner.
Targeting: There is no targeting algorithm besides scanning.
Firing: Corners fires proportional to the distance of the enemy or current energy level. In the first case if the enemy's distance is less than 200 or the energy level is greater than 15, the robot will fire at power one. If the enemy robot's distance is less than 50 Corners will fire at power 2. Otherwise the robot will fire at power 3.

Tracker:

Movement: Tracker's movement rate is determined by the enemy that it is tracking. Once Tracker finds an enemy, it will move to 140 pixels of its position and either wait or fire on the enemy robot. Also if the enemy is too close (within 100 pixels) Tracker will move back in the enemy has a position of less than -90 degrees and equal or less than 90 degrees. Else it moves ahead 40 pixels.
Targeting: Once the enemy is scanned the gun will move to face the enemy. It will re-rotate every time Tracker is tracking an enemy.
Firing: The gun will always fire at the power of 3.

Conclusion:

I think that a lot of basic structures for movement and tracking can be learned from these sample robots. I know while designing my robots I would often look to these sample robots to gain inspiration or to review and adapt algorithms that were used.