Designers Are from Saturn, Programmers Are from Uranus

[Music] hello people I think we're going to get started I kind of wanted to mention um if you were sitting in here before things kind of got going and they didn't scan you on the way in if you would really really please scan your ask them to scan you on the way out because otherwise I don't get the review and I don't get a lot of the information that I need to to make the talks better for for years to come um that being said I'd like to start uh my talk this year is designers Are from Venus and programmers are from Uranus I I kind of get to say things like that because I I'm I am a programmer and so um it's sort of like Dave Chappelle gets to tell certain jokes and Ellen degenerous gets to tell certain jokes so who who who am I I'm standing here in front of you guys um I've been in Game Dev for a really long time I was recently at blizzard and I worked on Hearthstone it was actually my 19th ship title um I've been in companies from garage companies to Sony of entertain

Sony Computer Entertainment of America probably the largest one and I've worked on a game in almost every genre which is kind of kind of weird in a way um I had never done a card game before that was interesting and mostly I've done gameplay and AI but I've also done design I've even been lead designer on a few of the projects that I've worked on and I put them in this order for a good reason I've always found that AI is sort of on the border between design and gameplay um on the border between design and and programming and in order to do AI right you end up having to be in both sides and this is kind of why I'm doing this talk because I find myself in many of the companies that I work at as sort of a translator between these two groups I would find myself all the time coming around the corner at Sony and and finding uh uh two people arguing and I would kind of sit off to the side and listen to them for a while and very quickly determined that they were just having a communication problem they needed Google Translate to to come in

and kind of help them and so I would say hey I think what he's saying is this and I think what he's trying to say is this and they would both kind of shake their head and go yeah and then walk away and that happened so many times that I realized that this is really a problem and and um that combined with doing a lot of psychology sort of work with with AI I've really started to get a feel for how people work together and and and and that sort of thing and it's been part of my job for quite some time so in in summary I'm a seasoned veteran I've pretty much seen everything and I've been exposed to a wide vast array of work environments so why this talk well the way that we make games is changing quite a bit I mean the old the old way right was that a designer would write a spec the programmer would go off and and implement the spec he'd come back eventually and they would play test it and and it might get repeated maybe that was kind of how things worked but nowadays that's not even really how we even make games anymore a lot of times a system designer will write the doc the

programmers will then Implement a tool that the content designers will use to make the game and then the programmers will support both of those designers with tool and feature changes and then we keep doing that over and over again until we ship and and many times we even keep going it afterwards because games are online nowadays and we can update them all the time now obviously this is more of a AAA process and there's differences if you're doing a an indie team or what have you but this is kind of how games are done nowadays and and as you can see there's a much tighter coupling between the designers and the programmers in the new system than there ever was in the old system the other reason I'm doing this talk is because features themselves in our games are changing you know while the the dis the the disciplines are still in the big three you know designers programmers artists are how we divvy out our our staff game features are not really divided that way anymore I mean even this feature that probably could have been drawn by the same guy who programmed it who was also the designer

but even that feature I don't I don't believe was done by one guy and and what about that feature is there anybody in this room that can tease apart which was the programming and which was the the the design on on this feature it it as our games become increasingly complex the features themselves become increasingly complex and they require these these cross-disciplinary teams to work super tightly if they're going to if they're going to work out and these two groups can be especially tough to harmonize because they really don't think anything like each other so the things I want to cover in this talk are basic differences between the two actually working together as far as the establishing a connection and and ongoing sort of things and then some Bridge methods that are starting to be used by the industry um one of the things I did when I when I when I do a lot of these talks is I go on to Google and I type the

thing that I want to think about into Google images and and it it's cool right because Google images or Google in general the way that they score things and they bubble to the top is like that's the link that the most people clicked on so in in effect you kind of get a asked the audience sort of sort of thing when you when you consult Google on things and so I typed game designer into Google and that was the actually the first picture that came up now for me I don't know if if it's different for anybody else and and that's that's kind of a cool picture and so then I typed game programmer in and I got that picture and and I think it's kind of interesting that that even ask the audience there's a massive difference right when you when you ask the audience what what's a game designer you get a concept you get a a powerful drawing of of the creative process and when you ask what's a game programmer you get John carac you get you get a specific guy you get you get somebody sitting at a desk programming and so even the general populace sort of knows there's a there's

a very distinct difference between the two the two and so the process by which these two groups actually do work is vastly different as well the design as you guys all know is is very free form it's it's super collaborative it's largely discovered it's it's you're kind of out there in design space looking looking for the fun combination of rules that that that that give you something special and it's very situational depending on the game the part of the development process there's no real sort of formula for for the design process at any given moment whereas programmers are not that way typically their job is much more structured they can divvy out tasks and separate systems much more easily and they can divvy out the work much more easily they deal in abstract systems and and that's sort of their mindset in the in the total and and also they're typically a lot more isolated they tend to be able to figure

