Far Cry 4: Gameplay Team Workflow, Iteration and Philosophy

[Music] all right good evening everyone welcome to far cry 4 gameplay teamwork flow iteration and philosophy now I was asked to tell you guys to please turn off your cell phones and rate the session after we're done now that this is done let's get started so first of all I'd like to introduce myself my name is McConnell dystonia I graduated from a credit point technique democrat in 2009 software engineer I worked in some smaller games early on in my career I joined far cry 3 as a core gameplay programmer where I worked on navigation combat and takedowns and all this stuff now in Far Cry 4 acted as a lead gameplay programmer which is what I'm here to talk to you about now why am I doing this talk I'm not gonna lie it's pretty cold in Canada right now I just wanted to get down here in the heat I mean anybody else in the room coming

from a like a really cold place yeah ok so I'm not the only one who had this idea ok great I like it all right all seriousness though the reason why this talk is so over the course of the last 5 years on the Far Cry game play team we have we've really refined a production workflow and we eventually came up with something that allows us to iterate very efficiently and be quite flexible it's kind of almost as if we were a small team even though we're a very big team now this is kind of a lot of stuff going on that I'm gonna be talking a little bit about management a little bit about production some game design what you should get away from this presentation is when you leave you'll have a really good idea of how the gameplay team on Far Cry works how we operate how we structured how we build their features really from start to finish and hopefully you guys can walk away with some ideas maybe that you could try on your own projects now before we get into the to deep stuff I just want to clarify some things just to make sure we're on the same page I'd like to talk about

what the Mandate of our gameplay team is so the very first things I made this stuff is very in-your-face right so the weapons the vehicles all the player abilities and the skills such as the takedowns or if you heal yourself so all this all this nice stuff interactive objects like the new grapple tool we introduced in Far Cry 4 and everything that is destructible objects actually the game systems behind them and also the assets and so basically this is all part of the gameplay team mandate there's also the stuff that's not as in-your-face so we did the arena in Far Cry 4 all the player replication the the system's that are underlying such as the saving the input systems the player replication the scripting system basically what I'm trying to get at is it's kind of a it's kind of a big mandate we do have a big team but we still need to be structured in this way to be able to really pull through now this is the only slide where I'm going to really talk about project structure and this is for you to really situate what the gameplay team does and how it works with other teams within the

project now we'll see here is our project is really divided in many different teams and the different teams I've ownerships over different areas of the game the gameplay team being one of them you now know what the mandate for the gameplay team is and there are other teams that we interact with AI is separate from gameplay in our case I know several productions like to have them included together in our case we separate them we have missions teams which would be the guy that would be crafting the missions for the game and the presentation team is what I guess would people typically call UI so they do menus HUDs Maps and all this fancy stuff one important thing here is that every everyone a little steam really have definite opener ship over their various areas of the game now in terms of gameplay team structure if you look at the diagram on the right you might think okay this is this is a fairly standard organization you know so your project has management and then you have the different departments but this is not this is not a project structure this is really the team structure so the key

thing is on the gameplay team we have our own animators we have our own programmers our own game designers we have our own testers actually well it's dev testers I'll get into the details as to what they do later on so we have all our resources and what's great about this is we're really masters of our own planning we don't have to wait or rely on an outside department or if there was for example an animation department that relies on that actually serves the whole project you they're really busy working on something else for another team then we can't necessarily have support so if we have our own people we're masters of our own planning can iterate very efficiently if I need help from animation I can just poke my buddy who's right next to me is on the same team hey could you unblock me on this and then we can get the ball rolling really fast now like I said one very important thing is the team really has ownership over a gameplay so we decide the gameplay what goes into the game and I'll get into the details of how we do this I want to talk about the floor plan a

little bit and this sounds I guess this might sound a little bit goofy but I want to talk about this because it makes a very big difference in and how fast you can iterate and what your production workflow is going to look like so what you see here we have the various disciplines within the game play team just by the way I might say game play sell every now and then selling team really the same thing I just might you know say one another so within the team we have the various trades like you see at the top that would be the windows and we have meeting rooms down there so the key thing is that people are seated together all in the same area now what we want to do is really try to make this with the people that interact the most together to be seated nearby a very good example would be game play programmers and game play animators we want them to sit back to back or really right next to one another and as ridiculous as this sounds we found that sitting people just right next to one another instead of like five seats away will really significantly increase the production workflow because they're essentially but like you're always more buddies with the guys sitting right next to you at work you spent like 40 hours a day your buddies

and you talk and it just becomes very natural to share the information now how is this is this is not necessarily the best floor plan that we've ever had the reason behind this is like you can tell that the different disciplines are so a little bit segregated like programmers a bit together animators a little bit together there's so thing I guess think a little bit more Christmas tree and a little bit less Megazord I was asked I was asked by someone how do we overcome space issues on a production floor and really the great thing about having everyone working on the same Rufe within the game play team is our dependencies are really within the team if you have 25 people on your team all you really need to do is to secure an area of the floor space that can contain 25 people and then you kind of manage that way now obviously a project wide like I was talking earlier we do we do talk and we do collaboration with

