W.I.P. 6 – Star Weasel

Oh, let’s start with names again shall we?

When you set out to paint a picture you start with a blank canvas, and a world of possibilities. You can then dip your brush in oil paint or gouache or watercolour paint and let rip with your imagination. Likewise if you decide to write a short story, or a poem, or a sonata you start with a blank page and a pen and the freedom to express yourself. Going digital, if you want to write a word doc, or create an image in Photoshop, a model in 3DS Max, or write a blog post in WordPress you fire up your program of choice and start with a clean state that you can immediately attack with keyboard, or mouse, or touchscreen or tablet. These are endeavours that typically take hours, (but may last days (or maybe longer)).

When you set out to make a video game, you fire up XNA, or Unity or GameMaker, and the first thing it asks is for the name of the project. Before you can place one pixel or create one polygon or type one line of code it wants the name of the thing that you will be creating. This is a project that could last months or years. A name, right now, before you go any further.

Fingers crossed in a short while I’ll finish my current game, and release it to critical acclaim, and people will love it, and the rather silly name “Super Thrustforce: Orbital Meat Police” will be known to gamers across the world.

But deep down I’ll always know it lives in a directory called “TestProject01”.

I tend to start lots of projects – I’ll often abandon them quickly afterwards, and then start something else instead. So I’m used to having to name these things with temporary names, knowing that I’ll live with something placeholder, but can rename the end product if it ever materialises. However, if I haven’t started something new in a while I tend to forget this part of the process, and the request for a name upfront is always jarring.

To cut to the chase, many years ago I decided to have a pop at writing a Uridium-style game in XNA – a bi-directional side-scrolling shoot-em-up played over the surface of giant enemy dreadnought spaceships. I wanted this to be a short project with a definite goal to aim at, and this seemed small enough. I gave it a quick think over, thought it should be easy enough and then fired up XNA. I hit the project name barrier. I dunno, let’s try “SHMUP”. Nope – it already exists. Of course it does, I’ve had half-hearted stabs at my favourite genre loads of times. OK “Shooter01”? Already exists. “ShootEmUp”? Gone. Fuck it, “Star Weasel”? New project created – result! Blank canvas time, let’s make a game.

I now have a game called Star Weasel, for no reason other than I have an abiding fondness for all of the sock-shaped creatures of the mustelid family (stoats, ferrets, polecats and weasels), and a mental toin coss picked “Star” over “Space” as a way to make a critter sound like a game name.

So after all that preamble here’s a quick video of the game:

This was made in late 2009 to early 2010. I think it holds up fairly well, and bears an awful lot of similarities with current project STOMP. Possibly too many. Bold colours, untextured polygons relying on a shader to look nice, 2D game in a 3D world, a background starscape with 3D planet and moons orbiting far faster than they should etc.

More worryingly – that ship. On the left Star Weasel, on the right STOMP:


Look at them! They’re almost identical. And they’re both dreadful (of all the models in STOMP the thing I like least is the player’s ship – it’s getting a redesign right now). Four or five years and any number of different projects separate these two games, and yet I made the same godawful spaceship for both. STOMP’s ship actually started off blue, but somewhere along the line I recoloured it on a whim, and somehow managed to make it almost the same as the ship in Star Weasel – THAT I NEVER LIKED THEN EITHER.

Moving on, and to follow up on my post I <3 3D, here’s a quick video showing off the various camera angles I added for the fun of it:

So to smmarise what we have then is the basic framework for a Uridium style game, with some shootable objects and enemy turrets and whatnot. Not shown are enemy homing mines, which were implemented quite nicely, but I’ll get on to them later.

So, what went wrong with the Weasel? Two things mainly.

The first was scope. The game became far too complex and daunting. As with Dogfight Thing I started with a simple premise and quickly over-complicated it to the point that it became a mountain to climb. For starters I’d decided (because the enemy dreadnoughts were component-based) to make a level editor, and that’s a whole heap of no-fun whatsoever in its own right. However the biggest issue was in the actual game design, and looking back I think I can see exactly how it went wrong.

I started out as an artist, and one of the things I know I’ve always been weak at is making superfluous shit up. In art classes back in the day I used to love drawing dragons and monsters and castles and stuff, and was pretty good at it, because I could justify everything I was drawing. So what if my dragon has a few ear-piercings? It’s a dragon with a strong sense of identity and a personal stylist with very little regard for their own personal safety.

I was rubbish at spaceships though (and as we’ve seen – I still am). Good spaceships tend to be covered in clutter – all manner of vents, and panels and stuff. Superfluous shit. I struggle with this – I want to have a reason for everything.

So I start working on a game featuring enemy dreadnoughts with shootable surface objects, and I immediately have to start giving functions to these things. That’s a shield generator, that’s a radar nodule, that’s a power unit, etc. Suddenly I see a very different game emerging, with interwoven systems like a fully-functioning star-destroyer might have. Do you take down the tough defence cannons first, or try to endure their onslaught whilst you soften them up by destroying the shield generators? Destroying weapons-guidance systems would make enemy fire less accurate, and getting rid of radar would make enemy fighter passes less frequent. Suddenly we’ve gone from a game where I can just place lots of stuff that needs shooting, to one that needs careful planning and balancing so that all of these systems justify their existence, and levels will need to be populated with extra care and attention.

I still think there’s a really nice game in this, it’s just not the one I set out to make.

The second problem was that the game was in 3D. I was going to do a companion piece to my I <3 3D blog post (called “I h8 3D”), about the unforeseen problems that using a 3D engine can bring, but never got around to it. However, this game illustrates one of the main issues really nicely.

It’s all very well thinking “I’ll make Uridium in 3D”, spending a bunch of time knocking up some models, whipping together an XNA project and getting the basics of a side-scrolling shoot-em-up in place, but you really should spend a little bit of time thinking through the mechanics of the game and how they’ll translate to a 3-dimensional solid world beforehand.

In the original game, the player shoots targets and dodges obstacles on a 2d plane, and that bit’s easy to replicate in 3D. In the original game the enemy fighters and mines live on the same plane and yet ignore the targets and obstacles – they simply appear to fly over them, because sprites can do that if they want to. You can’t do that in 3D – you’d see them fly through solid objects. To fly over the obstacles they have to actually fly over the obstacles, and if they’re doing that then the player can’t shoot them, so there’s no point in them being there.

The alternative then is rather than having waves of stupid enemies that simply pass back and forth (nice and easy to program), is to have smart enemies that can navigate around all the clutter that someone stupidly positioned all over the otherwise nice empty deck (much much harder to program). And those nicely-implemented homing mines I mentioned earlier? In their simple-minded desire to head straight for you, they’ll fly straight through anything in their path, which looked rubbish. So then I made them destroy whatever they hit instead, which meant they were more of a threat to their own ship than the player was because they almost always hit something friendly. It was kind of amusing for a while, but it looked pretty stupid in the scheme of things. The other option was making them explode on contact but not destroy the target, but this still meant they rarely bothered the player, and also robbed them of the ability to look like dangerous explosives. Basically they needed to be much smarter, or they needed removing.

