Just a quick one today. I’ve registered with F6S for the chance to get some much needed help in bringing Archaos to you lovely people; and I’d very much appreciate your support just by simply following by clicking the button below:

Don’t worry, I don’t want any money, pledges, DNA etc, just a simple show of support – it really will mean a lot to me, as there’s nothing I want more than to get the chance to be able to make games such as Archaos – games which I feel there really is a dearth of in this age of many shallow social and AAA titles alike.

Whether or not you choose to follow me on there, the fact that you’re reading this already shows that I have an audience, and that’s really important. Thank you so much for your support!

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.