Hey, Game Designers: Don’t Be a Groundhog!

This is the first piece of an ongoing series of thoughts about Game Design and Video Game Development in general. It is the conclusion of 12 years of working in different roles in the Games Industry.

The most famous game designers of the past were programmers. Think Sid Meier, think Will Wright, think Brenda Romero. But at some point in time, it became obvious that they were even more helpful when they concentrated their work on design aspects of the game. Over time, game design has become a heavily specialized craft, often with little to none programming knowledge involved anymore. Unfortunately, this development often raised a fence between game designers and the productive part of the team. In the shadow of this fence, misconception of the role and purpose of game design thrived, giving room to the rise of a little mammal.

From soothsayers to jesters

To many in this industry, the game designer nowadays is a mixture between a soothsayer and a jester. This conception is basically inscribed into the role: Game designers are supposed to predict the future. They are expected to have visions of finalized, successful games, paired with the ability to describe these miraculous million sellers in elaborate details.

In the early phase of conception, everyone in a development team is turning to these wise soothsayers and their immense wisdom. Although no one really believes into soothsaying, they rely on these predictions; you have to start somewhere, after all. But rather soon, doubt takes over: This early prototype… It does not really look like a million seller? Heck, some people in the team say that this will never work out. Over time, there is more and more of a gap between the development team and the game designers. Producers take sides, trying to mitigate damage. Designs get defended and fortified, grumbling coders implement features that (to the surprise of absolutely no one) fail and need to be redone. Dates get delayed, concepts get rethought. In the end, the most powerful person in the team decides what the game is going to be, while miffed Game designers jump around, telling everyone that this would have never happened, if only the team would have stuck with the one true vision (= their own). Sparks of the game design’s random nonsense still make it to the game, but more as gestures of good will by the people in charge. The more positive developers sigh and say ‘Yeah, you need to have some craziness in games. I guess, this is what these guys are for’.

It is the natural course of things, right?

It is not. And if you are in such a situation, odds are good that you ran into a groundhog.

The fence

First of all, everyone is right to mistrust soothsaying. Far too many game designers see themselves as god-sent messengers of creativity whose ideas are just so much more valuable than the ones of their colleagues. Even with less audacity, most Game designers think of themselves as ‘The Idea People’, with ‘The Implementation People’ sitting on the other side of the fence. Sure, feedback and ideas can be thrown over the fence, but only Game designers have the secret knowledge, what is right or wrong

.

You know what: They are right! But this is not, because their ideas are that great (as unfortunately so many Game designers still believe). It is in their job description! Game designers exist, to separate right from wrong. There are so many solutions to any given problem, there is rarely one true path to pursue. If you want to ensure that a game is going into ANY direction, you need to give someone the power to decide.

Unfortunately, with great power comes great responsibility. (Thanks Uncle Ben!) In any game, there is a multitude of contradicting requirements, usually quite a few of them invisible to the majority of the development team. A good game designer weighs the different demands and makes decision based on their importance and the effect they will have as a whole on the game. And this is, where groundhogs undermine game development.

Meteorologist and groundhogs

Imagine, you want to know when winter is about to end. You could turn to your local meteorologist.

She would look into the data of previous years, she would view satellite images and she would consider other factors like the amount of snowdrop over the last month. After that she provides you with a rough estimate that winter will end somewhere between February 20^th and March 20^th and the odds for this prediction, maybe 65%. You could ask another meteorologist and he would have a slightly different answer. There are better and worse models of weather predictions, but all in all, they come to similar results.

Or you can go and consult a groundhog.

As Bill Murray taught us: If a groundhog sees its shadow, winter will persist for six more weeks after February 2^nd. The groundhog’s prediction is based on common wisdom, so it’s not fully random. Let’s say, it has a 60% chance of making a correct prediction. In Game Development, groundhogs might tell you that VR is the future, mobile MMOs make a lot of money, shooting people is fun and iteration is important.

