One of my earlier and more involved pens was the result of a thought: “What if 8-bit but open world?”. A great candidate seemed to be Jet Set Willy, and luckily there’s an absolutely excellent disassembly of the game available. It was fascinating to dive into the data and see how efficiently everything was packed in there while remaining pretty readable. Before the days of widespread fast and convenient compression, programmers just squeezed things down to the last bit.

I ended up writing various routines to process things in a way that looked true to the original, including figuring out how to parse the attributes (the way the Speccy encoded colour and more into 8×8 pixel blocks with a single byte) and generate all of the graphics, rooms and movement patterns.

It’s not complete unfortunately – the arrows and the rope swinging routine got the better of me at the time, but I still think it’s still a really cool little bit of nostalgia, and decently structured (for the time at least; this is pre-ES6 JavaScript).

Anyway, here it is in all its glory. Enjoy!

I quite like the big comment attempting to explain all the bitwise stuff:

    // The attribute format is a single byte containing 2x 1-bit values for flash and bright, then 2x 3-bit values for paper and ink
    // So the value 221 (binary 11011101) broken down becomes flash 1 (1), bright 1 (1), paper 011 (3) and ink 101 (5)
    // To extract these, we perform up to two operations:
    // 1. We perform a bitwise AND on the value with a bitmask of corresponding length for how many bits you want to extract - if 
    // we're looking for a boolean here (using a single bit in the mask), we can just coerce it with the !! operator as the outcome
    // will be zero for false and non-zero for true
    // 2. We perform a bitwise shift to the right so that the bits we're interested in are at far right side
    //
    // Examples:
    // To get the bright value (1 - true) from 221 (11011101):
    // 221 & 64 = 64  (binary: 11001101 AND 01000000 becomes 01000000)
    // !!64 = true    (binary: 01000000 is non-zero, so it becomes true)
    //
    // To get the paper value (3) from 221 (11011101):
    // 221 & 56 = 24  (binary: 11011101 AND 00111000 becomes 00011000)
    // 24 >> 3  = 3   (binary: 00011000 shifted right 3 times becomes 00000011)
    //
    // Quite a nice explanation of what you can do with bitwise operators can be found here:
    // https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/Bitwise_Operators
    // 
    // P.S. I revised this whole intro in September 2020 as I realised I didn't understand bitwise operations as well as I should
    // have. Littered throughout this code are examples of the old inefficient method of "shift then and", as opposed to the
    // 'correct' way of doing things (especially for single bits). No doubt there's more on this for me to learn but it's good to
    // be honest.

I’ll write up a few more of these for other pens I’ve done if there’s any interest. Let me know in the comments or via one of my socials if you’d like to know more about any of these, or indeed anything else I’ve done!

• Bluesky
• X
• CodePen

You can view the microsite I put together for it here, browse the repo (and maybe even if you feel like it, or spot some of my horrendous and inevitable broken maths, contribute) on GitHub here, view the API docs here, and I’ll also be posting some simple examples to demonstrate the various features shortly. Enjoy!

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.

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!

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.

Archaos is very, very slowly moving along – we’re talking geologically slow here, but nonetheless there’s still a roadmap and there’s still progress on it. My aim now is to have a release before my 30th birthday (next year) and I’ll be damned if I don’t make it!

I’ve been experimenting with presentation and so on, and came up with a little thing tonight which I thought was quite cute.  I’m really feeling the love for CSS3 and HTML5 now.

WordPress has become my new powerhouse tool at work, and I’ve been churning out sites left, right and centre in this wonderful blog engine turned CMS (as of 3.1 especially so) – check out some of the following:

• www.lovegeobar.com
• www.communityfoundation.org.uk
• www.redboxdesign.com

The last is our most recent project, and is very much not a site you’d expect to be WordPress powered – such is its flexibility!

I don’t update on Twitter much anymore, as it’s become a bit of a joke now with all of the celebrities and ridiculous trends; it pains me to say it but I think Twitter is more about Justin Bieber now than anything sensible. Alas, I spend most of my social networking time now on Facebook.

Finally, I’ve booked a flight to Arizona in September for a two week photography road trip with two of my good friends – should be awesome!

Anyway, hopefully that’s got everyone up to speed on what I’m doing – keep your eyes peeled in the coming months for updates on Archaos and other projects.

{
  "turn" : 1,
  "phase" : "move",
  "interaction" : "sequence",
  "finished" : true,
  "actions" : [
    {
      "type" : "move",
      "player" : "lewster32",
      "time" : 1263682234,
      "data" : {
        "piece" : "p0",
        "path" : [
          {
            "x" : 1,
            "y" : 7
          }
        ]
      }
    },
    {
      "type" : "end_turn",
      "player" : "lewster32",
      "time" : 1263682234
    },
    {
      "type" : "move",
      "player" : "bobster16",
      "time" : 1263682234,
      "data" : {
        "piece" : "p1",
        "path" : [
          {
            "x" : 13,
            "y" : 5
          }
        ]
      }
    },
    {
      "type" : "move",
      "player" : "bobster16",
      "time" : 1263682234,
      "data" : {
        "piece" : "p3",
        "path" : {
          "x" : 11,
          "y" : 4
        },
        "flying" : true
      }
    },
    {
      "type" : "end_turn",
      "player" : "bobster16",
      "time" : 1263682234
    }
  ]
}