out a task go off and kind of do it and come back for feedback that's not the case with with with design typically you don't have that sort of back and forth you have group group sort of Dynamics so if you have a mixed team environment you can see where this might rub everybody kind of the wrong way um the programmers are going to feel interrupted quite frequently because because there's a there's a loud potentially boisterous talk going on right next to them and while yes occasionally they're going to be able to give some feedback that might steer that group in the right direction for every one of those times there's probably 10 times where they're going to give some feedback or naysay something that's that the designers aren't even trying to say we should do they're they're they're blue skying over here and they're bouncing stuff around and it and it's sort of Proto ideas and you don't want to naysay a Proto idea right because that that that leads to stifling and on the same other side of the coin you know the designers might feel stifled when when in reality that they

they maybe just are are miscommunicating what they're talking about at any given time and so yeah I think for certain parts of the development a mixed team sort of environment works I especially like it when you're doing a a new feature you you all kind of sit together for a while and kind of get an idea as to as to the beginnings of it and the starts of it and and that kind of thing but then I personally I think that it's better if the if the the the programmers can be isolated a little bit so that they can get a little bit more more uh of of that deep focus that they need to do their job the two group groups have very different goals when they're making games as well design is searching for fun and they're searching for that consistent player contract they're trying to find that set of rules that they can limit the player to and and and see how effectively they can sort of maintain just that that that contract with the player versus the programmers are looking more for performance scalability

and maintenance of of the overall product they're not really talk they're not really thinking about this particular game they're thinking about uh um code in general I think both sides have Simplicity on their on their on their watch word but I don't know that they mean it in the same way and I'll talk about that in a little while part of the re part of the thing that I wanted to show you guys was um on Hearthstone um the the designers and by designers I mean the two designers were sitting in in a particular spot and right between them was a series of posters that they had up called the design pillars that that clearly stated the the the goals of the Hearthstone design effort and I wanted to show you guys these um there's game for everyone keep it deep make it physical great flavor play fast and win or lose the game should still be fun so now if I kind of go back over these

again you'll notice that these are very colorful they're very flavorful um they give you a a decent idea as to what hearthstone's tone is supposed to be like it's it's its overall attitude and and to a certain high level extent you can kind of see the game that Hearthstone is supposed to be just just in these in these pictures now I want to show you the series of posters that were sitting on Bob Fitch's desk the the the lead programmer and these are the the programming pillars in the ex 7et away from the design pillars solve the problems you have fast doesn't mean sloppy keep it simple know how it broke it better work leave no tracks play the game you're making and use the right tool now one thing you should notice on these is that these have nothing to do with Hearthstone in fact

these are the exact oh excuse me these are the exact programming pillars that Bob Fitch has used for 20 years um these are about building tools and about Building Systems and about working with the other programmers leave no tracks um and and so the the difference here is that one group is very much thinking about the game and what it means to make this game whereas the other group is very much interested in the process and what it means to do the process now how do these different goals and motivations lead to success what what is it that about performing these goals and motivations that actually give satisfaction down the road to to these groups I mean obviously you can tell they're they're fairly different right for the designers um fun is fun right but but if you can maintain a a contract and maintain

Simplicity you're talking about that game that's easy to pick up and difficult to master you've you've made an accessible game that a lot of people can learn that rule set and and really dive into whereas the programmers they've won if they've kept the bug count low if they've made intuitive code so that an additional staff that comes in can can can jump in and and help out and and if if there's no crunch that's how they win and so you can see where sometimes something that the designers want that will actually give them the win is exactly the thing that might cause the programmers to lose what they considered to be the win and that's that's a big source of of of rub right I think that the this the common thread for for the two to to win is is is the word Elegance but even then I think they're thinking about it in two different ways I think when you have an elegant game that's where you you have the minimum set of rules so that you have depth in your game but but it's not so many rules that

it's that it's complex it's it's accessible still whereas in in programming Elegance means it means the code is clever but not in an unintuitive way again because that's that's a that's a strength but it's it's clever in such that you get a a surprising jump in performance or a surprising jump in optimization of space or something and so when the programmers say Elegance they mean the code itself is elegant not the game which is what the designers are talking about again there's sort of a different tack so how do we get these two groups to work together um they're very different people and they have to be very closely associated and and how do we do this I think for me it's all about Beginnings it's all about when your game first starts especially with new staff um you you have I like to use a two-part process to to sort of jump start the process of of this connection first I I like to call it the pre-prototype um when the design has

been gone long long enough you've got a nice paper prototype you've got a good idea of the of the rule sets that's when you bring the design in or excuse me the programmer in and that way you can get everybody on board and on the same page as to what the the the design is going to be you can start the buyin process and more importantly you can actually at this point essentially teach the programmer how your brain works how you perceive this design problem how you perceive the what are the important bits and what what are sort of not the important bits all of that um is this is your time to sort of shine and and give give him insight into into your brain um I like to do this with as many different types of media as I can the the paper prototypes work great um obviously talking doing a lot of whiteboarding um act it out you know stand next to each other and act it out if if if that would make it more clear

