Animating Dauntless: Slaying AAA Animation on the Indie Scale

[Music] all right hi everybody so a little bit of housekeeping before we get started cell phones to quiet well that's really loud and don't forget the speaker evaluations at the end that feedbacks super helpful and thanks so much for coming my name is Simon under I'm an animator I've been animating games since about 2001 I was lead animator at EA Square Enix Robo toki and I'm now working at Phoenix labs I also teach animation I've taught at schools such as nomen I animate Vancouver Film School Phoenix labs for those of you hadn't heard of us we are an indie developer based out of Vancouver BC we're team about 40 industry veterans working on our first original IP dauntless so these are a few

of the teams that the studio that our company has worked in the past the employees sorry as you can see we have a diverse and experienced crew who aren't strangers to big triple-a titles and big teams games like the Mass Effect franchise League of Legends Dead Rising and Gears of War just a few of the projects we've worked on most of the team have spent the majority of their careers on big teams and projects our motivation for going indie and remaining smaller came from the desire to eliminate many of the dynamics involved in larger teams that tend to slow down agile decision-making and it lets our senior team focus on what's really important which is making games so Phoenix Labs was started with the idea that if you assemble a small experienced group of people with great intentions empower them to solve their own problems they can make any project they throw themselves at great so what is dauntless

it's a co-op action RPG set in a science fantasy universe for players band together to slay behemoths that threaten the survival of their fractured world to give you guys a better idea of what that's all about here's our announced trailer [Music] [Music]

[Music] [Music] [Music]

[Music] [Applause] so incidentally that trailer was made in-house with just a handful of the team while we were also working towards a pretty major pre-alpha milestone so it's a good example of how we're able to produce a lot of content quickly and at a quality bar usually reserved for much bigger teams with larger budgets we've got some lofty goals for dauntless and for the studio and no small amount of challenges to overcome in my talk today so I'm going to cover some of the ways we've found to make our work more efficient and more fun and just our general mindset when we approach these challenges so what are we up against as I mentioned we want to keep the studio relatively small no more than 30 to 40 people we wanted to challenge the

convention of over complicated systems and processes and instead work with less overhead more empowerment and less management our animation team consists of three animators when we break down the scope of the game that leaves one animator for player one animator for behemoths and another one to oversee the dialogue NPCs and narrative we needed to avoid wasteful practices as well as optimize each person's contributions to the team one or two people being blocked on a 100-plus person team won't really read derail a milestone but could have pretty bad consequences on a team our size and at the pace we move we all came from big triple-a studios and projects and didn't want to sacrifice the quality we're used to delivering nor the scope of the project we wanted to take on we needed to find a way to deliver the experience we're after with the team in the budget we wanted to work with specific to animation the challenge was how do we produce a high volume of animation at a quality we're happy with and ensure the animations we do producer

getting the most mileage in game we also wanted to create an appealing stylized universe the easy choice would have been to choose realism and just charge headfirst into the uncanny valley photo-based textures unedited motion capture default lighting 3d scan props and characters it would have allowed us to create a lot of content quickly and with little direction to maintain continuity for us that didn't feel like an exciting proposition to work on and not really an appealing choice for the universe we wanted to create but as many of you likely know creating stylized polished animation and is pretty labor intensive and polish times not a luxury many teams get especially smaller teams and our first try and quarter a game or behemoth battles Boston counters are hard enough to do the RET right on their own and on top of that animating believable beasts is a challenging and time-consuming task for animation there's a very good reason few games

choose to make creatures a focal point it's just really tricky to do well so how do we approach all of this in a way that delivers something we're happy with without a giant team massive budget or unlimited time for animation turnaround time at an acceptable quality was one of our most important problems to solve we didn't want to become a bottleneck for design VFX or audio so creating and iterating animations quickly with as little effort as possible was paramount key framing animation animations from scratch at the fidelity we're after is an expensive proposition especially when you factor in the cost of the many revisions we typically take before finding the right mix of timing coverage and appeal for gameplay purposes so what do we do we decided we would make use of motion capture as much as we could luckily in Vancouver we've got a few good options of mocap vendors nearby but shooting externally can be expensive and

