[What the heck do game designers do, again? DoubleSix (Geometry Wars Galaxies, South Park XBLA) creative director Jim Mummery examines why the designer isn't the "king" or "rock star" of game development - but nonetheless has a vital role to play.]

We work in an industry in which, it would outwardly appear, the designer is king. Only a designer would get their name before the title of the game or have a credit that reads: "A Game By." They are the new rock stars who conjure the entire game fully-formed from their amazing minds all by themselves. All hail the games designer, for without them, surely we would have no games. Right?

Wrong.

But I'm getting ahead of myself -- let’s jump back in time to a strange land.

In The Beginning

In the games industry there was a time, long ago, when games were made by coders – just coders. They knew what worked, how they worked and no one else was needed. They programmed, they made the assets, they built the game. Small pixel stickmen ran and jumped over small pixel spears. The games were simple, times were good.

Then games became successful, and so became competitive, and so it was deemed that they needed to look good. So artists were summoned, artists who could work in the medium of D-Paint and turn pixel stickmen into beautiful animated sprites.

The battle between what looked good and what worked began (and still continues to this day). These coders and artists, both of whom knew how to make games, both of whom had clearly defined roles, worked together (albeit grudgingly) and the world of games became a happy and productive place.

Until games became even more successful and even more competitive and so the games had to become more complex; more in-depth. There was simply much more to do, more code, more art. The coders were too busy, the artists were too busy. Someone was needed to do the odd jobs, the little tasks, putting the pick-ups in the game, spawning enemies, making the coffee…

This little guy worked with the other more talented people, the artists and the coders, he helped them out but more and more, the things that needed changing in the game were the things he was doing. The game looked great and worked great but the publisher didn’t like the little things, like where he had put this enemy or that power-up.

And so the publisher needed him to make changes. The little guy didn’t mind, he could fix that, he would make a difference. He began to feel important -- at least when he wasn’t getting the coffee.

More and more his relationship with the publisher grew, after all they were talking all the time and lo, they coined a term for what they were fixing: gameplay.

Birth Of The Designer

The fateful day came when they found something he couldn’t fix with the simple tools he had been given. Egged on by the publishers, he turned to the others, the ones busy doing the real work and asked for better tools, for more enemy types, for less coffee making. With no time to argue, they gave him what he wanted and when he saw the difference he’d made, he realised what an unadulterated genius he was…

Thus the designer was born.

Okay, so writing fairy tales is an easy way to fill space -- but what’s my point?

As ‘designers’, we came to this party last. Everyone else here has a defined role; we exist only because coders and artists were, for lack of a better term, too busy. Some designers even claim to know games better than anyone else -- but this is obviously a fantasy.

These days, anyone who enters the industry (coder, artist or designer) has had similar game-playing experiences; they all know games and what they like in the games they play.

The big difference is the coder can program (it’s a small word for making worlds) and the artist can draw (not literally -- hell, these days half these guys can’t even sketch, but the stuff they can do in Maya and Max will make your head spin). They would not need us except for the fact someone needs to do the ‘other stuff’.

Luxury Of Time

There is a misunderstanding that a designer is someone who mysteriously understands how games work and knows intuitively what is needed to make them good. All gamers know this on some level -- and we, the game developers, are all gamers.

The only reason designers often have the answers when others don’t is that we have the luxury of time to think about it. That being said, due to the industry’s history and because of the fact that everyone, no matter what their role, understands games, the designer can never be ‘the guy with the knowledge’ -- or, at least not the only guy.

He works with people who, like him, live and breathe games. His role is to support them, not dominate them. To work with them to create games they all want to play, to create a game that belongs to them all. As a result, the designer is the collector of ideas, opinions and feedback. The conduit for what the team believes.

The thing is, listening is harder than not listening; it is easy to walk over anyone with an idea. It takes far more effort to convince them of your way of thinking (in fact it is often impossible) and harder still to know when to climb down and accept theirs.

It is his job to take all their passion and filter it; find which ideas fit together, which don’t, which are ideas that the publisher will buy into and which ones aren’t.

The game does not form complete from out of his tiny mind. It is formed by the varying talents of the team and the by the happy accidents that occur along the way.

So where does that leave us?

Designer, Not Director

First, let’s get rid of the idea of the designer as the director of the game. Games are made by teams – one guy cannot do it alone (with a few brilliant exceptions).

The designer is part of that team and because his job (the scripting, the documentation, tweaking game-play and making the coffee) is reliant on everyone else – it is his job to listen to what they have to say and find a way to make as much of it work as possible.

He is a listener and communicator. His job is the flexible one. His tasks can stretch to fill the available time. Theirs cannot.

Design works best when it’s finding solutions to problems that cannot be resolved elsewhere, solutions that fit within the restrictions created by budget, timescale and the other disciplines.

At its best, design is about technical pragmatism and team co-operation rather than selfish and singular idealism.

A case in point: say our designer needs a new tutorial element for his game. The game has evolved into much more than was originally conceived (thanks mostly to the enthusiastic involvement of the team) but he now has more to teach the player than he did before.

Currently, all he has are load of static screens with images and text but, whilst they are clear and concise, they just don’t get the message across. Players read them but do not take it in. It’s not enough. The game is well into development and there is no time for any major changes.

Ultimately, if he’d thought about it earlier, he’d have asked for a playable tutorial but the game didn’t need one then and, now it does, he doesn’t have the assets to make one.

What does he do? First things first – he has a quick discussion between other members of the team, in this case the other leads, the artist responsible for level building and the coders in charge of the front end and scripting.

Very quickly, everyone agrees that a playable tutorial is the obvious choice. Why didn’t we do that in the first place? Static screens were never a good idea! Our designer looks down into his shoes and mumbles something about how everybody else does it.

Quickly the conversation moves on to what would be needed if a playable tutorial was put into the game.

The level artist is first to point out that if the level requirements are kept simple, he can build it very quickly. So they find a theme the artist is a) interested in and b) he is sure he can build as quickly as possible.

Next, the front end coder is equally enthusiastic and can easily change the front end to accommodate the tutorial level and allow more text to be shown on screen during gameplay.

Lastly, the scripting coder says that as soon as he has a list of requirements, he should easily be able to provide the parameters the designer needs to build the tutorial scripts he needs.

But our designer knows that ideally, tutorials don’t progress until the player has proven they’ve understood the instructions. The gameplay is usually held up until the player does what they’ve been told. Despite everything the team has given him, he won’t have the tools to enforce that kind of control and so will have no way of knowing whether the player has understood the tutorial.

However, the designer knows the game’s scripting system well enough to know how it can be manipulated. If he simply breaks the tutorials up into multiple levels (and therefore multiple tutorials) – all with on-screen instructions – he easily has enough tools to give each tutorial a very focused, very specific, very simple goal that will allow the player to demonstrate what they’ve been taught.

Working in this way, he can script the tutorials so that the player would have to understand the objective of each tutorial to unlock the next one. Each lesson leads neatly onto the next. Since the tutorials are optional, the player is never prevented from playing the game and if they fail the objective they can always replay the tutorials again if they want to.

Problem solved.

To clarify, the idea of the playable tutorial (the obvious solution) could not come from the designer alone since at that point he did not have the tools to make it possible nor could he assume the team had the time to give him those tools.

The solution came from the team as a whole (more specifically from the people who would actually have to do the work) and from the real world constraints laid upon the game at that point in development.

So far, so obvious, right?

Except who is making this game? Is it our designer – the rock-and-roll visionary – or is it actually the entire team working together to make the best game possible? We'll explore this in the next installment.

[Jim Mummery is a small man who cannot code or draw and he lives at the mercy of people who can.]