human beings have a lot of different ways of retaining information and sometimes you can give an email to somebody and they will remember it for 10 years and other times you can give somebody a piece of paper and they will read it 20 times and they will still have to pick it up for that 21st time they will never it will never stick and so mixed media is a is is super important I mean any any grade school teacher will tell you this right um people learn in different ways and the the the purpose of this uh uh interview if you will is to explore the boundaries of your game space with the programmer right from the start um it gives him the opportunity to push back on your design try and try and find exceptions and and edge cases and and it gives you the opportunity to to explain how the design encompasses those edge cases and and and those exceptions because at this point he's trying to determine an abstraction that's going to to work well to to

encode your your game design and at the same time those exceptions those edge cases might be things you haven't thought of and so it's going to give you Clarity in forcing you to verbalize those things while to to the programmer so then he's going to go off or they is they're going to go off and and do the do the the code and they're going to come back to you at some point with some semblance of a prototype um at this point the the it's it's it's time for the opposite to happen now it's your turn as a designer to get into his head and to see if he got the message as well as as well as how he thinks about things so now it's time for you to push back on on his abstraction and let him explain how his system is going to Encompass I keep saying his I apologize how the programmer is going to Encompass your your um your design how how his abstraction is going to handle everything that it needs to handle and again the same thing happens when you work on exceptions and what have

you him CL the programmer clarifying these things in his own mind while um um we they talk about it is is is a very important step uh part of the reason I'm tripping so hard is because the female programmer from Haron is right here and I'm trying not to be a jerk um he also has a they also have a lot more uh uh idea about the performance of the system how the system is going to play out um given all of the things that now now are known about the program and how it's going to handle data um and so this is where the programmer might give you a uh hey if you don't have to do this all the time it would be a good thing in fact let's make some limitations and some budgeting based on performance numbers that we already know and if if it this is a really good time to sort of start the negotiation process for for the the interaction between the two the two camps um again it's good for you as a

designer to watch out for over engineering the design the the programmer might be making a system that's way too broad to try and grab every possible option and if you notice this and you say hey hey that's that's that's really never going to happen um you can you can give the programmer boundaries that you're willing to live with such that he might be able to uh um simplify things down at at at at the system level and actually get some real good gains and again though watch out for trust fails at this point because if you say something's never going to happen and then down the road you say ah yeah we're going to do that now like that that's a big problem and be prepared for some sort of strong negotiations because this is very early in the process and if you say never at that point you better you better kind of mean it so what I'm talking about here is establishing a connection between two human beings and you know this is this

is met the standard metaphor right because yeah two human beings can link up there is a an easy way to even communicate but there is signal loss um the problem I have with this particular hookup is that it's typically more like this these are these are not people that really speak the same language or think the same way and so you really have to come about it in this way instead um a lot of programming is is is more top down and content is more bottom up uh I think a lot of systems designers also think top down and so there's there's there is some common ground but there's it's a really hard road to do and you really have to be careful and you really should start thinking about things in these terms so that you don't designers love to use flowery language we we hate we hate seeing the the the same word used over and over again but programmers basically love Clarity of language that's it's

actually probably one of the reasons why we deal with computers better than than than people because computers by definition are the ultimate example of clear clear language you know every time you put a sing semicolon in the wrong spot the computer will say wrong and that starts to sort of sound like a lot of programmers doesn't it you know like you you you you deal with that entity enough in your life and you you will become that you know like they they will tell you when you put the semic and in the wrong point and so what we really need to do to establish this connection is is remember that communication Clarity is key vocabulary is actually one of the very few things that human beings do when they form groups to to bond uh uh High School clicks are are about forming your own vocabulary um human beings do this so that they can feel a kinship with each other and and know that they're on the same page it's it's one of the reasons why when Geeks get together and we start quoting movies

we feel more connected to each other it's because that's our shared vocabulary and and if you have that one friend in your group that keeps quoting Monty Python wrong or slightly wrong you he he doesn't get it he's he's never going to be in the group nobody likes that guy and and so when you're dealing with programmers you really have to remember that they are the kings of consistent and clear language because that's what the computer demands of them and the more senior a guy is I think that he can get a little wiggle room and and he can figure things out but the junior a person is they're they're still very fresh every time the computer's slapped them is still like stinging on their cheek and so they they're still in that mode and when they come in and they talk to the designers sometimes they want to sting you back I've seen entire meetings be derailed by a single antonym some designer in the room will say the word

