LEVEL DESIGN OVERVIEW

Below is an overview of some of the methods I use when approaching level design and gameplay.

It is a living document that will grow as I do.


 

The Experience

I believe the experience the player feels while playing is vital. Players want to be entertained and feel one or several emotions so establishing the tone or theme of the level is important. Once a tone or theme has been established I will begin building a foundation of images on pinterest, music on youtube, and notes in google docs. The key here is that I begin to create a small collection of references that can be used by other team members and allow for easy collaboration.

A fantasy town, at sunset, I built in Unreal Engine 4 using an asset pack.


Blueprint

Once the overall tone and theme are complete I will begin to sketch the level out. I like to visually create the play space from a top-down or side perspective. In Cosmonaut we had specific pixel limitations so initially building the levels with grid paper made sense. For Hollowed we were building a side-scrolling game with 3D assets so I had more room to be fluid in the design. What was most important was that these concepts were references to build from and not the final version. I allow game-play and testing to shape the level to its final form. I can only predict what may be fun based on previous conventions or decisions made beforehand.

Cosmonaut early level sketches.

A Story of Ash level layout and notes.

Depending on the level I may create more detailed sketches from 3/4 perspective to help understand the actual structures and world space, specifically size. I may also begin to place markers and form a legend for where challenges may be, where audio may play, where an item may be placed or when an event such a cinematic or story should be.

Hollowed, beginning of the trial.

Study of Inside for creating perspective and shapes in Hollowed.


Documentation

Sketches are perfect for getting ideas across or personal reference, but my team needs to be able to understand how the level is actually being created. In some cases like in Cosmonaut I had to remotely work with the programmer to build the levels. I will opt to use some form of collaboration tool such as google docs or Confluence. In the case of Cosmonaut I created an excel sheet that we used to build and iterate upon the levels before actually hand building them in game. This saved us a lot of time and rework.


Grey-box and Snipets

Once the shape of the level has been established I will begin working with the grey-box. In some cases a very basic grey-box is given to me and I will have to build on top of it. Generally this will be with actual boxes but if there are assets available for that level I will begin to use them to get a sense of how they will be used in the level. In some cases I will take assets and manipulate them in the level to create temporary assets that convey what something should look like. The goal here is to get a prototype of the level up and running as fast as possible.  In some cases this is fairly quick and painless but in other cases it can be very time consuming. In Hollowed we had little direction on what the world should truly look like since the art assets were still being created. We had to instead improvise and continually build upon iterations until we had a solid visual to convey.

Anger Keystone greybox

 

Anger Keystone in development

A snipet is generally taking a screenshot of the level then using it to collaboratively make notes and iterate. For Hollowed I proposed that we layout the entire trial (our main string of levels) to allow the team to visually see how we are stringing the levels together and allow for notes or suggestions to be posted by others on the team.

levelSketch1.jpg

Fleshing out the level

This is a point where I can start to implement game-play features. This will be different from game to game but I can provide a few examples from previous projects. In Cosmonaut I was focusing on tight claustrophobic corridors. In Hollowed I focused on creating platforming and vertical/horizontal play using the core abilities. In Project Folklore I focused on creating limited open world environments for a VR player to explore and interact.

snowflakeScreen6.jpg

Up to this point I would be asking for feedback from the team internally, but we would also begin looking at play-testing the early versions of the game. Doing this will help guide the shape of the level to better suit the needs of teaching, entertaining, and controlling the player. In Hollowed we had to test our various mechanics in many different challenges to establish what was too hard and what was too easy. This allowed us to establish flow which informed how to proceed with structuring challenges in the game. In Cosmonaut testing helped to establish that earlier sections seemed a lot more dull then the others. Players felt the horror kick in too soon and were not given a moment to feel high and mighty before taking a great fall into the darkness.


Polish

Last but not least is the push to complete a level. This stage is I focus on using feedback from all sides to continue improving the level. In some cases a level was handed off to another and I would pick-up the more difficult or less polished levels. In others I would work with an environmental artists as a small strike team to flesh out and make an area shine. Regardless the point was to assist in any way possible to bring the level to life. This could be anything from assisting in audio to helping guide others in lighting and set dressing.

In Hollowed we had to split designers and artists into 2 man groups and tackle the entirety of the game. To speed up the process the project lead wanted each artist and designer to handle the light of those section, but not everyone was a skilled lighter. I setup a blueprint for point and spotlights that handled many aspects of lights automatically such as setting to static if not using light functions. Working with the lead artist I established a set of colors that would work as a standardization across the board. The blueprint also allowed for pulsating lights and flickering lights that used light functions rather than event tick to save on performance.