“It’s time to blast one another’s limbs off and paint the town red! I expect to see nothing but blood and broken dreams after, understood? I picked this underground base for good reason…”
DM-SubterraneanComplex (DeathMatch-SubterraneanComplex) is a an Unreal Tournament level made by me and tested by, amongst others, Unreal Tournament professionals. Mechanically, it very much aims to play into controlled chaos, similar to something like Baby Park from Mario Kart: Double Dash!!. Aesthetically, however, it aims to look and feel like an underground mining facility, similar to Xenoblade Chronicles’ Ether Mine. The project took a total of 8 weeks to develop.
Unfortunately, the level itself is no longer available due to UTCC–the site it was published to–shutting down.
Solo
8 Weeks
Developed in Unreal Tournament
Released on UTCC
So, with this being a solo project and all, I effectively did everything myself. From learning the game’s metrics, to making and iterating upon the blockout, to playtesting and photographing real-life references to then later use in the level, and so on.
To quickly list everything I’d done in regards to this project, I worked on the following:
– Learning Unreal Tournament’s Metrics (e.g., Experimenting in gym levels, Playing the game, etc.)
– Creating and Iterating Upon the Blockout (e.g., Level Planning, Playtesting, Iteration, etc.)
– Photographing real-life Landmarks to work into the level (e.g., taking pictures, creating draw-overs, converting draw-overs to blockout, etc.)
– QA Testing (e.g., creating and using a Conditions of Satisfaction document, Bug Database, Test Plan, etc.)
– Create a Handful of Blender Models (i.e., modelling a Plant, Monitor; both unused)
Furthermore, I sought out professional Unreal Tournament players to playtest my level. This was to get feedback from people who actually play the game on a daily basis, opposed to my peers who only played Unreal Tournament for this project, like myself.
Encounters
(Constantly running into others)
Intended Outcome:
Circular Motion
(Constantly Moving From Side to Side)
Intended Outcome:
Verticality
(Constantly Moving Between Floors)
Intended Outcome:
In order to create a consistent and cohesive player experience, I set these three pillars at the start of the project. These pillars acted like Acceptance Criteria for each and every thing added to the level. Does this thing that you want to add encourage encounters with other players? Does it encourage players to move in a circular motion? Does it facilitate verticality? No? Then it probably doesn’t belong in this level.
Furthermore, despite me never mentioning them to playtesters, they were often the things they liked most about the level. Constantly moving between floors and running into other players, rarely getting time to breathe; it gave the level a very distinct and unique feeling.
The level’s initial concept stemmed from a handful of photographic references. These photographic references ranged from pictures of local buildings to downloaded images of overgrown air force bases. Combining these references birthed the initial concept: an abandoned, overgrown alien base. However, I soon realised that I needed much more than a couple of reference images and an indistinct concept in order to be able to propose it to others.
Feeling inspired, I started sketching potential gameplay moments. Though none of these moments made it into the final product in the end, sketching them out made it easier for me to picture the level in my head. Not too long after, I established the first iteration of my node map. The creation of this node map marked the start of development to me.
Photographic Reference
Draw-over
Implementation
Photographic Reference
Draw-Over
Implementation
This image shows a sketch of the ninja path at the very top of the level. implementation proved tricky.
this image shows one of the earliest sketches of the level. i had no clue how to continue on from here.
This image shows a sketch of the trash can-inspired room as well as some unused gameplay moments.
this image shows a more elaborate sketch of the image on the left. it also features a detailed arch.
This image shows an early version of the spire in the middle of the level. it used to be climbable from the outside.
this image shows an early node map of the level. This node map was never used, but did help a ton with brainstorming.
Right around the beginning of the level’s development, I ended up sketching out a bunch of gameplay moments to gather inspiration (and, of course, hopefully use once I started working in-engine). Though many of them remain unused to this day, these sketches, combined with me finally being able to settle on a level layout, resulted in me being able to make the next iteration of my node map.
Having finally started development of the level at this point, I made sure to keep the node map up-to-date as more and more feedback and changes rolled out in-engine. This ultimately resulted in the node maps shown below.
So, The first iteration of the level’s layout had finally been established. And, for the most part, this layout actually managed to remain relatively unchanged. Despite that though, the level still got a multitude of iterations, most of them related to either balancing, bugs, decorating or item placement.
The images below show a sketched out top-down map of the level’s ground floor, as well as an in-engine screenshot of what the level actually looks like top-down.
This Image shows a drawn top-down map of “DM-SubterraneanComplex”. This was made before development had begun.
This Image shows an in-game screenshot angled down at “DM-SubterraneanComplex”. This was made after development had ended. As you can see, the initial map was kept to throughout all of development, minor differences aside.
Moving away from concepting for a bit, I also made sure to engage in some general metric and scene exploration to maximise player comfort as well as to pinpoint out and prevent potential frustration points. Poor metrics can ruin great experiences, so it’s important to keep them in check and set the most important ones during the earlier stages of development. Metrics are also a great tool to ensure the experiences you put out are consistent. So, with all that in mind, I made a gym level, recreated the level’s general shape as well as some more specific gameplay moments and tested for the most important metrics to set. These ended up being the following:
– Indoor Lighting;
– Spacing Between Objects;
– Object Angles;
– Object Height;
– Jump Pad Placement;
– Floor Separation;
– Lift Speed / Elevation.
Furthermore, I recorded metrics such as minimum comfortable ceiling height (to prevent claustrophobia and potential head bumping), maximum platform height (to negate fall damage) and maximum comfortable slope angle (to improve upon immersion) to make sure the map felt as consistent and comfortable as possible to run through.
This image shows a screenshot of my gym level. it features all guns, power-ups and pick-ups, as well as a shooting range and a handful of gameplay moments.
this image shows a screenshot of my gym level. It features an early version of the ramps and bridge surrounding the shredder. These proved too tedious to make consistently.
This image shows a screenshot of my gym level. it features different sizes of the shredder, the centerpiece of the map, to determine its most comfortable and usable size.
this image shows a screenshot of my gym level. it features an early version of the shredder, post gym level experimentation. this was the base of the initial blockout.
This image shows a screenshot of my gym level. It features a lowering ceiling, to determine the maximum, minimum, and most comfortable ceiling height.
this image shows a screenshot of my gym level. It features the inside of the hexagonal towers. in here, I was testing for elevator speed and duration.
Besides metrics, I also focused a good amount of my energy on segmented fun, making sure the individual gameplay moments present weren’t only comfortable and/or functional, but also fun. To provide an example, the centerpiece of the map, The Shredder, had to undergo constant iteration to make sure moving between floors felt as intuitive as possible. This, in turn, made it more fun to use.
Speaking of iteration, the level in its entirety has seen many iterations over the course of its 8 weeks in development. From something as small as making sure certain Health pick-ups feel balanced, to something as big as transforming entire rooms or even floors. Being based on student and teacher feedback alike, these iterations made the overall experience so much better in the end–it made it much easier for me to conform to the target audience’s desires.
To me, the iteration process felt like a constant balancing act between changing too much and changing too little. Sometimes I’d feel obliged to make a drastic change prior to a playtesting session in order to be able make sure playtesters would notice the more subtle changes I’d have made since last time they had played. This resulted in me gaining a better understanding of the level’s greatest strengths and biggest opportunities.
To provide a nice little overview of the biggest iterations and changes made throughout development, I created the following:
Initial Blockout
1st iteration –
Initial Blockout, Packaged.
Includes Basic Geometry / Gameplay Elements, Experimental Lighting And All Planned Weapons / Pick-Ups.
Demonstrates Core Player Experience.
2nd Iteration
2nd iteration –
Made A Handful Of Quality Of Life / Balancing Improvements, Including The Addition Of The Grenade Launcher.
3rd Iteration
3rd iteration –
Lighting, Material Implementation And General aesthetics Have Been Improved Upon.
Slight Tweaks Have Been Made To The Map’s Gameplay Beats.
Final Product
4th iteration –
The Level’s Lay-Out, Readability & General Immersion Has Been Improved Upon.
Colour Coding Has Been Implemented. Pick-Up Placement & Distribution Has Changed.
The Link Gun Has Been Added in Place Of The Grenade Launcher.
During the concepting and pre-production phases, doing proper research in regard to metrics and, in this case, the original game is integral to the foundation used to build the level upon later. It might not seem like it at first, but the longer development goes on for, the more small, foundational mistakes start to build up. A common example being metrics not lining up. This exact thing happened to me at the start of development, resulting in me having the rebuild the entire level from scratch.
During the production phase, make sure to prepare intricate and engaging questions for potential playtesters. Being able to gather data in an effective manner is important to future iterations. Furthermore, involving others in the development process makes it easier to prevent falling into endless and redundant rabbit holes; sometimes a second opinion can help a lot.
Lacking prior knowledge of a genre prolongs the research phase, but doesn’t make designing levels for it an impossible task. The more knowledge, the more potential power.
Being distinct and concise in the earlier stages of development makes for a great foundation later on. It’s about getting the intent across, not the initial execution of that intent.
Aesthetics are much more than looks and feedback. Aesthetics make the experience memorable to the player. It’s easier to recall a level’s aesthetics than a level’s design.
Taking risks during the iteration phase seems like the best time to do so to me; feedback, both positive and negative, is guaranteed to impact the ensuing build. If the feedback is taken to heart rather than ignored, the risks taken prior to that build resulted in a better final product in the end.
Design pillars should constitute the absolute fundamentals of a level and should be noticeable in the final product.
Observations based on metrics and/or behaviour should be seen as equal to feedback based on opinions and feeling; both are needed to conform to the target audience’s desires.