Turning Knowledge Into Questions (Update)

When reading to understand, it takes a while before the full concept is realized. You must first do the initial reading, taking a moment or two at difficult points, digest the material, then review. The real test to see if one fully understands the material is if he/she can create questions based on the reading that isn't easily found just by skimming.

This is just the case for this week's assignment for my Software Engineering class. This blog post contains 10 quiz style questions that will help me and fellow classmates study for the upcoming midterm. Each student will come up with their own questions and by the end of the assignment, we will have a diverse array of questions to study from.

Topics range from the initial FizzBuzz program, multi-tasking, Java concepts, Build technology, testing, Ant, and Configuration Management.

I will amend this post with the answers later on this week.
Answers are here!

Here goes:

FizzBuzz + Anti-Patterns
1) How would you test the correctness of the FizzBuzz program?
A: You essentially want to create a unit test that tests the boundaries and the conditions that print "Fizz", "Buzz", and "FizzBuzz", namely 1, 3, 5, 15, and 100.

2) What would be a Happy-path test for the FizzBuzz program?
A: Happy-path test would be creating a single unit test that would always test a single value, let's say 1, and always return 1, causing the test to always pass.

Three Prime Directives
3) How do the Ant .xml files in the robocode-pmj-dacruzer system satisfy the Three Prime Directives?
A: The build files included allow for automated quality assurance/distribution which is a very useful tool to alleviate the tediousness of importing foreign projects. The fact that it's coded in Ant and automatically downloads necessary libraries it needs to successfully "build" a system ensures that an external user can install and use. The .xml files are direct source code which users edit, and there's also the online API for Ant.

Coding Standards
4) You created the ultimate Robocode robot that can beat any opponent, why would ensuring your code be up to standards be necessary?
A: The ability to beat another robot does not ensure readability or the ability for another user to adapt code. When you need to isolate a specific portion of code to test, have you're code could be a mess and probably would have to re-structure you're code in order to do so.

Quality Assurance
5) Your code has passed automated tests Checkstyle, PMD, FindBugs, why are automated tests not enough to ensure quality code?
A: These sorts of tests are only ensure that you're program follows standards and runs. It in no way can test the validity/correctness of your program. You will need to create an array of tests to accomplish this.

Asking Questions, Getting Answers
6) You're having trouble getting your JUnit tests for Robocode to work in Eclipse. You keep getting the error "robocode.jar not found." Given this problem, write a question in good form, you may make-up any other specific details that will aid in the diagnosis of the problem.
A: Hello, I've been trying to get my unit tests for a Robocode project to work in Eclipse, but I keep getting the error "robocode.jar not found." I've tried searching the forums to see if anyone else has this problem, but so far no one has. I'm sure I've setup my VM-arguments correctly (-Drobocode.home=) when I "Run As". I'll greatly appreciate any help/insight. Thank you for your time.

Understanding Ant Code
7) Given the following Ant code from checkstyle.build.xml:



What does it do?
A: Creates a target for checking if "checkstyle" has already been installed, if "checkstyle.config.available" does not exist, then Ant will download the necessary files from "src" url into the "dest" folder giving it a timestamp.

8) Write a simple Ant statement that checks if the file robocode.jar is available in the path ${robocode.path} and give it the property robocode.available.
A:


Version Control
9) Given an example where pessimistic locking is preferred, then give another example where optimistic locking is best. What does this tell you about which Version Control System to use?
A: Pessimistic locking only allows a single person to checkout a file, and places a lock while until it's been checked back in. Optimistic locking allows for multiple check outs and only places a lock when a person check's it back in with updates. On web based project or a large development team, you would want simultaneous check outs to facilitate work, so Subversion might be the right tool to use. However, if strict updates need to be kept, and you're in a small team of maybe 2/3, pessimistic might be feasible, so Revision Control System (RCS).

Open Source
10) What's the different between Free Software and Open Source Software?
A: Free software doesn't need to make its source code available and modifying and distributing the program is not necessarily allowed. Open Source software makes it source code available and modifying and distrubting the software is allowed.

How did y'all do? ^o^

Creating a Google Home: StrafeNShoot Repository

When working in a software development team where a group of people are working on the same project, version control becomes a key element in maintaining the most current, up-to-date distrubution of a software. Constant updates have to be taken in account so that a developer does not end up making a change that has already occured.

