Game Design Case Studies - One Designer | One Game | One System

[Music] hello everybody welcome to game design case studies I am Eric Zimmerman and I'm moderating this panel um what is game design case studies game design case studies was inspired by a question about what is an advanced game design talk unlike our sisters and brothers are spiritual sisters and brothers and other design fields like architecture graphic design industrial design we're a very young field we're still kind of figuring out what an advanced understanding of game design might be and I'm inspired for panels like this by things like detail magazine architectural detail not being not the men's magazine they have they have magazines that are extremely focused these individual magazines are about like timber construction and building libraries and inside they basically have porn for architects right like detailed diagrams and layouts that

that just explain hey how does this design system work how is it put together beyond what you see on the surface and the challenge for us as game designers especially with video games is that we play each other's games but we have to extrapolate how the system works based on how we think it's functioning under the hood so the idea here is to be able to lift up the hood and really see what's underneath the session was approved by GDC I did a call for papers and I got a lot of excellent proposals for game design case studies and I chose these three amazing ones that you're gonna see today so we're gonna see three 15-minute presentations and the guidelines for for what they're doing is just each of them are gonna show one game that they designed and one system in that game and all we want them to do is show us how it works without some of the other things that sometimes take up time they only have 15

minutes so we really want them to focus just on how it works and hopefully what we'll get as a result is porn for game designers so please join me in welcoming Tanya short Dan and Bennett fadi today to give their game design case studies we're gonna start with Tanya short Tanya we are so lucky to have her brilliant design brilliance here today she is the captain at Kitfox games and she is going to be here talking about a game that she designed shattered planet take it away Tanya thanks Eric right so I'm the captain of Kitfox games and I'm gonna tell you about the way that the levels and shattered planet are procedurally generated according to design philosophies so kickbox games has actually made up of four people another one is in the audience over there somewhere and the reason I bring this up is because a lot of what I'm going to be

talking about today is actually systems developed by a gyeongwu but also primarily Mike DigiPen and he would rather die than be up here talking to you right now so I'm here to tell you about the procedures that we developed together and the design philosophies that I developed with him so shot at planet came to this team last July and it's a science fiction dungeon crawler of sorts it could be called a roguelike by some and the point to take away here but looking at the screenshot is that it is procedurally generated tile by tile so all of the walkable area is generated by an algorithm there's no hand-built pieces there and it started at the beginning we wanted to make levels that felt like someone had designed them so we took apart a this is a very early mock-up of a level that we were designing and looked at what made it feel like it was designed and so I'll be going through the procedure that the algorithm actually takes and why it takes those steps and then what content

design tools and methods that we used and then what's missing so the procedure of the procedural generation begins with the actual geometry so it builds a shopping list of possible rooms in the dungeon that you can walk along and that's you can think of that as analogous to a level designer coming up with what the possible minimum and some sizes that they can build a given room in and then it starts placing them out deciding where doors can be placed it chooses one as a door it places another island it connects the island and it makes a critical path and it makes the side paths and it understands which is the main and which is the credit be off the critical path which will be important later but at this point you have basic geometry and it decays to look a little bit more organic a little bit more like a shattered planet and little less like a dungeon that you would find in under the ground

with a lich in it and it does that by each individual cell along the edge kind of managing itself having cellular automata to decide based on its neighbors its probability of disappearing with possible doors kept as an exception for reasons the next step is it paints the texture of what it should actually look like to humans it uses Perlin noise mic squashed it until it had a good contrast at the resolution we wanted which was five to five or nine by nine and then along the seams it paints a transition texture which on the right you'll see between one and two they never actually touched there's a transition texture put in there where they would have touched so you get this result of the primary texture of the secondary texture and a transition texture in between which is pleasing one thing that you'll notice here actually is that the bridges never got quite transitioned correctly they still stick to only one of the primary textures oh

well the the third thing that it does is it makes it feel even more organic and even more shattered by again using cellular automata to have the individual spaces around a given room decide it's probability of having what we call crumblies each Edge has that percentage chance to spawn a new crumbly and it inherits the texture of the cell next to it in a case of a transition texture it just picks one of the two textures do you inherit we did have to move the islands a bit further away from each other to prevent the illusion that you could walk on these crumblies between islands that was the only real adjustment we had to make to the algorithm and you can see this is before we added the crumblies it looks very geometric very rigid and then adding crumblies and also a background texture helps immensely with the feeling that you're actually in a level that someone may have designed by hand so next we have to figure out where to put

