How Saying 'No' Can Help You Make a Better Game

[Music] I'd like to know how many of you are currently a producer on a video game or VR entertainment okay all lots of people awesome how many of you aren't a producer yet but want to get into production okay and how many of you are game developers but not producers and you don't want to get into production all right and then how many of your students awesome all right thanks a lot okay john carmack says that focus is a matter of deciding what things you're not going to do all development teams are different but almost all of them try to do more than is possible either just because you have a lot of great future ideas or because you're stakeholders that is your publisher or your lead designer or your fans or you yourself ask for too much I've been a designer and a producer for about 15 years on a lot of different teams and I've repeatedly seen that even

teams that are great at coming up with a coherent focused design plan are rarely able to avoid doing work that isn't in that plan but the studios that survive are the ones who learn how to say no to features or publisher requirements or additional asks that they know they won't be able to get done okay how many of you have shipped at least one game and those of you who have shipped a game how many of you have ever shipped a game that had all of your good ideas in it yeah everybody cuts ideas you have to if you're going to ship so the question is how do you make sure that you're cutting the right things at the right time here's what I hope you're gonna get out of this talk first of all some tools for recognizing and preventing feature creep working within constraints and making the best game that you can with the resources that you have some ways to manage the challenges of your role as a producer while helping your team finish

what you start and some examples of successful teams that did stay focused on their games core features and what they did to make that possible and lastest knowledge that you are not alone other game teams have faced the same problems that you're facing right now they've solved them and they have shipped amazing games okay this is the iron triangle how many of you are familiar with this or I've seen it before awesome okay so a lot of game developers are familiar with this as cheap fast or good pick two but there's another way to look at it each corner of this triangle represents a constraint on one of your resources so schedule is a constraint on how much time you have budget is a constraint on how much money you have and scope is a constraint on how many features you can put in your game now time and money are pretty obvious there are limited resources and sometimes they're extremely limited there's not much you can do about that most of the time but scope is something you

definitely can control and do something about you can think of the area of the iron triangle is sort of the overall potential quality for your game the farther out any of those corners is from the center the higher quality our game could be but the problem is when you're making a game your schedule and budget probably look a lot more like this so people tend to focus on that third corner scope that is your games feature set or the design vision for your game if this is really good you can make a great game even with a very limited time and very limited budget a lot of indie developers do that all the time now a lot of game developers especially new ones will try to just add as many features as possible in the belief that will make their game better they just push that corner out as far as it could possibly go they try to add everything that they think of but the problem is that if your time and money are limited which they are you will not be able to finish all of those features it's just a law of physics that you cannot get all that stuff done and if you ship a game that has a bunch of unfinished features

your quality will be lower not higher only finished features count for improving your games quality so that means that you need to make sure that the features you're choosing to spend your limited resources on are the right ones for your game so really to maximize that corner of the triangle you need to focus not just add stuff great game development teams have a clear shared vision of the game design and an infectious enthusiasm for that design and this is from the game outcomes project which was published about a year and a half ago and you should all look it up it's an extremely informative about how to make good games Paul Tozer and his team surveyed hundreds of game developers they asked them about their development process their team worked their culture and then they compared those responses and did statistical analysis comparing what the team said to the success of their finished games now the results are really interesting some of them are kind of surprising but their strongest result is not surprising and that is that teams that had a viable compelling clear and well communicated shared vision were the

most likely to make a successful game and that doesn't just mean financially successful or critically successful it also means games that met or exceeded the team's own expectations for what they were trying to make so if you only take one thing away from the talk it's this have a clear design vision for your game and make sure that your whole team believes in it so let's talk about some ways that you can create that focused vision and how you can communicate it to your team in a way that creates that infectious enthusiasm and by the way Paul Tozer is talking on Thursday so I recommend that as well all right so we've got a strong design direction for your game you can distill your design down into one clear compelling mission statement the no one lives forever development team had a concise mission statement in place when they're publishing contract was signed and they used it to guide their work throughout the game's development this was their mission statement make the player feel like the hero of a 60s espionage movie has to have a strong narrative it must

feature a fiercely competent hero an assortment of despicable villains the hero must have access to an impressive arsenal of gadgets worthy of get smart memorable death-defying situations opportunities for stealth as well as action a variety of exotic locales and finally every aspect of the presentation must convincingly evoke the era and this statement covers a lot of ground and you can see how this mission statement could help a development team define everything in the game character designs sound effects level design tools lighting techy Minh it gives the team really clear guidelines on how to prioritize their work and it also gives them a way to determine when to say no to a new idea that does not fit this design vision Craig Hubbard the lead designer said it was our intention that every feature task and ounce of effort would ultimately either support the vision or end up on the cutting room floor remember that limits on what you're able to do will always exist but you can make sure that you're only spending time on things that directly support what makes your game great okay so a mission