I’ve already mentioned elsewhere that I’ve tended to struggle even getting started with AI. I always want to do it well, so put it off until later to do it properly, and often never get back to it. In this case, it was probably the straw that broke the camel’s back.

I’d only wanted to work on a short project, and suddenly it had become a lot more complex than that, and I just lost the will to carry on with it. I actually really like the idea of making the game at its fullest – with complex functioning systems, and smart enemy defence forces – it’s just not something that I enjoyed stumbling into at the time. One to revisit later, maybe.


For this post I thought I’d write about something close to my heart – puns. I love puns, and wordplay of all kinds, and whilst I’m generally pretty modest I will claim to be pretty good at punning. Whilst not strictly game design related, puns are something I’ve tried to work into almost every game I’ve worked on (assuming they’ve not already been designed in as standard). Games tend to need a fair few things naming (levels, achievements etc.), and if the tone of the game doesn’t preclude making puns then each of these names is an opportunity to amuse the player, which is kinda the point of making games in the first place. This is especially pertinent for me now, because I intend to throw as many puns as possible at STOMP.

However whilst I love my punning, I’m still not entirely sure why some puns are better than others. So I thought I’d take a look at some puns I’ve come up with for the games I’ve worked on to see if I can make any insights.

I’ll start with the last game I worked on at Blitz as a designer – Puss in Boots (I genuinely believe we made a really good Kinect game with this – if you’ve got kids and a Kinect I recommend it). The puns for PIB were mostly for achievement names, and sadly THQ dismissed some of our better ones – partly because of copyright worries (even when invalid – “A Tale Of Two Kitties” was perfect and Dickens is out of copyright) and partly because I think they didn’t understand them. However one that did make it was “Well Balanced” which was an achievement for crossing a tightrope perfectly. This one pleases me. It’s not funny. It’s not that clever. It’s just an existing phrase that also happens to perfectly describe what you’ve just done. There are no loose ends though, and that helps it a lot. Often a pun doesn’t quite “fit” the situation you’re using it in and that’s unsatisfying. I used “Prevent the meat death of the universe” in my STOMP trailer. I love the wordplay, but it doesn’t fit the scenario well enough – you’re just trying to rescue Earth’s cows – if you fail there will still be lamb and pork and squirrel and all the other critters folk eat around the world. This inaccuracy bothers me, and if I didn’t like the notion of “the meat death of the universe” quite so much I wouldn’t have used it (I’d have saved it for later though – there’s almost certainly a game in there somewhere).

There’s one pun for Puss In Boots that got rejected that I loved to bits though, and again that’s because it fit so neatly. In each of the game’s levels there was a fragment of golden egg to collect. When you collected all of them you’d get an achievement. I understand why my idea wasn’t picked for a game with a worldwide release, but I still resent that achievement not being called “They think it’s all ova – it is now!”.

One of the first games that made me appreciate that puns are a force for good was Fuzion Frenzy. This was a party game for the original Xbox, and the puns here were used for naming the individual minigames. However the minigames for Fuzion were handled by two different teams, and the other team didn’t want to play ball, so around half the minigames were named with puns, but half weren’t. So the game ended up being a bit schizophrenic in this regard. We had games called Tailblazer, Blast Man Standing, Rubble Alliance and Twisted System (I love a (somewhat obscure) pop culture reference), and theirs were called functional names like Collector and Bumper Race. I don’t get why you wouldn’t try to spice them up a bit. (As a side note, one of our minigames involved catching falling sparks from fireworks. I don’t think this was one of my names, but up until weeks before mastering this minigame had the placeholder name “Up the glitter”. Eventually we explained to our American producers about cockney rhyming slang, and changed the name for something a tad more acceptable.)

The last game at Blitz that I provided achievement names for was Ace of Spades (I didn’t work on the game, but was called on for the punning), and I like to think some of these are pretty good despite them having to be done at short notice – Turret Syndrome, Mountain Casualties, Butte Hurt… There are two I thought I’d expand on though. The first is “Pillar Assault” – awarded for shooting out a number of pillars in a certain bit of architecture. I have no way of knowing how many people actually spot the loose homophonic reference to Lot’s wife here, but I love including less-obvious stuff in the hope that a few folk do at least notice it. Once again, the punnish element isn’t funny, and is in no way relevant to the game, but it’s a little extra something for those that happen to catch it. And the name fits the achievement like a glove, so the irrelevance isn’t compromising the functionality at all. The second is another that I’m not entirely happy with, but it was just too good not to use. It’s an achievement for tea-bagging enemies (it would take an entire blog post to explain fully why I love this achievement). The name was “Plumming the deaths”. I sniggered to myself for quite a while after coming up with that one, I must admit. But I’m not actually that happy with it. It’s so close, but it’s just far away enough to be unsatisfactory. It wanted to be “Plumming the dead” to make sense really, but “dead” is far too far from “depths” to make the phrase work. Even “deaths” is a little bit more of a stretch than I’d like (that “p” is really important in the word “depths”), so it sits in an uneasy middle ground of not being ideal in either direction – it doesn’t quite sound close enough, and it doesn’t quite mean what it should, but it’s as close as I could get it. If the verb “plumming” didn’t amuse me quite as much as it does I’d have come up with something else instead.

Following up from the obscure reference to Lot’s wife, perhaps the most obscure reference in one of my achievement names happened completely by accident. In Powerup Forever there’s an achievement called “Bully” awarded for squishing 111 tiny enemies in any given level. Why 111? Why not? Round numbers are boring, and people tend to use them without thinking. I think nothing in game design should be done without thinking – you should have a reason for everything. As I said at the start, all names are a chance to amuse the player. Numbers can be too (see 42 and 69 for easy examples). So why 111 exactly? I’m English and I love a bit of cricket. 111 is the English bogey score – superstition dictates that English batsmen tend to get out more often on a score of 111 (or multiples thereof). This score is known as Nelson. Most of the world will take nothing from the total being 111 (or will be confused, which is a positive in my book – anything to make the world a weirder place…), but the few who do recognise what I intended may be ever-so-slightly amused. If I’d have used 100 no-one would have cared either way, so this is a net gain. Anyway, we now have an achievement called Bully where you need to score a Nelson. Result!

