ROC Hockey

As respite from soap-boxing, this week I have a technology demo that was built to provide a testing ground for some new technology I’ve been working on - state machines.

State Machines have long been used for embedded systems as a programming abstraction that provides a tight language for programming systems that have well defined modes. They fit a certain class of problems very well and can help provide robust solutions in scenarios where other approaches rapidly become riddled with corner cases and become difficult to test. UML state machines appear to be the front runner in this technology today because they combine the best of other approaches into a common model. Particularly the hierarchical and parallel nature of the UML machines manage the unbounded growth of definition when they reach a level of sophistication such as (using the common example scenario of a computer keyboard) allowing the caps lock key to be used independently of the num lock key. I was pleased to discover that the W3C have a fairly mature working draft of a State Chart XML (SCXML). A standard representation for the machines is essential for a tooling ecosystem to evolve. I did look at implementing the specification but there is a lot of non-trivial functionality hidden behind the surprisingly compact specification and, in the end, discovered that Apache have an SCXML implementation. The implementation is not perfect, for example it doesn’t readily allow persistence and restoration of state - i.e. the RESTful requirement that state can be transferred in and out of it that enables capabilities such as hot-switching of running machines and the capability of scaling instances beyond that which can be held in memory. But these things can be fixed and they have been. So we now have a nicely contained SCXML language runtime that can orchestrate sub-requests based on state changes. We will be releasing the state machine runtime soon.

So to the testing ground / demo. Some of you may know that I have a distant past in computer games. For a long time I’ve wanted to have a platform to bring two or more parties together in some (fun) way. Multiplayer games are the way to go. Let’s think about how to do this in resource oriented computing (ROC). In terms of abstract raw resources we’ll have a number of them:

1) one resource for each player registered in the game engine that holds their details and if they are involved in a game
2) one resource for each game that is active that contains the state of the game world.
3) one resource for the global game engine state that references all registered players and games etc.

So in this example I’ve created a simple two player game that allows any registered player to challenge another player who is not playing yet. The negotiation of the game start and lifecycle of a player is defined by this state machine:

State Machine Diagram Graphical representation of the SCXML is using SCXML Gui

Each player has a state machine that controls what events (requests) are responded to at any particular time and then what sub-requests which then mutate state are issued. Each player has their own state machine and they communicate with each other and the game engine via requests. I hope to present more details of the technical implementation of this later. There are still some patterns in terms of how to best abstract state that are in flux.

The front end of the game is provided by an HTML5 browser that talks using websockets to the game engine. The display is rendered using an HTML5 canvas. In the game engine a Java port of Box2d of Angry Birds fame is used to power the physics simulation. Communication between client and game engine is all using JSON. This game is just a demo. The approach to sending each frame update over web sockets to each client many times a second isn’t really a scalable solution to high frame-rate gaming - I know that. The latency and bandwidth requirements are too high.

Take a look - the demo “ROC Hockey” is hosted at http://carly.1060research.com:8081/rochockey - have fun!