actor when he meant entity and the the pro some programmer will go wait wait wait are you talking about the the the entity or are you talking about the Battle manager and his brain is off in that direction now trying to find the inconsistency it's no longer in the meeting and and and you have to practically apologize to the guy no no no I'm sorry I said the wrong thing and that's annoying I agree but it's something you should be aware is is happening consistency vocabulary is something that really needs to be set up in that pre-production phase where you set a vocabulary for the game and hopefully he'll code the thing using the same vocabulary so that when you talk the consistency stays now during the Prototype phase he's going to come back at you with some naming systems that he's made up maybe there's a scripting language and he's written out a bunch of op codes or maybe there's a a a naming system for the the assets that are going to be loaded into the game I personally as a programmer try to try to have some flexibility in this in in the

Hearthstone game I first brought U the list of op codes for the scripting system to um the designer and they were all written uh in the third person like the player who owns this card was an OP code so that in the script you could reference the player who owns this particular card in that script and the designer at the time said oh I don't think about it like that that's that's that's weird I don't understand that and I and so I said okay take this file and there was a file with all of the op codes that was read read in by both the tool and the engine and that was sort of the the text of the of the of the op codes that was used in the tools because I didn't really care what they were and and he went through and rewrote them and I looked at them afterwards and what he had done was changed them all from third person to first person because when he was writing the cards he saw the script as being the card itself saying what it was so he changed the player who owns this card to my

player and I saw that pretty quickly and I got a good insight into his mind as to why he was re reordering these okay when he writes a script he becomes the card and he writes my script basically and so it was very easy for me then when I would talk to him to use better metaphors to to to sort of get into his mode when we talked however be explicit again this is a Clarity issue right and there certain things that you really have to be explicit about one is priorities musthaves versus would be nice that's that's at the bare minimum I better know which ones you have to have and which ones would be nice I mean obviously there's a priority of the would be Nies as well but post ship is not is not a good priority to say I want to know if it's a musthave post ship or if it's a would be nice post ship because if it's a must have then it might not be a post ship feature I have to take that into account as a programmer before the game ships otherwise there's a nasty surprise

especially if you want to do some content fairly soon after we ship estimates are another big thing that you have to be explicit about don't give snap estimates because programmers are notorious for remembering them forever ranges are a lot better as well because they show certainty if I say a task is going to take me between 15 and 20 minutes I think you're fairly certain about that whereas if you say it's going to take between 1 and 4 days I'm going to realize immediately that maybe the thing I'm asking you isn't very clear because if you can't tell me within 400% time scale then then maybe I haven't been clear and and and I need to talk to you more about what's going on there's some a lot of other types of communication that come up in Game Dev meetings meetings are a big one they they run they run nasty for most programmers I I think I think designers have a little bit better time with them I think producers have the best time with them I think producers actually you know have a bed made out of meetings at

home um and and the big reason is is that the the chunk size of work between the two groups is wildly different I think it might be the same except that programmers tend to have a a leadin phase and a lead out phase because your brain requires a different degree of focus as well as like width width of of of information that you need to sort of have in your head at once in order to do a software engineering task than than a a collaborative creative task and so the the sort of well documented uh uh programmer Works chunk size is about 4 hours and so if you if you have a meeting in the morning that might actually kind of shoot the programmers morning and if you then put another meeting in the middle of the afternoon ouch he might not actually get that much done especially High focused work that day um this is one of the reasons why you really need to think about meetings

and if if they're necessary try and frontload them all those sorts of issues also social setting programmers again you know they vary greatly but in general they're not as social as designers uh uh even even here at GDC I have people come up to me and I'm also another programmer and I can tell you within three words if they're a programmer or a designer that's typically just eye gaze is all it takes the programmer will walk up to you and go hey Brian and that's pretty pretty high percentage of the time uh um they typically don't like being made the center of attention and and meetings can do that I mean I've seen the single most powerful confident programmer I've ever met practically turn into one of these in a meeting hey hey hey hey defensive wants people to stop talking um ongoing Communications are very different as well you really should

I like to do at the start of of of a team I like to say hey do you like emails do you like IMS do you want me to come talk to you in person do you like phone calls because different people like different things and with programmers especially because of that that the work chunk I was talking about there's times of day where this might be varied um they might say after 4:00 please don't come anywhere near my desk send me an email I'm I'm busy and and that might change over the course of the project but this is something that you really should think about because this is the sort of thing that you can really kill productivity completely innocuously um and the last thing is feedback and suggestions um I find that if as a designer you open an idea Zone that it makes it reciprocal it makes it easier to reciprocate as a programmer they will also be a little bit more open for ideas when when the designer comes to them um I love this question this is

something that Eric dods taught me I had had sort of a notion of this but this this is the the most wonderful question there is right when somebody comes to you with some feedback or a suggestion and they start as say Hey you know would be really cool don't say we don't have time for that um oh I don't agree with that there's a million different ways to answer this question but this one what are you trying to fix it does two things it shows respect for the person that's coming up to you with feedback because it doesn't say your idea is dumb it says whatever your idea is your intent coming up to me is to try and make this game better and I see that but it also potentially digs deeper than just their little description and gives you an idea as to what the higher level thing is that they're may be trying to fix and maybe there is something there maybe their idea is stupid but maybe the thing that they're trying to fix is not non-existent um other communication documentation is