the obstacles so we wanted obstacles to make you know the terrain more varied so you not let you just walk everywhere you can see and to do that we first used a depth-first algorithm depth-first amaz'd generation and what you can see it's doing here is any given place that is part of the maze connects to every other place right there is no place in this maze where you will get stuck you can always move around even though there's obstacles and so we used a variant of this on the map using path finding so the path finder would would decide where obstacles were allowed to go we would not do it this way again I do not recommend it and it's because this works especially well with rectangles and as I described before we don't actually use rectangles so for example if you start with the door at the top white section if you start walking on that path it no longer connects to a lot of the other paths you actually will get stuck almost

constantly using this method so we had to actually add and duct tape a second system which would go around and destroy obstacles that were placed in the way if the Pathfinder couldn't find the rest of the the maze that it had generated so that was fun so next I mentioned before that there's a critical path and an off critical path the reason why it needed to know that was because although there's different entities that could spawn in them one of these was actually a particular kind of entity which would pick a bridge and turn it into an invisible bridge and put a locked door on it and then put a key along the main path so the design tools we could specify 0 to 3 of these locked doors it would segment away one of the side paths and make sure you couldn't get stuck and that room could only be accessed through that bridge and that's important to happen first because the

next step was to find where there were dead ends in the level and actually looped them around again because as any level designers in the room might know you shouldn't have players backtracking constantly so all of the possible doors that we flagged earlier now look around and see are there any possible doors kind of near me if so I have a 50% chance of connecting to you with an additional bridge so you end up with a much better flow a much more fun experience to explore because you're not constantly going out into the tree and then back again and then out in the side path and back again so next the algorithm looks around and says okay well let's put in some enemies some treasure or some items some story bits and it has a similarly built shopping list that I've defined of possible entities so it's it puts a certain amount of risk and reward like little breadcrumbs of treasure and smaller enemies along the main path and bigger enemies and bigger treasures along the side paths and it actually uses the

obstacle list here that we generated earlier remember the the maze everywhere we was generating where obstacles were allowed to go it uses that because enemies are basically obstacles you have to be able to get through them at some point to get to the end so that's a reuse there of the algorithms a side system and finally after the whole level is built it's all living there's enemies and treasure and you're ready to start playing it splats a big layer of darkness on top and then the player goes around deleting it as he walks this simultaneously adds a bit of mystery making it feel like maybe there's something around the corner that the designer has intended for you but it also as a side benefit gives the player a sense of where they came from and where they're going because if they haven't been there yet then there's there's darkness in front and it kind of allows the player to have self-directed strategic exploration of the space if they're more of a careful player they'll

use the fog differently than a very bold player or a completionist player and it was interesting watching the fog of war specifically to get those cues so the planet has created itself we now have an algorithm that will generate the basic islands so the problem at that point is how what should it actually generate and why and and that's something the algorithm can't really help us with as the level designer a game designer of Kitfox I look at the tools and they're just a pile of mad libs so I start defining the upper bounds and the lower bounds and I start thinking of themes like I sell it okay this is a cold room where there's mushrooms and it can be about this big and it can have these kinds of things in it and I hope that the algorithm gets it and I play it a little bit and so this is what kind of what that looks like this is me defining the primary secondary transition tiles potential

holes in the geometry and and obstacles and things like that yeah so another thing consideration in picking the minimum and maximum size is was actually to think about the theme emotionally of a given level so if a level is supposed to be very claustrophobic that's more of a defensive level because you have more backing when you're fighting enemies you're not gonna get surrounded as much you can see everything all at once smaller rooms are better whereas we have a place called the wasteland which is a much bigger open agoraphobic scary place that's a better suited to larger numbers and the sizes of the islands so at some point we realized that although we wanted to support various player strategies there were a few that needed special attention one was fire everybody loves to setting things on fire and we

wanted to encourage that but part of the problem was that there wasn't enough grass everywhere which was the flammable stuff and so part of it was actually going through methodically and thinking about what are the exactly all of the strategies that we're supporting what how exactly are are the different island-themed supporting this so fire is a strategy that's supported and the various other things we have to make sure that there are enemies and treasure to be found that suit the way that the player is trying to play and that meant tweaking exactly the content in there even if the algorithm itself remain the same a given level will generate very differently depending on what strategy it's trying to encourage one special shout out is that we we had a explosion effect that everybody wanted instantly which was making all of the tiles fall off the face of the earth is exploding the whole shattering the planet it's everybody's fantasy right and then the player would