not very conducive to iteration for a small studio early on we determined that having access to our own motion capture space was going to be pretty vital there were often times we would need only to prove out a small very very small aspect of gameplay and iterate on just a handful of moves booking a shoe at a local studio casting and actor craft services and so on would have been way too expensive in both time and money and ultimately work against the point of wanting to use mocap in the first place one of the great aspects of being as agile as we are making a decision like this and seeing the results becomes a really tight loop for us from when we decided we should look into getting a mocap suit mocap system and building our own and starting shooting was really only about two months so now we had to figure out which system to get some of us on the team have had a lot of experience with various capture systems mainly vikon which for a long time has been the standard but we wanted to give

as many of the currently available options as we could find a chance some of the main factors that mattered to us when considering a system was ease-of-use we couldn't have extra cat headcount to run it it had to be easy enough that one or two people on a team could shoot with his little setup time as possible scalability shooting more than one actor at a time capturing rigid bodies or props or maybe even doing facial capture we wanted a system that could grow with our needs and upgrade easily in the future without having to retool the entire thing access to support while we had a ton of experience working on mocap data and coordinating and directing mocap shoots we didn't have very much experience solving and tracking data setting up a mocap space milk at volume story from scratch having instruction and using the system and the support line when things get a little confusing was was pretty important to us and of

course costs we're working on a budget and getting the most mileage for our money was was a top concern and lastly data quality getting clean easy to work with data was gonna be crucial if it was going to take a lot of time for us to clean that up or you know imprecise capture data we just lose a large part of the draw of using this productivity tool so we looked at those criteria and weighed some of the currently available solutions against them so these are the vendors we chose to evaluate there are others out there for sure but we wanted to start with ones we'd either had experience with ourself or we could get feedback from people we know and trust or at the very least had been used in a production environment we talked to most of them research ones that didn't respond to our emails and because we're a little crazy about our data we made a decision matrix to weigh them all against each other as well as our criteria so which did we choose we ended up getting an OP to track system from

natural point we've got 16 of their prime 13 cameras on tripods and in our current space we're able to get about a 30 by 30 foot volume and we've been really happy with how it's worked out we chose it because it gives us the best cross-section of data quality ease of use portability price our costs for all the cameras tripods suits crash mats everything ended up being only about the same as a couple of shoots at an external vendor and so far on dauntless we've had about 70 shoots so it's fair to say the system's paid for itself several times over excuse-me setup was surprisingly easy the time it took from the initial unboxing to our first capture was only about two and a half hours mobility is also good for a trailer we rented out a larger office space in our building this is us doing it right there and we were able to get about a 25 by 50 foot capture volume to get a little more running room and it only took a couple of hours for us to

break it down move it downstairs and set it back up again and be shooting and we only needed it for a day so the mobility was really really great for that it also satisfies our easy-to-use criteria one person can set it up put on a suit and capture themselves and then solve it or target and we target the data onto the gameplay rig I've been able to do a small shoot on my own about a dozen moves or so and be back at my desk in under 30 minutes this allows us to talk about some new gameplay ideas in the morning and be playtesting them in the game before the end of the day this type of iterations allowed us to try new ideas quickly and find the fun in the gameplay without being a slave to labor-intensive content creation and long iteration times which as many know is often the enemy of quality and game development development you definitely don't need to jump into fully the same equipment we have there are a lot of different setups out there to choose from could fit a wide range of budgets I should also say this isn't a paid endorsement of opted track although

