A lot of the heavy work has been via the use of AI (Claude in this case). I’ve been using it both as a learning exercise in agentic workflows, and, honestly, just because it’s a lot of fun! I really wish I’d learned Z80 assembly back in the day, but I never got round to picking it up before I’d moved on to higher level stuff. Now, I can work with a game I’m super-familiar with, and see the code that drives it, and that’s a really cool way to get into it.

Anyway, hopefully the disassembly is as useful (or just interesting) to everyone else as it has been to me. It’s not finished yet, but lots of good stuff is there now. I’ll be putting the source for it all on Github soon, once I’ve tidied things up. This is now available to view on Github here: https://github.com/lewster32/chaos-disassembly

If anyone’s interested I’ll even write about the process. A lot of it was setting up the tools and reference materials, and finding concrete known places to start in the code to then work back from.

Props goes to other people’s work in starting to crack the code open in Skoolkit, such as https://github.com/ZXGuesser/chaos-disassembly – this one especially proved invaluable as a reference guide to keep things on track.

• Much more competent computer wizards. They now act much smarter with regards to their spell choices, unit movement and so on. The general intelligence they display can also be modified with a new difficulty slider in the (also new) player configuration menu. As the difficulty increases, so too does their aggression, sneakiness and attention span.
• Mobile support. While the game has long been ‘sorta’ playable on mobile, it now has proper support for things like panning around the board, auto-focusing on the next player and more. The UI has also been tweaked to fit better at mobile viewport sizes.
• Enhanced spells and units. A small but growing selection of new spells are available (they can also be turned off if you want a more classic experience). They include some powerful new dragons, a unique immobile ranged-attack unit and a few more. I have several more spells and units planned – see this document for more info.
• Better UI. The UI elements I created many moons ago were partially implemented, but some of the UI was still just placeholder stuff. Now all of the menus, inputs, checkboxes etc. have the correct styling.
• Many bugs fixed. Yep. There were a lot. Notable ones include being unable to fly-attack enemies in some cases, and computer wizards raising dead units right under the feet of a non-dead unit. You can view more info on Github’s bugs page: https://github.com/lewster32/archaos/issues?q=is%3Aissue%20label%3Abug
• Tests, tests and more tests. Under the hood, there’s now a huge suite of over 1,000 tests that run before every deployment. This has proven invaluable in fixing and adding features while being confident I’ve not broken anything.

With all that though, we’re not done yet! Here are some of the things I have planned still:

• Remote multiplayer. It’s the most requested feature, and something I’ve experimented with a lot in the past. I now have many of the building blocks in place to get this right, so this is still definitely on the cards.
• Tutorials. For Chaos die-hards, it should be very easy to pick up and play Archaos, but I’m acutely aware it’s a game with a learning curve, despite all of the effort I’ve made to have it explain itself and try not to overwhelm the player. That said, a nice set of tutorial scenarios to introduce new players to the mechanics would be a very nice thing indeed.
• Standalone client. While it’s very convenient to play Archaos on the web, and it was indeed built to be a web-based game, I’d like to look at distribution of the game as a standalone thing. I’ve already got a pretty good working prototype of a slimline desktop client powered by Tauri, so having this able to be distributed via something like Steam is now a definite goer. Watch this space!
• More spells and units. As mentioned above, I don’t want to stop at the few new spells and units I’ve added. Eventually I’d like to get them all in there! This would also come with a way for each game to select the available set of spells wizards have access to.
• More interesting board terrain. Right now, everything happens in the rectangular void, as it did in the original. I’ve always been interested in having a bit more variation in the scenery though. Trees, walls, ruins, visual variety to the floor types and more are all things I’d like to add to spice up the look and feel of the board, as well as potentially add some obstacles and dangers. All optional of course!

Anyway, enough gassing. Go play it here: https://www.archaos.co.uk/

If you’re interesting in the nerdy stuff, visit the Github repository here: https://github.com/lewster32/archaos/ – you can also post any bugs, suggestions or comments in the issues board.