get stuck and then they weren't as happy so we added in a little bit of a caveat there that if you exploded part of the level that led to the exit that maze algorithm I mentioned before would kick in it would path fine between you and the ending it would make sure that particular path cannot get blown up and it said it exposes this dynamically generated skeleton of the world which most players don't even understand exactly when it's skeleton and when it's not but it's it's not letting you get stranded basically so we were pretty proud of ourselves and we were very happy that the game came out and had you know 400,000 downloads and whatever but there were some problems and it's it's very obvious we became very obvious in the last few months of development the primary one was actually that a given room had no idea what his purpose was it had no idea if it was on the main path was on the critical path if it was a locked room if it was a boss room there was there was just wasn't any sense in

the algorithm of what a room was at all it was just geometry that was connected together and painted with a texture and everything I told you about and that caused the problem because this is actually a screenshot I just took in the game as I was playing and you can see that the key and the door that was supposed to encourage you know exploration and risk for reward of go find the key and bring it back to the door and get in a reward its non-functional because the key is right next to the door like why bother and meanwhile although this particular example has crystals floating over there which is very exciting it half the time there'd be no treasure on the other side and that's fun too right yeah so if we could go back in time we would definitely tell ourselves to build in an idea of what each room is doing another thing that we wished we had done is more of a meta level design of difficulty so we had a ramping difficulty kick in after a certain point and it would add to the difficulty make it harder and

harder and harder but it really just kind of felt like a bunch of random stuff that was sometimes harder and sometimes easier whereas a better designed pacing would have peaks of very difficult fights and then let you relax a little bit and then build back up and so forth and it does not do that and finally the the number one thing that people complain about they said that it was um it felt a little empty and to me I interpreted that as lacking deep consequences it lacked any rooms that were hand built it lacked any kind of sense that things were connected and I think that we as humans and especially roguelike players we're suckers for deep patterns we just love making constellations out of nothing and and it really needed to feed just a little that a little bit more and so that's what we're building into our next game which is moon hunters we're building a lot more hand-built content and completely redoing the procedural generation and so now I will take your questions thank you [Music]

if we have time for a couple quick questions for Tanya before we move on to Dan and while we're getting Dan's laptop set up any questions so the the question just repeated for everyone was as you're making the move from the procedural to the designer the other way around from the feel to the mechanics of the procedural generation I mean it's it's just part of the process for me I feel that that's an important part for every designer to think about like the goal the vision and then break down that down into rules and the way that we did that was we actually built a hand-built tutorial level and gave it to people and tested it and made sure we liked it and then once we had something we liked we analyzed it and we looked at okay well

what are these rules I was traditionally trained as a level designer so I knew some of it but some of it was unique to the game that we couldn't have known before building that prototype because it was it was specific for that game so that gave us rules about like oh this is how big that room should be and this is how long corridor should be and that kind of thing and so that helped us build towards code [Applause] [Music] all right I'm I'm here to introduce next Dan Kassar so don't tell anybody this is a secret but we've snuck in a tabletop game designer into this session so yeah so so Dan is here to talk about one of his card games and it's drafting mechanic but the twist is that he's also a software developer so he's also going to talk a little bit about some of the digital tools that he created in order to test and balances his card game as it was being developed so take it away Dan

thank you Eric hi I'm Dan Kassar I'm a tabletop game designer originally from New York now based in Philadelphia and I'm going to be talking about how I use digital tools to help me balance the Rochester draft in cavemen the quest for fire drafting is one of the most fundamental game mechanics out there after all we all remember picking teams for kickball in the schoolyard but in the world of modern board games when people talk about drafting what they usually mean is a particular kind of card drafting that I call pick and pass the way it works is this each player is given a hand of cards he selects one from card from his hand and then passes the remainder to his left simultaneously receiving a new hand from his neighbor on the right again players pick one of the cards for themselves and continue to pass them on I think it's safe to say that the prominence of this approach probably came from Magic the Gathering

and its booster draft tournament format where instead of building a deck before hand it makes deck construction part of the tournament itself each participant is given a booster pack players each open their pack select a card and then pass the remaining cards Antwan bauzá proved how successful this mechanic could be when he won the prestigious kennerspiel des jahres the German expert game of the Year award in 2011 for his game seven wonders which is entirely based on the pick and passed draft mechanic but I remember sometime in the early 90s I saw a group of players at a local game store drafting magic cards in a way that hadn't seen before instead of opening one pack per player and passing the cards they would open a single booster spread the cards face up on the table and then players would take turns making their picks I later learned that this was called a Rochester draught named for the city in western New York where the format is supposed to have originated widely regarded among serious management