a source bot I mean I don't know that programmers do documentation all that much better but we definitely try because we make it part of our process and I think designers try as well but they tend to especially later in the project kind of fall off the wagon a little bit more than than programmers do um so try and keep your design docs up to date uh especially if they're short keep your design doc short um uh our Hearthstone designer was proud of himself because he could get our documentation down to about two pages and that was that was a a point of Pride with him and and I applauded him for it when he did it because that that takes work you know I've I've made uh uh GDC talks take less and less slides and that's a that's a really hard thing to do to boil something down when when we talk about design driven production the the the the

information about how to make this game and about where the the intelligence lies is sometimes spread out in 15 different places how do I make a new actor how do I make a new script for this particular actor how do I what what what do the priorities on the animations even mean all of these sort of process level things need to be documented as well and a lot of times this stuff falls through the cracks and so you hire a new designer or you hire a new programmer and he doesn't know squat and and it's really hard to get this things to keep going and finally content and scripts and much the same way that programmers when when I work with programmers I try to get them to comment their code if I look at it and I say hey this doesn't make sense to me throw a comment in here so that a month from now we know what this means when there's a when there's a bug I do the same thing with contents and scripts um I put comment upcodes into my scripting languages and when the designer goes to check something in I say what does this

even mean throw a comment here and tell me what this means the same exact statement as the programmer it will help down the road and it will also make that communication more clear so both sides can see that things are are are are are sort of even bug reports is kind of a big one because obviously bug report your your designers aren't aren't aren't going to be doing real bug reports however they get the pre pre pre pre-alpha of the game and they essentially are the testers of the pre pre pre crap Alpha of the game and and not only that they're the pre pre pre Alpha of the tools and so they end up being bug reporters in a certain way and so try try to know that this statement is sucky we had a designer on Hearthstone that would love to say this and to a certain extent he was was very systemic with this he would he would do this everything if if if it was his favorite

hamburger he would say this hamburger is the greatest hamburger ever and we used to tease him we used to say he was a Sith because only Sith speak in absolutes and the problem is is that what this statement gives you is a notion that he doesn't feel that that he he kind of feels like this bug sucks and it just needs to go away when in reality yeah of course it does but but I need more information if I'm going to do it quickly and and by not having legist legitimate bug reports and by not sort of being a part of the bug fixing process it it tends to to build that us or them sort of thing when in reality it's it's a cooperation it's two people working together to try and make the same thing it's not an us or them there's some trouble spots obviously um workflow again when you're dealing with

a lot of tools a lot of people get very early on tools and they start working with them and they try to make what they what they can and there's problems there always will be but they try to make do they try to work around the bug and they try to use the tool anyway and a lot of times they do that because there's not time to fix them but a lot of times they just do it because human beings will throw a little duct tape on the hammer and use it anyway we're we're sort of trained to kind of make do but my point is don't don't do this try to tell personal preferences and pet peeves on the current tool sets to your programmers as as quickly as you can um as nicely as you can but as quickly as you can because if they can improve some of these very basic usability problems with tools and with your workflow it's going to not only increase your productivity but it's going to eliminate this nasty little erosion of good will between the programmer and the and the designer uh

um this is sort of like if you're in a relationship with with with another human being and let's say that person let's say that person doesn't lift the lid or or doesn't put it down when they're done it's not a big thing but eventually you hate them so if you just tell them hey this is a pet peeve of mine could you please and if they're a reasonable human being they will go well I could care less I'm just going to do it and and it doesn't take any of my time bang that's the sort of thing that I'm talking about another thing is Discovery and please don't laugh at my picture try to find a good picture for Discovery um surprise asparagus he discovered that um Discovery is a necessary evil when it comes to to design and it's not even that evil right we're we're we're trying to mine mine the goodness wherever we can find it um but this can lead to some pretty hairy

changes in the in the code especially big changes if you can if you can find if you can try and work hard to find the big changes early on obviously that's ideal but that's not always the case so when you come to the programmers with big changes obviously this is this is a time for potential strife and and if you come to them with a a foisting sort of situation that's obviously where there's problems but if you come to it as a negotiation hey remember what we said before we have to take that back but we're willing to negotiate on this and this it it makes it less about accept this and and don't don't talk back as opposed to we understand there's a partnership we understand that we've had to come back on part of part of what we said before to be a true statement and and we're willing to work with each other on it repr prioritization ation is is a little bit of oh that's shouldn't have come up oh never mind um

