Author: by Jim Mummery

[In the final part of his opinion piece series on what game designers actually do, DoubleSix (Geometry Wars Galaxies, South Park XBLA) creative director Jim Mummery looks at 'Coffee Boy' to discover why designers as rockstars is still incorrect.] If memory serves, we had dragged the designer kicking and screaming out of the primordial ooze and touched briefly on the role of the design in game development. Due to the nature of its birth the role of design is not clearly defined as code or art roles in terms of the duties and responsibilities that come with it. We are, more than any other discipline, jacks of all trades with all the dangers that entails. Designers fill roles according to the game they are making. And, obviously, all games are not the same, nor are all designers. So how can we discuss design when the indy working alone against the odds with her own money has such a vastly different experience of design from the lead working on the latest cross-platform Franchise Game 2009 for the biggest developer in the world. Well, in an attempt to answer that let’s go back to our fictional Coffee Boy from Part 1. Coffee Boy has vision. He knows what's wrong with games today. He's read/been taught/learned all about emergent game-play, narrative design in video games, how to lead the player, it's so clear how everyone else is so wrong. Our designer is a rockstar wanna-be; his voice that needs to be heard; it has to be heard. So where did our designer end up? The Trials of Coffee Boy Maybe he struck out on his own… found some money, borrowed some money, robbed a bank maybe, uncovered buried treasure, He learned to code, taught himself to draw or maybe found some like minded souls who can code/draw (who also found buried treasure and could afford to work without pay) to create something special however long it took. This is the dream. I may sound like I am laughing at this scenario, I am not. When this industry started people like this were responsible for creating the industry we have today, the basic foundation of which we often take for granted. Even today, the new pioneers are those creating content out on their own; creating some of the most amazing and innovative games you have ever seen. More often than not though it doesn’t work out. At some point most developers entertain the idea of starting their own company and reaping the rewards of their labor but whilst the upside can be great, so are the risks. It doesn’t matter how much talent you have, the chaotic nature of the industry means that things will not go smoothly. And when you’re small it only takes a few knocks for your company to go under, and for your game to join those 100,000s of unreleased masterpieces that never see the light of day. Chances are, like most of us, Coffee Boy ended up working for someone else – probably at an independent development company. Maybe he was lucky and got a junior designer position after only six months of trying, which leads me to… Obvious Point Number 1 1) Most of us work for other people... Most designers don’t work for themselves; they work for dev companies big or small and the ‘relative’ security that provides. So Coffee Boy is a dev now and the more development he experiences, the more he realises how little he knows as to how development is structured. The more experience he gets the more he realises development can often be quite chaotic. His ideas of creating his vision or blowing the minds of the company he works for are quickly dashed. He doesn't get to choose his projects; he's assigned to them, often not for very long. He doesn't get to make decisions, his lead tells him what to do. So he gets on with it. It doesn’t matter. He’ll do it alone, without help, because he’s that good. However, the coder's laugh at his naive unrealistic suggestions; an open-world game, on the DS, in six months? The artists too have reason to be derisory, they want a brief on how his level needs to look; does he realise that the open landscape grey-box he's built won't even run at 10 fps when its arted up. He has a lot to learn. Mostly he learns that he can’t do it alone, he needs to seek out information from others and work within a team, which brings me to… Obvious Point Number 2 2) Most of us work in teams, with teams... Of course team sizes vary. The average has been growing generation to generation but there has always been a route for small teams on casual web Games and now XNA, NDS or digital download. However, the teams grow as the quality and profits do and as digital download titles, for example, get bigger and more expensive. For example, there are companies that throw 20+ people at their XBLA/PSN games. So, the reality is that most of us work in teams that require a traditional team structure; lead art, lead code, lead design. Back to Coffee Boy… By now he has knuckled down, got on with his work but things are not going smoothly – his level is barely half-finished and he’s just seen a huge flaw in it. If he had the time, he knows how to fix it – he’s had enough experience to understand how these things work but, sadly, that doesn’t mean anything – his deadline is in two days and so there’s nothing he can do about it – and so to onto… Obvious Point Number 3 3) Most of us have tight deadlines... The reality is the more the game is worth, the more money is invested in it and the more pressure there is. Crunch on big AAA titles can be just as bad as smaller independent projects but can go on for much, much longer. Then again the finances on smaller projects are always tighter and, as a result, the reason that crunch doesn’t go on for that long is because you go under before then. So we are all under tight deadlines. We all work with too little time even when we schedule for it. Why? Because time equals money and it’s usually someone else’s money. So our poor, confused, idealistic Coffee Boy returns to the games he loves for inspiration; he tells people his level should look like this FPS, play like this stealth-action game but it’s another week and another project and someone quietly tells him he's working on a licensed kart game for the NDS. And so onto Obvious Point Number 4 4) Most of us work on someone else’s project... Despite the perception of the designer as creative source, many of us work on IPs that belong to someone else or on RFPs that were handed down from the publisher. Put simply, for most of the time, we are working on someone else’s project. Even as leads, we often do not have control over many aspects of the project. Of course, we don’t have to; we could leave, set up our company… see points 1 to 3. Where does this leave us? None of these points really fits the rock star myth that Coffee Boy hung onto so tightly when he was on the outside looking in. But now, after a nightmare few months in our fictional development scenario, he has probably been cured. But, even if we accept my broad assumptions; that most of us work in teams, that we all struggle under tight deadlines, that we are usually not in control of the project or the company. Where does that leave us? What is our role? Let’s give Coffee Boy five years more experience and then return to him and see what we find. In fact, what we discover is that he has magically grown up into our other example – our tutorial-deficient friend from the last episode, the one that we left looking at his shoes last time. Let’s take another look at his situation. The Salvation of Coffee Boy Last time, he was working on a game with a team of at least 4-5, probably more and, as everyone noticed, he had no tutorial for his game. This was a problem last time, a problem he overcame through working with his team – but why did that problem exist? It’s easy to blame him the designer – after all the rockstar myth tells us that he is responsible for everything. But is that really the case? Actually, no. He hasn’t necessarily made a mistake. Coffee Boy has had some experience by this point so we’ll give him some credit. It does, however, clearly signify a relatively small scale of game. Games that exist without tutorials (even embedded ones) do so because the player learns the game through playing with no intrusive external voice telling them how or level specific step to show them each new aspect of the game. The game is designed around an escalating experience that allows the player to develop with the gameplay (for those of you that care, examples include Geometry Wars: Retro Evolved and Flow). So our guy could be working on a casual PC game or a digital download title (of course he could be working on a revolutionary console game but taking points 1-4 above into consideration, it’s unlikely). Considering he has a team to work with let’s assume it’s a digital download title. So, to recap, he was working on a game that needed no tutorial but now needs one. Why is that? Last time we mentioned that things changed but what? What triggered this change? Why would he alter the game in such a drastic way as to change his approach to the player’s experience? Let’s go back to discussing who is in control. If he’s working on a digital download title and he’s working for someone else, he has many masters. If he’s on PSN, he’ll need to pass Sony concept approval, if he’s on XBLA he’ll need to do the same with Microsoft. Both companies will have comments and feedback to ensure they are getting the best games possible on their platform. He may be dealing with an IP holder who will want to protect their IP and so will have comments. In addition, it’s very likely he has a publisher and they’ll have lots of comments for the same reason. As will the company our designer works for, as will his team. All of these people want the best game possible, all of them have experience with games, not all of them will have experience developing games and only the team themselves will have experience developing this game. Sadly, the people with the most power to see this game released will not be on the team. As a result, our designer must deal with all this input; from the team, his company, the platform-holder, the IP-holder, the publisher and find what can be done, what must be done, what works well, what doesn’t, what is achievable, what is too expensive and what will take too long. We carefully lay down the foundations for our game, set about building them and then we are asked to knock everything down and rebuild it all in half the time because someone somewhere else knew better. And often, but not always, they are right. While we’re here, it’s worth restating, this is role sits at the heart of being a designer; acting as a conduit, a filter, a funnel for all ideas and comments on the game and cherry-picking what can be done, what fits and what will work with the ever-changing collage of concepts that makes up the game in the designer’s head. So, on a regular basis our designer is dealing with feedback on the game from various sources and adjusting the game as a result. In our example, this is probably why the game changed to such a radically degree that a tutorial had to be introduced. It could be as simple as the addition of a minor mechanic requested by the platform holder or a requested adjustment to the control scheme by the IP holder or the publisher’s demand for a whole new scoring system. Whatever it was, it tipped the balance and created a situation where the game could no longer be learned through play. There are often some counter arguments to this situation. The Persecution of Coffee Boy First, if there was feedback to make changes and Coffee Boy changed the game as a result then they were right and he was wrong, he was making a flawed game. It is the designer’s fault. Second, alternatively, he should’ve stuck to his guns and not changed anything if he really believed in his game, he shouldn’t have given in but he did. So it is, once again, the designer’s fault. Both these arguments are, of course, ridiculous. They assume that it is possible to be right 100% of the time. It is not. They assume that the designer has complete control over this game. We’ve already established that is unlikely. The first assumes that it is possible to be right 100% of the time not to mention having some amazing sense of prescience to avoid all the myriad of problems associated with games development. The second assumes that because he has accepted some feedback as valid, he does not fight his corner. It is safe to assume that if they designer is receiving feedback constantly, some of it will be valid and will need to be addressed and some of it will not. Both arguments come from the same point of view; of someone from the outside looking in. And here’s the trick. This assumption that everything is the designer’s fault goes hand in hand with everything is the designer’s idea. Both are generally erroneous. However, there is a distinction to be made here. The designer is the funnel, the conduit, the filter for all feedback and ideas that come in. And as a result, at any point during his involvement he has to take responsibility for how these ideas are dealt with. So, no – the designer was not at fault for making a game that the team, company platform holder or publisher wanted to change. Nor was he at fault for not fighting his corner, assuming he did actually fight his corner when it was appropriate. However, he is responsible for both the current state of the game and so is also responsible for addressing comments on it, i.e. adding the tutorial. Ultimately, feedback is very important, and the designer’s role includes making a game that will appeal to all parties; the team, the company, the publisher, the platform holder and, above all, the audience. If course, it is all very well saying the designer is a filter for ideas and feedback. But what does he actually do? Sadly, it is usually the case that a game is sold or won through documentation. I say sadly because there’s nothing like a good demo but those cost a lot more money and so are rarer than you would think. As a result, we sell through pitch documents and these tend to be the domain of the designer who creates, in broad strokes, a reason to invest in the game. He states clearly why this game is new; why it’s different but also why it is safe; why it is a sure thing. It’s all a flurry of creative writing and visual imagery. And if done correctly can land you a due diligence visit, a lot of late night phone calls, lengthy contractual negotiations and, ultimately, a project. So, now you have a live project on our hands; you spend the next few months writing up the documentation, writing briefs for the team, collating ideas and feedback – writing the GDD. You edge your way into development. Then you reach the point where you have the tools you need and enough of the game to act as a test-bed. Now it’s time for the fun bit - the real work. No more idea-pushing, no more theory... You spend your days in a haze of numbers – booleans, floats, integers, strings – you live in excel, visual studio and xml – you tweak numbers en masse, carefully adjusting global multipliers or ambitiously ramping up individual values – the best guess values you started with are slowly dragged – kicking and screaming – toward something workable. Days fly by and all you feel you’ve done is realise how far you have left to go. Values blur together. You fix some values – sure they have been set in stone, only to return to them later... This isn’t rock and roll – it’s number crunching, it’s testing, it’s math, it’s experimentation, it’s trial and error and it is the most fun you will ever have in this job. You are changing the game and seeing the results right before your eyes. That never gets old. This is the period where the designer gets to be truly creative – testing and refining until they run out of time. People on the outside joke that you play games for a living – usually you laugh along before reminding them pointedly of the long hours you work – but here, balancing your values, changing your tile sets, altering values global and specific – stick in a spreadsheet that doesn’t appear to have an end – or rifling through endless lua or xml files and then booting the game and seeing the difference – maybe you feel a little guilty, you think maybe they have a point. Here you are using all the lessons you’ve learned from the games you’ve played and the games you’ve made – you carefully craft your experience; you know enough not to listen to the absolutes banded around as laws of design. You know when to take the player by the hand and when to let them explore. In terms of the image of a designer working in isolation; of being creative, responsible and inventive –in terms of the rock and roll genius – this is as close as it gets. So there you are – having fun with numbers when that day comes that everything changes – just like it did for Coffee Boy. Flexible Design Someone wants a big change. Someone who has the power and the clout to get what they want. The change they have asked for is huge; it will invalidate everything you have done so far, it will create more work than there is time or people on the schedule. It will completely change the game. Make my 2D platformer 3D? Add guns to my boxing sim? Make my DS game open-world? In two months? You make your arguments; you fight your corner, you rail at the injustice of it all or sulk quietly over your beer depending upon your approach to stress. It may be that you, the designer, actually agree with them; you’d love to make that game, in fact you would have suggested it already but the restrictions placed on the game to this point have made even suggesting it laughable. I’d love to make that game but we don’t have the time/money/resources to turn our $250,000 game into a $20,000,000 AAA title by next week. All too often it comes down to this; they have clout, you work for them (directly or by proxy) and so a compromise will be reached that will leave you, the developer, in a tight situation with more work than you can handle for too long. So what happens in these situations? There’s a number of fun terms used here: blue sky, paradigm shift, think outside the box. Whoever is asking for the change will ask that the team blue sky the changes. Pretend there is no schedule, no staff shortage, no lack of budget. Design a solution to give them the game they want and we’ll see how close we can get. This is supposed to be a freeing process; it is intended to remove restrictions from the creative mind to allow it to flourish. It is intended to strip away those annoying considerations like manpower, budget and timescale so a real gamer solution can be found. Except when you do this, generally you come up with solutions that aren’t as economic or appropriate as they need to be and often don’t have team buy in. Generally, despite the ‘forget about the schedule’ – time is always limited, very limited as is the budget. And this process is usually left to the designer, it’s his mess, let him sort it out. As far as the company is concerned, they don’t want the whole team stuck in a room making stuff up whilst there are contractual obligations to fulfil. Everybody else has to get on with what they are doing. And as far as the designer is concerned – he only has a very short time and the quickest way for him to do anything is to just make stuff up as fast as he can. Now, working within restrictions is what design is all about. At this point in the project you need to try and find solutions within the context of the game you have. However, the designer cannot do this alone – the team has to work together (see last episode). Even when working within the above restrictions, the solutions must be filtered, taking into account the consequence of each discipline. Once again I am beating my team-is-all drum. Why? Because there are more of them and they are bigger than me and they actually read this rubbish. Seriously, the team is everything. You know this already. Many of you will say it obvious. A game does not exist until the team is on it. A game is the product of those who work on it (however many of them there are). Ideas are nothing but a precursor to implementation and at the heart of that is the process; the filter, the glue, putting all those ideas together – that is core to the role of the designer. Taking ideas and feedback and filtering them; putting them together to make the best game possible; not in a generic, anything’s possible, blue sky sense but to make the best game possible with the team you have, in the time available, with all the surprises your development will spring upon you. These variables will change with each project and with every designer and from week to week, sometimes even daily. You work with what you have. It is that flexibility; that ability to work within restrictions; to work with the team; to be an advocate for the team’s ideas as much as your own - therein lays the genius of our discipline. However, there is a question I haven’t dealt with. Where does the rock star image of the designer come from? If my description of the reality of being a designer is so far removed from the perception of what a designer does why does the rock star image exist at all? It exists because, like the coder and artist team at the beginning of my story, we have been too successful. We now work in a very large industry and we now support a lot of press and marketing. There is a need to promote our games, a PR machine that pushes developers into the spotlight to wax lyrical about their games. In that setting, promoting the game you have worked so hard on, you can only say what’s good and amazing about your game – after all, you want someone to buy it. However, the press and the marketing department don’t want to talk to anybody. It’s not good press, as it’s often difficult to keep the reader engaged when they have to remember who did what and when. Better to talk to one person, who for the purpose of the interview is “responsible” for the game, albeit in a fictional sense. The result is that often we have one face, one voice to tie the game to and very little reference to the team. This creates the rock star myth; the perception that one person was behind it all. It plays to our sense of story; our need for pattern finding, security. He made that game it was great, his new game will be too. However, games are not usually made by one guy or girl. And if they are, they will be coder, artist and designer in one and can argue with themselves on the best way to make games in the privacy of their own blog. Perhaps then this PR process should celebrate teams, not individuals. Perhaps, those who end up in the interview hot seat should big up their team more; maybe the journalists that write up the interview should keep the quotes that refer to the team. End Note So what am I saying? Design is not about being a creative whirlwind to quote one of the giants of our industry. It is not about driving your team insane to paraphrase another. There are a lot of descriptions of design but the only one that seems close is vision holder but not in the sense of creative source or vision creator. It isn’t that. It is about holding onto the vision of the game; not your vision entirely, but the team’s, the company’s, the publisher’s, the platform holder’s and finding a place where all these ideas meet within the restrictions that all these people place on it. You hold the vision, you protect it, you change it, alter it according to the demands made on you. You select the input from the team and add to and take away from the vision. You hold it and take care of it but it is not yours. The truth is that development is always challenging. Design is about working with what you have. Neither of those are rock and roll. [Jim Mummery was asked why he wrote this blog but he couldn’t hear us through the crowd of screaming groupies.]