players as the drafting format that requires the most skillful play an open draft plays quite differently from pick and pass it turns cards into chess it challenges a player to make the best decision based on what he has already chosen and what he has seen the other players select torn ardor becomes all-important and countered drafting becomes a much greater factor because there's no hidden information you can choose to thwart an opponent by denying him a card that he needs but only if you're willing to sacrifice one of your picks to do it cavemen the quest for fire is a card drafting game I designed based on the Rochester draft that was published by Rio Grande Games in 2012 players bid for turn order before drafting cards to contribute to their tableau that represents their tribe combining an open draft with an auction creates a game experience that can be highly competitive without the need for direct conflict players take the role of tribal

leaders and compete for scarce resources such as dinosaurs to hunt cavemen to recruit and inventions to discover vying to be the first to invent fire gameplay is organized as follows each turn a number of cards are drawn face-up into a common card pool then the players use teeth representing prestige amongst the tribes to bid for the conch which is the first player token after the bid players pay food for the cavemen in their tribe to keep everyone alive then starting with the conch holder and proceeding clockwise around the table players take actions that allow them to draft cards from the pool and then some of the remaining cards are discarded and the pool replenished for another round so the challenge was how to achieve costs and reward curves that not only kept the

pace of the game moving forward but also created opportunities for players to compete meaningfully in a game that used resource denial as its primary means of player aggression for example suppose we're early on in a game of three players Abe has the conch at the start of the round and if no one bids he will go first he's trying a technology focused strategy since invention is the way to win the game it's very efficient but it can be hard to keep your tribe fed and starvation can ruin your plans Brenda sits to Abe's left she's trying to pursue a strategy that relies on foraging it's slower but safer strategy than hunting and also gives her the freedom to go after certain inventions Chris is the third player he's pursuing a hunter based strategy that ensures that his tribe will be with well-fed but it might be hard for him to compete for special abilities later on in the game in this spread the most interesting card is this one baskets which is an

invention that grants its owner a considerable bonus to their foraging score obviously any of the players would derive a benefit from this card but Brenda Bob benefit most since it suits her strategy best a bids first since he starts with the conch but he decides to pass since he thinks that the other players will bid andin cavemen you are allowed to jump back into an option even if you passed in an earlier round Brenda also passes because she's betting Abe won't draft the card that she wants Chris decides he can't take a chance and he bits to teeth to gain the conch he wins the option and drafts baskets so that Brenda can't get it moments like this are where the fun of the game really come from and they require a number of conditions to be met in order for those situations to emerge to create that tension players need to have both the desire and the ability to be in the bidding and in cavemen that means having sufficient total skill to make use of

the card in question as well as enough teeth to make it worthwhile participate in the auction in order to achieve this balance I went through a huge number of evolutions of the deck before settling on the one that made it to print and I was only able to manage that complexity with the help of technology I started writing code on my Commodore 64 when I was 8 years old and I've been writing software professionally for the last 15 years so I supposed it's almost second nature that for for me to record the information related to my games b-day analog or digital in a computer readable format I chose to use a form of loosely structured data called XML to represent the dead XML extensible markup language was designed to be both human and machine readable and to permit evolution over time data elements are represented as tags with names and values that you can expand on arbitrarily to suit your needs since the data was human readable I could work

with it without any special tools just a text editor like Windows notepad and it allowed me to quickly add and remove cards and since it was machine readable I could use it for all sorts of automation from printing my prototype decks to running scripts that exercise different place in Aereo's over time however editing the document by hand became a cumbersome and importing the data into Excel while helpful was a tedious manual process so instead I developed a piece of software that work much like Excel but used my XML document as its data source and would save a copy of the document every time I made a change this offered a number of key advantages for one thing this automatic version tracking ensured that I never lost any of my ideas I could always go back to a previous revision over the two and a half years I spent working on the game I created more than four hundred and fifty versions of the deck sometimes they work but more often they didn't if I decided I didn't like the direction things were going in I could simply go

