verifying my robot manipulation

In this post I'm going to wrap up this second robocode series by verifying that my new design works the way I want it to and hopefully showing that all this work has paid off.

To review, here's a brief description of my design:

  • the run method is called on my robot by robocode
  • my robot first retrieves a robot engine from a service locator and passes itself to the engine
  • the run infinite loops begins and there is only one thing to do each loop: the robot asks the robot engine to ensure the world state is up to date
  • the robot engine processes any pending world state updates that have been stored by events
  • if there are no updates, this process finishes until the next loop
  • otherwise, it pushes the updated world state to each context translator
  • the context translators convert the world state into a new state for that bounded context
  • the observable situation (using rx observables) is updated
  • any observers with subscriptions that meet the new state come into effect

I have two observers at present, one in the decision context to write statistics out for my acceptance test, showing that the robot was not disabled at the start of the battle (and there are no terminal exceptions as a result of new code).
The second is a manipulation observer that looks for enemies when we have no focus.

As I cannot debug my robot through visual studio, I have littered areas of my code with WriteDebugMessage statements for this exercise so I can watch the turn snapshot window.

So to begin, here's the battlefield:

Verifying1

At the start of the battle, there's not much activity yet on turn 0 as expected:

verifying2

But moving onto turn 1 and there's a lot going on:

verifying3

The OnStatus event has been called and the robot is about to publish the world state update to the robot engine as a pending update.
The world state update is processed by the run loop and the robot engine starts pushing the state update to the bounded contexts.

The decision context translator gets the first update and updates the decision state keeper. This publishes the decision state via an observable situation. My only observer in this context waits for turn fifty, so it is not yet called.

The manipulation context translator now gets an update and this flows through to the manipulation state keeper. Again, the observable situation for this bounded context is updated and we do have an observer subscribing to when there is no focus (and there will always be no focus at present).
This "we have no focus observer" is responsible for pushing a command to the robot via the ImARobot interface to look for enemies.

Turn two occurs and we have some activity! The robot has issued a TurnRadarRight(360) and this radar scan has begun.

verifying4

For the next few turns, the turn snapshot window is a little quieter as the blocking call (because this is a standard robot) takes effect.
What is interesting is that as the OnStatus call still takes place, the world state updates are stored in the robot engine:

verifying5

So all of these stay as pending updates in the robot engine until the robot run loops kicks in again and we can begin processing again. This is exactly what the design called for and I'm very pleased with that.

When the radar scan is over, it all kicks in again, on turn ten:

verifying6

I still have no focus so the manipulation observer once again issues the look for enemies command:

verifying7

So it all looks to be working the way I wanted it to. I have a domain driven design model that is completely independent from the robocode library using the adapter robot to act as the anti corruption layer.
I have a command being pushed to the robot and my efforts seem to have paid off.

If you have been following this series, please let me know what you think about my experiments.

My next robocode series will look at making the robot do some more interesting things and expanding upon this design.



1 comments:

  1. Endy December 18, 2010 at 2:59 PM

    So until now you implement system.reactive by putting your robocode dll into GAC? There's no simpler way to use system.reactive with robocode?