I think I’m done, at least within the compo time limit. I could spend the last few hours trying to fix more bugs, but I’m not very motivated so I’ll share some early postmortem thoughts instead.

I have a process I’ve developed for game design based around these concepts:

1. The way people become interested in a game is through its pieces. Good pieces = instant tutorialization and obvious mechanics. Therefore I now always start off by making good pieces and a fitting playfield for them. In the past I didn’t do this and my games sucked. Now they suck much less.

2. I try to achieve good game dynamics using the available pieces(or tailoring the pieces a bit more to fit). I use a very specific definition of a game dynamic, which is the intersection of two feedback loops produced via game mechanics. In general, the more intersections that occur, the more compelling the gameplay is going to be. Game events that occur outside of a feedback loop should only exist to support the fiction of the game pieces. That said, I don’t follow this rule too rigidly – it’s a model that I’m trying to test, not a dogmatic order – and I try to name and categorize what I’m achieving in broader terms. In this case the theme of “Escape” suggested someone nearly powerless, trying to escape hazards.

Starting from that little kernel of an idea, I drew some inspiration from other games: the “Deathrun” maps seen in some FPS games, Tower Defense games, Transformice… It seemed inevitable that I would do a multiplayer game where you had a whole group teaming up to get past a “big boss” type.

So I drew up my game’s playfield in Pro Motion, making some early assumptions that I’d have a low-res, single-screen game running more-or-less strictly on a tile grid. I was a bit worried that the playfield would be too small, but it turned out not to be an issue. As I drew I quickly decided it would be an ice cave rather than a generic cave, because the ice cave would suggest more interesting pieces. (as someone remarked, I could have done a lava cave instead. Different game, maybe that’s “Heartbreaker part II.”) Quickly I nixed the nascent generic obstacles I had first thought of(spikes, gun turrets, etc.) and replaced them with their ice-cave equivalents: icicles, slippery ice patches, and a yeti. I thought about the obstacles as I drew up the character portraits. First I did the Ice Queen – an obvious villain for the cold setting I was developing. Then I soon decided that it was tending towards a magical feeling, so instead of generic runner characters with torches or something, I opted for the counterpart Fire Mage. The “broken hearts” setting came out of that – I had been wanting to use the title “Heartbreaker!” for a while, though I had had a much different kind of game in mind for it. I had some trouble getting the portraits looking good, but left them for the time being.

By this point it was getting a bit late into my first evening, but I pressed on to set up my base code at this point. It’s all dribs and drabs from earlier projects – the build system, some timer code, the scene initialization process, the Player.IO connection code(the cloud service I’m using to host this and run the multiplayer APIs), the algorithm for collision, the sound management. I finished with just a tiny bit of proof that I could make a real-time multiplayer game – I’ve never tried doing a complete one start-to-finish, though I’ve worked with multiplayer/network code in other contexts.

The next day, I basically pounded away at the game until it succumbed to my will. It’s not pretty code and has some major architecture flaws, which is why I’m unmotivated to try a bugfix now. The biggest flaw is that out of inexperience I tried to push too much data into too little state, resulting in desyncs between the mages and the queen’s viewpoint, and various bits of oddness with how the characters move around(e.g. when a piece is brought onto the playfield the mages can be killed by its tween animation – a very unexpected game mechanic). Also, Flash is generally poor at networking for games – it supports some obscure stuff(various kinds of streams and proprietary protocols) and it has UDP in the AIR client, but if you’re making a web game you’re basically stuck with TCP, which means things periodically go berserk as the reliable delivery “catches up” with the game.

In any case, by the end of the night I had everything in a more-or-less playable state, which I mostly credit to player.io having a sane API and a decent service. I even had some players who got addicted to the game, buggy as it is. So I went to bed, and when I woke up(a few hours ago) I immediately got to work on some sound and music assets in Renoise, cleaned up the portraits a little, and got it all integrated. And that’s where I’m at now…

I’m a bit torn between trying to rearchitect the code after the compo is over and make a bigger game out of it, or just moving on with my main project, Moto. I guess I have some time to think on the matter.