Robert Gordon
Level Designer
Onslaught
In four months I made a single-player Quake map. It highlights Quake's combat loop from a dark cave to a demon-infested castle.
Project made using Trenchbroom a modded engine made and updated by the Quake community that supports not only Quake, but also Quake 2 and Hexen 2.
Level Designer
February 24th 2024 - June 30th 2024
Solo Project
Trenchbroom
Overview
Onslaught is a fast pace combat focus level with light switch hitting puzzle elements. The player using a wide variety of weapons and there own movement must overcome increasingly more complex enemy encounters.
Level Design Process
Research
Study the game Quake through a playthrough and find information about Trenchbroom
Documentation
Plan out level with notes on goals for level and level map.
Prototyping
Started building out the level in the level editor. Prioritize making sure level was playable in this.
Iterating
Feedback
Playtest prototype to identify issues when playing. Identify ways the problem can be resolved.
Once a playable version is made present it to playtesters. Obtain their feedback to find issues with level and continue iterating on the level.
Research
Gather information was vital for this project as I never played Quake before and never used Trenchbroom.
Firstly I played through the original Quake before starting the project to get a feel for the game. Quake as a game is a fast-pace third person shooter where the player needs to ulitize there movement to avoid enemy fire along finding the right openings to defeat the enemies.
Additionally, lots of research went into Trenchbroom with finding many vital sources of information to ensure this project went smoothly:
-
Video tutorials by dumptrump_ds that breakdowns many key aspects of Trenchbroom from the intital set up to using the many tools provided in the software itself
-
Func_Msgboard an older website that documented many answers to potential problems experienced in Trenchbroom
A massive shoutout goes to the Quake Mapping Discord an active server that was an invaulable resource. Not only providing a space for answers to multiple questions about Quake and Trenchbroom, but also provides areas to showcase early map visuals, a built in system for playtesting and even hosts level jams for Quake.
Documentation
To start off I written about about each section of the level breakdown what will occur in the each section. Like what enemies will be present, when will new weapons be available, how will certain triggers work in a given area, what will be needed to progress further into the level.
Additionally, I crafted a level map to giving my idea a mental image to base off. To see where I can take the idea and test of ideas before even touching the level editor.
.jpg)
Prototyping
With the plan in tow I started making the prototypes for the level. The goal was to create rough drafts for the level will be flawed, allow me to see my ideas fully realized see if I can pursue the idea going forward or will I need to adjust my plans.
The best example would be the first big encounter with the ogres in the fortress. I wanted to use some varied heights to create a unique area, however there was a massive problem. The ogre's in Quake cannot aim at the player when they are at a lower elevation than the player. This turns the ogre into a nonthreat removing all of the tension that was in the encounter.
Iteration
Old level end with fiend
With the prototype established I started work on iterating on them. The focus would be on identifying and then resolving issues I find when play testing with the section I was working on. Problems could be enemy AI not working properly, triggers not working as intended and many others.
Sometimes these changes can dramatically the dynamic of an area. For the final area I wanted to end with a showdown with a powerful enemy which at first was a fiend. However, after playing it didn't work at all as the area was too big and easy to kill him. However, a shambler worked significantly better and using the pillars were a great blockades to the shambler's lightning attack.
More examples include the arrow to communicate where to go in the first combat section, removing a wall on the side of a later room filled with knights and many others.
New level end with shambler
Feedback
Level Skip and Fix
After many iterations of the level where I can feel confidant in my build I needed more feedback on the project. For this project I turned to the Quake mapping discord that had it's own dedicated channel for people to request feedback on their Quake level along with multiple members for playtesting and providing feedback.
Plenty of invaluable feedback was provided with some I want to highlight. The big one would a skip that was possible near the end of the level. It skips multiple encounters along with with relatively easy execution made it less than desirable and thus was removed.
The next piece of feedback was tricky to handle because my level was too easy. I wish to bring a fair challenge to my levels and look into it. Not all the encounters were touched, but a good amount of them were updated to feature an additional enemy. My favorite inclusion would be the added enforcer in the encounter before the fortress. Its inclusion also comes with a new set of stairs that gives the player a risker, but rewarding pathway to the fortress.
Old Version
Updated version
Design Insight
Combat Encounter Goals
For each encounter I established goals I wanted to use to help created varied and enjoyable encounters for the player.
The doorway problem
Variety of enemies
Scripted events
Initial cover
Pickups
Eliminate or minimize the effectiveness of the door way problem
Presents a variety of enemy types
Implement scripted events that will trigger to provide
Provide cover near the start of the encounter to give the player a basis in the encounter
Ammo, health, and new weapons pickups help the player be well prepared for future encounters.
The Doorway Problem
A key goal I needed to ensure the player couldn't easily retreat to previous areas. This prevents the player from using a dominant strategy of having the enemies slowly funnel into the entrance and shot them down one at a time.
The video to the right I disable the door in an earlier build to close show off how boring the encounter would be.
It was commonly solved through a door closing when entering a room, but more creative means were used when the opportunity arose.
Variety in enemies
Each encounter is carefully designed around the enemies in Quake. An encounter can not only change dramatically by what types of enemies are used, but also how many, what combination of enemies used or even when these enemies appear.
For example, in the second to last encounter the player is presented with a room with an ogre far away with multiple knights running to them.
The knights prove a delay threat that need to take out quickly before they overwhelm the player as the fire from the ogre provides a long range threat that the knight lack.
Player start
Level progress
Additional knights that appear after the first one dies
Scripted events
In Quake triggers prove a useful tool to help create many unique possibilities to help elevate an encounter.
For example, in the first major encounter once entering the player is suddenly jumped by two rottweilers who emerge from a door. Sudden appearance of the enemies allow for them to given the attention to the player of the new threats that are ready to attack.
Even scripted events outside of combat were used to help build up a fight. Once opened the last door the player climbs up a flight of stairs where it is fairly dark, but becomes lit as torches are dramatically appear.
Initial Cover
One critical part of my layout was always proving the player a piece of cover early on. Cover early on proves the player something to use as a basis for combat to avoid fire from enemies.
Without it, the player will effective be wide open to all the enemies attack only using their mobility to avoid attacks. Quake's mobility does allow this situation to not be a death sentence, it can easily be overwhelming.
Pickups
Health and ammo are provided to help the player room for error within the level as it would be obscured to expect the player to clear the whole level without them. Additionally, they can serve as a breadcrumb for the player guiding them to areas.
For example in the first area the player has the initial cover then two more additional cover. The one with the health pack provides more opportunities for safety, while the norther one is risker, but provides the player the nail gun.
Slower pace challenges
While the combat is the main focus of Onslaught quieter moments without combat were also key to help cool off after intense combat encounter.
These areas were usually design around simple puzzles around the player shooting a target to progress further. For the area before the final encounter the player must shot two targets that open a path to the final encounter.
The first one is accessed by heading to the right up the stairs to reach the top where the player can fire at the first target. Once there they can go back down to see the second hallway to enter where they will go through two combat encounters before finding a portal to reach the second target.
Player start
Teleport Entrance
Shooting the target
Target
Teleport Exit
What I would do differently in the future
Better use of time
I understand the fact that working a job would naturally make it harder to get in time to work on a project. I still feel like the project just took too long. I am still glad that I got the project done at all, but feel like I still need to work on my planning and organization of the project to be better in the future. This project was a great learning experience for them and I am excited to get better at these skills.
Using curves
Creating curves in Trenchbroom is a tricky thing to implement as they require a very meticulous setup that I did learn, but was hesitant to implement more into my level. As previously talked about how long I took on the project I understood I needed to make compromises in what I could implement which was a consequence of it.
Going forward with this knowledge I will push to try to use them when initially when planning and when making the structure of the level.
Platforming
There was one piece of feedback that always stuck out in my head when getting it from the people in the Quake Mapping Discord. They talked about how my level didn't try and implement bits of platforming into the level. For this project, it wasn't my focus, but it would be a fine addition as a way to add variety to the level.
I sat on the idea for a while and ultimately went against it as I felt I couldn't deliver a refined enough version and focus on more pressing matters for my level. However, for future projects, I would be more than interested in experimenting with the idea.
Closing Thoughts
This project was a fun time to go through. Additionally, it helped me get some hands-on experience crafting more traditional combat encounters along with a more thorough planning stage. I wish to use these experiences to help create even better levels in the future.
Shout out to the Quake Mapping Discord for helping me with feedback on my level. The feedback was greatly appreciated and extremely helpful and insightful for things to consider in future projects. I also want to shout out the LinkedIn user on identifying and providing a solution to the ogre. It was an issue I noticed but had no idea how to solve, so thank you for your input as well.