Three Hundred :: Mechanic #169 Sites:     Webcomics   |   Three Hundred Mechanics   |   Three Hundred Prototypes
 Three Hundred
   - Index Page
   - About...
   - By Year

   - Comp-Grid
   - Procedural
   - Tactics
   - Tiny Crawl
   - Misc

PreviousMechanic #169Next

  Mechanic #169 - Interactive Fiction - Stealth
Posted: Oct 16, 2013

A number of techniques intended to bring stealth-based gameplay to interactive fiction.

  Interactive Fiction - Stealth

Interactive Fiction is well known for its ability to convey a deep story filled with interesting puzzles. Indeed, it is the definition of "adventure game" going back Colossal Caves. The whole room-based textual world also went on in MUDs to create role playing games, PvP combat games, storytelling games, building games, and even a number of experimental games. But certain genres are difficult to convey through a traditional prose environment.

Stealth, in particular, is difficult because it is based on two things that IF traditionally does very poorly - spatial awareness and timing.

With IF, something is either in the same room as you, or it isn't. For instance, this tends to make the concept of melee weapons versus ranged weapons moot (I've seen implementations of ranged weapons which fire into a neighboring room, but it was unwieldy). Traditional stealth games tend to make a big deal out of line of site, in which you can be near an enemy, but behind them, hiding in a trash can, or simply ducking behind conveniently waist high shelving - things that you can not do with the typical IF model.

Interactive fiction is not always turn based, and indeed MUDs have real time combat, but the trick with timing in stealth-based games is that you need to perform multiple actions in a specific time frame. For instance, a guard turns his back, you leap out of the closet, suffocate him, then drag his body into the closet before a second guard wanders into the room and discovers you. To present this scenario in IF, there must be points during which the player is vulnerable. With instant actions, you could perform this entire thing with a single macro instantaneously.

What follows is my attempt to present a series of game design patterns meant to create a real time, text-based stealth gameplay system. I'm aiming for a plausible scenario that looks fun by itself, rather than just a simulation of a different genre using a weaker medium.

  Information Gathering

Text-based games tend to suffer from the wall of text syndrome. That is, when you enter a new room, you are presented with a paragraph (sometimes several) of text. Before you can determine what kind of room you are in, what the exits are, or what you can interact with, you must first read the text in its entirety. This is time consuming, but luckily, only required one. Many text games give a short room description, which reveals more information through examination (you only notice that ajar drawer after you examine the desk).

While IF tends to purposely obfuscate things, hiding everything in the wall of text, MUDs have a tradition of explicitly pointing out things like exits, players, and interactive room objects in their own sections. Arguably, in many MUDs, you don't even need to read the room descriptions to enjoy the game. Window dressing. In other words, MUDs have restructured how information is presented to the player to highlight gameplay-relevant features.  

Example 1: Gameplay-Relevant Details
Castle Hallway (n,e,w)

    This is a stonework hallway heading east from the kitchen. Through a door to the north is the dining room. Against the south wall is a [CUPBOARD] standing next to a portrait of Hitler and another portrait of Hitler, only smaller than the first portrait and painted with only a smaller amount of talent.

On the floor: a ham sandwich, dirty magazine.

CASTLE GUARD is alert and standing guard.
(CASTLE GUARD) is leaning on his spear, snoring.