statement is great if you have a really strong design team or a design director and you have a really clear idea of the game you're wanting to make but what if your game idea is a little more vague pillars are a way to identify and communicate what your game vision is and so here's what pillars are and how you can use them pillars are major features or selling points or unique aspects of your game that can be a strong foundation to build on think of them as the core features that will make or break your game that if you execute on them really well your game will be successful so first before you start development early as possible in pre-production at least or at least very early in development decide as a team on three pillars for your game three is a good number because it requires some discussion from your whole team and some buy-in to decide on three it's also an easy amount to remember and any more than three can tend to split your focus good pillars are actionable specific and

positive they should cover large areas of your project and make it easy for your developers to know whether their work is aligning to your goals and pillars are often very similar to a game's unique selling points or marketing points which makes sense because in a way pillars are how your team markets your game to yourselves like the mission statement pillars are a way for your team to have context for what they're working on and how it supports the game vision of all the games I've ever worked on the ones that have strong pillars from the start or the ones where the development teams did their best work and fully understood how that work was supporting the game design in the first game I ever worked on was Dungeon Siege and though we didn't have a specific enough idea of the design of the game to have a really detailed mission statement we did know the main selling points of the game we were making and that was strategic party based gameplay painless loot management and a giant continuous world with no loading screens now dentists need one shipped 14 years ago and I still remember these pillars really clearly and it's because they were great they they were what we told

the press they got players excited the development team was excited about making this game these clearly illustrate what the game is going to be like to play and they gave the team good guidelines for prioritizing their work these pillars are vaguer than a full mission statement or a 40-page design doc but they did leave us a little bit of room to try some different things as we build the game and as a level designer on that game I found these pillars really useful for my work especially number three because knowing that we were trying to make a big continuous fantasy world with no loading screens let me know that for example I should prioritize exits and entrances to the dungeons making those smooth transitions that are seamless over say making the story really great now when the game came out it was reviewed and people noticed that the story wasn't very great but that was because it wasn't one of our priorities the continuous world on the other hand felt really good to players and they enjoyed that so pillars are a really great tool you should spend time on them you should work on sticking to them because here's an example of what happens when you don't do that

now Diablo 3 during its development had seven design pillars there are two problems with these first of all some of them are extremely vague especially strong setting and highly replayable neither of those are much more specific than just saying my game is going to be good and the thing is as a developer that doesn't help me with my day-to-day decision-making because I already want to make a good game that's already one of my goals and as a player this doesn't really get me excited about the game because I don't really understand what highly replayable or strong setting means and second when Diablo 3 was released the game actually didn't do a very good job of expressing the pillars here that are specific and actionable Jay Wilson talks about this on his GDC 2013 talk on the games design so when does he when Diablo 3 came out the loop progression was actually fairly poorly paced the character abilities weren't very well differentiated and there's one more thing I don't see anything on this list about a real money auction house and in fact

it directly conflicts with at least two of these pillars but that feature took up a lot of development time and effort it wasn't ready when the game launched players didn't particularly like it and it was ultimately shut down now I'm not saying any of this to criticize Diablo 3 the game was successful by many metrics and it made a ton of money but the game the team did not stay as well focused on their design vision as they wanted to and I'm bringing this up because even Blizzard which is arguably the most successful development studio ever has trouble with this this is really hard creating a solid vision and staying focused on it is very difficult even for experts so make sure that you spend a lot of time working on it here's a tool that can make it much more doable which is voluntarily setting constraints on what you're making limit your focus and your efforts to just what you know will make your game really great when the Rocksteady development team started work

on Batman Arkham City they knew that they'd not only need to increase the scope of the game from Batman Arkham Asylum but also that they need to keep the design constrained to something their team could build to the same level of quality here's how Sefton Hill the game director for the Arkham series described their decision players will accept whatever rules the developer decides upon as long as those rules are smart and fun and fair when we approach the problem of creating an open-world in Arkham City we decided from the outset to create what we called the world's smallest open-world game we created a rule that made sure that we were going to have to concentrate all our efforts on the things that really mattered to us now the world's smallest open-world game is a really good constraint you can see how this would help the development team make smart decisions it impacts things like enemy density and level size how Batman moves to the world those can all be guided by this rule and the team can keep coming back to it as what they're trying to make it allowed the team to create a world that felt as dense and well-crafted as the levels of Arkham Asylum but that also felt much broader

in scope and that allowed the player to make a lot more decisions and very importantly it empowered the team to say no to ideas that did not fit this voluntary constraint making games is hard enough so you should create rules which allow you to focus all of your energy on what counts if you have strong design rules that your whole team believes in you can make sure that features that don't support the vision don't get worked on so you don't have to spend any of your precious constrained resources your time and your money on things that don't fit your vision this is another pretty well-known example this is a list of Chuck Jones's rules for the Roadrunner cartoons and this gets passed around the internet pretty frequently and it's easy to see how this list of rules would make it really easy to say no to ideas that really don't make sense on a roadrunner cartoon Chuck Jones was a strong creative director with a very clear vision and he used these rules to clearly communicate to his team what his design vision was and in a way that made it really easy for them to evaluate whether their own work and ideas were a good fit or not okay so what if you

