http://www.youtube.com/watch?v=ptxZwwfQj9c

“for dust thou art, and unto dust shalt thou return.” – Genesis 3:19

In the not too distant future, the continued research into molecular nanotechnology yields an efficient way of creating self-replicating nanobots. Despite concerns over the ‘grey goo’ doomsday scenario now being within the realms of possibility, systems are put in place to prevent the uncontrolled replication of the nanobots. The engineering and medical uses of the technology become highly desirable as a tool to enforce national security.

The truculence inherent to biological life combined with the ability to commit large scale acts of destruction upon its enemies sees the human race enter into a colossal war. The war rages for decades, becoming ever fiercer. Nanotechnology finds its way into all sides, and the ruthless debilitating efficiency of the war machines is now only matched by the restorative technology keeping soldiers in the front lines.

An inevitable stalemate is precluded by the sudden mass use of nuclear weaponry by diminutive factions who become cornered by the nanotechnological superpowers. The resulting mutually-assured devastation wipes out most of the life on the planet.

The military-grade nanobots produced during the war are not as easily defeated, being less susceptible to the radiation that destroys the DNA of organic life. The widespread electromagnetic interference nevertheless causes many of the nanobots to cease to function, and leaves some partially damaged.

Some of the damaged nanobots retain their ability to replicate, however the replications are often inaccurate and the results unpredictable.

Life, in its weakened state after the nuclear war, clings on and begins to recover. The remnants of a highly developed world left cold and silent are now the scavenging grounds for the remaining life on the planet. The nanobots however have begun to replicate in an unyielding way, evolving rapidly to convert carbon into the raw materials needed to duplicate themselves.

The nanobots inexorably consume everything in their path that is or was ever living. Life is unrelentingly and savagely attacked, and finally eradicated by the unstoppable clouds of mutated replicating nanobots. All that remains is the slurry and the dust of unneeded materials left behind.

Many years pass. The planet is once again cold and silent. Withered outlines of structures lay amongst the thick grey dust which coats the ground and chokes the atmosphere.

From the grey, a piercing blue light appears.

Over the last 6 months, I’ve been putting together plans to do something pretty radical, and as of a few weeks ago, those plans reached a head. I have now left my previous employer, the wonderful Cool Blue, and I’ve set out to work on Archaos and other projects full time, as an independent game developer.

It’s a big and somewhat scary step for anyone to abandon a guaranteed monthly income in pursuit of something which may likely end up falling flat on its face, but on the other hand games have been pretty much my whole life for a long time.

Earlier this year I held a LAN party at my house for a few of my long time mates, all of whom I met through games (most via Quake 2) and it happened to be just after this year’s E3. On the Sunday morning I was up before most people, and I sat watching trailers and coverage of games like WatchDogs, The Last of Us and X-Com: Enemy Unknown and started to yearn to be a part of this industry. Gaming is what I’ve always done, and what I want to do.

I’m now in the early stages of setting up my own business and I’m both refactoring and redesigning what I’ve now spent what amounts to many years of time, effort and planning on, with a cross-platform (desktop and mobile) release of a fully working, multiplayer Archaos as my primary goal.

The plan is still to allow players on all platforms to play together, and to switch from one platform to another (so a game can begin on your desktop, then you can continue to play turns on the train to work via your phone for instance) and to make use of the features afforded by devices (e.g. push notifications when it’s your turn) and I think in that respect, there’s not much else out there that I can find that offers that kind of seamless strategy gaming experience.

Anyway, just to give a bit of a taste of what I’ve been working on…

Note that these are still early concepts and some things are likely to change, but I’m much happier with the look of Archaos now that I feel I have a consistent style.

Stay tuned for more news, as well as a big update to this site coming soon!

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.