In a stealth game, the most important information is the status of the NPCs. The point of the game is to avoid them and they represent the single greatest threat against the player's success. As such, I've given each NPC its own line, and put the NPC block at the prominent position at the bottom near the input. The NPC's name is BOLDED and all caps to draw attention to itself, as well as placed at the beginning of the line with the NPC's behavior coming afterwards. The non-attentive guard has his name in parenthesis (I'll discuss this more in a minute). At a glance, you can tell exactly how many NPCs are in the room, what they are doing, and what threat they pose to the player.

Stealth games don't tend to involve a lot of inventory management, so I've opted to list the items on the floor on a single line, though still separated from the wall of text room description.

The room title is followed by a listing of exits (n,e,w) so the player knows what avenues for escape are available.

Finally, important words in the room description have been singled out in bold, all caps, and isolated via brackets. This is intended to make, at a glance, the gameplay vital aspects apparent. In this case, you don't even need to read the wall of text to know that there is a cupboard in the room, and from past experiences, you know that you can hide in a cupboard.

If you were to enter this room, you'd know exactly what threats there were and what options you had for escape. These are details that are important when you are in the rush. Knowing about the portraits and dirty magazine are important, but they are important only when things are safe and quiet. In slower moments, the player has time to parse the wall of text, so the less imminent needs don't need to be as explicit.

  NPC Behavior

Line of sight is not an easy thing to emulate when players are either in the same room as NPCs or not, so I've opted for a binary line of sight. Either an NPC is paying attention to things happening in the room, or not. In the above example, the sleeping castle guard is not paying attention. The player could be in the room, performing actions, and as long as those actions were quiet, it would not alert the guard.

Rooms are filled with distractions that can affect whether an NPC is attentive or not. NPCs can look at dirty magazines, stare wistfully out a window, use a computer, dig through the trash, and so on. Each of these distractions comes with a stream of state-change actions that indicate the NPC's status.  

Example 2: Window Distraction
(CASTLE GUARD) is coming this way.

CASTLE GUARD has entered the room.


CASTLE GUARD is looking visibly bored.

(CASTLE GUARD) stares out the window.


(CASTLE GUARD) stretches into a yawn.

CASTLE GUARD turns around, surveying the room.

(CASTLE GUARD) stares back out the window.


(CASTLE GUARD) sighs loudly.

CASTLE GUARD turns away from the window.


(CASTLE GUARD) starts walking off to the east.

Castle guard has left.

As seen here, the guard comes into the room and gets distracted by the window, changing his alert status several times. In each case, there is a small bit of warning before he does. The "..." indicates long periods of time where the state doesn't change. So the guard hangs out in the room for a while, alert. Before he turns to the window, losing his alertness, it is predicted by a warning that he looks visibly bored. This lets the player know that something is going to happen, and he can start typing in his next command.

Movement between rooms is not an instantaneous event. Instead, warnings are barked at the player that the guard is arriving or leaving before the actual action occurs. So the first second or so that an NPC is in a room, it is not alert, giving the player a chance to flee or hide if need be.

Players can encourage these state changes intentionally. For instance, if a radio is left on, the guard would be distracted momentarily as he turned it off. Or the player could leave a dirty magazine on the floor which the guard would likely be distracted with for some time. Or, if the guards are distracted, but not distracted enough, the player could interrupt one distraction with another. For example, turning off the power could cause the TV to go out, forcing a guard to leave the room so that the player could then perform many loud, alert-worthy actions.

  Hey! Listen!

This is all great an all, but if the player is just standing there when these NPC state change, he's going to get busted. So there needs to be an indirect way through which the player can discern information about NPCs that aren't in the same room. This comes through the propagation of sound, and through the ability to set the player state into a listening mode.

Sounds are easy and obvious. Basically, each sound made has a loudness which dictates how well it can be heard by neighboring rooms. Each pathway the sound travels through has a cost that degrades the sound. So talking in neighboring rooms, that are close together and feature no doors or other obstacles between them, can be heard perfectly next door. With a heavy door, it may muffle the sound so that you can tell that two people are talking, but you can't hear the individual words. When you are hiding in a cupboard, the sound cost is considerably increased for any sounds that don't originate in the same room.  

Example 3: Sound Propagation
[EAST] CASTLE GUARD says, "I like to eat bananas."

[EAST] HITLER says, "I'm more of a orange man, myself."

> close east door


[EAST] SOMEONE shuffles around.

The east door is opened.

(CASTLE GUARD) is entering from the east.

> hide
(in cupboard)

[HERE] CASTLE GUARD has arrive.

[HERE] CASTLE GUARD says, "Man, I sure do love bananas."


Also available to the player is the ability to peek and listen. Peek simply lets the player look into a neighboring room. Listen focuses the player towards a specific direction, increasing the sound value for sounds coming that way. So, while a door would muffle sound, listening at the door would allow the player to ignore the dampening value of the door and passageway, hearing sounds from that direction as clearly as if he were in the same room. Listening is a state, which means that the player would continually be fed sounds while listen, but could not perform other actions.

Loud sounds, like explosions or the clanging of pots and pans, can be heard multiple rooms away. The sound is just continually damped the further away it gets, and instead of listing the direction it is heard from, it just says [SOMEWHERE FAR OFF].

Sound is a two way street. The player can perform actions that make a lot of sound that could alert guards in another room as well, causing the NPC guards to come into the room to see.

  Multi-Room Line of Sight

One important aspect of line of sight is that someone at the end of a hallway should be able to see the other end. This creates obstacles that are not easily overcome. If you had the ability to impair a neighboring room (stun grenade, perhaps?), it wouldn't affect the dude at the end of the hall. This would force the player to use different approaches to solving problems.  

Example 4: Far Off Guy
Castle Hallway (n,e,w)

    This is a stonework hallway heading east from the kitchen. Through a door to the north is the dining room. Against the south wall is a [CUPBOARD] standing next to a portrait of Hitler and another portrait of Hitler, only smaller than the first portrait and painted with only a smaller amount of talent.

On the floor: a ham sandwich, dirty magazine.

CASTLE GUARD is alert and standing guard.
... [EAST] GUARD CAPTAIN is alert and standing guard.

Guards with a longer line of sight are shown in the NPC list for the rooms that they can see, just like the other guards, but with a simple ellipsis indicating that he is afar, along with a note indicating from where he can see the room.

If you peek into a room that the guard can see, he will be listed in the NPCs, even if you could not logically see him from a particular direction. For example, looking into the hallway from the south would not logically make LOS to the guard two rooms to the east, but he is listed anyway. It is too complicated and hides too much pertinent information if it mattered which direction you viewed a neighboring room from.

Similar to sound, any behavior the guard performs while in line of sight (if the guard can see you, you can see the guard) will be echoed in each room. If something blocks the line of sight (a door is closed, the room is filled with smoke, whatever), then the guard can not see the player, nor can the player see the guard's behavior.

Most NPCs would not have extended line of sight, and would be limited to what is happening in the current room. These guys are more intended to be sentries who watch over a specific set of rooms rather than a global simulation of line of sight.

  Stealth Mode

A lot of stealth is based on line of sight, but the Hitman series uses disguises as part of its stealthiness. Basically, certain disguises cause NPCs to react differently depending on the costume and the location. If you are dressed like a cook in the kitchen, you are ignored. If you dress like a cook in the mob boss' bedroom, you are attacked. This puzzle-like aspect of locating disguises and using them properly would translate to a textual environment easily, and without modification.

As mentioned above, NPC actions take a certain amount of time to complete and feature textual updates as to their progress. The same applies to the player. An action like choking an NPC could be seen as a process that takes time to perform:  

Example 4: Far Off Guy
(CASTLE GUARD) is leaning on his spear, snoring.

> strange guard
You sneak up behind the CASTLE GUARD.

(strangle guard) The CASTLE GUARD is surprised as you wrap your hands around his neck from behind.

(strangle guard) The CASTLE GUARD is struggling.

(strangle guard) The CASTLE GUARD goes limp in your hands.

> hide body in convenient body hiding chest

While the player would be more nimble than NPCs, able to move between rooms quickly and without the warnings, there are still behaviors that are considered high risk that either take a lot of time and/or make a lot of sound. Enter stealth mode, which allows the player to trade time for silence.

In the above example, the castle guard is surprised as the player sneaks up to strangle him. The player was in stealth mode. In whatever is the opposite of stealth mode (noisy mode?), the player will rush up to the guard and strangle him twice as fast - but the guard will hear him coming and make a yelp before hand. So stealth mode = quiet/long, while noisy mode = fast/loud.

Stealth mode has a couple advantages. There is a long delay before getting spotted by sentries a couple rooms over, or by NPCs entering the room. Stealth actions, like hiding in cupboards, are instant. Can cancel certain actions before they are complete (like going into an occupied room, then reversing course). In dark or dimly lit rooms, the stealthy player will automatically hide in the shadows, becoming invisible except when performing actions.

The only real disadvantage to stealth mode is that it takes longer to perform actions. The point is to slow the action down to the point where the player is being deliberate about every move and action. It's about making the timing matter, so that the player has to wait and plan before acting.

Noisy mode is largely for when the player doesn't care about being quiet, either because there is no nearby threat or because the player is trying to use noise to manipulate NPC behavior. Also, noisy mode is the punishment for being caught by an NPC. When in pursuit and in line of sight of an enemy, stealth mode can not be enabled, meaning that footsteps are heard and hiding takes time and can be interrupted. Stealth mode is also considered "suspicious activity" when wearing a disguise and can blow your cover.



Copyright 2007-2014 Sean Howard. All rights reserved.