So that brings me up to STOMP, where I’m free to indulge myself to the full. Another pun I used in my first trailer was “That really takes the brisket”. I think this one deserves groans. I try not to use puns that deserve groans (people often groan at puns regardless of whether they deserve it or not – but I will admit this does deserve it). In fact, in the trailer the cows were originally in a green grass field, but I changed it to brown dirt so that if I had time I could have added a tumbleweed pass after the “brisket” pun – that’s how bad I think it is. The thing is the pun was originally a potential level name – “Taking the brisket”, and I don’t think that’s anywhere near as bad. I’d happily name a level that. And this is what puzzles me – why am I happy with that, but not the version I actually used? Is it just the attitude? “Taking the brisket” feels kind of passive – it’s just sitting there minding its own business, whereas “That really takes the brisket” feels much more cocksure and in-your-face, and that bothers me.

One final pun – or rather two takes on the same device, and some thoughts upon them. Amongst my very favourite puns for STOMP is a level called “There’s something about dairy”. I am really happy with that one. However I first came up with the dairy/Mary swap for “Dairy Poppin’s” – which will probably still lead to me creating a new game mechanic (or at least some background graphics). But despite these two using the exact same device, “Dairy Poppin’s” is nowhere near as good as “There’s something about dairy”, IMO. I think the main reason for this is expectation. With “There’s something about dairy” you have expectations of how it’s going to end that are then confounded when the switch takes place, but you’ve been given so much to work with that it’s effortless. With “Dairy Poppin’s” the switch happens at the start meaning you’re expecting something to follow naturally from “dairy”, but then have to work backwards once you’ve heard the lot to make sense of the thing. There’s also the fact that “There’s something about dairy” immediately makes sense as a sentence in its own right where “Dairy Poppin’s” doesn’t – and I think even if I do get exploding cow bombs in the game to illustrate the concept it still won’t ever be as strong.

That’s probably enough for now. I may well revisit the topic again though – whilst I have well over a hundred cow puns lined up for STOMP (I’m hoping I get to use them all), and I’m still coming up with new ones all the time, and I would love to figure out what really makes the difference between good and bad ones.

I <3 3D

Later than intended (I took an impromptu holiday) here’s a quick post about why I love making 3D games (or games with 3D assets at least).

One of my favourite things about working in 3D is that it allows me to monkey around with the camera angle really cheaply. As mentioned in my WIP for Super Critter Kill, that game started life as a different game entirely, and all it took was a camera switch and a fake arm to make it look like a completely different genre using exactly the same assets. I’ve also done it in another old project that I’ll hopefully do a WIP for in the near(ish) future. So it’s only natural that at some point I’d have a play with the camera in STOMP too, and so far I’ve done 3 different things.

The first thing I tried really early on was simply to make the camera more dynamic by making it look-ahead of the player – the faster they’re moving the further it looks ahead.


I rather like this, but  I’ve had it disabled ever since because it needs more work (it’s a tad harsh), and needs testing with finished levels to assess whether it affects gameplay negatively. In its current, 2-lines-of-code, implementation it also suffers from a big problem which is if you smack into a wall at speed it instantly slams the camera back to default which is really jarring – so if I keep this it’ll need some easing applied to fix this (which would help smooth it out generally too). Also camera shake values that work well for the fixed camera are pretty brutal with this one.

The next thing I tried was more of an experiment – fixing the camera to the player’s ship so it rotates with them. This causes the world to rotate around the player, with the player’s ship remaining vertical on screen always – like in the (top notch) arcade game Assault (there’s another future WIP subject here). I don’t have any video for this, sadly. I thought this would be unplayable, but actually it wasn’t *that* bad. It was a little strange, and fairly tricky to find “up” so that I could hover, but I could actually play it. The biggest issue was that because the camera was tightly tethered to the ship, and because the ship turns fast and stops turning instantly, and because you’re constantly making adjustments to your heading, the scenery whips around constantly, spinning and stopping in a really harsh fashion. It should be possible to alleviate this with easing again – but I wonder if that might feel a bit woolly. It should be fairly quick to try though, and if it works it may well make it into the game as a bonus.

The last thing I tried – and I’m amazed it took me so long to think of giving it a go – was to make the camera 1st person (okay – it’s strictly 3rd person – but only so you don’t get weird fragments of ship obscuring your vision). This again is really quick to implement – quite literally 2 lines of code. But this time I was right – I thought it would be largely unplayable, and it certainly is. Largely. However it does look kind of cool.

Obviously the turn speed is far too quick for comfort, the lack of awareness of your surroundings is a killer (maybe a rearview mirror would help), and knowing which way gravity is acting is really tricky (it’ll be so much worse when I start switching gravity around later in the game). It also shows up the fact that the scenery is “sliced vertically” and that my skybox has no proper roof on it, but those are minor concerns. However I may still try to find a way to get it in the game. Even if I just throw it in as an easter egg the player can give it a pop with invincibility turned on if they wish.


One of the things I’m keen to do with STOMP is to make sure that it is accessible as possible. Thrust-style games are fairly tricky beasts if you’re not used to them, so I want to make sure that newcomers can have a pop at this one at a level that suits them, and also experience everything the game has to offer. Here’s how I’m going about that.

First off – and the most obvious approach – the game features difficulty levels (currently easy, normal and hard – but I may well expand this, if only to add some super-hard stuff). The difficulty levels aren’t fully implemented yet, but they affect things like enemy fire rate, bullet speed, accuracy etc, rather than just altering the hit points of enemies (which currently I don’t plan to do). I’ll probably extend this so that the easy difficulty level also mitigates damage taken from enemy fire and impacts too.

On top of that I’m also giving the player the option to turn on invincibility to play the game. This makes them impervious to damage (obviously) but also grants unlimited fuel (and by association therefore grants infinite shielding). This allows the player to practice the tricky control method in safety without having to endlessly play the tutorial level where they’d be largely safe. They can play the whole of the main game this way (in each of the difficulty levels), and unlock each of the levels for single level replay too. The only thing that will be restricted when playing with invincibility activated is posting highscores (although scoring potential will be reduced anyway, since the game won’t award low-damage and fuel remaining bonuses to invincible players). This ensures that anyone at all can see all the content in the game that they’ve bought.STOMP_levSelect01

I’m toying with the idea of splitting the invincibility option into bits too so that the player can toggle whether they need to refuel, whether they take damage from enemy weapons, and whether they take damage from collisions. This not only provides the most options for tailoring the game to suit the player, it also allows the game to be played differently – certainly the option to ignore collision damage would allow the player to rattle around the levels like a thing possessed which could be fun. (I’ve just realised that if I add impact damage to enemies and other destructibles that you hit (not currently the case) that this could be a thing in its own right. Feature creep ahoy…)