don't even know what your game should be yet maybe you just have a seed of a good idea or a really vague idea of what direction you want to go but you know that you'll need a lot of exploration before you're able to find that clear vision there are good ways to do that too octa dad is a good example of this process the team of student developers started with a basic idea for your game for their game and then they did a lot of prototyping early play testing and major iterations on the design because their game was so unique they didn't have a lot of other games to compare it to the possibility space of what they could build or what could be fun and this type of game was very large so especially when you're building something very innovative or that no-one's done before an agile exploration approach to your game can save you a lot of wasted work and it can get you to a good game a lot faster oh sorry spoilers okay so this is how games are traditionally designed you start with a design document you spend a bunch of time building that you get to version one and then you realize unless you're

working on a slam-dunk sequel that you need to make some big changes to actually make a good game so then you do a lot more work than you finish version two and they ship it but more developers are starting to use a more agile approach they have less of a clear target but a sort of a idea they work toward it but then earlier they prototype and play test they iterate and they changed their design a lot more frequently this means that you do less work on the game overall more of that work is spent on the right features and it means you don't have a clear vision of the start of your project and that's ok as long as you make sure that you leave yourself the time to iterate and that time to find what your vision is and focus in on it now this can be risky so you need to make sure that creating that core vision to find your game is your top priority at all times and then you don't get too distracted by cool ideas that don't really get you closer to that finished game once you have your game vision once you've identified what you're going to be you're still gonna have plenty of work to do everything from the way Octodad walks to the kitchen challenges

to octodad's manly tentacle moustache was the product of an exhaustive list of possibilities and seldom did we go with our first idea our dedication to exploring every avenue served us well there's a post-mortem by the octave ad team up on game courier guide and it's a good read the octave EDD team represents the best and worst of this agile design approach they play tested early they iterated on their core idea and they ship something really unusual and attention-grabbing and fun but they also got distracted coming up with a lot more features than they could actually build they played a lot of Minecraft and they ended up cutting really big chunks out of their game ok so you have a good design vision for your game or you at least have a plan of how to come up with one now you have to protect that vision by managing your scope because sometimes your lead designer is this guy I was just playing World of Warcraft when I was struck by a flash of inspiration our game should have epic battles working on the email to sunder the rest of the team now I think we've all worked with this guy you know his heart is in the right

place but this is why scope management is so important inspiration is everywhere your team is made up of a bunch of smart people who decided to be game developers on purpose they're never ever going to run out of ideas ideas are an infinite resource but finishing those ideas finishing a game that includes some of those ideas requires resources that are not infinite okay back to this again the iron triangle constraints feel really frustrating especially when you're trying to make something amazing we often get into the habit of thinking that if our publisher would just give us more money or if we just had a little more time or if our team would just work longer hours or if your team would just get on board with all of your awesome ideas that you want to put in that your game would just automatically be more awesome but that's not actually true big budgets lots of time and freedom from creative constraints are seductive traps don't fall into them remember how having a shared clear design vision was the

number one correlating factor to game success the number two factor was protecting that vision by managing design risk that is protecting against building the wrong things statistically the biggest risk to your game is not lack of funding or lack of time or someone else stealing your ideas the biggest risk is wasting your precious development resources building the wrong features embracing your constraints will help you guard against that say no to ideas that don't fit your time or your budget constraints or don't fit your games vision make the Iron Triangle your ally and use it to protect your game the features that you don't do are just as important as the ones you do if it's going to take away from the game then not doing that feature is an important decision now this is really hard to believe when you're working on a game often your vision of what the completed game will be like includes all of your cool ideas and anything else that tends to pop in your head but when you have to cut really big features it's hard to imagine a player seeing the finished

project and not noticing those giant holes that were left by your cuts but if the rest of the game embodies your clear focused vision your players will not see what you had to cut away incomplete or badly implemented features or features that don't really fit your games design vision do stick out like a sore thumb but missing features are almost always invisible if the rest of the game is executed well as Bruce Lee said hack away at the an essential now the last big game I worked on was Middle Earth shadow of Mordor this game started and ended with a very strong design vision but during production a lot of features were added that were cut and I'm not talking minor features I'm talking about major game systems entire levels really awesome features that some players would have really loved and the final game was successful though without any of those things that were cut players really loved it the Nemesis system or individual enemies that you fight like and come back with more abilities and more personality was a big hit with players and the team was really proud of the game that they shipped now cutting the big features did

leave holes but players as far as I can tell didn't even notice them I didn't see anyone online saying like oh yeah I mean that game was good but it would have been way better if there were two totally different factions of orcs in a civil war and you had to like politically manipulate them or you know the combat is pretty cool but without that house-sized giant beast to climb and parkour around on I just felt kind of empty like nobody noticed that those things have been cut and a lot of work didn't go into finishing those features when those features that didn't match the vision or cut it made the game feel more finished not less finished so how'd he decide which features are the right ones to cut and which features are the right ones to really focus on and spend time on it can help to have some kind of process for making decisions on new features or additions and to make sure that everyone on your team is on board with it this is often called change management or scope management so let's go over some tools that can help your team have a have good scope management so you can stay focused on building the right features

