One robot to rule them all

Alas, my robot project has come to an end. However there is still one more act in this play, the epilogue of my journey of which is called robocode. The name of my competitive robot is called RobotDevil because just like the real devil, you never know what (s)he is going to do, or not do... The inspiration of my robot was the idea of a snowflake. They say that no two snowflakes are alike, and I would like to believe that when a user runs RobotDevil, no two instances will behave the same. Without further ado, whose cuisine robot will reign supreme?

Overview 

If I asked you to pick a number between 1-10 and use that number as some sort of 'random' generated output, how 'random' would that be? The same theory applies to what I had attempted in my robocode project. I had set out to try create a robot that ideally will not win 100% of the time yet not lose 100% of the time either. A rudimentary coin flip of a robot would be my esoteric description. In essence I opted to build a robot that would display 'random' movement behavior, an optimal firing scheme and sophisticated tracking logic.

Design

Movement: Movement is the heart and soul of RobotDevil, since our movement paradigm is limited to the battlefield and 360 degrees of turning options, the 3 factors in movement for RobotDevil was the degree of the turn, length of the turn, and condition of a hit wall. The general strategy for moving the robot was to create unpredictable behavior, since most advance robots will attempt to predict RobotDevil's next movement. The only downside to this approach is that RobotDevil may not make the most logical decisions, such as moving towards an enemy bullet or walls.

Targeting: Targeting is relatively simple in the design of RobotDevil, once an enemy robot has been scanned by our robot, the robot will adjust the firepower to either the MAX_BULLET_POWER or 1. RobotDevil continuously sweeps the area by rotating the radar and gun 360 degrees.

Firing: Firing is simple since once RobotDevil sees another robot it either fires a weak bullet or the strongest bullet. The measure taken to anticipate the movement of an enemy robot was not taken since our movement is not predictable.

Results (Out of 100 rounds)

RobotDevil 2606 (14%) V.S. Walls 16575 (86%)
RobotDevil 17549 (52%) V.S. RamFire 16466 (48%)
RobotDevil 1867 (10%) V.S. SpinBot 17423 (90%)
RobotDevil 10136 (59%) V.S. Crazy 6993 (41%)
RobotDevil 20612 (68%) V.S. Fire 9593 (32%)
RobotDevil 15093 (51%) V.S. Corners 14241 (49%)
RobotDevil 2664 (12%) V.S. Tracker 19446 (88%)
RobotDevil 18020 (100%) V.S. SittingDuck 0 (0%)

As the results show, RobotDevil performed horribly against Tracker, SpinBot and Walls. Partly due to the fact that these robots stay at a distance and attack rather than approach other robots. I suppose one design improvement RobotDevil could use is a better tracking system. 

Testing
Majority of the testing was done to ensure that the movement of RobotDevil was truly random. So jUnit tests to check between two length in distances traveled are not the same. It is suffice to say that the tests were a good indicator of random movement but this brings me back to my original question of how random is random.

Lessons Learned
I felt that this robocode development experience provided myself with invaluable experience in jUnit and simple software development principals. It was a great introduction in testing practices such as behavior in code. Perhaps after seeing some of the robots developed by my fellow software developers, it will provide me with inspiration on possible future implementations in RobotDevil.