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.
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.
With the aid of @andy_herbert, Pentacom’s online bitmap font maker and CR8 Software’s Type Light, I’ve managed to create a crisp OpenType version of the font from the original Chaos, with a few tweaks and the addition of a (nearly) full latin and eastern European character set.
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.