For this week in my Software Engineering class, we learned about Configuration Management(CM) and Version Control Systems(VCS). We were to use a specific type of VCS, namely Subversion(SVN). Since the version of SVN is dependant on your Operation System, I used TortoiseSVN on my Windows XP. In combination with the previous assigments that dealt with Ant and Build, which made distributions easy to package, distribute, and unpackage, SVN allows access to an online repository for my Robocode project StrafeNShoot, and any modifications made to the StrafeNShoot project SVN updates and commits the actions to the online repository.
The online repository we have used is Google Code, Google's developer network of open source projects.

My personal Google Code repository can be found here.

It currently stores the most up-to-date version of StrafeNShoot, summarizes the robots strategy, and contains two Wiki pages that show the User Guide and Developer Guide. You can either download the .zip format of the distribution, or can Checkout the project using SVN.

Note: Anyone can Checkout the project Anonymously, but if you would like to be a Project Member and/or commit or receive update notifications, I will have to add your Gmail account to my project. If you would like to be added, feel free to e-mail the discussion group at robocode-etm-strafenshoot-discuss@googlegroups.com

Along with Google Code, I have created a Google Discussion Group for my Google Code Project. All updates to StrafeNShoot are automatically posted in the discussion for everyone to see (including non-developers). This allows developers and others to see updates that have been going on and where the project is headed.

This weeks assignment details can be found here.

I've completed all the tasks except the known issue of the codesite-noreply@googlecode.com to the discussion group. However, I did get a workout this and instead added my Google Code project URL, robocode-etm-strafenshoot@googlecode.com to my discussion group. Then add the group's discussion e-mail (robocode-etm-strafenshoot-discuss@googlegroups.com) to the Activity Notifications in the Admin Source page of the Google Project, this allows for the updates to be e-mailed to all the discussion group members.

The most difficult task I found was using SVN. After installing SVN, you don’t actually open SVN the program, but use the Right-Click menu in the repository folder. The order of steps to use SVN was unintuitive at first. After modifying any of the files in my project, I had to first "update" the repository, then “commit” the actions. Remembering/re-pasting my Google Code project is a slight pain, but manageable.

I did accidently activate the "Adult Content Warning" when creating my Google Group. I inadvertently checked it off thinking it said that "My group does NOT contain any Adult Content". I looked through Google Group's help site, but found that only Google Administrators are able to change my Content Policy. I've posted my request on the site hoping they'll soon change it. I learned my lesson in that I should read carefully before checking off options that involve “Adult” and “content”.

Google Groups help was also useful in looking for known issues such as codesite-noreply, and already existing cases of accidental “Adult Content” activation.

Verifying StrafeNShoot's Strategy: Failure

The topic for this week in my Software Engineering class was about building test cases using JUnit and verifying certain aspects of my robot, StrafeNShoot. The aspects in question for movement, firing, and targeting strategies.

Here's a quick recap of StrafeNShoot's strategy:

Movement: Moves in a four corners style, starting from the upper left, lower right, upper right, then lower left. I chose this movement pattern because although it doesn't seem random, it provides a good path for my robot to always be in motion.

Targeting: The gun is initially positioned at the rear flank of the robot as it moves. When StrafeNShoot sees another robot, it attempts to keep an active lock on the target, while still maintaining it's movement patter.

Firing: As long as there's an enemy in it's sights, fire at will.

The assignment details can be found here. We were to create 6 test cases, at most 2 of them could be acceptance tests, which merely checked to see if StrafeNShoot could consistently beat another robot; behavioral tests, which tests the movement, targeting, and firing strategies; and lastly unit tests, to verify that the output of these methods were correct.

Sadly, I was only able to create 2 out of the 6 requried for the assignment, 2 of which acceptance tests.

The easiest of the tests were obviously the acceptance tests, mainly because Prof. Johnson had already included such a test in his pmj-dacruzer file which was easily adaptable, but also there was no real calculation involved, nor did I have to modify the source code of StrafeNShoot.

When it came time to implement a test for behavors, I began thinking of how I could test if StrafeNShoot does in fact move to the four corners. I then realized there was no concrete test I could do that would test for this, as StrafeNShoot "attempts" to move in the four corners style. It's possible that throughout the entire battle that StrafeNShoot will never reach a corner, since the way I coded the movement, if StrafeNShoot runs into another robot, it immediately attempts to go to the next corner without reaching the one it was trying to get at.