various teams within the project so what we try to do is really book the team's that interact the most together to be near one another that's not always possible obviously because you're always going to work with like five six ten different teams and nope you can't always be right next to one another some some gameplay we try to be closer to the UI team and the AI team because they're the ones that we interact them else with now I want to talk about team philosophy this is this is a little bit of game design I guess and a lot of projects would call this design pillars now really the underlying idea behind all of this is love the player and the four pillars will really illustrate that the first thing is embrace systemic what this means is so when you go to e3 and you showcase your game and the guys showcasing the game will walk up to an elephant get on the back of the elephant and start like ramming vehicles hitting NPCs the player when he buys the game or one when he plays the demo he's gonna be both like he's gonna expect to be able

to do this in the game you don't you don't want this to be just like just for just for show same thing for the vehicle takedowns is a new feature that we added where you're driving right next to another vehicle you can jump aboard I mean kill the driver eject them then you could take control the vehicle we could do them as like one time sequence it would be cheaper but we really make this choice we'd rather have less features but make them work throughout the game because this gives this gives you a very rich experience the second key point is really to respect the player choice the biggest example I can give for this is our gameplay loop which really illustrates you know you have you can always attack when you attack an outpost you can always go the stealth way so you can do takedowns do some silent weapons but you can always go guns blazing with explosives and vehicles and this is this is some choice like that some players like to make you know times they'd like to go stealth sometimes he likes to go guns blazing and we really try to add more features to respect both areas and whenever

possible we want the player to be able to make his own choices the third thing is gameplay first now this is kind of a big buzzword a lot of people are talking about this but what does this really mean what it means for us is that the gameplay is more important than the visual quality of the game I say visual fidelity I guess would be a better way to put it I have a very good example for this one in the vehicle takedown that I just discussed we found that when we were tweaking the feature like I said we want we want it to be accessible we want the player to be able to do it throughout the game and what this means for us is we had to have some pretty big interaction angles and interaction distance because if it's very to narrowing always looking for the perfect scenario the player is always going to try to do it he's never going to be capable and he's gonna think it's just bad in this case what it meant to make this choice to really push the gameplay make sure we have these opportunities is that unfortunately the feature if you look at it in third-person it looks kind of goofy now I don't know if you guys play the coop but if you are driving a

vehicle and you see your buddy jumping outside of the vehicle and jumping another one it warps but it's a choice that we make because to us the feature being available and just generally good on the gameplay side is way more important and having it look perfect in all scenarios lastly quality matters again sounds very obvious but what it means is as soon as we start discussing features very very early on we really focus on making sure that we can realize this feature to a full quality and we are dedicated to it when we have a feature in the game what we do is if it takes longer because we want it to push the full quality what we'll do is we'll take the time to really push it to the right quality so it doesn't clash with the rest of the game and will actually maybe scope down on some features or even cut other features completely because we want what we ship the game with to be very solid the next thing I want to talk about is our development process is very this is how we work and how we build the how we build the game now we have a mix of bottom-up and top-down what I mean by

that is so there are sometimes some requests that come from from higher up for example the in Far Cry 4 ki raat is a very vertical world some big mountains and there's a lot of verticality to it as opposed to Far Cry 3 which was a little bit more flat now what this means is we were requested to have some more tools to really explore this verticality and what the design in the gameplay team came up with is two new features amongst other things the first thing would be the buzzer so that's the one-man gyrocopter that you can you know navigate and go anywhere which is a feature that people enjoy so far and the other thing is the the grapple hook which is another way or another more fun way I guess if you needed to climb a very big distance instead of just having ladders you could have grapple hooks so this really came from up from from bottom I mean but there was initial requests that came from top now the second point is everyone is a game designer this is we really strongly believe that everyone on our team in the gameplay team our

gameplay experts and we want to leverage this resource why limit yourself to just having two or three game designers decide what the games going to be where you could have a team of 30 people all putting in what like their expertise and like this this is essentially what you want right so we have a lot of great examples as in a question that we asked to people a lot is what would you like in your game the grapple hook initially was supposed to be just a vine you would just have an area where you would just plug the hook and then you could climb much like you would do with a ladder but the process of the programmer and the game designer doing a lot of back and forth between them and challenging each other eventually made it made it to fully fledged physics systems which is really cool now promote ownership and impart a team is very much in that same line of thought a question we asked to the guys is is this is this fun to you when you work on a feature it's not a matter of just implementing the feature at the request of the game designer no it's it's your feature it's your baby it needs to be awesome you need to think it's awesome because if it's not good enough then is it gonna be good enough

for the players so really push for the guys to have ownership and like I said if you go to e3 and it's your feature and you had ownership on it and it goes on stage and you do I don't know you get on the elephant you start ramming vehicles I can tell you when the crowd starts cheering that the guy who worked on the elephant is going to have chills finally lots of iteration I mean we had to read a lot I guess we iterate a lot more than we'd like to admit but this is a direct consequence of being heavily focused on quality and we want to ship like our features to be very good and what this means is well sometimes you need to iterate a little bit more now to illustrate all these points I'd like to walk you guys through the eight steps of a feature so it starts some really the an idea of a feature all the way to a ship product so that's good of the first step the first step is really an idea now the thing here is you know everybody has cool ideas but what we try to aim for is

ideas that really have a good a good game design purpose two examples would be oh clickers losing batteries so first thing would be for example the buzzer in coop you have this one man gyrocopter and we added the coop the the grapple point on the gyrocopter so that at any given time instead of having to break the pacing of the game have to go down and you stop the gameplay pick up your buddy go up well at any given time you can just fly by your fun can just like grapple so yes it's a cool feature but it helps you really maintain the pace now I mentioned earlier about embracing systemic and one of the great consequences of really embracing systemic is that since these systems are made to be robust and works throughout the game we can do these kind of things like really quickly instead of taking weeks this took us just like a couple of days just to tweak the minor details so this is this is definitely a big win another great example of something that is cool idea that has a game design intention is the vehicle takedown now we made a big effort to really merge I

