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'm supposed to remind you to turn off your noise making devices before we go so where do you get your ideas isn't this the question that every writer dreads as if there's some magical place where these ideas come from anyone who's been working in a creative field for long enough knows that like writing or like games knows that ideas are a dime or a dozen but implementation is hard don't get me wrong good ideas do help but devils in the details of implementation writers get asked this so often that they come up with py answers like Haron Ellison would say connected there's a nice shop there where you can order ideas and they come in a tidy box and then you use them Neil Gaiman had a py idea a py answer to this 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 uh question how do you make your games fun um you know Pro tip for anyone who's just getting into game design professionally we don't like the word fun 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's good and that that players enjoy um 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 Sol they solve those big risky questions early before production starts how do you get your your systems to work so that people are hooked so that people keep playing so 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 uh uh my name's uh Richard Rouse I will be your host today I'm a director designer writer at paranoid Productions where we're 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 um with five other game designers um and this 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 uh and that session went pretty well and it was really interesting um 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 that means a lot of the rules you he today are things that these specific designers really enjoy using that help them make their games you know whatever genre whatever team situation

they be may be in just because you hear rule here today doesn't mean it's necessarily the final word on this 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 they 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 as like a deck of cards uh that we as game designers can choose to play and deploy when the time is right um I've been working as a game designer for a bit for for a while uh so naturally I have my own deck of these rules sometimes those rules are specific to a project so for example on the suffering game you know these might be some of the rules that I used you know I wanted a consistent rules-based world I wanted a narrative that changed the future and the past um I I said to everyone all the time the game's always too hard and sometimes these rules will change project to project for a few different reasons for example on the church in the darkness the game I'm working on now a lot of the rules stay the same but obviously not

every game has horrific creatures in it so we took that out um and some of the rules change because I realized the old version wasn't wrong it wasn't your game is too hard it's your game should be hard enough uh and sometimes new rules come up so these can shift project to project Studio to studio so bear that in mind you know in the throws 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 um but I still find it useful that you 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 tests her game before it's maybe even ready for testing George fan is going to tell us how your enemies are not as different as you think they are Liz England is going to tell us uh who you should uh make your game design documents for and Michael to platter is going to tell us how systems can bring about some human stories um but up first

we have Lee Perry uh 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 a VR title moonstrike 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 give you Lee Perry thank you hey everybody uh so this is my talk call it Poss as first polish later so when I first started making games uh like a lot of people I used to think that games were about uh these high Concepts and big ideas about the settings and character bios and all the kind of classic things that kind of get people into games early on but as you start getting uh more experienced you start to realize that so many games have like something kind of special about them that make them kind of endearing Beyond just their Concepts and it kind of becomes uh 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 this huge part of your game in addition to the concepts um so generally when I'm talking 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 in a Mario game where you jump and there's a little screen shake and his little particle Cloud on his feet or how like the uh guys who make pegle kind of um Blaze the trail on neat little sounds escalating as things happen or exploding particles everywhere or slow motion and you know they're kind of the the Godfathers of really good player feedback then if you want more specific details on that there's a couple of great talks online uh the greatr guys did called juice it or lose it uh there's a really good vam beer talk called The Art of screen Shake really good uh feedback techniques

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 a big press show or you know uh demos Etc and 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 that 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 uh feedback to it like little particles and screen shakes and Marcus 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 uh became an instrumental tool in selling features to the team and so consequently we constantly had this like ratchet up version of feedback and polish in the game and so that was pretty cool um 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 as a single person uh for adding feedback in my game and so I started working with this and realizing that uh adding feedback in your game even if it's just for you is another great tool it's not just for the for the players it's not just for a team but it's also for you because um as many of you may know if you're working on a small game it's easy to be plagued by this like crippling self-doubt about