As for unit tests, it was hard to think of a solid unit test that I could use. The main problem with the unit tests was that I could not find a way to directly access StrafeNShoots internal variables. The trigonometry I used to calculate to turn to a corner, which would have been an ideal choice to verify, was hard coded into StrafeNShoot's source code. And the only way for me to verify the angle was correct, was by using the exact same steps I used to calculate the angle in the first place. There were other issues such as verifing that StrafeNShoot would correctly calculate the angle to turn towards the enemy.

With my test cases seriously lacking, I can firmly say that my test cases do not adequately ensure the quality of my robot. Sure it has the capacity to beat other robots, but being able to verify it's strategy without actually watching the battlefield is a whole nother problem.

For my EMMA coverage, there isn't much to tell, overall my block coverage was 43% and line coverage was 55%. But I've uploaded the whole results, which can be viewed here.

When I first started working with Robocode, I had no idea that the analysis would get this deep, I thought that the only thing that matters was coming up with a unique strategy, and beating other robots. But now, even if you have a unique strategy, it can be a pain trying to verify the things it does. When I decided to implement my strategy for StrafeNShoot, I did not code in modules, or even think about refactoring certain pieces of code. It ran sufficient enough to not look twice. But after this week, it shows how much modules, organization, and coding with verification in mind can lead to a well documented, quality source code.

My distributed StrafeNShoot package with it's lone, 2 test cases, can be downloaded here.

"Building" Quality Code: An Ant Experience

Working with Robocode for almost a month now, you begin to see the tediousness of some of the tasks. Some of which include, waiting for a battle to end, making sure your code is up to standards, and importing another persons Robocode robot. The current topic for this week in my Software Engineering class is Quality Assurance and Build Technology. This past week I have become familiar with the build technology - Apache's Ant in combination with Apache's Ivy - Library-Level Dependency Management Tool, to eliminate the tedious tasks.

Together with Ivy's ability to download and store the necessary libraries, and the automated build technology that is Ant, I can battle, standardize my code, and package my robot for distribution, all without ever opening Eclipse or Robocode.

Although Ant is Java-based, the build files are written completely in the XML format which means 1) No Compilers and 2) Each file can be read as source code. By using Prof. Johnson's Da-Cruzer build, I adapted it to work with my robot, StrafeNShoot.

By using the following tools:

• PMD
• Checkstyle
• FindBugs
• jUnit

I can eliminate long hours of staring at code looking for any rules that might have been broken by using PMD, Checkstyle, and FindBugs tools. I also can eliminate waiting for a battle to end by creating a test to see if my robot can beat another by creating a jUnit test and asserting that it has done so. In my case, I adapted Prof. Johnson's jUnit test to assert that my robot will always beat SittingDuck.

The other tools such as "jar" and "dist" make it easy to distribute my robot so other's can easily extract and battle/examine my robot. Compared to the long and painful way of importing a new project into Eclipse, and making sure all the paths are set before you can Roborumble.

Once you get Ant and Ivy set-up, this is indeed an incredible tool to automate tasks. However, the initial set-up was not so pretty. The errors that I encountered were mostly from adapting Prof. Johnson's DaCruzer build. I had not replaced all instances of his initials with my own, and same for his robot name, therefore Ant was so kind to tell me what types of problems I had and I quickly made the corrections.

I did run into some Environment Variable problems. I kept getting a "Unable to find tools.jar" error message when trying to build. Ant also gave some feedback saying it was looking for tools.jar in "C:\Program Files\Java\jre6". After searching the web for solutions, I can across the solution at this thread: http://forums.sun.com/thread.jspa?threadID=757039 Essentially I needed to declare my JAVA_HOME variable to point to the jdk folder, and the folder itself, NOT the bin, and I also remembered Ant does not work well with spaces, so I relocated my Java file directly into the C:\. So my JAVA_HOME ultimately was defined as "C:\Java\jdk1.6.0_16".

When I finally got it to run, I did the all the tests as described by the assignment and ended up with just 1 error:

• Checkstyle - 1 error
• PMD - 0 errors
• FindBugs - 0 errors

I was amazed to read that my error was:

[checkstyle] C:\robocode-etm-strafenshoot\src\etm\StrafeNShoot.java:78: First sentence should end with a period.

My first sentence of the javadoc was missing a period. Something so simple, yet hard to spot, the Checkstyle tool found it in 3 seconds. The fact that I don't have to use a resource heavy IDE like Eclipse to run these tools, and can do so easily with just the command prompt, I find these tools extremely helpful and efficient. Not only can you check the quality of your work, but you can also fix your code so that it is quality based on informative feedback. Although it takes effort to set-up, once everything is set all you have to do is invoke a simple command and Ant will do the rest. =)