back through the history of the data and carry on from an earlier version additionally the flexibility that I had in adding and removing fields allowed me the freedom to discover over time what data was important to track and what was not as I conducted playtesting I went back to my document and tried to incorporate what I learned sometimes I needed to tweak the cost sometimes I wanted to change the wording on a card but just as often I was trying to capture data that was beyond just what appeared on the physical card I wanted data about how that card affected gameplay overall I wanted to understand how each card fit in and which players selected them and at what time since there was no strict structure to the data I could make up new fields as I went along and I could remove them later without causing problems if the information didn't prove valuable this allowed me to incorporate playtesting metadata directly alongside my card data so that I could then edit and analyze

all of it using the same tool and this was how I identified the three core strategies that players generally followed I noted the number of cavemen that a player had and of which types at the time that intervention was taken and over time certain patterns started to emerge the hunter strategy was characterized by selecting additional hunters early and gaining an advantage in food and teeth it's straightforward and effective but it means that the player cannot leverage many of the higher cost inventions in the game the inventer strategy usually meant taking a thinker as your first recruit and then carefully managing your food supply while amassing inventions that only you could use it has the advantage of being efficient but thinkers can't help you feed your tribe so food often becomes a problem the elder strategy focuses on foraging as a safe food supply and can be dominant if it manages to acquire one of the few key inventions that help it gain teeth so that they can compete for

fire at the end of the game once I had made that discovery I started including the strategies in my data when I designed a card I would tag it with the strategy I was gearing it towards and then after play testing I would add additional information about the strategy being used by the player who drafted it this helped by not only making sure that the cards were doing what I designed them to do but also helped me make sure that I could easily see how many of the cards I had intended to help each of the three major strategies if I added or removed cards I could sure that that strategies remained relatively equally supported I remember one time in particular where my play testing data showed its value in an unexpected way I had been taking the game to designer meetups for playtesting sessions and the game was generally well-received but there were a number of questions about the balance of the inventions in the game so I had been steadily tweaking costs and swapping out cards and gradually a strange thing happened players had

stopped engaging in the auction everyone was content to simply let the Conch pass around the table and take what they could at first I thought this was some sort of anomaly or something particular to the way the cards had been drawn so I kept going the way I was going tried to achieve a perfect balance between costs and benefits for the inventions relative to one another but looking back over successive versions of the data I saw that during the process of balancing the invention costs I had gradually increased the cost for the most useful inventions thus putting them further out of reach for more players for more of the game as a result all the tension was gone somehow more balanced costs killed contention that's when I realized that in order to make the game fun I had to create sufficient opportunities for players to compete leveraging the data that I had gleaned from play testing I identified inventions that worse suited to multiple strategies then I made those inventions intentionally under costed so that

players would bid for the opportunity to draft them for example the feast card allows a player to convert food into teeth this of course only works if you have enough food to spare so it's not suitable for a player focus solely on invention but it does work well for other players that can gain a surplus through hunting or foraging if it appears late-game this is a card that is intended to be bid over because it's mathematically superior to all other ways of gaining teeth in the game similarly medicinal herbs greatly reduces the chances that you will incur losses when you go hunting this works well for both hunters and inventors because both of those strategies rely on hunting to gain food it's got the lowest possible cost so anyone can take it and it's more useful than many other cards at the two and three cost levels so this encourages players to compete over it tabletop designers may not always think about the ways they can leverage technology to help them enrich an analog experience bouncing a set of cards can

be a tremendously tedious task a single design decision can cause changes that ripple throughout the entire deck as cost curves shift and card counts are thrown out of balance having software to make this more manageable encouraged me to take more chances make bigger changes and ultimately lead to a better design [Applause] then it's a it's a crime that you're not working in the digital game industry sure so first of all ya the tool is excellent I built something similar but I was using Google Spreadsheets which does a lot of this stuff but what I found was and you can you can export things export XML you can do the revision history but what I found difficult was figuring out a way to actually visually display these cards I used HTML but it's really hard to get

that to print properly I'm just wondering what kind of tool you built or used for that display yeah that's a problem that I worked on I had went through a few iterations on that first I tried SVG which turned out to be really difficult don't recommend that so I tried using my second more successful attempt I leveraged an external tool called man deck if you're a tabletop game designer you might know this one it's a it's actually scripting software that that you write code to generate your cards so I would out of my tool I would generate a script for an deck and that would do the so I could leverage it to generate my cards and print them so that works a lot better in an deck cool yeah Thanks so whenever I'm building tools for a game I'm thinking always about how I'm not spending time making my game I was wondering if you measured the amount of time you invested in this tool because it seems like all of your