reprioritization is is is a lesser evil I mean reprioritization might just be there's a demo coming up or somebody needs to see something or maybe an artist needs something quicker because of whatever and so these are a lot easier to to sort of get into the system but but still again try to do it as quick as possible because you don't want to waste work obviously crunch everybody's on tiptoes and and when you have people that aren't social gifted crunch period suddenly becomes a really hard place um so I don't really want to go into this too much but just just just me remind yourself that again you're dealing with the the can and the banana like this is this is the time when the wire might even be a little bit frayed right you have to come at these sort of communications knowing that that that there's a big Gulf to be done here and these trouble spots are really about trust this is this is the the trust part of the relationship um the workflow like

I said sort of slowly erodes trust over time because the tool doesn't really do what I want and if I ask him he's not going to really do what I want and and and I'm going to have just more hassles and Discovery again you're you're you're dealing with the contract between design and programming at this point and the contract part of the problem that I see with this particular grouping is that the contract is a little bit inconsistent um programmers agree on a contract and they actually have to write that contract into code it's somewhat calcified for them design doesn't exactly have that ex same level of calcification they they can feel a little bit looser with their contract and they have a little bit of an easier time to kind of change their contract whereas changes to the programmer side of the contract are actually some somewhat harsh and this inconsistency I think is part of

the rub so finally I want to talk about some Bridge methods that some that are starting to appear in the industry uh I I specifically use use a rope bridge on this because it's serviceable but there are some hazards and you have to watch out and one person with a big knife can kind of cut it all apart so first is a technical designer this is this is a person that's gone either direction right you either have a designer who has a lot of who has who has a lot of of programming skill or or or a a a programmer that's that's decided that he wants to go more in into the design Direction and in either case what you really have here is somebody who speaks sort of both languages and they're they're they're down on the worker side and these guys can be amazingly effective at what they do at not only Bridging the the gap between staff but also by

potentially not being seen by their the other members of their team as being the programmer is telling me to do this or the designer is is demanding this they they can soften the blow by knowing the language a little bit better of both sides however there's there's definitely some some issues they need twice the mentoring and twice the management they technically are both a programmer and a designer and and if they're not getting both mentoring and both management you can run into some of the problems that you can with green programmers and the thing that we all know Green programmers can can cause some severe havoc in a codebase um they can check things in that maybe aren't approved at com in on a weekend with a great idea and and just hack it together stick it in the game thinking that everything's going to be great um we don't like this even when the programmers do it and we certainly don't want anybody else doing it especially

somebody that's supposed to be there to help us um all of these sorts of things and it's not just sort of rogue rogue Behavior it's it's it's also just inexperienced programmer things like poorly optimized code or or potentially hackable code on an online game things you have to think about also again you have to take care when you do have designers and programmers and Technical designers involved because that tasking they might feel like somebody's stealing something from somebody or they might not know who's who's supposed to take a particular thing and so there's a little bit of tap dancing when you're dealing with with cross-disciplinary groups simply because of that I also don't think that technical designer should be the main designer I think that the main designer should have only the player's needs in mind he should be the advocate for the player and and technical designers whether they want to or not

are also worried about the performance and the maintainability of of some of their stuff and and that's good that's what we want however it it causes them to be a little bit more pointed in that in that direction I also think that their cross-disciplinary staff is absolutely the future of some of these features we can't we just can't have people that don't have both of these things the art world has already embraced this directly with technical artists who who can code shaders to make special effects that are in every game out there just about um the the we're we're a little bit behind them but but that's that's the way of it but but only sort of obviously you have to deal with some of these issues and it it's also going to be a culture thing as far as the the corporations themselves right now there is the big three of design track or excuse me of of career tracks and people that straddle the fense can sometimes have a hard time getting promoted because if they don't have two

managers that know everything they're doing in an effective way it's hard for a design manager let's say with a technical designer to really know just how much value the the coding work that a that a a TD has has put on into a project it can be difficult um you know for for HR in general to even hire one uh on the other side is sort of the the the management version which is the Dual class creative director this is this is obviously a a guy who who is sort of like a technical direct technical designer except more at the management level and he knows enough so that he can push back on both sides he can actually be the the person that maybe does the mediation and the management for for your cross disciplinary stuff and and and sort of have that ownership Clarity that that the underling didn't have but because he needs to manage both sides he ends up not really being able

to do much work and so you have a very powerful person ending up being just a manager and this is a classic problem right but but it's something to think about if you're going to go in this direction so finally just remember that programmers and designers are very different people they're they're not just different people their their their brains are wired in a very different direction and this isn't a bad thing though this is a good thing because the best systems and the best games come from a melding of design and engineering design and engineering's way of thinking is is very orthogonal they're coming at the the the issues from very very different directions and this push back is what causes the systems to be as good as they are but because they're so different you have to build that strong relationship and like in any relationship communication is the heart and trust is the soul you really have to come at it in this direction and you have to realize that when you come to a

