←

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!

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.

Apologies for no updates in a month – I’ve been working on other small prototype projects, sharpening my skills and learning new languages (such as C# in Unity 3D – which I cannot recommend enough!) as well as just recently attending a rather prolonged hospital stay. Needless to say I’m back on with things now so expect to see some more updates and progress in the coming days and weeks!