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.

I won’t lie, Feathers has been difficult to get my head around – it seems to be an excellent library once you’ve sussed it out, but it’s not well documented (relying mainly on examples rather than proper documentation, and leaving you to even look at the library’s code itself to figure some things out) and took me a long time to get comfortable with. The upshot is I now have a very nice, fast, flexible native-feeling interface to Archaos which will work the same on all platforms.

You can see a short video of me demonstrating it on my desktop below – and you’ll just have to take my word for it that it works just as well on a mobile device

None of what you see here is mocked up – the games you’ve joined or created are being retrieved from the server, and their details are being displayed. The isometric mini-map shows a real-time view of the game, and will update even while you view it from the lobby.

More features will need to be added to make the lobby fully featured, such as an interface that allows you to add friends (and so see their newly created games and join them), the ability to sort and filter the games by various criteria and of course the ‘create new game’ screen itself, where you’ll be able to set things such as the board size, maximum number of players, round/turn lengths and so on.

One last thing – I had a discussion with one of my friends about Archaos and realised that the words I was using to describe various things didn’t make sense. Because of this conversation I’ve settled on the following:

• Board: The rectangular grid upon which the game is played.
• Unit: A piece on the board, be it a wizard, wall, creature or corpse.
• Turn: An individual player’s ‘go’ – i.e. selecting a spell, casting a spell or moving his/her units.
• Phase: The three distinct gameplay segments, consisting of spell selection, spell casting and unit movement. Technically a fourth non-playable phase happens after spell casting and before unit movement, in which gooey blobs and magic fire spread, magic wood and castles/citadels may disappear and so on. Other phases may be introduced with new game modes.
• Round: One set of phases, beginning in Classic mode with spell selection, and ending after the last player’s turn in the unit movement phase.

This means that each round has several phases, and within each phase each active player has a turn. Not all phases force the players to take turns one after the other – the spell selection phase will allow all players to select their spells together, and the phase will only end when either all of the players have selected a spell (or cancelled) or the time runs out for that phase. The spell casting and movement phases that follow will work as normal, with every player taking their turn one after another in the correct order. Timers here will work on an individual’s turn, so each player will have (for instance) five minutes to cast their spell, before the game cancels their turn and moves on to the next player. The same goes for the movement phase’s turns. All of this will of course be configurable upon creation of a new game.

You’re here because physics, chemistry and biology have been at work shaping energy and matter for 13.75 billion years, and will continue to do so long after you are gone. Your purpose is to enjoy your short waking moment in time, to learn and to explore, and to recognise that you are part of a magnificently ancient, complex and purposeless universe that has produced you with your own complexity and consciousness, and given you the ability to comprehend your place in it and choose your own purpose.

Pardon my Polish…

I’m not sure yet whether or not this font will go into Archaos however I’m happy to provide the font free for all to use as they wish – though giving Julian Gollop credit for the design of the original font would be encouraged, naturally.

Anyway, you may download the font below.

Chaos Sans 1.0

187 downloads

Question is, can you name them all?

Above are 51 spell icons rendered in glorious colour, and in no particular order. The borders are colour coded to help identify their type and use, though when implemented into the game, they will also come with a name, description and stats where necessary.

The alpha now has (nearly) full combat and movement, so the next step will be adding the spell phase. With a bit of luck this should happen in the next day or two, after which a very nearly full game can be played.

Click the image to view the huge (7680 px wide) original

@andy_herbert has painstakingly put this ‘cheat sheet’ of all of the original game’s units together showing graphics, stats, movement and combat ranges for each one, and grouping them together into this attractive infographic. I think it’s wonderful, and I’m going to print a large version of it out for my wall to use during testing!

Alpha is now under way with a small number of testers. So far we’ve played a few furtive ‘games’ (in the loosest sense – no casting, no ranged combat yet!) and apart from a few silly bugs, all seems to be well. I’m putting the finishing touches onto the standard movement/combat model in the next day or two (including finally adding ranged attacks) and then I’m going to implement casting.

Casting brings with it the somewhat-more-complex-than-it-seems matter of the user interface – which of course is critical to any game and which if not implemented correctly can really hinder this game. The interface in Archaos has to be intuitive, compact, and it has to get out of the way when you’re trying to play the game itself. As a cross platform mobile and desktop game, the way a player will interact with the game will differ slightly amongst platforms, however I want to ensure that the differences aren’t too jarring, and that each platform plays to its own strengths.

One of the methods to improve the experience is the use of gestures, so a player can pan and zoom the map intuitively, like they’re used to – and it may also through testing lead to methods of reducing the chance of accidentally performing an action, such as by having a user tap and hold on a unit or tile and then drag outside of a circle in order to perform the action (to ensure that the unit or tile tapped is the intended target, and that the user hasn’t just accidentally tapped the screen somewhere).