what you're working on at every turn so adding feedback early on uh is a way to give yourself uh kind of an additional kind of clarity about what you're working on so in like some crazy idea 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 um but what we had to do is kind of detach uh the concept of good player feedback from the entire uh concept of Polish so it's not uh feedback is not polish it's it's Pizzazz is what I call it and you can throw jazz hands when you say that to somebody um when I'm talking about Pizzaz I'm talking about things that are um really help how visceral your game is but it's not necessarily like this is the final uh 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 and so it's really critical as early as possible in 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 a lot of you work with concept artists but I keep finding good concept artists often make stupid noises when they're drawing um and that's awesome anyway uh so there's a lot of easy things you can do for this since they don't have to be final elements uh you can have particle libraries from you know God knows where super Punchy over-the-top sound screen shakes all of these things uh good placeholder music post-processing these are all elements of uh 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

cuz that timing is going to allow you to develop your core Loop better and to kind of like figure out what the sole 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 uh not just to press but um it's also about your internal confidence of what you're working on which helps team morale Etc when people feel good about your game uh it's huge obviously 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 stuff all work in VR for the most part stay away from screen shakes yeah but um the 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 uh to elevate your pitch and Elevate the uh your game right now by having some of these elements cuz not a lot of people are going that extra mile uh my current game moonstrike prepare yourself for virtual virtual reality so this is one example like early on I kind of had the uh like really basic selection Tools in my game where I'd kind of paint these selections and it kind of worked and spawn these little fleets and it's kind of galcon like but it was cool it was it was really simple it wasn't super compelling and so I'd go in and make kind of little models like little selection dotted lines and you know just kind of placeholder assets to make this kind of uh sequence feel a lot better then I'd add sounds all a pegle which 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 freaking fun like a kid when you're sitting there waving your hands around and you're like yeah 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 um 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 got support from valve and super early Hardware because they were like oh man this could be a thing that's cool um I became an official uh Oculus partner one of the launch games for the touch controllers uh and crazy limited Hardware uh it was awesome I attracted a really great uh development partner tiany Smith who's helping me on the pro 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 spheres and stuff so my point you're going to add feedback to your game anyway right because you should um so just frontload

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 polish it's Pizzazz and do some jazz has when you show it to people yeah thanks thank you Lee I I think he's just reminded us you know when talking about working with big teams just how political the of game design can sometimes be when you're not only convincing the Publishers but also the team itself uh so next up we have Emily short she is a veteran of the world of interactive fiction having worked on everything from the classic galatea uh to doing some writing in sunless sea to working on the Innovative interactive fiction system versu and she's going to tell us how she tests her game before she even has testers Emily [Applause] short hello I'm Emily short um and that

was a really good uh point to segue from into my talk uh because I'm going to tell you something else that you should be doing right at the beginning of your project um I'm a since I'm a freelance consultant in interactive narrative I spend a lot of time with different tool sets for writing and for managing content and dialogue 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 um 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 Uh 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 uh 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 perhaps 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 um and this is not a game example but it's a piece of really beautiful visualization that shows um an analysis of the words in English transl ations of major religious texts and how often those particular terms appear that allows you to really quickly kind of grasp where those um 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 graphis the visualization shows us the structure and it's a little bit simplified for this talk but 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 a distinction between which of these pieces are player choices which are represented by solid lines um 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 uh the transitions that are in red are ones that have no stat effects and that's important to call out because part of the the spec the brand commission for this game is that there have to be stat changes 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 um so the chart keeps up with the changes that I've made in the story so unlike a hand gener a design document it's not going out of date uh 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 a case where the visualization I'm doing is farther from being a spec document and closer to being a play test report vers is a project that I worked on for several years that involved character 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 um from a QA perspective that meant we needed to go far beyond just having play testers play the game a 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 player 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 visualized the resulting information and this is just the beginning of the story um it actually continues for many many more scenes with much broader branching but even if uh it's tough to read on that this slide so let's zoom in here um so here we're seeing just the first few scenes of the game the first scene can

end one of a couple of ways the percentages on this diagram indicate how many times the randomized player has reached each of these optimal optional scenes um scenes that the AI reaches frequently are light gray scenes that they are reaching more uh seldom are 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 um a sign of some sort of implementation problem so those would be called out by again by coloring them in red um 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 has the player reached this point how are the uh the randomized traces leaving this point um I could click through and open it up and get a description of here are all the different Roots into this here are the roots out and I can quickly see like if something is getting 0% that means that route through the story isn't being used even even if the node is being hit there's something probably