if anybody is here from optic track I wouldn't mind some more cameras we've just been really happy with the equipment and support they've shown us so as I mentioned in the previous slide a lot of what hinders good content creation becoming great is iteration so often the first idea isn't the best one but if you've invested a ton of time into it or your ability to iterate on it is cumbersome you're gonna be a little reluctant to make changes and even if they're in the best interest of the product creating biped animations using mocap is fairly trivial way to prototype but creatures are a trickier matter as most animators know non-human characters are time consuming thing to animate by hand in an effort to minimize possible throw away work we started prototyping creature gameplay using stepped or linear interpolation and only a few key poses to communicate the intent to the move within only a few hours we can have a handful of attacks and locomotion

moves in engine for the designers to create prototype encounters with and get a feel for pacing and staging they're also free to scale chop up repurpose these placeholder atoms until they get something that feels close enough to what they had in mind after that we can re export these as FBX FBX is to give us a rough framework to do a second pass on this way the animators can be confident that all these moves have been vetted in engine many many times and play tested repeatedly so we're not going in blind working this way has greatly reduced the impact of revision work for us and we continue to update these animations adding in betweens and ultimately moving to final polish always play testing at each iteration and getting team feedback along the way at no point do we ever put a polished animation in game that hasn't been played tested many many many times now this didn't come naturally for everyone on the team it took quite some time for the non animators on the team

to be able to see past step keyed animations and understand what the end goal was I think this is really only possible after having work through this a couple of times with the team if you want to work this way definitely expect some growing pains and complaints about animation quality or frame rate for a while but it's definitely helped us speed up so it was also important to get the most mileage out of these animations that we put into the game we wanted to create a lot of diverse behemoth encounters and spending all that time creating awesome animations would be a bit of a waste if they weren't being seen or used much we made the decision to create some high level categories in our game called the genus we call it to slot these different creature types into mainly based on their physiology some examples of a genus would be here on the screen like a mixed flyer or an agile quadruped head or a theropod each variant in the genus

SAV say shares the same skeleton type and rig we can reuse and retarget animations within the same skeletal structure and change or replace geometry color size affects audio and create unique encounters with often no new animation assets we can even make small anatomy changes within a genus such as adding or removing tails or wings and even changing leg types like from reverse knee to a plantar leg some variations required a few new animations some a little more but this really only adds to the asset pool that that genus can use and all the possible variations that we make in the future basically just adding more LEGO pieces to our collection here's an example of a behemoth Bhangarh with a variant Nasher by changing only a couple of animations adjusting behavior and stats as well as changing some play rates on base animations we can create a unique and engaging encounter with much less work than creating a new behemoth from scratch it was also critical for us to

solve complex animation problems with as few assets as possible much like our approach to animation our environment team has a pipeline that allows them to beam at to create massive variety of playable terrain quickly these can contain multiple biomes sub biomes obstacles complex and AB meshes to locomote around encountering a behemoth could happen on a slope in a valley next to a cliff or even in a forest so a traditional animation system would require us to create a massive number of locomotion in combat anim animations to handle turns and slopes and liens and collision volumes again we didn't want any solutions that involve just throwing people or assets at we wanted something that was a bit more elegant more tunable and allows us to use as few animations as possible so as an example here is a behemoth traversing a curved path on a fairly complex slope it's a lot to ask for a single animation to solve and a

pretty common problem for games to make this trickier is quite large and he's a longer creature with a tail navigating around multiple obstacles while traversing this slope we could choose to solve this with blend spaces and a bunch of animations for coverage but we really felt like there was a better way to approach this we ended up using a full-body eye case solution and we chose to integrate an off shell off-the-shelf package called that Kinema and using these Eyck a layers we were able to do a lot with only just this single walk cycle so here's an example of that same walk cycle same path nothing's changed with ikinema turned on conforming to the path foot planting and a look at to lead the head into the turns are all working together to help turn just this same walk cycle into something that's a lot more versatile we also use this for hit reactions aiming attacks and appendages especially when they're on uneven terrain or a