Have fun!

What’s new? Why, I thought you’d never ask!

• Up to 8 players can now duke it out for wizardy supremacy.
• Numerous bugs have been fixed, especially around mounted wizards.
• Computer controlled wizards are now available, and can be mixed and matched with human players just like the original. They’re currently not the smartest tools in the shed, but they’re able to cast all spells and use all units reasonably effectively.
• The code has had lots of inline documentation added, and the dependencies are almost entirely up to current versions (with the exception of Phaser, which introduced some breaking changes in recent versions that I need to catch up with).

You can follow along with the updates, check out the source code, raise issues or even contribute on the Github page here: https://github.com/lewster32/archaos

The game has also now been listed on Open Source Game Clones, so thanks to ju5 for doing that! It also has a listing on https://chaosremakes.fandom.com/wiki/Archaos which I’ve dutifully updated a bit.

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

Well, here we are near the end of 2021 and what do I have but… a beta release of Archaos! Yes, that’s right, the game I’ve been working on most of my adult life finally gets a public, playable release!

This iteration has taken just over a month from start to beta, and I’m pretty happy with where it is right now. There are of course bugs, inconsistencies, and annoyances, as well as some big missing features (computer opponents and multiplayer being the ones I feel most will point out) but I hope to address these in time.

If you want to play it now, you can do so here: https://www.rotates.org/archaos/2021/

It currently has no network multiplayer or computer opponents (things I plan on addressing in due time) and has some bugs and inconsistencies, but I’ve managed to have a decent amount of relatively ‘vanilla’ experiences now playing the game on my own.

The source code is also public, available at my Github: https://github.com/lewster32/archaos – please do feel free to report any bugs or requests features etc. on here, and I’ll do my best to get around to them.

Thanks for holding on there, it’s been a journey.

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!

More soon…

As it stands, I need to do a partial rewrite on the client, as some aspects of it (mainly legacy stuff from last year) have become unmaintainable. Sounds drastic but I assure you this is only a minor setback; lots of Archaos is done and working to my satisfaction (the server for example is in a pretty good state at the moment, and the implemented features are working very efficiently) however the rigours of dealing with stateful asynchronous stuff all over the place (via the network, player inputs, waiting for animations and so on) combined with the lack of any kind of pattern have led to a game which as it stands is becoming near impossible to debug. Action must be taken, and that will begin with the application of a proper MVC pattern to the client game code.

In order to continue to be able to work on Archaos, I’ve taken on some web jobs (which bizarrely appeared totally out of nowhere from friends right as my savings were about to dry up) but this is a temporary thing and as soon as they’re done, I’ll be back onto Archaos and aiming for a beta release.

I can only apologise for the seemingly endless false starts and broken deadlines for those of you who’re following this project – it’s embarrassing to keep having to explain myself. My focus is however still solidly on getting Archaos finished and released, and then getting to the bit I’ve been really looking forward to; extending the game through new modes, features, spells and units!

Stay tuned!

I’ve spent a fair bit of time testing the system and comparing movement ranges with the infographic posted previously. Due to some discrepancies with the way the original game handled non-flying movement, calculation of a non-flying unit’s range isn’t trivial – and when you throw in obstacles and danger of your unit getting engaged, the efficiency and accuracy of the pathfinding system becomes vital. I may still need to tweak it a little further but at the moment I’m very happy with the results.

Ease of interaction is one of the top priorities of the game; if the game’s controls aren’t implemented correctly, it could quickly get very annoying – for instance, if it was easy to accidentally move a unit to the wrong position. This is especially important when dealing with mobile devices, which offer less feedback and less accurate interaction methods.

With this in mind, all actions carried out in the game must be confirmed, either by tapping twice in the same spot, or by tapping the ‘confirm’ button which will appear once you’ve tapped to express your intent. This method seamlessly works between mobile and desktop, with intent on the desktop being indicated as you hover your mouse over the board.

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.