okay the first way is objective feature ranking there are two big problems with new ideas that your team comes up with first of all someone on your team is going to be convinced that no matter how expensive or risky or hard to implement a feature is it's going to be the best thing in your game and the second problem is that person might be right you never really know which feature is the one that is going to be the thing that a player falls in love with and tells all of their friends about so if you find an objective way to rank your plan features it can help a lot like the Arkham City team The Witcher 3 development team knew that their new project was a lot more ambitious than which are one and two so they used a numerical grading system similar to the one in this table team members voted on the features they liked the best and the features were evaluated for level of effort to implement and then those two numbers were combined into a value score and they use that to prioritize their backlog and decide what to work on now a lot of teams hear about techniques like this and they don't even try them because they know that the numbers won't be perfect and of course they won't if

you're trying to rank your features early in pre-production to discuss like guess how much a future will benefit your final game of course it's not going to be a totally accurate number but what's important here is the act of looking as objectively as possible at your ideas and really considering whether they're worth spending time working on assigning an actual number to a features value can help you evaluate that more logically instead of just based on who on your team expresses the strongest emotions a second way to help manage the scope is to have a future backlog or ice box so if a proposed feature isn't very high value or if you're just not really sure if it fits your design vision well you can put it in your backlog let it sit for a while don't work on it and then it's possible that as you work on your other features that you know are high value or essential you'll realize that you didn't need those features at all and that they don't really fit your game it's also possible that you realize that they were worth spending time on you can pull them back out of the backlog and finish them knowing that you have enough time to do so make sure you do this early in development though you're gonna get closer to shipping then you know much

faster than you think you will and it's a lot easier to put something on the back burner if you haven't already put a ton of time into it and finally external feedback is invaluable for scope management it's very difficult as a game developer to be as objective about your game as you really need to be so as early as you can do regular play tests with people who aren't on your team do they find your game satisfying do they want to play more of it do they see your vision coming through and what you're building even before you have anything playable when you explain your game vision or mission statement or pillars to people who aren't on your team do they get it and are they excited knowing what feedback to take from play testers and what feedback to ignore is a learned skill you should be as objective as you can and find some way to measure player feedback with numbers if at all possible this is a screenshot from antechamber Alexander Bruce the creator of antechamber tracked the play times of everyone who tried his game demo conventions over years of iteration and

he used that number as his metric how long will player play your game voluntarily before they walk away he increased that number from an average of 5 minutes to over 40 minutes and the result was pretty amazing antechamber is also a great example of agile development and iterating until you zero in on your game design you should check out Alexander Bruce's GDC 2014 talk it was rated best talk of the year and it goes into a lot of his development process there was also a great talk yesterday by Ben Kane on designing keep talking and nobody explodes he also talked about using this process they eavesdropped on players playing their bomb defusal games game at conventions and then they use the data they gathered to iterate on the game and focus in on their core design which was a game about communication between players so you should check that talk out as well if you're interested in the more agile exploration and approach to game design and mostly remember that if you aren't measuring something it's very hard to improve it and even if you do improve it it's hard to know that you did so having

an objective numerical measurements for things in your game that you want to be great will let you know if you're actually succeeding here's another way to do metrics so Warner Brothers hired immersive which is a firm that studies player behavior to conduct play test for shadow of mordor and our the Arkham games to see if the games are satisfying for players our Mercer's research has shown that whether someone is having fun is a really poor indicator of whether they'll keep playing your game or if they'll tell their friends about it but there are specific needs that players have that they come to your game to try to fulfill and the needs that they use and measure our competence or the feeling that the player is effective and skilled when playing the game autonomy the feeling that they're in control of their own decisions and relatedness feeling a strong connection to other players or game characters or the game world Troy Skinner and Scott Rigby from immersive get a really good talk on their process in 2015 it's in the GDC vault and Jason Vandenberg is giving a

talk Thursday afternoon about player motivation that also discusses these metrics and I'm not saying that you have to use these exact ones although they are very good set and I personally believe that they were a critical part of why shadow of Mordor was able to refocus on their design vision and they have a solid foundation in psychology outside of games if you think about like what you find satisfying in your job and your day to day work it's probably a really similar list to this one but again the important thing is to identify something measurable that you want your players to do and then measure whether you're doing that Alexandr Bruce wanted players to play antechamber longer Warner Brothers wanted players to be drawn to their games and the ways that make people tell their friends are awesome a game is if you want your players to really be drawn into your game's story for example you know ask your play testers to rate on a scale from 1 to 10 how immersive they think your story is and then work on it some more and then ask any batch of play testers the same question and if that number goes up you're probably doing something right remember though that having measurable goals requires you to know what you want your game to actually be so it always comes back to having that clear strong design vision for your game alright so

many of us have worked or are currently working on free-to-play games that monetize through in-app purchases and for those games you already have Chiefs of metrics that you're supposed to maximize so you got player acquisition engagement retention install rate monetization how often your players are giving gifts to each other you know how often they tweet about your game like so anything you can measure about a player um and that's great but what's interesting is that this set of metrics is really strongly correlated to this set which is that if players feel that your game is satisfying their needs they are gonna keep coming back to it they are going to tell your friends about it so if you find some way to measure whether you're giving players what they need and make decisions based on those numbers then you can maximize a lot of metrics at once all right so you have a solid vision for your game your team is excited about it you have a process for deciding which features to work on and which features not to work on you have

