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.