GDC 2011 - "Unscaping the Goat" (Level Design in a Day)
•Télécharger en tant que PPT, PDF•
5 j'aime•2,025 vues
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.
Recommandé
Contenu connexe
Similaire à GDC 2011 - "Unscaping the Goat" (Level Design in a Day)
Similaire à GDC 2011 - "Unscaping the Goat" (Level Design in a Day) (20)
Dernier
Dernier (20)
GDC 2011 - "Unscaping the Goat" (Level Design in a Day)
- 7. UN Fear of The Unknown Blame Transference Targeted Frustration SCAPEGOATING
- 9. Whee!
- 10. Your level isn’t fun!
- 11. ENVIRONMENTS UNREALISTIC? Probably the level design!
- 12. FRAMERATE DROPPING? It’s got to be the level design!
- 13. MISSED THE MILESTONE? Damn you level designers!
- 14. FENRIS THE WOLF APPEARING TO BRING ABOUT THE AGE OF RAGNAROK? LEVEL DESIGN!
- 19. Transferring the fear of failure I just wrote the code! I just wrote the spec! I just made the art! I just… Ah, crap!
- 21. Art Director
- 25. Greater than sum of parts
- 26. Greater than sum of parts FUN
- 27. So, will it be fun? Define “ fun ”
- 28. Greater than sum of parts NOT FUN
- 36. Fun Fun Fun Fun Fun
- 37. Fun Fun Fun Fun Fun Design Iteration
- 38. Creation Testing Response Collaboration Redesign
- 39. Creation Testing Response Collaboration Redesign How does iteration prevent scapegoating?
- 40. Creation Testing Response Collaboration Redesign
- 41. Iteration of Game Pressures of Development
- 43. A Good Level Design Tool
- 44. Not a Good Level Design Tool It looks like you’re trying to make a fun level!
- 56. Trust
Notes de l'éditeur
- (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!