work like with it with a videogame usually when you work on your editor you're also like salvaging some of that technology for your game but I see it seems like in this case there's absolutely no overlap right and was there anything that you did to like make sure that the features you were adding were paying off on like an individual basis because obviously the tool paid off but there were a lot of like you know seems like luxury quality of life stuff in your tool did that did that work out well yeah I would say that without the benefit of the tool I wouldn't be able to surface the same data that I was that I was able to see with it it was kind of the thing that started as you know a hobby project started very small like I said I was originally just tweaking the XML and by hand and notepad and then I was like well I'm a programmer I can do better than this and so I did and you know it evolved over time no I never measured how much time I actually spent on it like I said it was kind of you know grew

up with the game over time I just added more and more features and as I said I spent years working on the game so it was I never really paid attention to you know how much time it was I don't because it was fairly generic I didn't feel like it was wasted time because I am using it for future games as well cool thank you how much of the analytic stuff you got was out of the running yours you mentioned software to run games following certain strategies how much would you say came from that versus how much you got from watching and I presume recording human play sessions did you record those and feed it back into analytics I recorded it in that I watched and then put the data back in and so I did do a certain amount of scripting and automation and what that allowed me to do well that was generally to do was to just run algorithms to check my math once I was comfortable

with that then it was pretty much all hand play testing that gave me the best results thank you all right thank you thank you [Music] so one of the one of the funny things about games is that games and game designers are kind of like dogs right I mean as a as a as a species you would never guessed that like some some strange little thing that looks like a shaved rat is also this the same same species as a sort of huge giant hairy bear of a dog right that is like ten times as large and looks like it's from a different planet so what's amazing about the the the designers that we have for you today is that they're so different and it's it's my pleasure to introduce Bennett fadi who's going to give you a completely different kind of case study he's here to talk up today about real-time physics in in his game super pole riders Bennett is a legendary indie game designer best

known for QWOP he's also a professor at the NYU Game Center where I also teach let's give it up for Bennett buddy [Applause] thanks Eric okay so super pole riders is a game of pole vaulting polo it's part of a compilation of four local multiplayer games called sports friends which is out for PCs and Playstations so the basic idea of super pole riders is that players traverse an arena primarily by vaulting up on a pole vault pole which allows them to kick a ball that's suspended on a wire towards a goal and score points right so that's the basic layout of the game and what I'm going to talk about today is how I designed the input scheme for the pole that the pole pointing mechanics the game itself is a gamepad redesign of an older flash game I made called pole riders a game that I

thought had some pretty bad design flaws it was really unhappy with the original game is is a browser game so you're using digital keys to control the pole and the way that works is you can only rotate the pole towards pointing up with the up key or towards pointing down with the down key and it moves really slowly and I think inaccurately and it feels unresponsive and very loose which is funny but not not very fun and I also had this really serious problem which was that people were blocking their their the goal with their poles and you know this is super embarrassing to admit in front of a crowd like this but my attempt to solve it was that I made the defending player have really weak arms if he was standing near his own goal so he couldn't lift up his pole very well which you can imagine not a very good solution doesn't work anyway because you can kind of like run towards the wall and get it wedged up there and then the other person can't score a goal so I was

really unhappy with that as well and I came to see all of those problems is stemming from a kind of a central conflict between the design goals of real-time input schemes real input schemes for real-time games and the technical limitations when you're using a physics engine for your games so in real-time games there is this this thing that you want which is a really tight correspondence between the trol surface and the controlled object so the classic example would be in Super Mario Brothers your character is basically instantly in the air when you hit the jump button and you know what what's more of a kind of apropos example is really the design touchstone for my game is the arcade game 720 degrees the old Atari game which has a special joystick called a spinner which is which is a joystick that's constrained to the edge of a circle so you can see you're only able to move it around the edge of the circle and then this what it does is it makes the skateboard always point

exactly where the spinner is pointing right no matter what so there is this one-to-one correspondence between the position of the joystick and the position of the skateboard in there in the digital realm and by contrast games that have fully dynamic physics engines which was starting to see more and more of typically use in direct controls that have a very weak correspondence between the the input surface and the inner game because at an engine level you can't manipulate things in the same absolute direct way without risking fletcher's so for example this is Angry Birds and Angry Birds what you do is you pull back on an invisible spring which attracts the bird towards your finger without it mattering whether or not the spring can get the bird all the way to your finger in fact if you made it so that the bird stuck absolutely to your fingers position you'd get glitches if you put your finger over the ground for example the physics engine wouldn't know what to do and you'd get you'd get flaws and glitches or in Lander you're applying

