In this blog I'll be talking through the development process of a level design project, from pre-production flow charts to a fully playable block-out. I'll be going over the design techniques used, as well as how the level was tested and changed based on feedback.
Pre-production
The concept I went with for my level was of a skyscraper constructions site, one that the player has to scale while being pursued by an all-encompassing corporation's hired mercenaries. The player character would start in alleyways nearby, before finding a way into the site and dealing with different obstacles and enemies in their way.
For the most part I wanted the level to have a fairly fast-pace, not spending too long in each area and keeping gameplay interesting with variety.
By starting with a flowchart and beat chart for the level, I was able to better design the level to match the pacing I wanted to achieve. It also meant that sections could be easily moved about or changed entirely without having to think about the space or layout yet.
Once I had finished these, I moved on to creating bubble diagrams, then drafting the level layout before settling on the finished design.
Development Process
Metrics Gym
Before starting the level block-out itself, I set up a metrics gym level to help get a feel for things like jump distances and cover height. Settling on specific metrics for the different gameplay mechanics like this was very helpful and saved a lot of time when it came to putting the level together.
Initial Block-out
I started work on the level proper by blocking out each section from start to finish. This was the longest part of development, and I would make changes to the design as I went along. During this time I was also taking part in playtesting sessions, so I had feedback from others to take onboard as well.
Scripted Sequences
Once the level had been mostly blocked-out, I started work on implementing the different scripted sequences needed throughout.
Some of this involved scripting via blueprints, to create the collapsing scaffolding section for example. For others though, I used level sequences to animate things like a helicopter passing by a window and flying up to the roof.
Lighting
Due to being set in a city at night, the level needed a huge amount of lighting set up. This was also the first time I had properly tried to light a night-time scene, and at this scale it was a bit daunting.
Streaming
Since this was going to be a relatively large level, I knew I'd have to use some form of level streaming to maintain a decent framerate during gameplay.
Unfortunately, the nature of the level I designed ended up being quite counterintuitive for streaming sections in and out, since at various points the player will be very high up and able to see the majority of the level.
Because of this I initially thought I would only be able to load and unload indoor sections, as they were the only parts easily obscured from view for the majority of the level.
Eventually though, I found a solution for the outdoor sections of the level. I settled on loading in simplified "LOD" versions of certain areas when the player would be able to see them from far away. For example, the alleyway section is completely unloaded once the player crosses the collapsing scaffolding, as it is completely obscured from view for a time.
However, when the player reaches the main building, there is a large window facing the alleyway that they can look out of. Before the player reaches the building, the LOD version of the alleyway is loaded in.
I used the same technique for some other sections as well, and also ended up creating separate sublevels for each section's lighting. This way, distant areas can have their baked lighting visible, without having dozens of dynamic lights loaded. It's not a perfect effect, and I didn't have time to fine-tune it, but from a distance it's hard to notice.
Cutscenes
For some parts of the level, it was hard to convey either what was happening or what the player had to do. For example, in the collapsing scaffolding sequence, players often wouldn't realise that the platforms were falling, or why.
To better convey information to the player here, I decided to use the level sequencer to create a short cutscene.
I tried to make sure it was obvious where every object in the scene was in relation to the player character. The first shot is of the player character from the enemy's point of view, so as to not completely disorient the player when the cutscene starts.
Later in development, I also realized that the context of the level itself wasn't being conveyed very well at all. This time I set out to create a longer cutscene, showing how and why the player arrives at the start of the level and better establishing the goal of the level.
Most of the information was conveyed through dialogue this time, but I also tried to make use of framing and composition to better show the player's goal.
Design Technique Examples
In both pre-production and during development, I tried to utilize a variety of level design techniques throughout to better guide the player.
For the box puzzles, I tried making use of scrape textures on the ground, as an affordance that they can be moved. Or for certain ledges, I would have wires hanging down acting as an affordance to be climbed onto and letting the player know the way forward.
Lighting was also extremely useful as a technique for guiding the player. By taking advantage of contrast in both brightness and colour, the player's attention could be drawn to things easily.
I tried using lighting as part of a bait-and-switch moment in the ditch section, in theory drawing the player towards the bright ledge at the end of the ditch before being ambushed by enemies. After turning around the player should then see the real path forward through the pipe.
Lastly one of the more obvious techniques for guiding is the use of landmarks / weenies. In the case of this level, the first building acts as the most obvious landmark, as it is almost always visible from everywhere in the site. I also added some structures such as the smaller crane in the first section of the construction site, to help the player to orient themselves.
Feedback and Changes
Throughout the development process, the level changed a lot from the original design made in pre-production. Some of these changes were inevitable, as certain gameplay mechanics wouldn't be available in the template project I was using. For example, the original level design made use of ladders in quite a few sections, and since it would've been far too much work to get working with the project I instead had to redesign these areas to compensate.
Most other changes were made as a result of repeated playtesting of the level. This included both my own playtests as a developer, but also (and more importantly) the playtests of fellow students and peers.
Developer Playtesting
While blocking out the early platforming sections of the level, I found that there was a lot more back-to-back climbing and jumping than anticipated. I felt that the original design for this section would end up being too long and repetitive, both in terms of gameplay and scenery. To resolve this, I had the idea of having the player traverse through a short indoor section, with some simple stealth / combat involved. In the pictures below you can see the before & after of this change during development:
Along with this change, I also realized through testing that the collapsing sequence would need a "valve" to stop the player from simply jumping back to safety once the platforms began to fall. To achieve this I created a tall set of scaffolding that the player would traverse up before dropping to the platforms below.
I reused this idea for the end of the section, to bring the player back up high enough to jump to the ground-floor of the building. This helped remove the need for the scaffolding platforms to slowly rise higher and higher towards the end, which usually just resulted in a lot of slow climbing animation for the player.
Another difference to the original design I decided to make was to the second box-pushing puzzle. When testing it myself, it felt too straightforward and similar in solution to the first puzzle, and didn't really require any thought to solve.
The new version is still relatively simple, but has a few more steps involved as the player must use a smaller box to reach a larger one, then use both to reach their goal.
I made a lot of changes to most of the combat sections outlined in the original design as well. In practice the AI did not behave as I originally imagined when designing the level, so the majority of things like cover placement etc. had to be adjusted.
Generally speaking, I had overestimated the challenge that each enemy would pose, and usually ended up increasing the amount of them in each area.
The final combat encounter on the roof was probably the most drastically redesigned part of the level. I actually went through multiple different versions while blocking it out. There were multiple reasons for the changes, one being a consequence of moving the end of the level to a third building's roof (as it overall fit better with the level layout and made more sense narratively). Since the cranes moved to adjust for this, the roof's layout had to be shifted as well.
I also realized that the original design didn't account for a "gate" to stop the player from running along the cranes before destroying the helicopter. I had to change the layout of the roof even more to fix this, adding a radio tower that would form a ramp after the helicopter collides with it.
Peer Playtesting
Once a week over the course of development, I was able to take part in playtesting sessions with other students and peers. While they played through my level, I would try to give as little guidance as possible and take notes on how each person interacted with the level. At the end I would ask them for their own thoughts and any feedback they had for the level, and recorded those as well.
After each session I would have a list of things to work on for the next week.
This helped a lot for finding areas to fix or improve that I otherwise wouldn't have noticed as the level's designer. I was able to see things like which platforming jumps people tended to overshoot, or which were too thin and easy to miss.
A consistent problem I noticed players having was actually at the very start of the level. The player has to shoot down a box from a crane hook, so they can climb onto it to reach a ledge. In early versions of the level blockout, players almost always tried to climb the crane itself to progress instead. I went through many different techniques trying to fix this: making the hook the same colour as other objects that can be shot (exploding barrels etc), using lighting to highlight the box, placing ammo nearby to hint at the mechanic, and changing the shape of the crane vehicle to look less climbable.
These techniques did help more players figure out the solution on their own, but for most it still took a lot longer than intended and it was rarely their first course of action. If I had more time I think I would have settled on simply using dialogue to make it clear how the player is supposed to progress.
One of the areas I received the most feedback on was the helicopter shooting segment. Most players were very positive about it and claimed to enjoy its intensity and the feeling of running just ahead of the helicopter's fire. However there were a few issues.
A few players felt that the segment had too many enemies in addition to the helicopter itself. This and the low amount of cover resulted in both very high difficulty and sometimes in players staying stuck in one place behind cover for extended periods. This slowed down the pacing of what was intended to be a fast and intense sequence, and overall it seemed stressful to a degree that could stop being enjoyable.
Another smaller issue with the segment was with the platforming involved. The player has to navigate and jump between bits of scaffolding to progress, all while avoiding the helicopter's fire. Initially the jumps here required a lot more precision and were less forgiving, and many players would miss their jumps while trying to focus on the helicopter. After seeing this through playtesting, I tried adjusting the size of the platforms and slightly reduced the number of jumps involved.
Some feedback mentioned that the segment also ended too early. Since I was also going to be reducing the number of enemies in the section, which would likely have shortened it even more, I decided to extend the sequence. The player would now have one last run to make before reaching safety from the helicopter.
For one last example of changes based on this feedback, I found that upon reaching the scaffolding leading up to the collapsing section, most players were faced in the wrong direction. This led some to try jumping to the platform above the indoor area they had just came through, thinking it was the intended way forward.
My Own Thoughts
Pacing
I feel very positive with how the pacing of the level turned out. Based on both my own playthroughs and feedback received from others, I think the level was successful in balancing intense combat with calmer traversal and puzzle sections. I don't feel that any section drags on too long or outstays its welcome.
Scripted Sequences
From listening to feedback it seems that both the collapsing scaffolding sequence and the helicopter attack sequence were the two most well received parts of the level. I'm happy with how they turned out, and I think they act as very memorable gameplay moments for the level. At the same time, they aren't so long or so frequent as to become tiresome.
Combat Arenas
The combat arenas of the level seemed to work decently, most of the time. In some areas, such as before the elevator in the first building, they usually functioned as intended, with a number of approaches the player can take.
Certain other areas, like the front entrance to the first building, did not end up working correctly. Often with these areas, most of the arena doesn't end up utilized at all in the encounter.
Something I wish I'd have done better in general with the combat is giving the player more reason to move between cover. As it is now, it is usually the best strategy to camp behind one bit of cover as the AI come towards you.
Narrative
While I'm generally positive about the level's gameplay, in contrast I felt that the narrative aspect had been left underdeveloped and was its weakest point. I think I could definitely have better outlined / defined a more interesting story for the level in the pre-production stage. As a result I think the level has few unique moments outside of its gameplay, and even then tends to rely more on common video-gamey tropes for its impact, e.g. shooting down a generic helicopter.
With the time I had left, I decided to try adding what details and story elements I could, to at least make the environment reflect a larger story context.
For example, I added some elements to reflect the "Meteor" corporation's presence in the world. Signs and text on the construction site imply that the skyscraper is itself being built by the corporation's construction division. I tried to put more emphasis on the package the player is transporting, with a bit more dialogue on its importance and mystery.
This was difficult to do at such a late stage of development, as there wasn't enough story-background written previously to go off of. After making these additions though, I think that the events leading up to the level would probably have made for a more interesting level itself. In future I'll definitely want to put more thought and effort into narrative in advance.
Scope
Looking back now, I think that the scope of the level had been made slightly too big. While it was still achievable, and I was able to get the whole level blocked out from start to finish, I was left without much time to polish certain areas or act on certain feedback. I definitely feel that there are some rough edges to the level as result, and in retrospect I think I would have preferred to have something slightly less grand in scale but more polished.
The setting of the level itself, a city at night, inevitably meant that a lot of development time would be taken up by lighting and level streaming. Combined with the large scope, I felt very much pushed to my limit to meet the 12 week deadline.
Overall, despite the workload and difficulties encountered in certain parts of development, I feel like I've learned a lot from working on this level. Hopefully the next time I work on a similar project, this experience will help make it a lot more manageable.