really try to yeah I'd say merge I guess vehicle and combats one of the thing we added was the drive and shoot for this regard but the vehicle takedown is another great one where you have this really strong action within a vehicle and it's not just driving and it has another purpose which is again instead of running around the world if you have a broken vehicle you don't have to you don't have to necessarily get out repair it and get back in and breaks the pacing you can just find somebody your vehicle take down and you recuperate his vehicle which is in great condition designers on the team are required to be very technical and this is great because I don't think I don't think I've ever heard in the past five years on far cry I've never heard somebody or a game designer say just do it this way because I said so this is not the culture that we promote like I said in a culture where everybody is a game designer what happens when the game designers disagree with the programmers and the animators is these are really great opportunities for your game designers to coach your programmers and your animators on really what makes great game design and vice

versa you want to use that opportunity for your programmers and your animators to to teach each other and really try to grow this this knowledge we kind of expect everyone to try to have this curiosity and really push it forward the second step would be the gut checks so once you have your your cool idea what you want to do is really go around the floor talk to the people and see what they think right so we try to eliminate the crazy ideas the great thing is we try to hit for obviously higher return and investment not buzzword and what this means is by including the people all the programmers they'll be implementing the feature sometimes yes you're going to cut some ideas that might be too crazy but sometimes they'll come up with some great ideas they're actually very quick wins because they're the ones that have the technical expertise to build those features now you see this nice very sweaty arm armless arm shake thing what I what I'm trying to illustrate with this is at this stage I think it's very very important to have a very very strong

person argumentum for game design and a strong person on the production trying to you know hold game design back because what happens is if if your game design really overpowers production you risk having a game that's yes very good but that might never ship because you're always going to crazy ideas and on the other side if you have production that really overwhelmed game design and just like no we're just going to do this because it's the only thing that's safe and fits then you risk having just a very bad game because it's not design driven enough I can give you some examples some features that were that were cut at this stage of production well I'll give you one on Far Cry 3 we had vehicle.well water take down sorry so when you're in water and there's somebody you can stab the guy whatever and we wanted to make it more systemic where if you're in water at Navigant at any there's somebody else in the water somebody else nearby we'd like to be able to do these takedowns we chose not to do so because I mean honestly kirat doesn't have that much water and we felt that the time invested there was not that much return on investment because there's not going to be that many

opportunities for the player we'd rather you know spend our time to something else they'll be able to be done throughout the game that might feel more epic third step would be the episode process acronyms yeah now FS o stands for feature sign-off I could I could probably do a whole talk of a now around this but I'll go over it quickly the idea is the feature sign-off is a document typically written in Excel where the game designer will go over the various things that a feature can do and if there's any risk potential risk there you want to highlight them and this document will be sent out to all the various technical leads of all the teams on the project now remember the first step before I said gut checks where you go around you see people for example in the game play team but what this is really great at is because this document is sent out large and people meets like all the various technical leads of all the teams on the project will meet to sit down make sure that they go through every line what it does is yes on a game play team we do have the technical expertise for the gameplay stuff but we

might not know what everything means for AI for example if we decide to add elephant riding what does it mean for AI if Anaya walks in front of a player on the back of an elephant what is he gonna do you're gonna be scared isn't gonna be Shu the player should the elephant and then if you drop the elephant in the middle of nowhere and it gets an AI regains control over the elephant I was he gonna be able to pass back to like a proper proper navmesh so by having this process which is formalized and forces us to really include everyone on the project these you know have these bad surprises later on everybody knows what's what's happening now the next step is the prototype stage which I'm sure you're all familiar with there are certain things about this is our prototypes actually so it's not necessarily step 4 it could be step 3.5 what I mean is this process is not entirely linear some steps will happen at the same time and we're comfortable doing this starting the prototype as the FSO process and that is not because you know we have experience and

eventually you don't have these crazy surprises anymore we rarely completely cut anything anymore so our prototypes have functional assets so we don't just for example if you want to throw a knife you wouldn't just play like a random reload animation that would toss a green cube we like to have some basic assets and it's very easy for us to do so because like I explained earlier within the team we have all the people that we need to really fully realize the content now one thing you're going to talk you're going to hear me talk a lot about is de-risking first when we work on feature is when we do our planning we always focus on de-risking so much that we'll actually prefer de-risking lower importance features then actually iterate on high importance features that don't have risks anymore this is very important now there are various types of risks you get realization risks such as how are we gonna make this look good game design risk this is gonna be fun how this is gonna work technical risk this is gonna work with our engine within a reasonable amount of time balancing risk if I have

this new weapon like the mortar is it gonna make the game too easy am i you're just gonna break the game whenever I use it so these risks need to be addressed first before we move forward and this is what we try to do with a prototype and when the prototypes in the game it's also a very good meet for discussion when you have something in the game it's concrete people can can look at it feel it play it and that's really great fuel for discussions now let's look at some features in their prototype stage I hope this works ok so this is the drive in truth now you'll see this is very very basic right so there's no look around you just aim forward the hand on the Left is completely like badly animated but this this gives an idea of the intention behind the driving shoot now this feature is the buzzer obviously the asset is obviously very placeholder with a nice checkered temporary texture and there's not much stuff going on not much look around the inputs are very clunky but still I mean you can get it you can get on the buzzer you can fly around lastly the grapple again very very basic

