←

After quite a few years (people operating on geological time may be starting to sense a pattern here) I’ve updated the Archaos beta at www.rotates.org/archaos/2021

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.

I’ve always enjoyed short, snappy little projects that deliver a quick dose of dopamine, and I’m a big fan of CodePen as a way to exercise that ‘tinker and play’ attitude.

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

It’s been a while has it not?

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.

Recently, as part of my continued work on Archaos (yes, I’m still working on it, never fear!) I put together an isometric (well, axonometric to be a little less precise) renderer for Richard Davey‘s wonderful Phaser HTML5 game development framework. It’s got a nice adjustable axonometric projection helper, a simple and fast physics engine based on Phaser’s own bread-and-butter Arcade Physics, and it’s probably close to production ready. I deliberately kept the system simple, and the API as close to the existing Phaser API as possible to allow for quick adoption, and it plugs in pretty much seamlessly.

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!

www.archaos.co.uk

More soon…

I’m taking a little bit of a break from Archaos at the moment as more immediate priorities have arisen – notably my financial status! As you probably know, I quit my full time job in September of last year to work on Archaos, and indeed I’ve made a lot of progress; as much if not more in my abilities as a programmer as on the game itself.

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 the last few days working on the pathfinding system on Archaos. This replaces the previous and temporary ‘one step at a time’ way that non-flying units were controlled, and makes the process of moving of your units much easier and faster.

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.

For the last few weeks I’ve been adding in two very important systems to Archaos – namely real-time communications via TCP, and the use of a database back-end for the server. The first makes games much more responsive, and allows the server to inform connected players of actions as and when they happen. It will also pave the way for an exciting addition I have planned, which will (hopefully) combat the inevitable pacing problems that arise from typical turn-based games. If you want to know more about what I’m getting at, give this excellent article a read.

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.