Unscaping the Goat is my talk from GDC2011, addressing the issue of scapegoating in the game industry, especially as it pertains to level designers. Why does it happen, why do we do it, and how to we prevent it when making games? Here are my thoughts.
(The text in the Speakerâs Notes section represents what I said during this presentation as closely as possible, no audio available yet) Good morning everyone, welcome to GDC 2011, and the Level Design in a Day ⊠day. Last year I talked more about the production side of level design at a high level, and Iâm going to continue that trend this year, on an only somewhat related topic.
So, Iâm Ed Byrne, a game designer by trade.
I helped make these games.
I wrote this book.
This is my favourite game ever, and the sole reason I wanted to be a game designer.
If I could have lunch with three of the most influential humans on my career in any moment in time or space it would be Bob Ross, Jim Henson and Iain Banks.
Okay so Iâm here to talk about something a little different than last year, but something I feel is important to level designers in particular, and something not discussed in open forums like GDC that much. Iâd like to talk about fear of the unknown, transference of blame, targeted frustration, collectively known as scapegoating. Specifically, scapegoating level designers, how it happens, why itâs bad and how best to stop it before it starts
When I was starting out as a level designer, on a game that would one day be called Splinter Cell, I had my first encounter with scapegoating.
I was sitting there, hammering away on a demo level we were putting together to get the greenlight to go into production
⊠when the projectâs producer came by and said âHey Ed, Iâm worried. I just played the level and it really isnât fun yetâ. (even though we were still just prototyping at that stage). I realised later that he wasnât talking about the failure of all the myriad elements (Art, AI, Gunplay, Stealth, Audio, etc.) that went into the game to coalesce into a fulfilling and engaging gameplay experience. He wasnât worried that I didnât have the tools I needed or the code required. He was telling me that the level I was working on - and thus responsible for - wasnât fun, and asking what I -  by myself - was going to do about it. Epic âscape! He had, literally, placed the burden of making the demo successful squarely on my shoulders.
As the years passed I saw this happening quite a bit.
Even in Inception the first thing they do is blame the level designer when things go wrong.
What is scapegoating, and why are level designers so particularly prone to it? Why does it happen? How can it be prevented, or even stopped once it has begun? Why should we even care? I think these questions are so prevalent in our industry that I think itâs an essential understanding for level designers, leads and producers to have, both to see it when it happens and prevent it from occurring in the first place.
The form of scapegoating weâre interested in is the transference of feelings of blame or responsibility - and âpassing it alongâ as it were - until it reaches someone who everyone can feel comfortable attributing it to
One very important point is that this isnât a new or misunderstood process. Scapegoating has been an accepted practice amongst communities small and large throughout human history. In fact itâs almost essential in many cases where the community would fall apart if it didnât have some kind of outlet to ascribe communal fears to. As an example, when disease strikes in the village a victim is chosen to be ostracised as a means to prevent dissention and conflict. There are countless examples of this throughout history. A more modern example can be seen in politics where someone is âthrown under the busâ so to speak to preserve the reputation of the candidate after an election loss. [McCain/Palin]
So, when a group is afraid or angry it turns on someone or something to stop destroying itself. It transfers the fear of failure. Itâs a protective measure that often ends up scape-goating the weakest or least-understood individual in the community.
In my experience, Designers fit this bill - because often their work is the least tangible, the least transparent and most occult.
The scared looking guy in the scene is usually the Art Director, by the way.
Why is this prevalent in the game industry? In the military, a strict hierarchy and rigid definition of roles and responsibilities helps control scapegoating. This is true of other entertainment fields such as fim and theatre In games we have the complete opposite, with no real standardisation of roles, little in the way of agreed-upon hierarchy between studios, even between teams within the same studio. Game designers as a rule are often a kind of strange group not easily placed within the infrastructure of modern entertainment.
And while game design is about planning, and to some extent architectural, Level design is about quality of assembly. A level designer does not (these days) make her own art assets, write his own tools or program his own systems. (continue)
Instead they are given the responsibility of taking what others makeâŠ
⊠and then crafting those assets into an experience that is GREATER THEN THE SUM OF ITS PARTS.
Like an alchemist turning base metals into gold, the final product of the level designer, the sum of all those parts is âfunâ. Itâs picking up a controller and having fun, instead of just simply interacting with a virtual environment.
However, the level designer also often carries the burden of proof of fun. The level designer is called upon to know when itâs fun.
If something breaks down, if some of those elements donât mesh or if thereâs something missing quite often that becomes a problem with the level design. If the AI units canât path properly, if thereâs a long corridor too narrow for an engagement or if the difficulty level is too high that can all too suddenly land in the lap of the level designer as an issue with his or her work.
Why is scapegoating bad? Surely the pressure of responsibility makes those in the spotlight work harder to re-establish equilibrium? Can it not be a valuable tool to highlight problems? What if the scapegoating is actually deserved ?
Regardless of the legitimacy, unchecked scapegoating can lead to a very problematic situations: - It destroys morale and leads to a factionalisation(made up word) of the team, breaking down trust. Iâve personally seen this issue on different teams and different studios. Once finger pointing starts, the work to get back to a place of trust becomes extremely difficulty. This is mostly because blame-shifting is effectively the release of pent-up negative feeling into the dynamic of the team at large This becomes extremely corrosive over time.
It creates stress on level designers to put something out quickly, even if it isnât necessarily good. Knowing that youâve been hung on the line to deliver something fun - to deliver a level for a milestone review for example - can often increase the risk of oversight, mistakes or rushed implementation.
It spreads. While it may feel better to those transferring responsibility, even experienced vets who are in the spotlight will react under the pressure. Often the end result is to pass on the blame (counter-scapegoating) which results in in-fighting within a department, drawing in even those not originally involved. It can quickly take over the entire team
Collapse of the system. Panic/Frustration over a perceived incompetence  will eventually lead others to try to assume the role of the level designer. This is ultimately where many games fail. If thereâs a complete lack of trust, the scapegoat will either flee or be removed as a solution to the problem⊠(continue quickly)
Scapegoating isnât a SOLUTION, itâs a REACTION If the livestock are dying, find the witch and kill her, right? But that doesnât mean the bovine virus will stop killing them, it just makes people feel better to do _something_ when afraid.
And this is the hard part. This is why we scapegoat - weâre dealing with the intangible, the magic. Fun is not scientifically quantifiable, you canât easily deconstruct it, plan it in detail or even anticipate with any great success the nature of its final form - so HOW DO YOU SOLVE FOR ITâS ABSENCE? How do you devise a solution for making a level fun?.
You grow it.
Fun has one major medium in which - like bacteria in a petri dish - it will flourish. And thatâs the heart of what I want to talk about today: Iteration.
Iteration is a word we toss around in the industry all the time, and it refers to the loop of creation, testing, response, collaboration, redesign, refinement. Technically, the definition of iteration is âto repeatâ but as developers we hold it in a much holier esteem. Iteration is the process in which fun is developed but also refined. A great game is a successful combination of interaction, emotional resonance and intellectual stimulation, whether itâs a board game, on Facebook or on the PS3. In order to get the balance of these things right, and working properly, we have to iterate or risk creating something that isnât fun.
But why then does iteration affect the likelihood of scapegoating?
Like a chain on a bicycle, design iteration drives the product forward. If the chain starts slipping -- without iteration, the cycle of construction and deconstruction - thesis and antithesis if you will - a project will quickly become belaboured, in the same way a person trying to ride a bike up a hill with a loose chain will become unable to progress forward much at all.
Developing games is just naturally difficult. Thereâs always pressure â financial pressure, family pressure, emotional pressure .If the process is belaboured, iteration stops and the other team members waiting for the âfunâ to happen begin to get nervous, the pressure builds up, the trust collapses and thatâs what causes scapegoating. Ostensibly a lack of trust in the level designer, but really the process .
So - iteration, keeping that cycle moving, as many loops as possible happening as frequently as possible. Thatâs a nice notion but how is that done? In my experience, there are four things that need to be addressed for a healthy level of refinement, the Four Tâs
Hereâs an example of UnrealEd, a visual, reactive level editor. Powerful but flexible.
Okay, so why is that? Plenty of level designers work in text editors and thereâs nothing shameful about scripting per se. The difference is a commitment to reducing the cause/effect loop as much as possible. The sooner you can see the effect of your changes - real-time is preferable - the quicker you can make decisions about whether that change is good. The shorter the time between having an idea and actually PLAYING that idea the better. Very often a level designer is given a text editor and some arcane scripting tools... âSo just call the new AI you want by adding this block of text! Simpleâ âOkay... ah, cool. How do I test the encounter?â âWell youâll need to just check everything in. And recompile the gameâ âWow, how long does that take?â âOh about⊠THREE HOURS!!!!â </cue Satanic laughter>
You can get _used_ to anything. However the better the tools are tuned to quick turnaround, prototyping and near-real-time feedback the more iteration can happen in a single day. You might find that level designers are actually creating MORE CONTENT than the game NEEDS as opposed to struggling to create content at all.
Tools are often the realm of engineers and thus, a lot of collaboration is needed between designers who will use the tool and those providing the tool. This is something that even junior level designers can assist with.
All too often we simply forget that good work takes time. My rule of thumb in the game industry is that your levels are going to take about twice as long to finish as you thought when you started the game. This is why protecting your polish time is so important.
Honest scheduling. The urge to shorten estimates, and not be the one to hold up your hand and say âweâll need more time if you want something goodâ is strong, especially in an industry slavishly driven by milestones, deadlines and narrow marketing windows. However part of protecting iteration time is a realistic assessment of when the game will be ârunningâ and how long itâs going to take to get âfunâ â protecting that gap and allowing iteration to happen there. This is based on a myriad of factors like platform, average experience, publisher, funding, and on and on. Still, âhopefulâ scheduling is the bane of iteration and project polish.
Realistic scoping. Not every idea is good. Not every good idea deserves to be implemented as a feature, and certainly not every feature will make it into the game. Setting a hard constraint on the scope of the game (how many features, how deep and how broad the feature spread will be etc.) will help make sure the game doesn't over inflate with great ideas to the point where your iteration time is spent spinning up the rest of the game. Scoping is also a continuing process throughout game development. As a level designer youâre on the frontlines of seeing whatâs working and what isnât. As such scoping recommendations are the responsibility of designers, as difficult as that can be sometimes.
Protecting the teamâs time and ability to polish should be the number one priority of those responsible for scheduling and managing the project. The more producers and leads understand the importance of these issues and why time for polish is important to preserve the better the product will be. If you spend all your time preparing a fantastic meal, and forget to leave time to cook it, no-ones going to want come to your party.
Of course, tools and time alone do not produce anything by default. Giving someone a set of oil paints and a month wonât result in a ready-to-hang Van Gogh. Talent has to be a factor and not just art talent, a level design team requires a few key representative skills to avoid hamstringing iteration: Communication. When youâre building a team, look for talent in communication (this affects Trust) and problem solving. While some level designers are not the fastest or most innovative, their ability to bridge departmental gaps, effectively describe what the team needs to support engineers and visualise their needs effectively to artists will make them invaluable. Communication is the cornerstone of any relationship and thatâs true for game developers too.
Flexibility. A team is made of different designers with different strengths - consider scrapping notions of ownership to facilitate best iteration. If you have designers who are good at setting up encounters, have them do that on every level for a while. If you have designers who are stronger visually, get them in with the artists early and have them help flesh out environmental narrative of the maps across the board. Flexibility in ownership allows you to leverage the latent talent in your team.
Diversity of talent increases iteration through faster problem solving MacGyvers can get features and ideas up and running fast, hitting the iteration point sooner Fluid ownership models can often reduce the wasted time of a rigid one-level, one-owner system
Trust is when level designers have the confidence and support of their team-mates and managers to do their thing. In my experience Trust is the hardest thing to preserve throughout the product cycle.
Information  Communication of intention, current state and what will get the level to the end zone. This can be done in scrum meetings in small teams, using a war room to illustrate progress or through specific cross-discipline meetings. At Zipper we even used occasional ânews letterâ style emails to update the progress of the game and levels. However, if people arenât willing to listen, they wonât go out of their way to attend the meetings or read the emails. Always be Communicating even if you feel itâs redundant . Scapegoating, remember, is a product of channeling misgivings and fear, so level designers needs to be active in abolishing incorrect assumptions
A key way to establish trust is to seek critique, incite discussion and follow up with results. If your team - the whole team - isnât sitting down to play the game regularly then itâs going to be an uphill battle. Scapegoaters will rely on their own flawed reasons for blame-throwing and will not take attempts to correct the situation in a positive manner very well. Persevere. Illuminate the issues publically. Be honest in feedback. Invite discussion regularly, but donât design by committee.
Without knowing what a level designer does, what they have to work with or how much they have to do, its easy to make assumptions. Make sure the difficulties of the task and the obstacles to progress are understood. This shouldn't be confused with seeking sympathy. One of the best ways to do this is have other team members ride shotgun with a level designer as they work, or even to try their hand at making a level themselves. The best understanding comes from experience.
Conversely, Strive for pluralism for you and your team. A good definition of pluralism is âa theory that reality consists of two or more independent elements.â Bearing the brunt of responsibility may feel like everyone is out to get you but you need to understand why if youâre going to fix it and re-establish trust. Be open to the fact that others may feel differently and see the situation theyâre in from a completely different point of view. By establishing an outside perspective you can facilitate Information, This makes Discussion and Education much more effective. Scapegoating doesnât feel as bad when you can sympathise with the people transferring the blame.
The team, and managers and directors especially, need the ability to - and this is possibly the most important aspect of trust - to see the POTENTIAL of the level and evaluate it as a concept and not as a product. The biggest problem with panicking when a level is only 80% done and ânot funâ is that it is often reset or wild changes are enacted in an effort to get it âfunâ. This often leads to a stunted iteration cycle where there is either too much in the way of interference from outside (lack of trust) or the changes requested donât happen quickly enough (time and tools) escalating the panic. Trust means faith in other people, but once your senior people can understand the goal of the level as separate from where it might happen to be when they see it or play it , the better the iteration will be. and the less of a need for people to cast blame.
MacGyver talent vs. James Bond talent (in case tools and time are not available, this will help iteration). James Bond had an entire R&D department furnishing him with tools. When he needed a jetpack, Q would give him one MacGyver had to make his own jetpack out of bleach bottles, condoms and baking soda. Generally level designers find themselves in the latter more of the time. Being able to use the little you have and still come up with something surprising, engaging and fun is a critical talent that will only improve with better tools and support. The MacGyvers of your team will also give hope and inspiration to teammates who have a harder time thinking outside the box.
Letâs summarise how these four things will allow for great iteration
And finally, why iteration trumps scapegoating every time. As Iâve said earlier, scapegoating isnât new, and it certainly isnât limited to level designers. It can happen in 5-man mod groups or 300-person teams. Most of the time it happens and people put their heads down and focus on their own tasks. However, Iâve seen it result in negative consequences. Calcification develops, and departments become less flexible. Then paranoia can creep in. Finally, in its last stages, it can result in open revolt with one or more members of a team deciding that the level designers arenât capable of delivering and trying to take over their levels in an attempt to âsaveâ the game. It takes courage to call out scapegoating when you see it, much less try to fix it, but fixing it is possible.
As a level designer you have an amazing role - to take the work of others and to forge experiences and events that players will remember for a lifetime, if done well. But that doesnât mean everyone will see you do it, or appreciate how you do it. Very often the best design work is the subtlest. In my favourite episode of Futurama, Bender the robot encounters God after an unsuccessful attempt at being a deity. God tells him âWhen you do things right, people won't be sure you've done anything at all.â Donât let it stop you from doing things right. Thanks for listening!