objective numerical measurements that match your design goals your team understands the importance of scope discipline and what the biggest risks to your project are but then someone on your team has a cool idea for an awesome design feature but it doesn't fit your design vision so what happens next I once interviewed for a producer position at a major game studio they've probably heard of where I kept getting asked the same question how do you deal with people hating you when you tell them they can't have something and that question really worried me and it indicated to me that the team has some really major problems people who are not willing to work within constraints are like a nuclear reactor with no control rods they caused a lot of damage and they don't produce anything useful right now on your team you probably have some people who act as your power source they're the ones coming up with the awesome ideas building prototypes feeding energy into your team and staying excited about that cool game you're building and you probably also have some people who act as control rods the pragmatists who keep an eye on your priority is your

budget your schedule and you make sure that everyone is staying focused and working on the right things and you need both of those types of people they're both vital to your success if you're a solo developer you need to be both of those people which is really hard if you don't have that right balance between passion and pragmatism on your team and especially if like that team I interviewed with one or the other of those types of people is seen as a problem then you have a major fundamental team issue that you need to fix both your optimists and your pragmatists are precious resources you have to have both if you're going to ship a great game now a lot of game developers and a lot of producers are afraid of saying no to cool ideas because they don't want to dampen their team's enthusiasm or slow down their momentum but enthusiasm is only effective when it's directed towards the right things people do their best work when they know that they're working towards a specific and exciting goal so give them that goal by having your clear design vision now there are potentially bad consequences for saying no to features you might upset somebody

you might accidentally say no to the coolest idea for your game or you might be overly cautious so let's go over some tools you can use when saying no that will minimize those negative effects first is yes but before you say yes make sure that the stakeholder fully understands the consequences of what they're asking for remind them of the risk they're adding make sure that they know it's their responsibility remind them of the design vision that you agreed on make sure they understand that design vision they fully believe in it and protect that vision as well as you can so for example yes we can do another demo for e3 but it will delay the next milestone yes if sometimes well all the time your team will get new information they'll mean you need to do something different sometimes a major pivot in the project or sometimes just a minor change or addition but it will happen for sure and it's okay when it does yes if is figuring out how to do that necessary

new thing so yes we can do another demo for e3 if we cut half a level 14 or yes we can add that feature if we cut something equally big what do you think we should cut from our list of things that we already agreed on this is where having that ranked feature list can come in really handy cooperation not conflict when a stakeholder wants something new added and you know that it will add risk to the project or that it doesn't fit your design vision don't let it become new versus them that's not productive it's not a position you want to be in it makes it really easy for people to dismiss you as someone who just hates fun but you and the person asking for this new thing both want to make a great game you both have the same goal so make it you and them versus reality like the priorities we agreed to at the beginning of the last mile put this demo last and now you want to move it up so what do you want to move it above what can we change about our plan to be able to do this new thing that you want that's really important to the game what can we do to create a new game within those constraints that exist that we can't change and finally follow

your process even if you don't have really strict numerical rankings or metrics you should have some objective way that will let you be confident that a proposed feature will or won't support your design vision you won't have to worry about accidentally cutting the best thing in the game if you have some way to objectively measure what the best thing in your game is all right none of what I've said up until now will do you any good if the ambitious optimistic people on your team just will not listen to your pragmatists or if your team's prioritization decisions get overridden by someone higher up the chain of command so what happens if like that team I interviewed with you have people in authority who just will not take no for an answer the best thing you can do is arm yourself with data remember all those metrics that you're gathering on whether players are doing what you want and encountering your game the way you want them to keep those ready at all times I know it's more than one really good producer who just keeps a PowerPoint always updated with the latest metrics that they can pull out

and convince whoever needs convincing that their team is making the right decisions make that person who disagrees with you show you in your data where you are wrong be really clear about trade-offs present a menu of options if you have to make them choose if the choice is realistically between feature a and feature B show them the data that proves that that is a choice that needs to be made and then make them make that choice stand your ground if you're working with someone who stubbornly refuses to rein and their ideas or requirements or refuses to cut features if you're not just as stubborn as they are your game will not ship and find allies on your team who might know more about how to get a specific person to listen or who might have more authority than you and who want to know the real situation on what's really doable by it for your game people who have been around for a while and have shipped a lot of games often want to hear the truth about what your team is capable of and if you've been gathering

and keeping track of that data they'll see you as a valuable resource and they'll want to hear what you have to say now at last though if none of those help don't force yourself to stay in a situation where you can't be effective this is reality if you're gonna be beating your head against the wall until you ship a bad game that was the best you can do under the circumstances don't make yourself go through that game development is hard enough without working under people that make it even harder alright and then remember that saying yes is never free it always costs you something for one thing every feature that you add to your game adds some risk maybe a little or maybe a lot but always some anything you add to the design requires more assets that need to be created more gameplay that needs to be tested more bugs that will have to be fixed later on keep your eyes open to that cost and make sure that your team can handle it and again make sure that anyone requesting new additions fully understands that cost if you say yes to something you are agreeing to really

