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.

So You Think You Can Robot?

Today we will be reviewing some sample robots included with the RoboCode game and looking at what makes them tick.

We will be evaluating: Walls, RamFire, SpinBot, Crazy, Fire, Sitting Duck, Corners, Tracker; on these three criteria:

1. Movement - How they heck are they moving? Crazy randomness or controlled chaos?

2. Targeting - Which way are they looking? How do they find their next prey?

3. Firing - Fire at will! How do they fire? Unload all your ammo and pray no one is left standing?

Walls

First up we have walls, a very simple robot. The first thing it does when it begins is to turn to the wall closest to the direction is it facing; meaning even if the wall is one pixel away from it, if it is facing in the other direction it will go to that side instead. I am unsure of the coders reasons for doing this, but it does save valuable time turning. After reach a wall it will travel around the battle field in a constant circle from corner to corner.

This walls robot does not have actual targeting. What it does is use the radar as attached to the gun, and fire as soon as the gun is aligned with another robot. The gun is always point out at the battle field, so it will fire once as it lines up with a target horizontally or vertically, and then again when the robot turns at the corner because of the shift in the position of the gun.

One thing I noticed is that this robot will stop and fire continuously at another robot that is blocking it's path, only if the gun is currently facing in that direction cause by the arc of a corner turn. Meaning this will only happen in a corner. Other than that, if your robot moves and doesn't stick to the sides, this robot is not very effective. Against a stationary opponent though, it is super effective.

RamFire

RamFire is a interesting a unique robot as it is on a suicide missions. How this robot works is it chooses a target and then SLOWLY rams into them. In RoboCode, collisions between two robots cause damage to both parties. It will keep moving up against its target, "Ramming", them for damage.

Targeting is done by a simple scan from the turn of the gun and body. Once it scans its first target and rams them continuously. My tests show that it does not track, but goes for the first scanned target, if its current target moves out of the way in time, it will begin scanning again for something to ram.

To avoid killing itself in the process, RamFire begins bombarding its target once it has made contact with them. In RoboCode, you score points and regain energy on successful gun hits.

Again this robot is quite effective against a stationary target or one that stays in the corner and can become trapped. Other than that move of my simple movement robots, as long as they do not stop can usually avoid getting caught by RamFire.

SpinBot

SpinBot is a very simple robot that I actually borrowed some code on when doing my own spinning movement. SpinBot moves in a circle and that is about it. Looking at the code, the robot is taking a very hard right while flooring the gas and never stops.

While rotating in this circle, any time the gun lines up with another robot, it will fire a shot at it. It is kind of simple is does ok against some robots as the circular movement avoids many shots, though due to the small radius of spin it sometimes runs into the bullet anyways as it makes a full circle, and then it is also a easy target for robots such as RamFire.

Crazy

Now here is an interesting robot. They name only gives us a small hint at what this actually does. The Crazy robot is designed to move around in a crazy fashion. What? I had to take a look inside the code to understand for myself what the heck was going on.

The Crazy robot's movement is designed in a very simple three step manner. It turns 90 degrees one way, then 180 the other way, then 180 again the other way, all while moving forward or backwards. On wall hits or being hit, it will reverse direction. This gives it a very random move path because there are many collision events and each time it will respond but moving around in a circular 180 degree fashion.

There is no real targeting like with many of the above robots, what Crazy does is fire on the scan of the gun with another robot. Very simple no tracking involved.

Overall Crazy is a very evasive robot and survives a while even against the more aggressive robots.

Fire

Fire is a very simple robot and is something that we have programmed before. Fire is no movement. It is stationary and rotates it's guns to scan for targets. Upon scanning a target it will stop turning its gun continuously fire until the target is destroyed. Fire turns its gun in a clockwise fashion so it has minor tracking ability if you are moving in a northern or north eastern path, but will lose its target and start firing on a new one if you move counter clockwise around it.

Overall very aggressive but does not work well against mobile and other aggressive robots who have mobility.

Sitting Duck

Like the above Fire robot, Sitting Duck is also a robot that we have made before. Having none of the three elements we are looking for, sitting duck basically is a stationary target practice, or a road block.

Corners