My automated packaged, version 1.1 StrafeNShoot can be downloaded here.

Enter StrafeNShoot - My First Competitive Robocode Robot

After two weeks of introduction to Robocode, it was time to create a competitive robot. Even looking at sample robots and collaborating with fellow classmates, it was hard to find a place to start. What type of movement, targeting, or firing strategies will be effective against other robots? For starters, it began with developing a single robot that can counter as many of the following eight sample robots: Walls, RamFire, SpinBot, Crazy, Fire, Corners, Tracker, and SittingDuck.

---

After much toil, I implemented this strategy:

StrafeNShoot
(Source code)

Movement: Essentially uses the 4 corners movement as a method of getting around the map. Starts to go to the upper left, and then lower right, upper right, lower left, and back to upper left; going in a perpetual cycle throughout the match.
Targeting: As it moves to each corner, the robot tries to keep the gun pointed either at the center of the battlefield, or at the enemy.
Firing: As soon as it sees another robot, it will reposition the gun and fire with a power of 2. I used power of 2 because throughout trial runs, the points gained outweighed the energy used. However, when it gets shot at or collides with another robot, it will immediately realign the gun and shoot with a power of 3. Since the robot is moving most of the time, it was difficult for other robots to hit, so it was feasible to use maximum power.

---

Trial Runs:

Consistently Defeated: RamFire, Crazy, Fire, Corners, Tracker, SittingDuck

I noticed that with my strategy I had an advantage over stationary/tracking type robots. Because my robot moves at drastic lengths from one side of the battlefield to the other, stationary type robots will continually keep firing and missing; expending their energy and ultimately disabling themselves.

Tracking type robots have a hard time repositioning themselves. By the time they reposition and start moving to my location, I’ve already moved onto a different heading and the tracker is just trying to keep up. Meanwhile I’m firing as I’m moving to each corner.

Although Crazy is neither a tracker nor a stationary robot, its random movements work to its disadvantage, often times it runs into my bullets, and since it only shoots when it sees a target without any type of tracking, my robot will have moved on by the time it fires.

The Troublesome Two: Walls and SpinBot

Examining all the sample robots, it was hard to come up with a solid movement strategy. Robots such as Crazy, SpinBot, and Walls, make it hard to create a standard pattern of attack, even tracking their movements makes it difficult. When it comes to these two robots, my win/lose ratio is about split 50/50.

For Walls, the initial placement of the robots seems to play a significant role. When the robots are initially placed, sometimes my movements are exactly in-line with Walls so every time Walls fires, my robot will get hit and the converse is the same. Sometimes Walls’ movement is in-line with mine, so every time I fire, Walls will get hit.

For SpinBot, because it keeps moving in a circle, it can seemingly dodge all of my shots. Sometimes I’ll run out of energy just trying to shoot at it, or at rare occasions I’ll collide with it and I’ll fire at maximum power to take the win. Also, at times SpinBot will use up all of its energy just trying to shoot and I’ll take the win when it becomes disabled.

---

Here are my final results, 100 matches for each of the 8 robots:

Walls: score percent: 53; 47 wins; 53 losses
RamFire: score percent: 57; 77 wins; 23 losses
SpinBot: score percent: 53; 53 wins; 47 losses
Crazy: score percent: 68; 65 wins; 35 losses
Fire: score percent: 84; 97 wins; 3 losses
Corners: score percent: 83; 100 wins; 0 losses
Tracker: score percent: 82; 98 wins; 2 losses
SittingDuck: score percent: 100; 100 wins; 0 losses

---

Lessons Learned

During the creation process, I came across many contradictions. What worked to defeat one did not work against another. For predictable movements, it seemed that a blunt strategy like RamFire would be a sure win. But for robots with completely random movements, the only way to combat it was to move randomly as well.

Creating a single robot that could defeat all eight of the sample robots would be no easy feat, and by doing so would increase success in real competitive battle. However, the only way to test it out is to put it in actual battle. Talking with a few classmates, I found that I could easily defeat a specific sample robot while theirs could not, and vice versa.

When I was designing my robot, I was only thinking of survivability. Meaning, I thought that if I outlasted my opponent I would win. However, survivability is only one part of your total score. Even if a robot is defeated, it can still out rank your opponent, so even a blunt robot like RamFire can still out rank you because it will gain a lot of ram points. I will keep these things in mind when I make upgrades to StrafeNShoot.

