←

I’m happy (for now) with the performance I’m getting on all tested devices, and so I’ve spent the last few days on the units and visual tweaks. The coloured background is now back in (and more subtle, like the original concepts I posted before) and I’ve painstakingly redrawn each of the original creatures from the game, keeping as true to the originals as I can while injecting a bit more detail and colour variation.

Plenty for the blobs to eat…

One of the important factors for me is to give every unit a distinct presence. I’ve kept myself within a relatively small palette of colours, but tried to ensure that every unit is easily discernible. My first test had Hydras, Green Dragons, Gooey Blobs and to a lesser extent Crocodiles all looking very similar due to them using the same green. I’ve now varied the colours a bit to make the Hydra more yellowish, and given the Crocodile a tan belly. This will help when the board gets cluttered with units – especially given the isometric perspective which serves to make the board look even more hectic.

There are a few units I’m not entirely happy with at the moment – the Gryphon looks a little bit like a big goose or something, and needs to look more eagle-like. The Wall presented an interesting challenge and I decided it’d be best if I rendered it isometrically. I may yet do the same for the other large structural units too (i.e. Dark Citadel and Magic Castle).

The ‘classic’ unit set comprises 286 separate sprites, with separate sprites for left and right (because of the edge lighting always being on the right)  although some units end up with duplicates for various reasons; the Gorilla for instance, which looks the same from either direction – or the Vampire, whose cape blowing in the wind should always go in the same direction. An absolute godsend during this process has been TexturePacker – which has meant I’ve been able to quickly create, change and update a very optimised single sprite sheet with ease.

As well as these visual bits and bobs, the client now connects to the proper server (rather than a quickly hacked together server) and it can now manage multiple games. This means that I’m closing in on that first big milestone: a properly playable alpha version . Shortly after the game reaches playable alpha, I’ll be announcing my plans for beta testing.

I’ve done an awful lot in the last week or so on Archaos. Primarily the focus has been on optimisation, as it quickly became apparent that as3isolib was simply not fast enough for the job at hand. This led me to explore the possibility of using Starling, a fantastic 2D-on-the-GPU framework, which tries to remain true to the standard AS3 display list as much as possible.

This of course meant I had to rewrite my entire render stack from the ground up. Bummer.

After a few days of building and tinkering with my own Starling-powered custom and very lightweight isometric rendering engine, the frame rates began to climb and climb. Today, after reading up on it a bit more, I’ve managed to get the game pretty speedy.

A whole lotta dragons

Above is a 200×200 board (that’s 40,000 squares) with approximately 20,000 animated, interactive golden dragons nodding away at just under 5 frames per second on my (admittedly pretty powerful) PC. Now this kind of test is pretty unrealistic, but it demonstrates what the engine is now capable of pretty well.

I’ve included further optimisations such as clipping (items off-screen are not drawn, which speeds things up considerably) and making use of a single ‘Texture Atlas’ for all of the units (basically a sprite sheet – gives a huge performance boost).

I’ve deployed some tests to my iPad 1 and my iPhone 4S and they’re running pretty nicely on both (my iPad is pretty much past it now but still churns the game out at a good 30-40fps) which makes me very happy indeed – especially in comparison to earlier last week when I deployed the as3isolib version to my iPhone and it ran at about 2fps!

I’ve also added other little visual touches and niceties (such as units jumping/flying between tiles rather than just sliding across) and have plans to add some really fun little things to make the whole experience of wizards and creatures fighting with one another all the more satisfying.

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!

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.