Corners is quite a good robot, but interestingly very simple. I had heard that it was one of the tougher robots. Upon testing, it is mind boggling how simple it is and yet it is very powerful.

All Corners does is picks one of the corners to go hide in. It moves to the sides and the into the corner on start. If by chance that it is destroyed in the current round, it will remember that is choose a different corner the next round hoping for the better.

Firing on Corners is very simple too. It is set to fire on scan from the gun, so it will fire if a robot moves directly in front of its line of vision. Once in the corner it will rotate the run back and forth between the angles that its back is not against. This allows it to fire at a more rapid pace and avoid needless scans. I though it was very effective that it did not scan areas it knew had no enemies.

Tracker

Tracker is the only robot to have a lock and track movement out of the other seven reviewed. It is similar to the tracking robot that we have programmed. It rotates its gun to scan for a target. One found it will lock on and move to within a set distance.

The targeting like most of the other robots, consist of turning the gun around until the object is scanned. To keep track of a target, it will store a targets name and check to see if a scanned object is the currently tracked target.

Firing for Tracker is a simple, when it is within a set distance fire at the target. Upon testing, I found it to be extremely ineffective. Since it only fires at a target at a certain distance, it is very easy to miss a constantly moving target. I also found that it has a hard time catching up to a target that is constantly on the run.

I was able to defeat Tracker using a movement only robot that goes runs to the corners. Tracker wasted energy by missing all its shots and then running out of energy before every getting the chance to get close enough.

Battle For Supremacy

As a final battle after testing and reviewing each of of the samples separately, I decided to have a little fun and throw them all into a giant battle. Surprisingly, the top place robot were SpinBot and Crazy. The circular movement robots. I had initially thought the robots utilizing the corners and sides where there is less threat from behind would win, but the circular movement of the robots allowed them to avoid fire from all sides.

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.

The Robocode Experience

For the past week, our first real java project in class was to familiarize and try our luck at at RoboCode.

What is RoboCode you may ask?Well, Robocode is an Open Source educational game started by Mathew Nelson. You build small tanks that are thrown into a battlefield where they battle it out until one is left. The catch is that each tank has to be programmed in java by you.

After installing the open source game, we were assigned simple design tasks for basic movement, tracking, and firing. The tasks ranged from simply doing nothing, to having tracking software installed onto your tank.

While it is fun to play around with, anyone learning java can greatly benefit from creating a few robots. After about a year of learning new programming languages, I too, have to admit my java was very rusty. After spending a couple hours on RoboCode, memories of searching through the java API and creating insanely complex loops and methods only to find out there was one in the API, came rushing back. An uneasy feeling rose up in my stomach as I instantly knew I was going to be getting very little sleep this entire semester.

I was able to start slow, learning the basic methods involved in moving and turning the tank, but some of the later movement specifications were no simple task. It required you to think about the positioning of your tank for different orientations and adjust accordingly. In one of the movements, I found myself making a different test case for the tank’s relative position to the center of the battlefield, and which way it’s gun was facing. Throw obstibcles in front of that and you’ve got yourself a thinker.

If you want to take a look at my completed (12/13) Robots, download themhere.

One of the hardest problems I had was having to use complex math to allow more elegant movement. One of the robots, which I was unable to finish was a robot that would move from one corner to the opposite corner, which was more complex than I initially though. In the game itself there was a sample robot that would move to corners by first moving vertical then horizontally. I had implemented something similar to this, but then after some discussion with other friends, we agreed that it did not hold up to the true task for the movement, which was to be able to move diagonally from one corner to the next. This seems somewhat simple in math, though my worst subject, it requires just a bit of trigonometry. Drawing things out on paper or even in the air can help many times. It helps you visualize your objectives. On paper is sounded simple, use the position to make a triangle using some trig functions and you’ve got yourself a direction, but trying to implement it in java still causes me many problems. This was in fact the only one I was unable to complete.

This was an overall good exercise in java. The real challenge lies in creating an actual competitive robot. Implementing creative movement patterns and attack strategies may require a lot more planning, and much more complex math. We can build upon the smaller programs that we have made, much like our experiences with java programming. Always keep good code in case you ever have use for it in another.