programmer with a discovered task you may be killing his ability to succeed at this game and that causes trust to to be damaged and and it might fuss with the entire team cross-disciplinary staff can be super valuable if you can get over the problems and just remember every day that we're all on the same team and we all want to make something great we want to be something we want to make something that we can be proud of so that's that's my talk thank you is there any questions to the mic what does it look right now now uh for those designers who are straddling the fence to get into the uh industry as

a firsttime hire well that's tough right because you essentially you're essentially at that point interviewing for for two jobs that nobody knows if you can do you know designer I I think it's very difficult for just being a a designer to get into the industry much less telling somebody that you're a technical designer I think I think if you you know have have put out your own indie game or something or or something like that as a programmer that you could maybe say that yay I I was the designer and the programmer on my this project it did it did pretty well check it out that that that might be an inroad but shy of that I think that's a very tough road anybody else yeah oh how uh I love the idea that hearstone had a two-page design doc could you go into some more details about what that looked like like for example was there just one line for each

mode um no it was more like I mean probably but but but it was very boiled down to where none of the I mean the thing is is Hearthstone itself is a very simple game right so so the design dock for Hearthstone was the very boiled down version I mean you don't have to have the design of all of the cards when you can have a design that just shows what the keywords mean what the sort of game Flow looks like and and and just just a few other things you can kind of fully describe Hearthstone very quickly I mean obviously I don't have the two pages or I or I share them with you because they're they're pretty pretty kickass yeah I'd love to see it if you ever put it out someday thanks yeah hi Ryan yeah hey well H I am a programmer to designer so I'm kind of the other way what I was wondering if if this I mean how far do you go before starting to look for help

with other parts like for example the main issue I have is with the art department they are like aliens to me so it's kind of difficult to start talking with them without them just going into really Ary kind of terms and so go to them and say that say Hey you know what I really need understanding with you guys and and you guys are aliens to me can we sit down and have a conversation and get a good vocabulary going I mean exactly what you just said to me go say to somebody on the design side and say hey I I want to make better games and I know that to do that I need your help but right now you guys are speaking simlish and I don't even know what you're saying okay and and just that's how you do it thank you no um so uh first to answer the other person's question we do have a lot of technical designers at Maxis and they always start as Engineers because they have to prove themselves as Engineers first and that's that's the only way

that I've ever seen it done so I I would hire I would go into try and be hired as an engineer and then switch to design um my question is uh if you're in a state where uh because a lot of what your talk is saying is about building this sort of trust from the beginning if you're in a state where the trust is already damaged um do you have any tips for going back and attempting to repair that yeah I mean not to extend the the the the marriage counseling metaphor too much but literally you need a mediator and and until trust is is repaired communicate through the mediator so that things can be couched and and obviously the reason that the trust is broken is because there's some issues there right there's some headbutting there might even be egos involved that kind of thing and you need to add another person to the equation until things are smoothed out and parameters are set and boundaries are set and that that relationship is more serious right and

then you can go back to to to to working together but that's really the only way I've ever found but who who do you find that is that person right like who is that person that both sides can put their trust into and that's probably the hard part right that's the hard part that's where you need that cross discipline staff I mean I've had the luxury of being kind of that person on in a lot of companies I've worked at I've seen it I've seen other people doing it uh uh a lot of times if if just the lead designer is is is um what's the word I'm looking for veteran enough is is senior enough he he will have worked with enough problems that he can that he can that he can mediate a little bit but but you need that you need that mediation I don't think that those two people typically can do their workload and repair that relationship by themselves cool thanks yeah hey if it's interesting

for designers to learn scripting to get into programmer's head uh know since it's all about negotiation what should designer ask programmers to do themselves you know to get into our heads well I mean that's that's kind of what I was saying you know the the the start of the process of the game in in just the description of how the Prototype is going to Encompass the design you can hopefully get into that programmer's head by asking him questions like oh you did it this way because and and he might say well it's because if I don't do it that way the performance is on10th and then you go okay now I know why he he did that particular decision um you know any anything from you know just just why but but also just how his particular brain wraps around a particular problem you know that that's why I I mentioned that process is because getting into another human being's mind is a very difficult thing to do and using the game that

you're working on as the tool that you do that with is probably the best way I've found to do that okay thanks yeah hi um so I agree with your experience that the programmers are very much focused on the performance of the code and the designers hold that space of owning the player experience have you had any experienced any success where early on by hopefully getting the programmers more into the player experience because they are creating the player experience that it kind of helps with that communication gap and if you have any suggestions for doing that because oh absolutely I mean personally personally the the I have always loved the notion of of feature-based teams so so when you have a team coming together the reason they're coming together is not because they're working on a game as opposed to working on Elizabeth let's say for for BioShock Infinite the the people that were on the Liz team they called themselves that the Liz team and it was the the animators the programmers

