The Level Design Process
Updated: Oct 29, 2019
This guide is an overview of the process utilized in designing a video game level.
There are 7 stages in my level design process:
In each section below, I have broadly defined the purpose of these stages as well as provided some context for the activities which occur within them.
Purpose: This stage focuses on generating ideas for the level
Output: Level design documentation
Designing a new level begins with generating ideas about the level’s defining attributes and their place within the context of the game. These attributes might include high-level items such as setting, pacing, and objectives- all of which should align with the game’s creative pillars. One way to identify these attributes is to curate a list of open-ended questions about them and then brainstorm a variety of answers. These answers should provide a solid foundation for the level’s design without being weighed down by minutiae.
The following is a list of questions to get started with, alongside some possible answers:
Q – Where does the level take place?
A – scorching desert, haunted castle, bustling city
Q – When does the level take place?
A – dead of night, middle of winter, end of days
Q – What are the level’s objectives?
A – escape enemy capture, find the crystal, capture the flag
Q – How does the level fit into the game?
A – final boss level, tutorial level, survival level
Q – What makes the level awesome?
A – giant spinning laser, flying stingray herd, zero-g space elevator
When answering these questions, it is valuable to look at other games, movies, and even our own world for inspiration. I like to bring together my inspirations in a mood-board where I combine images from different media representative of my level’s attributes. In the example below, I created a mood board to illustrate a colorful low-poly style of environment art using screenshots from some of my favorite games.
The output of the Ideation stage should be compiled into a Level Design Document which highlights the level's attributes, inspirations, and state of development. Furthermore, this document should be considered 'live' and receive updates with new information throughout the design process. Maintaining this document will ensure the team has a valuable point of reference and documentation for the level.
Purpose: This stage focuses on refining ideas for the level
Output: 2D level sketches / illustrations
After defining the attributes of a level, it is helpful to sketch a variety of potential designs on paper. These 2D renditions can be created quickly and easily, which allows for a first round of iteration before building a level in the game engine. Additionally, the sketches can be added to the Level Design Document as another point of reference for the team.
When I sketch levels, I like to create two or three different types of drawings for each level or segment of a level:
Flow Diagram – a series of arrows that illustrate the critical or divergent path(s) players will take through the level
Layout Diagram – a top-down drawing of the level including rooms, corridors, points of interest, and more
Detail Diagram – a top-down drawing of the level including placement for characters, cover objects, gameplay actors, and more
In the example below, I have scanned in a picture from one of my design journals. On each page are three iterations of a single section of a level, each with a unique Flow and Layout diagram. These sketches are rough, and include only lines representative of level geometry, callouts for important features, and different colors for elevations.
The output of the 2D Sketch stage should be a series of sketches or illustrations which depict potential level layouts. These should be reviewed by the team and evaluated against the Level Design Document. At this point, a sketch should be approved for further development, or additional iterations be created to explore new ideas.
Purpose: This stage focuses on illustrating scope for the level
Output: 3D level sketches and iterations
Following the approval of a 2D sketch, it may be valuable to build a rough 3D ‘sketch’ to further illustrate an idea's potential without committing to a complete blockout. Similar to the 2D sketch, this is an opportunity to iterate on ideas quickly and easily. A minimalist 3D representation of a level's intended layout and scale will allow the team to assess whether the implementation of their ideas is realistic and will align with production goals.
This 3D sketch can be created in either the game engine or a modeling toolkit and should be built according to the scale and metrics utilized by the game. In the example pictured below I created a 3D Sketch utilizing only primitive blocks. This took less than three minutes to create and provides a basic representation of a level’s layout with both scale and depth. Furthermore, there is no need for this sketch to be any more complex than a collection of floors and ramps, and it does not need to support gameplay.
The output of the 3D Sketch stage should be a rough 3D rendition of the 2D sketch. This should be reviewed by the team and evaluated against the both the Level Design Document and the approved 2D sketch. At this point, the 3D sketch should be approved for further development, or additional iterations be created to explore new ideas.
Purpose: This stage focuses on building the level
Output: Playtest ready level blockout
After the concept of a level has been thoroughly fleshed out and vetted through pre-production, it is time to begin building the actual gameplay space- commonly referred to as a 'Blockout'. Depending on the project, the blockout could be built in a proprietary game engine, an open source game engine, or even a modeling toolkit. Regardless of the tools being leveraged however, the space will be created using primitive geometry, shaders, and lighting.
Featured in the image below is an initial blockout of a level I designed as a side project for Unreal Tournament (2014). To build this space, I used a variety of primitive static meshes including rectangular prisms, triangular prisms, and cylinders. These meshes were scaled, rotated, and translated into different orientations and dimensions to create the variety of shapes and spaces I needed for the blockout. It is important to remember most shapes can be reduced to these simple primitives, and the only limit to building robust levels is one's own imagination.
Aside from the geometry itself, it is valuable to enhance the visibility and aesthetic of the blockout with the implementation of basic lighting and shaders. Personally, I like to leverage shaders to color-code different components in the level to provide the kinds gameplay cues typically handled by environment art. For example, I might color all interactive objects as green, all climbable objects as yellow, and all destructible objects as red.
To coincide with the above, it is imperative to implement all components which are required for testing gameplay in the level. The ability to effectively playtest throughout the level building process is crucial and should be a priority for the team. It is an important part of my workflow to frequently enter my spaces as the player character and test geometry changes as I make them. If a blockout is only tested once it is finished, there is a substantial risk in losing time to correcting issues which could have been addressed throughout the process.
Below is a list of items that might be required for playtestingl:
Player spawn points
AI spawn points
AI navigation mesh
The output of the Blockout stage should be a level representative of the approved design and include all components necessary for gameplay. This should be reviewed by the team and evaluated against both the Level Design Document and playtest feedback. At this point, the blockout should be approved for further development based on feedback, or additional iterations be created to explore new ideas.
Purpose: This stage focuses on refining the level
Output: Updated level blockout and iteration notes
Once a comprehensive blockout of the level is complete, the team can begin testing the level within the context of the full game. Through playtesting, the team can curate feedback which identifies points of improvement the designers can utilize as a baseline for iteration. After iterations have been completed, the process can be repeated with another round of playtest, feedback, and iteration. Given this process can go on indefinitely, it is important to identify the criteria by which a level is 'good enough' and the team can move forward. Overall, the goal is to refine the level as much as possible within production constraints.
Identifying the aforementioned points of improvement can be difficult given the subjectivity inherent in design. For example, when playtesters provide feedback, their likes and dislikes will be derived from their personal preferences. A single feature of a level may be adored by one playtester, but despised by another. Subjectivity is not indicative of invalidation however, and all feedback should be assessed for consideration.
Below is a list of example questions to assist in iteration:
Is the level too easy or difficult?
Is the level too linear or open?
Is the level too simplistic or confusing?
Does the level accommodate player choice?
Does the level accommodate game mechanics?
Does the level align with the game’s goals?
Lastly, the most important question of all:
Is it fun to play?
This question might seem simplistic, but I firmly believe it is the most important question that should be asked throughout the game development process. If the answer to the question is 'yes' than the team should press forward, and if the answer is 'no' than the team should press pause. Either way, it is important to determine why the answer is what it is.
The output of the Iteration stage should be a level which manifests the final design and includes all components necessary for gameplay. This should be reviewed by the team and evaluated against both the Level Design Document and playtest feedback. At this point, the blockout should be approved for art implementation, or additional iterations be created to explore new ideas.
Purpose: This stage focuses on adding art to the level.
Output: Completed level with final geometry and initial art
After the blockout of the level has been locked down following iteration, artists can begin their environment art pass. This process involves artists replacing temporary level geometry with art assets as well as adding atmospheric effects such as lighting and post process. Ideally the level design is preserved during propping, but sometimes conflicts with art implementation emerge and it is necessary to make accommodations. Consequently, it is imperative communication between artists and designers is maintained throughout the process.
Many of the issues which might appear during this stage are related to collision, visibility, and performance among other items. If possible, it is valuable to address these issues as they arise because correcting mistakes here can save time later in the development cycle.
Below is a list of example issues to watch out for:
An asset has missing or incorrect collision
An asset obstructs a line of sight
An asset obstructs a player path
A point of interest is not emphasized
The framerate is below target
Art is an incredibly important part of a game’s experience, but gameplay should always be the priority. Therefore, it is necessary to ensure the player experience is as smooth as possible and functions as design intended.
The output of the Propping stage should be a feature-complete level which resembles the final product's intended look and feel. This should be reviewed by the team and evaluated against user experience standards to ensure gameplay in the level is smooth and free of issues.
Purpose: This stage focuses on the user experience of the level.
Output: Polished level with final geometry and final art
Once the art pass nears completion, it is time to add the finishing touches to the level. These touches might include elements of both art and design as different components of the level are tweaked to meet a quality standard. This standard should be measured according to criteria which define minimum and preferred benchmarks. All levels in the game should meet at least the minimum, and any which fall short should receive additional polish.
Below is a list of example points of polish:
Level does not have floating objects
Level does not allow players to become stuck
Level does not allow players out of bounds
Level has smooth collision throughout
Level has consistent frame rate throughout
It is important to take an active role in resolving these issues throughout the entire level design process. Waiting to cleanup issues will result in further complications, as time needed for cleanup will be used to develop other content or vice versa. Ensuring polish is a part of the team’s workflow will ensure the final product is stronger.
The output of the Polish stage should be a feature-complete level which manifests the final product's intended look and feel. This should be reviewed by the team and evaluated against quality standards to ensure the level of polish aligns with the appropriate benchmarks.
After a level is complete, it can be helpful to set aside 10-15 minutes and perform a quick retrospective to analyze the level's successes and failures. Understanding why the design hit or missed its goals will help inform more impactful designs for future levels. Additionally, the critical thinking inherent in this process will encourage continued growth as a designer.
Overall, the level design process is defined by timely and thoughtful iteration. For the process to be as effective as possible, it is crucial to constantly evaluate the state of the level and identify areas of improvement which may be addressed through iterative design changes.
A Note About the Author
Evan Brooks is a professional level designer currently working at Funcom and making awesome video games alongside awesome people.