As I realise people like to see screenshots of progress as well as words, here’s a view of a typical alpha testing game session (with debug data above the units) showing the newly added window bezel to the mini-map, which is the basis of the UI, as well as the new ‘volumetric’ cursors and the big ‘cancel’ button.

My horse prepares for its gallop towards the hopelessly outnumbered cyan wizard

From a technical standpoint, the ‘netcode’ is fairly simple; when a client connects to a game, a snapshot of the game with all of the relevant data (position and status of units, players, whose turn it is etc etc) is delivered to the client which then sets the board up accordingly. The client then starts either polling via HTTP or listening via TCP (how this is chosen I have yet to decide) for new ‘actions’.

Not related to post: The unadorned mini-map – and yes, units now cast shadows. The shadows stay on the ground when they move too! Like proper shadows! I am so smart.

Actions represent every possible individual step which influences the game state in some way; a player joining or leaving during pregame, a unit moving, a new turn, a player being defeated or the game ending. Each action has both a timestamp and a consecutive action number. This means that all the client has to do is keep a record of which action number it’s up to, and wait for new actions. When new actions come through, the client processes these new actions in turn until it’s up to date with everyone else.

Because of the added complexity of creating a game which works over the Internet, some slight changes have crept into the gameplay, though these will be mitigated to keep the game as pure as possible. One such change is the way that individual units’ moves are processed.

In original Chaos, when you move a unit, after it has moved, it may then perform an attack (if it moves adjacent to a combat-capable enemy unit) or a ranged attack (if appropriate). These potentially up to three components of each unit’s ‘move’ are all typically linked together. With Archaos, a player may move their unit, and then lose connection, their PC may crash, the boss may come in – whatever – the point is they may be interrupted. In this case, with the traditional system there’d be two choices – either to automatically ‘end’ that unit’s move completely (which seems a tad unfair) or invalidate the unit’s move (not really practical).

The solution therefore is for the client and the server to track the move/attack/ranged attack phases as just that, distinct phases of the move. That way, if a unit moves but doesn’t get to perform its attack or ranged attack, clicking on it later in the same turn would allow you to continue its remaining phases.

Of course, this differs from Chaos and I’m always acutely aware of things which differ from what is both in my mind and the minds of most of its fans a well balanced and perfectly fine game. With that in mind, what I can do to ensure the gameplay remains (mostly) original is to automatically call the attack/ranged attack routine in the client after each unit’s movement phase. If the player then actively cancels one or both of these phases, they are marked as ‘complete’ and the unit’s move ends completely. Action or cancellation will be made mandatory on the client, so that the only time when the option to ‘revisit’ a unit will be available is if the move is cut short in some way. This does mean that players could potentially quit out of the game in order to bypass cancellation, but as there are no benefits I can see to doing so, it means that this feature can do its job without interrupting gameplay.

The game is now quite close to the alpha stage – that is it will be in some way playable very soon. The alpha will almost certainly begin by the end of this week, or the weekend at the latest (unless I run into some catastrophic game-breaking bug) and will feature a comparatively small subset of gameplay to begin with:

• Users will be creatable
• Games will be creatable (with the ability to set a width and height of the board – wizards will be spaced around the board as in the original game dependant on number of players)
• Games can have up to 8 players and can be limited to fewer players if the player wishes
• Players will be able to move units around the board, attack one another and cast basic creature units
• Players will be able to defeat other wizards and win the game
• Players will not be able to cast non-creature spells
• Wizards will not be able to mount creatures such as horses etc
• Animations for things such as spell casting, attacking, ranged attacking and wizard deaths will not be implemented at this stage
• There will be bugs, crashes and weirdness – this is an alpha remember!

I will make further announcements about the alpha during the week on Twitter. I will be looking for volunteers to help me test the game and iron out any issues with what is essentially the core gameplay mechanic. It won’t be a particularly amazing experience at this stage (not compared to the original game or the final product, or even the subsequent beta) but it will be essential to test it on a range of hardware, and in a range of conditions.

As Archaos is already multi-platform ready, I will be able to create iOS and Android builds for those alpha testers who would like to try it on their iPhones and iPads. If this is the case, I’ll provide further instructions on what you need to do to get Archaos running on those devices. I’ve not yet tested Archaos on Android but I will at some point this week before I start alpha.

If you’d like to be part of the alpha phase, and have read all of the above and realise that you’ll be testing a limited and unfinished product, leave a comment below or drop me a line on Twitter.