Classic Combat
design exercise for a classic retro shooter type game
Last updated
design exercise for a classic retro shooter type game
Last updated
In this project, you'll research, pitch, and prototype a combat arena for a fast-paced arcade-style retro first person shooter. Classic FPS games like Doom and Quake emphasized constant movement against hordes of enemies with simple AI patterns, and heavily influenced contemporary action shooter game design today. This design exercise focuses more on your design thinking and communication skills, rather than construction or production skills.
Before continuing, make sure you've read about Pacing, Balance, and Encounters.
Educators: if you're assigning this design exercise in a class, we strongly recommend assigning the same game for everyone -- either Doom or Quake.
If you are new to first person shooters or usually dislike these games, choose Doom or Doom 2.
If you are interested in the hardcore technical details of shooter design, then study Quake.
Follow this guide for getting Quake working. We recommend the QuakeSpasm source port, and no graphics mods.
Chances are, you haven't played any of these games recently, if ever. For better or worse, these are iconic key games that deeply influenced the game industry forever. You should probably learn why.
For the purposes of this exercise, you need to play at least 5-10 levels, to the extent that you will recognize most of the weapons and monsters, which will probably take at least an hour. Play enough so that you can talk about it, and it's OK to use cheats or play on easy mode -- we're here to study the design, not to prove gamer skills.
To activate invulnerability in Doom, type IDDQD
.
To activate god mode in Quake, open the console with ~ (tilde), type god
, and press enter.
Both Doom and Quake have been, as academics say, "well theorized." There's been lots of design analysis and criticism written about both games over the past few decades. Being a game designer means interacting with this legacy and joining the conversation.
If you played Doom or Doom 2, read the short essay "Coelacanth: Lessons from Doom" by JP LeBreton, industry level designer on BioShock and Psychonauts 2. Then reflect on these questions:
LeBreton references a 1982 arcade game called Robotron 2084. Is it really that similar to Doom? You can decide for yourself and play Robotron for free in your browser at Archive.org (click the button to start the emulator, and when you see the "Factory Settings Restored" screen press F2).
After you've played Robotron for at least 15 minutes, compare it to Doom. Are the controls similar? What about the weapons, the enemies, and of course, the level design?
LeBreton argues that Doom's "weapon design is strongly orthogonal." What do you think he means by that? Give an example of orthogonality in a different game.
Why is the essay titled "Coelacanth"? (Google it.) According to LeBreton, what do modern FPS games do, and how does he feel about them? Do you agree or disagree, why or why not?
If you played Quake, read the changelog for the Quake mod "Copper" by Matthew Breit, industry level designer on Quake 4, Titanfall, and The Beginner's Guide. Then reflect on these questions:
Explain Breit's tweak to the Ogre grenade aiming formula, and summarize why he thinks it is necessary. What are the possible arguments against this new behavior?
Google how player armor in Quake works. What is the armor damage mitigation formula, and what is Breit's critique and fix for it? Do you agree?
What were Breit's design pillars for Copper? Who is Breit's audience for the mod and this changelog post? How does this audience differ from modern FPS audiences today?
Of the levels you played for either Doom or Quake, which was your favorite, and why?
Describe one weapon and player tactic that is effective against one monster type, but ineffective against a different monster type. Why?
Identify two different monsters that are interesting to fight in the same room, and two monster types that don't seem to work well together.
Breit notes that "very few things in Quake's game code (or, for that matter, Doom's) changed with [difficulty] level." Why do you think that is?
Both Doom and Quake feature a secondary mechanic called "in-fighting", where a monster can accidentally attack another monster, causing them to fight each other. Which monster type seems to be the best suited for causing in-fighting?
OK, time to do some level design. Your task is to design a one room arena for Doom or Quake. It must include:
2-3 types of monsters
1-2 weapons
1-2 minutes of gameplay
Sketch 10+ small parti thumbnails. (1-2 min) Conceptualize the big idea behind your arena. Don't overthink it, just draw any shapes that might symbolize how the level would play out. What type of combat do you want to pursue? Which weapons and monsters will be there?
Then sketch a 3+ possible layouts for a one room arena. (5 min each) For the purposes of this exercise, do not try to build a big huge elaborate level. Instead, focus on making just one room interesting enough.
Then, pick your favorite layout, and rethink it. (5-10 min) Keep your layout loose and don't try to lock it down so fast. Make at least one big change. What if you used a different monster type? What if you replaced the boxy room with a cylindrical room?
This drawing should have a little bit more detail, and you should definitely label it and explain more of your concept. It should answer these basic questions:
Write 1 player experience goal for the encounter. What kind of combat or tactics will your encounter emphasize? What will encourage full use of the combat space?
Are there any breadcrumb trails with health or ammo pickups to help motivate the player to move around the arena?
Will you use any locked doors or keys to gate the player's progress?
Label core elements like player and enemy spawns, items, hazards, etc. and highlight a critical path.
(TODO: show some one room arena encounter sketch samples)
Pitch your design to someone else, and have them use the rubric below to judge your pitch based on the (a) experience goal, (b) supported play styles, and (c) clarity of plan. For example. they might say your experience goal felt memorable, but doesn't really support any clear paths or strategies, and too many questions remain unanswered.
In your pitch, make sure you narrate different ways how the combat encounter would likely play out, while summarizing your intent and the player experience. Good luck!
Try to implement your design plan within the actual game.
Before you begin a blockout, make sure you understand the metrics for the game. For your convenience, we have gathered the basic metrics for Doom and Quake:
Now it's time to open a level editor, and blockout a simple one room arena with monsters and weapons.
If you're new to level design and construction, we recommend starting with Doom because the editor uses a simpler 2D interface.
If you want to use something more complicated to learn, you can try to build in full 3D for Quake.
See the Tools page for links to Doom and Quake resources.
You don't have to follow your plan from the Layout phase exactly, but use your sketch as a general guide while you Blockout and Iterate. When you playtest you will probably realize your plan didn't work out the way you imagined, and you'll have to change your plan -- and that's OK, that's what level design is all about.
Remember the original brief and keep it small, especially if this is your first ever level. Do not make an arena more than ~1024 units wide, and do not spend more than a few hours.
The purpose of the blockout phase is to test metrics and gameplay. Use prototyping textures, and do not waste time on decoration or lighting.
Monsters don't really have true pathfinding, so keep areas somewhat open to give them enough space to wander. Your hallways, if any, should be 128+ units wide.
To confine a monster to an area, build a height difference into the floor. It is useful to "leash" monsters with ranged attacks (Imps in Doom, Enforcers and Ogres in Quake) by placing them on a raised platform that is too tall for them to descend.
First, playtest the level yourself. Can you complete your own level? If you cannot, then it is probably way too difficult for the average player.
After the level passes your personal playtests, go on and playtest with at least 3 different people.
For info on how to find playtesters or run a playtest session, see Playtesting.
As you run the playtest, ask yourself:
Can the average complete your level without any guidance or intervention?
How many times did each player die and restart? Zero deaths might mean it is too easy, a couple deaths mean the arena is appropriately challenging, and 10+ deaths might mean it is too difficult and most players would likely give up.
Our goal was 1-2 minutes of gameplay. If the fight is always over in a minute or less, that's too quick. If the fight usually takes 5 minutes or more, that's way too much.
The whole point of playtesting is to iterate and make changes based on the feedback. If you do nothing in response to a testing session, then arguably you are not doing design. It is always possible to improve something.
Make at least one change to your level geometry. Rebuild a room, add an extra platform, extend a hallway, carve a new doorway. No level is perfect.
Make at least one change to your monster or item placement. What if you tried a different monster type? If you changed your level geometry, does this new floor / wall / room accommodate a new monster? What if you offered the player a different weapon against that monster?
Add one secret, like a hidden weapon or item. It can be tucked away in a corner, or it can sit behind a secret door that looks like a wall. What would be satisfying to discover? What kind of secret would feel fair and appropriate to the rest of the level?
Congratulations, you just built a classic first person shooter level! You have followed the tradition of countless level designers and modders before you.
Take some time to reflect on your experience. What parts of the design process did you enjoy? How will that influence your creative process in the future?
Repeat this project, make another Doom or Quake level.
Try some other projects.
Read about the History of encounter design.
Evaluation
Experience goal
Supported play styles
Clarity of plan
Memorable, cohesive
Multiple robust strategies
Can visualize it all
Typical, predictable
One ideal path with side paths
Need to clarify details
Confusing, incompatible
No clear path or strategy
Too many questions
Feeling
Research
Layout + Pitch
Blockout
Playtesting
Research was very useful and relevant.
I enjoyed discussing plans.
I love building a space and walking in it.
I love to see others play my work.
Research was OK I guess, I see the point.
It was helpful to communicate.
Building a space was OK, but a lot of work.
A little playtesting is useful. A little.
I don't like doing research and it has no purpose.
I'd rather not share my plans with anyone.
Building was boring and time-consuming.
Playtests make me anxious and scared.