Trial Version Robots: Learning Simple Behaviors

In order to create a competitive robot jutsu I need to come up with a baseline for my robot design. The robots that I have previously coded was an introduction to Robocode, in order to become familiar with the basic Robocode mechanics. For a robot to be competitive, it should have strategy and countermeasures. Although I need to look at this more in depth as I progress with Robocode, looking at the pre-packaged Robocode Sample robots will hopefully shed some light on creating a competitive robot.

In this blog entry I will examine and offer my thoughts on 8 of the sample robots, these include; Walls, RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, and Tracker. For each robot I will evaluate criteria based on:

1. Movement: How does the robot move? Does it have an avoidance or following strategy?
2. Targeting: How does it find a target to fire?
3. Firing: What is its criteria for firing?

Robot #1: Walls
Movement
Operates a very simple movement strategy that goes to the nearest wall, and just traces the wall. There is no follow strategy as this just traces the outline of the stage.The only avoidance strategy this robot exhibits is if it runs into another robot, if just reverses direction 100 pixels, and changes back to its original heading.

Targeting
Keeps gun perpendicular to the wall at all times. Only sees a target if one passes in the direction of its radar.

Firing
Fires with a power of 2 at any robot it sees.

Robot #2: RamFire
Movement
Probably the most blunt robot in movement. Rushes towards any robot it sees to point blank range in an attempt to ram it.

Targeting
This robot just rotates its whole body until it finds a target, does not go for any specific target or hold any targets in memory. Once it looses track of a target, has to swing its whole body to find another target. This is very inefficient since the robot is moving its body to scan, it will take a longer time rotating rather than just using the radar.

Firing
After it rushes to point blank range, fires the gun once it rams into another robot. The power of the shot is proportional to the enemy’s energy level. Essentially tries to out damage the target by ramming and shoot at the same time.

Robot #3: SpinBot
Movement
Spins in a clock-wise circle…that’s it. No avoidance or follow strategy whatsoever, but probably the most mesmerizing to watch. However, it does make it hard for other robots to shoot at it since it's in constant motion. Robots that are stationary have the hardest time against this robot.

Targeting
Keeps gun stationary at all times, only sees a target if one passes in the front of the radar.

Firing
Shoots at any target it sees, still going in a circle. Fires the gun as maximum power, so waiting for the gun to cool down to shoot again can be a problem if faced with multiple targets.

Robot #4: Crazy
Movement
Erratic and somewhat unpredictable movement. The robot makes a series of right and left turns as it moves ahead. If it hits a wall, reverses direction. This robot makes it hard to target as it keeps moving. I want to note that this robot is an AdvancedRobot, as coding an erratic behavior in a normal Robot would be difficult.

Targeting
Keeps gun stationary at all times, only sees a target if one passes in the front of the radar. This can be a problem if crazy is being followed as it can't see behind and even when it reverses direction, it doesn't turn around, just backs up.

Firing
Shoots at any target it sees, while in its obscure movements. Relies on the fact that a target will be seen, even while moving in obscure motions.

Robot #5: Fire
Movement
For the most part stays stationary, but if a robot gets too close, it moves away. Extremely vulnerable to robots that constantly move, as this robot stays still.

Targeting
Does not target any specific robot, just has its gun spinning all the time. This can be very inefficient as losing sight of a target will result in the robot doing a complete 360 to look for targets.

Firing
Shoots at any target it sees while spinning its gun. Depending on the range of the enemy and current energy, Fire will shoot either at maximum power (3) or just normal power of 1.

Robot #6: Sitting Duck
Movement
Does not move…at all. It may seem like it's waiting for the perfect moment to strike, but it does nothing.

Targeting
A very pacifist robot as it does not target anything.

Firing
Again with the pacifism, does not use its gun or shoot in anyway.

**The Gandhi of all sample robots, just counts the rounds and battles it’s been alive.

Robot #7: Corners
Movement
At the start of first battle, moves to the upper left corner. Stays stationary once it reaches a corner. If it died in the previous battle, will switch to another corner.

Targeting
Once in a corner, the robot continually robots the gun to scan for any targets. However, it does make use of the fact that it's in the corner. The robot does not spin it's gun a whole 360 degrees to scan for an enemy, a maximum of 90 degrees is only necessary.