slope such as when he does a tail attack on a slope it takes care of that and keeps the alignment so even with these measures and many others we still have a really tight tight line and a lot of content to create especially when we go live so we did have to outsource some animation work we were looking to do development better than we in the past and how we approached outsourcing was no different having a lot of experience with traditional outsourcing business model we knew we didn't want to work that way for animation outsourcing typically has a point of diminishing return the usual high in studio overhead with pre planning managing directing and maintaining dictates that there's got to be a big enough bulk of work to send out we knew we weren't going to have hundreds of animations to send out at a time and we couldn't sacrifice a lot of in-house cycles to overseeing animation outsource to work so we wanted to find a partner rather than a vendor a group who

worked more as an extension of our team and collaborated with us rather than just completing heavily directed work we were super fortunate that we didn't have to search long for such a partner we teamed up with steamroller studios whose creative director happens to be a friend Julie Elsa dual they're a group of amazing people based out of Florida and they brought a ton of film and creature experience to the table that ended up being a really great match for a gameplay experience instead of a faceless group of contractors in a far-off land we got new teammates who were invested in the quality of our product and could collaborate on ideas with us help win simple blocking of test animations polishing animation we'd already blocked out in-house or just I da ting on what a behemoth attack could be were just a few of the ways that this partnership was a massive help to us being able to hand off animations with minimal direction and knowing that they were reviewing and checking the quality of their work before we ever even saw it

it was just like having a team of experienced animators in the studio with us having outsourced several times this was definitely a breath of fresh air for me and something I'd always wanted an outsourcing partnership to look like so those are some of the high level solutions but I also wanted to share some of the practical workflows and techniques we've been using along the way as well so one of the bigger time savers for me was the ability to use mocap for more than just human characters I've been wanting to try this for some time and I felt strongly that it had a lot of potential to be a potent productivity tool for us but sadly my first attempts at capturing my movements and retargeting them to a creature didn't go as well as I had hoped I started by characterizing the creatures proxy model essentially defining the skeleton for it in MotionBuilder and working with the solving parameters to get the data to fit the anatomy and default posture of the creature maybe with a little more

careful setup and fiddling with parameters I could get a little closer to something that was usable but from this vantage point it was a little more comical than practical so the problem was I was trying to do this how we always solve mocap by remapping on a joint level to the final character while there's definitely more elegant ways to retarget data to wildly different anatomies using more complex I K solving for example the end goal is I just wanted a faster way to define weight posing and timing on my character not necessarily a precise performance transfer it also needed to be done without having to write a new pipeline or involve a team of people to help me out with that so instead of forcing the anatomy to match I chose to think of captured performances a series of movements on centers of masses so in this way I can sculpt the data to work with these relative masses instead of trying to force joints to match on disparate anatomies I just translated the performance into these collections

of areas of movement I could sculpt these to work with different starting positions and orientations and if a part of the capture didn't work with me I could just check it out and key it myself pretty quickly my first attempt at this gave significantly better results than the first so this is literally my first animation I tried this on I found the scene it's a simple test I know but this actually only took me about 30 minutes to get here and that included solving the mocap data I'd probably take an animator considerably longer time to get to this same place and I'm starting with higher fidelity base to work from when finishing this versus blocking so with just a little bit more work keying the hands and feet polishing the performance and adding a little bit of texture I can get decent results with much less time and it would take the key frame to this low the detail so how did I do this I'm sorry to say it is not a very technically impressive workflow I start

by bringing in the exported motion capture into motion builder and solving it to our player skeleton I've usually fixed any jitters pops or weird rivet rotations in motive and that's opted tracks capturing and editing software by this point but if there are any other issues I'll address them here on the control rig before going any further I'll also often do a quick retiming pass using the time warp tool as I like it a little bit better than the one in Maya even though this one can be a bit more finicky a general idea of what my timing and spacing is going to be and we'll get it as close as I can but still thinking really broad strokes first at this point it's not on the final creature model so it's really tricky to be super accurate here and then I export this as an FBX bring that into Maya and I import a set of locators I created ahead of time that live in a simple hierarchy I've found that this was important that these live in a parent-child relationship similar to how the skeleton is set up and that avoids a lot of problems in the transfer

