This spring, George McLay and I taught a two week course on Level Design and Environment Art thanks to an opportunity from the fine folks at Futuregames. Our course’s focus was on the day-to-day collaboration between Level Designers and Environment Artists. Altogether, we are pleased with the results of the course, but there are always opportunities to improve.
In starting the course, we had two big ideas we wanted the students to learn:
Players experience the game environments, which is the result of a collaboration between Level Design and Environment Art. Players don’t experience our separate disciplines in isolation. The work is fundamentally collaborative, and we succeed or fail as a team.
To facilitate collaboration and iteration, we use nondestructive workflows. Specifically, we taught the students about modular mesh workflows from a level design kit (LDK) up through an architecture pass.
However, our assignment also created a few other challenges we took for granted:
How to keep production moving. How to build fast, but also build in a way that informs collaboration.
How to overcome the blank page problem.
How to control production scope.
How to push back against problems in the work while keeping teamwork functional.
For me and George, these challenges are a daily part of the job, and we underestimated the extent these challenges could dominate the focus for some of the students.
On the Level Design side, I had the students create a basic lock-and-key pattern:
The player sees a goal they want to reach. This could be a narrative goal (“escape the prison!”) or an enticing landmark.
Along the way, the player encounters a lock that prevents them from reaching their goal. This could be a literal lock requiring a literal key, or it could be some other obstacle that must be overcome elsewhere.
Looking elsewhere for a way to overcome the lock, the player discovers the key.
The player returns to the lock, unlocks it, and continues on to the goal.
Crucially, I stressed that the lock-and-key pattern is a way to structure content, regulate pacing, and get more play out of less space. The lock-and-key itself is seldom the source of “fun” (or—depending on the game’s goals—satisfaction, relief, dread, accomplishment).
To make the pattern more than the lock-and-key, I required the level design students to include at least 1 encounter space. This could be a combat encounter, a boss encounter, a traversal or platforming encounter, or a puzzle. The focus of the course wasn’t on gameplay systems or scripting, so in practice this meant blocking out a larger space and having text markup that said “combat encounter”, for example. Some students took this approach a step further by marking up the design intent in detail “combat encounter starts here. Ranged enemy over there. Ambush after that here” and so on. This helped me when it came time to evaluate the levels, but it also helped the level designers communicate their intent to their artists.
On the environment art side, the assignment had them build a basic level design kit for their level design teammates to use in their blockouts. Then, once the level design student had a functional pass on the blockout and the environment art student had signed off on it, the artist would start work on a modular architecture pass. In each of these production steps, we left some room for students to iterate and push for changes when there were problems. For example, if the environment artist didn’t feel confident they could achieve an architecture pass on the blockout their level designer provided, then they needed to push back for level design iterations.
We also imposed a few constraints. First, we limited the teams to the theme of “fantasy”. I figured most of the learning would come from students talking through problems together, and it was best to keep the students within a similar problem-space. If one team was struggling to build hard-surface abstract sci-fi megatstructures, their struggles wouldn’t overlap enough with a team building a flooded medieval town for them to learn from each other.
For the second restriction, we strongly advised against organic environments (caves, cliffs, hills, islands). We wanted students to go through a modular mesh workflow, which is a much harder problem to solve in organic, irregular environments.
If you have taught a course before, you can probably anticipate the problems from the simplified assignment outline above. George and I hadn’t taught a course before, so we stumbled right in:
Problem 1: the possibility space was too big. We allowed students to work in Unreal 4, Unreal 5, or Unity, since we weren’t familiar with their technical backgrounds prior to our course. We also didn’t require them to build with a specific game and set of game mechanics in mind, so long as they made clear in the level what kind of gameplay they intended. This meant we saw first person shooters, stealth games, puzzle adventures, platformers, and a few projects that sat vaguely in some undefined mix. Another consequence of this was a massive blank page problem for students to overcome; not only did they need to design a level, but also the game that the level would belong to.
Solution? Specify the exact game and set of game mechanics. “Make a Skyrim dungeon in Unreal 4! Your level should support stealth, combat, and magic gameplay.”
Problem 2: because we were building for an imagined game instead of one you could truly play, the level designers could only do so much to iterate on playtest feedback. Even with text markup explaining “jumpscare! monster ambush here!” it required playtesters to do a lot of work imagining, and this gave the level design students an excuse that “it’ll work better when there’s a real jumpscare here instead of a placeholder” (a problem that plagues waterfall production also, ahem).
Solution? Have the students build for an actual game. On the level design side this would be easy: have them build Quake 1 maps! Or Half-Life 2 maps! On the environment art side, this is much harder because there aren’t so many moddable games that conform to modern workflows. Even on LD side, modding may not be sufficient for their education, since the brushes->compiler workflows of Quake and Half-Life are very different from the modular mesh workflows of modern tools like Unreal and Unity.
Problem 3: assignment details lacked clarity. To grade the assignment, we needed a playable build in addition to a design pitch doc, a moodboard/refsheet, the LDK .fbx, the arch pass .fbx, and also the project files. Since different students used different tools, this became a headache.
A simple, absurd example: the assignment details for the design pitch doc did not require the students to include their names and roles on the team. As a result, many of the submitted docs did not include names. This left me and George guessing as to who was the level designer and who was the environment artist, or even if we had the right assignment for the right students.
Solution? Split the assignment deliverables into multiple sub-assignments on separate deadlines and specify exact requirements. Make tools a clear part of the assignment constraints. Have students submit their pitch docs and mood boards end of day 1, and grade them right away.
To return to the example of the pitch document, we could have provided the students with a blank form to fill in the blanks, since “how to write good pitch docs” was not one of our course objectives.
Problem 4: in the assignment rubric for the level design, one of my criteria to achieve a pass with distinction was “emotional pacing”. I gave a lecture walking through an example of the lock-and-key pattern in Half-Life 2 Episode 2 and how it provides structure to create an emotional journey of anticipation, fear, and eventually satisfaction in victory. This topic is huge and could have been its own course, rather than a single lecture and a bullet point on the rubric. The specifics of emotional pacing also depend heavily on the game genre and the tools, in the form of game mechanics and systems, that come with it.
Solution? If we have the level designers building for a specific game and constraints, then it would be easier to point to examples and specific techniques.
Problem 5: we graded both students based on their combined work. In cases where one student let their teammate down, this created unfair grades, as happens so often in group assignments. In a professional environment, you succeed or fail as a team, but in a professional environment you also have more recourse than in a classroom if your teammate is preventing you from doing your job.
Solution? Grade the students primarily based on their individual work. Make the combined work a smaller portion of their individual grades.
Thoughts for the Future
Now that George and I have done the work of stumbling through the problems above, I believe there are ways to do the course better. Going into the course, I was worried students would be frustrated by limitations on their creativity if we were too specific in our constraints. My hypothesis now is that we could fix the majority of the problems by tightening the constraints.
Specifically, a few things I would try in the future:
Require the students to build for a specific game and game mechanics. (Perhaps build a framework in Unreal for them to build with?)
Some students would be disappointed by the lack of creative flexibility, but I think there is a way to frame this limitation as a focus on craftwork fundamentals. In art classes, students study contour lines to add that skill to their repertoire, not because contour lines are the only skill that matters.
Integrate play-study into the course. Instead of giving a lecture with still images of Half-Life 2: Episode 2, play it live! Have students interrupt any time they notice something interesting, then pause and talk, or reload a save and play through it again.
I hope this structure, which I’ve seen work for film-studies and seminars, would give students ownership in identifying these patterns and what they do. The seminar structure is more student-driven instead of a forced teacher->student knowledge transmission and hierarchical “because I say so” assignments.
Require submissions along the way so we can check on their deliverables and help them adjust before its too late.
Maybe we’ll get to teach a course like this in the future and maybe we’ll encounter a whole new set of surprising problems! In the meanwhile, hopefully these notes have been useful for those of you who teach your own game development courses.
Cover objects are a core piece of a level designer’s toolbox, and there are many ways to use them. The examples below look at de_dust2 from Counter-Strike: Global Offensive, but some of the same concepts apply in other first-person shooter level design.
For those unfamiliar with the basics of Counter-Strike, the defusal game mode pits a team of attackers (Ts) against a team of defenders (CTs) in a series of 1-life rounds. The attackers win a round by planting and detonating a bomb at one of the two bombsites, or by eliminating the defenders. The defenders win a round by eliminating the attackers, defusing the bomb, or by running the clock out.
A full round of Counter-Strike tends to have a few phases of play:
Attackers probe the enemy defenses for information and opportunities to gain map control.
Attackers commit to taking one of the bombsites, spending utility (smoke grenades, flashbangs, and molotovs) to gain an advantage in the fight.
If the attackers succeed in planting the bomb, defenders now have an opportunity to attempt retaking the bombsite against the attackers. This behaves as a kind of role-swap where attackers are now defending and defenders are now attacking.
Cover plays many roles in each of these phases.
Also for context, this article isn’t about competitive Counter-Strike map theory and tactics. My interest is as a level designer and my experience with de_dust2 is as a casual player where some of these patterns play differently from how they play in the esport scene.
Freestanding cover objects provide a full loop of pathing around them. Players can use these cover objects to hide or hold against many angles. Here on B site for example, a player can use the tall box to hide from upper tunnels (left of image center), or to hide from window and defender arch (off screen to left)
Freestanding cover leaves options open. A player can choose to peek from either side, loop around it, or disengage. They can choose to hold close to the cover and try to peek wide and fast, throwing their opponent’s aim, or they can try to back off and play from range. So long as they are in an even fight, they have options to play that cover to their advantage. Even in a 1v2, freestanding cover can help the outnumbered player juke and stay alive, burning precious seconds off the clock.
Because of this versatility, freestanding cover tends to work best on objective sites where players may duel or attempt to run the clock down.
Directional or Team-Favored Cover
On de_dust2’s B site, there is a cubby in the wall where a large wooden gate is shut. This recess is deep enough for a player to hide behind the post and use it as cover against an attack from the upper tunnels.
The team-favored quality of cover depends on how each team approaches it. For the defending CTs, this cubby is fully visible; they don’t need to clear those angles when they enter the site. But for the attacking Ts, this cubby could hold a sneaky player, and they could lose the round if they don’t clear that angle.
Even once the attacker has cleared the cubby, they can’t use this same cover against the defenders. The cover offered by this cubby is only useful against upper tunnels. Even worse, the cubby is exposed from the defender archway, which means attackers can’t use this cover when they are holding the B site against a defender retake.
Although this cubby is defender-favored, it still requires a big commitment. If attackers throw a molotov into the cubby, that defender has no good options. Unlike the freestanding cover on the site, the cubby doesn’t allow a defender to disengage without being spotted.
The cubby is also small enough that a long rifle muzzle can stick out. The defender in this cubby either needs a short-barreled weapon or to play anti-flash (looking at the wall) and wait for a teammate to provide info. A deeper corner, which could hold more defenders or give a single defender more options, would significantly shift the balance of this site.
Another Team-Favored Cover
On the attacker approach to A site, there is a large blue garbage bin. This is a massive cover object creating a deep pocket of cover on either side. However, the attacker entryway to this area minimizes the cover that the blue bin could provide to a defender.
A defender could try to tuck into the corner on their side of blue bin, but their weapon muzzle may stick out, and the shallow depth of their corner favors the attacker clearing that angle. (By having a wider sweep of the corner, an attacker would see the defender’s shoulder before the defender could see the attacker’s.)
In practice, if attackers successfully make it out the threshold into long A, they can tuck behind blue bin and create a crossfire against any defender attempting to push into attacker territory. By gaining control of blue bin, the attackers can lock the defenders out of this part of the map without a serious expense of utility. If attackers don’t succeed in taking blue bin, they haven’t lost much ground because the defenders can’t use the blue bin against the attackers.
Imagine instead if the blue bin was a freestanding cover object like those crates on the B site objective. If attackers succeeded in pushing into long A, then they would have an additional angle to loop around the blue bins, making it harder for defenders to hold. On the other hand, if the attackers failed to push into long A, then defenders could also take control of the blue bin and use it to hold any further attack against long A. If defenders could use blue bin, they would effectively lock attackers out.
A cover object pivots when players can use the same object against multiple angles. Freestanding cover objects pivot, since they can be played for many different angles, but simple corners can also pivot.
On long A, the timings from the start of a round mean that defenders arrive at this pivot corner just before attackers can push out the arch.
This pivot behaves almost like a control point in the battle for map control. Defenders start with tentative control of this angle. If attackers succeed in their push, they can take control of the corner and use this lower part of long A as a staging area to commit to the A-site attack. Defenders could attempt retaking long A from attackers, or attackers could opt to silently disengage and leave defenders worried about an attack that never comes.
Outside of Counter-Strike, payload levels often use corners like checkpoints. Defenders start with control of a corner that lets them hold back the attack. But if attackers manage to push the defenders away from the corner, the attackers can now push up and use that same corner against the defenders into the next stretch of the fight.
Cover can also soften or harden the effect of a pivot. Imagine how some alternatives to long A might play:
Adding a full sized cover object here would create an extra pocket that attackers need to clear on their approach to the A site. To clear this pocket, attackers would be exposed to all of the angles at the top of long A. Also, if a defender has to disengage from a fight on the pivot, they would now have this safe pocket to retreat to instead of being stuck in the killzone of the long A street.
A similar cover object deeper on long A has the opposite effect. This reduces the number of angles that an attacker has to worry about when peeking the corner. It blocks off the sightline at “Goose” (the left corner at the top of the street). This cover also lengthens the distance a defender needs to retreat from the pivot before reaching safety. Attackers could also creep up to the pocket created by this cover and hold there safely, similar to how blue bin functions prior to this area.
However, for Counter-Strike’s gameplay, any of these cover modifications to long A could upset a delicate balance, making long A plays either the dominant tactic or a nonviable tactic.
A Note About Utility
If you aren’t familiar with the specifics of Counter-Strike, the empty stretch of road on long A may look like bad level design. In Call of Duty, this area would be a death trap, and common Call of Duty layout patterns would suggest the area needs flank routes and more cover here. However, in Counter-Strike these paths are possible in exchange for utility.
Smoke grenades deny vision. Smoking a threshold or t-junction can deny a path or allow a safe crossing. Smoking a corner create pockets of hidden information and off angles for enemies to worry about. Players can also deploy a smoke in the open, like the one pictured above, to create new angles for players to fight around. Smokes behave like cover objects in how they conceal information.
Molotovs and incendiary grenades behave as area denial. They can negate a cover object. In the picture above, my molotov is clearing out the corner behind the car. If an enemy is hiding in the corner, I would hear a hit effect of the molotov damage ticking. The enemy trapped in the corner would either have to deploy a smoke to extinguish the molotov or try to escape the flames and run into my crosshair.
There are also flashbangs, which can blind players or force them to look away for a crucial moment.
This combination of utility makes it possible for attackers to push areas like long A, but it comes at a cost. Each player can only carry so much utility, and grenades cost resources as part of a match’s persistent economy. When players throw their utility to push long A, they have made an investment that requires them to follow through before the smokes fade.
Taken together, these details of cover form a few patterns:
On the attacker side of the map, cover tends to be attacker-favored with opportunities to gain territory and lock defenders out from easily retaking it. I think of this pattern as “footholds”. The attacker side of long A and the upper tunnels are both attacker-favored footholds.
The objective sites are built to support defender retakes, which means they have the most freestanding cover in the map and support a wider variety of engagement angles. There may be some team-favored positions such as the cubby on B site, but these tend to come at the cost of locking a player to their position.
Separating the attacker-favored footholds from the defender sides of the map there are killzones without any cover. For B site, it is the long hall of upper tunnels. For A site, it is the long stretch of road. In both cases, the killzones require a hard commitment where attackers need to spend their limited utility to attempt the crossing.
These patterns reinforce the stages of play I described at the start, and when a map rearranges these patterns, the stages of play change too. Some Counter-Strike maps make the attacker footholds weaker, offering greater possibility for defenders to get aggressive and lock attackers out of options on the map. Other maps make path commitments harder or easier, which affects how defender prioritize positioning and resources. Even within the same game mode rules, a few tweaks to cover can make a huge difference in how a map plays.
The notes above aren’t comprehensive. Cover has different quirks in every game, even within the same genre. What’s true of Counter-Strike isn’t quite true of Halo or Call of Duty. Despite that, I hope the notes above gave you some new ways to think about cover and how level design can use it.
Last winter in London, Ontario, I spent an evening watching the ice skaters at Victoria Park. I first saw the skaters as a group, a few dozen people skating in a large circular pattern like one entity. But sitting to watch them, I saw more in motion at the rink than I can describe by the motions of the skaters around the ice.
There were games within games, merging, breaking off, and forming anew. There were stunts and tricks demonstrating skill, or daring, or beauty. There were chases where pairs weaved between slower skaters, treating them like obstacles in a game all their own.
There were individuals and groups. The solo skaters seemed lost in their experience, lost in the practiced motions of their bodies, faces blank with concentration. There were groups of friends teaching and supporting. A new skater shuffle-stepped across the ice, arms raised at their sides to balance and reach for their friends if they slipped. There was the turn-taking of teaching–I show, now you try.
There were couples skating together. Holding hands, the skaters’ different velocities drew them together or apart. Holding hands revealed a hidden goal of synchronicity. There were playful failures of one partner catching up to the other, or of one dragging the other behind. When one partner pushed too strongly ahead, their hands slipped apart.
With one couple, the young man was a more experienced skater than the woman with him. He skated a stride ahead without losing her hand, then turned to face her while his velocity continued forward. Skating backward now and slowing, he let his date continue on her own trajectory gently into him and his embrace. They laughed. A show of skill and confidence as flirtation.
As with the best playgrounds, the ice rink was a space for play that didn’t force specific acts. Instead, the ice rink enabled many forms of play that could shift and transform. A group of friends could split into pairs, become a chase, become a dance, become a tutorial, become a romance, and then reunify as a group of friends.
That same period of play could mean many things to each participant whose path had crossed many social worlds. For the couple falling in love on the ice, or for the pair chasing in sport, everyone else must have disappeared as others beyond the circle of their game.
I left wondering if I have created play spaces that allow for such a rich variety of social experience. Have I created games with greater depth or wider possibility than an ice rink? Have I created games where my players can fall in love?
Pieter Bruegel the Elder’s Winter Landscape with Skaters (1565)
In my previous blog post, I described level design as constraint management. Level designers take the needs of art, design, and tech, and we try to resolve their conflicts through the process of creating our levels.
In that post I also hinted that the way we negotiate these constraints is by building level geometry; we negotiate through the process. The complexity of all these constraints is too great to solve in our heads or solve on paper; we have to build and iterate on our proposed solutions, which are our levels.
On team projects, this also means the purpose of a level blockout is to communicate with teammates across disciplines. The blockout should communicate our solution so others can evaluate if it works for their need.
But, shame on me, my previous post didn’t give examples from an actual level and blockout process! Thus, the need for this followup post.
To keep the example simple, let’s say I’m once again making a Quake 1 singleplayer map.
Imagine I already have a beginning to the map, which slowly sets a mysterious tone and sense of place in overgrown ruins. Imagine I have also introduced the basic weapons and monsters for the level, gradually raising the tension. As the player delves deeper into the ruins, the floor falls out from under them and drops them into an encounter room!
I have a few ideas for how to build this encounter:
At first, no enemies. The space should start as a puzzle-exploration room, then turn into a combat room.
There should be a clear goal for the player. I want them to see the exit in their first scan of the room but not know how to reach it. Maybe an exit to an ascending staircase that the player can see across a chasm too wide to jump.
As the player explores the room, looking for a way to reach the exit, they should discover a few buttons. When the player activates one of these buttons, some level geometry in the middle of the room rises, forming a platform for a few seconds, and then reverts. Individually, it isn’t clear how these buttons and platforms help. But once the player has discovered them all and tested some combinations, they grant the player access up onto a ledge, where an intermediary goal waits!
Because the buttons are on timers, the player should have smooth paths around the space, no awkward turns or frustrating collision. The buttons should also ideally have a view on the platforms they trigger.
At the intermediary goal on the ledge, there is a use-once switch. When the player activates this switch, a new platform ascends at the chasm. This new platform still isn’t enough for the player to jump all the way across to the exit, but it hints that one more platform should be enough.
The ledge with the intermediary goal should also show the position of the other intermediary goal so the player knows where to go next.
The player should now *get* what they need to do to escape. The player has solved the puzzle and now just need to complete it. This is good for player-intentionality, but it’s also boring. So now let’s add monsters!
I want to gradually shift the tone from puzzle-exploration to combat, so I will open monster closets in waves. This means the same puzzle space from before should also serve for combat: no awkward dead-ends or bad collision for the player or monsters to get stuck on.
The ambush should surprise the player. This means the monsters can’t be waiting behind locked doors from the moment the player first falls into the room; that would be obvious! I also want the player to think “ah if only I had paid closer attention, I could have anticipated!” This means no teleporting monsters into the arena. A tricky problem!
The monster variety during this combat encounter should escalate over time. Depending on how I’ve built the space, some monsters may not work.
Once the player defeats all the waves of monsters, the player should now be able to reach the other ledge and complete the second intermediary goal.
When the player presses the use-once switch for the second intermediary goal, a second platform ascends, completing a jumping path across the chasm to the exit.
As the player prepares to cross to the exit, one final wave of monsters! A “boss” wave! This may also be a great opportunity to drop in a quad damage powerup to increase the intensity. For this phase of combat, teleporting the monsters in is OK. (The player’s expectations should have shifted after the first combat waves, and they should be expecting more combat at any moment, so teleport spawning no longer feels as cheap.)
At last, the player kills all the monsters, reaches the exit, and returns to the rest of the level above! The encounter room is complete!
Those are my initial goals for the encounter room (revised a little for clarity). Already, I noted a few challenges in making this encounter work, but I need to build the space to see. Sketches can help me identify more of these problems before I move into the level editor. Likely, I will change my plan for the space as I build it and struggle with all of the moving parts. Then, once I’ve built the level, my pan will definitely change with playtesting.
A quick sketch of the encounter, and just enough info to block out the space in the editor.
So far, the biggest conflicts in this encounter room are between gameplay types. What works well for a puzzle-exploration phase at the start might get in the way during the combat later on. For example, I want the buttons to be hidden enough that the player needs to explore the space, while for combat I don’t want the space to sprawl or become too fragmented.
The other conflict is handling the surprise. When the player first falls into the room, I need to reassure them that this is a puzzle room, that there aren’t any monsters around, nor any combat-cover, nor suspicious monster-closet locked doors. But the room still needs all of those things for the combat phase!
Turning the encounter into a constraint diagram, there are a lot of conflicts! And this is before we consider art…
I need to solve these conflicts as I built my level. Already, this encounter room is a challenge to build well! But my constraints so far are mostly about the abstract gameplay…
Time for Nightmare mode. “Architectural Realism” adds a whole new set of constraints:
What was the purpose of the room originally? Who built it, when, and why?
How has the room fallen into this state of ruin? Is it water damage? Erosion undercutting the foundations? Was there a singular event that led to this state, like a flood, earthquake, or explosion?
How do the buttons operate? Are there moving chains and counter-weights that connect the buttons to the level geometry they affect? Can the player see these moving parts?
What purpose did these buttons and moving geometry have within the original space? Or did someone graft these features onto the ruins later on? Either way, why are they there?
Are these moving components used often? Or is this the first time anyone has used the space in years? Decades? Centuries?
Why were there monsters waiting in closets? How did they get there? Have they been there a long time? How did they survive without food and water?
Thankfully, when mapping for Quake 1, I don’t care! (Or at least, I don’t care too much.) Quake’s chunky graphics mean that realism is off limits. I have to embrace some degree of abstraction.
Up to a point, Quake 1’s players also don’t care. Players want the level to convey a fantasy, which requires a consistent theme and governing logic. This is very flexible! If the level is a ruined temple, floating platforms are probably bad. But if the level is a floating castle in the sky, then floating platforms are probably better than grounded ones. My rule-of-thumb: if I would believe the space in a dream, then it’s good enough for Quake. (And if the space is the kind of dreamscape that would stick with me once I woke, then it’s great for Quake!)
But outside this specific example of making an encounter room for a Quake 1 map, these “architectural realism” questions often matter a lot! For western AAA games in 2020, players want spaces they can recognize from the real world, things like hospitals, cities, parking garages, offices, airports, suburbs… Even in sci-fi games, players don’t want generic sci-fi corridors; they want sci-fi hospitals, sci-fi cities, sci-fi parking garages… (This is a big generalization, of course. Some games within the Western AAA space care about “architectural realism” more than others.)
If I take my room encounter’s design from earlier and I apply the constraints of architectural realism, this is a hellish challenge. Likely, I need to change my design and loosen the constraints for art. This means stepping back from the specifics and considering my big goals with the encounter—the series of feelings I want the player to experience—rather than the implementation details such as the arrangement of buttons and platforms. From these big goals, it is easier to find a solution for these conflicts.
In practice, most levels don’t solve all of their constraints. Production imposes its own set of constraints: time, budget, team size, and scope. As a level designer / constraint manager, I need to find working solutions. I need to build foundations that solve the most important conflicts and leave room to iterate on the details and smaller conflicts from there as the team has time. Making games is messy.
In the end, the “design” in level design isn’t some magic or some lofty science exclusive to those of us with the job title. Level design as constraint management means building, testing, communicating, and iterating. This is the reality for anyone tasked with implementation, building tangible solutions to abstract goals and needs. Level design is craftwork, and that means building.