Author: phil 29th April 2015

Let’s blog!

I want to talk to you today about a bit of the games design process which doesn’t get a whole lot of attention, mainly because, like an anonymous streaker, it doesn’t have a name and there isn’t a clear way of tackling it #OhJokes

It might get a little bit boring as I delve into matters of Games Development so I’ve peppered some images throughout to sweeten the deal:

Here’s a brief description of how the problem manifests: When you first start working on a project, once you’ve got past the initial research and the early prototype stages you’ll find you’ve naturally accrued a great many different ideas for features and mechanics you’d love to include. A gun which shoots bees, a shader for your river made of syrup, a companion mobile app which allows you to waggle the main character’s buttocks… god this game is going to be great…

The difficulty comes when you start to work out your production schedule. You set yourself an end date and you suddenly start to realise that all the wild wacky and wonderful ideas you’ve come up with won’t all fit within the time frame you’ve set for yourself.

Here’s a rundown of what generally happens when faced with this problem:

1. You go back to your estimates. You eye up the numbers next to each features and gently massage them until they more comfortably fit within the boundaries of your lovely schedule (don’t worry producer friends you can reformat it all later)
2. You prioritise all your lovely ideas from Absolutely Essential to Wouldn’t It Be Nice If, and you accept the grim fact that those features on the bottom of the list probably won’t make it into the final game. (You can also make yourself feel better by accepting that the end user probably won’t have been aware those features ever existed anyway… unless you already included them in your kickstarter pitch… :-S)

B is clearly the way to go right? or a bit of A followed by B at least. The difficulty I find is in creating that list. When creating a prioritised list you can’t always look at the individual features and judge them on an individual basis, you have to think about the bigger picture of your game.

What use is it having a river made of syrup if you’ve already had to cut the gingerbread boat?

The point is that a game isn’t just a collection of random ideas. Good games involve multiple systems all working in conjunction with another. Some games take a reductive approach – they build up a feature set which explores as many features, ideas and mechanics as possible, then they carve away the excess until only a pure core remains.

Great if you have the time and resources to explore that far, but what generally happens on a budget is that you have to build up from bricks rather than chisel out of marble. So how do you choose which bricks to use and which to leave on the…. brick… pile?… brick shed?

The simple answer is that it comes down to your goals. What are the most important pillars of your game? Are you going to struggle to sell the game? Do you therefore need to prioritise features which will help the game appeal to a broader audiences? Are you lacking in lasting gameplay appeal? Do you need to focus on mechanics which will vary the gameplay experience over time? Are you trying sell Beats headphones? Do you need to include more Beats headphones?

I could mention the difference between the goals of a developer and publisher and how this leads to the many an upset tummy on a project but I’ll spare you that and instead include this picture of an elephant:

If you know what you want from your game it becomes much easier to look at the many disparate features and judge which will work well together and bring you ultimately closer to your goals. Experience will always help in this decision too as you’ll be able to more easily tell which ideas work and which will lead to colourful headaches down the line.

Oh and one Jerry Springer style final thought: One of your goals on a project should always be to enjoy yourself, because one day you will be dead.