on a lot more complicated physical moves especially when the behemoth is inverted each of these markers is used to define a center of mass that I want to transfer from the capture my main ones I want our hips torso head hands feet I'll usually grab movement from the elbows knees shoulders but only use them if I really need it I'll pair --nt the appropriate joint to the exported skeleton in a position that best represents the point of movement I want to represent and bake that translation and rotation onto the locators at this point I can blow away the skeleton and I'm left with just the locators which I'll save out merge with my behemoth rig and start and set my starting pose and in this case my Idol then just align those locators to the atom layer on an animal--a ur sorry to the control points I want on the behemoths rig I just parent these to parent the rig to the locators bake that translation and rotation and then blow away the locators for my scene now I'm free to insert my impose retime the

animation and just start layering on top of this base movement to get performance I'm after so what are the limits of this system obviously putting movement on a bipedal creature is a little more forgiving than a quadruped ed I can still use the timing and weight of the main center of masses the hips and the torso I also sometimes use props in mocap to approximate the difference in limb length if needed usually just giant styrofoam blocks even just having basic info on a character's fuselage help speed up the first pass and Kien quickly using AI K on the arms and legs and just makes the getting a detailed block out really really quick it does get a little awkward when somebody walks in on me doing this in the mocap room though so a big focus of our culture at Phoenix labs is making sure we're spending our time solving the right problems for animation we try to

remove as many pain points in our workflow as possible a pain point is something that causes an animator to either lose momentum while working on something or an unnecessarily repetitive task basically anything that takes you out of your flow as much as I hate that word whether it be the creation or the exporting end a lot of our processes and tools are built around minimizing these repetitive or time heavy tasks for example I found I was spending way more time than I would have liked animating the tail on behemoths especially during the initial couple of passes to prove gameplay this was even more of a problem on complex moves that required the tail to be interacting with the ground plane I wondered if there was a way to automate the majority of this using dynamic simulations in Maya not being familiar with dynamic sims at all in Maya this took a little bit of trial and error to figure out the process that produced the results I was after but here's how I set that up on our rig so I

first needed to start with my base post for the tails for this again I'm using the idle pose to avoid any circular dependencies I used to I need to decouple the simulation from the main character rig and because of that I tend to leave animating the tail like this to the very end first I need the animation for the tails parent so in this case it's the hips to live on something outside the rig I like to use locators for just about everything so I'll go with that all I'm doing is basically just baking the translation and rotation out to a locator from the hip control I do this kind of thing a lot so I've got a little Python script I wrote to make this a single button press or a hotkey then I duplicate the joint chain of the tail and unparent that from the main skeleton and create a curve that follows the tail with a CV at each joint and make that curve a hair simulation parent the resulting follicle to the locator that we baked with the hip movement on it and then setting that curve as a spline ik4

the duplicate joint chain I can then use this joint chain to drive my f kin controllers FK controllers on the characters rig via Orient constraint and if the tail is going to be interacting with the ground plane I'll just create a simple poly plane and use that as a collision object or you can actually set ground plane as collision within the follicle settings as well at that point I can tweak the dynamic properties of the follicle things like stiffness dampening motion drag to make the tail feel like it has the correct weight and mass and I also key things like how much attraction to the original curve and how much gravity and friction lives on the ground plane to help sculpt that tails movement it took me a while to figure out what settings in the dynamic properties I needed to adjust to get me close to what I was after there are a lot of them in there but now I can get away with only a handful of them and that'll get me most of the way when I'm most of the way there when I'm happy with that how that's working I just baked it back down to the rig and now I can key over that using layers or

