Naughty Dog combat designer Benson Russell walks us through the combat design process at the acclaimed studio, breaking down iteration, team members involved, and how the tools pipeline hooks into workflow.
[In the second part of his series on the combat design of Uncharted 2, Naughty Dog combat designer Benson Russell walks us through the combat design process at the acclaimed studio, sharing the breakdown of the steps of iteration, team members involved, and how the company's tools pipeline hooks into workflow. Part I discusses how the team evolved the combat design from the original Uncharted.]
In Part I, we focused on where we came from -- that is, starting with Uncharted: Drake's Fortune -- and where we wanted to go with Uncharted 2. For this part, we'll be taking a looking into our design process from the ground up.
Just to set the stage a bit, this article is purely about our encounter design process, and how we put an encounter together. By this point in the process we'll have a lot of our core mechanics defined and we will be prototyping the new gameplay mechanics and styles alongside this process. Well, that's the theory, anyway...
For Naughty Dog, it all starts with the story. Instead of creating spaces solely around gameplay and then worrying how the story will fit in, we instead want to take the story into account as early as possible.
We want the gameplay to support the story and help draw the player deeper into the experience. This isn't to say that we don't think of cool set pieces, moments, or locations for encounters first, but we still find a way to incorporate them into the story arc where they make the most sense.
At this point we want to take into consideration where our characters are in the story arc, so some key questions we ask are:
What are the characters' goals?
Where is the location?
What is the tone and mood of the current story beats?
This helps to give us guidelines to focus the encounter for both gameplay and art. What style of combat best supports the desired tone and mood we are going for? How do lighting, weather, and time of day play into things? Do we need to foreshadow a big event coming up soon? All of this will factor into how we want the encounter to play out.
Once we've sorted out the story side of the equation, we check on the gameplay side of things. We like to maintain a spreadsheet that tracks a lot of the gameplay information for all levels across the game.
With this we're able to see what mechanics we've used and where, what weapons we've given the player up to this point, what classes of AI we've introduced, and what mechanics we've trained the player on. Of course this is always a work in progress, and we adjust it to what best fits the game's needs over the course of development.
Using this spreadsheet we see how the story elements of the encounter match up with the gameplay ramp and pacing. The goal is to make sure we're achieving a balance amongst the different gameplay mechanics, picking ones that best support the story while evolving things for the player. If there's a conflict between the story and gameplay elements, we do our best to try and support both, but we'll usually lean towards favoring gameplay in the end.
One designer will usually be the point person for the level. Since we don't have anyone at our studio that is hired for the sole purpose of filling a producer's role, the point designer becomes the acting producer. They will head up overseeing the level through to completion, helping coordinate all of the different disciplines in what is needed, and coordinating with the rest of the designers and leads.
Once we've picked a point designer for the level, we have a pow-wow to go over all of the story and gameplay needs, as well as brainstorm what the level should be.
Anybody that wishes to be a part of the process can come to the meeting, but the key people are the point designer, the game director, and the lead designer. They will have gone over the story elements with the creative director and co-president (who is essentially the head designer of the studio). Sometimes the combat designer (that would be yours truly) will sit in, but at this stage it's not always necessary.
For this meeting we're just interested in getting a starting direction and flow for the level -- working out the initial high-level details. We figure out the beats for the level such as the location and setting, key story and gameplay moments, the objectives of the player, combat pacing, special "wow" moments, etc.
At this point, we start to create a generic high-level layout. We don't want to go into too much detail; it's more of a representational space then an actual specific layout, and is made for showcasing the flow of the level. This is iterated on until it's agreed upon that we have a good starting point for the design.
Once we've established the high-level flow, the point designer will then create a simplified blockmesh layout of the area in Maya. The idea is to keep this as light and lean as possible using basic shapes so we can rapidly prototype spaces and gameplay. We want to get as much of the size, scale, and positioning of structures right before we hand the level off to the artists. This is because as finalized art comes into the level, making changes becomes much more difficult and time consuming.
As more of the level starts to take shape in blockmesh form, we start to go over the space with the artists to try and catch any potential major issues and address them at this stage. These issues might include visibility and polygon counts (or more specifically vertex set counts for the way our engine works), how much instanced geometry we will be able to use, texture memory count, how can we split the area for level streaming, etc. It's much better to tackle these now while the level is in a malleable state rather than once it's artified.
For exploration and puzzle sections of the game, aside from the puzzles themselves, we concentrate on making sure we meet our jump and grab height standards. Also, the flow of the level and how we lead the player through the environment is very important (i.e. how much do we wish to obfuscate the path from the player?)
We consider sight lines to areas beyond, looking at how we can use the environment to lead the player around by placing "weenies" -- this is a term borrowed from Disney theme park creators used to describe recognizable landmarks that can lure people.
Where combat spaces are concerned, we have more details we have to take into account when laying out the space. Some questions we have to ask ourselves:
How does the player come across the encounter?
Is the enemy aware of his presence and waiting for him?
Are they oblivious, thus letting the player stealth his way into the area?
Are they setting a trap and pulling an ambush on the player?
What's the tone and mood of the area, and how can the combat support this?
We also want to try and find ways to widen the corridor of the playspace to give more options to the player in combat. This doesn't always mean just opening up the horizontal axes, but also the vertical. With Traversal Gunplay we want to let the player use their climbing skills to gain the advantage on the enemy.
Conversely, we want the enemy to be able to use these routes as well if the player decides to hunker down and sit still for too long. We try to encourage the player to move around the space and explore avenues that they normally wouldn't find in any other game. We want them to analyze and use the space differently to gain an advantage. All of this factors in to the layout of the space and how it can enhance the combat experience.
As the level starts to take shape and gameplay is put into the area, we start to iterate over the experience to get feedback, and see if we're heading in the direction of... funtasticville!
To help facilitate this, we've specifically designed our gameplay tools and pipeline to let us iterate through gameplay changes very quickly. The details of how we set up our tools and pipeline are unfortunately beyond the scope of this article, but I feel it's worth mentioning a few high-level points to demonstrate what I'm talking about as the quicker you can iterate on something, the better you can tweak and polish it.
Our pipeline is designed around the data being live on a set of servers rather than residing on our individual workstations. When we run the game this data gets streamed onto our devkits. This way we don't have to take time syncing up the game assets, as they're always available immediately.
There's a few types of data that we as designers deal with: the static background geometry, the foreground geometry (which is anything that can be interacted with, move, or animate), and the meta-game objects used to implement gameplay logic (position markers, trigger regions, splines, etc.) All geometry is built inside of Maya, but all gameplay metadata objects (including foreground geometry instances) are all placed and manipulated in our custom built level design tool called Charter, which is strictly designed for this purpose.
(Click image for full size)
There's no cooking or pre-packaging of any data before hand; it just runs in the engine directly with minimal load times (on average about 45 to 50 seconds from game launch to main menu). When we build a level, we have the option to build just the gameplay data that's placed in Charter. It's a very fast process (usually under 30 seconds) which we can also dynamically reload into the running game to see our changes immediately. The same goes for our scripting language that we use create the gameplay logic.
When you have a very fast pipeline for getting your changes into the game, it frees up your workflow tremendously. Instead of lumping a bunch of changes together due to long load and build times, instead we can focus on specific elements of gameplay, even if it means iterating just one parameter at a time, and fine-tune any part of the experience (i.e. when tuning weapons, AI, puzzles, etc.)
For combat-specific areas of the game, we want to start with a simple approach and build up from there. The key reason for this is to keep things light and lean for quick iterative testing as we focus in on what works.
As the combat designer, this is where I usually start to come in and throw a monkey wrench into the equation -- um, I mean, help make things fun. Working in conjunction with the point designer for the level, as well as with the game director and leads, we'll figure out a starting direction to try based on the requirements for the encounter. The goal at this point is not to do any fancy or complicated combat scripting, but to just put in the most basic pass we can that gets the essence of the desired direction across.
From here we'll do several iterations to try different ideas and find out what will be the best fit. Sometimes it's small changes and enhancements to the basic first pass; sometimes we scrap the whole thing and try a different direction. This is why it's really important not to get too complicated from the start, because we want that ability to scrap what we have if need be without remorse.
It's very difficult and rare to come up with something from scratch that is going to be perfect on the first try, so you need that ability to quickly iterate, along with the willingness to try different ideas. As we get closer to what we're wanting, the scripting will start to become more complex, but only once we know we're on the right path.
We also need to have a critical eye and awareness of analyzing the fun factor. As an example of what I'm talking about, if you play through something and it seems "alright", don't just settle for that. Dig down and try to figure out why it's just "alright" and what can be done to improve it. Granted, these are the first steps towards finding the right direction, so it's not going to be absolute perfection, but you should still be able to feel out if you're just putting in something that's mediocre, or even worse, frustrating.
Also, don't forget to compare it to the goals of the space and story. For example, if you're trying to give a sense of being oppressed and pinned down, if you feel like you have the ability to roam around without much threat, then you're probably not going in the right direction yet. An eye for the details can go a long way in turning the encounter into something awesome, but the trick is to not get bogged down in the polish details at this phase.
Once I've gotten something that I feel is working and going in the right direction, I'll start to have the point designer, lead designer, and game director play through it to see what they think. We'll probably start with a few rounds of iteration amongst this group, but eventually we'll start to grab whoever is available in the area.
Our office is arranged in giant open spaces where we keep the different disciplines together. Our desks are arranged in groups of four with half-height walls, so it's really easy to hear and see everybody. At this point I'll literally pop my head up and grab anybody that's close by (which would be fellow designers, mainly) to come over and try the encounter.
The standard focus testing rules apply when observing someone play (i.e. you keep your trap shut). However, it's alright to give them a brief synopsis of what has happened up to this point in the story, so they have some context when playing through the encounter. A few key questions to keep in mind:
How are they approaching the encounter?
How are they flowing through the encounter?
Where do they tend to go?
Are they frustrated or having fun?
Do they tend to die at the same points?
Do they have the gear (weapons, ammo, etc.) that they need for the encounter?
Once a person is done with a playthrough, we ask them for their thoughts so we can get their raw feelings about what they just experienced. After gathering all of their feedback, we'll start to grab several other people and run through it again.
Our fellow coworkers are one of our best resources, so we want to get a variety of opinions involved. We also want to use people that aren't just the "core" gamers, as we want to get a good smattering of different skill levels. Some people are going to like head-on conflict and combat, others will prefer stealth and being crafty, and we want to see every approach, and what lies in between.
Along the way we'll make adjustments to the encounter and fine tune things, but the goal is to find the right direction for the space. Once we've accomplished this, then it's time to hand the space off to the artists for beautification. From here on we'll be working with the artists to oversee the space, making small adjustments along the way as the blockmesh starts to change and become more organic.
Something that's always a bit of a struggle is the maintaining of standards during this process. While those blocky shapes are absolute gameplay perfection, it's not exactly a Rembrandt -- a child's crayon interpretation would be prettier.
So as the artists start to turn the gameplay masterpiece into something visually stunning, we need to work closely with them to make sure certain gameplay standards are adhered to (cover heights, jump distances, etc.) We want to find the best compromise for what works. Even though we'll favor gameplay for critical areas, we still want it to look its best and let the artists strut their skills. It's always a collaboration.
During this time I'll start finalizing the scripting and gameplay for the encounter -- making sure the right visual variety of enemies are present, adding weapon and ammo drops for the player, polishing up the scripting and making it bulletproof, etc. Then we'll start the entire process again on the next level, usually having several running concurrently over the course of production.
So there you go. That's a brief walkthrough of how we approach the process of encounter design here at Naughty Dog. In the third and final installment of this series I'll be covering the technical side of how our AI works, techniques we used to make our combat fun, and then lessons we learned along the way.
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
