Wednesday, July 2, 2008

Plan for Robocode 1.6.2

We just released Robocode 1.6.1 Beta for community testing. While we are waiting for at least one email with feedback (we really miss it), I will present detailed list of tasks for next version 1.6.2.

RobotPeer redesign - messages instead of shared state

Each robot has it's peer which takes care about the real truth about that robot. Things like energy, velocity, direction and also intentions (settings or commands) are stored there. Battle is reading them each turn and modifying according to rules. Robot is accessing that location using RobotAPI. This location is represented with class RobotPeer.
There are two problems currently. First is that both threads battle and robot's are accessing RobotPeer, so data there need to be synchronized. Current implementation does that per call. So subsequent calls could return different values. And as it is, we couldn't do any better, because bigger granularity could lead to deadlocks or at least to slowdown.
Second problem is that there is fixed cost per call for such synchronization from both sides, robot's and battle's.

What we plan is that we split RobotPeer class to two separate parts. First will serve to robot and second will serve to battle. They will be synchronized once per turn. Let's call first part RobotProxy and RobotPeer the second part from now on.
Great moment for such synchronization is when robot calls execute() method. As everyone knows, robot is blocked till next turn there. We could gather all settings and commands set by robot from last turn and make message from them. Then we could send such message to battle's part.
During processing of turn facts about robot are changed, also new events are produced. Such data need to be sent back to robot during resuming after call to execute(). That data will be merged to information set hold by RobotProxy. RobotProxy will serve as local cache for such info.

We may also wish to decompose hosting of the robot from actual battle logic.

Battle recording and replay - listener and producer

  • New version of independent class inside of BattleManager class, next to Battle class. May be called Recorder ?
  • Still controlled thru BattleManager and sending BattleEvents like Battle does
  • Recording should be implemented as IBattleListener
  • Replay will just feed dispatcher of BattleManager
  • Think about IBattleControl interface and where to put method for saving and loading recorded battles
  • Should be possible to go to any turn, and also rewind the battle etc.
  • Should be able to records robot renderings as well as print outs
  • Possibility of saving/loading the Replay to a file, e.g. XML

Introduction of interfaces of future modules

As preparation for modularization in 1.6.3, we could do some of the steps earlier. The difference is that in 1.6.2 we will not move implementations in namespaces and we will not break compatibility. My guess is that full modularization will need such non-compatible changes. I'm not talking about RobotAPI, but ControlAPI. So we might even need to release it under 1.7 version instead of 1.6.3.
It will be big change. So some of the work ahead could help us manage it better.

Low priority tasks - nice to have

  • OptionManager - components subscribe for changes in setup/options/configuration
  • Reduce complexity of TeamPeer, ContestantPeer, ContestantStatistics, TeamStatistics
  • Decouple battle save/load from BattleManager
  • Adding the music from Hans HiScore
  • ATW battle events dispatcher, single point dispatcher on AWT thread
  • Robocode log to window - not only to console but as well to GUI window

No comments: