Storage solutions

Right – time to drag myself a little more up to date here. In the last post I’d introduced my “Harvest-A-Moon” game and basically said how I’d realised the game seemed a lot smaller than I first feared, and that the major issues were things like animated characters and enormous amounts of GUI. In this part I start by trying to tackle that second bit.

So, I’d made a start on the inventory system with the quick inventory (the bar of heads-up display that sits at the bottom of the screen and lets the player select what they currently have equipped easily). This is just the beginning. I also need a main inventory (what the player can carry essentially), a storage inventory (often dealt with by crafting storage chests and the like in games like this), and a shipping inventory where you can put all the things you want to sell.

I decided I’d try to work towards getting these up and running ASAP, but then there comes the realisation that this involves actually having stuff to put in the various inventories. This is actually kind of annoying. Here I was trying to get the dull stuff out of the way instead of creating lots of fun content, when it turns out I actually need the content, to do the dull stuff properly.

So I decide to quickly cobble up a load of tools for the player to use. I’ve got so very many ideas for the game at this point, it’s quite tricky to decide which tools I actually need in some cases, but after a bit of deliberation I decide upon the following roster: mattock, shovel, axe, scythe, water and fishing rod.

There are a few things to note here. First and foremost I’m picking tools that will probably be needed without really knowing what the full scope of the game is. I’m unsure about the axe right now, because at this point I’ve not got space-trees in what I’ll laughingly refer to as my game design (not ones that need axes anyway) and don’t know if lumber will figure in any way at all. I’m also choosing tools that have good, and properly agricultural, names. I could refer to the mattock as a pickaxe, and the shovel as a spade if I wanted, but the words I’ve used have a weight and heft to them that I much prefer (I’ve avoided Hoe because it’s not that useful, and also a fairly cheap homophone gag that I don’t really need).

Also, and this is something that may or may not happen (because I have two conflicting ideas for how the game should “feel” right now) – these names conflict amazingly with one idea for an upgrade path. Historically, Harvest Moon style games always allow you to upgrade your tools – copper axe, iron axe, steel axe etc. But my game is set in space, so I’ve got great options. So by picking properly rural, down-to-earth, names for my tools I can slam them against an upgrade path of things like “laser” and “plasma”. “Laser Mattock”. “Plasma Shovel”. Those are tools that will get the job done! As I said – this bit’s not definite, but I like the names – and that massive contrast is a part of this.

Finally on this point, I referred to the watering can object (very traditional in HM-style games) as simply “water” above. As much as I like the contrast, as much as I like the idea of this being a mid-west farm in space, I cannot reconcile the idea of humans having colonised other worlds and yet them still using watering cans. Axes, yes. Watering cans no. So for now it is just called “water” (at the moment I’m thinking it might be a water tank backpack with spray gun thing, but haven’t got a name for that yet).

So with the tools in place I then look to adding just enough items to stress test the quick inventory bar (it can hold 8 items, so I need 9 or more). The planting of the space radish mentioned in the previous post was fudged in before, done on a key press – so I make the seed bag a proper object, and then make the harvested space radish another. We’re almost there. To expand my crop-growing script I decide to introduce a crop that can be harvested multiple times too, so add a space bean seed item and also a crop item too. I then implement that re-harvestable mechanic as well, because it’s really quick and easy. Now I have enough items to be problematic, so I just need to crack on and get the inventories sorted. And I kind of do – a bit.

I knock up another inventory system first – the player’s backpack essentially – what they can carry on them. In most games of this type this will start off small and be upgradeable to a bigger size (possibly several upgrades). This seems – hmmm – contrived, to me. Here’s the thing. I started playing video games before upgrades and power-ups had been invented. The one thing that’s really easy to spot for me is when you’ve been started off in a game under-powered or under-equipped simply because the designer wants to palm off something you should have had from the start as an upgrade. It’s like the first speed pick up you collect in Gradius – “Gee! Thanks! My ship now almost moves at a speed that allows me to play the game properly. Thanks for nothing.” So basically I’m thinking your backpack stays the same size, and right now this is it (could get larger if I think you need it):

Anyhow, implementing this makes me realise that you obviously need to swap items from your quick inventory to the main inventory, and that will be easier if the quick inventory is directly underneath the main one. I dismiss out-of-hand the idea that the quick inventory should move into place, and simply make a new one that sits underneath the main menu. When you open your inventory the code hides the original quick inventory, moves everything from it to this new temporary copy, and then lets you use that instead. Much easier. (One thing to note at this point is that I’m using keyboard/pad controls – I’m going to have to do this all over again with mouse controls which sounds like a royal pain-in-the-arse and something I suspect I’ll be dodging for a long time to come).

Next I wanted to add a storage inventory. Again, often these are a bit arse-y in these games. You usually have to craft chests to store things in, and then slap them all around your home to hold all the stuff you’re accruing, and when you run out of space you have to find the bits you need to build a new one, and then find somewhere sensible to place it, before you can do anything. I’m thinking one central storage facility that will hold absolutely everything you could ever possibly own is a good start point. I can foresee issues with it, but they seem minor compared to the alternatives.

But to have a storage inventory I need somewhere to place it, and right now I want that to be in the players house (because they need to access it for cooking and crafting and when they can’t go outside, which are all things I have plans for). So then I make a quick room out of blocks and cylinders that holds the things I currently think the player wants (from left to right – a computer (comms), a workbench, a kitchen, the ladder to the surface, the storage unit and a bed). I then quickly make it so you can go from the surface to the bunker and back again, and then also make it so that you can use the “storage” object to access a new inventory, and start implementing that.

This inventory is slightly different again, because now you need to be transferring between the storage inventory and both the other inventories. So this will work the same as the main menu only more so. It has copies of both the main and quick menus in it, so when you access it, it will copy the content from the real ones into its temporary ones. And this is where I got to on this. The menu is laid out and ready for me to finish off the code. It looks like this, so far (not sure what’s going on with the lighting here – the light in the scene seems to be affecting the GUI):

And now I’m much closer to being up to speed on this blog. Writing it has made me realise that I got a bit more side-tracked than I’d hoped and there’s loads more stuff still to do to get the inventories up to even basic functionality still, and that will have to become a priority once more. My next post will start off being about writing a fishing mini-game though, because that’s what I was doing just before I wrote this. Space fishing! Something I’ve wanted to make an entire game about before now. Now I’m just adding it in as a mini-game.

And Now For Something Completely Different

Hello. It’s been a while – and to be honest I’m forcing myself to write this now, because otherwise I’ll have too much catching up to do. First up – as the title suggests, I’ve moved on to a new project. I did do some more work on International Road Bastard, but hit a point where I wasn’t sure about it. I added physics to all the other cars for starters (which they needed if they were going to fly up in the air and get pushed off cliffs etc.), but that stopped them doing their nice “spinning wildly out of control” thing which made the game much less fun. I’d need to code that back in, and that’s part of the issue. Things were starting to look like a lot more work (the player’s car needed to be done properly too for example), and at the end of it all I could see is a silly little game – fun, but ultimately quite throwaway, and that didn’t appeal.

Whilst this was happening I’d been playing My Time At Portia – a nice (if unfinished) Harvest-Moon-ish game with a focus on building, rather than farming – and it got me thinking about something I’ve had at the back of my mind for a long time now. Harvest Moon in space (very literally Harvest A Moon). Before now I’d always dismissed this out-of-hand as being too big, but I had a few days off and didn’t fancy trying to wrangle Road Bastard into shape, so I thought I’d just have a pop at it, to see where it went. I had a head start from another work-in-progress project – a moon base simulator – which gave me a curved world (which I wanted) and a nice little landing pad with rocket that would set the scene nicely.

So I copied this project, ripped out a few bits that weren’t needed, and then knocked up a crude astronaut character from Unity’s spheres and cylinders. Then I also knocked up some crude models of several stages of growth for my first crop – space radishes. I quickly implemented this, which gets us to here (those radishes grew from a planted seed, and through 4 stages of plant before fruiting):

At this point I came to a realisation about the game – it doesn’t seem anywhere near as big as I’d assumed. I mean – there’s a lot of peripheral stuff in most HM-style games, but when you cut to the chase it’s largely inventory management over time. You have stuff in your inventory (seeds and tools etc.). You use tools to prepare the ground, then plant seeds. Then you wait for a while, before harvesting them to get crops in your inventory. Then you store them, or sell them, or combine them with other things to create different items in your inventory. That’s the core. Add in animals which are similar, mining, foraging and fishing and you’ve got most of the good stuff. Then it’s just a case of what else you add to bulk out the package. This realisation gave me renewed interest in carrying on with the game and the ideas came thick and fast (it’s genuinely one of the most fun things I’ve worked on – so many neat ideas…).

At this point I took stock though, and tried to think what the big issues would be. Clearly, the fact that the game revolves heavily around inventory management means that there’s going to be a lot of GUI work, which is something I try to do as little as possible of. There’s a lot of learning needed here, and that’s not something I take to well (I love accruing knowledge, I hate having to sit and read documentation or watch over-long tutorial videos for hours when I could be making cool stuff instead). The other major issue is going to be character work – I need animated 3D models for the player, livestock and any other NPCs I use. This is stuff I’ve done passably in the dim and distant past, but again – there’s a lot of learning involved, including finally using Blender (which I’ve had installed for ages, but have been trying my best not to go near wherever possible – hence using Unity’s primitive shapes for everything so far). However it’s certainly doable, and if it turns out I’m not up to it, I could always consider getting a decent character modeller/animator to do these bits for me (I’d be reluctant though – I really like being a one-man team).

So, to cut to the chase the game seems pretty achievable, and I’ve got more ideas than I know what to do with, so I just crack on. And because I’ve identified inventory is the key to the game, I’m forced to address this right away. I’ve never incorporated a proper one in a project before now, so I have a quick google, and find a Unity tutorial that gives me a good start point on both how to manage an inventory, and also some pointers on working with the GUI for it. So I quickly cobble together a makeshift quick inventory for the player, with some very rough placeholder artwork:

And then I immediately decide that I’m an idiot, and should replace the artwork for something that won’t make me hate the game. So I redraw the item slots as something halfway competent, if a little bland, and that looks – if not good – then a lot less rubbish:

And on that note I decide to have a crack at changing the way the game looks, because this is straight from my moon base prototype. I’ve not got a clear idea in my head yet of an art style, but I know what mood I’m after, so I have a pop at pushing it that way. I also add a few basic buildings to set the scene – which is basically an American mid-west vibe, but in space, so there’s a windmill and a water tower. The player’s house I decide is going to be a bunker under the ground, so that little cube is just the entrance. Which brings us to here (this is by no means final, but it’s much closer than old pink-world up there):

The final thing I’ll cover in this post is the curved world thing. The way it was implemented in the moon-base prototype was as an actual curved world – the map was actually part of a sphere. I soon realised that this is a horrible way to do it (unless I’m missing something obvious – which isn’t unlikely, admittedly). But basically I found that the easiest way to move the player’s character around on the outside of a sphere is to simply rotate the sphere (and everything on it), whilst keeping the player stationary. If they move forward you rotate the sphere toward the screen, if they move right you rotate it to the left etc. This seems simple enough, but doesn’t work for other entities though. So if you want an NPC to move between two arbitrary locations on the surface of the sphere it’s a right palaver. What I ended up doing was temporarily rotating the entire world so that the NPC was at the top, then spinning everything around the vertical axis so that the NPC was facing the thing they wanted to move towards. Then I could set them to rotate forwards around the sphere toward the target using the sphere’s centre as the pivot. Then I’d rotate the sphere back to its original orientation, with no-one any the wiser. It’s one of those things that you realise is utterly insane whilst you’re doing it, but then follow it through to the bitter end out of morbid curiosity.

Basically, that had to go, so I had a quick search on the Unity asset store and found a nice shader that performs some kind of wizardry to create the effect for me. The world now is actually perfectly flat, everything works as if the world is flat, it just ends up looking curved in-game. This is what the place looks like with the curvature set to zero:

The other benefit to doing it this way (other than not being hideously-unworkable obviously) is that I can alter the curvature without having to change, you know, almost everything else in the game (seriously, you’d have to remodel everything for starters, and then all rotation speeds would change and, crikey… it would be a nightmare. Whereas with this I can just type in the figure “30” to make it do this:

Right, that’s the lot for now. I am playing catch up with the blogging, so the next post hopefully won’t be too far off.

The People’s Popular Front (End)

Not much action on the dev front for a while, partly because I had a coding thing I needed to do that was a little on the boring side, so found motivation tricky. I’ve since mustered up the chutzpah to break the back of that, but it still needs a bit more work. (It’s all about traffic control, and I’ll blog that later).

Today though I got around to playing with a bit of front end (UI), which – in the early stages at least – I usually tend to enjoy. When working in the industry I found front end was often treated as a necessary evil – nobody really wanted to do it, but it had to be done. And OK, there’s a lot of unglamorous stuff in there that is a right PITA (and that’s why it can become a chore) but it’s also a massive opportunity. This is the first thing the players will ever see of the game, so this is where you should be setting the tone, and the feel. It should be treated as an opportunity, rather than a burden.

First off I had a choice to make – I either use Unity’s UI system, or I make my own. Neither is ideal. Unity’s UI stuff seems pretty good, but I don’t know it that well, so there’s learning involved in bending it to my will, and even then I’m sure I’ll find something I want to do that it’s going to have a hissy fit about. Whereas implementing it myself involves, well, implementing it myself. I did that for my Picross game, and the front end for that is a right royal mess (I’m talking about the code, which is borderline diabolical – I think the user experience is at least adequate).

However, I’ve got loads of past projects to loot for old code, and one of those has a menu system that makes a stab at simplifying some of this stuff. It also currently uses 3D objects rather than fonts for all the letters, numbers and symbols, which brings a raft of advantages and disadvantages (you can do a lot of cool things with 3D objects, but you’re wrangling it all yourself, so things like word-wrap and letter-spacing are now your problem, rather than the system’s, and that’s just for starters). However, all I want to do is get a front end up and running fast and worry about the actual implementation later, so yoinking this and pasting it into Road Bastard is the quickest way to go.

A bit of copypasta later and I have a rudimentary front end in place (the font is what was used for the old game obviously – I’ll make a new one if I decide to keep this system). I also have a new working title – International Road Bastard. This was a fairly obvious step. The game is nice and small in scope – a vertically scrolling racing game. What it needs is variety to keep things fresh. So the idea is to make it a global rally type of thing – an International Cannonball Run perhaps. Ice stages, desert stages – a nice change of scenery and a chance to add a bit of local fauna and flora (to smash up like a bastard).

Previously all my front ends have been largely hard-coded – and that works, but starts getting unwieldy as the number of menus and sub-menus increases. This new system is implemented in the editor largely by setting up individual menu items that can either launch a sub-menu, or call a function – such as starting the game, or quitting. It’s much easier to work with for these straightforward things, but at the moment I haven’t considered the awkward bits – volume sliders, reconfiguring controls, choosing screen resolutions etc. A problem for another day… The other thing I need to do is find a way to make this localisable (is that a word?). Currently the text for the menu options is English only – I need to find a simple way of redirecting this to any number of languages. Again – a problem for another day.

So next I start thinking about look and feel, and the first thing that occurs to me is to get car sounds in there. When I start a new project (however short-lived it may turn out to be) I always copy three sound effects from an old project across to the new one – menuMove01.wav, menuSelect01.wav, and menuBack01.wav. It’s so important to get feedback on a user’s actions that these get plumbed in immediately I get a front end up and running. So replacing the beeps I’d copied across initially with a revving sound and horns gets me this, which is a start:

And then I take into consideration that the game is called Road Bastard, and the next step seems very obvious. Bear in mind this took twenty minutes tops, and is just a case of me twiddling (technical term) with the pitch and volume a tad. I like it (I’m tempted to try making it top out with angry horn beeps on top of the revs).

So, that’s where it’s at right now. I’ve no idea how much of this will make the final cut, but I had fun doing it for the most part. I do need to sort the issues with my front end system – doing it right isn’t the nicest job and will take time, but could be so useful in any future projects. However I know myself well enough by now – I’ll probably kick it in the right direction a bit, and then leave it until next time to do it properly. It’ll slowly work its way toward completion, and that’ll have to do.

Let’s Get Physical

The day after I wrote my previous post I opened up the Road Bastard project, and realised right away that I was sick of the way it looks. Almost every project I start gets made with Unity’s standard primitives – cubes, cylinders and spheres etc. and I tend to just throw a few plainly-coloured materials at them to make sense of things. It’s a really quick way to get a project up and running, but it does mean they tend to all look the same. And I’m a bugger for picking the same colours. I like most of my colours to be a bit on the blue side, so I generally have bluish grey for metal or concrete, and bluish greens for grass and trees etc. and I’m now thoroughly bored of it. So the first thing I did was find a couple of better materials for the road and the grass that I’d downloaded free from the Asset Store, and then darkened up the remaining flat colours a bit to make it look a little different. I’ve no idea what the final art style will be, but this at least isn’t boring me silly:

(There is an issue with these materials in that something about the way they’ve been made means that lights and effects don’t show up anywhere near as well as they should, so I will need to replace them again, shortly.)

Next up I added some camera shake for when the car is on the grass. I have this in almost all my projects – it’s a very quick way of adding a bit of visual interest – so it was just a case of copying and pasting some code from another project. I forced this in, by just applying it when the car is a certain distance from the centre of the road for now. I stupidly didn’t think to also check that the car is moving, so it shakes even if you sit still on the verge. Never mind – needs doing properly at some point anyhow – the point was more to get the code up and running.

I also got around to buying a fog asset from the Asset Store. I added this with default settings, and it didn’t seem to show up, but then I remembered the new materials don’t like special effects, so I tried turning the lights out:

Looks like it’ll work, but I’ll play with this later. I’ve bigger fish to fry.

Next up I decided to do something a bit more important – change the control of the car over to being physics-based. This actually involved re-working pretty much everything. If you’ve read the first post on this game you’ll know that the game was originally meant to be a very simple lane-changing game. Because of this, it was written in a very cheat-y fashion. Basically the player’s car never moved down the road – the road moved towards the player. As the player accelerates the road just moves towards them faster. Likewise all the other cars are moving at their own speed, but also towards the player at whatever speed the player is currently at. I can’t remember exactly why I did this at the time, but it was a valid approach – it would have worked. But now I want to use physics to get proper collisions etc. and so this all needs ripping out and putting back in properly.

A quick change to the player code adds physics-based handling – but in a limited way. I’m not about to write a vehicle simulation – that would be beyond me, and unnecessary for what I still see as a simple game. So I’m cheating again. When the player accelerates I apply a force to the car that pushes them straight down the road. When the player steers I apply a force that pushes them across the road, and I also turn the car to face into the turn. This is different to what should be happening – which would be turning the car and then applying acceleration along the car’s forward axis. I could be wrong, but I think that doing it properly would cause lots of problems. My way allows me to take advantage of Unity’s physics system for collisions, but also gives me very tight control of the car. I’ve also restricted the physics quite a lot – there’s no gravity involved, and the car can’t rotate in any axis due to a collision. I may relax some of these if needed, but for now I want control. Anyway, basically I get the car running with physics quite quickly. The handling is awful, but I can tweak that later.

Next up I redo the road system, which was always a kludge. Basically the road is made up of a number of “tiles” that move towards the player. As the nearest one moves out of camera, I simply moved it to the back of the queue, and the whole thing just continued, looking like the player was moving, but they’re never actually getting anywhere. The change is a simple one – decouple it from the player’s position and move the piece further away from them, so that as they move down the road there is always a new bit to encounter. It’s still a kludge but it will work.

The final piece to getting this working is to change the camera so that its position is tied to the player’s car, rather than just floating in space (without this the player’s car zooms off out of view quite quickly). With that sorted we’re almost back where we started I just need to deal with the other cars.

At this point I added a traffic manager script to start controlling the way cars are spawned. I’ll go into this later because it’s complicated, but for now I’ll just say I had a couple of ideas about how this would work, and I’ve already realised they won’t work at all. So it goes. For now it just chucks cars along each lane at a different speed at 2 second intervals. I also added oncoming traffic on the other side of the road at this point. I then tweaked the cars to add physics to them, and then unleashed them.

Phew! A lot of text to get through, but that leaves us with things being done a little more correctly, physics is enabled so the player can collide with stuff, and there’s a script firing lots of cars with no AI at all down the road at varying speeds. Which results in this:

Now that looks like there’s proper potential to be a “Road Bastard” there to me. It’s actually quite good fun just driving along nudging other cars off course and seeing the results, which given that it’s all so basic is quite encouraging. One of the first things I’m going to do next is add an explosion for major car-to-car collisions to start getting a bit of feedback in there. Then I need to probably look at creating better traffic patterns, or maybe add some car AI.

One thing I need to think about though is how to keep as much as the action on-screen as possible. Because the player is driving fast (and at the moment nowhere near as fast as I’d like) there’s the potential for a lot of the chaos created to be lost as the player zooms past as it’s happening. I need to try to make as much happen further down the road as I can so that the player a) sees it, and b) has to deal with it.

Who Turned Out The Lights?

I only managed a couple of hours work today, but they were pretty good ones. As mentioned yesterday, the empty spaces off to the sides of the road were annoying me, so the first thing to do was knock up a couple of quick bits of scenery – one for either side. As with the rest of the game so far, these are all made with Unity’s primitive shapes right now, because otherwise I’d have to finally get around to learning how to use Blender to create 3D objects (I’ve spent 20-odd years using 3DS Max, but can’t justify the expense right now so need to make the change, but it’s a very reluctant one. Also, I hate learning new software – I genuinely find it immensely frustrating to have powerful tools but not the knowledge to use them – and it’s one of the few areas in life where I lack any degree of patience. It’s why I generally learn the bare minimum I need to get by with any software package, and use those tools exclusively – even if I’m aware there are better ways to tackle a job, but would need to learn how to use them.)

Anyhow, after maybe quarter of an hour of playing with capsules and cylinders and cubes I’ve got something serviceable, and I think it helps a lot. The grass verges make me think the car should shudder when travelling over them, and kick up dust. It’s also a good excuse to add camera shake, so these get added to the list of things to do. All non-essential, but all will add to the feel of the game, which is all I’m after right now.

Next I decided to address the horn, changing it from a short beep to a loopable sound, allowing the player to sound properly angry if they wish. I suggested yesterday that maybe the horn would intimidate the car in front – I’m wondering now if making that a function of time would work too – so some drivers panic immediately, while others need a longer blast (possibly over-complicating things, but probably worth looking into). I recently got a bunch of sound effects in a Humble Bundle, so I looked through these and found several car horns, but none of them looped. So I picked one I liked, opened it in Audacity and cut out the middle section and tried playing it looped. Huge clicking sound when it looped, so I nibbled a bit off the end and tried again. And again. And again. Then I tried nibbling a bit of the start. And again, and again. After whittling away at it for ages I finally had a (very short) loop that wasn’t too bad – it still clicks a bit, and will need replacing, but it will do for now. Audio is one of my least favourite jobs (which is a shame, because it has such a huge impact on a game).

Next up I decided to look at adding night time to the mix (this will also pave the way for all manner of colour schemes). A little tinkering with the light settings helped me find decent values to make a start, so I then coded a routine to fade between different sets of light settings at the press of a button (for now). That worked a treat – could hardly see a thing, so next up I strapped a couple of spotlights to the front of the player’s car, and – crikey – for something so cobbled together it actually looks rather neat. As you can see in the video below – night falls like a dropped brick right now – I’ll slow that down later. Next up I added tail lights to all the cars, and then when night falls the game manager script tells all the cars to put their lights on. The important thing here is that the cars each generate a random delay before they do this, to prevent all the lights coming on at the same time as if a switch had been pushed. Pleased with this.

Whilst rummaging around in the RenderSettings to adjust the lighting values I noticed the settings for fog too – I hadn’t thought of this, but fog would work a treat. So next up I spent a bit of time monkeying around with fog values – again putting them on a button press for ease of testing. I’ve soon got a real pea-souper. It’s not right, but it has definite potential:

So, next I think what happens if I mix it with night time, and this is what you get, which again could be really nice:

This is part of why it’s so very hard to finish a game. At this end of development, it’s almost like the game makes itself. It’s like it runs away, and you’re just trying to keep up with it, new ideas coming thick and fast, and you cobbling stuff together in minutes and getting cool results. It’s almost intoxicating. At the other end of development, you end up desperately trying to drag the bloody thing across the finish line, and it’s really reluctant to go. Every little thing seems to take an age to finally put to bed, and whilst what you’re working on is probably essential, you know nobody will even notice it. At some point the balance tips from that rush of ideas to that slog of just trying to kick the thing out the door, and at that point starting something new and interesting is always going to look much more appealing.