exaggerate that base animation just as if it was motion capture so here's the kind of results I can get now with about five minutes of setup work it's not perfect but you can see even subtle interactions with the ground that could take a wild animate by hand if I didn't use this massive method with even a little more time adjusting and testing and keying the settings on the rig I can get a lot better result when we combine this with our a Kinema in engine we can be more adventurous with creature designs and adding and removing appendages on our behemoths and rather than trying to make safe choices when we design these creatures we can take a little bit more risk so this works great when I need to have the tail just arbitrarily follow the creature but what if I want to define parts of that movement such as in an attack or a personality move for that I'm essentially doing the same thing only with a couple of extra steps first i'll roughen the main poses I need the tail to hit on the behemoths rig then I'll

duplicate the tail joint chain just like last time remove any constraints or dependencies and then duplicate duplicate it again so I have two versions of that joint chain the first one I'll constrain to the original tail and bake the animation back to that and then remove those constraints so I'm left with block tail animation on one of the joint chains I'll create the curve same as last time but instead I'll skin that curve to the animated joint chain from here it's pretty much the same turning the curve into a follicle using the dynamic curve to drive the second chain and then using that second chain to drive the FK rig in this method curve attraction and dampening become the main dynamic property to key and just make sure I hit the poses I'm after this method takes a little longer than the first but still far less time than hand keying to achieve the same results we've since started incorporating this incorporating this into our rigs and tools so it's not a manual setup for me each time which makes it even faster

I've also used this for smaller things things like the scales on his back I don't really have the time to animate each of those by hand you can see there's a lot of them but being able to just simply and bake that back to the rig can save a ton of time so I know this isn't a revolutionary way of working I think Naughty Dog showed a similar thing in their tool set quite some time ago but it could be used for almost anything you just want to get some really quick overlapping movement on even if you just end up using the sim chains for reference and row toeing over it we've also used animation dynamics in engine for obvious things like cloth of course we also use things like muscle jiggle on behemoths player arm or anything else that just might be easier to swim in engine over top of animation state changes so I can't talk about animation pipelines with talking and without talking a bit about rigging and tools because we have limited animation tech art support and a myriad of different

behemoths and player rigging needs not to mention everything else that EA does we needed to find a way to approach rigging in a way that was efficient and reusable so we have a Python focused toolset for creating and animating behemoth rigs because our bahama stab a variety of proportions of variation that also needed to be expanded upon in an agile way the rigging toolkit uses a module definition system to break up the workload of rigging the different parts of a behemoth this allows for a rule set to be applied to many behemoths based on the parts that they have if a new part or functionality needs to be added later a new module can be written and added to the system the animation toolset hooks into these modules to search out what information it needs to affect those parts an example of this would be the eye kfk switching tool knows about what modules it's looking for and therefore what attributes of that module it's looking for instead of being named based or hard-coded into the rig so these are

examples of modules for different parts of the rig some attributes are used during the creation process and some are used by the animation tools limbs get defined in an interactive way during a placement phase and then committed during a creation phase this was generally successful for us it could be greatly expanded upon in the future for better create to better create a definition of the rig as a whole also when a skeleton is already pre defined the modules needed to pass it hooking up the joints it cares about and that could be better automated as well we'd also like the toolset just to have a better friend enter wizard so it's better for people other than just tech artists to use and also because the physiology between the behemoths is dramatically different this led us to some different needs that you might not think but the center-of-mass was a big one for us generally we may allow for different pivot points for the whole body and the rig to make it easier to animate but when procedurally moving characters in

the engine throughout Kinema we needed to find define a hard center of mass over the root in the skeleton for quads and bipeds this is sometimes obvious but for a biped quad quadruped it hybrid on the right it led us to think about where that behemoth would be pivoting from during its movement most of the time and create a chest based centre of mass this was contradictory to the bind pose and the rigging toolkit needed to be able to take this into account and finally just quality of life improvements as mentioned earlier removing as many of the repetitive and time-consuming tasks as we can helps to speed up iteration times and make the work more enjoyable and that leads to higher quality overall some examples of this are automating mocap pipelines tools to help with multiple frame range exports from a single file i kfk switching pivot point changes for any control mid animation and mirroring and just easy to use pose libraries as well so lastly is something