wrong uh with the logic that I've set up for this um so I can see all the possible transition States um and finally I think it's important to make the point that your visualization does not have to be even a little bit attractive um so I started the 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 um 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 data so we had written a number of events that could be selected to occur next uh 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 um for each quality and then charting the result in Excel helped us get a visual sense of what was happening so for instance in this represent uh 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 spent 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 um even conditional sell per formatting counts okay um 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 the 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 of this zero of that they're 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 that 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 um 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 uh you might want to talk to them at this stage

about how they would approach this second 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 um 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 um 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 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 cont 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 U we'll just rely on the content creators to make sure this data is formatted correctly um your content team may be Geniuses but they will make mistakes um 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 more corrective tools so I'm not by any means the first person to stand up at GDC 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 shamard at the 2012 AI Summit which includes some discussion of 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 um res Graham Michael DAW and Brian Schwab talking about visualizing

expected AI behavior um and how to see when something is going wrong so if you want sort of more deep Dives in how people do this um these are great places to look and then outside the world of GDC talks you might also get some visualization ideas from Edward tuft's books uh or from 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 visual attention to them it forces you to think about what success would look like what is a 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 [Applause]

[Music] thank you Emily I think uh all of us as designers are are have been known to say but it's not ready yet for testing and I think Emily has just provided us one more thing we should be doing that maybe we aren't so uh next up we have George fan who's been uh developing games for many years he actually started with uh one of his earlier games was a San 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 versus zombies um George will be telling us how your enemies aren't as different as you think is as 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 uh and uh I just want him to know that George you're the only George that I'm a fan of so that George fan

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 um in this case I mean making it so each new enemy is tackled in a 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 cuz 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 used to defeat them if you're ever unsure about eny design I recommend analyzing the first Super Mario and see how it did things as 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 fought 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 o vision it's a way for us to reme remember to get into the player's 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 O 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 and Ted's Excellent video game Adventure All right so let's get into this I'm going to start with some some don't dos 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 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 skeleton any differently than the mummy so they'll store both of these in their brain occupying the same space um and our brains tend to Clump things together in order to keep up with all the information you need to process now the player's 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 variety here um even lazier than changing just the look is changing one color to another I mean I certainly didn't think of this gray fish from Super Mario as a brand new enemy type but I'll cut them I'll cut them some slack cuz they were up against some extreme memory limitations at at the time but nowadays color shifts they just

don't pass for brand new enemies anymore an 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 pallet swapped 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 is small enough that once again the player's brain will meld these two together into just one bad guy with about 500 HP all right now that we've covered some don't dos it's time to take a look at some do do I've got a big doooo 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 um 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 as something else in this hypothetical game we've designed two enemies a bird that moves in a zigzag and a and a bat that moves 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 O vision 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 the generator from Gauntlet it doesn't matter how many ghosts you kill if you don't kill the bone piles first they'll keep spawning more ghosts the UFO from space invader 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 the Healer will keep them healed so the correct play is to focus on killing the Healer first then take care of the grunts after the healer's 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 it's 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 in these two formations of healers and Grunts and archers in grunts the Healer and the Archer would seem as seem as the exact same unit in terms of priority even though they perform 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 low amounts of damage also fit into this deal with me last category all right 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 while 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 o 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 it would then be up to us to decide if these small differences were enough all right on to the next attribute uh when most games in your game do close range when most of the enemies in your game do close- range 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 in 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 to 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 in 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 the Buzzy beetle is immune to Fireballs another common action of Marios both enemies do their job keeping Mario on his toes and not letting him perform the same actions over and over in Plants versus Zombies I had the early issue of walnuts being really good and notice players falling into a rut of using walnuts to solve everything so I designed these pole vating zombies that would leap over the first plant they ran into thus making wets 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 counters 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 PvZ I knew players had gotten used to zombies coming in from the right side of the screen so I threw them a curveball and introduced the Digger zombie which surpris attacks your plants from the left on the flip side we can design enemies by giving them a weakness offering a 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 a power that helps you defeat it with ease and finally we have the attribute of player attention which mostly comes in the form of graphed attacks this involves designing enemies who attacks