Firing
Simply shoots at any robot it sees. Uses power proportional to distance, the closer the enemy, the stronger the shot. On the other hand, if current energy is low (> 15) then will use just a power of 1.

Robot #8: Tracker
Movement
Follows the first target it sees and sticks to it until itself or the target gets destroyed. If the target gets destroyed, the robot will find another. If the target is 150 pixels or more away, the robot encloses to 10 pixels. If the target is too close it will back-up. I've noticed that an "efficient" tracking method is to get within only 150 pixels of the enemy, this will keep the target in a larger radar scope without having the gun go a 360 every time it loses track because it's too close.

Targeting
At the beginning of the battle, the robot will rotate its gun until it finds a target. Tracks a single target until itself or the target gets destroyed. If the robot comes into contact with another, it will immediately make that robot its main target, and back up a little.

Firing
This robot only fires at others that have hit it.

My Thoughts
After reviewing these 8 sample robots, I sort of have an idea of different countermeasures that I could implement for simple robots. Some robots are very situational, taking RamFire as an example. In a huge brawl of multiple robots where endurance is key, RamFire is probably not the best choice to throw in, but for 1v1 it would probably perform the best.

I'm still on the fence about tracking robots. Although it seems like a cool idea to track and hunt down a robot, having a 1 track mind isn't always efficient. The really weird ones like SpinBot, Crazy, and Walls I think perform the best overall out of all the robots I've evaluated. The fact that the Corners robot stays stationary is just begging to be mass targeted.

As these robots are "sample" robots and aren't meant for competitive play, they still give you an idea of certain elements that you would want and not want in a robot.

It's What's Inside That Matters - Even For Robots

When it comes to the battlefield, even the messiest coded robots can still win against a well organized and standardized coded robot. So why would someone even bother to create a standard let alone re-code all their robots to fit that standard?

Even if a programmer worked alone, where only he/she would be looking at source code, he/she would not remember every little detail that was changed. Quick fixes and minor updates that don't get documented properly could leave you scratching your head while you try to remember why you made the change. In a worse case scenario, you're working on a software team and you're colleagues can't figure out how or why your code works.

Taking a quote from The Elements of Java Style, "code that is written to style is predictable, robust, maintainable, supportable, and extensible." Even when programming for something like Robocode, this holds very true. Building a competitive robot requires numerous cases, for countless situations. So far, my 13 simple robots only take roughly 1 to 2 kb each and I have no doubt that a competitive one can reach anywhere between 10 to 20 kb. Although using an IDE like Eclipse to manage all code, and no matter how pretty Eclipse makes your code look (by color coding words), all it tells you is what it does, it's up to the programmer to document why it does it.

One comment I remember from my Prof. in the intro classes to ICS, and that's "comment as if the reader knows where you live." A very funny yet creepy way of remembering on how you should comment your programs, showing how if you don't properly comment your programs, they'll hunt you down. Though, creating a standard and using proper documentation allows others to easily understand the flow of not just your program, but any other. Modification becomes a breeze because you'll know what each section of your code does. It also serves as a reminder, if it's old code you probably won't remember certain details.

For this Software Engineering class, we also have our own ICS standards. Using our own ICS standards, Robocode standards, and Elements of Java Style, I have modified my simple robots to conform to these standards. Even though I had already commented my robots, after reading the aforementioned, I realized some of the documentation is wrong. It was a bit embarrassing to look through my robots only to find that what I thought was right was incorrect documentation. Some comments just said what the code was doing rather than why it was doing it, or something simple like using end-line comments were all over the place. Luckily Prof. Johnson released an XML document that has the basic formats in it that works with Eclipse. It won't properly document your code (haha), but it will give the code basic formats like proper spacing, JavaDoc format, and line lengths.

During modification, I would like to give credit to Kendyll Doi. He had created a very nice formula to augment the Robots firepower in Firing03 robot. This robot is supposed to use firepower proportional to the robots distance, so the farther away the robot, the less power it would use, and the closest, the stronger the fire.

My original formula looked liked this:

 fire(1 / e.getDistance()); 

But the battlefield is already big so no matter how close the robot is, the value of fire would almost always be the lowest.

Kendyll's take looked liked this:

 fire(3.1 - e.getDistance() / 1200 * 3); 

He worked out that with the radar's max distance at 1,200 pixels, he used a ratio between the distance of the target to 1,200. At a max distance of 1,200 the robot will shoot a minimum power of 0.1, and at close range, a power of 3.

My standardized robots can be found here.