that seems to come up a lot in discussions about using mocap often the thinking is we're not making a realistic game so we can't use mocap well it definitely takes a little bit of work to get the results you're after when you're confident with the process you can get to the end result in much less time than all hand keyed movement another great thing about using capture is that it gives you a fairly consistent baseline of quality across all your characters and your project so a common method used when exaggerating mocap is to lift keep it keep OSes from the performance this is done by putting the motion capture on a base layer and creating an override layer with the weight turned down and then you set keys where you want to keep the movement essentially giving you or you your block out and you're in betweens for free and just allowing you to read time in the graph editor or even in the timeline this works the same way in both Maya and motion builder well this is a great workflow and something I still use from time to time what

bothered me losing all of those micro rotations in detail that you get from mocap and we spend so much time on the polish pass trying to add that back in I wanted a workflow that allowed me to sculpt that performance without being too destructive to the original data so what this mainly took was a bit of a mental shift from thinking of motion capture as a recording of a performance and rather to a collection of curbs to curves to sculpt and manipulate much like the centers of mass that I showed for creature movement so I'll explain this with a really simple example so once I get my capture onto my rig my first priorities are timing and spacing it helps to have a clear idea of the goal in mind especially before putting the suit but sometimes this is a little bit of trial and error when I'm working this way with mocap I'm still always thinking as I said broad strokes first I don't want to get really really caught up in small details right now for retiming I'll use either time warp in MotionBuilder or the retime tool in maya

what I'm doing at this stage is just trying to recreate the tempo and feeling I have in my head for the move the actual movement isn't being exaggerated here only the time and spacing so it takes just a little bit of imagination it's probably not the only time I'll touch the timing I'm just trying to get it as close as I feel is right at this point when I'm more or less happy with that I'll plot it back to the main rig so I don't have keys on my sub frames if the move calls for it I'll insert my start and end pose here and work the movement to come in and out of those poses properly for the most part I use the lattice tool in the graph editor so remember I'm trying to preserve a lot of the micro movements in the capture so just deleting large chunks of data to blend into poses kind of works against this so I use the lattice tool a lot just trying to sculpt these curves and sculpt the performance when I get my poses insert it's time to start adding in the exaggerated movements so I go to go with my timings alright for this I

use layers again starting with broad strokes I'm trying to hit the main poses and movement changes to define the staging here the missed instance in instance I'm trying to exaggerate the distance and timing of this jump I might pop back to retiming while doing this to get the first pass nailed down when I'm happy with the main timing imposing and spacing pass then I'll start to refine silhouettes intermediate details the final passes for smaller things like overlaps contacts cleanup and other details like that much of this I still keep on layers to avoid touching the the base capture and then I can just use an override layer to key the weight on and off if I need to really override a part of it so here we can see the difference between what I started with and the end result once you get comfortable working this way it can cut down the amount of time it takes to achieve the same result doing it by hand considerably this example here it's still pretty rough and needs a bit more

work but including capturing the data solving it and reworking me to my I've only spent a couple of hours just to get to this point so even for a really fast animator that could be pretty challenging to do with key framing only so don't be intimidated to try out motion capture even if your project might not seem like it calls for it much of the hype around it has been centered on preserving the actor's authentic performance but I encourage you to think of it more of a profit more of a productivity tool so now not every move in our game was created this way there's definitely a lot of hand keyed animation as well and it ultimately comes down to each of the animators individual expertise to choose what method is best for the thing that they're creating that day but for complex movement we've found this to be really really valuable so as you can see there wasn't one single magic solution to all our development challenges it took these and many many more tiny changes in how we approach development always asking ourselves the same question are we working on the most