this gentle thrust to a moving object with this with this thrust control to gradually alter its velocity so you can't make the position of the land to correspond one-to-one to the to the thrust control you can't even make the velocity of it correspond one-to-one you're just applying a kind of weak acceleration and I think we still see a lot of physics based games that are in that vein using buttons or joysticks or triggers to control an acceleration rather than have a kind of one-to-one correspondence and Paul riders is a physics game and it has this fully dynamic world which means the players the poles and the ball are all able to push back on each other but it's also an action sports game so I wanted the pole to be controlled with that one-to-one correspondence to the to the controls you know and I which for the the sequel meant using an analog stick partly because we're also targeting consoles and PCs so those two things are in conflict since in-game objects can push

back on the digital pole but they can't push back on the real thumbstick the pole can even get jammed against the walls or against environmental objects or players in which case it won't do anything when you move the controller so it's kind of completely break correspondence so when I went to make super pole riders I had the idea that I wanted to to solve or at least reduce that conflict and so my approach was to start by making two grounding decisions which I was reasonably confident were correct and then to try and solve all of the kind of secondary problems which bubbled up out of those two decisions so the first grounding decision I made was the pole should always at least try to move so that it's pointing in the direction that you're pushing the analog stick like there the spinner joystick in 720 degrees so that allows you to at least have the goal of creating a strong or perfect correspondence between the game world the pole in the game world and then the analog stick on the gamepad because the pole is literally mimicking the motion of the thumbstick the second

grounding decision I made was that the pole should be unrealistically heavy much heavier than than the player in the ball and that's for two reasons so the first is just a technical reason so the way these physics simulations work is if you've got two objects that are connected they won't be stable unless they have similar mass which in this case means that the the mass of the very first part of the pole the very first segment of it has to be close to the player's mass which so the total mass of the pole will be greater than the player and second second since the pole is the main element that you're controlling that's where all of the kind of strategy in action happens I was thinking of the pole as being the real character right it's the real it's the real avatar of the player so I wanted it to have physical dominion over the player's body so it for that reason needed to be far heavier than the player as well so went about implementing it and to do that I anchored the pole to the players body using a rotational joint so this is this is just a you can imagine like a

little pivot joint that has a motor on it that can apply a rotational force or a torque to rotate the pole and the question is how fast then how strong should it should should the motor turn and so as a first step what I did is I just gave it a proportional control which just means that the torque of the motor a is some arbitrary tunable constant which I've written here is K because I did a physics degree in college multiplied by the difference between the joystick angle the angle that you're pushing the joystick in and the pawls angle in the game so the idea is that it's pushing hard when the pole is far away from the position that you're requesting with the joystick and it lets up a little bit as as you get closer so I also made it that if the person let go of the joystick altogether the motor would just switch off but that leads to the problem of overshoot right so the pole reaches its target quickly but it's so heavy that the weak proportional talk remember it's going down to a kind of force of zero at that

point can't stop this super heavy fast-moving pole when it reaches the target position you wind up with a wildly oscillating pole that never-never points where you want it to point so what I realize is that my two grounding decisions were in conflict so in engineering I did some research and in engineering that sort of overshoot an oscillation is a problem that occurs in all kinds of systems from the furnaces that heat up large buildings to thermostats and coffee makers and so on and they have a standard solution in engineering which is to use what's called a PID controller Pibb controller which stands for proportional integral derivative control which takes the proportional control I described on the previous slide and in adds integral and derivative components to the proportional control now that sounds very complicated and technical but it's not it just means that you're going to speed up the motor based on its angle relative to the target that's what we're already doing but you're also going to slow it down relative to its angular speed and to its angular

to its average angle over time right so you've got instead of one constant K you've got three constants K 1 K 2 and K 3 this it's just tunable constants and it turns out you know there's no magic way of tuning this system whether it's whether it's a boiler or whether it's a video game the way people do it when they're when they're fixing the furnace in your building is you just you just shootin the numbers manually until you find the right combination of magic numbers so I did that eventually I tuned these constants to the point where I had a reasonable blend of speed and stability so with that with that edit it looks something like that and with the pig tuned I was able to find this kind of I think a reasonable balance like as good of a balances you'll get with a super heavy pole and so I had kind of first pass of my direct pointing controls that I wanted with the heavy pole but latency is still a problem here