where you just tie them onto an object and when you get to the top you leave very little realization so that typically that's what our prototype stage look like so at this point we did a prototype in the engine and we have a good idea of you know what what's there really what's the potential for the various features so what we do at this stage is we scope so we discuss so what works what doesn't work we get some feedback and it's a great it's a great time to really start doing play tests also when you're at the prototype stage so we do two types of play tests so we have the typical play tests will you'll grab somebody on the production floor and just say dude I'd like you to try this feature you know somebody that hasn't tried it and you can really try to observe the person so you'll see what he's doing with it and see what's not understood mainly and the other thing we do is that Ubisoft we have a we have a play test lab where some people from outside the studio will come in and we'll try our unfinished games and then the biggest thing here

you want to get those guys involved as soon as possible if you have some big features that are going to be iconic for your game you want to get this tested as soon as the prototypes phase you don't want to wait until the very end right you want to de-risk this stuff and the guys at the play test lab are really good at aggregating all the feedback and really giving you tips on what is that you could do to improve certain features and de-risk right so I could give you some examples at the stage of a of some features that were that were cut unfortunately when we got to the prototype stage the first thing would be the vehicle takedown from boat to boat and the reason why we cut this one is because we realize when we did the prototype for the vehicle takedown that the animations were actually very complicated to do like several NPCs they're very long so there's a significant cost there so to scope down on this feature we actually remove the boat to boat part and this is really only for animation costs because the code was there it was working but then again little return on investment there because there's not much water in

curette so we try to be smart about it another thing that we caught at that point is we had a shooting gallery now you know what shooting galleries are many games have had them so you have panels and you shoot with like weapons and the reason why we cut those again the code the prototype code was working is because we figured that it was gonna be so long the level designers to do all the setups and all the very various areas of the world and all the various weapons and honestly it's not it's not a big innovation it's not necessarily that fun it's not that far try so we decided to just get rid of it now the next step is the alpha step the Alpha for us it's it's really a roadmap to the final quality of the game so once you get to alpha all your major risks should be eliminated and when I say risk again I'm always going to try to really push to de-risk first sometimes what we'll do to D risk is we'll create what we call strike teams so our strike teams are composed of you know many people and sometimes we're gonna have multiple people of the same trade trying to de-risk the same

problem there it's happened two times like two significant strike teams that we had in Far Cry 4 was for the elephant riding was one because like you want to you want to be able to drive the elephant but you still wanted to feel like a living animal this is this has a huge set of problems of their own so this was one of strike team that we did and we really try to shield these people as much as possible so they can really blitz on making sure that all these risks are eliminated now one of the peculiar things about Far Cry is that we really try to have all the features alpha at the same time and the reason for this is we have a very big feature matrix so the more we add features the longer they are to make really because like I said earlier when we expect the player to when the player expects to be able to do something we want to give it to him right so again what this means is the more you add features the more you have dependencies with other features and these are very very hard to predict so before we move on to polish into beta we try to get everything in the game in

alpha and we want to let this stuff really marinate in there so let's take a look at some features well the same features as earlier in their alpha stage so first things should be driving shoot yes now you can see it like animations are okay you can look around you can aim on the right you can you can kill some guys now the aiming seems very difficult but now the gyrocopter again you can shoot now it's hard to tell because you don't have the control in your hands but the controls already much better you can move around and the grapple you can tell that right now it has physics you can swing around it's not just like a straight rope that doesn't really do much so at this stage the alpha like I said you have a really good understanding what the feature means for the game what is it gonna be what's the potential and all the big risks are no longer there really now you're never gonna guess what comes after alpha anyone beta yeah okay not bad not bad so uh the particular thing about our beta is that it's really as far as most

features will go the bulk of our stuff is really only gonna make it to beta and we're gonna ship in this stage and this is actually a very nice comfort comforting thing where you're trying to ship you got bugs and everything and you know in the back of your head okay all the stuff that we have in beta you know we can ship in this in this state and that's always good to know earlier I did mention that we have for the prototype that we have several people working on a like the prototype at the same time like you want hard assets animation assets and programming and we really rate everything together for example if you work on well I don't know on the buzzer you want to improve the animations you want to make the mesh look better you wanna have the programming so I know I know some people I'd like to push for example the programming all the one until the end and then just Waits whenever animation is available to really polish the animations we avoid doing that because you always get kind of bad surprises there where animation starts doing polish for example when you realize that you need some cold support you always keep going back to the

features that you thought you were done with and again this is very easy for us to do because we do the planning for all the people on the game plane team including the artist the game designers the the animators and programmers now this page is a project it's very very important to take a close eye on the play test results during the heat of production we actually have play tests from like people outside of Ubisoft coming to test their games we have that every two weeks and if you keep a close eye on the play test results like you're gonna know if one of your feature doesn't work for example for us the drive-in shoot is one of the ones that really went until the very end where okay it worked like as devs we worked on it so we knew we knew it was okay but there was a people had a really hard time driving and shooting at the same time being able to hit targets I'm not hitting trees in the process so by keeping a close eye on the play test results you make sure that whatever it is that's in your game it's solid if people understand it and it's really important that they be kept in the loop again Rhys cope is necessary we don't

