←

For the last few weeks I’ve been adding in two very important systems to Archaos – namely real-time communications via TCP, and the use of a database back-end for the server. The first makes games much more responsive, and allows the server to inform connected players of actions as and when they happen. It will also pave the way for an exciting addition I have planned, which will (hopefully) combat the inevitable pacing problems that arise from typical turn-based games. If you want to know more about what I’m getting at, give this excellent article a read.

The database server, client and game server respectively.

The second addition is a solid database-driven server. Until now, as a temporary solution I’d been storing all of the game data in a single file. When the server opened, it read all of the users and games from this file, and then stored all of the data in memory. If the data changed, the server would periodically save the entire file back to disk. The server would only write the data to disk if it had changed, and only once every so often – this kept writes to a minimum. The solution was fine for small scale testing, but it would not have scaled up well – quickly consuming all of the memory in the server machine, as well as being difficult to manage.

Now all of the data is stored on a mongoDB server in essentially the same format. The game server is then only responsible for the manipulation of the data, and not the storage and management of it. The game server itself is relatively simple in its approach; when a user sends an action, it loads the game, determines if the action can be performed, and if so what the outcomes are. It then saves the changed game back to the database and sends the actions to all of the connected players (which it does via TCP). The game server never keeps games, users, units or anything else in memory for longer than it needs to check or manipulate it. There are no special objects or instances; every function works only on the raw data. I may introduce some caching to reduce database operations later but at this stage the setup is fairly efficient.

So, I have what I feel is a solid base now, I’ve got some of the actions in and working (such as creating, joining and leaving games, unit movement and engagement) and now it’s just a case of writing the client-side stuff for the remaining actions, adding in the spell system and then getting it out there for public beta testing!

Look out soon for another post on the spell system and how I intend to tweak it to provide a more balanced start to each game.

Over the last few days I’ve been planning, and then implementing the RESTful communication part of the server, and this has been built on top of Express‘s fantastic routing. The next few days will see me implementing the rest of the current game logic on top of this routing, using the HTTP GET and POST methods and simple URI schemes in order to provide any client with a stateless, efficient way of communicating with the server.

For example, a client could request ‘/games‘ from the server and receive a list of games, each with its vital stats (players, board size etc). A client can then request to see more on an individual game by requesting ‘/games/game01‘ for instance. A client can then finally choose to get the status of the game from a particular point via ‘/games/game01/update/20‘ which will return all the actions from action 20 and above, or alternatively the client can request ‘/games/game01/update/1325635230240‘ which retrieves the actions from after that timestamp. The server determines whether a request called for a timestamp or an action ID easily because of the huge numerical difference between the likely amount of actions in a game and the value of a typical timestamp.

I have also decided (for now at least) to focus on JSON as the primary format for data from the server – I had intended to explore other formats such as XML, BSON and MessagePack but keeping things in JSON seems to be efficient enough at the moment.

Once the server is returning everything correctly using this new URI structure, I’ll shift my focus to the client for a while, and get some of the boring stuff such as creating/editing users and access control sorted out. I’m being purposely very careful about having something solid and playable before I go and start with the spell phase, and all of the delightful things that brings with it!

As a little bit of an aside to ‘the main project’ , I’ve been getting more familiar with node.js by forking a nice simple IRC bot project on github. At the moment I’ve just got it logging in an mIRC compatible format, and added some missing features to the logging, but in the future I’m going to extend it into a proper modular IRC bot.