I’d like to mention the huge amount of support, encouragement and fantastic resources provided by certain people of late. @andy_herbert has been a fantastic vocal advocate and provider of much inspiration and technical knowhow (he’s an utterly brilliant multi-talented programmer in his own right) and I owe an awful lot to his ‘cheery’ tone on Twitter!

Secondly, I’d like to shout out a big hello to the Slashdot horde, who accosted the site a few days back. I got a hell of a lot of visits from these guys and I’m sure it’s helped spread the word about Archaos (even if that wasn’t actually my intention) and more importantly the Chaos scene in general!

Finally, a big thanks to @Zolyx for mentioning the project on his blog along with the other fantastic Chaos projects out there – muchos appreciated!

For those interested in creating a client (and because the code isn’t yet ready for viewing!) here’s the current output of a test run on the server. Note that games, pieces and spells have a unique game ID, which is a letter followed by an incrementing numeric value. One of the current things I’m working on is cleaning up the code so all possible references are made to these UIDs, and not directly to the objects, as this will make things safer and more manageable within the engine at the expense of a little bit of performance (no doubt I’ll rewrite much of this at a later date so there are two ‘levels’ of code; the UID data-driven level that the users interact with, and the deeper object-driven stuff that processes things.

{
  "turn" : 1,
  "phase" : "select_spell",
  "interaction" : "all",
  "finished" : true,
  "actions" : [
    {
      "type" : "select_spell",
      "player" : "lewster32",
      "time" : 1262563476,
      "data" : {
        "spell" : "s0"
      }
    },
    {
      "type" : "select_spell",
      "player" : "bobster16",
      "time" : 1262563476,
      "data" : {
        "spell" : "s6"
      }
    }
  ]
}

{
  "turn" : 1,
  "phase" : "cast",
  "interaction" : "sequence",
  "finished" : true,
  "actions" : [
    {
      "type" : "cast",
      "player" : "lewster32",
      "time" : 1262563476,
      "data" : {
        "spell" : "s0",
        "target" : {
          "x" : 0,
          "y" : 1
        }
      }
    },
    {
      "type" : "spawn",
      "player" : "lewster32",
      "time" : 1262563476,
      "data" : {
        "x" : 0,
        "y" : 1,
        "occupant" : {
          "uid" : "p2",
          "owner" : "lewster32",
          "properties" : {
            "movement" : 1,
            "combat" : 7,
            "defense" : 8,
            "maneuver" : 6,
            "resistance" : 4
          }
        }
      }
    },
    {
      "type" : "succeeded",
      "player" : "lewster32",
      "time" : 1262563476,
      "data" : {
        "spell" : "s0",
        "target" : {
          "x" : 0,
          "y" : 1
        }
      }
    },
    {
      "type" : "end_turn",
      "player" : "lewster32",
      "time" : 1262563476
    },
    {
      "type" : "cast",
      "player" : "bobster16",
      "time" : 1262563476,
      "data" : {
        "spell" : "s6",
        "target" : {
          "x" : 11,
          "y" : 1
        }
      }
    },
    {
      "type" : "spawn",
      "player" : "bobster16",
      "time" : 1262563476,
      "data" : {
        "x" : 11,
        "y" : 1,
        "occupant" : {
          "uid" : "p3",
          "owner" : "bobster16",
          "properties" : {
            "movement" : 1,
            "combat" : 6,
            "defense" : 5,
            "maneuver" : 2,
            "resistance" : 4
          }
        }
      }
    },
    {
      "type" : "succeeded",
      "player" : "bobster16",
      "time" : 1262563476,
      "data" : {
        "spell" : "s6",
        "target" : {
          "x" : 11,
          "y" : 1
        }
      }
    },
    {
      "type" : "end_turn",
      "player" : "bobster16",
      "time" : 1262563476
    }
  ]
}

These are what every player will receive at the end of each phase. They contain each action performed by the players in the order that they performed them, and timestamped for reference and backup purposes. Players have relatively limited access to the game in terms of actions, just like in the original game. A player may select spells, cast spells, move and attack pieces and end their turn. From these actions however, more actions may occur, so a player casting a spell on tile x will set off a chain of actions, where the server rolls against the spell’s chance, then (if successful) performs the spell’s effect, which may be to spawn a new piece or whatever.

Soon I’ll be locking down the format of these outputs, and documenting the errors and notices a user receives directly. This will allow for anyone wishing to do so to begin planning or working on a client – and I sincerely hope people do!

• Creating games
• Joining and leaving games
• Creating and moving pieces on the board
• Extensive move validation (bounds checking, path checking, engagement checking etc)
• A customisable turn/phase system (this has been an absolute pain in the arse to implement – but it appears to be working as intended now)
• Full JSON messaging system (you talk to the server in JSON and it talks back to you in JSON, there’re no sockets, special protocols or proprietary formats)

The Google Code wiki is somewhat out of date (already!) as things slot into place during development, and I’ll update it as things become more solid. I’m currently using a private SVN, though as the project nears a working first version (and if there’s any interest) I’ll be happy to give access to the SVN – there’s a lot of experience and expertise out there, and I’d greatly appreciate a second opinion on aspects of the code!