The game also features bonus mini-games. I’m hoping to have 24 of these – 3 for each of the game’s 8 levels. One of these will be unlocked by collecting a pickup hidden in each level – it doesn’t matter if you do this whilst invincible or not really (whilst it’s true the freedom to explore given by not having to worry about fuel makes this easier, there’s no point in making the player do it again “properly” once they know where it’s hidden). The other two are for completing each level with a good score, and a fast time. These will still be unlockable with invincibility on – but because they’re skill-related these will only be partially-unlocked if you do it that way. You will be able to play the mini-games (which is the important thing), but the unlocking won’t contribute towards completion of the game (and any achievements I happen to tie to that), which only really matters to people who care about that sort of thing. You will still need to hit the goals normally to achieve completion.

Beyond that, in the menu I’m giving the player options to unlock the main game levels and each category of mini-games at the press of a button anyway. You don’t even have to play the game once to get at all the content. Why? Why not? The player will have paid for it, and it makes no sense to wall them off from it. If they aren’t skilled enough to beat the time or score I set for a level – or if either of those goals don’t really appeal to them – I’m happy for them to get the content without jumping through the hoops I’ve set up. And if I’m allowing the player to unlock them whilst invincible, then the only thing standing between the player and the levels is their time – something I’m loathe to waste. People who care about unlocking things the way I’d like them to are free to ignore these options, and gain the satisfaction that that provides. People who don’t can just cut to the chase.

As with using invincibility, these options only partially unlock the levels – if you want achievements and completion you still have to actually do what the original goal was. I also plan to allow to allow the player to lock these things again (although I’ve just realised I can do this on two levels – lock everything (to wipe the slate clean so that it can be done all over again) or just lock those that haven’t been fully unlocked already – more feature creep, perhaps).

There’s an added advantage to this too. I’ve personally played many games to death on one machine, and then installed them on another and been annoyed that I couldn’t get at my favourite bits until I’ve unlocked them all over again. This fixes that.

This is the sort of stuff I’d love more games to look at doing. I can count all the novels I’ve started reading and not finished on the fingers of one hand. I’ve lost count of the number of games I’ve given up when encountering difficulty spikes. I’m not a big fan of story in games, but still it annoys me that each of those is an unfinished story that I’d have happily followed to the end if the game had let me. Why not let me toggle invincibility and bludgeon my way through it? The game can withhold achievements from me for wussing out by all means, but it doesn’t have to deny me access to the rest of the game I paid good money for just because I can’t beat a particular collection of poorly-judged design decisions (usually a boss fight).

W.I.P. 5 – Maps and Legends

OK, here’s a look at the hobby project I was actually working on when I got made redundant and decided to go Indie – Maps and Legends. The name once again was very much placeholder (and REM fans may recognise it as the title of a nice track from the album “Fables of the Reconstruction”). Maps and Legends (MandL as I tend to call it) got shelved immediately since there wasn’t a chance it would be completed before I ran out of money, and I’m not entirely sure how easy it would be to make money from it. Here’s a screenshot:

mandl04A quick disclaimer on the graphics – I really don’t like how it looks. The whole game is really rough tbh, but specifically the island graphics are rubbish. The thing is it’s largely unimportant – the game could be in lushly textured 3D, plain old sprites in 2D or even ASCII – it’s just a map at the end of the day – the gameplay is all in the text.

Another disclaimer – having said that the text was all first draft too. The examples I’m posting could all do with work.

Also, once again there’s no playable version. As it stands it’s awful – largely unfinished, with most of the existing content actually disabled, and what’s left in there happening all the time. When making a game built almost entirely of random events you soon learn that you want the ones you’re currently working on to happen all the time, and everything else to GTFO.

So first a quick overview. MandL got a quick mention in my first WIP – the game was born as an entry for a coding competition back at Blitz Games with the theme being procedural generation. I decided to procedurally generate an island populated with tribes and NPCs that the player could explore with the intent of creating a game a bit like Strange Adventures in Infinite Space or The Wager. There would be no combat – the game would be all about decisions and consequences. It soon became clear that this was far too large for the monthly competition, so I split that away and made Super Critter Kill for the competition, and kept MandL as my main project at home.

As a brief overview of the game, the player takes the role of a Victorian explorer and would start having made landfall on a mysterious island shrouded in darkness. The choice of Victorian explorer gave me a very clear voice to write with and lots of character, but also led to me adding a faithful manservant who would accompany you, which opened up lots of opportunities for humour.

The player explores by moving one square at a time, and when they enter a new square they might encounter a tribe or an NPC who they could talk to, or they might get a random event, which could be based on their location or the time of day, or any number of other triggers. These events could be chances to gain cash, useful items, extra resources etc. but could also be much more complex, or just be for fun. Below is one example where the player can lick a frog to see if it has any special effects (they can also get their trusty manservant “Branston” to do it instead).


This event could lead to one of a variety of “drugged” status effects which would have all manner of repercussions (some good, some less so), or could do nothing at all, as below (where your manservant is now called Duckworth-Lewis – note to self: random generation makes coherent screenshotting very tricky indeed.)

The original idea was to create a game that could be played in a lunchtime, but would stand up to countless replays with the player always getting new adventures (hopefully). So there had to be loads of these events, and to keep them fresh they needed to vary each time you received them – hence numerous “drugged” effects coming from one event. However to go further I then decided to try and generate the description of the event itself – so that even if you happened to get the same event, chances are you wouldn’t have read the same words before. This would involve all sorts of techniques – random phrase selection, changing events based on the player character’s gender, what they were wearing and so on. So if you met an NPC whilst wearing a remarkable hat you might get different text than if you weren’t. Obviously this makes generating the events far more tricky and time-consuming, and in truth I’d barely scraped the surface on this aspect.

And the plan was even larger still – those “drugged” effects I mentioned earlier included “paranoid” which would stick with the player for the rest of the game and would affect a huge number of events – meetings with NPCs, dealing with tribe leaders, and probably most mentions of the player’s manservant. (If theres enough mileage in it I could also include the option of a paranoid manservant if you chose to get him to lick the frog instead.)

