February 21, 2013 - UI and the lobby

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.

November 14, 2012 - Meet the cast

I’m happy (for now) with the performance I’m getting on all tested devices, and so I’ve spent the last few days on the units and visual tweaks. The coloured background is now back in (and more subtle, like the original concepts I posted before) and I’ve painstakingly redrawn each of the original creatures from the game, keeping as true to the originals as I can while injecting a bit more detail and colour variation.

Plenty for the blobs to eat…

One of the important factors for me is to give every unit a distinct presence. I’ve kept myself within a relatively small palette of colours, but tried to ensure that every unit is easily discernible. My first test had Hydras, Green Dragons, Gooey Blobs and to a lesser extent Crocodiles all looking very similar due to them using the same green. I’ve now varied the colours a bit to make the Hydra more yellowish, and given the Crocodile a tan belly. This will help when the board gets cluttered with units – especially given the isometric perspective which serves to make the board look even more hectic.

There are a few units I’m not entirely happy with at the moment – the Gryphon looks a little bit like a big goose or something, and needs to look more eagle-like. The Wall presented an interesting challenge and I decided it’d be best if I rendered it isometrically. I may yet do the same for the other large structural units too (i.e. Dark Citadel and Magic Castle).

The ‘classic’ unit set comprises 286 separate sprites, with separate sprites for left and right (because of the edge lighting always being on the right)  although some units end up with duplicates for various reasons; the Gorilla for instance, which looks the same from either direction – or the Vampire, whose cape blowing in the wind should always go in the same direction. An absolute godsend during this process has been TexturePacker – which has meant I’ve been able to quickly create, change and update a very optimised single sprite sheet with ease.

As well as these visual bits and bobs, the client now connects to the proper server (rather than a quickly hacked together server) and it can now manage multiple games. This means that I’m closing in on that first big milestone: a properly playable alpha version . Shortly after the game reaches playable alpha, I’ll be announcing my plans for beta testing.

November 11, 2012 - Optimisation

I’ve done an awful lot in the last week or so on Archaos. Primarily the focus has been on optimisation, as it quickly became apparent that as3isolib was simply not fast enough for the job at hand. This led me to explore the possibility of using Starling, a fantastic 2D-on-the-GPU framework, which tries to remain true to the standard AS3 display list as much as possible.

This of course meant I had to rewrite my entire render stack from the ground up. Bummer.

After a few days of building and tinkering with my own Starling-powered custom and very lightweight isometric rendering engine, the frame rates began to climb and climb. Today, after reading up on it a bit more, I’ve managed to get the game pretty speedy.

A whole lotta dragons

Above is a 200×200 board (that’s 40,000 squares) with approximately 20,000 animated, interactive golden dragons nodding away at just under 5 frames per second on my (admittedly pretty powerful) PC. Now this kind of test is pretty unrealistic, but it demonstrates what the engine is now capable of pretty well.

I’ve included further optimisations such as clipping (items off-screen are not drawn, which speeds things up considerably) and making use of a single ‘Texture Atlas’ for all of the units (basically a sprite sheet – gives a huge performance boost).

I’ve deployed some tests to my iPad 1 and my iPhone 4S and they’re running pretty nicely on both (my iPad is pretty much past it now but still churns the game out at a good 30-40fps) which makes me very happy indeed – especially in comparison to earlier last week when I deployed the as3isolib version to my iPhone and it ran at about 2fps!

I’ve also added other little visual touches and niceties (such as units jumping/flying between tiles rather than just sliding across) and have plans to add some really fun little things to make the whole experience of wizards and creatures fighting with one another all the more satisfying.

May 16, 2009 - ArrayQuery

As I continue writing convienience classes for my Chaos project, I’ve put together something which (with a bit more testing) would be very handy for general AS3 development. It’s a simple to use class for querying an array of objects and returning the results as a new array. You can use it to recursively filter the objects by their properties until you have the ones left that you want – and yes I know about Array.filter but it’s much more usable and cleaner than that!. I’m using this to allow easy access to the units on the board (and I’ll more than likely be using it for the spells and other data structures in Chaos) – but as it’s a very universal piece of code, I think it deserves a place on its own. Keep your eyes peeled in the coming days!