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.
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.
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!
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.
I’ve spent the last two months refactoring a lot of code, tidying up and making everything more manageable. I’ve also spent the time working on implementing a Feathers-based GUI so that the game works more like a game should (i.e. with an opening screen, the ability to select which game you want to play and so on).
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.