believe in it and you have to make sure that your team believes in it too if your publisher mandates that you add a My Little Pony champion to your MOBA you have two options and neither of them is saying now you can say yes and you can half-ass it and your players will hate it and you'll hate it and it'll be a terrible part of your game or you can say yes and you can believe in it and you can make the best damn my little pony champion you can possibly make a great example again from shadow of Mordor the games publisher like they do required regular demos for conventions and for press and instead of reluctantly saying yes and viewing those demos as yet another unreasonable publisher request or demand and half-assing those demos the team used those demos as a tool to make the game more polished and to get a better understanding of how long it took them to finish a feature they took something that should have been a burden but they made it something that benefit them and that they actually believed in doing ideally anything you say yes to should add value to your game if it doesn't see if you can figure out some way to get some value out of it if you have to do it anyway and remember that

whenever you say yes or no to an idea from someone you're setting a precedent for how much of a voice or how much authority that person has anytime you say yes to someone you're making it harder to say no the next time and anytime you say no to someone you're making it easier to say no in the future the people involved in your game inherently have different amounts of authority if your publisher controls the budget they're gonna have more authority when they ask for something than say your audio designer but that doesn't mean their ideas are necessarily better or a better fit for your game this is another reason why it's important to have both a clearly design defined design vision but also a way to objectively rank features if you don't have those things you're in danger of getting in that habit of just saying yes to ideas coming from people with more authority regardless of how good for the for your game those ideas actually are and last remember that any time you say yes to something you're saying no to something else you just might not know what it is yet because your time and money are limited if you spend them on something that inherently means that you can't spend them on something else and especially

when you start playtesting your game and when you start coming in towards the finish line you're going to find things that could make your game a lot better that if you hadn't spent time on low value features early on you might have time to really really make great all right in conclusion making games is hard making good games is nearly impossible a strong clear vision is vital for a good game and your team needs to believe in and fully understand what that vision is you need to protect your design vision by saying now if you can't say no you can't control your scope and you can't control your risk and constraints are your ally not your enemy make friends with the Iron Triangle and use it to work for you nice there's a [Music] [Applause] all right there's my email address if

you want the slides I will send them to you feedback is welcome my twitter and then some resources so the game outcomes project if you are a producer or a designer you should definitely read that there's a lot of really great post mortems up on gamasutra which is where i got most of the case studies in this talk the GDC vault has a lot of great talks as well especially again the talk on antechamber in 2014 [Music] books the mythical man-month is a classic old lady 3040 year old book on project management but it's got a lot of good wisdom in it and then i've been a project manager for nine years and i've learned some stubbornness all right so questions I think they're gonna want you to line up at the mics hello hi I'm Linden Great Auk I'm wondering about sequels you said no one would miss the features you cut but what if they had been in a previous game would you have cut them anyway oh you

mean if you so the question is sequels if a feature had been in a previous game can you cut it first sequel is that we're asking yeah um that's a good question I've worked on a few sequels and usually they're easier because it's easier to zero in on what you want to add to the game but I've also worked on some more sort of floundering messes I know I mean I'm gonna say it depends but again I think it's just as important for a sequel to have a really clear design vision of what it is and whether you're sort of incrementally adding things to the previous game or whether you're doing something completely different and and there have been really good sequels that have done in each of those things where the sequel is pretty different from the first game and still really good or whether it was sort of the first game plus a few features but I think it really again just comes back to like having a really clear idea of what you want to make and then validating it by having people test it or at least you know like like the Destiny team just show people their concept art really early on and they said does this look cool to you you know like they would they would test players potential players on how they felt about the concept art so if you have the original game you have players that are familiar with it and they have a few ideas for

what you want to add to it or even take away from it I think that would be a lot easier to validate even than just a brand new game idea thank you yeah hi my name is Franco the way our team works is we're resource for different business units and we're constantly butting our heads up against people who think they know more and then you know they should like you're a shared services group for you yeah we're like a just a services group within the company so have you ever had to like cave and did it ever actually turn out to be a good thing well let's see so the question is have you ever caved and had that turn out to be a good thing um well first of all shared services like like you know I keep I keep something like game development really hard get in it and I know you guys all know that shared services is like five times as hard as that it's I've actually never seen a

shared services group that worked really well um and I think because like when you're making a game people assume that game developers can just do way more than they can actually do because they don't think about all those hidden costs and with shared services it's much worse because people like oh you know I have five artists I can totally use all five of them they don't realize that every other team is thinking the same thing um so I think like my opinion is that with shared services you have to be even more anal about really ranking what you're going to do and having a queue and being able to say no and telling someone like you know what you're not gonna get that for two months because we have all these other things above it in the queue but I'm definitely familiar with teams where the stakeholders just won't listen to that and then I think it comes back to like you know what happens if they don't listen to you if they don't listen to you when you say like like there is no possible way within the laws of physics that I can do what you're asking right then at that point there's there's honestly not a lot you can do sorry it's it's like I think that's why shared services is so hard as because people just are really reluctant to agree that you know five people can't do twenty five people's worth of work right right