right you know it's taking time for the pole to reaches target which is a problem because you know although it takes time for the pole to rotate your control stick can be moved around instantly so it was feeling sluggish it also breaking that one-to-one correspondence and the controls that I was going for and I'm spending a lot of time with the pole pointing in a direction that's different from where I'm pointing the the stick in 720 degrees they have that same problem but they were able to implement a fix in hardware this is the underside of the of that spinner controller there's a bike chain and a heavyweight hidden under the joystick so just resists being moved around too fast so this is hard mechanical limit on how fast you can rotate it which limits the rotation of the skateboard in the game but that's obviously not an option if you have a thumb stick on a gamepad it's also not a it's not an option to try to rotate the in-game pole as fast as the thumb stick because that would require near-infinite forces in the physics simulation which will certainly cause bugs and glitches so I couldn't do that you need controls that can respond instantly but you can't

force things in physics games to react instantly especially if they're heavy so it's kind of a fundamental problem facing most physics based games and I don't think it's usually solved well but I came up with 2 fixes to it so the first one is to add some one-to-one instant cosmetic feedback that's reacting instantly to the thumbstick but which isn't part of the physics world so if you look closely here I know it's subtle but the instant that I move my thumb stick the players elbows rotate so it looks like he's kind of twisting his upper arm to apply leverage to the pole so that kind of squares the circle right we keep our slowed dynamic physics world and without having glitches but we're adding fast visual feedback elements that aren't part of the physical physics simulation so the controls now respond at least cosmetically perfectly to the joystick at least in these kind of elbows and so players feel at least like the game is reacting to their input even though the pole even if the pole is blocked even if it can't rotate at all and I think that

reduces the feeling of latency the second approach I took was to design the game so that the player is unconsciously encouraged to request positions with the thumbstick that are close to the poles current rotation current angle so it's like the player is enforcing one-to-one correspondence between the stick and the pole rather than the system so how do you do that well this is again back to 720 degrees what they do is they wipe you out if you point the stick in a direction that's perpendicular to the direction you're traveling in so it gives you this message you're trying to spin too far wipes you out so usually what you're doing when you're playing that game is you're trying to keep the joystick pointed in a direction that's close to the direction of travel rather than making really fast Corrections I couldn't do that in my game I can't wipe people out because they moved the thumb stick too far but it did provide the inspiration for the actual fix that I came up with so while I was tuning the game I realized that I could make the ball a lot lighter than the pole in the player and if I made the ball really light then it would be easy to block it either with the pole or with your body

so then what you find when you when you test it is that the players want to spend more of their time in a defensive pole with the stick straight up or with the stick straight down where they're trying to keep the the pole still they're only making these kind of minor Corrections like in 720 degrees to the angle the pole so that so the thumb stick and the pole are usually pointing the same way and I don't think people really notice that they're doing it but they're doing this job of bringing the thumb stick in the pole into one-to-one correspondence for you so they you still have this kind of high latency and poor correspondence if you need to switch the polls position suddenly but you're only doing that a small proportion of the time so by making the ball extra light I made the correspondence better more of the time okay but that solution leaves me with one further kind of problem which is it brings back this problem from the original game so now that now that I can block with the poll I can use the poll to block the goal indefinitely since the ball can't pass through the poll so I

really struggled with that problem I think is evidenced by the fact that I think that what I did with the with the flash version with his arms getting really weak when he was standing near his goal but after really kind of thinking about it for a long time I found some solutions to this in level design so by adding a dip in front of the goal so that when you're standing in it your poll just can't reach high enough to block that was one solution another level I added a hole in the goal area so you just can't stand there and defend and the other thing I did is I made some levels where there's this uncle aidable backboard that the poll can't rest against which means that if somebody comes and pushes you the polish is going to be pushed back past the goal and it's not able to defend anymore so that's how I designed the input scheme for for super polar writers it's a it's a system that doesn't just happen at the level of interpreting the joystick movement and deciding what to do with that joint but also at the level of how the player and the ball objects are

constructed how heavy they are and how the levels are designed and I think in the end that does a pretty good job of solving the fundamental conflict here I've got I've got my fully dynamic physics world where everything can push back on each other and I've got a control system that corresponds most of the time at least to the thumbstick on a gamepad it's not it's not as good as 720 degrees but I think it's a lot better than the original version of the game and it makes pretty good use of the analog sticks thanks you