deal a ton of damage it's not avoided but give you ample warning so you have the opportunity to avoid them they function in the function um how they function in groups of enemies is to demand your attention for some amount of time an example of this is from Super Mario 3 where this Sledge 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 all right to sum things up here 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 o 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 info is right here I'll be coming out with a game later this year that has its own share of enemies that are actually different so follow me on Twitter for

updates on that all right [Applause] thanks thank you George and I feel right now everyone in the room has opened their laptop and has ripping out their pallet Swap and code I hope you are anyway so next up we have Liz England she's a game design veteran having worked on everything from scribbl knots to resistance to Sunset Overdrive a game we both worked on but due to the modern nature of large game Vel mment 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 Liz [Applause] [Music] England thank you can everyone hear me yes excellent um yes so I am talking about probably the most riveting topic that you could possibly discuss in game design which is about documentation um now this talk is a little bit Advanced

maybe sort of um and it kind of assumes you already know a lot of the trials and tribulations of dealing with game design documentation especially on a big team um there's several talks prior to this um that I recommend um that you can find on the GC Vault or you can find on YouTube because I'm going to spend my 10 minutes talking about a very specific kind of subtopic um and my personal take on this which is my thesis which is make actionable documentation um 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 um and and for me that's what actionable means it means people can act on it um 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 um a lot of times when we make documentation we make this to be um comprehensive and exhaustive about a game we're documenting a game game um 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 uh 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 um it's the people that care if you document it uh and when I talk about people um let me uh so instead of asking what feature are you documenting ask who is this document for um and then try to answer that who question right um 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 um but I would say get a lot more specific than that um 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% that they care about they're just

going to bother you at your desk instead um and maybe you prefer that um 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 and you say hey Adam that guy in AI you know what does he need in order to you know read this documents and you sit down with him and you get his buying in the first place I like to think of a document as this like special handcrafted bespoke artisanal gift that I'm giving to another developer and it's like made perfectly for them um and maybe in this case Adam right likes use cases so oh yeah he loves use cases and we use 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 um and when you when you write documents this way you're getting a lot of buying 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 s 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 um 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 will you play it I'm like well what am I doing with the game you know am I um how am I interacting with it so uh when I say act I'm saying uh 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 um it should have an explicit purpose right if I write a documentation for someone uh DOC for someone you want them to do something with it um and that's where I get into a little bit of game design we all should be familiar with use our verbs right like run jump shoot we should use those kinds of verbs with our documentation as well so read is a bad verb you don't use

that verb um 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 um 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 um or for a programmer in order to implement it and so on and so forth um the important lesson here is that um your documents are going to have very different form depending on what the purpose of that document is and also depending on who you're writing it for so there's a lot of uh different variables that go into your document there's no one set kind of per Perfect Design document to follow so that's sort of like my summary of make actionable documentation um and again actionable here is the important word it means people can act on it so I'm going to go over a bunch of practical considerations um and there's a lot of them right cuz when you actually try to put this into um 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 um also this means you know we have smaller documents more concise documents because you stripped out all this extra information that you don't need to give somebody but that does mean you have one feature but you might have to make several documentation several docs for that feature so um I'll give you a couple little examples so this is a map from most of my examples are from Sunset Overdrive this is a map from Sunset Overdrive and it was great because it might make zero or almost zero sense to you guys but it was built with the people who needed to use it together in the same room um and this was basically leads from all the department got together and we built this map um 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 in the first place um 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 um and it just has a bunch of Post-it notes and this was our way of organizing side content in the game um 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 just posted notes and we moved 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 hand 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 flowchart now keep in mind so this flowchart worked really well for various people on the team especially for QA so that they could debug when do side content roll out but when you look at it you realize none of the location information is here there's no map right so we stripped out the information that we didn't need because it would just essentially clutter um um clutter the rest of the uh

