Ryan W's Demo Manifesto
Walkthroughs are an essential part of this site, because they are based on the direct gaming experience that made Doom so important to each of us. Textual walkthroughs are a traditional and efficient way to convey facts and data. Some readers however do not naturally absorb information from text, or even from annotated map views; they need to watch over someone's shoulder and see the in-game sequence of events unfold. Like many gamers, I can remember people who could only navigate a Labyrinth level by feel, or retained the geography of Rygar better by not drawing a map. It is for such right-brain players that walkthrough demos are created.
While I personally have pledged to stop uploading 7-hour LMPs, this page is still slanted toward the inexperienced player. In any instructional activity, certain participants will demand an accelerated syllabus, or reject our examples as too artificial and academic. Those players should be referred to the COMPET-N stacks and the miscellaneous historical sites (such as idgames/lmps), respectively. For the rest of the audience, our paradigm is analogous to the written walkthroughs: the more we standardize and simplify our presentation, the more clearly a map's individual characteristics stand out.
Ryan W, 2011 March 05
Although a particularly difficult battle scenario may force compromise, the following are ideals of all demos:
- Keep moving. If the end product is too boring to watch, it can't educate anybody.
- Every pickup should be visible in the recording, whether the player needs it or not.
- Melee weapons are considered too unwieldy to use.
- Darkness in an OEM level should not be sufficiently incongruous to affect combat (intense blinking lights are another matter).
- Choose the compatibility mode that makes playback most straightforward for the most users, assuming that the WAD design doesn't require a particular format.
As the difficulty setting increases, these general trends are present:
- Less hoarding for the next level.
- Less clearance when aiming the rocket launcher.
- If a group of monsters is encountered, lower skill levels peel them off individually to ambush them in an empty room. Higher skill levels tend to awaken them together, then string them out between obstructions so that they attack one by one.
When the player is backed into a corner and must overreach one of the limitations listed below, that ability becomes more accessible in future maps. Completing an episode also makes you more powerful.
The ITYTD player is more disoriented than fascinated. Perhaps she rarely plays video games, or perhaps she spends most of her time with RPGs and puzzle titles. When a game engine is new to her, she repeatedly attempts tactics which seem like common sense but don't work. Although she genuinely wants to improve, this frustration sometimes induces capricious reactions to in-game adversity.
Hopefully, our demos will convince this player that she can:
- Shoot straight when not under duress.
- Plan ahead for the next battle. For example, draw the correct weapon before teleporting; avoid the blur artifact next to the mancubus trap.
- Execute timing patterns (like the chaingun secret on E1M7) at about 40 percent COMPET-N speed.
- Use stereo sound cues to outmaneuver a monster behind a wall/door.
First-timers who experience "FPS motion sickness" should STOP PLAYING. No video game is worth injuring yourself over. (Hey, now you have more time to spend on Apeiron and Mighty Final Fight.)
The HNTR player is only a slightly stronger fighter than the above, but has a much better feel for the game environment. His movements are faster and more agile, and he can predict contingencies by examining a level's layout.
Specific advantages include:
- Jack-in-the-boxing against one overmatched opponent.
- Hiding behind locked doors.
- Deliberate barrel frags.
- Aiming jumps in automap mode.
- Calculated risks may be taken to gain loot earlier, if no monsters are present (e.g. the blue armor on E1M1).
- Any barrel that might absorb crossfire near the player should be preemptively removed.
- Sound-blocking linedefs, monster-blocking linedefs, impassable linedefs, and REJECT anomalies can be turned to the player's advantage.
- Exploitable bugs, such as sticky doortracks and vertical blast damage, are known and used.
The HMP player has significant experience with one or two other FPSes. He has a general grasp of monster AI, and can adapt to his circumstances by making health/ammo tradeoffs. His maneuverability usually allows him to fire accurately while in motion. He can employ infighting almost at will.
Abilities gained at this level include:
- Chaingun tapping.
- Jack-in-the boxing against successive opponents (i.e. can feel his way backward along a passage after inspecting it carefully).
- Stopping short after a jump.
- "Slicing the pie" to check for stragglers, so that hearing/seeing each monster death is not required.
- Calculated risks may be taken to gain loot earlier, even if monsters are present (e.g. the yellow key area on E1M6).
- Exceptionally annoying opponents, such as arch-viles and pain elementals, are targeted first to get them out of the way.
On HMP and higher, serious players learn to identify their own weak points and design practice sessions around them. The route in the demo should look rehearsed.
The UV player has beaten other FPS games. She is confident and aggressive, fully expecting to reach the exit. She knows how to attack any monster with any weapon at a pinch. She normally eschews infighting, her footwork and ammo management being adequate to soften up a crowd of enemies from a distance.
Differences from the HMP player include:
- The run key is usually down.
- Firing angles are always lined up in real time, without frotting three walls every time a new sergeant comes into view.
- Assuming sufficient ammo and maneuvering space, a boss can be fought in the open field.
- Large calculated risks are acceptable in the first 1 or 2 rooms of a level (with nothing to set one's back against), if there is enough health elsewhere to compensate.
IMO this kind of thing should not be controversial in an open-content reference work — do we require each article to be written in one draft and never revised? Nevertheless, altering demos remains a sensitive issue in the Doom community, so I had better explain myself.
A calculus textbook uses contrived examples to illustrate a point cleanly, rather than randomly choosing a real-world problem and hoping it will be tractable. A newspaper article might be reorganized several times before publication, as the reporter and editor decide how to present the story most engagingly. Similarly, a walkthrough demo is wholly focused on the viewer, not the author. If deleting filler material aids comprehension, and if a little extra effort allows a representative outcome of every encounter to be included, then such decisions make for a better encyclopedia, period.
Although all performances are designed to be as reproducible as possible (no mouse, no backspace, no Z axis), these features of PrBoom+ apply to my demos:
- The -recordfromto and -skipsec options are used to play from savestates.
- The -shorttics option is globally active. That bug definitely disrupted my timing in ye olde demo sessions.
- High-resolution (software rendered) display modes.
- iddt and automap overlay for tracking monster movement and double-checking harvesting (but obviously never for targeting or locating items — that must be based on what the camera sees and hears).
- Game speed is occasionally increased to wait out a monster migration.
- The overlay player marker is used as a long-range crosshair, compensating for the weapon alignment bug. (This is my smallest advantage, as it can be approximated by rapidly hitting the tab key.)
- These ideas didn't originate with me, but from the reminiscences of experienced players on dwforums.
- This kind of thing develops through practice, according to the Doom manual. I personally had a rather serrated learning curve, as I refused to play below UV after I finally got my own copy.
- Or so we are told by period observers (cdrom.com, DHT, Usenet).