MCV/DEVELOP News, events, research and jobs from the games industry
I’ve spent the weekend involved in a Flash Game Jam run by a friend (if you want to find the results, try Google, I’m not making it easy for you), and something quite worrying cropped up. It occurred to me that in my career I’ve made – from start to release – less than ten games.
Closer to five, actually – but it’s not the number that matters (I’m happy with my CV!), it’s what this means in a broader sense.
It means that I’ve practised making a game less than ten times. Not bad I suppose, considering the way things work in the industry – I’m young, games are complex, it takes teams of talented people working in sublime symmetry to deliver on much of the promise of a project. But compared to a lot of other professions, it is a little worrying.
Take writing as an example. I write a lot; I write in my day-to-day job as a Designer, I’m re-writing this piece now, I write letters to friends, emails to business associates etc. And so, I am quite practised at writing. As a result of this practise, I’ve gotten fairly good at it – that’s what tends to happen.
What about cooking – something that at a commercial level takes a large team of people to do properly. Well, these busy chaps toil away day after day often serving hundreds of covers every lunchtime and dinnertime, and so they’re pretty well practised too.
Now think to your own jobs. Think back a few projects – what exactly did you do? How much of what you did on each project was new to you? New techniques, new tools, new code, new mechanics – I’d bet at least 70% of your workload was sufficiently different to the previous game you made to count as ‘new’. In fact, how many games have you been able to release in the last few years?
This means that we, as a collective industry, don’t get nearly enough practise in. And we all know practise makes perfect – and conversely, lack of practise will surely lead to imperfection. How can we expect to create great games when half the time we’re too busy creating the new? Breaking the mould is all well and good, but we’re forced to do it so much more than is necessary.
Every time a new piece of hardware comes along, we have to learn new practises and change the old ones. Every console cycle we have to put up with a sea-change of technology that leaves us all struggling to swim.
All of this means that we constantly fighting the technology that should be empowering us – and I dread to think what this all means for the poor buggers coming out of education with a nice set of soon-to-be-out-dated software skills under their belts. But not all of the blame should be placed at the feet of the hardware and software vendors – we make it difficult for ourselves a lot of the time too.
Well I reckon enough is enough, and I do see a few solutions, and a few examples to take solace from. First off, you can get practise built into a project on a smaller scale – it doesn’t have to be full products (but more on that below).
As you may have read before, prototyping is something I’m very keen on. This is where the cost-effective dry runs can take place, where we can practise in a safe environment. Safe for the ideas, safe for any investment, and safe for our sanity. Prototyping means we can practise – or ‘iterate’ to use a much more trendy term – for the big event.
Engines are another obvious angle. They cost an arm and a leg most of the time, but at least you know that the arm and the leg will work. It’s up to you to scope the products and purchase sensibly, but if you’re going to make an FPS or a 3rd person action game, try out Unreal or CryEngine or Source for pity’s sake. If you’re making a sports game or an MMO, look elsewhere – but be sensible and you’ll benefit from a whole world of other people’s practise being applied to your project.
Similarly, in-house tools should never be overlooked. Getting the balance right between usability and the time it takes to build them is always a challenge, but time after time I’ve seen small decisions about tools have massive impacts – both positive and negative – on productivity.
If the level design department has to rebuild after every change, even if it ‘only’ takes two minutes, that’s going to add up quickly – especially so at the end of a project when the changes come thick and fast.
A few hours of code time to reduce this (or even better, make the game live-editable early on in the project) will alleviate a lot of wasted time, and allow the content team to practise more. Not to mention the fact that the improvements will continue to be of use on every project from that point on. That’s value for money I can get behind.
Even the genre or style of game you’re making can be attuned to ensuring you get more time for practising the important parts of the game. As I said before, why break the mould?
If you spent ages making an awesome racing game, don’t start something so different that you have to throw it all away. Just because the player’s avatar is physically driven and the level design tools are geared towards circuits doesn’t mean you have to make a racing game next time.
A game like Star Fox or Panzer Dragoon could quite easily pop out of that tech, leaving one of the main challenges being to add a nice animation system. Surely that is better than trying to make your next game an Uncharted competitor.
But enough of the small, let’s get back to the big picture. Look at some of the most successful studios out there; Valve, Blizzard, BioWare, Codemasters (to name but a few). These guys have built up core tech and expertise around one or two main areas, using every game they produce as a training ground for whatever their next game will be.
Valve’s domain is the single- and multi-player FPS, Blizzard are masters of the RTS and the MMO. BioWare knock the ball out of the park with their western-style RPGs (while nobody could accuse Mass Effect 2 and Dragon Age of being terribly similar).
Codemasters are almost unrivalled when it comes to their racing teams’ expertise and technology, while their in-house audio guys get seemingly every award going. And there’s good reason – they’ve had a ton of practise.
Now on the job scale – a person-to-person scale – practise is easier to wrangle time for than on a project scale. But so many issues crop up simply from the process of creating a game from start to finish.
We’ve all got a pretty good idea of what is required for the day-to-day creation of code, assets and levels, but what about the concept process that defines that game in the first place? What about all those TCR’s, the marketing materials, the interviews, the PR exercises, the pitching, the demo creation – all the little things that we tend to overlook from time to time?
All of these must be practised too. And I have to labour this point – not in isolation. The whole thing is a big tangled mess of cause and effect, so to simply have lots of concept meetings is not enough. You’ll only be able to engage in meaningful practise by taking a concept from those meetings and executing on it, and then releasing it. Only then will you have practised fully, and only then will you have benefitted properly.
It’s easier said than done, and requires a business and management team that recognise the importance of quality content over everything else. It also means that sometimes you’ll have to reign in the ‘Creatives’ – Bob being bored of designing scrolling beat ‘em ups on XBLA is not a terribly sensible reason to switch to the iPhone and match-3 games. But if you just get the chance to practise more, then you’ll get ever closer to being perfect.