just Reese go early you're on weary scope throughout the production because we want to make sure that we don't dig ourselves like in a big grave and a huge pile of stuff that we can't get through let's look at some well the same features in their beta stage so the first thing is to drive and shoot now you can see that it feels like wow it starts to say because you have to control again but it's pretty good we have the auto drive that's going to prevent you from like hitting trees and all the stuff you can look out the window we have some nice aiming assist so this is this is pretty good I mean we could probably ship with this aside from some minor bugs you know same thing with the buzzer buzzer at this point you can you can shoot you can navigate around I mean the controls are super tight whenever you put your stick in a direction it's going to smoothly turn and you know you get you get really the full experience you could probably ship in this state the last thing is the grapple so you can see now you got to fully realize jump the rope some minor rope popping is just a bug and aside

from that I mean the experience is pretty solid now the last step of a feature is the gold and all in so like I said earlier most of the features will only make it as far as beta the features that we still work on past beta are really the ones that we find are not necessarily understood enough or come out in the play test results as being problematic and the ones that are tagged as all in so early on in the production process the game design team will write what we call a master features list that contains all the features that they want to have in the game and these features will be ordered by importance the ones that are all in are the features that are really the most iconic and that we know right from the get-go now we're gonna work on until the very end I think the elephant is the biggest example of this like if you think Far Cry 4 I mean the elephant is so iconic and everybody keeps talking about the elephant because it's so great and it's

different but this is one of the features that we know it's an all in feature I mean it's good beta like it's good enough maybe you ship with this now we're going all the way with this one driving shoot is an example of another one that we wanted to push forward we're really did a lot in the middle you got the corpse the reason for this is the moving bodies is an example of a feature that we really that was a low importance feature but it wasn't all that great and there were some issues with like dropping and making a drop at the proper location so we still gave it a good pass at the end just to make sure that it didn't clash with the rest of the game again commitment to quality now mmm I'd like to talk about planning and okay I hear you guys I'm not gonna talk to us about planning really okay the reason why how to talk about planning is because this is depending how you do your plan and a king I think it can be a great tool to really build a strong team that is united and I'm gonna explain this so first of all we do sprints during

production there are two week Sprint's very flexible we do two-week Sprint's because we want to be synchronized with the rest of the production floor it's also nice when we have play tests every two weeks because we're synchronized and because honestly if you have two weeks prints you have a small list of tasks and it for the people working on their tests it feels like it's always achievable you know as opposed to adding for example four weeks we had this huge list and it always feels like ah I got to do all this men the second thing is aim for eleven twelve days of work that's just a formula don't worry too much about essentially when we when we plan we always round up so if we think something's gonna take half a day we'll put one day if we think something's gonna take three point five four days we'll put five days and we add up to eleven twelve days and that's how we do our planning so I know some people like to do for example realistic estimates and x two x 1.5 if you're struggling with your formula and maybe try this one maybe not when we when we manage our sprint when we plaintiff I when we plant if I plan our sprints we like to plant if I nice you like to

synchronize the various trades again this is very easy for us because everyone's under the same roof and we do the planning for everyone for example if you want to add a new weapon you probably want your artists and model at least the first pass of the weapon and then you can have programming an animator do a pass maybe the next week or something but this becomes super easy again d risking first always be risking first and lastly the priority is always to blocking for workers so we do we do have goals right we this is the things that we'd like to hit this print but regardless of whatever you're working on your task list if one of your co-workers is blocked you want unblock him so again I have my animator right next to me and he's blocked and he's trying to do some things like I need coop support for this okay no problem I'll just shelf whatever I'm doing as long as it's not like too complicated process I'll give you what you need and then he gets unblocked and the great thing about this is a great team building and team spirit thing right where it really feels like your

co-workers have your back so when you help your friend you and block him the next time around like he gets unblocked or you unblock somebody else and this is a great way to really handle this now nice this guy really going to talk to us to us about bug tracking yes the reason for this is your bug and task tracking system is probably gonna be the only tool that every single person on your production floor will use now we use JIRA I don't want to get into the like what is your and everything what I'm what I'm trying to picture this here is how we use those systems to really have a workflow that is dynamic and really build a good team now on the Left what you look in so you see there are two columns the left column would be your typical lift a list of tasks that you need to hit from top to bottom so the top part would be your must fix issues like the stuff that's blocking production then you got plate test issues we prioritize those because you probably want to have the result of the plate test as soon as possible in every two weeks so if you wait then you might get them in four weeks instead of two

weeks etc etc where the magic happens is on the right side which is essentially a mirror of your own list of stuff that you need to do but for your team so what this does is having everything on one page it's good because well people will typically not switch between two pages yes just one page and when you go on there and you look at what I need to do today you know oh I have this bug with like the elephant writing okay I'll get on that and then you glance at the top right you see oh man my buddy Johnny he's got like three must fix issues what are we gonna do about that it's like yeah I'm curious I'd like to know what he has click and then you see all he has these three problems I could probably help him out with this one so you can help them out now this sounds very naive but we're very idealistic should I say but the reason why it works is because we encourage people to help each other out we provide them the tools to do so and have this like easy flexibility and because somebody somewhere I started doing it if you get your buddy Johnny out of trouble when you're in trouble next time around body like your buddy Johnny is gonna get you out of trouble

