Let’s say that you have a scenario featuring a pack of werewolves that have taken up residence in a ruined castle a few miles away from a small village. What scenario hook could you use to get the PCs involved in this scenario?

Perhaps:

• The villagers could ask them for help, or perhaps a local burgher could offer to pay them to root out the werewolves. (This is an example of patronage; an NPC is requesting that something specific be done.)
• The PCs could hear rumors in the local tavern about the spate of recent werewolf attacks, or perhaps they see bounty notices posted by the local sheriff. (This is an example of an offer; the GM is simply offering information and it’s up to the PCs to determine what they want to do with that information, if anything.)
• As the PCs ride past the ruined castle, a couple of the werewolves come racing out to attack them. Or perhaps they hear screams of terror emanating from a farmhouse. (This is a confrontation; the scenario is directly encountered by the PCs.)

In each case, the PCs generally come away with a basic understanding of the situation and an understanding of what action they’re expected to take: There are werewolves in the ruined castle and they need to get rid of them. (With some of the hooks they might only know that there are werewolves in the area and need to do some investigation to identify the ruined castle as their den, but that still constitutes a general understanding of the situation. It’s also possible, of course, for the PCs to choose a course of action that doesn’t involve getting rid of the werewolves: But when you design a scenario with slavering werewolves who are killing innocent people, it’s fairly clear what the expected decision will be.)

This, however, is not a necessary characteristic of a scenario hook. In each case, you can twist the scenario hook by misleading the PCs regarding either the situation or the expected course of action or both.

For example, you might mislead them regarding the nature of the threat: The villagers, discovering dismembered limbs and unfamiliar with lycanthropic activity, think that the attacks signal a return of the tribe of cannibalistic ogres who plagued the region a generation ago. That’s what they tell the PCs, who will be unpleasantly surprised — and perhaps wish they had stocked up on silver weapons! — when they head out to the ruined castle and discover the truth.

You might also mislead the players regarding the motives of the various NPCs involved. For example, it turns out that the werewolves in the ruined castle have actually come to the area to END the attacks by hunting down their former packmate who is now suffering from silvered rabies.

Or when the werewolves come rushing out of the castle towards the PCs, it’s because they’ve just escaped from the hidden torture dungeons of the local baron, who is transforming innocent villagers into werewolves to build a powerful, supernatural army. Reversing good guys and bad guys like this is an extreme example of the principle.

When NPCs are involved in delivering the misleading scenario hooks, it can be useful to distinguish between whether the NPCs are deceiving the PCs or if it is, in fact, the NPCs being deceived (or mistaken) about the situation: If the villagers know that the werewolves are just peaceful nature-lovers and they want the PCs to eliminate them so that they can claim the werewolf clan’s ancestral property in the valley, that’s a very different story from the villagers honestly believing that the werewolves are guilty of horrible crimes.

The possibilities are basically endless, and can obviously vary greatly depending on the actual details of the scenario in question.

The reason to use these misleading scenario hooks is because you’re creating a reversal: The players enter the scenario thinking that it’s one thing, and when they discover the truth the entire scenario changes into something new. In practice, delivering a strong reversal like this can turn even an otherwise pedestrian scenario into a truly memorable one.

MULTIPLE MISLEADING HOOKS

Having multiple hooks for the same scenario is a good idea, for the same reason that the Three Clue Rule is a good idea in general. Ideally, you want each of these scenario hooks to be distinct: Coming from different sources. Including different (although probably overlapping) information about what’s going on. Being driven by different motives.

(It’s less interesting for three different villagers to all follow the same basic script in asking the PCs to help them fight the werewolves. It’s more interesting if they see werewolf tracks in the forest and then a villager asks them for help and then they spot a poster offering to pay a bounty for werewolf pelts.)

When some or all of these scenario hooks are misleading — particularly if they are misleading in interesting and different ways — it not only becomes much easier to vary the hooks, it immediately creates a sense of mystery that will tantalize the players and encourage them to engage with the scenario in order to figure out what the heck is going on.