and the designers that were specifically working on that feature and and I find that by coupling in in that feature space and owning a particular feature you you you narrow down the amount of information that you need to be sharing and so there's deeper understanding of that particular thing and so you get that closer that deeper level of communication and there's higher buyin then too right and so the the there's probably also a larger Avenue for hey can you do this hey could we do this kind of back and forth as well um I'm an engineer and I've often had either artists or designers come to me with a very specific thing that they want and everything they say I want this and you're and you're thinking I my response to your what want to fix it question and everything is I always come back with what is it you're trying to solve because they often have a very

specific idea of what they think they need to solve their problem but it often isn't the actual solution or the best solution in the engine so you always need to make sure that you ask because otherwise you have this miscommunication and everything and if you give them what they explicitly asked for it often doesn't work the way they expect it agreed yeah I mean and that's then that's why I tell people to ask that question yeah always ask you know what is it you really want I mean don't tell me explicitly what you want me to have done tell me what it is you're trying to fix and I may have a better solution for you yep yeah and and in the same vein if if that is the case then then maybe you need to do a little bit more education exactly usually of your designers because they just didn't even know they could do that already they didn't understand the engine enough and everything to know what their op options were what they should have done very cool so earlier you mentioned mentioned the uh communication between you and the designer between the third and first

person uh for the scripting are there any other really good examples you can think of for Hearthstone specifically of good communication between programmers and designers well I mean remember I was doing all of the gameplay and AI programming for Hearthstone pretty much and one guy was doing the vast majority of the design of the cards and that kind of thing for for for the design and and to a certain extent he was a technical designer because he was actually coding the script on those cards and so there was a ridiculously tight relationship there I I I I talked about this in the in the Hearthstone thing is is that there was a a specific mandate to have an intermediate player be the the base goal for the AI they just they didn't want a high level player they wanted an intermediate player and so I spent you know a month and a half just sitting with the designer trying to figure out

what an intermediate player was and and and not only with him but with other people that were playing so so that we could get that idea and then going forward a lot of times when I would get a bug I would come over to him directly and we would sort of discuss it together I found that by including him a lot in the solution to bugs in new features that we were thinking of adding like right from the start in doing that inclusion not only allowed him to know the process more under the hood so that new cards coming in wouldn't have the same bugs or or as well as I knew things that he hated he was like well we haven't even fixed the last time we did this you know what I mean like like I I would get that feedback very very quickly I think that it's more just a I can't I can't the the more tightly coupled you are the more tightly coupled you should you should work you know you

should get up out of your chair and go ask that person as much as you can right yeah I prefer the personal communication too so thank you thanks anybody hi uh so you tell uh uh hearstone design do is only two page long yeah so probably programmers in blizzard specifically hstone have some flexibility like you don't specify uh designers don't specify it's uh really detailed and uh only if some issue appears they tell programmers to change it like is the programmers uh flexible or they have clear specifications but not written on the page like in your work on AI probably uh how many decision how many design decision you made the for example actually the the the AI and

Hearthstone was largely driven by the design choices that we made I mean everything from the actual techniques that I used to to specific game plays that the AI would make were were sort of discussed with design and it was very experience driven so I mean yeah it wasn't all written down but a lot of that was was explored discovered work that was coming in like as after Alpha anyway and so that that wasn't something I would have ever really wanted written down and there was not really time it's not like programmer decisions it's it's a result of communication yeah yeah I'm not I'm not exactly sure what your question was uh let time be more detailed uh the problem is uh you can as designer you cannot uh describe the feature in all details of course in in all uh possible things uh uh that might happen so a

programmer makes its own decisions its own design decisions when it WR it how you I think I see what you're saying so so in what you're saying is a a two-page design basically leaves the door open for a lot of programmer decisions and in in this case maybe you're right that the fact that he could have a two-page design was because I was very collaborative with him and didn't do that however um my read on the two-page design document is just that it suddenly becomes something that's legitimate and maintainable and and that you can like update whereas if it's 100 pages long nobody's even going to open it that's that's my point with that yeah um so I relate a lot to the um the bit about tech designers needing sort of twice the mentoring um but I'm wondering about like the effectiveness of a pure engineer as a mentor for the tech side or like a technical designer as a mentor yeah I mean I mean there's a

trade-off there hopefully if if you've got a mentor position they've been in the industry for a while I mean if they're doing gameplay or AI they've done a lot of design anyway because there's no way to really do AI without being partial in the design space you know you're you're crafting an experience using AI techniques you know and and that's that's primarily a design processing anyway so so if you have senior staff they've either they've either been in games for a while and so they can they can have a little bit of that you know I mean everybody is is not a zero or a one right everybody kind of is somewhere in the middle and so I agree with you if you have a very dry programmer you maybe shouldn't have him be re reviewing that guy's stuff but there's very few of those you know what I mean they they tend to not be managers in the first place right because managers have to deal with varying levels of their staff so true okay all right thank you thanks

[Applause] guys