again this sounds very simple but these are all very great tools that you can implement to make sure that your team really help each other out is very dynamic and solid and we always have these these days managers where we're kind of stuck in meetings all day long I mean it happens and if you don't want to have to always be there at your machine to really dispatch if something goes up like this really gives you a good idea to quickly see at a glance what everybody what everybody's doing on your team what's keeping them busy for upper management like I've seen they like to have a good idea of where the team is we have are some internal software that lets you know for for asset milestone for example the list of stuff that we have remaining to do we have our velocity so it gives them an idea of like when we can finish and we can scope regularly daily stand-up meetings our daily stand-up meetings have like 15 to 20 people and last three minutes that's it he's lost it not really

mmm I want to talk about this because I've heard a lot of people say that this is impossible or it like stand-up meeting should not be this large so first things first when we call a stand-up meeting we actually have a gong at the office and yeah it's pretty big so the idea is instead of for example having your stand-up meeting at 10:30 and having people just stand there waiting five minutes for everybody to get there because people are not on time we just ring the gong when people hear the gong they'll just go up to the standup and this is this is very nice some other teams eventually synchronize theirs then that meetings to be at the same time as ours because it's easy hey stand-ups when you hear the gong and yeah so what goes on in a twenty people stand-up meeting for three minutes what information can be conveyed the first thing you want is whoever's calling the meeting the stand up meeting guy you want to go over certain goals certain objectives and I guess I'll give you a walkthrough of what a typical stand-up meeting could could look like so for example I'll

start and call the meetings like okay good afternoon guys good morning guys okay today this week it's evaluation so please try to take some time to do your auto appraisals also there was some issues with stability in the build yesterday which was affecting some of our partner studios please try to be careful if you submit anything risky be extra extra careful and now the next person would really think keywords so I would say all right today I'll be working on you no problem camera when getting on the back of the elephant okay for me I'll be working on transition from one vehicle to another and the vehicle take down and somebody would say I'll be working on more to our explosion impact and it really doesn't need to take that much more time than this the idea is for everyone to have a good snapshot of what everybody else is working on and when you need to talk to someone because for example the mortar guy I worked on some stuff that might be related cuz I worked with explosions last week what I do is I could just say simply I'll talk to you after the stand-up or sometimes you don't even need to talk he sees you so you just not and you point him and they get it you know so then you synchronize you sync up after the

stand-up it's very important that it stays within three minutes because if it's more than three minutes people simply stop listening so keep it short keep it nice I mean give the information you need to do and you probably even have time to sing happy birthday in there sensor Sprint's are small so two-week Sprint's it's it's a very good motivational tool and what I mean by this is you know I was saying earlier that it's it's a finite list this small s and stuff for example for your spreads you'd have eight tasks and you have two weeks to do it and it kind of forced forces people to really go okay so I have these eight items I'd like to get those like six out of the way this weekend only I'd like two items left next week like you want to be a winner you want to be that guy like in front of everybody else or not necessarily in competition but you want a guy you want to be the guy that finishes on time right so one mistake we did on far cry 4 is stopping Sprint's a little bit too early when we when we were in the debug phase later on

we stopped Sprint's and we just okay this is the pile of dogs that we need to get through but this was a mistake because when you have Sprint's like this you can put bugs in there it doesn't have to be tests you can put like a list of bugs you're essentially giving your team a chance and being a winner every two weeks as opposed to being a constant loser that just crumbles under a pile of bugs that just keeps piling in you don't feel like you see the end of it right so this is this again can be a great motivational tool if done right one finishing Sprint's early the guys will debug stabilize stabilizing is good because we have played test every two weeks and the guys would probably appreciate your game better if it doesn't crash in their face and the big big big thing is help your friends now I said earlier that we always prioritize unblocking co-workers unfortunately what this means for you is if somebody on your team gets blocked while you want to unblock them as soon as possible that means you're kind of delaying your sprint tasks but that's okay because some people will finish early and then it can help you out and what happens when your friend Johnny

comes to see you and says hey I'm out of tasks and I see you have a lot of stuff left I think it can help you out finish on time next time around when Johnny's in trouble you're gonna help them out now a big danger here is wanting to finish your Sprint's so much on time that that's that's all you really focus on right so some things will slip you need you need to accept the fact that some some things will slip now I'm not gonna say that it's fine that you don't hit your objectives we always try to be better we always try to do good but if you know why certain tasks is slipping or if you even block somebody else it's work that you would have done later on anyway the key thing is if you're ever unsure always go back to this one question which is what should I be working on right now this doesn't make sense for me to do this you're not you're not trying to hit like 50 Sprint's on time you're trying to make a game so try to try to keep this on the back of your head because it's it's easy in the heat of production to look at Sprint's I just want the Sprint's that

match I want to hit the Sprint's on time but you're making a game now I mentioned development testers how are they different from I guess more traditional testers well first they are embedded within our team and we the gameplay experts for example the game playtesters would be gameplay experts so they'll know the subtleties between different systems and when something this very subtle is broken they might be able to tell another great thing about them is they're technical so we can give them some technical tasks one of our testers on Far Cry 4 was responsible for doing the animation memory profiling so we didn't have to take some animation some some programmer time for this and we always knew quickly where we were standing in terms of animation budget they also have visual studio on their machines so if you have a changeless that you want to test as soon as possible you can shelve it send it to them they can you know unshelved it compile and all it's good a great tool that we had on on--for cry for the test is what we call pre flights the I guess the

