Massive interview with Pete Ellis, an experienced level designer from Guerrilla Cambridge studios.
Pete has worked on "Killzone Mercenary" for the Playstation Vita, and "Killzone Shadow Fall" for the Playstation 4. He is currently working on "RIGS: Mechanized Combat League", a Playstation VR exclusive.
After Pete contributed 3 extensive tutorials on Single Player Level Design Pacing/Gameplay Beats (1, 2, 3) and Seeing the World as a Level Designer - I had a lot of questions I wanted to ask Pete and learn more from him.
The interview goes deep and we discuss a lot of topics.
Interview Topic Overview:
Now, get ready and let's dive right in...
I'm from Birmingham in the UK and I currently live in Cambridge as I have been working for the Sony studio 'Guerrilla Cambridge' for the past 5 years. In this time I've worked on "Killzone Mercenary" for the Playstation Vita and "Killzone Shadow Fall" for the Playstation 4.
I'm currently working on "RIGS: Mechanised Combat League", which we've built from the ground up exclusively for Playstation VR. It's a first-person arena based shooter set 50 years in the future, where you get to pilot giant Rigs and compete in the sport of the future; the mechanized combat league!
Prior to this I worked at 'Frontier Developments' for two and a half years, also in Cambridge, on a third-person open world game "The Outsider" but unfortunately it was cancelled so never got a release.
I always knew I wanted to make games since playing Mario on the NES as a kid, so I took my education on that route and did a degree in 'BA (Hons) Computer Games Design' at Teesside University in the north of England.
This was quite a general course so at the end, although I had my degree, I didn't have a specialized portfolio. I also thought at this point I wanted to be an artist as this was the main focus of the course and we hadn't experienced working within an engine yet.
I tried applying for lots of different artist jobs but didn't get any interviews and one reply I received was that they didn't have any animation positions. I hadn't even applied to be an animator! But that taught me a very important lesson; that my showreel was crammed full of all the work I had done at Uni and so had lots of animation in there as well – I hadn't specialized, nor shown my best work but rather all of my work!
I went back to Teesside University to do a Master's degree two years later and studied MA Computer Games Art. This is where I first experienced the Unreal Engine and fell in love with design; it was exactly what I had wanted to be doing - making games!
This time round I focused all my effort on creating levels by modding Unreal Tournament 3 (even though this was self-taught as the course was teaching Unreal Engine 2 as Unreal Engine 3 wasn't released to the public until half way through the year). After gaining a distinction in my Masters I was also armed with a specialized showreel and portfolio of level design, so within 2 weeks of finishing Uni I had started work as a Graduate Designer at Frontier Developments, which is when I moved to Cambridge.
We have a fairly large team here at Guerrilla Cambridge, around 60 people, so when I work on a level I usually work alongside two environment artists and a concept artist. I am responsible for the layout and gameplay of the map/s and so I don't create any environment art but rather greybox layouts.
click on image to view full size
Design and art go hand in hand though, so both disciplines overlap each other.
For example, I might have a requirement for a certain piece of geometry to contrast with its surroundings and be unique so players recognize it and use it as a landmark and call out positions to other team mates. Sharing this with the art team influences their work but they also influence my layouts as well.
I like to get the art team involved from the start as their input can help my layouts utilize art theory well, such as composition and leading lines, to help make the map as great as possible from the start.
My responsibilities change depending on whether I'm working on a multiplayer map or a single player mission.
For both types of level I'm responsible for creating and maintaining the gameplay. This includes creating the greybox layouts at the start as well as working closely with the artists as the levels get further into development. When a level goes through art passes we stop using the original greybox, although we can refer back to them when needed, and instead make changes and iterations inside the art layers.
For multiplayer maps I'm responsible for making the levels playable with the enemy AI, which requires special objects for them to successfully play the game modes. These can include such items like 'beacons' (which is Killzone Shadow Fall's take on flags for capture the flag), capture points or demolition objects. I also need to create and maintain a waypoint navigation graph for the AI to be able to move around the environment.
For single player missions I create combat encounters using a visual scripting language, similar to that of say Blueprints in Unreal or Flow Graph in CryEngine. In addition to markers, zones and trigger volumes this also needs the waypoint navigation graph for the AI.
There are many, many more responsibilities depending on the style of game we are creating.
Fundamentally, a designer communicates between all the disciplines and brings it all together to create the best experience for the player. This does mean you will have to fire fight any unforeseen issues that arise!
The process differs slightly depending on whether we're developing for single player or multiplayer levels, but they all share the same basic structure. This is:
On single player missions we start by getting a brief from the Game Director about the overall idea for the level, including the important story beats, what mechanics we might introduce and the characters involved. From here we can start planning the level in a lot more detail and determine how we want the level to unfold and what requirements in gameplay we'll need.
I have previously written an in-depth article for WoLD on how to structure pacing and gameplay beats in single player levels here:
Armed with a solid plan we then start to create the greybox in the 3D modelling package Maya. This is done as quickly and as simply as possible so that we can get it into the game engine early in order to test the size and scale.
Additionally, with simple geometry you don't have as much investment in it than if you'd spent hours or days refining it. This means you're much more likely to be happy to change or remove geometry that's felt to need improvement, which is very important for iterating. You can't be precious about your work as parts of it will need to change to advance the level.
Early on during the greybox process we also include the proposed enemy encounters. This is so we can understand the difficulty of the level, as well as the pacing. Additionally, the layout of geometry has to support and compliment the AI behavior so it's important to start building these areas early.
As the level progresses it gets attention from the art team and in turning it from a greybox to something pretty, it inevitably means changes.
Artist improvements are also made to the level, such as improved compositions or tweaking leading lines in the main structures to subtly draw focus to important areas and so the design adapts to accommodate these. It's also important to maintain any important sight lines or visual blockers that were created in the greybox as inevitably they will be changed when they get arted.
For example if you've provided a box that blocks a line of sight into a different area, if this gets arted in a more organic way this might cause glimpses to the other area that aren't desirable. Collaborating with the art team can correct these issues whilst maintaining their artistic vision.
Eventually the level will be developed to a point where it's of release quality and so you're then into the last phase. This is optimizing, bug fixing and polishing tasks. Optimizing is to make sure you have a solid frame rate with no drops and it can be achieved through many elements, such as tweaking what assets you stream, removing entities after hard gates that won't be seen in the level again, or making sure no closed areas have remaining AI trying to navigate to the player.
An example of optimization that you wouldn't necessarily think about, or know had happened, from Killzone Mercenary is the spawning. If we spawned multiple enemies at once there would be a few frame drops as the new characters would all try to calculate navigation paths simultaneously. Although it wasn't that noticeable we strived to smooth this by adding tiny 0.1 second waits in-between each enemy being spawned. Whether you call this polish or optimizing, this is the kind of attention that goes into the game towards the end of production.
There is a fundamental difference between single player levels and multiplayer levels in who they are created for; single player you are designing to be in favor of the player whereas multiplayer is designed to be balanced. This means that in single player levels the player should stand the best chance of surviving or having success, whereas in a multiplayer map it has to be balanced for multiple people so that the only difference between these players is their individual skill.
When designing multiplayer maps you focus a lot of time on creating a balanced map so one team doesn't have an advantage over the other. For example if one team's base was higher up then they would have a height advantage to start with. There can be areas nearer the center of the map where you might want to include elements that actually give an advantage, so it gives the teams something to fight over. This could be something explicit like an emplaced turret, or something less obvious like a high vantage point or a sniper perch.
It's important to create flowing loops and figure of 8s in the routing for multiplayer maps as well, so a lot of time is spent creating these paths to allow for interesting and satisfying experiences.
Most of the time single player levels need to consider a narrative and so the gameplay beats are structured accordingly. A lot of time is spent planning the level timeline in terms of pacing, as we need to consider both high octane action sequences as well as down time and periods of calm. Once a map is in greybox development we spend a lot of time creating satisfying combat encounters that suit the player's skill level according to how far in the game they are.
Although I do enjoy creating multiplayer maps, I'd have to say that my passion lies in single player mission creation. This is because I love to sculpt the experience I know the player will have, focusing on the gameplay beats and the narrative, whilst controlling the pacing at which this all unfolds.
I would say they should make sure to create a coherent experience. Yes you've got some really great ideas, but if you just jammed them all in together randomly without proper structure it wouldn't play very well. This is where planning the structure of the gameplay beats and the pacing really pays off.
For example, if you want to have a puzzle where you gain entry to a locked building by blowing a hole in the wall using a certain type of explosive, then you want to make sure that the player already knows how to use this mechanic so they can figure the puzzle out (unless of course this is also going to be the point where you introduce and tutorialize the new explosive). Therefore, you must make sure to plan beforehand to have either a reminder of the mechanic you want them to use so it's fresh in their mind, or a tutorial if they haven't used it before. It would be best to include this in a period of downtime as well so it's not missed during combat. From this you then know in your plan you must place this section between any combat encounters. This is how your structure begins to form and allows for a much more satisfying experience for the player.
For building a multiplayer arena I would say that it's important to start out by focusing on creating a balanced map for both teams. This means that the time it takes for both teams to reach the same objective should be exactly the same. It also means that for game types where the objective is simply to eliminate the other team, such as Deathmatch, then the loops and flows should be equal for both teams where one route doesn't favour a particular side. The exception to this is if your game uses base camps for respawning, in which case the first set of routes extending from the base should favour the home team.
The Statue of Liberty head in Crysis 2's 'Chasm' is a unique call out point:
A good way to start with multiplayer arena creation is to make a symmetrical map.
This way you know that the routing and timing is exactly the same and doesn't favor one team. When doing this however, you need to make sure that you change the art between the two sides to make them unique so that you don't confuse the player as to which side they are on. Making unique areas helps with orientation as well as creating call-out areas for communicating between team mates. This is where something in the environment is so unique it can be used to say to your team mates 'the enemy is at the <UNIQUE THING!>'. A good way for creating call out points is to make sure the object or element has a colour and a single line 'descriptor'. So for example you could have 'the enemy is at the gold statue' or 'the sniper is hiding behind the red car'.
As I mentioned earlier it's important for a map to be balanced even though not all of our maps are symmetrical. Another key principle is to have a readable environment so that players can understand the routing clearly.
In 'RIGS' we have a strong use of colour to draw people's attention to important routes, such as the route to the 'Power Slam' goal in that game mode. This routing is yellow as we use a consistent visual language throughout the game to signify the goal and the states associated with it. For example, the color on the HUD (Heads-Up-Display) is yellow to tell the player when they are in 'overdrive' which is the state they need to be in in order to score. We also mark players with a yellow trail to indicate when they're in overdrive so other players know to either focus their attention on stopping them, or if they are on their team to try and help them.
To further improve the readability of the routing we have calmed down detail in certain areas so that they are less distracting, which helps with the player focusing on and understanding the layout more easily. For example, in the map we showed at E3, Rio de Janeiro, the tunnels in the central structure have lights inside them above the entrances. Not only that, but the surrounding walls are darker shades so by contrast the tunnels stand out to you. All together this means that if you quickly skim the environment you can understand the routing and choke points clearly.
Working in VR is completely different from traditional game development! When we first started we thought we could bring everything we have learnt from previous games on to 'RIGS', but we quickly found this was not the case! I unfortunately can't discuss much about the levels in any detail as it's not released yet and so far we've only shown two of the maps.
However, one example that's not specific to 'RIGS' that anyone working in, or interesting in working with, virtual reality might find interesting is that a big difference between 'traditional' games and VR is that the viewport is not a camera; we can no longer take control of it as we had done before. The viewport can only be moved by the player's head. Whereas in traditional shooters it's become standard now to have camera bop when the player sprints, this is something we had to remove very early on. Taking control of the player's head can make them feel uncomfortable, so it's a strict no-no for VR games.
Camera shake effects like the 'roadie run' in 'Gears of War' is not something you should use in a VR game as the viewport is no longer a camera you can take control:
Another difference in developing a VR game is that it's paramount that we maintain 60 frames per second or higher at all times, at every stage of development. Traditionally, we have been able to start making a game where the frame rate is lower to begin with, but as the project goes on and gets optimized, the frame rate improves.
With VR however, there's no way you can validate the design or the new mechanic if you're not running the game as it's intended to play as the experience of being inside the virtual environment is different from watching a screen.
For single player I would highly recommend not only playing but also studying 'The Last of Us' by Naughty Dog. It's a master class on how to create a narrative driven single player game. There are so many elements in this game that are well refined and polished, but there are also a lot of subtle things the player wouldn't notice that are important to consider for a well-designed game.
For example, something to look out for, which is almost invisible to the player as it's done so well, is the implementation of hard gates. They use these points that the player can't backtrack through in a way that supports the story and situation the player finds themselves in. For example, when leaving a safe place an animation plays of securing a door or covering a route behind you as the characters want to keep this place safe or unseen. This stops the player from going backwards to help progression as well as allowing for elements to be streamed out, but it also fits with the context of the situation.
If you don't have time for the full game the DLC 'Left Behind' is also a master class on level design and is a perfect example of excellent reuse of an environment. Without spoiling too much if you haven't played it, one part of the DLC is set in one area, but the objectives pull the player through in different directions and you experience the environment from alternative views. It's actually just one building but it's done extremely well; a great example of an efficient design.
One of my favorite games in terms of multiplayer is 'Crysis 2' by Crytek, with my favorite map being 'Skyline'. This is an excellent example of form following function; the map is created to utilize the game's traversal mechanics throughout. The layout is readable in what you can and can't use, as well as what powers you will need to use to take advantage of them.
The structure of the main routing is a figure of 8, which makes the experience of traversing the map flow well. There are plenty of 'pro routes' that experienced players can find in subsequent play-throughs which ensures the level doesn't become repetitive. Additionally, all the different areas of the map are very unique so call-out positions are instantly recognizable, meaning orientating yourself within the environment is easy as well as communication between team mates being efficient and effective.
click on image to view full size
I think the first piece of advice would be to not be afraid of failing. There's a design mantra 'fail faster' which refers to the speed of iteration and development. It doesn't mean that you should purposely aim to fail, but rather that you will inevitably fail at the start so get through that process quickly. If you spend ages trying to get one aspect correct before committing full production on to it, it's going to be hard to change anything that's not working as you won't have the time; the later you fail, the harder it is to change.
Failure isn't as negative as it sounds, in fact failure should be seen as getting one step closer to getting it right. You have to know what extremes or boundaries you have for your design, so it's actually best to find these out first rather than trying to find the final design first try (as you most likely won't). For example, if you tried an enemy's weapon damage as causing 50 hit points to the player but you found this was tough, you might be tempted to try something like 40 hit points in the hope this would be spot on. If it was still too tough you'd then have to try, say, 30 hit points and try from there. If this was getting a lot closer, but still not quite right, you might start changing it in smaller intervals, such as 28 hit points.
If however, the first time you tried something different to 50 you purposely overshot just to find the extreme you might have tried 20 hit points. You might then have found that actually this wasn't too bad and the final number should be something closer to 20 than 50, then you'd have a better idea of what your third try would be.
The second piece of advice would be to consider process earlier. At the start of my career I was giddy with excitement to start building games I wanted to play! However, as there's always a pressing time pressure with making games, it's important to also focus on the process of how you're creating games. Even though this isn't the most glamorous thing to be focusing on it's an important part that allows you to speed up your workflow and generate more work.
A good quote I found a few years ago that summarizes this perfectly is in a small book called '101 Things I Learned in Architecture School':
"Being process-oriented, not product driven, is the most important and difficult skill for a designer to develop"
The third piece of advice I'd say is to look into 'emotional intelligence and insights' early. This is the ability to not only understand people's emotions in a professional environment but also an understanding of how different personality types perceive themselves and others.
So for example my personality type is that I'm enthusiastic, energetic and sociable. This isn't necessarily how everyone else sees me though and someone of the opposite personality type might see me as hasty and disorganized. Conversely this same person might see themselves as formal, precise and deliberate, whereas I might see them as cold, reserved and lacking passion. There isn't a 'correct' way to be as different personality types see each other differently, and this is important to know in order to work together effectively.
We always have deadlines, be it professionally where we have explicit deadlines for ensuring the game gets out to market, or when creating a personal project in your own time. This is because as we are making our art if we had forever to do it we'd never finish it. We could always be tweaking and changing minor things and it would ultimately never get done.
It is important to priorities your work into things that are really important that definitely need doing, things that hold up other work until they are done and other parts that would be nice to have done but don't ultimately require completion. At work we use project software called Hansoft which we can track our tasks in which helps.
Additionally I make sure to focus on one thing at a time until it's completed before I move on. I used to try and juggle many different tasks at once as at times when there was a lot of work to do and a pressing deadline I could feel overwhelmed.
However, focusing on one task and completing it helps make me feel I've made progress, rather than looking at the total workload and feeling I'm not making a dent in it!
Responsibilities are split between what each discipline excels at. This is good because when I take input from the art team I know their expertise will make my levels look amazing and far better than I ever could. Looking at that the other way round, I can make their pretty levels play amazingly and far better than they could!
We often will ask each other for input when trying to work out a particular problem or we need suggestions for a certain area. I often go to the art team and tell them what I'm planning on doing to see if they have any suggestions for how to incorporate my design whilst improving the overall vision.
Ideas can come from anyone and it's good to actively encourage that. Having multiple people have input into an idea makes sure the best qualities come out of it. That said you shouldn't 'design by committee', that means that you shouldn't just get everyone's conflicting ideas together and combine them all as this will result in a jumbled mess. It's important to understand what the fundamental element is in people's ideas so that this can be extracted and used within a different context. That way you are getting the best of each discipline whilst ensuring you don't end up with conflicting results; each element of the game must be consistent.
Recently I've been writing a lot of articles as these act almost as 'post mortems' for any ideas or elements I've been working on. A post mortem in game development is where you analyze how successful a game's process was after you've completed it. This is so you can understand how parts that didn't go too smoothly can be improved for future projects. So when I write articles on design subjects I can analyze in more detail than I would do in my professional work as we're usually too busy for this!
I also like to create small parts of a greybox level in Maya or a game engine like Unreal Engine 4. This could be something like a combat encounter for a differing style of game which has different core mechanics to what I've been working with professionally. For example, an arena in 'Gears of War' will be shaped differently to an arena in 'The Witcher 3':
Although they are both third person games which feature combat, the core mechanics and gameplay are so vastly different (cover based shooting vs sword play).
I've just been doing my own personal stuff in Maya recently, such as a combat encounter for what a level would be like in 'Uncharted 4'. The variety of traversal mechanics and the vertical gunplay Uncharted is known for makes for interesting layouts. It's interesting to consider how, for example, the rope mechanic influences layouts and how this can be layered in with the piton for climbing rock. The game isn't out at the time of writing so I'm eager to see how the masters have constructed their levels when it's released!
Besides the obvious answer of playing games, I used to do a lot of martial arts, having trained for over a decade and a half. However I've recently had surgery meaning I have to focus on other sports now that aren't as full contact. I've just started to get back into basketball and I've started running, cycling and swimming more. I think it's good to get out and away from the computer, especially considering I sit in front of a monitor all day for work!
I also used to snowboard at a semi-pro level back in the day, and although I don't get to do this every day anymore I still like to go to the mountains or an indoor snowdome when my wallet allows it – which unfortunately is not often enough!
Crysis 2 is the property of Crytek GmbH ©2011. Developed by Crytek GmbH. Published by Electronic Arts Inc.
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
The Last of Us is the property of Sony Computer Entertainment ©2013. The Last of Us is a trademark of Sony Entertainment America. Created and Developed by Naughty Dog, Inc
The Witcher 3: Wild Hunt is the property of CD Projekt Red ©2015. Created and Developed by CD Projekt Red
Gears of War the property of Microsoft Corporation ©2006. Gears of War is a trademark of Microsoft Game Studios. Created and Developed by Epic Games Limited
All content on this website is copyrighted ©2008-2020 World of Level Design LLC by Alex Galuzin. All rights reserved.
Duplication and distribution is illegal and strictly prohibited.
World of Level Design LLC is an independent company. World of Level Design website, its tutorials and products are not endorsed, sponsored or approved by any mentioned companies on this website in any way. All content is based on my own personal experimentation, experience and opinion. World of Level Design™ and 11 Day Level Design™ are trademarks of Alex Galuzin.
Template powered by w3.css