Anyway, at this point I decide to make a build to grab a video, and realise that the fog doesn’t show up in a build. A quick Google shows this is a known issue – fog works in the editor, but not in the final build. I try a few of the suggested workarounds, but none of them work for me. I soon get bored of this, so turn to the Unity Asset Store and find a few snazzy-looking foggy assets – and that’s where I’m at now – trying to decide whether to buy some fog I didn’t know I needed 20 minutes ago. They do look very good, so I’m very tempted (who knew you could make money selling fog?).

Tomorrow I’ll probably decide about the fog, and maybe look at adding camera shake and a few particle effects. After that I’m probably either going to have to bite the bullet and start using Blender to get some proper geometry in there as I search for an art style, or I’m going to have to look at getting the traffic working properly (which is perhaps the biggest unknown right now). Or I might put these off, and mess around with a few more cosmetic touches, because that’s much more fun.

Is This Thing On?

Hello. Long time no see. With a week off work I have a little time to tinker with potential new projects, and so I thought I’d also look at firing up this blog again – hopefully I can stick with it this time.


So I decided to sift through all my old prototypes looking for something I fancied revisiting – and came across the rather uninspringly named “DrivingGame” (I’ve mentioned before that the first thing you need for a new project, even before you’ve drawn a pixel or written a line of code, is a name for your game, and I’ve long-since given up trying to be clever with these).

Regardless, I want to do something nice and quick, and this feels about right. It was originally meant to be a very simple game of dodging traffic, with the player not having full control of the car – just the ability to switch lanes, and accelerate and brake. It was loosely based on a spiteful old arcade game that I have a fondness for – Road Fighter:


This first attempt never went anywhere – perhaps because it felt a bit “appy”. But firing it up again, I rather liked the look of it, and remembering the game it was based on, I came up with a new idea and a new working title – Road Bastard! This isn’t just a working title – this is pretty much my entire game design document right now. Enable the player to be a “road bastard” (whatever one of those is), and reward them for it.


A word on game design documents. When I worked as a Creative Manager, and then as a Game Designer, game design documents were things I came to hate with a passion. You had to write one for every project, detailing the story, and the characters, and the gameplay mechanics, and every other aspect of the game to win a contract with a publisher initially, and that’s fine and understandable. But the moment you win that contract the thing should be thrown in the bin and never mentioned again. It isn’t though. It’s maintained throughout the duration of the project to record the current state of the game. But because the game will almost certainly deviate from the design document within weeks of the start of development (at most) and continue to do so throughout its development, the game design document then spends the entire project chasing the current state of the game, needing to be updated every time a new change is made. It’s a colossal waste of time for a document that I’m pretty sure never gets read by anyone other than the poor sod who has to maintain it.


Anyhow, the first thing to do to make this better was to rip out the old control method and put in a new one, allowing proper freedom of movement. First up this meant just getting the car to move across the road, rather than snapping from lane to lane. This was an improvement, but not enough. So then I just added the cosmetic touch of rotating the car as it moved from side to side, and that immediately felt so much better with the car weaving, rather than sliding, around (so often these tiny touches are critical). Obviously, this is made entirely out of placeholders so far, but it has potential, I think:


As you can hear in the video, the car has a horn – if you’re making a car game then you can’t add the horn early enough, IMO. Maybe wait until it can move and steer first, but there’s no harm in doing it first. It doesn’t matter if you don’t plan on making it affect the gameplay at all – there is no downside to adding a horn. In the case of this game I’m thinking of perhaps making it intimidate the car ahead of you – maybe make them act erratically – that could be funny.


So, that’s the current state of play. Next up, I want to work on some “low hanging fruit” to push it towards where I want it to be. I’ll add in some scenery to fill in the gaps off to the side because they’re bugging me. I also want to add a night-time mode. Whilst working on this I remembered some of the very early arcade driving games like Night Driver, and I think a brutally dark colour scheme would work well here (whilst the player should be a bastard, the game will probably be a bastard right back at them). Also – and this is very important – I’ll look at replacing the current horn sound (beep) with an angrier looping sound, so that the player can hold it down for as long as they want – that’s what a “road bastard” would want.

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).