Corwin reacted to General Vivi for an article, Designing Highly Replayable Stealth Levels for Payday 2
The Making of Murky Station: Payday 2
Payday 2 is a four player cooperative first-person shooter with RPG elements that centers around robbing banks and stealing rare loot. It was released on August 13, 2013 and has since shipped over 50 DLC packs and counting. With a thriving subreddit, it has consistently been in the top ten games played on steam. Today, I wanted to talk about my adventures designing stealth levels for Payday 2 before leaving Starbreeze in January 2018. While parts of this article are specific problems and solutions for Payday level design, I made sure to discuss them in a broader sense. The skill level of this article is for junior to mid-tier level designers, if you are a senior designer some of this article may sound familiar to you.
I'll start off by saying that Payday's stealth mechanics are not perfect and can be flawed in some areas, but I wanted to focus on the decisions behind the map design, specifically for the heist Murky Station. I'll also break down how we consider using RNG (randomization), and the ways we apply it to objectives and mechanics to keep the level fresh and replayable. This map took 6 weeks to make between 2 people. My partner took the role of Level Builder / Environment Artist and I took the role of Designer / Scripter. Between the two of us, we figured out the scale of the project based on the needs of our studio. The idea was to create a small heist that took around 10-15 minutes to finish with high replayability. There's a lot to go over, so let’s get started!
Let's start from the beginning
Before we start drawing or building layouts, we make the call if we are going to create a Loud level (combat only), Stealth level (avoid combat), or Mixed style map. For the short period of time given to us, we decided to stick to stealth only. Making this decision early on helped us create better movement options for the player and focus our efforts towards balancing patrols and objective placement. We decided that the theme of the level was a small train depot run by a group of mercenaries shipping large weapons. The main objective was to infiltrate the depot and steal an EMP bomb. Keeping the objective simple and intuitive is important in multiplayer games where players can drop in and out of the experience at any point in time.
We decided to shoot for 10 - 15 minutes of gameplay. Breaking down our main objective into smaller sub-goals that could take about 2 minutes each (this is based on our extensive knowledge of payday 2). It should be noted that this time assessment will change once the player has completed the level a few times. These numbers tend to get cut by a third, or in some cases, by half. With our main objective in mind, we can construct a simple flow diagram for the heist and start to think about possible dynamic and RNG elements that can be used to create a re-playable experience.
(This is a scripting example from our editor, each entity has it's own function)
Testing your ideas before scripting them? Wait... What?
Since 90% of Payday levels are hand scripted, it's important we don't waste time building the wrong things. Testing your objectives and complicated RNG elements has to be fast and efficient. The last thing you want to do is build an entire system and find out it sucks. Most of the time you don't even need animations or even a model to properly test your ideas. At such an early stage some floating debug text will do just fine. You might be asking, what if I don't have debug text or the ability to script? When playtesting levels for Payday 2, a lot of the time we'll get a simple block-out done and then ... here it comes ... pretend we're doing the objectives.
It might sound crazy (and not everyone can get through it without laughing) but we'll have one of the designers act out the role of Bain, our mission giver, and just spout objectives at us. We'll move through the space and pretend to see guards or hack laptops and delay time based on things we expect to happen. You can basically break down how your systems might work and try out a few possibilities. For example, knowing that you might have two escapes at either side of the map gives you enough knowledge to make pretend decisions. Telling your fellow devs the van is arriving up top and pointing out where to secure loot can help you find out if a location is interesting for the escape or not.
Even though the artists might giggle, or people from the other teams walking by stop and wonder why they can't see that hoard of enemies. It really works, and can often steer the level in the right direction and prevent us from investing too much time on the wrong objectives. Now, I know this approach won't work for all studios or situations, but all I gotta say is... don't knock it till you try it...
Constructing our Sandbox Layout
Now that we've pretended to run through our objectives and have gotten used to our basic block-out, let's talk about the layout we built for Murky Station. We went for what i'd like to call "the onion approach", which is pretty much what it sounds like. You'll have multi-layered rings that give you the sense of progression towards the center (or a goal). Essentially, we use the outer layer as the player start and each sub-objective is based inside a different layer until the player reaches the main objective (at the figurative center). This approach is very useful when working with sandbox type levels, especially when the player can virtually go anywhere they want.
Side Note: We also layer our music track each time a sub objective is finished, creating more suspense and a sense of agency.
You can see that the outer onion layer is the player spawn (colored green) on the overpass which gives them a full view of the trainyard. From here they can study patrol routes, train-car positions, and possibly objective locations. The overpass can also be used by a player with a sniper rifle to mark guards in the different lanes, helping provide accurate information on guard positions for the players on the ground floor.
The next layer is breaking into the train yard through a fence around the perimeter. The fence is here to guide the player and give them a visual boundary for the "safe zone" (where no guards patrol). The next layer is searching the train cars to discover where the main goal is hiding, followed by breaking through the vault doors inside of the trains themselves. These onion layers have to be carefully managed to give the proper impression to the player. Too many layers and you might confuse the player or make them forget what they're doing, too few and you might leave them feeling unchallenged or unaccomplished.
Player Mobility is key!
Mobility is key to providing players opportunities to express themselves and make better decisions while traversing a level. I felt that it was pretty important for Murky Station to allow for different play styles ranging from slow and methodical to fast and dirty. The last thing I wanted was to force players to play a certain way or for the routes to become predictable and linear. In order to do this, I spent the first week of development prototyping and testing out different layout ideas that would maximize paths and choices for the player.
(Here is a simplified top-down of the routes in the train yard area)
It became obvious that we would need to allow players to traverse through and under the trains as they cover most of the real estate in the train-yard. Unfortunately the older train assets were not built to go underneath, but lucky for us, the nighttime setting of the level would cover up this fact. There being only 2 of us on this project, I took a crash course in Maya and cleaned up the bottom half of the trains by removing collisions and remodeling them for readability purposes.
The next challenge was to teach the player they could hide under trains and be safe. Payday players haven't been under the trains in any other heist up until this point, so we needed to call attention to that but also show them it was a safe place. Making these spaces dark and in the shadows helped create an illusion of safety but also made it harder for players to find them.
To help solve this issue we added yellow caution tape as a trim and a dim red light under the wheels to catch the players eye. These combined elements would then be used as visual vocabulary in other parts of the level to teach players something should be explored.
One of the other ways we added more routes to the level was to build a ventilation system in the lower tunnels. Leveraging the fact that this was a stealth level to create these smaller spaces, especially since they didn't have to accommodate 40+ police officers. The vents allowed players to safely view guard patrols, search for objectives, and move loot. To prototype this, I built a modular vent system using basic mock-up units that allowed for rapid construction and testing. Funnily enough, the first iteration of the vents was too small and caused players’ bodies to clip through the floor. I was able to rework my mock-up units and we settled on standing height instead of a crouching one. Once again we used yellow caution tape as our visual vocabulary to highlight the vent entrance on the wall.
Modifying the trains and vents is one of the factors that contributed to the map’s success and gave new players more confidence to explore the trainyard and lower claustrophobic tunnels. So now that we've explored the different possibilities for movement and giving the player more choices, it's time to buckle down and get our randomization system built.
Randomizing Objectives to Maximize Replayability
RNG is one of the core pillars of Payday, so every decision we make is looked at through a lense of RNG. We strongly believe randomization should be meaningful to gameplay and not just added for the sake of it. It’s important to ask questions like: was it worth changing all the cups in your level? Did you gain anything from swapping out all of your cars and buildings? Was creating a third entrance valuable to the level? Maybe one day we'll completely randomize every object in a building down to the smallest cups, but in a game like Payday I personally feel these types of things have diminishing returns and can often ruin a planned design.
When working with RNG it's important that you ask yourself as many questions as possible to start with a strong foundation, especially if you plan on finishing on time. Something I often see junior to mid-tier level designers forget is to build for scope and set priorities on their objectives. It might sound trivial, but forgetting your priorities can send you down a black-hole that eats away all of your time.
So how did we go about adding RNG into Murky Station? Breaking down our objectives, we can start to consider what RNG options are available and doable within our one month time frame. I've also labeled them with my personal priorities (low - high).
Break into the train yard randomize breach locations (low) Locate the Bomb Train randomize train configurations (high) Hack into the train randomize panel to flip sides (low - medium) Open the Vault 4 different vault door / key types (high) Find the Vault keys The map supported up to 40 hiding locations (med - high) Secure the EMP bomb parts 2 escape locations, 1 chosen per playthrough (medium) I focused most of my efforts on randomizing the train configurations, vault doors and key placement. These objectives were critical in influencing how the player would move through the main space and how they could tackle the same area in different ways through multiple playthroughs. In order to accomplish this, I broke down my sub-goals into digestible points of interest and isolated them into their own prefabs (shown below). Doing so allowed me to script one prefab and teleport it to as many locations as I wanted. This approach made the randomization more manageable to script and cut down the amount of bugs that might have formed if I built everything by hand each time.
Side note: We gave each one of our key / vault prefabs its own unique visual and audio so that players could identify them from a distance or listen if they were close by. Providing them with this level of feedback is critical in helping them make proper decisions while traversing the level.
Now that we have our vault doors and keys figured out, I can begin the planning process of placing them throughout the level. When placing them, each location must meet certain conditions before being finalized. The main goal is to provide the player with a challenge and also encourage them to be creative in tackling the surrounding area. Having designed the layout to have many interesting choke points and traversals, it was fairly straightforward where I could place them. Collecting the keys is one of the more RNG based objectives in Murky Station, sometimes all of the keys are in different corners of the map and other times they are all next to each other. Eventually there was a script clean up to prevent overpowered locations or terrible RNG possibilities, but overall it was a huge success for the level.
We generally kept the key locations central to the layout and tried not to place them too close to the player’s safe zones. Placing several keys along the outskirts was a nice change of pace from the main lanes, providing a different type of challenge due to the openness of the layout.
This is what the upper train yard looks like and how the keys are distributed. The lower tunnels have the same amount of keys placed.
We also used the same method for spawning the train interiors and vault doors. By creating one prefab and scripting it four times inside the level (one per vault door type) we were able to randomize the location of the players’ main goal with little effort. The engine also allows us to rotate our prefabs, giving us the option to flip the train interiors. This added a whole new layer to their configurations, since some of the interior layouts were asymmetrical.
We ended up with roughly 600 train configurations, 2000 vault door combinations, and 256 sub objective configurations. With 1 of 2 exits being chosen randomly each playthrough, this really changed what types of decisions got made by the players. It also influenced how they would flow through the level and took advantage of their diverse set of movement options.
On top of that we use non-linear objectives, which basically means you can do multiple objectives at the same time or in some cases, different orders. In Murky Station, players can simultaneously be looking for keys, searching through trains, marking guards from the overpass, and securing extra loot they find. This allows 4 players to comfortably split up to cover more ground and work off each other. A well coordinated team might have two players hacking into the trains to find the EMP bomb, while the others are looking for the vault keys. I find it very important to provide all players an opportunity to contribute towards the main goal.
Side note: With all of this randomization, you might be wondering how QA can test it all. The short answer: they don’t. We need to build efficiently to insure 90% of the level is solid, and then catch as many edge cases as possible. On the Payday team, the frontline of defense for QA is the designer making the level, It’s our job to test our own work thoroughly! The way the systems above were built would only required 1 prefab to be maintained for each example. This provides us the freedom to go nutty with the customization in the level, knowing it has a low chance at affecting our prefabs. So, as long as we build smart we can cut down the amount things QA needs to test and help speed up production.
With the objectives off to a good start, let's take a look at how RNG might affect our guard patrols and cameras in the level.
Guard Patrols and RNG
Randomization can have a large effect on how smooth or frustrating a level turns out to be. One of the things we have to keep an eye on when designing stealth levels is frustrating the player through poor patrol placement, amount of guards, and how long they pause at each location. The goal is to create a fun puzzle-like challenge, not a terrible waiting game. Bad RNG might have you sitting in a corner for one minute waiting for the guard to leave, only to have another guard take his place when that minute is up. It's our job as the level designer to help prevent such situations from happening by adjusting our timings, reworking the layout, or possibly the level’s mechanics. This is why it's so important to create a solid base for player movement options from the beginning.
Since we don't want our guard patrol RNG to get out of hand, we need to be careful about how they flow through a space. Doing this requires it's own personal attention and multiple iterations. Tilt too far in one direction and you'll end up with bare areas that have no guards, tilt too far in the other direction and you'll have too many guards stacked on each other with no wiggle room. The last thing you want is the possibility of a death chain reaction. This is caused when you kill 1 guard, only to have another guard 10 meters away spot that body... forcing you to kill that guard, who eventually gets spotted by the next, ect. In Payday 2, players have a limit of 4 guards they can kill before the alarm goes off (on all difficulties). In our levels, we have to actively manage the amount of crossover between paths and how often guards might meet.
In the first test pass for Murky Station I ended up with a good amount of coverage for my level, but the downside was that some sections could randomly get 8 guards piled up. After a bit of playtesting and redesign, I decided to break up my patrols into smaller loops and add more points. This increased the amount of coverage and kept the patrols more consistent. It also lowered the maximum guard stacking to around 4 and drastically reduced the amount of death chain reactions that could happen.
First pass patrol locations
Second pass patrol locations
(the new paths provide the same amount of level coverage with a less chance of guard over-stacking)
A fresh take on an old mechanic
In most of our stealth levels we use random static security cameras to challenge the players’ skill at avoidance or sabotage. The players have multiple mechanics in order to deal with them in a variety of ways, but we hit a brick wall when discussing options for Murky Station. Due to the hallway nature of the layout and the surrounding structures, we were left with very few options when it came to camera placement. With so few options, the cameras would be no longer modifying the level in a positive way. We also found them at odds with the design of the level, since you were supposed to be searching for a specific train car. If we had cameras pointing at it, you would be able to identify it too quickly and negate the challenge of finding it.
So how did we fix these issues? Getting rid of the cameras was not really an option, so we began brainstorming and looking for assets that might be of use. It's important the core camera functionality remain intact and also continue to meet our core pillar of randomization. We discovered an old drone asset for one of the previous levels and began prototyping a few ideas. The design we ended up going with provided us the coverage we needed, while also creating a new challenge for the players to overcome.
Each train can spawn up to two drones, which will then fly around the perimeter of the train and scan for players and bodies. Randomly throughout the level, three to four drones will be activated to begin their scan. The loop takes about 30 seconds before they return to their trains and deactivate. The cycle continues like this every few minutes until the level is finished.
On harder difficulties, more drones will spawn and they will become indestructible.
What's great about the drones from a design perspective, is that we can dynamically modify how the level gets played and prevent players from getting comfortable in using the same routes each play-through. Some players will avoid lanes with drones, more skilled players will dodge them using their movement options, and some players might even get trapped and need to think of a new routes. Let's take a look at the patrols and drones in action.
(This clip is sped up about 8x and set to the hardest difficulty to help illustrate pathing and drone movement)
Murky Station was such an enjoyable experience to work on that I still play it to this day. When you break down the objectives and how they influence one another in a co-op space, you can begin to see the bigger picture and how a well-planned level with controlled RNG elements can stay fresh and replayable. Experimenting with different types of RNG is something I find very interesting, especially when you combine it with level design. I hope my article gave you some more insight into how we build with RNG and why we consider it one of our core design pillars. If you found this article helpful, let us know in the comment section!
Thanks for reading, here is my Info :
Email: generalvivi [at] gmail . com
Before you go!
If you enjoyed this article and would like to hear how we used RNG in other ways, check out Patrick Murphy's article on the Payday 2 level "Hoxton Breakout".
I also have a speedrun (1min) of the level for you to check out and a playthrough on the hardest difficulty (10 mins) by one of the pros from the community.
Fastest time 2018 (warning to lower volume)
10 min gameplay video showing off a lot of variety in the heist.
Corwin reacted to PeteEllis for an article, Creating a Single-Player Combat Space
This article is the first installment in a three-part article that looks at the considerations for creating a single-player combat space, using a walkthrough of the first battle in ‘Killzone Mercenary’ as a working example.
Creating a Single-Player Combat Space Part 1
This article will explain how to create a combat space for a single-player campaign, using my work on ‘Killzone Mercenary’ (hereon referred to as KZM) as an example. There is already a fair amount of literature on the different methods you can use for creating a combat encounter, but I felt that none of it really discussed how to arrange the layout in closer detail, nor did they discuss where the different elements were appropriate. In my early work I tried to jam in all the concepts for encounter design without fully understanding how they affected the player’s experience. As strange as it sounds, I discovered there were times when it was better to restrict the number of elements being used to provide a much more focused and coherent experience; sometimes less is more. I will take you through an example to explain what I mean and how this can be the case.
I will use the very first combat arena in KZM as it’s a small encounter where I can explain in depth what goes into even the most basic combat space. This encounter is a fight against assault troopers who are trying to stop the player from escaping the building and reaching the objective building; the ‘Halls of Justice’. I designed bigger encounters that featured many flanking opportunities and complex circular navigability but focusing on a simple encounter allows me to explain certain techniques in detail and where I purposely removed some elements to balance the difficulty and give the player different experiences.
First of all I will explain two important aspects that must be considered for combat creation; AI metrics and weapon choice. I will then take you through a step by step walkthrough of this first encounter explaining in detail the reasons how it was designed and constructed for optimum player experience.
The design mantra ‘form follows function’ should be the basis when creating an arena layout; that is that the arrangement of geometry should derive from its purpose. The arrangement should support the function not only of the style of experience you want to create (is it a tight corridor section with close quarters combat or an open space with multiple routes and options, for example) but it should also support the main element that makes up the combat encounter; the enemy AI.
When considering the layout for the AI or non-player characters (NPCs) that will populate your environment you have to consider their metrics. These are the numerical values for how the NPCs move around and use the environment and the differences between various NPC enemy classes. This isn’t something people tend to talk about and so it can be easily forgotten or missed, yet it directly affects how your enemies will move and react.
For example, in KZM the standard enemy NPC class were the Assault Troopers. These soldiers could be given patrols and animations to perform whilst they were in an ‘unalerted’ state, just like every other enemy class. However, when they were in an alerted state their behavior changed so that they used cover points to move around the combat space. The maximum distance between cover points that an assault trooper would move was 10 meters. This meant that any cover point that was further away would not be considered, so we needed to make sure when creating combat spaces which used assault troopers that there were enough cover islands so they could move around. If there weren’t, the assault troopers would just stay in the same spot and could risk looking less intelligent.
The assault troopers also tried to maintain a distance of 15m whilst they were trading shots with the player. The behavior was that if the player got closer than this range, but not so close that they were in melee combat distance (5m), the assault troopers would retreat to this mid-range distance of 15m. They would also never choose a cover position that was closer than 15m to the player, so when we created combat spaces we had to make sure that there was enough variety of cover positions in the >15m range.
For the production of KZM we used the ‘Killzone 3’ engine and modified it for the PS Vita. In ‘Killzone 3’ the assault troopers picked their cover within a range that was further than 25m from the player, but we discovered that this was too great a distance for the enemy to still be clear and readable on the PS Vita screen. In our modified version of the KZ engine we had to reduce the combat distance to 15m, which meant that the original combat spaces we had created using the ‘Killzone 3’ metrics also needed adjusting in order for the NPCs to still work. It is an unfortunate truth that the game metrics, be it for the AI or otherwise, can change within a game’s development, which means that your combat arenas will also need to be adjusted.
The metrics for both the player and enemy weapons were also considered. As this is the start of the game we can be more certain that the player is using the default starting weapons, at least on their first playthrough, before they have earned enough credits to buy a new arsenal. Therefore, the combat distances of enemy placement were considered to be comfortably within range for the player’s assault rifle.
The enemy assault trooper archetype used assault rifles that were balanced to have a short range of <10m, and a long range of >20m. This meant that their behavior was to try and keep the player within these ranges and would thus move around the environment to try and maintain this. This was important to consider when building the environment so we could determine the amount of movement the troopers were likely to perform. This is important for balancing difficulty as a moving target is harder to hit.
As this was the opening of the game, we wanted to make it compelling in order to grasp and hold the player’s attention; we wanted to start with a bang. If the first lot of encounters in the game only included assault troopers with nothing else to differentiate them it may not have been so compelling. Therefore, we decided to include a significant Killzone enemy vehicle; the Helghast Dropship. Of course it would have been far too difficult to fight a Dropship at this point in the game, so instead it was used as an impressive introduction of enemies into the arena using the rappel ropes from the ship itself.
Using the Dropship at the end of the encounter, it was important to foreshadow its existence prior to its introduction. The level’s opening cut scene introduces the buddy character, Ivanov, and the narrative that he and the player are infiltrating the building whilst trying to avoid the searching eye of the Dropship.
The foreshadowing of the Helghast Dropship
Once the player has control they make their way up a flight of stairs learning how the movement works and feels whilst being in a safe environment. Once at the top of the stairs they enter through a door where they are introduced to the new melee attack which utilizes the touch screen on the PS Vita.
After a successful melee attack the player enters through the door to the first combat area. The composition shows the exit of the arena in the top left third of the frame. Central to the player’s view is where the first pair of enemies enter from, ensuring that their arrival is not missed.
The exit to the arena is in the top left section of the opening composition
Starting on the level above, the two assault troopers vault down into the gameplay space, to give their presence a more dramatic opening than merely walking in through a door. Their animation and movement also ensures that they catch the player’s eye if they aren’t looking in the desired direction. These vault down animations were 4m high, the standard height for a room in KZM, which meant this was a metric we had for the balcony and floor above.
Two assault troopers drop into the environment from the level above
Once the assault troopers had landed in the arena they became a lot less mobile than their standard behavior so that they were easier to shoot because, as previously mentioned, a moving target is harder to hit. As this is the very first section of combat the player encounters in the game it was important to ensure that it was easy to get to grips with.
None of the enemies were waypoint/navmesh restricted to certain areas in order to limit their movement as this could potentially lead to NPCs not behaving correctly under differing circumstances. In fact, there were only a very select few instances where we waypoint/navmesh restricted any characters in the whole of KZM; we instead crafted the environments to support the behavior we wanted from the NPCs. This was important for consistency; if you restrict areas and zones for the AI then they won’t behave consistently with what the player has learnt. This would lead to the player not being able to predict their behavior and therefore won’t be able to plan how to attack effectively.
Here, in this first section, the two assault troopers took cover at two upright pillars of high cover and an overturned sofa of low cover. They didn’t tend to venture further into the environment unless the player had for some reason retreated to the edges of the level. The reason they wouldn’t move and advance on, or flank the player was because the other cover options in front of them were within 15m of where the player was likely to be stood. This caused them to be more static and thus easier targets to allow the player to get to grips with the shooting mechanics.
I also chose to mainly use higher cover here so that when the enemies lean out of cover their shooting positions allowed the player to shoot their full body, which was a bigger target than when they poked their heads over the top of the low cover positions.
Low cover positions are great for seeing the enemies move around and change their positions, as the tops of their helmets are visible over the top of the cover. Enemies are much harder to track when they use high cover as it breaks line of sight to them, so this is usually the harder option. However, as they have restricted cover positions and weren’t moving around in this specific situation, it was the best option to use for less difficulty.
First Combat Front
A ‘front’ is the perceived line or boundary that faces the enemy and is the nearest position which combat should be engaged from. The ‘fronts’ used here create boundaries between the two sides; a front for the player and the buddy character and an opposing front for the two assault troopers. This was the simplest setup to start the player off with and it only required two sets of cover points as I didn’t want to encourage the enemy to flank the player at this stage. This section of the encounter only needed these few pieces of cover (in the image below) in order to work and the other pieces of cover were actually for further waves of combat.
The two fronts and the cover setups providing it
It’s also worth noting that the cover object which the buddy character crouches behind is positioned further forward than the arrangement of cover that the player is drawn to. This is so that the buddy character is in the player’s view so they always see the buddy’s actions and involvement. It wouldn’t be optimal to have a buddy NPC that the player rarely saw. The buddy is also kept near to the player in order to maintain a close relationship and the feeling of being a team. Empathy is directly related to proximity between characters, so if the buddy was further away from the player they would experience a much more detached feeling towards them.
Continue to part 2 or go back to the homepage.
Creating a Single-Player Combat Space Part 1
Creating a Single-Player Combat Space Part 2
Creating a Single-Player Combat Space Part 3
Copyright ©Peter Ellis 2016. Killzone™ Mercenary is the property of Sony Computer Entertainment © 2013. Killzone is a trademark of Sony Entertainment Europe. Killzone: Mercenary is a trademark of Sony Computer Entertainment America LLC.
Corwin reacted to Froyok for an article, Technical breakdown: Assassin's Creed II
The following breakdown is based on my own guesses and how I understand the game from the textures and meshes I have watched. I can't tell you exactly if I'm right or wrong since I'm not a developer of the game. However, I believe I'm rational enough to think that most of what I say is close to what the developers have done. The purpose of this breakdown is educational and the work presented here belongs to its respective authors.
Anvil engine The Anvil Engine is a proprietary game engine used by Ubisoft's game projects for a few years now (the first game using it came out in 2007). We can call the Anvil Engine a next-gen engine since games for the previous console generation (like the Playstation 2) were using the Jade Engine at Ubisoft. The first project using this engine was the first Assassin's Creed game. Its initial engine name was Scimitar (before the release of the first game). Today, eight games are using this engine.
The engine has since been updated with Assassin's creed III under the name 'AnvilNext'. Mostly to support the new game challenges and configurations that we have today and probably to be ready with the future game consoles coming along.
Atlas and batching As with every open world and/or huge city, you have to deal with a very high number of resources. Mostly to keep the player in a fresh world and avoid repetitions. Games over the years have used various techniques to get past this problem. One of them is to reuse any resources that you have created. Creating a texture for only one object in this type of environment can be a problem in term of memory footprint. So reusing a texture will allow you to keep you memory low in size. Pretty obvious, however it's a hard balance that you have to deal with: diversity versus quantity.
The size of the memory is not the only problem that you will meet; the number of drawcalls is also very important. As a reminder, a drawcall is a call to the API (the functions of the GPU to draw a set of primitives). For each frame that you render, you have a certain number of drawcalls. Each time you call the API to draw something it takes a given time, regardless of what you want to draw. So you want to be sure to reduce these calls to avoid any loss of performance (taking too much time to draw a frame will reduce your number of frames per second).
Each time you change a mesh for a new one you will create a new drawcall, because for the engine it's not the same geometry. This rule applies for the shaders too. If you change the shader, you don't render the same thing, so you have to change the way you render it. This means a new API call.
A common solution to this is to batch your calls. 'Batching' means to group some meshes together before calling the API to draw them. This is why it takes less time to render a big mesh than multiple small meshes. How to batch these meshes if chosen by the engine, there is no best rule for this and it depends a lot of what you want to draw. In the case of the Anvil engine, you are focused on drawing large and open spaces. The best way to improve the performance in this case is probably to batch per shader. So each geometry using the same shader will be sent together to be rendered. This way, reusing textures will allow you to batch a lot of things and gain a lot of time.
So using atlas textures (multiple textures merged as one) will be a great benefit: you will reduce your memory footprint and you will use only one shader for multiple objects showing different things. Assassin's Creed II uses this system a lot for the environment and the characters. Since we evolve in cities, some houses are often similar, it is logical to find the same design multiple times. Which means that reusing a texture would not shock the player. It will even help for the visual consistency of the level. However, I believe that the engine was not perfect and due to some performance problems (maybe because of the dynamic lighting) they limited the number of textures. In Venice for example, you have an average of 1500/2000 textures in memory (including everything: sky, water, normal maps, shadows, characters and so on).
What do the textures look like exactly? In this game, textures for the walls are often around 512 x 512 pixels. Details, ornaments, water use 256 x 256 pixels most of the time. For example, the roof texture is only 256 x 256, but the tilling is so well made that it doesn't gene at all.
However, these textures being very tiny, the developers used vertex painting to blend details and break the repetition. Since there are almost no specular reflections in the game (probably to strengthen the feeling of the walls are made of bricks and dirt) the vertex painting masks are stored in the alpha channel of the diffuse texture. As you can see in the second screenshot below, the alpha mask uses very defined greyscales, probably because they separate each level of grey as a separate filter.
The textures are very bright, and we feel that in-game: the overall lighting is itself very luminous.
Levels of details Dealing with an open world means dealing with a very long view distance. Therefore, the farther you see, the more you need to draw. Unfortunately you are limited by the hardware (especially on consoles) and you will have to use some LODs (level of detail). The developers have chosen to let the LODs 'pop'; this means no blending transitions between them, which is visually ugly since you notice the change.
The environment collisions are dissociated from the visuals mesh. Probably because you can more quickly hide/disable the collisions of the environment since they are not visually displayed on the screen. This explains why forcing the LODs of the environment allows you to... climb the void!
On the PC version, you can increase the minimum distance for when the environment starts to blend (which is something like 40/50 meters if you blend at the furthest possible distance). It's also interesting to note that some props like barrels, crates and other little things are independent of the global LOD distance. It seems that some props are linked to the LOD of the building mostly because they are at the roof level, while props in the street have their own blend distance.
Characters Pedestrians in Assassin's Creed are based on modular characters. The developers use a set of heads which are combined with hands and different clothes. While the hand and heads have their own details and colours, the clothes are just a totally grey shared texture (except for the letter) and coloured in the shader to add variety in the game. They also add a detail texture to break the linearity of the clothes and bring up some fine details. Characters have also their own LODs.
During a presentation at GDC 2008 about the first Assassin's Creed, Francois Levesque (a technical director on the game) explained their pipeline to produce a lot of different characters without losing too much time. They used a base head which blends to fit to the high-res character. This way they automatically get the LOD mesh at the same time since the meshes always shared the same topology. The only update to do was for the position of the bones on the top of the vertex to keep their skin deformation.
Since meshes and UVs are similar, it's easier to manage and create a crowd dynamically. So there are maybe 5–10 different clothes and then the game dynamically creates a character to add it in the game scene. In the first Assassin's Creed, characters had 2 LODs, which meant 3 meshes per character. In Assassin's Creed II it's the same thing. However it seems that the clothes and the head don't blend at the same time. Probably because they don't have the same space occupied on the screen. So the heads go to their first LOD mesh sooner.
You can see some examples on zBrushCentral with the base mesh topology and also the topology of some bodies used by the game.
Lighting The Anvil engine is an engine developed to mostly show open environments. With the development on this second opus, they wanted to add a day-and-night cycle. To achieve this they naturally chose the cascaded shadow maps technique (more exactly, Parallel-Split Shadow Maps as described in a GameDev.net forum thread) which even today is the best way to draw a unified shadow on such big environments.
There is no Global illumination at all, it's mostly only a main directional light (the Sun) combined with an ambient colour which evolves during the day. Some interiors like the tombs present localised point lights; there are also some point lights which are enabled during the night.
However, regarding the performance, they were obliged to use a very low resolution and a blend distance. This explains why you see a lot of blurred pixels on the ground/walls for the shadow. This is also why you so clearly see the blending of the shadow from one level to another.
Some shaders use the Fresnel term to enhance the looking of the character clothes a bit, but most of the time they simply use direct lighting without complex shaders (again, because it was very expensive). There is no fake sub-surface scattering (SSS) for the characters, even during the cinematics. The SSS only comes in with Assassin's Creed: Revelations and will be improved for Assassin's Creed III.
Conclusion Assassin's Creed II was a really good improvement compared to the first game, however it looks like the engine faced a lot of new constraints which were not totally well handled. The way the LODs appear and the nice but still limited quality of the lighting are good examples of that. Even on modern computers today the game gets some slow-down in certain places.
The engine was improved for the next game iterations and increased the amount of details and the quality of its lighting to finally show beautiful cities as we can see in Assassin's Creed III today.
Corwin reacted to Thrik for an article, Interview with Jean-Paul Jarreau, Black Mesa level designer
Tell us a little about yourself. Where do you live, and what's your day job? Oh man. I unfortunately live in Rochester NY (no its not driving distance from NYC) and am currently unemployed. I graduated college with a degree in Photography and a minor in Philosophy in 2011 and worked for my step father's company until july of this last summer. So I currently spend all my time working on levels and photography, I honestly cannot complain right now.
When and why did you decide you wanted to bring worlds to life in 3D? When I was 14 I had a passion — playing games. I loved it, it sparked something inside me and I had no idea what it was, but I liked it. My personality can be pretty analytical at times so naturally I tried to figure out how to make them. I love architecture, buildings and 3D space, so I just went for it. I spent hours and hours in every level editor I could find and I, admittedly, stuck with hammer because it was the easiest to pick up, had the largest support and the biggest community. I've been with it since. That's what, 9 years? 9 years of blue screens and move_rope causing crashes straight to the desktop — it's a love–hate relationship.
How did you get involved with Black Mesa? This is funny considering the level of amateur crap I have made. I applied to Black Mesa back in 2004/2005 by sending a VMF to the founder of Black Mesa (Jon) of my recreation of the first Power Up level. It was a mess and ugly as sin. I had quite literally no idea what I was doing, but it was satisfying to create, so I kept with it. I clearly remember Jon's words: "It looks, eh, amateurish". So, I spent the next few weeks refining my work and I applied a few other times. I eventually got on the team and I started work from there. I remember a good friend of mine, Daniel Junek, was already on the team and when I loaded up the private developer forums and saw his orange map layout of the blast pit silo, immediately knew I was going to be on the team for a long ass time — I saw what COULD be Black Mesa and was instantly inspired.
Funny story: I always considered Daniel's work (he did Blast Pit) to be godlike, it was just incredible, I had never seen anything of such quality and ridiculous planning and care. I have this habit of comparing anything I do to the current best work in the world so I know how to improve myself and I considered Daniel's work to be the best in the world. So, naturally, I compared my work to Daniel's and for years it never even compared, but I was slowly getting there. So, a few months ago I, slightly buzzed, messaged Daniel on steam and came to realize he did the same thing with my work this entire time.
I joined the team and looked at what was available to work on and I, of course, had to pick Lambda Core. I had no idea what I was doing and some of the early parts of Lambda Core show that.
What was it like getting to reimagine the world that kicked off many MapCore members' interest in level design? Oh wow I never thought of it this way. Want to hear something hilarious? Before getting on the Black Mesa team I had never played Half-Life before aside from one or two killbox matches on a friends computer.
But as for re-imagining a world that so many hold dear? Its a difficult process, at least for me. I wanted to strike people on an emotional level with my work, I wanted people to see certain things I made and say "Holy shit, this is amazing", and while I don't know if I have accomplished that or not, I do know that getting there was an intense process.
I remember loading up a Lambda Core map and thinking to myself, "What makes this interesting? What makes this bad? What makes this fun? What makes this area instantly recognizable? How do I create something in the present that completely awed those in the past? It was honestly tough in certain parts and I can remember re-doing sooooo many parts of the game because I personally thought it didn't hold up to any creative scrutiny.
Were you often tempted to take a whole new approach to parts of the game? How did you find the right balance of old and new? This is a good question and I bet some die hard Half-Life fans still think we screwed up parts of the game haha. For me it was mostly taking a look at the original and what it tried to accomplish and improving on that. Sometimes certain areas didn't even need improvement, it just needed refinement, an extra level of polish to really take home its intended goal. When there was a controversy over what should be done in the game, we would just look at the 'numbers'. Did a majority of Half-Life players like this certain area? If not just scrap it and try again but be sure to retain the original's emotional impact on the player.
Did it ever feel like Black Mesa might never make it? Was your motivation affected? More than you can ever imagine. We worked on it for about 9 years remember! Honestly? It probably felt like we weren't going to make a release more than we were going to make a release. There were periods of inactivity on our developer forums for months at a time. We all have personal lives to attend to and sometimes it would be a perfect storm of events where no one would work on anything for extended periods of time. Then, out of nowhere, something would happen and everyone would get sparked and jump right back in and get loads of work done for months. Rinse and repeat.
In the SUPER early stages of development there was a point where we didn't even have a coder for 2 years. You can only imagine how incentive was on the team at that point.
There's still a significant portion of Black Mesa yet to be completed. Will it be purely new material when the remainder is released, or are you revisiting and/or expanding existing material? I will answer with a simple work-in-progress screenshot of something I am working on and nothing else:
What do you think is a stand-out part of Black Mesa? I have actually never thought about this! But the FIRST thing that jumped into my head is when you first enter the turn-table room in Power Up. You witness an intense fight between a Gargantua and a few human grunts. It's incredible because of the collaborative effort that went into it without a single f**king hitch. It's like it was done by one person! Let me explain:
You enter a beautifully themed section of the facility created by Daniel Junek You witness well crafted animation by Nate of the Garg getting blasted by a human grunt and consequently falling into and breaking the concrete wall near him. The Garg was made by Chris The surrounding textures are made by Mark The dead human grunt bodies turning into scorched corpses, the flame effects, and the Garg behavior was done by Paul and Mark All the sound was done by Joel Look at that! It's the personal work and vision of a team of people all together forming a unified and impressive quality of interactive work. It wouldn't even be possible to create something that well done by one person.
Now you may say "Hey, thats how all games are made." But, its a little different when you are creating something of this size and scope and all you have to communicate with your co-workers is Skype and a forum. There were a lot of times when I would be making a gesture with my hand or something while trying to describe the way I want a prop or texture to look. That was frustrating.
You do a lot of multiplayer level design in addition to your single-player work. Which do you prefer? Single player is telling a story and using the environment to make playing the story fun and visually interesting while guiding the player through a struggle. If you can hold a player's attention and feed them the facts then you are good to go. Multiplayer is about cohesive design and fun welding itself into one entity and that can be difficult at times. Honestly I probably prefer the multiplayer work because of repetition. You know players will be running around your environments thousands of times which will eventually lead to an appreciation for the map on tiers usually only seen by the actual level designer. That is a double edge sword though.
Briefly, what's your general workflow for putting a level together? LAYOUT, LAYOUT, LAYOUT. I try to get simplistic layout for a map that is fun and cohesive before doing anything else. Why do you play a video game? Because it's fun, and as a level designer, that fun can be directly proportional to your quality of work. You are almost like a spokesperson of your entire team's work and I love it. I mean I could tell you about all my thought processes while I work but that isn't as fun. But, I usually tend to think of ideas in a 3D space, so I never really draw layouts, I usually just throw some brushes around to get my idea out of my head and see what can be made of it before I attempt any sort of real layout. A lot of my past ideas failed even before getting to the layout stage, so that is good (I think).
Which bit of the process is your favourite? That part in a map's life right as you know everything is fun and you get to unleash your thematic ideas you had been planning in your head while working on the gameplay and layout.
And your least favourite? Any sort of tedious mind numbing repetition is annoying. Or when you spend a long ass time solving a problem in your level only to have it come out like crap but its 5am and you have to go to sleep knowing what you just created is terrible. That's no fun for anyone.
What's the hardest problem you've encountered while mapping? Writers block can apply to anything really. There were times where I would just stare blankly at a map for hours not knowing what to do. Recently though? I cant stop with my ideas, it's great. I'm trying to ride that wave for a little.
Also, scrapping something you have put a massive amount of effort into can be disheartening but it has to happen sometimes. But what essentially is anything creative? It's the formation of an idea while hiding your influences. Sometimes these ideas need to go through an emotional struggle before work can continue.
Which piece of level design are you most proud of? To date, my Black Mesa magnum opus is most definitely the final Lambda Core teleporter and its prior lower reactors. Fun fact I thought some designers might appreciate: the entire Lambda Core reactor and teleporter actually lines up like an actual facility if you copy all the maps into one file and place them correctly.
More recently? It's my map cp_imbricatus for Team Fortress 2. I have a feeling that the map will fundamentally change the way a good three-control-point attack/defend map should play.
In addition to level design, you're an accomplished photographer. How did that begin? Accomplished? Oh you. Thanks, you.
Here is a story I have never really told anyone haha. I was an idiot in high school, I mean who wasn't? But when it came time to apply for colleges, I just straight up didn't make the cut. I applied to stupid high reach schools and nothing else, I think I even applied to the wrong program in a few schools. Needless to say, I didn't get in anywhere and I panicked. My mother had some connections at Rochester Institute of Technology and randomly one day called me while I was out and asked me a few questions:
She said, "I got you into RIT and their photo program doesnt require a portfolio, which would you like to do? Fine art, photojournalism, advertising or biomedical photography?" I got lucky and I knew it. I wound up graduating with a bachelors of fine art in advertising photography. Crazy.
A lot of your photos are taken in very challenging conditions, such as live music performances. What skills and equipment do you employ to get such great results? Simplicity is key. Both visually and philosophically.
You must look at every situation like you are the one viewing the content with no prior context as to what is going on. Do you want to portray a story? Do you want to create something purely for its visual content? What's your end goal? I could honestly talk about this for hours.
I currently only use a Canon 5D Mark 3 and the only lens you ever need — a prime 35mm f/1.4. A good photographer with a bad camera is going to make better pictures than a bad photographer with a good camera. I also adhere myself to a lot of personal restrictions (in level design as well). An example being I never crop any of my images, I always thought it was best to just leave it straight out of camera. I do Photoshop my images, but I don't crop them. (Note: if you are a client that hired me as a photographer, I will do anything you want to the images if you request it. These rules usually only apply to personal work.)
Keep an eye out on my Tumblr for some new photography coming up soon.
Do you find that your photography skills bleed into your level design? For example, when composing scenes? Absolutely! And it works both ways too, photography helps my level design and level design helps my photography. Lighting plays a more important role in both than most even think. I am just lucky to have experience in both.
I don't want to toot my own horn here but look at the lighting in some of the reactor areas in Lambda Core. It got to the point where I set 50% and 100% falloff distances with a hard cut-off for the yellow lights surrounding the central cylinder so the centre reactor would ominously glow yellow without casting any mood changing light onto the surrounding geometry. Does that level of detail pay off in the end? I don't know but I hope so.
What games would you say have inspired you the most? I have never thought about this before but here is a list of the first games I can think of to inspire me:
Ocarina of Time: Video game perfection. Majora's Mask: I cannot even put into words the impact this had on me Wind Waker: How do they even make this stuff? It's like they converted crack cocaine into playable form. Half-Life: Was I obligated to say this? This game changed what a first person shooter could be with its incredibly inventive layouts and story telling. Painkiller: The basic first person shooter mechanics perfected and in gory glory too. Incredible environment art to boot as well. Banjo-Tooie: Incredible game design, just incredible. Battlefield 2: The amount of serotonin released in my brain by playing this game should be illegal. Super Mario 64: An amazing sandbox game before that term ruined a lot of modern day games. Far Cry: It materialised my emotions while playing a game by me actually muttering the word 'wow' while playing in certain spots. There are loads more but these are just what I could think of off the top of my head.
If you could give a budding level designer a short piece of advice to help them succeed, what would it be? Your work is going to suck for a long time, get used to it. If someone is being a dick about your work, they probably have a good point. Listen to them without bias. This will push you beyond what you thought you were capable of. You made the level, no s**t its easy to understand by you — other people HAVE to play it before anything is considered good. Scale will make or break you. Do a lot of scaling tests in every game you want to develop for before attempting anything else.
MapCore would like to thank Jean-Paul for his time, and wish him the best of luck with his future projects. You can enjoy more of his work by visiting his portfolio and Tumblr. He's also looking for people to help out with testing his latest Team Fortress 2 map; simply download 'cp_imbricatus', take a peek at the
and join in on the tf2maps.net server.