THE BAIT HOOK

The other form of a misleading scenario hook is one that is only “misleading” from a metagame perspective: This “bait hook” can be completely legitimate from the perspective of the game world, but the reason the GM includes it is in order to put the PCs in a position where they can be confronted by the true scenario.

For example, they might be hired to guard a package of diamonds that’s being delivered to a bank vault. But the only reason that job exists (and it might even go off without a hitch) is to put the PCs in the bank when the bank robbers show up.

On rare occasions, bait hooks like this can also be diegetic when an NPC gives the PCs a false job offer in order to maneuver them into a location or situation for an ulterior purpose. This plot conceit is quite common in pulp fiction, for example, when detectives are hired to keep a person or location under observation so that they can be framed for a crime.

SPOILER WARNING!

If you click the image above, you will see the entire scenario structure for the Severn Valley scenario I designed for the Alexandrian Remix of the Eternal Lies campaign. If you do not wish to be spoiled on this scenario, DO NOT CLICK THE IMAGE. Its specific content is not essential for understanding the rest of this essay, and this essay contains no other spoilers for the Severn Valley scenario or the Eternal Lies campaign.

But I did want to show an example of an actual scenario structure that’s been used in actual play, and not just some deliberately over-the-top example.

What this image is specifically showing is a visual representation of the node structure of the Severn Valley scenario. If you’ve read Node-Based Scenario Design, you may recall that the essay features a number of explanatory diagrams that look like this:

This has, for better or worse, created the misapprehension that I design scenarios using this visual motif. This is, almost without exception, not the case. (I do occasionally, during the outline stage for certain scenarios, sketch out a high-level organization to clarify the location of funnels.) And the primary reason I don’t bother with visual node diagramming is, in fact, overloaded diagrams like the one at the top of this post: That’s the structure of what I would consider a medium-complexity scenario, and the visual diagram for it is just noise… I can’t really process any meaningful data out of it and I’m the one who wrote it.

So how do I organize these scenarios?

Text-based revelation lists.

I discuss revelation lists in the Three Clue Rule: For each conclusion that you want the PCs to make, list the clues you’re including in the scenario for it. This functions as a checklist which allows you to track their progress and (importantly!) a diagnostic tool during actual play to make sure they’re on track.

In my scenarios, they look like this:

SCENE 1: ELVEN CORPSES

– The Duke’s Map (Scenario Hook)
– Encountering Mutilated Corpses (Adventure 3:The Old Forest)
– Reports of Mutilated Corpses (Adventure 2 – Scene 4)

SCENE 2: THE BLACK TREE

– Tracking Drow Scouts (Proactive 1: Drow Scouts / Scene 1)
– Map to the Black Tree (Scene 3: The Drow Camp)
– Elven Retaliation Scrolls (Proactive 2: Elven Retaliation Squad)

SCENE 3: THE DROW CAMP

– Tracking Drow Scouts (Proactive 1: Drow Scouts)
– Elven Retaliation Scrolls (Proactive 2: Elven Retaliation Squad)
– Map of the Old Forest (Scene 4: Drow Citadel)
– Questioning Prisoners (Scene 2: The Black Tree)

SCENE 4: DROW CITADEL

– Questioning Prisoners (Scene 2: The Black Tree)
– Subverting the Crystal Ball (Scene 3: The Drow Camp)
– Following the Slave Train (Scene 3: The Drow Camp)

CLUE LIST vs. REVELATION LIST

There’s basically two ways to organize lists like this: You can list all the clues a node contains or you can list all the clues that point to the node. For the sake of clearer discussion, I’m going to refer to the latter as a revelation list (like the sample above) and to the former as a clue list.

I’ll often use a clue list when outlining or developing a scenario. After coming up with the “big concept” for a scenario, my design process generally consists of writing down cool ideas for various nodes. Then I’ll think about what kind of information a node might naturally contain to point at the other nodes. For example, I might jot down:

