A Custom Quake Level
Role: Level Designer
Walls of Ganath is a custom level for Quake (1996), set within the eerie confines of a multi-layered haunted fortress.
Players must breach its defenses and purge the corruption lurking at its core, blending intense action with light puzzle solving.
Solo
8 weeks
Trenchbroom
Project Role:
Level Designer
During an 8-week period I created a playable level for Quake. The work consisted of:
Concepting and sketching
Tool research, game research and reference gathering
Whiteboxing
Playtesting and Iteration
Design documentation
The level development began with gaining an understanding of the source material and tools I am working with. This included:
Understanding Quake gameplay
Understanding Trenchbroom engine
Planning the process
Sketching
Research and Concept
After sufficient tool research and planning I could began development in the Trenchbroom engine, which consisted of:
Whiteboxing
Creating combat beats
Adding level functionality and logic
Lighting and colors
Development
Testing and Iteration
I started playtesting my level and assessing feedback from an early stage of development, following a proper QA plan:
Internal and external playtests
Conditions of Satisfaction document
Assessing feedback points and creating tasks
the process
Project deliverables
Gameplay elements
Combat Encounters
The level contains 8 combat beats that are all scripted, sequenced encounters using 5 different types of enemies. Working on these included:
Making scripted enemy wave sequences
Resource and key item placement within arenas
Arena concepting and whiteboxing
Testing and iterating on the combat beats
Exploration Segments
Several sections, inculding the Trench area between the two halves of the level were focused on facilitating exploration with the purpose to:
serve as a breather between combat encounters,
reward the players’ curiosity when looking for secrets,
build intrigue in the player and make them want to explore further,
reward them with resources after completing the first set of encounters.
Puzzles
I created different puzzles based on wires connecting buttons to different mechanisms. These beats were aimed to:
Engage the player’s problem solving skills and challenge them in non-combat ways
Serve as movement challenges with the puzzle elements guiding the player
Add variety to the gameplay and compliment the combat ecnounters
The combat encounters in the level take place within enclosed arena spaces, with multiple waves of enemies following a scripted sequence. This design progressively raises tension, challenging the player with increasingly difficult situations.
Arena Combat
Interesting Traversal
The connector sections between combat beats challenge the player to explore unique and interesting traversal methods, such as navigating underwater. These sections also serve to build tension leading up to the next arena encounter.
Trap and Escape
In a truly Quake fashion the player is continuously baited and lured into traps with items and visual leashing. Suddenly, they are thrust into challenging situations, forced to battle a group of monsters while simultaneously finding a way to escape.
design pillars
Visual Leashing
To solve readability and navigation issues that came up during playtesting, such as players not recognizing the intended path forward, I used shape language and leading lines to guide the eyes of the player.
Onboarding
To make sure players understand the main elements and recurring mechanics in the level, for the first occasion they encounter those mechanics I made them mandatory to progress forward. By blocking the player’s path all their attention is directed at the nature of the obstacle; this is a good way to give them a moment to understand a concept.
Bait and Trap
In several points of the level I use items, such as armor and ammo packs to lure players to a location and then trigger a trap, starting an enemy encounter. I wanted to create the feeling that the player is an intruder in this castle and by picking up these items, they alert the guards around.
I found this was a good way to challenge the player and keep them on their toes throughout the level.
Scripted sequences
I used the scripting options offered by Trenchbroom engine to set up sequenced encounters where different groups of enemies attack the player as the fight goes on.
To spawn the enemies in I used spawn closets hidden in the level as well as teleportation.
Foreshadowing
I used foreshadowing at several parts of the level to build up tension and curiosity for the player and make their moment of finally reaching the desired destination more impactful.
On the left is a snippet of how the fortress is slowly starting to be revealed to the player as they approach.
Design techniques
Research
To create an experience true to the original Quake, I needed to understand what gives the game its distinctive feel.
Through extensive gameplay and online research I identified characteristic Quake elements, such as:
Room layouts, shapes and enemy positions
Encounter design with different NPCs and environments
Progression in levels, keys and locks
Common settings and architectural elements
Quake research
Before constructing anything for my level, I first needed to familiarize myself with the Trenchbroom engine, a modding tool for Quake used for:
level building
texturing
level logic (such as doors, platforms, and teleports),
enemy placement and behavior.
I experimented with these elements in my Testing Gym Level before starting development.
Trenchbroom: Quake modding tool
To be able to create the setting of a medieval fortress I drew information and inspiration from different sources:
Architectural research from the internet as well as a book on the historical elements of the medieval fortress
Concept art I found online provided abundant inspiration,
And Quake level layouts helped me understand how to translate these architectural elements and aesthetics into effective level design.
Setting research
Tools and preparations
In the beginning of the project I created a timeline with deadlines for project deliverables. This helped me prioritize my time and stay on track with the project.
Project timeline
To create a coherent level layout I adopted rational Level Design principles, such as the 4-step difficulty curve, known as the principle of Kishotenketsu and created Node Maps and Beat Sheets to make sure the plan for the level’s difficulty scaling is solid.
Rational level design
To ensure a smooth player experience in the aspects of platforming and positioning I used my Testing Gym Level to take measurements of the Quake player character’s movements and through experimentation figured out the best widths, lengths and heights for the specific types of platforms.
Player metrics
planning
Concepting
Sketching
I made sketching an integral part of my concepting cycle to communicate my design ideas better for others and for myself to be able to reflect on them. Part of my sketches served as layout overviews to plan player progression and pacing and another part were drawn from the player’s perspective to define the intended player experience.
Testing
Conditions of satisfaction document
To keep track of the state of my level’s individual pieces I used a CoS document. This was useful for:
defining the Definition of Done for the level elements,
determining if development is progressing at a good pace,
tracking the priorities of working on the level for good time management,
attaching playtesting notes and bug reports to the individual sections.
Feedback Assessment and Planning
After each round of playtesting feedback I
Summarized the feedback points, organizing them,
Reflected on the feedback, attempted to determine what the real problems with the level were behind the feedback,
Turned the findings into usable action points/tasks that could be acted upon.
Quality assurance
Project reflection
Developing a level from start to finish by myself over 8 weeks has been a valuable learning experience. There are elements of the project I feel proud of, but also many that I would do very differently if I had a chance. Some of these are:
Not taking research seriously enough in the beginning
Before I started doing level design I always tended to jump right into the creative process from the get-go, because inspiration usually came to me from within my head, but during this project I realized that I simply cannot build a place out of my own head. I cannot build a castle without knowing what parts a traditional castle consists of. This impeded my early progress making the level and had to return to research later in development, taking a look at the parts of the medieval fortress and so on.
Scoping too high
For an 8-week solo LD project my initial layout with 4 different interconnected areas and multiple ways to traverse was highly unrealistic and scoping down did hurt the concept a bit and made it harder to communicate any narrative.
Being more selective with my feedback
I heard someone say that “a game for everyone is a game for no one”, which is a lesson I did learn while playtesting, because after many rounds of testing and a ton of feedback points to assess I recognized how different people had contradicting opinions. At first I attempted to please them all, but later I realized how people are part of different audiences, liking different types of games or levels, so there is no point in trying to please them all. I should have identified my target audience better, so I could have been more selective with the feedback people gave.