simplest way to put it is pre flights are really a mini build that that is built with that changeless that you that you put forward so i'd like to have this this mini build of this version but just add this change list and this is especially useful for us because we shipped on five platforms so the two Playstations the two xbox and the npc and you when you when you work on some major changes you probably don't want your programmers and the heat of production to have to spend the time to like test all five consoles so you can just do a pre-flight the dev testers will go through it make sure it's fine same thing for the difficult repro steps just the fact that we added the online co-op component to the game made it so that we have to have we have to add like twice the amount of testers that we add on Far Cry 3 so we went to two to four because the coop like it's difficult to test co-op problems alone and like the idea is you want to keep your programmers programming you want to keep the animators animating and you want to keep the testers testing because they're the best at it how many times have you had a programmer try to test a mission but he just fails because it's not good

that happens you know now this would not be a proper GDC talk if I did not talk about improving technology to iterate faster so it is it is a focus that we had right so we had better tools but we also had some pretty crazy stuff in there so we got we got some new systems so RT pal allows us to synchronize or stream game versions instantly we had dispatcher that allows us to patch data in in big files also instantly and we had fast build which reduced our compile time by like a factor of 10 it's it's insane now you're probably wondering right now hey Emily the sun's unbelievable and unbelievable and amazing where would I go to find more information well luckily for you tomorrow morning my colleague Dan McKenna is doing a talk on this stuff so yeah tomorrow morning at 10 o'clock don't miss it there's truly some unbelievable stuff in there I go

see it it's worth it now the last thing I want to talk about is code development far cry 4 is an effort between 6 studios around the world we did we did a couple key learnings in there and the first the first thing you're going to notice is I I'm talking about code development I'm not talking about outsourcing and the reason is we really try to build a strong partnership with the other Studios that are working with us it's about understanding that these Studios could be making their own triple-a games and it's not because of a lack of skill that they share this project with you they could they could do their own stuff it's a matter of realizing that there's no B team we work together and we can be we can make some really great projects this way one of the key learnings we did something that worked very well for us is we had on the floor and Montreal we had a co dev team which was a group of people that were essentially responsible for managing the collaboration between the different studios like these guys

are on the floor with us they're in the stand up meetings with us and they actually act as communication coaches even like you work with other studios around the world not everybody has the same way of working not everybody has the same culture how do you deal with how do you deal with this stuff we're not necessarily all trained for this now these guys are very good so what we try to do is whenever we have interaction with other studios we just put them in CC you know when we send emails and they can read everything and see if there's any potential problem there you know that email that you send on Friday evening before leaving and you say alright I'll just do it this way don't don't do this you know and then you leave and all is good because you understand that the intention you had we're good but the other guy in the other on the other end of the line will leave you email and think oh my god this guy what a douchebag he's like telling me what to do and this these guys are really good for this because they'll see these problems and they'll flag them forward so you probably want some guys to be dedicated to collaborating it's like it's six studios it's not it's not a small thing another thing is FaceTime is is very important and they say that 97% of the

information that is conveyed in conversations is really done through the nonverbal stuff now you you may or may not believe this number whatever but it's still the fact that there's a lot of nonverbal in there so what we did is keep people at different studios met several times in person throughout production you want to build some good relationships and if you ever wonder if it's worth it to send people or if you're not sure if it's worth to have people meet in person then if you're not sure it probably means that it is worth it so really take these opportunities the next best thing which I wish we did more on far cry 4 is webcams webcams are super cheap nowadays there's no reason why like not everybody on the floor could have one so really buy a webcam so everyone encourage people to talk and this is I guess this is kind of all obvious stuff but it's like it's good to think about it and you need to make a conscious effort where you know what you work in people with people in person then you talk to this guy and you have this feeling in the back of your head that oh maybe he's not feeling too good what's what's going on there's there is

there's something some friction under there and you got a you got to make sure that you have the opportunity to see this stuff so again webcam is good build some good relationships likewise if you have problems with somebody and in your workplace it'll and it'll eventually fade away because you meet this guy you talk with this guy every day it's like hey are you doing you know let's go for some coffee and then you come back and eventually your problems fade away but that's not gonna happen with co dev because you don't see these guys on a day-to-day you don't see them face to face these problems need to be addressed and your best friends to detect these problems are the co dev team again yes okay lastly I want to talk about boundaries boundaries are very good you want you want to have a certain area of the game that you really give to your code at studios so that they can really take ownership and feel empowered in there I really want to push it forward but the boundaries should never be an obstacle to collaboration the best example I can give you is the example of I got to work

one morning and Brian from Toronto so the Toronto team was responsible for shangri-la you know the red sequence with the tiger and all this stuff so they're responsible for this great job by the way so Brian pokes me and tells me hey Mark you know we have some bugs left and everything but in the grand scheme of things the books that we have they're not they're not that important you know it's pretty minor stuff could we help you with your stuff when does that happen I got nerd chills just thinking about it that's that's that's what's going on right so if if you respect your partner Studios like you give them a chance there's really feeling empowered and you entertain this relationship this is the kind of stuff that can happen you can have a Brian story now the last thing I want to talk about is I guess it's a wrap up I'd like to mention a little bit quickly the different the different key key takeaways of of what I'm trying to say today is what we try to do is we