You can see: On first glance, there is little difference between the advices from a meteorologist and a groundhog. Both have a great chance to turn out wrong and both make an impossible attempt to predict the future. You might ask: Why bother at all? If a meteorologist can miss and a groundhog can miss, where is the difference? Is a 5% better chance worth the trouble? Also, isn’t the groundhog far more convincing? The meteorologist will remind you to keep your winter clothes, because she knows (and vocally points out) that the likelihood is merely 60%.  A Groundhog will talk with far greater confidence of the upcoming spring, throwing away all its old clothes, inspiring everyone to do the same. This is, why groundhogs usually make a far bigger impact, if their predictions come true.

‘We just need more iteration time’

The real catch are the short-term predictions: A meteorologist today has a 90% chance to predict the weather of the next day, while a groundhog always remains at his 60% common wisdom ratio. In terms of game development: Where game designers strive for methods and tools, groundhogs follow their instinct (which are often correlated to the games they currently play). This is where the groundhogs not only costs money: Their erratic micro decisions drive people into exhaustion and burnout. As they have no real understanding of the goals and effects of their deeds, groundhog designers jump between directions, often supported or forced by groundhog superiors. And worst of all, they put the craft of game design itself into a bad light. As groundhogs do not know about the outcome of their advice, they are vocal advocates of ‘iteration’ and ‘polishing time’ – things that help every development… but only, if you have a plan. What groundhogs mean with ‘iteration’ is a constant back and forth of undirected ideas that never really meet what they are supposed to do (although, most of the time, there is no stated intention behind them anyways).

Naturally, this causes a lot of distrust. It puts a barrier between game designers and all other developers and it is poison for even the most reasonable designs. If someone has experienced an imposter before, it is hard work for any game designer, to prove themselves to be the opposite. Add to this the joy, to redo this in every new project and you can see the harm that groundhogs do to the games industry as a whole.

Long development cycles and the complexity of bigger games help groundhogs as well. If a groundhog messed up any core mechanic of an important game, odds are good that a worrying developer will step in and clear up the mess, leaving the groundhog with a flawless CV. And even if everything falls apart, the groundhog can use the same excuses as any ‘real’ game designer: Lack of time, producer’s interference, reluctant team, diluted vison, hard competition, etc., etc. As long as game design is still seen as a somewhat necessary mumbo-jumbo rather than a craft, groundhogs will come away with their excuses.

How to catch a groundhog

So I appeal to anyone out there: Take your (senior) Game designers by their words. Let them prove to you that they know what they are doing. Do an experiment: Take any feature you like, with a short timeframe and as many people as you prefer and give it to a Game designer. Do not require anything, but ask, what he or she can achieve for this feature within the set scope. Insist, that the game designer names an emotion or a reaction, which players will associate with this feature.

Most groundhogs will at this point try to distract: ‘There is nothing good that I can do with such a scope. I would need at least [add impossible amount of people and time here]’ Here it is to you, to say: ‘But this your job! Give me what you CAN achieve.’

Game design is not about reaching a lucky strike after hundreds of random dice rolls, but about choosing a feasible road under given circumstances.  Game designers exist to save time. Iteration based on common knowledge is something that programmers can do far more effectively on their own. To be worth the money, a game designer’s solutions should be faster in the end than elaborated guessing and it should be able to adapt to new requirements. Thus, good design can be tried and tested.

True game designers will set themselves goals and go out, to do the necessary steps to achieve them. If you give him or her the agreed resources, you will be able to see the predicted results after the set deadline. Obviously, a groundhog can have a lucky hit as well. Try the experiment a few times, to be sure.

If you find a groundhog, consider other occupations for them. After all, groundhogs are usually inspiring people, sometimes very smart, talented in PR & Marketing – but they should not direct games.  But if everything works out fine, you will find something surprising, which has become a scarce resource between game designers and non- game designers: Trust.

In my next blog post I will investigate what game designers can do by themselves to lower the fence towards their colleagues.