Robocodes and Katacodes

There's a concept of kata that means practice and that some have interpreted as entailing "effortful learning". It seems to me that any kid of learning is usually effortful as long as the subject matter is challenging and the task represents a new type of task, qualitatively different from the concepts already learned or practiced before.

My experimentation with the concept of kata as software engineers have used the term, consisted of trying to accomplish 13 tasks in RoboCode. The tasks are outlined below. But first a brief digression on what Robocode actually is. It is a simulation framework that allows software robots to "fight" against each other. The robots represent and are rendered as battle tanks on the screen, and competitors and programmers get to program their own robots to act independently of human input once a battle has begun. The objective is for a robot to kill all other robots in a battle by using movement, radar, and shooting.

The Robocode framework is rich and includes many useful method call for getting the bearings and distance of enemy tanks detected by radar, methods for moving, for turning the tank gun, and for turning the tank radar. The tank is characterized by a set of parameters determining its speed, gun turn speed, radar turn speed, acceleration, bullet energy maximum capacity, and several other physical factors that can make Robocode competition a fairly complex business with lots of tradeoffs, strategy and tactical considerations, and design choices.



Returning to the tasks, here they are:


1. Position01: The minimal robot. Does absolutely nothing at all.
2. Position02: Move forward a total of 100 pixels per turn. When you hit a wall, reverse direction.
3. Position03: Each turn, move forward a total of N pixels per turn, then turn right. N is initialized to 15, and increases by 15 per turn.
4. Position04: Move to the center of the playing field, spin around in a circle, and stop.
5. Position05: Move to the upper right corner. Then move to the lower left corner. Then move to the upper left corner. Then move to the lower right corner.
6. Position06: Move to the center, then move in a circle with a radius of approximately 100 pixels, ending up where you started.
7. Follow01: Pick one enemy and follow them.
8. Follow02: Pick one enemy and follow them, but stop if your robot gets within 50 pixels of them.
9. Follow03: Each turn, Find the closest enemy, and move in the opposite direction by 100 pixels, then stop.
10. Boom01: Sit still. Rotate gun. When it is pointing at an enemy, fire.
11. Boom02: Sit still. Pick one enemy. Only fire your gun when it is pointing at the chosen enemy.
12. Boom03: Sit still. Rotate gun. When it is pointing at an enemy, use bullet power proportional to the distance of the enemy from you. The farther away the enemy, the less power your bullet should use (since far targets increase the odds that the bullet will miss).
13. Boom04: Sit still. Pick one enemy and attempt to track it with your gun. In other words, try to have your gun always pointing at that enemy. Don't fire (you don't want to kill it).

So far, I've been able to accomplish all but tasks 6 and 9. The difficulty in task 6 is geometric. There seems to be no direct way of specifying movement along a circular trajectory of a certain radius. Moving perpendicular to an intended focus will produce circular movement with that focus as the center, but the size of the turning radius is given by a combination of the movement speed and turn update rate. Very small movement and a high turn update rate can probably produce the desired effect. Another approach is to discretize a circle into a bunch of waypoints (representing a polygon) and then travel from one waypoint to the next repeatedly.

I think my difficult with task 9 stems from an incomplete understanding of Robocode's event processing loop and how it goes about intermixing events (like ScannedRobotEvents) and a robot's run method instructions. This was complicated by alternating between extending Robot which uses asynchronous blocking actions and AdvancedRobot which uses synchronous non-blocking actions.

What this means is I'll have to go back and get the 30,000 foot view or Robocode's event model again, before I delve back into the low level specifics of useful method calls for accomplishing basic movement, targeting, and tracking.

The most difficult thing about accomplishing the tasks from a software development point of view is the absence of a methodology for objective testing and validation of the robots. Depending on the behavior of a robot on the field, a robot may achieve the desired behavior to a greater or lesser extent. The Robocode framework also seems to lack the modular structure that would allow unit testing of specific functions to validate their correct behavior independent of other functions. This is probably endemic to simulation frameworks since they depend on the active progress of the clock and the actors, but a limited capability to test trajectory and movement functionality would be very useful.