Rules of the Game: Five Techniques from Quite Inventive Designers

[Music] hello hello I think we're going to get started here thanks everybody coming I supposed to remind you to turn off your noise making devices before we go so where do you get your ideas and that's the question every writer dreads this there's some magical place where these ideas come from anyone who's been working in a creative field for long enough know that like writing or like games knows that ideas are a dime a dozen what implementation is hard don't get me wrong good ideas do help officials in the details of implementation writers get access so often that they come up with picky answers like Harlan Ellison would say Schenectady there's an ice shop there where you can order ideas and they come in a tidy box and then you use them Neil Gaiman had a picky idea a pity answer just as well until he shifted to just saying honestly I make them up out of my head so anyone who's been doing game design well enough has probably heard our version of this where do you get your game ideas or maybe the the slightly better but still not great question how do you make your games fun you know pro tip for anyone who's just getting into game design professionally we don't like the word fund very much because it's too amorphous too broad too hard to define what exactly you mean of course we want people to have fun but it's not a very useful descriptor but this is a better question or maybe maybe how do you make your your games work right that's the question I like to ask veteran game designers to try to figure out what their process is how they go from those interesting ideas to a game that's that good and that players enjoy because it's going from the idea to the working game that's the hard part how do you get your prototypes to work how do you make them quickly enough that they thought they solve those big risky questions early before production starts how do you get your systems to work so that people are hooked so that people keep playing they understand what's going on how do you make your enemies work so that they're challenging enough how do you make your teams work so that everyone's turning going in the same direction so this is the rules of the game session my name is Richard rouse I will be your host today I'm a director designer writer at paranoid productions where we were working on an action infiltration game with a shifting narrative called the church in the darkness our format today is simple five designers get 10 minutes each to talk about a game design rule that is personal to them we did this session first last year with five other game designers and this turned out pretty well and you can go watch it on the vault it's up there for free if you go to GDC vault and search for five rules this will come up at the top on that session went pretty well and was really interesting so we thought hey let's do it again and get a new a new set of designers so as I said last year game design rules are personal not Universal and that means a lot of the rules you'll feel today are things that these specific designers really enjoy using that help them make their games you know whatever genre whatever a team situation may be maybe in just because you've you're a rule today here today doesn't mean it's necessarily the final word on the subject but I don't know about you but I find it interesting to find you know to hear from people who've worked on great games like some of the ones behind me now what rules they used when making them not so I can copy them so that I can try to understand what my own versions of those rules might be you can think of your game design rules it's like a deck of cards that we have game designers can choose to play and deploy when the time is right I've been working as a game designer for a bit for a while so naturally I have my own deck of these rules sometimes those rules are specific to a project so for example on the suckering game now these might be some of the rules that I used you know I wanted a consistent rule-based world I wanted a narrative that change the future and the past I said to everyone all the time the game is always too hard and sometimes these rules will change project to project for a few different reasons for example on the church and the darkness began I'm working on now a lot of the rules stayed the same but obviously not every game has horrific creatures in it so we took that out I mean some of the rules change because I realized the old version wasn't wrong it wasn't your game is too hard at your game should be hard enough and sometimes new rules come up so these can shift project a project studio to studio so bear that in mind you know in the throes of development nothing is absolute it's an act of constant compromise with the team and the schedule and the budget and the technology and so many factors but I still find it useful that know when you're floating out to sea wondering what the heck's going on in your project you can look to some of those signpost rules to help pull you back to calm waters so today we're going to have a series of speakers get up here a little later on Emily short is going to tell us how she test her game before it's maybe even ready for testing George Phan is going to tell us how your enemies are not as different as you think they are with England is going to tell us who you should make your game design documents for and Michael the platter is going to tell us how systems can bring about some human stories but up first we have Lee Perry he is an experienced game designer having worked on everything from the Gears of War franchise to the mobile title Lily to now of course working on VR title moon strike like so many are working on VR titles and he's going to tell us how everything you know is wrong when it comes to when to add pizzazz to your game Yuli Perry thank you hey everybody so this is my talk call it pizzazz first polish later so when I first started making game like a lot of people used to think that games were about these high concepts and big ideas about the settings and character bios and all the kind of classic things that get people into games early on but as you start getting more experience you start to realize that so many games have like something kind of special about them and make them kind of endearing beyond just their concepts and it kind of becomes less about this and more about what this means and this means and how just interacting with the controller and having you know things coming at you that you're instigating and getting this really good feedback is super rewarding and it's a huge part of your game in addition to the concepts so it didn't really want to talk about feedback most of us know what we're talking about but for the most part I'm talking about things like how satisfying it is and in a Mario game where you jump and there's a little screen shake and he's little particle cloud on his feet or how like the guys who make peggle kind of blazed the trail on neat little sounds escalating as things happen do-do-do-do-do-do or exploding particles everywhere or slow motion and you know they're kind of the godfathers of really good player feedback then if you want more specific details on that there's a couple of great talks online the great folks guys had called jinx it or lose it there's really good Vlambeer talk called the arts of screen shake really good feedback technique so it's very easy and for a long time i kind of associated these feedback techniques with kind of polish on a game and part of the problem is that you save a lot of Polish until the end of your game which as we all know from kind of practically speaking it's really easy to cut a lot of things at the end of the game when time starts getting squished in there sometimes you might have a game where you've got a big deadline in the middle of it like as a big pressed show or you know demo with some said run so you have this kind of spike and the amount of polish that you have earlier in the game and when we were working on Gears of War we ended up with this kind of level of polish it kind of looked like this through production and it was because we would have these debates about all these features like early on we could talk about things like a cover system but people weren't really sold on it until somebody would go in and add a bunch of feedback to it like little particles and screen shakes and markets going and all kinds of crazy stuff and so then people would be like oh yeah this is a cool feature and I get it and so the feedback became an instrumental tool and selling features to the team and so consequently we constantly had this like retching up version of feedback and polish in the game and so that was pretty cool it turned out that the feedback wasn't just a tool for the players it was a tool for the developers as well for kind of internal salesmanship that was pretty cool so a couple years ago I started doing kind of solo games and kind of this quest for self-sufficiency and being kind of a strong advocate of this I didn't really know what that meant for me is a single person for adding feedback in my game and so I started working with us and realizing that adding feedback in your game even if it's just for you is another great tool it's not just for them for the players it's not just for a team but it's also for you because as many of you may know if you're working a small game it's easy to be plagued by just like crippling self-doubt about what you're working on at every turn so adding feedback early on is a way to give yourself kind of an additional kind of clarity about what you're working on so in like some crazy ideal world it would be awesome if we could all take our games and just drive the Polish through the roof early on but obviously that's freaking insane you can't just take the first things you start adding in your game and polishing them I think they would call that polishing a turd perhaps but what we have to do is kind of detach the concept of good player feedback from the entire concept of Polish so it's not feedback is not polished it it's a dad's what I call it any concerns you have hands and you say that's somebody and what I'm talking about pizzazz I'm talking about things that are really help how visceral your game is but it's not necessarily like this is the final particle effect we're going to use or whatever what matters is that it's really super catchy and it makes your game just feel better but it's stuff you can totally throw away at some point but what matters is you put something in and when you're doing these kind of core loop elements of your game early on so it's really critical as early as possible on your game to get this feeling like you're the kid going wow or taking cars and smashing them together and whatever anything that gives you this kind of joy when you're playing your game so it's not enough to have these elements there's benefits from when you do this I don't know if leather you work with concept artists but keep finding good concept artists often make stupid noises on the drawing laughs that's awesome anyway so there's a lot of easy things you can do for this and they don't have to be final elements you can have particle libraries from you know God knows where super punchy over-the-top sound screen shakes all these things good placeholder music post-processing you know elements of you know good feedback but again these don't have to be final things just put them in early and they will help the project as you go because that timing is going to allow you to develop your core loop better I'm going to like figure out what the soul of your game is and you're going to find all these kind of emergent like things like oh man I didn't realize this was going to be so fun but it is we need to expand on that it also encourages you to show your game which is a critical critical thing when you're working on your game not just depressed but it's also about your internal confidence of what you're working on which helps team morale it said when people feel good about your game at huge obvious now we're working with a lot of VR stuff and there's a couple of things with that like VR is all about being intuitive and what can you generally teach the player without needing a tutorial and good player feedback early on is critical for making that happen and developing your game and all of these like known techniques like flashy stuff and particles and sounds and so all work in VR for the most part stay away from screen shakes nothing yeah but um also you know early on in this VR thing as you can tell from the show around us like there's a ton of elevator pitches and concepts going around but it's really easy to elevate your pitch and elevate your game right now by having some of these elements because not only people are going that extra mile my current game moon strike prepare yourself for virtual virtual reality mmm so this is going example like early on I kind of had these like really basic selection tools in my game where I'd kind of paint these selections and it kind of worked and saw on these little fleets and kind of gal calm like but it was cool it was it was really simple wasn't super compelling and so I go in and make kind of a little model like little selection dotted lines and you know just kind of placeholder assets to make this kind of sequence feel a lot better then I'd add sound all a Peggle but you can never have enough of and again it started to escalate how fun it was just to do this basic thing then I added support for both controllers even though it's totally redundant because it's just freakin fun like a kid when you're sitting there waving your hands around and I'm going to select this thing and I'm going to select this kind of thing and just adding these kind of basic elements to it drove the project really far early on I got a lot of really good early results for it in addition to all the normal kind of confidence issues with it I got support from valve and super early hardware because they were like oh man this could be a thing that's cool I became an official oculus partner one of the launch games for the touch controllers and crazy limited hardware I was awesome attracted a really great development partner Tiffany Smith who's helping me on the program because she saw what I was doing and some really great articles but like none of this would have happened if I would still stuck with cubes and Spears and stuff so my point you're going to add feedback to your game anyway right because you should so just front-load some even if you're going to throw it away don't wait till the end it's not polished it doesn't have to be perfect you can totally throw away but it's going to help you while you work on your game so it's not polished it's pizzazz and juice of jazz has when you show to people yeah Thank You Leigh I think he's just reminded us you know when talking about working with big teams just how political the act of game design can sometimes be when you're not only convincing the publishers but also the team itself so next up we have Emily short she is a veteran of the world of interactive fiction and of course on everything from a classic Galatea to doing some writing and sunless tea to working on the innovative interactive fiction system versu she's going to tell us how she tests her game before she even has testers Emily short [Applause] hello I'm Emily short and that was a really good point to segue from into my talk because I'm going to tell you something else that you should be doing right at the beginning of your project I'm assuming that a freelance consultant and interactive narrative I spend a lot of time with different tool sets for writing and for managing content and dialogues sometimes I'm building my own tools sometimes I'm working with other people's freeware tools and sometimes I'm working with proprietary tools that my client has come up with and I'm here to argue for a pretty simple principle visualize early so when you're designing a new system you need to think about how you're going to visualize its behavior if you're working on something with dialogue or narrative structure that might mean visualizing how pieces of the story or the conversation are going to feed into one another if you're working on a dynamic system that might mean heat maps it might mean taking traces of many consecutive runs through the system and laying them on top of each other it might mean a dynamic visualization tool that projects movement in response to variables that you're changing if you're building a procedural narrative system that uses a lot of content data or press not narrative system a procedural system that uses a lot of other kinds of content data that might mean coming up with ways to picture how much data you have what categories it breaks into and how you will know when you have enough and this is not a game example but it's a piece of really beautiful visualization that shows an analysis of the words in English translations of major religious texts and how often those particular terms appear that allows you to really quickly kind of grasp where those texts are showing up and what the relative significance of them can be so that kind of thinking about your procedural data can be very useful in sort of refining your system so I'd like to take us through how I've used early visualization in several of my own projects and then expand a little bit to talk about how that same approach might apply to other kinds of work besides narrative focus projects so here's an in-progress visualization of a chapter in platinum package which is a story I'm writing for choice of games line of branching novels and it might look like a design document of some kind but this is actually the result of running a Python script that I wrote against the code for this story and automatically generating a dot format file that can be read into graph is the visualization shows us the structure is a little bit simplified for this talk for the structure of one chapter and in that picture I don't just have sort of here are the nodes and where they're going but also the distinction between which of these pieces are player choices which are represented by solid lines and which are automatic transitions which are represented by the dotted lines I can immediately see by looking at my chart that I have a mix of player choice and consequence and the consequences are clustered towards the end of the chapter which is what I want meanwhile the colors of the lines are showing me what kinds of stat changes are happening when the player makes those decisions each color corresponds to a different stat that could be going up and down the transitions that are in red are ones that have noticed that effects and that's important to call out because part of the respect the brand commissioned for this game is that there have to be status for every single choice the player is making so I need to be able to instantly see that that is the case that I've left something out that I need to correct so the chart keeps up with the changes that I've made in the story so unlike a hand generated design document not going out of date that's important because I'm responding to feedback from my editor as the story progresses and over those iterations the game is diverging from the original document so I could do meticulous upkeep on a design document or I could just have a way of seeing directly into the code and that's much better now here's the case where the visualization I'm doing is farther from being a SPECT document and closer to being a play test report versus the project that I worked on for several years that involved characters with an AI driven approach to social interaction and that meant that at the high level there was an authored structure of a number of different scenes but within each scene what happened was very very dynamic depending on the moods and relationships of the characters and what dialogue the player chose to drill into and what they ignored from a QA perspective that meant we needed to go far beyond just having playtesters play the number of times in order to verify the quality of what we were building we needed to run through thousands of trial playthroughs with an additional AI agent making the players choices randomly and we needed not just to have that information but be able to look at that information and instantly see what was broken or what was working so this chart shows the way that we visualize the resulting information and this is just the beginning of the story it actually continues for many many more scenes with much broader branching but even if it's tough to read on that this slide so let's zoom in here so here we're seeing just the first few scenes of the game the first thing can end one of a couple of ways the percentages on this diagram indicate how many times the randomize player has reached each of these optimal optional scenes scenes that the AI reaches frequently our light gray seems that they are reaching more seldom our dark gray if there are any scenes and there are no examples of this on this slide but if there are any scenes that the AI never reaches that's almost certainly a bad sign a sign of some sort of implementation problem so those would be called out by again by coloring them in red and in fact in this case I had some help from the tool designer so we were able to build a visualization tool that was itself dynamic so if I looked in at one of these story nodes and wanted more information about what was happening how does the player reach this point how are the the randomised traces leaving this point I could click through and open it up and get a description of here are all the different routes into this here are the routes out and I can quickly see like if something is getting 0% that means that route through the story isn't being used even if the node is being hit there's something probably wrong with the logic that I've set up for this and so I can see all the possible transition states and finally I think it's important to make the point that your visualization does not have to be even a little bit attractive so I started this slideshow with a bunch of pictures from processing org by people who are very skilled and artistic and much better at visualization than I am but it doesn't have to be like that to be functional and if this picture is unsexy that's actually part of my point and this is a simplified version of how I looked into an experimental procedural narrative system that used a lot of event fate so we had written a number of events that could be selected to occur next depending on whether the protagonist had certain status features and of course the event could also change the protagonist status so running a simple script to count checking and setting of these statuses for each quality and then charting the result in excel helps us get a visual sense of what was happening so for instance in this representation the wealth equals rich attribute is being checked very frequently but set very infrequently which is a warning that the system contains a lot of data that might rarely have a chance to fire and I have been in many many situations working on procedural systems where we spend a lot of time trying to figure out what was wrong with the code when the problem was really that we had the wrong distribution of data so being able to see that quickly is very very important even conditional Delta formatted counts okay another question I had about this data set was how specialized the events were so an event might be checking multiple prerequisite qualities at a time and in order to get a sense of whether I was getting good coverage for all values of different qualities I just threw some count data into a conditionally formatted excel sheet and that didn't look particularly good but I could instantly see where the dead zones were there are zero this there about there colored red I know I need to build more of that kind of thing so it might seem like this is a really really open-ended piece of advice it might work out wildly differently for different kinds of projects and it might also seem to people who are mostly designers that I'm asking you to gain new expertise that isn't necessarily in your wheelhouse but personally I find that even asking myself the question what would a picture of this system look like gives me a really useful new angle on thinking about the quality of the design because a visualization puts its emphasis like color size priority on the page all of those kinds of things it puts its emphasis on what's wrong or what's important about your design so asking those questions about whatever system you're building what it here is important and what can go wrong is really useful if you have a system with a large amount of data thinking about visualizing that data means that you're going to have to think about things like data types what might characterize good or bad data how much data you're going to need and whether you have adequate coverage for different aspects of your game world and if you're not a programmer but you have one handy you might want to talk to them at this stage about how they would approach this seconds the sooner you have these ideas the sooner you can build them into your tools or specify them so that your tool programmer can start building them in for you so it is very very much harder and again this gets back into Team Dynamics if you're at the point where you're sort of working 80-hour weeks to get enough content into your system it's way harder at that point to say it would really help me if I had an extra tool to see what's going on here even if that would actually speed up your experience convincing anybody on your team to actually take a break and do that for you is nearly impossible so you're not going to necessarily anticipate everything that could possibly happen as the system evolves but one of the useful things about a visualization is that it helps you to instantly recognize issues and whatever it is that you've just built so anything you can do that highlights content problems while they're being generated will save you huge amounts of time later catching and debugging them and conversely anything that makes content creators feel confident about what they've built while they're building it leads to faster and better content so this is how to make future you really really hate current you will just rely on the content creators to make sure this data is formatted correctly your content team may be geniuses but they will make mistakes and you want as many ways as you can to find their mistakes anyway we all know why spell checkers are useful putting in more visualization options gives you more corrective tools so I'm not by any means the first person to stand out the GC and talk about how to visualize particular aspects of what you might be building as a designer so here's Noah falstein talking at a narrative summit a couple of years ago about puzzle dependency graphs this is a great talk from Alex djembe and dart at the 2012 AI summit which includes some discussion at how to visualize behavior of squad AI and there's a whole panel from the AI summit in 2011 ai tends to do a lot of this res Graham Michael DAW and Brian schwa talking about visualizing expected AI behave you're and how to see when something is going wrong so if you want sort of more deep dives in how people do this these are great places to look and then outside the world of GDC talks you might also get some visualization ideas from Edward Tufte books or for Brett Victor's websites but whatever you're trying to do thinking about the visualization from the beginning does some really useful things for your design process visualization forces you to think about categories what are the components of your system and how do they relate it forces you to consider what the failure conditions are so that you can draw the attention to them and forces you to think about what success would look like what is the finished system how do you know when you've got enough content and in the right places and if you visualize early you can either build or better yet make someone else build a better tool that will help you find your bugs faster and streamline your workflow Thank You Emily I think all of us as designers are have been known to say but it's not ready yet for testing and I think emily has provided us one more thing we should be doing that maybe we aren't so next up we have George fan who's been developing games for many years he actually started with one of his earlier games with the Sant aquarium which is a winner in the early days of the IGF but you probably know him for a little game he made called plants vs. zombies George will be telling us how your enemies aren't as different as you think if you think they are and a fun fact about George when you want to find a picture of him on the Internet because you haven't met him before you're very likely to come up with a bunch of pictures like this and I just want him to know that George you're the only George that I'm a fan of so George van [Applause] all right time to talk about my rule which is make your enemies actually different first let's zoom into this word actually what do I mean by that in this case I mean making it so each new enemy has tackled in a different way think of some of the games you played when where the enemy design was exceptional I bet in each case there was a high density of enemies that you had to use different methods to defeat the reason I have Super Mario in this slide here is because it does such a great job of meeting this criteria take note of the feeling you have right now when looking at this set of bad guys remembering all the different ways you use to defeat them if you're ever unsure about anything the design I recommend analyzing the first Super Mario and see how it did things is a clean example of enemy design done right sometimes we set out to make a game with a lot of enemy variety on the surface they look different enough and they seem to do different things but to the player fighting enemies becomes monotonous and each new encounter doesn't bring enough uniqueness to the table and we're left with a game that feels like you just bought a bunch of the same thing today I want to teach you how to avoid that to help us along I'm going to introduce a tool called player brain no vision it's a way for us to remember remember to get into the players brain as this is the most important perspective so let's meet our player naturally our player has a brain let's try using player brain Oh vision and imagine what this guy's thinking let's let's try to see what his brain sees based on this guy's expression I'm going to say he's playing Bill & Ted's Excellent video game to venture alright so let's get into this I'm going to start with some some don't do here are things you don't want to do when your goal is to make enemies actually different first pitfall happens when we have two enemies that are identical and think oh we'll just change the look of one of them that'll be enough and do this over and over again and you'll have the most boring game of all time the problem here is that the two enemies are doing the same thing the player doesn't handle the Ellison any differently than the mummy so they'll store both of these in their brain occupying the same space and our brains tend to clump things together in order to keep up with all the information you need to process now the players goal is to beat the game to that extent the player doesn't care that the mummy looks different from the skeleton in its efficiency the brain will squeeze these two together into just one enemy and that's what we want to avoid as we're not any we're not adding any true enemy to variety here even lazier than changing just the look is changing one color to another I mean I certainly didn't think of this brave fish from Super Mario as a brand new enemy type but I'll cut them I'll cut him some slack because they were up against some extreme memory limitations that's at the time but nowadays color shifts they just don't pass for brand new enemies anymore and abundance of them can often make your game feel cheap and most of the time you're better off with just one solid enemy instead of two palette swap enemies one more thing is to not think of small changes in HP damage and speed as brand new enemies a little bit a little bit is okay but if every bad guy in your game can be defined as just some degree of these three variables you're doing something wrong the difference between 500 and 510 is small enough that once again the player's brain will meld these two together into just one bad guy with about 500 HP alright now that we've covered some don't do's it's time to take a look at some doodoos I've got a big doodoo for you to take a look at and I'm going to call it attributes of differentiation basically these are qualities enemies might have that would make them play differently from one another you might think of them as sort of avenues to explore while you're trying to make your enemies actually different in this section of the talk I'll provide you with some examples of attributes I find myself using again and again the first one of these is movement we can often make the player handle the enemy differently by simply introducing new movement patterns in Super Mario these enemies all have distinct styles of movement and the player needs to account for each one differently but be careful you don't spend time making things have special movement when in the end it gets handled by the player just the same with something else in this hypothetical game we've designed two enemies a bird that moves in a zigzag and a bat that means in a sine wave there might be cases where this difference is significant but for the most part I see players handling these two movement patterns in the exact same way again not good if our goal is to make enemies actually different stuff like this can be found out through play testing but using player brain division we can often catch it earlier another attribute I like to consider is priority meaning when seeing lots of enemies on screen which order to defeat them in how urgently do I need to defeat this enemy relative to others an example of a high priority enemy is a generator from gauntlet it doesn't matter how many goes to kill if you don't kill the bone piles first they'll keep spawning more ghosts the US Open Space Invaders and it is an interesting case you prioritize it not because it's threatening but because it's worth a bunch of points and only on screen for a limited time let's think about priority some more suppose we have a group of basic grunts now let's add a healer to the group if we try killing the grunts first it'll take a long time because a healer will keep them keeled so the correct play is to focus on killing the healer first then take care of the grunts after the healers been dealt with but what about this let's instead add a high damage dealing Archer to the group in this case the Archer becomes our number-one priority because the more threatening unit again it makes sense to prioritize killing the archer over the grunts now as long as in this weird hypothetical game we're only presented with units and these two formations of healers and grunts and archers and grunts the healer in the Archer was seen as seen as the exact same unit in terms of priority even though they performed vastly different roles just something to keep in mind fact is a lot of enemies we design tend to fall into this high priority deal with me first category that's why it's good to explore the other end of the spectrum and design enemies that are best dealt with last both these guys get mad and become more deadly after you damage them so it's best to ignore them as long as you have other enemies to deal with enemies that have lots of HP and do the amounts of damage also fit into the deal with me last category alright another attribute we can consider is timing it often involves having an enemy that's more dangerous during certain times or likewise more vulnerable during certain times a prime example of this is the Piranha plant from Super Mario it's safe to pass law it's retracted into the pipe but dangerous otherwise the lava bubble is another bad guy from Super Mario that hops in and out of the lava and requires timing to avoid if we're observant and we use player brain no vision we might discover some similarities between these two units I initially didn't think of these as being very similar but in researching this talk I realized they're both timing based enemies with up and down movement the only differences are the lava bubbles immune to Mario's fireball and only found in lava now this is our own game we would then be up to us to decide if these small differences were enough on to the next attribute when most games in your game do close-range attempt when most of the enemies in your game do close written attacks you should shake things up by offering some enemies that are long ranged the catapult zombie and hammer brothers are examples of long ranged enemies and games where most enemies are close ranged likewise if most of the enemies in your game are long range consider throwing in a close ranged enemy to liven things up a lot of these attributes come down to being observant of what happens often in your game and designing things that disrupt that which brings us to our next attribute a good way of coming up with new enemies is to think about what actions the player does most often in your game then come up with an enemy that counters that action to shake things up and Super Mario the most common action to defeat enemies is to stomp on them so halfway through the game the spiny enemy is introduced which you obviously can't stomp on along the same lines buzzy beetle is immune to fireballs another common action of Mario's both enemies do their job of keeping Mario on his toes and not letting him perform the same actions over and over in plants vs. zombies I had the early issue of walnuts being really good and noticed players falling into a rut of using walnuts to solve everything so I designed these pole-vaulting zombies that would leap over the first plant they ran into thus making one that's a little less universally good and mixing things up for the player a good exercise is to think about what your players do often then come up with ways for your enemies to disrupt that for example if you notice in your game your players are just constantly spamming AoE you could design a unit that countered AoE these eggs when damaged release extremely powerful demons punishing the player who just goes around AoE attacking everything willy-nilly unleashing all the demons at once is a bad move and the demons become too overwhelming for the player to deal with instead the correct play is to break the eggs one at a time dealing with each demon individually before breaking the next egg with this one enemy type we've added a nice beat to our game where players play carefully for a bit and then they go back to constantly spamming AoE in pdz I new players have gotten used to zombies coming in from the right side of the screen so I threw them a curve ball and introduced the digger zombie which surprise attacks your plant from the left on the flip side we can design enemies by giving them a weakness offering the power to the player that exploits that weakness it often feels satisfying to face down an enemy that's tough to deal with initially but then you're given the power that helps you defeat it with ease finally we have the attribute of player attention which mostly comes in the form of telegraphed attacks this involves designing enemies to attack the electron of damage it's not avoided but give you ample warning so you have the opportunity to avoid them they function in the function how they function groups of enemies is to demand your attention for some amount of time an example of this is from Super Mario 3 where this sludge brother will jump up into the air forecasting a ground slam if you're still on the ground when they slam into it you'll get stunned for some time this forces you to pay attention and react by jumping alright to sum things up here's an effective way to make your enemies actually different first try to design each new enemy with an attribute of differentiation in mind I've given you some examples of attributes you can explore once you've done that pass the enemy through player brain no vision to see if it actually makes the player do something different do this and your enemies will be awesome I'm looking forward to playing your upcoming games with truly diverse sets of enemies if you want to talk more about this my uncle's right here I'll be coming out with a game later this year that has its own share of enemies are actually different so follow me on Twitter for updates on that all right thanks [Applause] Thank You George and I feel right now everyone in the room has opened their laptop and dripping out their palates waffle code I hope you are anyway so next up we have Liz England she's a game design veteran having worked on everything from Scribblenauts resistant to sunset overdrive a game we both worked on but due to the modern nature of large game development we didn't meet until this week now for another modern reality if you've been doing game design for a while you may know that no one is reading your precious game design documents and well good news liz has a solution for that with England [Applause] [Music] thank you everyone hear me yes excellent yes so I am talking about Polly the most riveting topic that you could possibly discuss in game design which is about documentation now this talk is a little bit advanced maybe sort of and it kind of assumes you already know a lot of trials and tribulations of dealing with game design documentation especially on a big team there's several talks prior to this that I recommend on that you can fly on the Ducey vault or you can planning YouTube because I'm going to spend my 10 minutes talking about a very specific kind of subtopic and my personal take on this which is my thesis which is make actionable documentation actionable here is a very specific term and I'm going to break it down for you which is to make documentation for people that people can act on and and for me that's what actionable means it means people can act on it and I'm going to separate this down and we're going to talk about people first so why do we care about people so well yes I saw I heard a lot of times when we make documentation we make this to be comprehensive and exhaustive about a game we're documenting a game and we're trying to plan out all the details and then you look at the documentation and it was never meant for a human to read it so my first step is to say when you make documentation you don't document a feature you don't document a game because the game is not reading your documentation it doesn't care if you document it it's a people that care if you document it and when I talked about people let me with live them so instead of asking what feature are you documenting asked who is this document for and then try to answer that to question right and when I talk about people I'm obviously talking about you know the members of your team and sometimes that means your whole team a lot of documents are written for the whole team a lot of times you write a document for one department or multiple departments but I would say get a lot more specific than that because when you write for an entire department for example you end up having a lot of extra information that's not very relevant and nobody wants to go through a document that's 90% irrelevant just to find the 10% they care about they're just going to bother you at your desk instead and maybe you prefer that so instead I would say you know instead of just writing for the team or maybe the department maybe you go to the one person who's going to do something with this document you say hey Adam that guy in AI you know what does he need in order to you know read this document so you sit down with him and you get his by in the first place I like to think of the document as this like special handcrafted bespoke artisanal gift that I'm giving to another developer and it's like made perfectly for them and maybe in this case Adam Wright likes use cases so yeah he loves use cases in these a ton of use cases and somebody else would prefer you know just a one-page high-level document and go over the details in person and when you when you to write documents this way you're getting a lot of buy-in from other people on your team and you're making sure that the information that they're getting is actually relevant to them instead of handing them a document that they've never seen before and then they're just their eyes glaze over which many of us would be familiar with so the next question is you know what do I want them to do with it well what do you do with design documents right what do you want people to do you want them to read them right wrong wrong that makes me so mad so it's like giving someone a game and saying well what do I do with this well you play it well what am I doing with the game you know am i how am i interacting with it so when I say Act I'm saying reading is a very passive way of dealing with documentation you don't write documentation for the purpose to be read documentation doesn't exist for the purpose to exist right it should have an explicit purpose right if I write a documentation for someone dot for someone you want them to do something with it and that's where I get a little bit of game design we all should be familiar with use our verbs right like run jump suit we should use those kinds of verbs with our documentation as well so read is a bad verb you don't use that verb but use verbs like maybe you need to inform the team right on a very basic level maybe you need to write a document that needs to get approved by the leads right and that's going to have a very different format than a doc that you write for QA so that they can debug your feature or for a programmer in order to implement it and so on and so forth the important lesson here is that your documents are going to have a very different form depending on what the purpose of that document is and also depending on who you're writing it for is there's a lot of different variables that go into your document there's no one set kind of perfect design document to follow so that's sort of like my summary of make actionable documentation and again actionable here is the important word it means people can act on it so let me go over a bunch of practical considerations and there's a lot of them right because when you actually try to put this into into action there's there's pros and there's cons right so the first one is different styles for different needs you know some people work best with visual documentation some people work best with like flowcharts or just a word document and as designers we should be familiar with being able to make all different kinds of these documents for them also this means you know you have smaller documents more concise documents because you stripped out all this extra information that you don't need to give somebody but that doesn't mean you have one feature but you might have to make several documentation several docs for that feature so I'll give you a couple little examples so this is a mat from most of my examples are from sunset overdrive this is a mat from sunset overdrive and it was great because it might make 0 or almost zero sense to you guys but it was built with the people who needed to use it together in the same room and this was basically the leads from all the department got together and we built this map and so it worked great for the team to track it maybe not so much like QA couldn't use this map to do anything and like if you were new to the team maybe you can't use this map but it was updated and it was used a lot because it was created with a bunch of people invested in the first place and I'm going to compare that to a different map this is a map that was sitting on my desk for about a year and it just has a bunch of post-it notes and this was our way of organizing side content in the game because instead of trying to deal with an unwieldy you know Photoshop map and we're just a bunch of designers we work really well with paper so we use post-it notes and we move the information around and so quest designers could use this to help plan out all that side content in the game but I couldn't have this to QA and be like yeah do something with this right so I had to make another document right and that was just a flow chart now keep in mind so this flow chart worked really well for various people on the team especially for QA so they could debug when the side content rollout but when you look at it you realize none of the location information is here there's no map right so we've stripped out the information that we didn't need because it would just essentially clutter clutter the rest of the clutter clutter the document for other people on other teams and then I'm going to go real quick because I'm taking too much time so this is another documentary wrote it's a big flow chart lots of detail it worked extremely well for programmers in order to implement stuff off of this this is our mission flow what happens when you fail mission what happens when you abandon a mission but I handed this with designers and their eyes just glaze over and they just looked at me with what was going on and so I basically reskin dit took away a lot of quantitative information I replaced it with some qualitative information you know what the context that designers understood which was I understand what a mission is so how does it fit into these different slots and that that ended up working well for them so I could not find a single document that was once it's one size fits all I had to make several that were that suited each person's needs so some other practical considerations it's okay not to update Docs if they've served their purpose go ahead and retire them you know I no one likes updating documents that have been old from 6 months old just just make a new one sometimes the game is its own best documentation so here's a good example of that and sunset overdrive we made a bunch of changes to our traversal system and then we know how to communicate that to the whole team's we've got this awesome visual design documents and everyone trying to understood oh so this is the direction traversal is going and that was great so they started implementing it and then you know a few months later it's like okay so what's going on with traversal well go you know sorry go play the game right because at that point the game was the best documentation you could have for the system and when it changed there's no reason to change documentation and inform the whole team you just go when you play the game some other considerations to deal with right docks when needed dot before don't write for an audience that doesn't exist yet so some people might not like this one what it means is let's say you're designing a boss and you have you know your high-level approval well you can go in and you can write all the details for it but it might not get implemented for six months and everyone knows that in those six months a ton of things are going to change so I would argue that you wait until the last possible practical minute before you write that documentation so you know who's actually implementing it so you can write for that person the obviously the flip side of this is that suddenly you get documentation and that means you have to have a really fast turnaround and be able to do documentation and be really flexible with it so that's one of the downsides and this also runs counter to a planet out first mentality or appears to on the surface at least because there's the idea that we want to plan everything and then part of that plan out was first as much as possible before you start investing the mind implement it but I would argue that you are your own reader so you should be able to and you can write documentation as yourself as the reader and the purpose is to plan right so it doesn't it doesn't entirely strip out the idea plan it out first some more some more practical considerations so it's not excuse to avoid documentation even if you're waiting up to the last practical minute you're still writing more documents not fewer it doesn't replace every document that you make they're still going to be times where you need to make that you know 20 page documents that some people may or may not read and it's sad when they don't read it but I would argue that we should try and make it as actionable as possible so this is an example of a document for Scribblenauts that I made and I had to be 25 pages so I just said okay every page needs to have sort of an actionable thing that you can do with it and split it up and then just to wrap up I just want to acknowledge that this talk may not work so well if you're in India or you work alone because you are making all the documentation for yourself and not a big team and then the last thing is that sometimes it's difficult on board new people if you don't have any documentation for features that exist but we already have the problem where our documentation that exists is either out-of-date or it doesn't exist so it's sort of like which is your least worst case scenario so that's it that was that's my argument for make actual documentation thank you it's all good so thank you Liz we are running a little low on time so I'm going to move right along here to our final speaker is Michael de platter talking about a subject dear to my heart off and we think about game systems as intuitive or sticky or challenging or good for flow but what if they are good for producing humanity Michael has been working in games for some time with everything from sports games to Total War franchise to 2014's game of the year shadow of Mordor Michael de platter please they're coming through yeah it's love GDC so much all these talks is so inspiring and I guess really that's probably the number one takeaway from this talk is how much other games and multiple genres can inform every game you're working on so this is really as Richard was saying before a personal story in the sense of a specific case study of hadded sports games and war games and real world references inform the Nemesis system and it's sort of a two-way street so the Nemesis system was something where we wanted players sorry I should just explain it was the key feature of shadow mode or the open world action-adventure game we did last year where players have their own unique and personal enemies we wanted to make it a villain simulator and we wanted to make these really diverse and meaningful enemies and what we wanted to do was to make them operate according to the most real-world intuitive rule set that we could so to find out about how do these kind of stories get created in the real world and how could we actually apply that to the creation of our game and as we're looking at that that really went back and looked not just at action-adventure games that just two games within our genres but also sports games war games all sorts of different things and in particular what we sort of looked at was the way that sports is a real-world system that is actively designed you know game designers work in in sports you know they design seasons they design formats they design rules and the things that those seasons and rules do is they generate stories and the ways in which they generate stories are through a lot of the same mechanics that we see in books and movies in other media so they create and set up conflicts one of the things that was very important for us is you don't have safe game mechanics in sports the failure and the way in which time moves forward is actually a key component of creating the drama and creating the story so for example if you lose the third match of the season you don't roll it back and play it again you have to overcome that loss and those sort of real-world passage of time is great for drama it creates rivalries it creates comebacks it creates underdogs it creates all of these personal dramas for players to overcome and that was something that we focused on a lot with our system as well and finding ways to make that treatment of time tie together with our fiction which in this case was Lord of the Rings and a system of death and resurrection so time would move forward and we will be creating these personal stories with enemies and another thing excuse me sorry end of the week getting finally hitting puberty and another thing that's very common and we can see in sports but also very much in drama whether it's Jane Austen or whether it's Patton or you know whether it's Star Wars is social structures and so two hierarchies underlie a lot of the most emotionally affecting stories people that start on top and they have a fall and move down in society people start at the bottom there's a poor innocent farm boy and make their way up and so that was again something that was really interesting for us to be able to simulate and by simulating these social structures time these relationships conflict to try and make something that's not a structured narrative but creates the same sort of emotion and the same connection and then as a specific example going back to sports sports seasons are basically a three-act narrative structure you have act 1 where you know we see who the various teams are who are the favorites what's going on and we have act 2 with this sort of constant buildup of the action the highs and lows and in act 3 they generally have a structure of the finals and the final climax in the grand final so even though the plot is basically the same every year the stories and the dramas of it are incredibly dynamic and that was a model which we wanted to take and apply into our genre which was action-adventure and the other one which was very important for us and often isn't the case in games in games there's the tendency when you fail to say okay go back and do that again we're going to wave our hands and say it didn't happen but the same sports whether it's an injury or a loss that that failure is actually embraced and used to create more drama and that was absolutely core to us we wanted when you died not to say okay that's a failure you should go back and do that again but you've actually created the seed of an exciting and personal story and this in debtor and his personal relationship against the guy that defeated you and of course the other place that that happens constantly and time moves forward we create these personal rivalries multiplayer games so you know Call of Duty and and so on which was another we were sort of trying to create the types of relatedness and grudges you get against other human beings onto our NPCs we wanted to make them as human as possible with the goal of maximizing players and Oshin and all of these sort of systems for creating stories in drama art within the framework of even nonlinear narratives or branching narratives or the sorts of things that we can see in RPGs is generally trying to actually make a system that generates drama and relationships and something else we looked at from sports and took is that there does it create stories at two scales you have this overarching narrative of the conflict between the teams who's going to win who's going to lose but then within that you also have the creation of very personal narratives so you have heroes and villains emerging you have revenge stories emerging you have underdogs that come up you have grudges but all of these individual personal stories are taking place within this framework of a larger conflict and again although we see it in in the real world in sports it's something that mapped very nicely the Mordor and orc society for us and then another thing that's really interesting is this whole sections of journalism basically that are dedicated to creating a narrative izing and weaving written stories out of what is basically statistical analysis people take stats of the results of different players different teams and they'll turn those into written narratives that people find really emotionally engaging and will follow so everything that we did even though the underlying complexity of the whole system and the Nemesis system under the hood is obviously enormous ly complex the way we always wanted to surface that to people is in a naturalistic story one of the ways we sort of test that ourselves is and we did this on Total War as well and you also see this on sports games is if people are writing stories about our game is the language they're using to express their story sound like they're really invested in that world and then of Crysta speed up a bit but war shares a lot of the same structures and again warlike sports not only creates these stories but is very often a reference point for entire genres of fiction so we have entire genres of movies around sports we obviously have a lot of genres and a lot of films around war because they share those dramatic traits of conflict of escalation towards a epic finale of personal story so no Band of Brothers platoon within the context of this larger epic conflict so games like civilization are obviously very good at simulating these large-scale conflicts that we wanted to see how could we put personal stories and nest them within that and an emphasis on human hierarchies and social structures whether that's generals and troops and the military hierarchies or sports teams and then just quickly a couple of specific examples of how we use real-world references to create stories even going back to total war which is where I was working before shadow of mordor people are also very very keen to project agency and project character onto onto NPC so by applying traits personality traits under our generals and our characters it just changed them from being collections of stats into being characters people could relate to and darkest dungeons obviously another game that does that extremely well and we try to do that with our orcs in particular their hates and fears which was simultaneously trying to make them do something that George spoke to before differentiating them as enemies by making them block your different abilities with our equivalent we had players spreading fires everywhere so we gave guys that hated fire so now they could block and come back at you as a result and punish you for doing that another example we had of using sort of a drama mechanic in the in concert with the balancing mechanics was in Rome very often the Roman Empire from the style of the game would cross the world start dominating the world and then you get to this point in the game we found where the final stages of a strategy game could be relatively boring mopping up so we injected this drama of the Civil War at that point Rome would turn on itself it would split you'd have all these family dramas rivalries because the big difference with shadow of mordor from big strategy games like Rome is that we wanted to make it personal and as I say we built it around those principles that we see in these real world story creating systems of sports and warfare which is basing it around conflict making the time always move forward so we can build these personal relationships embracing failure as a chance to create stories and also focusing on social structures and human hierarchies and again we can see that in Jane Austen we can see it in Mexican prisons we can see it in sports teams but then the other thing we have to do is is figure how do we surface that to the player how do we narrative pose that in a way that feels really powerfully like a story and that was where we put an enormous amount of emphasis in the in basically the clashes and the showdowns and having these guys actually remember you so players are always creating stories in their own heads and we just and are really willing to have you reinforce the meaning of those stories by speaking to them if you say you did this to me players are absolutely oh my god I did I am the center of the universe human beings are amazingly egocentric and it's great and so then this was just other examples you know we were obviously focused on a single player action-adventure game but there's so many other games now where you see this possibility of people creating narratives about what they've done within these worlds and what's exciting about something like TV is when people write their narratives of their game experience it reads exactly like a you know post-apocalyptic zombie horror so the same psychological forces the same stories are getting triggered by the same events and that takes the last slide which is a model it the way we work and our framework is very much represented you can in this book glue to games but there's a theory player engagement through need satisfaction which is a theory of player engagement based on the psychological self-determination theory and basically what it boils down to is that the things that motivate people to keep playing your game are the same things that motivate people to do things in the rest of their life which is autonomy people want their decisions to have the ability to make meaningful decisions confident they want to people want to learn and sometimes they want to feel like they're kicking us and relatedness people want to connect with other living things and that emotion actually doesn't really differentiate very much whether it's an NPC or a human you're actually feeling the same psychological needs so what we were really doing is looking at the real world to inform what we did in the game so strongly recommend glued to games and then see how you can use real world systems like that maybe inform getting players to get invested in the stories within your game thank you oh and we're hiring thank you all right all right so that's Michel de platter our final speaker thank you you know if you're thinking about your own deck of rules that you may be building it's kind of like building your own magic deck the card you choose will affect how you develop games and different decks will differently in different better or worse in different situations but more important is that the deck you have feels good as when you enjoy developing with so these have been our sessions there were a lot of references in this talk if you want to download the slides they're up at that URL right now so you can go grab them or go grab them later if you go to the writing section on my website you can download these got all those cool references to go do some more research we're not going to do Q&A but we'll be around for a bit either here outside in the hallway probably because we're a little over time if you want to come talk to one of us we would love that that'd be fantastic Andres please remember to fill out your surveys thank you for coming [Applause] you

Channel: GDC

Views: 123,498

Rating: 4.921361 out of 5

Keywords: gdc, talk, panel, game, games, gaming, development, hd, design, game design

Id: d8QAVGeEj-U

Length: 65min 59sec (3959 seconds)

Published: Sun Jul 30 2017