Lead Level Designer | 3D Action/Adventure | Ue 4 | Team: 17 | 6 Months
About The Game
-
Singleplayer action adventure game with puzzles and exploration in an open world
-
Control your glaive as it bounces off walls, floors and even enemies
-
Explore the ancient tombs of an alien race and defeat the robotic guardians to repair your communication beacon and get home
My Role As Lead
-
Organize 5 level designers to complete necessary tasks across five planned levels, audio, HUD/UI and particles
-
Laid out a series of guidelines, pipelines and documents to maintain efficiency
-
Held feedback sessions for the whole team to give feedback on the levels
Individual Contributions
-
Optimized the levels using level streaming volumes and careful control of sightlines
-
Built towards compatibility with PS4
-
Assisted with implementation of cutscenes, scripted elements and bug fixing
Game Trailer
My Role
Optimizing For PS4
Developing for PS4 introduced a number of new challenges that PC development didn't have. I needed to learn and implement new techniques and checks to make sure that gameplay was always smooth:
-
Level Streaming - I broke up every level into small chunks to load the game slowly as the player progressed. This kept the memory usage low at any given time. This allowed the artists to not have to worry about polycount as much and it let us eliminate loading screens from the game.
-
Two-System Testing - Twice as much testing needed to go into this project than if it were PC only. A system was in place for the lead programmer to identify any problem rooms. These locations were sent directly to me to figure out what could be causing performance problems.
Using Blueprint and Matinee
I've always been primarily a scripter, but have worked mostly in code. This was my first real chance to get into blueprint and learn Unreal's visual scripting. I combined that with learning matinee at the same time and using the two to create scripted scenes that gated the player until areas were completed.
We had a puzzle element involving finding four lost lever and using it to activate power sources. To make it more interesting I hid three of them behind walls and used triggers and matinees to reveal them out of the walls as power was restored and matinee'd the camera to show newly unlocked areas of the level.
Blueprint Samples
This code runs when the player walks through a trigger box. It checks if it is supposed to load or unload the hub world and all related streams. Then it dynamically loads the space or unloads it from memory.
Checks whenever the player returns a lost switch. Increments a variable and plays a matinee based on the number of switches returned.
Create an enemy and replace a missing lever, allowing an elevator to be used. This makes the third level accessible from the hub world.
This code runs when the player walks through a trigger box. It checks if it is supposed to load or unload the hub world and all related streams. Then it dynamically loads the space or unloads it from memory.
Documenting Everything
Organizing My Documents
The tool Mindmup helped the team to organize all of our documentation into a web. This allowed everyone to find the documents they needed and made them more used by the team.
I broke the level designer documents down into sections :
-
LDD's - Held the level design documents for all planned levels and level pitches
-
Level Guidelines - Guideline documents on how to approach different tasks such as level streaming, puzzles, player abilities/skills and lighting
-
"Jamboree" Notes - Held notes from team-wide feedback sessions where the whole team could see the current levels and give feedback and suggestions
Creating A Skill Progression
A player needs good pacing in the level itself but also in the rate at which they unlock new abilities and encounter new challenges. I drafted up this chart for my level designers to use as they were planning out their levels. It served a few purposes:
-
Gave descriptions of all of the tools, abilities and mechanics that could be used at any given point
-
Informed them of what skills should already be mastered by their level
-
Allowed the whole team to visualize how the player would be progressing through the game including what pieces are more important than others
I also made sure to include that this is a guideline, not a rule. It was important for me to give my designers the creative freedom to break these guides if the idea was great.
Download the document
Part of my skill progression chart showing when skills and challenges could be used and to what level they should be known.
What I Learned
Coordinating Designers and Artists
Each level was built using modular assets. During Alpha we began the process of stitching these pieces together to help with lighting, shadows and optimization. Level streaming made it slightly more challenging as pieces needed to remain separate if they were in different streams. To streamline the process, I created overhead wireframe maps with stream names on them and the line where streams changed. This organized everyone so that we could have five people simultaneously working on the stitching without anyone ever getting in anyone else's way.
These maps were again useful for organizing aesthetic passes and lighting passes done by artists. They could mark off which streams they needed and I could tell my designers where they should work based on that.
Dealing With Level Ownership
I wanted to foster a very creative attitude among the design team where any one of the designers could pitch an idea and improve any of the levels. I didn't want a level feeling "owned" by a single designer who controls it completely.
-
I held a "design jamboree" every sprint where we all sat down and reviewed each level. This gave every member of the team a chance to view the levels and provide solutions to design challenges
-
During early milestones (Proof of Concept stages) I encouraged designers to iterate on levels that they never worked on before to generate a fresh perspective
-
During later milestones (Vertical Slice and on) everyone focused on a specific skill type (scripting, particles, lighting, puzzles) and they became responsible for that across the game
Some methods worked better than others, but I can learn from the failures more than I can the successes. The jamborees were very successful in bringing out a lot of good ideas and getting everyone bought in on what was happening throughout the game.
Not giving each level an owner was a mistake. It allowed other designers to go in and change some of the initial direction of the level and lose some of what made it different. Going back to this, I would allow for level ownership, but still make sure that other people work on the level. That would keep fresh ideas coming in, but maintain someone as the vision holder for that level to keep the new ideas in check.