SCENE 2: THE BLACK TREE

– Questioning Prisoners (to the Drow Citadel)
– Questioning Prisoners (to the Drow Camp)
– Drow Scouts might show up here (track to Scene 1 or Scene 3)

Once I’ve done that for all the nodes, I’ll do a quick audit for each node to make sure I’ve included three clues. If I haven’t, I’ll get proactive figuring out how I can creatively include more clues. As I actually write up the full version of each node, however, I’ll assemble the revelation list: Each clue I include in the full write-up gets listed in the revelation list under the node it’s pointing to (with a cross-reference back to where it’s found).

This allows me to double-check my design process to make sure I’ve got all the clues I need. But it’s also important because, when it comes time to actually run the scenario, it’s the revelation list that’s essential. (I’ll have long since thrown out the clue list.)

(1) I generally don’t care if the PCs have missed the clues in their current location, but I do care intensely about whether or not they’ve missed all the clues that would enable them to find a particular node. That’s what I need to track during actual game play, and it’s also the information that’s more difficult to glean on-the-fly without a properly organized list because…

(2) The information about which clues exist in a given node is already encoded in the text. The clues are listed in the description of the node, right? Because that’s where they are.

In terms of grokking how a particular scenario “works”, though, the revelation list can feel confusing if you’re not familiar with it. For some people, it’s simply more intuitive to look at the list of clues a node contains and then follow where they lead. (This is, after all, how the PCs will conceptually work their way through the scenario.) This is one reason why, when developing the design standard for Infinity scenarios of this type, I included the requirement for both a Revelation List and an Operational Summary (which would explain the sort of “guiding principle” of how the scenario was supposed to function in play).

You don’t necessarily need the Operational Summary, though. You can get the same basic effect from a revelation list: You just need to work backwards.

Look at a node and ask, “How would the PCs get there?” In other words, follow one of the clues on the revelation list back to its source node. Then repeat the process there.

For example, how would the PCs get to the Drow Citadel in the scenario above? Well, let’s pick a random clue: Following the Slave Train from Scene 3: The Drow Camp. So we look at Scene 3 and pick a random node there: Tracking Drow Scouts from their proactive scene. Since that’s a proactive scene, it’s essentially a scenario origin point. It’s the trail head, so to speak, and from the trail we’ve followed we can see that “tracking bad guys through the Old Forest” is one approach to the scenario.

Do it again: You can also get to the Drow Citadel by questioning prisoners from Scene 2: The Black Tree. You can get to the Black Tree by talking to (or stealing intelligence from) the Elven retaliation squads operating in the area. So here we have a path that follows a trail of demihuman misery.

Do this two or three times (or more for more complex scenarios) and you’ll get a pretty good feel for the contours of the scenario structure.

So you’re a GM who wants to run a new gaming system. Maybe you’re a little intimidated because it’s more complex than anything you’ve run before. Maybe it’s your first time prepping to run a game you haven’t previously played. Maybe it’s just something new.