clutter clutter the document for other people on other teams um and then I'm going to go real quick because I'm taking too much time uh so this is another document I wrote it's a big flowchart 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 um but I handed it to the designers and their eyes just glazed over and they just looked at me with what was going on and so I basically reskinned it took away a lot of quantitative information and replaced it with some qualitative information you know with 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 one one size fits all I had to make several that were um that that suited each person's needs so some other practical considerations um it's okay not to update docs um if they've served their purpose um go ahead and retire them you know know uh I no one likes updating documents that have been old from 6

months old just just make a new one uh sometimes the game is its own best documentation so here's a good example of that in Sunset Overdrive we made a bunch of changes to our traversal system um and then we had to communicate that to the whole team so we got this awesome visual design document and everyone kind of understood oh so this is the direction traversal is going um 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 traval well go you know sorry go play the game right because at that point the game was the best documentation you could have for this system and when it changed there was no reason to change documentation and inform the whole team you just go and you play the game some other considerations to deal with um write docs when needed not before um don't write for an audience that doesn't exist yet so some people might not like this one uh what it means is let's let's say you're designing a boss and you have you know your high level approval well you can go and you can write all the details for it but it might not get implemented for 6 months and everyone

knows that in those six months a ton of things are going to change um so I would argue that you wait until the last possible practical minute before you write that documentation so you know who's actually be implementing it so you can write for that person um the obviously the flip side of this is that suddenly you get documentation uh and that means you have to have a really fast turnaround and be able to do documentation and be really flexible with it uh so that that's one of the downsides uh and this also runs counter to a planet out first mentality or it appears to on the surface at least um because there's the idea that we want to plan everything and then um plan it plan it out first as much as possible before you start investing the money to implement it but I would argue that um 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 uh strip out the idea planed out first um some more some

more practical considerations so it's not an excuse to avoid documentation um even if you're waiting up to the last practical minute you're still rating more documents not fewer uh it doesn't replace every document that you make uh there's still going to be times where you need to make that you know 20page document that some people may or may not read uh and it's sad when they don't read it but I would argue that um we should try and make it as actionable as possible so this is an example of a document for um scribbl nuts 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 um and split it up uh and then just to wrap up I just want to acknowledge that this talk may not work so well if you're an indie or you work alone cuz you are making all the documentation for yourself and not a big team um and then the last thing is that sometimes it's difficult to onboard new people 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 uh least worst case scenario so that's it that was that's my argument for make actionable documentation thank [Applause] 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 D platter talking about a subject dear to my heart often 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 worked on everything from sports games to Total War franchise to 2014's Game of the Year Shadow of Mordor Michael De platter hello coming through um yeah I just love GDC so much all of these talks is so inspiring and I guess really that's probably the number one takeaway

from uh this talk is how much other games and multiple genres can inform um 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 haded sports games and War games and real world references in for the Nemesis system um and it's sort of a a two-way street so so the Nemesis system was something where we wanted players sorry I should just explain it was uh the key feature of shadow of M 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 um 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 at that we really went back and looked not just at action adventure games not just at games within our our genres but also sports games war games all sorts of different things and in particular um what we sort of looked at was the way that sport 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 um and the ways in which they generate stories are through a lot of the same mechanics that we see in books and movies and other media so they create and set up conflict um one of the things that was very important for us is you don't have save

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 uh you don't roll it back and play it again you have to overcome that loss and those sort of uh real world passage of time is great for drama it creates rivalries it creates comebacks it creates underdogs it creates uh 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 uh make that treatment of time tie together with our fiction which in this case was Lord of the Rings and uh a system of death and Resurrection so time would move forward and we we would be creating these personal stories with enemies and another thing oh excuse me sorry end of the week it's getting uh I'm finally

getting puberty and um another thing that's very common and we can see in sports but also very much in drama whether it's Jane Austin or whether it's Patton or you know whether it's Star Wars is social structures and social hierarchies underly 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 as 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 um not a structured narrative but creates the same sort of emotion and the same connection and then as a a specific example going back to sports Sports Seasons are basically a three act narrative structure um you have act one