Another good example of the scope of the game (and the feature creep involved) was an event that would occur on the coast – finding a message in a bottle. This could turn out to be many different things – treasure maps, useful information, coded messages and loads of other things I haven’t even thought of yet. It could also simply be Victorian spam (note that this example is tailored to the player being female – with the player’s manservant (now called “Ives” – thanks again random number generator) being judged as satisfactory (the typo in “satisfying” has now been corrected, fyi):


But then I came up with the idea of it being an order for pizza. This led to me spending a fair while writing code to randomly generate pizza orders in a variety of styles – a basic list, a Victorian gentleman, a pirate etc. This involved creating daft names for pizza establishments and a full menu of pizzas, side-orders and beverages so that every order would be different. The text in the following example needs a ruddy good editing, but it’ll do as an example:


So when playing the game if you move into a beach tile there’s a smallish chance you’ll get an event. There’s a small chance that this event will be a message in the bottle, and then there’s a small chance that it will be a pizza order. This all adds up to the chances of you getting the pizza order event in any given game being basically very low indeed. Regardless, I spent lots of time making sure that if you happen to get it again in a different game chances are it will read entirely differently. That was my intended approach to many of the events in the game and there would have been hundreds and hundreds of them.

Furthermore, with the pizza example I figured if someone’s ordering pizza then somewhere there must be a pizzeria – so why not this island? So I added a chance of the island having a pizzeria. Now when the player gets the pizza order event they can choose to throw it back in the sea, take the money that’s included with the order, or take the bottle – each of which then allows the interaction with the pizzeria to change if they happen across it whilst exploring. The original low-odds pizza order event has birthed an entirely new set of events that now need to be written.

This is feature creep writ large – something that conventional game-dev wisdom is largely against – but here I’d argue it is critical to the game I was making. It’s something that one person on their own can afford to do, and in many cases should do – providing they can see that it’s actually benefitting the game.

An additional example of this is the pack animals. Along with your manservant, you’re also given a pack-animal at the start of the game. This is chosen at random (horse, donkey, ox etc.). It would then pop up from time to time in events with different outcomes for each (if a bear attacks it might scare off a pony, kill an ox, or be scared off by a horse as it lashes out with its hooves, for example). Also each type would generate its own events from time to time. Basically each pack animal was a significant amount of work, but only a small part of the game. So adding a new one should require a lot of justification – right? Nope! It needed me to think up just one pun about a goat.

To add the goat (an unusual choice of pack animal admittedly) I wrote a new intro that involved your intended pack animal being washed overboard from your boat on the voyage to the island, leaving you with a goat that was meant to be used for milk/food. This can’t happen often (not only would it get old fast, but also it would be a handicap for the player because the goat – crucially – can’t carry as much weight as the other critters), so you’ll be much more likely to get one of the other animals. At some point I’d then need to write all these goaty events and alternatives as they occurred (much of this isn’t yet implemented). Finally I then needed to add a very low-odds event where you stumble across a large stash of very heavy treasure.

All of this extra work is so that if you happened to get the slim chance treasure adventure whilst having the rare goat pack animal you’d find that the goat couldn’t carry all the heavy treasure. I was prepared to do all this extra work for the chance to use this line:

“We’re going to need a bigger goat.”

Get in!

I love puns, and think they’re worth celebrating, and will go to great lengths to do so. And whilst there will be a lot of extra work to get this one pun in, its all a bunch of opportunites to make even more good stuff that will benefit the game. And beyond that if anyone playing the game finds that as amusing as I do, chances are they’ll tell their friends about it, and that is worth an awful lot.

That there is one of the reasons I love this game so much, and also the reason I immediately put it on the backburner when I went indie. The scope of it allows me to indulge all my silly ideas, whilst writing about pirates and dragons and fairies and elves and anything else that I can think of, but it also means that as a job of work it’s an unkown size, certainly already very large, and would continue to grow if I worked on it.

A huge issue with it as it stands though is that it’s really inefficient to work on the way I currently have it. Every event is custom written, because every event is generated differently, and I never sought to mitigate this at all. Actually creating content for it is cheap and easy – it’s just text – but the way it’s currently implemented means getting it actually in-game, suitably randomised and generating the right number of player responses based on circumstances (if you’ve lost your manservant for example (snigger) then you can’t get them to lick the frog, obviously…) is much trickier than it needs to be.

However, I am currently looking at getting this back up and running in Unity as a side project. The main plan for it is to look at solving the issues with implementation to make it as easy as possible to add content, because if I can get that sorted, it’s an ideal project to have pootling along in the background. It just needs shedloads of text throwing at it, and that can be written anywhere and anytime. As mentioned at the top, the graphics are immaterial, so if I can build up the essential content to a point where it looks like a viable project I can start worrying about getting it to look the part so that people will be prepared to pay for it.

The Name Of The Game

I’ve mentioned before in my blog that I struggle with naming my projects, and STOMP is no exception. I’m still not sure what I feel about STOMP (Super Thrustforce: Orbital Meat Police) as a name. I settled on it because the game needed a name at the time, rather than because I felt it was a particularly amazing thing to call it. Obviously I’d love to have come up with something I thought was perfect for the game, but there came a tipping point where it was more important that the game had a name, than that it had the perfect name. STOMP was good enough.

Here’s how I got there.

I’ve always wanted to make a Thrust-style game, but until getting my paws on Unity I haven’t really had the tools I needed to do the job. (I did pitch a really nice Thrust-like game for Blitz Games Arcade division, but sadly it didn’t get picked up). I also had a stab at making one in XNA, but knew it was probably doomed to failure. The name of this project though was “Thrustforce”; a portmanteau word of the two main influences – “Thrust” on the C64, and Amiga classic “Gravity Force”. As expected I didn’t get far with this in XNA, but the name would return later.

So fast forward to Christmas 2013 and I’d been trying to think of a decent name for the game for a good couple of months on-and-off and failing. The cattle abduction theme had been in place for a little while now, but I was still thinking of maybe having different aliens which abducted different critters, so I needed something general. “Meat” then was the starting point. (I’m not ruling out other critters, but the cows are providing so much great material I don’t think I need them).

So then the idea of “Meat Police” popped into my head – it says what you’re doing in the game and I found the notion amusing. So then we just need to say where the meat policing is happening, and for some reason “Orbital” was the first word that popped into my head. Orbital Meat Police. Whilst I’m not going to say that STOMP as a whole is a great name for a game, I find something inherently pleasing about “Orbital Meat Police” as a phrase. Orbital Meat Police – it trips off the tongue nicely. It’s no “cellar door” perhaps, but there’s something there I like. I later tried replacing the “O” with “Off-World” (which would allow me to set a level in deep space, if I wanted, without being semantically incorrect), but it’s nowhere near as nice. (If I do set a level in deep-space I’ll happily let the name be wrong.)

So, Orbital Meat Police it was. However, the thing I really wanted from the game name was to tell the player what the game was. Orbital Meat Police tells you what the mission is, but not what you actually do. I wanted this specifically for fans of Thrust-style games. I’m one of them, and know I will happily jump on any new Thrust-style game I come across. I know if I read a name that suggests the game is a bit Thrusty (“Thrust”, “Gravity”, “Rocket” maybe…) then I will investigate it*. So that’s a thing that needs to happen, even though it almost certainly necessitates the intervention of a colon.

The first thing that occured to me though is that I’ve now painted myself into a corner. Orbital Meat Police gives me “OMP”. Whatever I add now really has to make the best of that, because you don’t get a free OMP too often, and so wasting it on something meaningless like AOMP, DOMP or VOMP would be unthinkable. So let’s look at the alternatives – POMP, ROMP, WHOMP, STOMP… “Hang about, I’ve already got a T”.

Thrustforce: Orbital Meat Police. Sorted!

The “S” is a no-brainer. I’ll happily stick “Super” on the front of any name – it’s probably harder to get me to leave it off, to be honest. “Super” is a great word. It isn’t trying anywhere near as hard as “Hyper” or “Mega” (I personally would probably only ever use those in parody). It’s enthusiastic without being obnoxiously so. In certain circumstances it can come across as charmingly naive, which is a lovely thing to be (One of my very favourite uses of it is in the shoot-em-up Gundemonium Recollection, where the 2nd level is called “Super Train Robbery”.)

So, STOMP it is. As I said at the top I’m still unsure what I feel about it as a name, but it has a good stab at explaining what you are and what you do and that I’m really happy with. It also gave me “STOMP” which is as good an acronym as I could hope for, but may well also inform some parts of the game (I already have a model of a shiny STOMP badge that could be used to represent this gung-ho squad of militaristic space police should I decide to push that angle).


*I will also be disappointed when said game doesn’t turn out to be Thrusty. /Gives Gravity Rush got a particularly withering Paddington Hard Stare./

Sneak Peek – Super Thrustforce: Orbital Meat Police

With my game featured on flyers at GDC and soon to be shown (in a small way) at EGX Rezzed it occurs to me that perhaps I should at least acknowledge its existence, even if I’m not ready to push it in people’s faces just yet. So a quick blog post will have to suffice…

So this is Super Thrustforce: Orbital Meat Police, a game about aliens, cattle abduction and retribution via the twin barrels of your spaceship’s miniguns. That and cow puns. Lots and lots of cow puns.

I’m not ready to announce too many details on the game  just yet, but I’m currently planning to release on PC, Linux and Mac at some point this year.

I will hopefully do a more formal announcement in the near future. I also intend to start blogging occasionally about development, so please follow me on Twitter where I’ll announce new posts.

A note on the music in the video. Originally I cheekily used the awesome Orange Goblin’s equally awesome track “Your world will hate this” for this video for the Rezzed game show (and before that I had Ace of Spades), but wanted something I could use freely to post on Youtube. More out of hope than expectation I started with Empire of the Claw, whose music I used in my game “A Vicious Circle”, and when I dropped “Trance of the 80’s Arcade” in I was taken aback by how well it fit (from a things-happening-at-serendipitous-moments point of view). Ideally I wanted something a bit more rock (hence the original Orange Goblin), but so many bits work here that I felt I’d be daft not to run with it.


W.I.P. 4 – Torus

This is the work-in-progress for a project simply called Torus. There’s actually not much game here, but I think it’s an interesting little project nonetheless. (When capturing video for this I noticed that I actually got around to calling this Torus Trap, but I never liked that much, so I doubt it would have stuck.) Note that there’s no build provided for this project, simply because in the state I left it, it isn’t actually worth playing.

Torus was one of the first projects I worked on when I started using XNA, and it many ways it shows. Perhaps the most notable thing about the game is how much of it is based on limitations and restrictions. I’ve mentioned before that I like a good restriction or two, and this is perhaps the clearest example I have.

First up – the entire premise of the game came about because I couldn’t do complex collision like meshes, or even non-axis aligned boxes. So the first limitation was that I’d only use circular or spherical collision (or anything I could extrapolate from these). Previously in C++ I’d worked on a project called Radius which was a little like Gyruss or Tempest with the player’s ship roaming the outise of a circle shooting inwards. So I decided to take that idea and then wrap it around another circle – and have the player roaming the inside of a torus. They’d be orbiting the circumference of a circle as before, but could also move this circle around a larger circle into and out of the screen. It’s hard to explain, so here’s a video of it in action.

The second limitation I had was that, at the time, I couldn’t find any example code for 3D particle effects in XNA. Basically I wouldn’t be able to make nice fiery transparent explosions. Without this I decided that I’d look at somehow cobbling together some kind of shattering using debris objects. I’m pretty sure with hindsight this would have looked awful, but I made the call and it led me to then decide that everything would be made of metal. That decision then informed pretty much all of the rest of the design.

As mentioned, the player was going to be moving around a circle – this then became a physical ring object. This ring then needed to move along the inside of a torus. I’m a big fan of machinery and intricate mechanisms, so I then decided to mount this ring on rollers that would transport it around the torus. An issue here was that the if the ring sat on top of the rollers it would either waste an awful lot of screen real estate, or the roillers would have to be small and unimposing. So instead I decided that the ring should pass through the rollers – this allowed them to be suitably chunky, made the engineering pleasingly elaborate, and also allowed the rollers to act like shields when the player was inside them. As an aside, the decision to use three rollers was an obvious one (three of anything is generally more interesting than four), but led to the knock on realisation later that this was getting fairly close to looking like Space Invaders wrapped around the inside of a doughnut.

With the ring and rollers requiring elaborate engineering, I then decided that the art style should head towards Steampunk, and this then provided the backstory for the game, and also the design for the HUD and front-end.

The backstory was going to be something along the lines of scientists trapping some kind of energy-based entity in a torus-shaped containment facility to extract energy from it – there would be farms built into the torus to do this. The trapped entity gets a bit miffed about this, and starts spawning enemies to attack the farms. The player then takes the role of a fighter defending the farms from the onslaught. The intention was that it would probably feel a bit like Defender, with enemies spawning around the torus and heading to the farms, with the player intercepting them before they did too much damage. Almost none of this was implemented, but I quite like the premise, and it would have allowed me to make even more over-engineered machinery, since the energy farms would need to retract into the wall of the torus to allow the ring to pass over them.

The HUD/front-end is perhaps my favourite bit of this project. With the game now being made of elaborate mechanisms it made sense that that should extend to the rest of the project, and so I made a nice mechanical heads-up-display, and front-end complete with iris door (this one needed work, but man, I do like an iris door). Scoring and lives weren’t implemented so the HUD currently spins through an automatic cycle to show itself off. Here’s a short video of the front end. I was planning on making this much more intricate, with many more moving parts

One thing to note about this is that I haven’t the first clue about using render targets in XNA, so that HUD is just hanging in space in front of the game elements so that it appears in the right place on camera. It’s a total fudge, but it worked so I ran with it. Here’s a final video with a couple of extra camera angles to show what’s actually going on.

Also of note from that video – the player isn’t actually moving along the torus – the torus and enemies are simply rotating around the axis of the torus. I’m pretty sure I first decided to do it this way because otherwise the lighting would change as the player moved, but it’s probably a good approach, because it simplifies the maths at the bit where the action is.

As you can see from the videos there’s very little in the way of gameplay here, and I think that’s largely down to the fact that it soon became clear it would probably be rubbish, quite frankly. I got the placeholder red sphere enemies in, and soon realised that actually aiming at them would be tricky due to having a 2D plane of influence in a 3D world (the elaborate grid suspended within the ring is to help aiming – if the enemy is embedded in the grid you can hit it, but that’s just a bodged remedy to a symptom, not a fix for the underlying problem). It also looks pretty poor, since at the time I had no knowledge of shaders, and was struggling to find example code that I could use. I think I only kept plugging away at this as long as I did because the engineering was fun, but shelving it was a smart move because making it look good was probably beyond my ability with XNA back then, and I suspect the underlying problems with the core game design would always have made this a tricky one to make fun. Most of the remaining design decisions would probably be taken to mitigate or counter the inherent weakness of not being able to aim very well (I’d already considered making the enemies into snakes (of spheres) – not because I wanted snakes, but because it would give the player a chance of actually hitting them reliably).

Having said that, I’m half tempted to drop the meshes for this into Unity and throw some nice metal shaders at them, just to see what they’d look like…

W.I.P. 3: Vadespacers (5, 8)

This is the Work-In-Progress for a game that ended up being called Vadespacers (5, 8). I’ve mentioned previously I’m rubbish at naming games, and this one got saddled with a name that’s a cryptic crossword clue. (Technically it could do with a definition in there to be a perfectly valid clue, but since it’s the name of the game I’d suggest that’s implied.) The game is so clearly my take on Space Invaders that I wanted to get that into the name somehow, but there are silly numbers of games called Space Invasion and Space Assault etc. so I wanted to pick something a bit different.

Below is the video – as you can see it’s so nearly a complete game that it’s daft I never finished this. As usual the current build of the game is available to download at the end of this post.

So on to the game then. I started making this at one point when Dogfight Thing was dragging on a bit, looking like it might never get finished. I fancied doing something where I already knew all the answers (yeah – right!) and I’d never in 30-something years of making games had a pop at Space Invaders. It wouldn’t just be Space Invaders though – I needed a hook, and the one I went for was to make it a bit more in-your-face. I didn’t want to change the game much, just give it a bit more attitude, make it snappier and a bit more feisty. I think it was getting there.

So before starting coding the main thing I wanted to change was the main weapon, and the first thing that came to mind was to replace the “one shot at a time” mechanism with the polar opposite – a minigun. I knew this could be balanced out (by giving the invaders hit points probably) so ran with this as a plan.

Another decision I took really early on was to give the player a single life to keep things lively. I wanted to make the game much trickier overall anyway, and snappier as mentioned above, and that felt like the player should only get one chance at success. As much as I love the traditional arcade “3 lives” approach, it’s kind of frustrating when you lose the first one cheaply and still have to play on. Better perhaps to make the one life all you have, and make any error equal game over.

Getting the invaders working was largely simple, but there were several things I’d not considered beforehand. That whole “doing something where I already knew all the answers” thing was misguided even with something seemingly as simple as Space Invaders, but most of the problems were easily solved.Vadespacers002

The implementation of the minigun weapon defined how the game would feel, and it’s something I’m happy with (although it could do with a better special effect). I wanted to speed the game up a little, but not too radically, so that meant the invaders had to take a fair bit of a kicking before exploding. With each bullet impact I then played an impact sound and jittered the victim around a little – this led to a proper feeling of them being riddled with bullets. It started to feel like you were giving them a real seeing-to (this works especially well for the bonus UFO I think).

The main design decision I struggled with was actually the shields. It’s not Space Invaders without shields, but I didn’t know how best to go about doing erodable ones like the original had. So I came up with a couple of alternate plans – either give the player a toggle-able portable energy shield that would form around them, or make the shields permanent. I quite liked the portable energy shield idea for shaking up the gameplay a little, but it felt a bit too far from the template, and with a little thought it had issues. It would be OK for it to stop bullets, but it couldn’t stop invaders, because that would make the shield incredibly powerful (unless I rationed it). So I went with the permanent shield instead (without properly thinking it through admittedly). It did tie in with the player being kind of clunky (the aliens use energy weapons, the player is flinging lumps of metal skyward as fast as they can), so strapping a couple of blocks of concrete in the air above them fit quite well. I hadn’t considered the fact that it would also have to wipe out invaders at the time, but later came to believe the game still works if invaders that get below shield level are considered to have invaded and ended the game.


Next I decided to add the rocket launcher to the game – the player already has a minigun, why not a rocket launcher too? To temper the usefulness of this I first made it so that if the player uses it behind a shield it kills them. With just the one life this perhaps feels a tad harsh (albeit in-keeping with what I wanted for the game), so I’m on the fence about this decision. I also added a chance for dead invaders to drop out of the sky, rather than simply exploding when killed. This redressed the balance in the invaders favour a little since the falling corpse will kill the player if they get hit by it, and using the rocket launcher potentially creates several of them – adding a bit of risk to using the thing. I also think it adds to the feel of the invaders being given a thoroughly good kicking, so that’s a definite plus point.


One final thing I added which is in the release below was a fast mode which simply makes the game play at twice normal speed. It was a quick and dirty trick to pull, and needs some balancing, but I quite like the feel of it. It’s much more of a white knuckle ride, and perhaps a tad closer to how I’d like the main game to feel. One of my favourite type of arcade games are ones that feel like they want you off them. Robotron always felt like this – it took your 10 pence piece and then did its best to throw you off. It’s the game equivalent of a bucking bronco – part of the fun comes from seeing how long you can defy it and stay on.

There’s not much more to say about this one. Basically it got to the stage shown in the video, and it’s not too far from done. It doesn’t feel quite how I want it to yet – it’s not punchy or mean enough. It maybe needs a bit more targetted aggression. Currently enemies fire at random and whilst they do fire fast shots if you’re close it’s not enough. The random selection works fine in the original where they’ve got shields to erode, but here it might be better to add a bit more malice – picking the right invader to fire (if only occasionally) and using deflection to fire at where the player’s going to be when the bullet lands.

I was also never completely happy with how the invaders sped up as their numbers are reduced. I tried a few approaches at monkeying with the numbers, but nothing really felt right. Stupidly I didn’t Google it at the time – the way the original game does it is easily found, wonderfully elegant, and should be easy to implement in my game despite the fact that my invaders move smoothly rather than in steps.

IIRC my game also doesn’t get harder over time either – you get the same wave over and over again. Fix that, work on the animation (only one invader type animates, and it doesn’t do it well either), tweak a few settings here and there, redo the lousy background mountains, make the bonus UFO score actually mysterious (involving rocket counting, akin to the original game), and this would be done.


In my defence for not finishing this when it was so close, I wanted to get it working with the Indie City portal to get online leaderboards in since it’s a pure score attack game, but after getting it working initially, an update to the IC SDK caused a bug with my implementation of it, and that stopped me dead in my tracks. I might consider finishing this off at some point and releasing it as a freebie (or maybe as charity donationware).

The one regret I have with this is that I didn’t set the screen to be portrait at the very start rather than using landscape. I’m not sure why this didn’t occur to me at the time – a defining point of the game is the overall shape of it, and mine is just wrong – too wide. It works my way I guess, but if i could change anything that would be it.

OK – here’s the download link. Instructions are included on the front end screen, but I left in my invincibility testing mode, so press “i” to cheat if you feel that way inclined.

Click here to download Vadespacers (5, 8)

As usual it needs the XNA 4.0 runtimes, which you can get from here:

Click here for the XNA 4.0 runtimes

W.I.P. 2: Dogfight Thing

This is the work-in-progress for Dogfight Thing – a long-running project from two or three years ago. There’s a playable download for PC at the bottom of this post of the current state of the game which is exactly what is shown in the video – i.e. lacking a lot of gameplay.

Oh Dogfight Thing – how I wish I’d finished you. You never even got a proper placeholder name.

Dogfight Thing first started as a dabble with making something a little like Time Pilot – one of my favourite arcade games. It soon became an attempt to create the kind of simple dogfight game that was ubiquitous on 8 bit computers back in the day, or indeed as one game type of the classic VCS game Combat.

So I quickly knocked up a biplane model, because biplanes are brilliant (and it also gave me an excuse to give the pilot a nice flappy scarf). The first pass was a Sopwith Camel complete with authentic colouring and RAF rondels on its wings.

Before implementing player movement I then had to add some scenery so that you’d be able to tell you were moving since the camera would be tracking the player. I was reminded of one of the dogfight games on either my Vic 20 or C64 which had the player landing and taking-off from a runway, and remembering this fondly knew that my game had to feature the same mechanic so built an airstrip at the left of the map. The immediate thought was then if I’m taking off to start then so should the enemy, so I built another at the right, and this kind of cemented how the game would develop for a while – with two opposing forces fighting with the same tools.



With that in place I then got the player moving at a constant speed, and rotating to provide the nice loopy control method. However there was an issue in that if you perform a half loop then you end up flying upside-down. The old games used to prevent this by automatically performing Split-S and Immelman turns – half-rolling/half looping, but I didn’t want that because it would make full loops look strange, and there’s a lot of fun in just lazily looping the plane about. I briefly considered auto- half-rolling if the player stayed upside down for a short while, but that sounded nasty, so the only thing to do was add a button to half-roll. This solved the problem, but also added the ability to roll whenever you want which was a definite bonus. I later added trails to the wingtips when rolling turned out to be one of the things I liked doing the most (and indeed the ability to turn the trail length up to “Frankly Silly” in the options menu).

Adding the first enemy to shoot then brought a change of direction. I had a Sopwith Camel, so the obvious choice was to add a nice Fokker as the opponent, but at this point I decided I didn’t want to go there. I’d already got a nice blue sky with fluffy white clouds in place – this didn’t feel like the right place for real war. So I recoloured the player plane in nice bright red and made a blue copy for the enemies. At this point I decided that nobody dies in the game (pilots parachute safely out and toward the camera out of the 2d-plane that the game takes place on). I also decided that since the planes were identical that the people fighting were divided purely by their choice of colour – that was the only reason for the fighting (like the cat race in Red Dwarf). Further to this I then decided to try comic book style explosions, which I rather liked.


I think the art style was why Dogfight Thing never got a proper name. I usually like to pick a name (even a placeholder one) to help define the game and inform decisions throughout. I also like to find a nice font early on for the same reasons. The bright and breezy feel of the game possibly meant that this was less pressing here – it was the touchstone for everything else (when I added smoke trails to damaged planes I started out with white smoke that went black as more damage was taken, but this clearly isn’t a black smoke game, so I soon changed it for denser clouds of white).


Back to the name – I’d been toying with were really simple names like Super Sky Pilot, but never liked any enough to commit to. I tend to struggle with names for games, which is a little strange because I love naming things like achievements. But then you can get away with a pun or a cultural reference for those – they can be silly and throwaway, whereas I think a game name needs something more – it needs to be more robust.

The next thing I added was bombing and this played nicely too once I’d got the physics working OK, and with that I needed something to bomb, and this is when the idea to make the player a part of ongoing war came about.

The idea was to give both sides armories that would produce tanks and other vehicles which would automatically move toward their opponents airfields. They’d battle each other when they met, but the player and the AI could swing the odds by bombing the opposition tanks, in an attempt to allow them to capture the enemy airfield. A fair bit of work was done on this and I added things like spotter balloons and flak cannons, and had plans for zeppelins and bombers and additional ground vehicles.


But development was taking ages. Suddenly my simple dogfighting game now needed the best part of a full-blown cartoon war in it. Something had gone wrong – it was far too big. I called a halt and had a rethink.

A new plan was made – I shelved a lot of ideas, and decided to make it asymmetric. The player would be given an HQ to defend, and it was just them against the enemy army and air force. I’d make it level based with each level just requiring a certain number of tanks/planes and flak cannons to be destroyed. This was much more manageable and was still the plan when I stopped working on it (probably distracted by a new idea).

A couple of additional notes:

One feature I liked in this was the sortie score functionality. The idea being that after taking off any points scored were added to the sortie score, and kills and other feats would add to the sortie muliplier. The sortie score however would only get banked to the real score when the player landed to end the sortie – adding a real risk/reward mechanic to the combat – as the player started to take damage they’d be torn between banking the points and getting repaired, or staying out and risking the lot. Obviously without much in the way of threat currently it’s not really shown off to the full right now.

I’ve mentioned how the overall design spiralled out of control, but here’s a smaller example of feature creep. The spotter ballloons I added looked nice, and were fun to pop, but only brought a collision hazard to the game – nothing more. Yet, once in I felt it needed to be done properly. To that end if you burst the balloon the basket falls and the spotter parachutes down. The basket is shootable until it hits the ground if you’re quick. If you shoot the basket the spotter parachutes away, the balloon floats off, and is shootable until it gets too high. If you fly the plane through the cables in the gap between the basket and the balloon, you get a bonus, the balloon floats away, the basket falls and both are still shootable. If you shoot both you’d get a combo bonus. That’s a lot of work for something that is just an obstacle.

The thing that’s most noticeably missing is AI for the enemy planes. I was tempted to say I’m terrible at AI, but I’m not – I’m just really bad at sitting down and having a go at it. I want to do a really good job of it, and so I put it off to do a proper job of it later, and then never get back to it. The daft thing is much of the time you probably don’t know what’s going to work until you’ve tried something, and then it often becomes much clearer. I need to work on this going forward.

I would dearly like to return to Dogfight Thing, but I’m pretty sure it won’t pay my rent so I’m going to have to leave it for now.

Click here to download Dogfight Thing for PC

Click here for the XNA 4.0 runtimes