In any case, you want the process to go smoothly. And you want to make as few mistakes as possible. (Although Step #0 is really accepting that mistakes will happen, and that’s okay. That’s part of the process.)

Step #1: Read the Rulebook. Cover to cover. I’m afraid there’s no cheating around this and no shortcuts. If you’re lucky, the RPG you’ve chosen will have a well-organized rulebook, but the process of mentally “touching” every page of the book will not only prevent you from missing a rule entirely, it will also begin constructing a mental map of the rulebook which will allow you to look up information inside it more quickly.

Step #2: Cheat Sheets. Make a cheat sheet. It’s real easy to fake mastery of a rule system when you have it all laid out six inches in front of your face. The act of creating a cheat sheet also enhances your own learning process: It involves “touching” every part of the system a second time, and also requires you to mentally engage with that system and really understand what makes it tick. (A lot of RPGs are also terrible when it comes to technical writing, and the act of boiling a messy text down into a clear cheat sheet will also result in you pre-resolving difficult cruxes that would otherwise booby trap you during play.) The cheat sheet will also often suss out those weird rules that RPG manuals leave lying about in dank corners.

Step #3: Run a One-Shot. If I’m interested in running a long-term campaign in a given system, I’ll virtually never start by jumping directly into that campaign. I’ll run a one-shot (usually with pregens). It allows both me and the players to work out the kinks, and the players gain a lot of valuable context when it comes time for creating their long-term characters.

Step #4: Co-Opt Player Expertise. Do so in every way you can. That includes, “Bob, can you look up the rule for pugilating people?” It also includes defaulting to, “Anybody know the rules for pugilating people?” (instead of defaulting to looking it up yourself). There’s sneakier stuff, too, like, “I can’t figure out how to beat the PCs when they use ability X. So I’m going to design a bunch of bad guys who use ability X, and I’ll see how the players deal with it.”

Step #5: Rules Highlight Sessions. This is something I originally discussed in Random GM Tips: Running the Combat, but for any game with a lot of specialized sub-systems, I’ll very specifically design sessions which highlight a particular sub-system so that we can, as a group, get a lot of focused repetition using it. Often groups struggle with these sub-systems because they only come up once every four or five sessions, which means every time they come up you’ve forgotten the last time you muddle through them and you end up muddling through them again. Having problems with grappling? A whole scenario based around grasping gorillas and their pet pythons will usually lock those rules in for the group. You’ll have increased expertise across the entire group.

Step #6: Set a Reference Time Limit. If you find yourself getting frequently bogged down in the new rules, set a time limit. If you can’t find the answer you’re looking for in 30 seconds (or 60 seconds or whatever feels right to you), make an arbitrary ruling and move on. Be open and clear about what you’re doing with the players, and make a note to review those rules after the session. Then, before the next session, review the correct rules with the group.

Step #7: Identify Your Hierarchy of Reference. This is something I originally discussed in the Art of the Key, but you should try to prep your scenario notes so that everything you personally need is on the page. (This can tie in well with #5.) Where the system cheat sheet gives you the core rules at your fingertips, this technique puts the relevant class abilities, superpowers, creature features, and similar character-specific abilities that are pertinent to the current situation at your fingertips. Over time, recognize when you’ve mastered certain material so that you can refocus your notes on just the stuff that you need now (i.e., “I now know what the Spring Attack feat does, so I can stop copy-pasting that into the NPC stat blocks.”)

A common form of mapping for RPG cities is the block map. For example, here’s the city of Kintargo from the Hell’s Rebels adventure path:

A common mistake when looking at such a map is to interpret each individual outline as being a single building. For example, when I posted a behind-the-scenes peek at how I developed the map for the city of Anyoc years ago, a number of people told me I’d screwed up by leaving too much space between the buildings. Except the map didn’t actually depict any individual buildings: Each outline was a separate block, made up of several different buildings.

When people look at a block map and interpret it as depicting individual buildings, how far off is their vision of the city?

Well, we can actually see this exemplified in a few cases where artists have (in my opinion) misinterpreted block maps. Blades in the Dark, for example, has a block map for the city of Duskwall. Below you can see a sample of that block map (on the left) next to a block map of a section of Paris (on the right).

If it was not self-evident, the interpretation of the Duskwall map as a block map is supported by this description of the city from the rulebook:

The city is densely packed inside the ring of immense lightning towers that protect it from the murderous ghosts of the blighted deathlands beyond. Every square foot is covered in human construction of some kind — piled one atop another with looming towers, sprawling manors, and stacked row houses; dissected by canals and narrow twisting alleys; connected by a spiderweb of roads, bridges, and elevated walkways.

You can see that if you interpret Duskwall’s map as detailing individual buildings, the layout of the city actually becomes far more organized and well-regulated than seems intended by the text. This is, in fact, a common problem when GMs misinterpret block maps: Their vision of the city, and the resulting descriptions are heavily simplified.

For example, when Ryan Dunleavy decided to develop a large version of the Duskwall map, he interpreted each block on the map as being an individual building (or, occasionally, two). Compare the resulting illustration of a single block in Duskwall (on the left) to what a single block in Paris (on the right) actually looks like:

(Please don’t interpret this as some sort of massive indictment of the artist here. Ryan Dunleavy’s cartography is gorgeous, and I recommend backing his Patreon for more of it.)

You can see another example of this with Green Ronin’s Freeport. When first revealed to the world in 2000’s Death in Freeport module, the city was depicted using a rough block map:

In 2002, for the original City of Freeport, this was redone with most of the blocks being represented as individual buildings:

The map was redone again for The Pirate’s Guide to Freeport, this time reinterpreting the original outlines as a block map:

I pull out this example primarily to point out that sometimes a block map outline IS, in fact, a single building. Because some buildings are really big. Or, in other cases, they might represent walled estates, as shown here with the estates along the western edge of the map.

And here’s a real world example of this from Paris with both the Grand Palais and the Petit Palais:

(click for larger size)

The north-south cross section of the Grand Palais is fairly comparable to the Parisian block shown above.

CONCLUSION

My point with all this basically boils down to don’t mistake the map for the territory. One of the great advantages of the block map approach to city mapping is that it leaves so much to the imagination, allowing both you and your players to lay in immense amounts of fractal complexity onto a simple geometric shape.

(Which is not to say that block maps are the be-all or end-all of utility at the gaming table. You can take my copy of Ed Bourelle’s Ptolus map when you pry it from my cold, dead hands.)

And when you miss that opportunity — when your mental image of the block map reduces each geometric shape to a single building — you’re robbing the city of its grandeur, its complexity, and its flexibility.

Take a moment to go back and look at the map of Kintargo, for example. Imagine what that city would look like if each block were, in fact, a single building. What you’ll probably end up with is a modest city still possessed of some good degree of size. But what you should actually end up with in your mind’s eye is this:

This article is a patron request from Robert Rendell. Help support the Alexandrian by visiting my Patreon.

This isn’t the first time I’ve talked about stealth here at the Alexandrian. Much of what I’ve written about is how to adjudicate stealth in a way which makes it a viable strategy for the PCs to pursue: Far too many GMs resolve stealth by having every PC in the group make a Stealth check opposed by the Notice check of every single NPC who could possibly see them. (In some systems it’s even worse, with GMs requiring every PC to make multiple checks opposed by every single NPC that could possibly see them.)

One way of dealing with this is to just have the PCs’ skill at stealth completely outclass the NPCs around them. Even in systems where the PCs are allowed to achieve supreme levels of power, however, this is usually doesn’t happen: The game world too often levels up with them, and because it seems that game designers are generally terribly paranoid about their bad guys NOT noticing the PCs, virtually every single NPC has their Notice checks cranked up through the roof. Even if this was generally true, however, I wouldn’t be entirely satisfied with the results. My goal isn’t to make Stealth automatically successful; it’s to make it viable. I don’t want to take the consequences of failing a Stealth check off the table (they can be interesting); I just don’t want that to be the de facto outcome every time Stealth is attempted (because, in short order, nobody will attempt Stealth any more).

So I generally suggest two broad paradigms when resolving Stealth attempts.

First, reduce the number of required rolls. When you call for a separate check against every single NPC, you’re usually rolling to failure. Avoid that by using let it ride techniques, resolving entire Stealth approaches in a single mechanical resolution. (For an example of how effective this can be in practice, check out Let it Ride on the Death Star.)

Second, reduce the number of people rolling. You’ll note that this also reduces the number of rolls required. If you have seven PCs roll to resolve a Stealth attempt whereas normally only one PC needs to roll a skill in order to accomplish an objective (like opening a locked door, for example), you’ve created a situation very analogous to rolling to failure and with the same unappealing probability curve; you’re just doing it all at once.

Generally speaking, you want to get the Stealth resolution boiled down to a single mechanical check (just like 99% of all other resolution checks you make in the game). One way to do that is to specify that the character with the lowest Stealth skill in the group makes the check. This makes sense because they’re the one pulling the rest of the group down, right? Personally, though, I’m not a fan of this approach. It penalizes the Stealth specialist in a way that other specialists are NOT punished, robbing the Stealth specialist of their well-deserved spotlight. I also think it’s more reasonable to assume that a character skilled in stealth can help their companions sneak into situations that they wouldn’t normally be able to sneak into.

Instead, I like to institute some form of piggybacking. This often requires a little bit of mechanical finagling in the system of your choice, but it’s worth the effort because once you have the mechanical structure you’ll find it coming in useful time and time again. For more discussion on this, check out Group Checks.

A PARADIGM FOR STEALTH

When designing the Infinity Roleplaying Game, I designed a new game structure for resolving stealth. I think it provides a clear paradigm for GMs to use in making rulings about stealth, and I also think you’ll find it easy to adapt to most any game system.

STEALTH STATES: Characters exist in one of three stealth states.

• Revealed characters are visible to their enemies and their precise location is known.
• Detected characters cannot currently be seen by their enemies, but their presence and approximate location are known. (“I heard something in the bushes over there.” or “The shot came from that apartment building!”)
• Hidden characters cannot currently be seen, heard, or otherwise perceived by the enemies. Although an enemy may be aware of their presence, their actual location is not known. (“Someone broke a lock on Entrance 3A. Sweep the building.”)

The states of “detected” and “hidden” are referred to as “stealthy states”.

STEALTH STATE TESTS: When a character in a stealthy state takes an action, they may need to make a stealth state check. Opponents can also take action to force characters in a stealthy state make a stealth state test. (“I’m going to check the warehouse again.”) The exact mechanic you use to resolve a stealth state check will obviously depend on what game you’re using.

STEALTHY ACTIONS: Becoming hidden is an action which requires a stealth state test. Once a character is in a stealthy state, they remain in that state until either they or an opponent takes an action which threatens that state. In general, these actions are not specifically classified. This is not a laundry list; it’s a paradigm that GMs can use to make their rulings.

• A silent action does not change the stealth state of the character performing it.
• A sneaky action requires a stealth state test, which is performed as part of the same action. If the test fails, the character’s stealth state is reduced by one step.
• A noisy action allows opponents to automatically make some form of Observation test (with a difficulty determined by exactly how noisy the action is) in order to detect the character, reducing their stealth state by one step.

Design Note: You’ll probably also want some mechanism by which the reaction to a noisy action can be escalated to a two step reduction: Margin of success or possibly an additional action of some type. In Infinity the Observation test was made at difficulty 0 (making it essentially automatic unless the environment, special equipment, or special training applied a difficulty modifier to the Observation test), and success allowed for an immediate Reaction to force an opposed stealth state test to escalate to a two step loss (immediately revealing a previously Hidden character).

You may also want some mechanism by which stealthy characters can reduce the severity of a stealthy action by one or two steps. In Infinity, for example, you can spend 2 Momentum to reduce a noisy action to a sneaky action or a sneaky action to a silent action. But there are any number of options beyond bennie spends.

COMMON SENSE PREVAILS: Many actions that directly affect a target (like shooting them) will automatically result in a stealthy character becoming detected by the target (even if they perform the attack in perfect silence from a state of impenetrable invisibility). Characters can also choose to simply stop being stealthy, either deliberately or as an obvious consequence to their actions. (“I’m going to walk out into the well-lit parking lot with my hands on my head and shout out my surrender.”)

MANY FORMS OF STEALTH: The Infinity Roleplaying Game takes this paradigm one step further by applying the same core structure to stealthy actions in other contexts (such as the hacking sequences of Infowar scenes and the social confrontations of Psywar scenes). This is part of a wider design methodology I used in Infinity to unify mechanical paradigms and structures in order to keep the system easy to learn and use even though it needed to cover the vast panoply of structures found in a full-blown space opera. (This, however, is a topic for another time.)

STEALTH AND ENHANCED PERCEPTIONS

Something that I think can be a struggle for GMs in general are characters who possess some form of enhanced perception: You’re already trying to keep a consistent picture of the campaign world in your head using the five senses you’re familiar with, and now you suddenly need to also try to imagine that setting through totally alien eyes. There’s a wider discussion to be had about enhanced perceptions in RPGs, but they also clearly have an impact on the rulings you make about stealth specifically.

For example, Eclipse Phase is a game where a truly dizzying array of enhanced perceptions are virtually commonplace. They include (just counting perception of the physical world):

• IR
• UV
• T-Ray
• Radar
• Enhanced Smell
• Electrical Sensitivity
• Magnetic Sensitivity
• Radiation Sense
• Zoom Vision

And this doesn’t even include the more esoteric examples, like the completely bizarre array of senses available to the suryas (space whales).

Often the best way to get a grip on this sort of thing is to take your cue from the resolution: Note that a character has, for example, infrared vision. If they successfully spot someone trying to sneak past them, think about how their infrared vision could have helped them do that and frame your description of what happens accordingly. Conversely, if they fail to spot someone trying to sneak past them, think about how that person could have thwarted their infrared vision (finding a hot background to hide against, for example) and describe accordingly. In doing so you’ll not only be teaching yourself to think about the world in terms of these enhanced perceptions, you’ll also be slowly introducing these concepts to the players. As both you and the players gain expertise over time, these enhanced senses will become integrated into your vision of the game world and you’ll likely begin preemptively taking them into account.

For example, your players might start saying before the check that they’re going to choose an approach that will let them mask their heat signature. When that happens, remember that player expertise can trump character expertise and rule accordingly.

Something else to keep in mind, however, is that enhanced perceptions may not be strictly beneficial; they can also have drawbacks. (Think of the guy in night vision goggles who suddenly gets blinded when the lights get flipped on.) In an e-mail to me, Robert Rendell pointed out the interesting consequences of this:

For creatures who can see fine in the dark (such as most monsters who inhabit unlit areas of dungeons), a nearby light source might not be anywhere near as obvious. If you have darkvision and can already see your surroundings perfectly well, someone bringing a light source near you won’t make much of a difference [i.e., it won’t allow them to see anything they couldn’t already see; it would be like carrying a candle into an already lit room… you might notice, but you might not]. You might start noticing colours, but that’s nowhere near as stark as going from blind to not blind.

Obviously, since darkvision has a fixed range, someone with a light source beyond that range would still tend to stand out. Intelligent creatures with darkvision might take advantage of that, attempting to have guard stations which have more than 60′ of clear sight along straight approaches to their lairs so approaching light sources are more obvious. They could also take other precautions: Having bright colours near their guard stations which will leap out when light is brought near, or even writing “Intruders!” in coloured paint on the wall to alert them when light is nearby.

This is obviously dependent on exactly how you choose to metaphysically interpret “darkvision” (and that might vary from one type of darkvision to another). But it’s a really cool idea, and highlights a way in which you can make this panoply of perceptions in fantastical worlds really come alive, creating a truly unique world with experiences you could never have in the here and now.

Another way to think about this within our wider paradigm for stealth is that actions might be classified differently depending on the senses which are perceiving them: For example, walking through a dark dungeon with a candle in your hand might qualify as a noisy action if someone with normal vision is trying to spot you. But the light might be totally irrelevant to a creature who can perceive the world only through radar, effectively rendering the candle-carrying a silent action vs. those creatures. Whether used in various gradations or as hard binaries, this can give some concrete mechanical oomph to the unique properties of these different types of perception.