where you know we see who the various teams are who are the favorites what's going on and we have act two with this the sort of constant buildup of the action the highs and lows and then act three they generally have a structure of the finals and the final climax in the grand finals 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 um action adventure and the other one um 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 as I say in 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 Vendetta and this 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 is multiplayer games so you know Call of Duty and um and so on which was another we 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 emotion and all of these sort of systems for creating stories and drama aren't within the the framework of um even nonlinear narratives or branching narratives or the sorts of things that we can see in RPGs it's generally uh trying to actually make a system that generates drama and relationships and something else we looked at from Sports and took is that it does it creates is 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 narrative so you have heroes and villains emerging you have revenge stories emerging uh you have underdogs that come up you have grudges but all of these individual personal stories are taking place within this framework of a a larger conflict um and again although we see it in in the real world in sports it's something that mapped very nicely to Mordor and orc Society for us um and then another thing that's really interesting is there's whole sections of Journalism basically that are dedicated to creating and narrativizing 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

ne Nemesis system uh under the hood is obviously enormously complex the way we always want to surface that to people is in a naturalistic story um 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 [Music] world and then have to speed up a bit but um War shares a lot of the same structures and again War like sports not only creates these stories but is um very often a reference point for entire genres of fiction so we have entire genres of of movies around Sports we obviously have a lot of genres um and a lot of films around War because they share those dramatic traits of conflict of escalation towards a uh epic finale of personal story so you know Band of

Brothers uh platoon within the context of this larger epic conflict so games like Civilization are obviously very good at simulating these large scale conflicts but we wanted to see how could we put personal stories and Nest them within that and an emphasis on uh human hierarchies and social structures whether that's generals and troops and the military hierarchies or sports teams and then just quickly um a couple of specific examples of how we used real world references to create stories even going back to Total War which was where I was working before um Shadow of Mordor people are also very very keen to project agency and project character onto um onto NPCs so by applying traits personality traits onto 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 uh and we tried 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 of differentiating them as enemies by making them uh block your different abilities 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 um another example we had of using sort of a drama mechanic in the in concert with the uh balancing mechanics was in Rome very often the the Roman Empire from the start 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 and rivalries of course 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 we built it around those principles that we see in these real world uh 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 um and also focusing on social structures and human hierarchies and again we can see that in Jane Austin we can see it in Mexican prisons we can see it in sports teams um but then the the other thing we had to do is is figure how do we surface that to the player how do we narrativize that in a way that feels really powerfully like a story um 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 like oh my God I did I am the center of the universe human beings are amazingly entric and it's great um and so then this was just other examples you know we were obviously focused on a single player action adventure game um but there's so many other games now where you see this possibility of people ating narratives about what they've done within these worlds and what's exciting about something like Day Z 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's um takes me to the last slide which is at monolith the the way we work and our framework um is very much represented you can in this book Glu to games but there's a theory player in engagement through need satisfaction which is a theory of uh 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 in the rest of their life which is autonomy people want their decisions to uh have the ability to make meaningful decisions competence they want to people want to learn and sometimes they want to feel like they're kicking ass and relatedness people want to to uh 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 fing the same psychological need so what we were really doing is looking at the real world to inform what we did in the game so strongly recommend uh glued to games and then see how you can use uh Real World Systems like that to maybe inform uh getting players to get invested in the stories within your game thank you oh and and we're Haring thank you all right all right so

that's Michael D platter our final speaker thank you you know as 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 cards you choose will affect how you develop games and different decks will work differently in different uh better or worse in different situations but more important is that the deck you have feels good that's one you enjoy developing with so these have been our sessions there were a lot of references in this talk if you wanted download the slides they're up at that URL right now uh 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 get all those cool references uh to go do some more research we're not going to do Q&A but we'll be around for a bit either here or outside in the hallway probably because we're a little over time if you want to come talk to one of us uh we would love that that'd be fantastic and please remember to fill out your surveys thank you for coming