←

As I continue writing convienience classes for my Chaos project, I’ve put together something which (with a bit more testing) would be very handy for general AS3 development. It’s a simple to use class for querying an array of objects and returning the results as a new array. You can use it to recursively filter the objects by their properties until you have the ones left that you want – and yes I know about Array.filter but it’s much more usable and cleaner than that!. I’m using this to allow easy access to the units on the board (and I’ll more than likely be using it for the spells and other data structures in Chaos) – but as it’s a very universal piece of code, I think it deserves a place on its own. Keep your eyes peeled in the coming days!

Last night I began to put a polish on the classes I’ve been labouring over for the past few months. The reason I’ve been labouring is that I’m trying to write this game in a way that makes netplay easy to implement. One of the biggest hang-ups has been on the role of a server in the whole thing, and how the data gets to and from it.

A big problem with HTTP and subsequently most of the technology designed around it is the lack of persistence. Simply put, when you visit a webpage, the server will fire up its processing engine, initialise all its variables and objects, read stuff from the database, process your request, then clean up after itself. This is fine for 99% of the things you’d do on the web, but when making a semi-realtime game run over this system, it becomes horrendously inefficient. By contrast, most games will load all the data into memory and it remains there in a persistent state, occasionally being altered by the course of the game.

So, if you want to make a game that runs online, you have an extra layer of complexity to think about in that you have to ‘serialize’ the game’s state into a format that can be sent over the internet to the server, then the server will ‘deserialize’ the data, process it, save it to its database, and serialize a response to send back. There are a few APIs available which handles these sort of operations quite well, but it’s still a complex thing to monitor.

Of course, you could do away with the server altogether (although this isn’t usually an option for a web app), or reduce its task to simply routing the data to wherever it needs to go. There are a few big problems to tackle with this however:

1. Cheating – without a server, this means every client is doing its own verification of valid moves etc. Someone could fairly easily exploit this and send invalid moves.
2. Synchronisation – with no centralised game state to reference, clients could get out of synchronisation.

The answer to both of these problems would be to perform validation on all the clients, so that everyone’s client would have to agree the move is valid within the context of their stored game states in order for it to be passed. This has its own problems of course, as it’s dependent on latency and consistency between client versions, and may make the game feel slow and laggy.

So after much deliberation about how to do it, I think I’ve finally found a way to handle server-driven games. The abstraction between the game data format and the renderer means that I have a very clean set of objects to represent games. By recreating this in C++ or Java on the server side, and using JSON to represent the objects and their properties as they’re transmitted from client to server and back again, I can build up a persistent remote version of the game on the server. Once a game is running, I don’t have to worry about storing and retrieving the data across requests, which eliminates much of the overhead. So the sequence of events that occurs when a Horse moves from tile A to tile B is as follows:

1. The server tells all players that the game is in a movement phase, and tells player 1 it’s his turn
2. Player 1 selects his Horse and tells it to move to tile B
3. Player 1’s client works out the path to tile B (it’s more than one tile away so it requires the most efficient to be worked out)
4. Happy with the path, the client sends the server some data, namely the player ID, unit ID and each step of the path in sequence. It also presumes the move to be correct and shows the updated position (this is called client prediction, and is very important in online gaming to produce a responsive interface – the chance a move will be legal will be many, many times more than the chance a move will not)
5. The server receives the request and checks against its own version of the game to see if the unit can make this move legally; it double checks the path.
6. Having verified the move is legal, the server sends back the player ID, unit ID and its final position.
7. Player 1’s client receives the validated move.

Of course, if the move is invalid, the server will send back a rejection, with the player ID, unit ID and its original position as defined on the server. The client will then move the unit back and display an error. It should be noted that invalid moves will be next to unheard of as long as the server and clients are functioning correctly, and are there essentially to combat cheating.

Finally, to combat disconnections or to simply allow the game to be played over a long period of time and over multiple platforms, the server can send an entire representation of the game to the client to get it up to speed.

In closing, it’s a lot of effort to get a game to work over the internet, but it’s worth it to be able to live out that long held fantasy of playing Chaos with your mates – no matter where they are…