yeah for the most part we try to like your slide said like you know show the data yet just really stick to that but almost like half the time it that's it yeah right and I think there's this tendency in game development where people are like oh data like that's not for meit we make entertainment you know games like data is for like you know people make tax software it's like notes like data is data and I think the more data you can have and Cheryl you know this is how long it takes us to make an asset we've done it 50 times this is time number 51 I know it takes us this long you know some people just will be really reluctant to listen to that but if you can just make it really obvious there will be at least some people on your team that will appreciate it that I do right thank you yeah hi there so I have a question we have like this really Rockstar programmer he's like unbelievably good keeps our stuff on time one of the problems we have though is that we work an environment where our customers are just down the hallway from us and they'll come down and they'll say hey I thought about this thing can you do that and oh yes you're not a problem and then we

have like all these added requirements that have been promised huh and unfortunately it's a military environment so you can like just get rid of them yeah well so I think I think that's that's something that happens so the question is we have a really rockstar programmer and people will swing by his desk and go hey can you do this thing and he'll be sure I can do that thing and then he has way too much on his plate the the problem is the question they're asking and the answer he's giving are sort of - like not aligned to each other so what what they're asking is like hey can you do this thing like well yeah of course he can do that thing he's a genius like he's really good at stuff of coercing it but but what they should be asking and what the question you should be answering is can you do that thing and also all the other stuff that you had to do and can you do that thing for me right now and not disrupt any of the other stuff in your list and the answer to that is like no you know that's impossible so you can either sort of put someone in between him which you know I've been sort of the buffer of like come to me first and then I'm you know a little better at answering the question of like no we can't do that and all the other stuff which is really the question you should have been asking me so a lot of times it's sort of like reframing the question back to them you know if they say like can you do this thing you answer no we can't do that

thing and all the other stuff on his list look at his list here's the data you know um it's not always possible to do but I think that's that's the way I found that kind of works is just to like remind them this is the question you should be asking me is can we do all the other stuff we already need to do and this thing the answer's no all right so this is about Peters about what sorry the pillows yeah yeah so basically you spend a lot of time defining the pillows you are a safe house you're you sure about them and they're gonna guide you for I don't know nine twelve months two years whatever what as a producer not as a designer but as a producer will do will you do if you discover after six months that one of the pillars was wrong or unattainable yeah you know that's that is terrible in that happens I worked on a game where that happened we had three pillars and one of them just like was not fun and we couldn't make it fun it was terrible and we basically shipped half of a game and

that's really bad so I think really the only thing we could have done in that situation was oh sorry the question is what happens if you have three pillars and it turns out one of them is bad and you have to get rid of it um I mean ideally we would have had some kind of backup earlier and also ideally we would have done more play testing earlier to validate whether we could make this thing work and the thing is it was really innovative so we didn't we kind of weren't able to play tested until it was mostly done which is a situation that you should try to avoid but yeah sometimes sometimes you'll get part with you development and one of your pillars just doesn't work then you have to cut a huge chunk out of your game and at that point I think it's just either double down on the other stuff or pull something on your backlog that can kind of help but yeah I mean sometimes cuts really hurt and sometimes they make your game way worse and that's a terrible situation sorry I don't have a magic answer for that but it's like yeah that happens and it's terrible hello I've got a question now it's going to be very difficult to answer probably as we know developers artists engineers

they like to tinker they like to continue your clean things at what point with a feature do you really get that definition of done that you decide you know this is this is done you know even if it's this buggy or this incomplete it fits the vision that we're looking for and let's move on or yeah you know I need it to continue to get to that point yeah that's my definition of done so I'm gonna cut these other features yeah how do you define done and how do you like pry something out of someone's hands when they really just want to make it perfect forever like I always think of there's sort of two types of people on a development team there's artists and there's craftspeople an artists are the types of people that will iterate on like a character's hair for like two years if you you know they would do that and you need those people but then the craftsmen are the people who are like this is good enough let's ship it you know and I'm definitely that second one um I think this is great it looks great to me let's trip it which really frustrates the artists so it's in a way it's like come to come to some agreement on how you can mostly satisfy both of those people I

mean if someone's in game development they like nobody gets paid if your game doesn't ship so you know they all know that you have to finish at some point but I know it can be really hard so I yeah I don't have a great answer beyond just sort of talk about it and make sure that everyone understands that that's the situation is like I know I recognize that you were the kind of person who could fiddle with that thing for the rest of eternity and that's cool that you're like that because that's a really good resource for us but you know but we only have this much time we really need to let go of it and and just kind of like make it clear to them why that's happening and not just that you're like there to ruin their life if that makes sense yeah yeah similar to his question he was talking about done and you mentioned exploration I think any experienced developer knows you need a level of exploration but it's the hardest to budget and schedule exploration so when you have a design feature it's pretty easy to give it a team and say hey how long does it take to make it so what's your experience and processes you've used to to schedule a budget for that exploration and say when it's over and it's time to turn in to production I think let's see most of the

