I’ve been getting into a routine of testing, re-writing and bolstering everything over the past week or two. This is in direct contrast to my usual routine of writing massive blocks of code without testing, then firing it up and watching it fail in multiple places, then lose the will to continue (something perhaps familiar to many developers) – so this time making sure every routine is working efficiently and giving me verbose feedback in every possible situation has been high on my priority list.
Tonight I implemented error codes and matching error messages – boring I know, but it’s just one of many steps I’ve taken to make sure I know when things aren’t working, and to make the client/server architecture as bullet-proof as possible. All this work at the front-end is to make sure that when the server’s launched, it’ll have a really easy to use API. One of my major goals after all is to make this an ‘open’ Chaos server, and invite front-end developers to produce their own ports for various platforms – indeed it should be very possible to write a front-end for a Spectrum using the same graphics, sounds and so on!
One of the other things I’ve implemented is a step-by-step list of actions for each game. The stored game data contains a current snapshot of the game, active players, unit positions etc – but it also now contains a blow-by-blow account of the entire game from when it’s created, as players join and then start playing. Clients will then be able to store a timestamp (returned from the server after each action they perform) and then put out polled or long-polled requests for updates from the server, quoting that timestamp. Once the server processes new actions, it can return those actions to the requesting client in the correct order (so for instance, if a player moves their wizard in the first turn, the server automatically advances to the next player as they no longer have any units to move – this logs two actions, a unit movement and then a “next user’s turn” action). Clients may choose to return actions from any timestamp, so as long as the client knows when it last got an update, it can always stay in sync. The client may also optionally request all the actions, in effect providing a way of replaying an entire game, or it can just request a ‘refresh’, which sends the client a snapshot of the game as it stands, with all the data it needs to resume the game from scratch.
Here’s an example of a typical update:
{
"response": {
"success": [
{
"id": 8,
"action": {
"turn": 3,
"currentPlayer": 0
},
"time": 1324168638420
},
{
"id": 9,
"action": {
"moved": {
"id": "wizard_0",
"from": {
"x": 3,
"y": 5
},
"to": {
"x": 4,
"y": 5
}
}
},
"time": 1324168655828
},
{
"id": 10,
"action": {
"turn": 3,
"currentPlayer": 1
},
"time": 1324168655828
}
]
},
"currentTime": 1324168722155
}
So far, I have a very solid base – board sizes and player counts are limitless and the server will automatically position wizards in a ‘Chaos-like’ arrangement around the board, regardless of size, shape or number of wizards, or at least up to 8 wizards, after that I need to write a routine to automatically space them – probably via some kind of circular distribution. Although spell casting isn’t yet implemented, units are and can be created by manually editing the game data – so I’ve had a wizard and his hydra happily moving around the board to my infinite satisfaction.
Next to be done is the combat routines – which will lead to the invariably sticky (though hopefully MUCH more manageable) death routine, which is always a bit of a pain with Chaos. Remember, some units die, some units disappear, some units (wizards) disappear and trigger a player defeated routine, blobs engulf, magic fire destroys outright and leaves no corpse, wizards on mounts if attacked by units lose their mount, but if overrun by magic fire disappear and trigger a player defeated routine and so on and on.
Plainly remaking Chaos is not as simple as it seems.