I’m now officially on the war path with my Chaos remake; I’m chasing Julian Gollop, and I’m spending a lot of time planning the details of the server. It’s proving to be easily the largest and most complex project I’ve ever tackled by a huge margin, and so I want to get things right from the beginning, rather than turn the codebase into hacks supporting hacks.

As a result of the work I’ve been doing lately, I think it’s now safe to ‘release’ the unfinished, somewhat buggy original Flash version that I did a while back. It’s no indication on the way the new rewrite is going to look (the interface is as temporary as it gets, for instance) but it shows some of the ideas I’ve had – not least being the move to an isometric viewpoint.

Two turns in and it's already going nuts - ah I love Chaos!

Anyway, without further ado, here’s the link. There’s no real configuration, no multiplayer, and gooey blobs, magic fire and mounts can act decidedly strangely at times, and these bugs were the reason I abandoned this codebase – the main class alone had turned into a thousand lines of semi-procedural hacks!

Well, I have to say I’m utterly blown away by the iPhone. I can quite solidly say it’s the most useful object I’ve ever bought – more useful even than my PC if I’m brutally honest. I’ve not put the thing down since I bought it; whether I’m checking my email, checking out websites in a proper browser on a proper screen, finding a takeaway in Barton-upon-Humber, playing Geo-defense or Wurdle while waiting for food in the takeaway, or even simply controlling iTunes on my PC from the familiar iPod interface via Remote (which has subsequently put Winamp on the back shelf – the first prog to do so since Sonique many moons ago) it’s been a complete and utter revelation.

This has obviously inspired me into developing for the iPhone – which means I need several things:

1. A Mac – Oh dear. I shudder every time I have to turn to one of the studio Macs at work. Despite my new-found respect for Apple, Macs are still truly dreadful to use, primarily because of:
2. OS X Leopard – It’s an improvement over the older versions, that much is true – however it’s also still basically an unproductive and annoying departure from what is obviously the ‘first choice’ way that Windows handles things. Apple can’t swallow their pride or dump on their existing userbase by conforming and as a result I can’t see Mac OS ever being their star product.
3. XCode + SDKs – All 1.8gb of them. Yay!
4. An iPhone developer account – Yes, Apple don’t allow you to run your own code on your own iPhone without paying them another £59. You can run it on the iPhone simulator that comes with the dev kit, but you obviously want to see and feel it on the real hardware (plus multi-touch with a mouse is out of the window).

As you can see this could become a pricey proposition. I’ve got something in mind for the first three steps – but it looks like there’s no way around the ‘Apple app tax’, I’ll simply have to stump up the cash.

The app that I have especially in mind is Chaos Enhanced (which now has a new name, though that’s for another post and an ‘official launch’) – which although being server-based and written in PHP with JSON I/O, needs client apps. If I can make the iPhone client smooth, slick and nice, then I can translate some of the features into the Flash client – I reckon this is easier and more likely to result in a really polished interface across the board, instead of me having to shoehorn the interface from a 1920×1400 browser window into an iPhone’s paltry 480×320.

On a rather unrelated note, I’ve also been looking at MooTools – partly because of the absolutely excellent Quakenet Webchat I discovered the other day which uses it, and partly because they’ve recently released a new version. Turns out it’s a really impressive looking framework, which takes an altogether more pure approach to extending and un-browser-fuckifying Javascript. I found myself absolutely hooked as I flicked through the docs and demos and I’m really excited about using it in my next Javascript project. Of particular note is its OO system, which I kinda envy and wish other languages I use (see AS3) had a similar system as opposed to the clunky, ugly and confusing Java/C++ way of doing it. I know I’ll attract hate with that statement but really, see how MooTools does it – it’s a breath of fresh air and makes total sense!

Finally, I’ve (attempted) contact with Julian Gollop regarding the ownership aspects of Chaos though I’m unsure as to whether I’ll get a reply – he appears to be a hard man to find. Hopefully I’ll get a reply, as a few things are resting on it at the moment. More news in the coming days on what’s going on with the game formerly known as Chaos Enhanced.