really try to empower our team so find ways for your team members to have opportunities to really take ownership and especially help each other out this can only lead to great things you have a solid team that can have each other's back and this is completely underrated well maybe not but anyway you should aim for that secondly be flexible always you're not trying to hit sprints you're trying to make a great game so whenever you're in doubt as to are you working on the right thing you probably want to think of does it make sense for me to work on this right now is this really my highest priority then when working on features you always want to de-risk first no matter what so the risk dearest the risks when you plan this is very important you want to scope often also you don't want to you don't want to wait until you're at the very end of your production cycle where you're crumbling under a pile of issues that you haven't resolved and then you need to scope features out completely that you can't ship unfortunately because you didn't scope before so the scope regularly again gameplay first and lastly have fun

we we make a living creating games that countless people will enjoy to me that is nothing short of amazing should be fun and there's always a way to make it so [Applause] so questions what would get set up from questions I'd like to take a selfie with you guys if that's okay hang out how does this work press the button I'm so bad at these things this can happen okay can we all pretend like we just won ten million dollars so like really arms in the air cheer don't care we do that okay good thank you so much okay let's

hear it yeah nice talk McConnell did a question for you the gameplay team seems to be a pretty autonomous pod how did you end all the communication with the rest of the group for other departments okay so every every single team on the floor does this the work yeah we could every single team on the floor has definite owners right so the gameplay team will have some gameplay owners AI will have their own owners and these guys are kind of always in constant collaboration and constant communication so when we do so what we do work on some new systems these guys will talk with me I kind of skipped over it a little bit but our lead game designer in our case was the game play owner was really responsible to make sure that the old game play was solid AI for example I their AI owner and these guys are in constant collaboration now when we do our sprints we send the Sprint's out to all the various leads so we know what every team is focusing on now when I mentioned earlier about I'm

blocking coal craze it's just not people within your team if if for example AI team is stuck on something you unblock them and next time around they're gonna unblock you so this is a very key thing is that does that answer your question yes thank you yes awesome hi yeah so when you were talking about Sprint's it sounded like you guys are doing like version of scrum and part of scrum is retros and I was wondering do you guys do that at all or why not if not part of scrum is what retro is like retrospectives where you talk about that sprint okay so you mean one where we're finished with this print reflect on what we did yes okay well what we did as an exercises so when we do the planning for the next print what we like to do is well I started off as poker planning's but it took too long did it work so well so what we eventually do is when we finish when we finish a sprint and we try to plan the next one we have a meeting with with the team so we'll take like 20-30 minutes and this is

where we'll sit down with the guys and we're gonna communicate the objectives for the next sprint and we can also take this time to really pinpoint the stuff for example that slip to the next sprint and reflect on our wins also so this is we try to do with the team but one thing that's important for me is that we I really want to try the time that to maximize the maximize the time that the guys have to work on their stuff so I try to keep these meetings short and like the stand-up meetings I like to keep them two to three minutes just you know as short as possible so so yes we do we do take time to do some reach respect but it but it's not really a formal process we very I guess scrum is a little bit more you know structured we try to be very very flexible like I said because it is what works best for us does that answer your question yeah yes thank you okay thank you hi first of all the great talk thank you I was curious as a programmer point of view when you're working on the proto phase of a feature yes are you taking time to do like clean

code even if it's taking more time and maybe if you scrap the feature or you are you just acting it and make it work just to test it we don't really do throwaway code and the the reason why we're comfortable doing this is because there's this process you know before it were we're already do the gut checks and the FSO process has already started where the other departments are involved so well what typically happens is like 98% honest I'm not gonna give a number because that's ridiculous but the vast vast majority of the features that we do there they're there in the game right so what will typically happen is this prototype it's it's going to evolve into some things sometimes completely different but we really do try to have a good foundation we don't want to have to code something then have coated again and like I said we're comfortable doing that because of the steps before and we've gotten used to making sure that the crazy ideas are filtered out a little bit earlier on but

then there's nothing telling you that when you start working in this prototype then maybe like you can change completely or it's supposed to be this and it can be scoped down to this but no we tried to have a decent foundation I'm not going to say the code that we do in proto is going to be final but we make it so that we don't have to rewrite the whole thing if we do keep the feature all right thank you cool hi um it all sounds a little little bit like a fairy tale to me yes everything was peachy and all the wind well yes can you mention like maybe one big mistake a problem you did during development that you would wish you didn't one big mistake I don't know if I could say big mistakes I mean the mistakes over all this stuff that we that we really learn from you know like these are all to me to me mistakes are really opportunities to learn stuff and if you learn something from from a situation is it really that much of a mistake really I

mean that the process the process that you see here it's kind of a the result of iteration over over over several years you know so the mistakes are really the problems that that that happen that we try to solve right so in this case a problem that would happen early on before we had this process would be a guys what's going on right we have a we have a hard time get a rating because we have a hard time for example I don't know getting support from animation because they're busy with like some other top-priority stuff so that to me I guess would qualify as a mistake and it's these things that we try to address with this process so in this case if I guess if you're asking me if there's like one thing that would really improve in the process if I knew I would have tried it already what I'd like really for us to do is try to find even more ways for the guides that for the guys to really take ownership and push the feature forward so well I guess this is one of the things that I really tried to hammer and where you want people to really have each other's back and help each other and whenever there's areas where we can

improve in this regard then that's those are the ones that you should really look out for and try to try to try to improve any other questions we good all right thank you so much