Locations Have Layers: How Can a Room Outage Affect Only the Devices It Should?

A power outage in one room should change only that room’s local power condition. The building and area must retain their own power records. Whether a device can ultimately operate is then determined by following the power path it actually depends on. Do not give every scene a shared “power on/off” switch, and do not equate “the room’s wiring is working” with “the room’s light is on.”

The following story, A Night Visit to the Eastbank Archives, is a fictional teaching example, not a real user case, a tested result, or a description of product features. All power relationships are simplified rules created for working through narrative scenarios, not for operating real equipment.

In the story, the player needs to consult a catalog in a reading room. There are three location levels: the Eastbank area, the archives building, and Reading Room 203. The archives also has a corridor, and Eastbank also has a station. At the start, local power to the reading room is interrupted, but the corridor lights and station screen remain on, as does the battery-powered reading lamp in the room.

These four observations can all be true at once. They require the author to answer two different questions: where an object is, and what keeps it running. The location hierarchy defines scope; dependencies explain effects. Neither can replace the other.

You can reuse the following record format directly. Here, “normal” means only that there is no fault at this level; it does not guarantee that upstream power is available.

For each change, add a separate event card: “Event name｜Location｜Field changed｜New value｜Cause｜Condition for clearing.” For example: “Reading room power loss｜203｜Local power｜Interrupted｜Fault preset for this chapter｜Room restoration event.” This card changes only one object; it does not also update the archives and Eastbank.

Distinguish locations using stable IDs; names are for display only. Even if another building also has a Room 203, it must not read the same fault record.

The scope card should also distinguish “normal,” “interrupted,” and “unknown.” Before the archives has been investigated, a dark room is no reason to enter “power interrupted throughout the building.” What a character knows need not match everything the author has recorded.

This example uses the following rule: an ordinary ceiling light comes on only when area power, building power, and local room power are all normal, and the light’s switch is on. If any condition is unmet, the light stays off. Several conditions jointly determine the outcome; this is not a rule that “smaller locations take priority.”

A room record of “local power normal” therefore cannot override an area outage. It says only that the room itself has no additional fault. Conversely, a room outage does not rewrite the area record or write a fault into the neighboring room’s record.

The battery-powered reading lamp checks its own battery and switch, not the power chain above. It is an exception grounded in explicit dependencies, not an impromptu declaration that “this spot is unaffected” because the author wants to leave a light on. When the battery fails, the exception ends.

A reusable evaluation sequence is: identify the target device, list its dependency path, read each current condition, and finally determine the device’s behavior. When records change, simply reevaluate the affected objects. There is no need to copy “area power interrupted” into every room as a local fault.

Nor does an entire bundle of location states propagate. An area outage can affect devices connected to that power chain, but it does not automatically change whether a door is locked, whether the catalog has been taken, or whether a character knows what happened. If an outage changes access control, write a separate dependency rule for that system.

Now have the player leave the reading room, enter the corridor, and return. Every step uses the same scope card instead of guessing the state again when entering a scene.

At the first stage, only the reading room’s local power is interrupted. Its ceiling light is off, while the corridor lights, battery-powered reading lamp, and station screen are on. The player can still choose to consult the catalog by the reading lamp or look for new information in the corridor. The difference between these actions comes from existing conditions.

At the second stage, a story event cuts power to Eastbank. Change only the area power record to “interrupted.” The corridor lights and station screen go dark, the reading room’s ceiling light remains off, and the battery-powered reading lamp stays on. The room’s original fault remains in its own record.

At the third stage, power returns to Eastbank. The corridor lights and station screen come back on, but the reading room’s ceiling light stays off because its local fault has not been cleared. This is an easy place to make a mistake: setting every device to “on” in one operation would erase the story condition established at the first stage.

At the fourth stage, the room restoration event occurs, changing local power to “normal.” The ceiling light comes on provided its switch is still on. Whether the battery-powered reading lamp is switched off must be determined by its own switch record; restoring room power must not reset it as a side effect.

The third stage could read: “Light from the corridor seeped beneath the door again, but the light overhead did not respond. The reading lamp on the desk still illuminated half a page of the catalog.” This passage presents only visible differences. The character may infer that the local fault persists, but the narration does not presume to declare the state of the entire city.

Treat the following four points as expected outcomes for the author’s walkthrough on paper, not as test results already obtained: a room outage does not change the corridor; an area outage does not switch off an independent battery lamp; area restoration does not clear a room fault; leaving and reentering a room does not reset any condition that has not been cleared.

Also reverse the event order: cut area power first, then restore local room power. The ceiling light should still be off at this point; only when area power returns afterward are the conditions for illumination met. If identical current conditions produce different outcomes, check whether the previous conclusion that “the light is off” was incorrectly stored, or whether the switch state was omitted.

For a short story with only two scenes, you can also list devices individually without building a complete hierarchy. The tradeoff is that each new device requires an individual scope check. If several rooms share an independent circuit, a location tree alone is insufficient. Add a “power group” record and have devices explicitly reference it; do not invent spatial relationships just to fit a three-level structure.

Sound, standing water, and sightlines may not propagate through location containment either; each needs its own connection conditions. This article’s three-level approach addresses only power scope in this example. It is not a universal physical rule for all location states.

When you finish, retain one scope card, a set of device dependencies, and the expectations for all four stages. Any sentence such as “the whole building went dark” should be traceable to a condition change capable of affecting the entire building. If the only event you can find concerns one room, keep the narration within that room.