important problems right now and what's the best way to solve them creating that culture in the studio has been the main ingredient in our success so far so if you want to find out more about Phoenix labs or Dauntless you can head to either of our websites PHX labs see a play Dauntless calm and if you want you can find me on Twitter and if you're interested in more discussions about animation and games head on over to annum state comm and that actually went way faster than it did the last ten times I read it so I have tons of time for questions if anybody has any otherwise available out in the hall afterwards as well thanks everybody [Applause] I was wondering which game engine you guys are using and what the strengths and weaknesses you feel well of it sorry can you repeat the second part of that so why did you choose the game engine that you're using or what what Mel G's

internal tech if you're using that and what are the strengths and weaknesses that you feel made you make that choice right so the question was what game engine are we using and what are the strengths and we can what caused us to choose that we're currently using Unreal for you before and really it came down to you know what's the best commercially available package for us right now that got us the furthest towards our end goal there wasn't much out there I think in our opinion probably building an engine from scratch was not necessarily the best use of time for a startup to do and it's been really great for us we found it it's been it's taken us most of the way without needing to write a lot of bespoke tools for our game it's been great yeah hey Simon great talk thank you thanks I was wondering if you could go in to a little bit about your interaction with your outsourcing team and how you work with them day to day and yeah kind of

pipeline for that briefly sure so usually what we'll do is we actually treat them almost like how you would a film team so we launched them on moves we will have typically I'll sit with the designer our little behemoth team and we'll come up with our encounter design for a creature when we figure out our base list of moves so make sure that we're all on the same page and then we'll get on we use zoom right now for group calls at the studio and we will launch them on the moves go into the mocap zoo so we can run around and look silly while we're demonstrating them and then typically I have a group chat with them almost every day right after lunch we'll do reviews we can do with zoom you can draw on the screen as well so we can do reviews I could do draw overs we could talk about the the they also have access to a branch of our perforce so when they submit they can

submit through there and it is mirrored to our own internal one so it's quite seamless I just export from that base folder and and put their stuff an engine typically I'll work with the leads on there but often the actual animator will come on the zoom call as well and we'll do it one to one but usually it's either with Jalil and the lead for us over there at steamroller whose name is Josiah and it's just been it's just like turning around and having an animator on the team we just hand them off some moves describe them as best we can we'll see the Block outs we always work in a very like I want to see blocking and then we do in-betweens and we do blocking Plus and finally polish and we track all this in a giant spreadsheet that everybody has access to it's a Google shared sheet so they can flip flags if they've taken a move they can just turn it a certain color and it Flags us that they've got it and then when they've handed it in and it checks it another color things like that it's really really quick I don't spend more

than a couple of hours a week reviewing animations really with them they're very good so I have a two-part question regarding the keyframe blocking when you're first prototyping your animations first I think I'd like to hear a little more about the actual process details regarding like how you went about creating the moveset in the first place and blocking out identifying what your key moments would be and then the second part was how long did the the initial blocking phase of the keyframe motion when you were prototyping for game play how long did that last yeah so our process usually is will will have we make sure everybody's pretty clear on the behemoth team before we start on what moves we want and a priority of how they're going to be delivered if the creature has like I

showed we've got variations within the genus so usually if it's a variant of an existing one we already have a base locomotion set we can draw from then it's adding new attacks and new personality animations or things like that if it doesn't then we block out some of those as well and really it's about coverage spacing and timing when we do these first passes so how much distance and coverage is an attack and what range is that covering for locomotion what speed are we doing the distance over time and we we work very quickly with that so typically for a variant and all the animations so if we have maybe 10 to 12 new moves for a creature to get done for attacks things like that we'll have that game play encounter up with within a week easily usually only a few days we can have a first playable and be played testing on the team and and iterating on it with I think our last variant we did took us

three days to have that and it's very quick we never spend more than an hour or two per animation to block it in thanks that's it all right thanks so much everybody [Applause]