Built by Ants - Scavenger:ReTune

So I have a 70+% win rate against sample Walls, yet I have a 70-80% lost rate against a Walls traveling in the opposite direction. The irony hurts so much. Yet I still can't figure out how to compensate for both.

These past two weeks we have been learning about build systems. Using ANT we are able to build our robot, run some automated quality assurance checks, and even test our robots through junit.

Click here to see my the build system for my Robot.

I gained a lot of insight about how build systems work and I can start to see the powerful advantage it gives programmers. Just having something like check styles saves so much time. I had caught at least ten errors that I didn't know I had, though more than half was either me forgetting to add a period to my javadocs or not putting spaces in my "if statements". Then things like PMD and FixBug, can save a lot of time has headaches by automatically catching common errors and bugs in your code.

The first thing you notice right away is that we use a lot of xml. I first learned about xml in my ICS101 class. We watched a video in which they talked about how companies use XML to help their transactions. I never associated it with the programming that I've done up to only a few weeks ago when I was going through a program called OTCG, which is a networked open source online trading card game framework. Using these xml definition files you can create any card game you want and connect to other players online to play with them. The only thing is its very basic and you have to define all the actions yourself in xml definition files. The minute I opened up one of the build.xml files in the sample folder I immediately recognized this as something familiar, though I never really saw how it could be applied to something as grandiose as a build system.

The assignment had us adapting the sample code as a template to our own competition robot. It was a fairly simple task, I didn't run into any hiccups that was not cause by pure carelessness, which was me looking at an entirely wrong folder which was one character off from the actual folder for fifteen minutes.

Competition Bot - Scavenger: First Tuning

It's time to gear up for our first class competition of RoboCode. Over the weekend, we have been designing and tweaking our robots for war.

Lets take a look at the robot I've designed. You can download it by clicking here.

Name: Scavenger

Description: Circle the Enemies and FIRE!

Movement: Moves in a slight angle relative to a traget robot's position

Tracking: Track closely with gun and adjust heading to match target

Fire: Fire on stationary targets

I named my robot Scavenger because of the way it wins. It will move in a circular path around enemies waiting for them to expend their energy by dodging fire. The original design was to only fire after the enemies have become disabled. This worked for the most part, but winning is about scoring points and you are able to accumulate a huge amount of points, although less than surviving, by scoring hits. This also allows Scavenger to take down stationary robots that have yet to be disabled such as SittingDuck, and Fire.

One of the things I learned while fine tuning this robot was that each situation requires a slightly different approach. To win we must try to make our strategy as general as possible and then fine tune.

We were able to discuss with our classmates strategies against eight of the sample robots. In each strategies, I realized that although each strategy may work on one of these robots, it would never work on another. You can tell by the labels written on the strategies when it is labeled as, e.g. "WallsCounter", "SpinBotcounter", etc.

Even after coming up with a strategy myself, I found that, although I could beat one robot with it, I would lose or come very close to losing against a different robot. I knew my strategy was solid, but I understood that I had to do test runs to understand problems.

Erratic Movement Robots:

The only two Sample Robots that I was unable to defeat with over 50% success rate was the two AdvancedRobots. SpinBot and Crazy both extend AdvanceRobot allowing them to, along with other things, do simultaneous movement. Since my robot is based off the movement of the target, the erratic movements from the SpinBot and Crazy to lower the effectiveness of my evasive movement. I believe if I can devise a better strategy for wall collisions and tracking, I would be able to fine tune my robot to defeat even these advanced robots.

Problems

The Walls:

No, not the Walls robot that seems to take everything down, but the walls of the arena itself hindered my movement. Allowing the robot to turn to correct it self wasted valuable time and allowed others to get more hits on it. I finally opted to just back track a few steps. Since the robot's movement is based on the movement on the target, it will auto correct itself after backing away from a wall. Otherwise, on stationary targets it will provide evasive movement until they have moved or run out of energy.

Enemy Range:

The last problem I found was trying to get my circling movement based on my target and their range correct. I had noticed that with by turn radius 120 degrees I was easily able to beat sample Walls, but the large turn radius allowed Sample Tracker to get an upper hand. If I lowered the turn radius to 100 degrees, I would be able to quickly move around Tracker, but then the small turns was less effective against Wall's fire. After hundreds of test runs, I decided that it would be best to just make a minor compensation rather than adjusting my strategy. I opted to change the turn radius relative to the distance of the target. This fix allowed me to compensate for both near and far targets.

Robocode v2: Real Programmers Don't Comment!

We are once again back at our robocode basics, finishing up unfinished code and fine tuning it for review. Movement01 doesn't do anything, so what is there to fine tune?

The main task this week was to implement RoboCoding Standards into our code that conforms to the java standards set forth in our book, class, and RoboCode.

Click here to see my attempts at RoboCoding Standards.

Comments are easy right? We've been coding for years!

As we saw in class; everyone, even the most experienced java programmer, can admit to breaking one or two standards. Trying to stick to a hundred different rules for coding is like trying to write an essay in proper English. Everyone has a different style of coding, yet we want to have a unified style of explaining what we write.

Just going back and reviewing my code, I had found huge amounts of violations that I had always though was correct. I had come to the conclusion that I was either an idiot or that standards for commenting change over the years.

One of the big things I noticed was the enormous amounts of end line comments. It seems like such a rampant thing that I always see people do. Well code monkey see, code monkey do, and like everyone who's made the mistake, the fact that bad commenting habits spread is a very important reason that being careful to stick to a proper uniform style is useful.

Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.

An interesting quote I saw on a shirt the other day had me wondering why we comment our code. The main reason I give for having comments is to allow others who may look upon your code to be able to read and have a clear sense of what is going on. Not everyone is a genius and can speak code, and not everyone is a genius in that they can write a program from start to finish without needing someone to review it.

These standards are there to allow us to map out our thought process to other coders. This allows cooperation between two unlike minded people. If you can't understand where one person is coming from and trying to do then how can you ever possible understand how their code works. But if we can write it down in a way that you can ready, although you may not understand their code, you can see how they are trying ti approach a problem.

It is also helpful, I believe, to have a very consistent and uniform for style to coding that we can easily read through ourselves. By avoiding writing redundant comments, and avoiding using third person. It creates a better overall flow in the though process and understanding when you read your's or another's code.