games I've worked on so there's there's kind of different types of games right there's ones where it's like this game has to ship by Christmas to match the movie and therefore when you walk back from that it's like okay pre-production has to stop in September or whatever right and then there's the kinds of games where especially Indies or you know like like right now I'm in research and we don't really have like like deadlines to ship stuff and then it's just sort of like recognizing it's kind of like the the other previous question of when you rip things out of people's hands and say this is done now it's just sort of self-imposed deadlines and and constraints and goals that aren't necessarily like set in stone and expose me outside and that's where it requires some discipline from your team just say okay we're gonna play test for a while and then we're gonna stop I mean unless your valve like valve has so much money they don't ever have to stop play testing right they can iterate forever and ever and never ship anything and that's a great situation to be in but I think amazing that you're you know if you're not in that situation and saying like no we're gonna have to ship you know at some point I know that a spry Fox just

does a lot of calculations on like how much money do they have and when do they have to ship in order to like make some money and then you know move on to the next game so when you don't have those sort of externally external pressure of deadlines you just have to sort of create it for yourself hi good talk oh thanks so I'm producing a master's thesis project and since it is one student's project and there are other students working on it there's no budget involved and there's a clear hierarchy of where the decisions should come from so I think that has created some problems in not only creating a cohesive vision between the group but also sort of deciding what level of autonomy the artists and the sound designers and everybody has so I was just wondering if there was a non data based way to sort of reconcile that okay so yeah so for a student project where there isn't a clear vision and there

isn't a clear hierarchy but there is someone who has like more authority than everyone else um I think what might help in that situation is just like have a lot of discussions about what the game is I've been on teams where where it was sort of like fluid like that and there there wasn't a lot of clarity and sometimes just like sitting down and talking about like okay what is this game and asking them to explain it to you and then kind of zeroing in on like oh okay it sounds like it's this inocent you know and like you can kind of find pillars that way maybe and then once you have those pillars and again it's sort of you know input from everyone working on it at least some input from Roane working on it and you'll always have like an artist who is like but I want to make final fantasy and you're like well that's not what we're making like but that's what I want to make it's like well here's the pillar you know like like sometimes you kind of have to override people but but having some kind of like community like okay what is this game discussion kind of regularly can help like you don't want to end up in a rabbit hole where you're just constantly doing that forever um but if you feel like you're making progress I think that can be kind of useful and just sort of like as the producer coming to it as a

questioner and being like okay tell me what this game is you know what am i doing like what are we doing you know and and being a sort of objective like question trying to get them to define what it is what happens if you've asked and they just sort of don't really come up with an answer collectively then so sometimes if you've asked and they don't come up with an answer sometimes you can you can kind of play dumb and just make your be like here's what I think the pillars are show me where they're wrong you know and and I think when you show someone something that doesn't match what they're thinking it's sometimes a lot easier for them to point and go like oh wait that's wrong it should be this other thing and just kind of like write things down or say things out loud and have them correct you until they find out what that is like yeah as a producer like not having a lot of ego and just being willing to say things that are not true or that are wrong out loud and be like oh I think it's this and they're like no you're an idiot it's actually this other thing you know oh good you know like actually I got you just so it was you know um and not not exactly like that but um but just being willing to like say things out loud and tell people correct you -

the right thing can be useful good luck um hi I'm a localization producer okay um so I often run into situations where I'm kind of in the naysayer where I have to convince the original content in the main office to cut features that are not culturally relevant to Western markets I just was wondering how often do you have to come up against going against the vision of maybe the I guess the powers that be mm-hmm but still retaining like I don't know without getting them so angry at you because you're just you're always the naysayer like I have trouble dealing with what is it being I guess the negative person the entire time yeah like I guess yeah mm-hmm yeah yeah so localization I think like localization UI and things like accessibility or like publisher cert requirements are all like that where it's like okay like you know these are things that we really have to

do and they're not fun things they're not like fun cool things so no one's really interested in then put them off until like the very last possible moment yeah and then they're like oh crap we have to do all the stuff so um again I think just just really sort of presenting your data really objectively and be like here's that list of things like I worked with the certification producer who is really good at just saying like here's a list of cert requirements and we're like well we hate those like we don't wanna do any of those things she was like well here's the list here's where we're not meeting it and just sort of presenting it like over and over and over and people did have a tendency to be like oh she hates fun and if she'd you know she doesn't like our game but you know of course she did she wanted it to pass certs we could like ship it and make money um and I think you know just sort of like maybe reminding people of the overall context of like hey you're the one who wanted us to localize into Dutch you know like I didn't come up with that idea you know um it's it's tough though I think I think especially yeah those sort of like and finishing polishing things that no one's really interested in are like really localization is super hard yeah I think the problem that I've run into mostly is

kind of like I don't have a lot of data to back it up because a lot of it is cultural contact so you can't really quantify cultural contacts yes so yeah yeah and even like yeah articles or best practices or guidelines and yeah sometimes don't those don't really exist but any any kind of backup you can find of like this was written down on the internet that like you know we really shouldn't do this in this country but yeah that's because the tough and thankless job thank you very much okay I think we're are we out of time yep all right I'll run out in the hallway though for overflow if anyone else wants to talk and thanks a lot again everybody [Applause]