I realize I have not been posting much game design related information to this blog, so here’s a snippet from the rough copy of the next Lazy Designer book.

This excerpt is from the systems chapter of Lazy Designer #3 : Designing Gameplay (now available on Amazon).

Doors

Doors seem simple, at least in our real world (unless you’ve ever had to install them) but they can cause numerous headaches in a videogame, unless well designed. The rules governing their behavior must be mapped out, from how they interact with visiblity, to how player controlled creatures and NPCs use them.

Perception

The most logical use of a door is to control what the player sees on the other side, blocking visibility when closed and revealing visual details when opened. Consequently, a natural assumption for both programmers and designers is to integrate the door system into the player’s visibility/perception/line of sight systems (systems dictating what characters are capable of observing). This is often a mistake. Though doors do need to interact with visiblity systems to some degree (since obviously they block what the player sees) there are a few reasons to avoid making them the core component of a visibility system.

Imagine that visibility extends throughout all open doors and if a door between two rooms is open, the character sees the room he is in and the room on the other side of the door. If there is an open door from the second room into a third, the third is also visible (and so on and so on). What happens in an open area, with little geometry to obstruct line of sight once the player has opened (or destroyed) all the doors?

If doors are the only component of the visibility system then the player might see the entire level, all at once! Though visually/realistically this might be appropriate it will cause performance degradation. If the entire level is visible this means the full area must be loaded into memory. For anything but the smallest of levels this be a challenge.

Certainly allow an open door to permit a character to see what lies behind but do not make that open door the sole arbiter of whether rooms load into memory.

Of course this improvement introduces new concerns (nobody said game development was easy).

If an entire area is not in memory at one time, design needs to understand the dynamics of the system used to load/unload portions of the area Why? Well consider an alert system in a dungeon cavern, where if a scout sees the player’s group they raise an alarm. If a particular room is not currently loaded into memory, the creatures within cannot respond to alarms triggered by allies! To make this work design will have to understand which chunks of an area will load together (to plan patrol routes accordingly) or creatures passing from one room to another might be allowed to pull more rooms into memory at one time; that is, the fleeing patrol guard might be able to ‘wake up’ the rest o the area, though this will have performance concerns too. Sometimes design will just have to fake it… using scripts to pretend the creatures came out of the unloaded room (by spawning duplicates of them) and then making sure that when players do reach the previously unloaded room, it is empty.

How Do You Open a Door?

Okay, what is simpler than opening a door? Again, here is an aspect where videogame implementation proves more challenging than real life.

• How do Doors Open? The direction a door opens is important. Towards or away from the character opening the door? In general opening away is simpler, but might not be feasible for your game. Are they sliding doors? This affects how the door interacts visually with other objects. If it opens towards the character using it, for example, the door will probably clip into the character.
  • Is animation showing the character opening the door required? Does this mean that character is unresponsive during the time it takes to open the door? If they are interrupted in this task (say by an area of effect attack), does the door snap closed or remain half opened? If half opened what happens when it is clicked again? Does it close? Does it open?
• Usable Doors? Generally doors serve more functions than a mere barrier. If there are gameplay systems attached to them (unlocking or bashing doors), then generally doors need to be placed by designers in a design toolset so that they may modify the parameters associated with that door (its unlock difficulty or resistance to bashing). This requires art to place appropriate door hooks into the level art, so there’s a place for design to hang the door.
  • If doors cannot be destroyed or locked or unlocked then artists will likely place doors as part of the level building process.
• Door Collision When the door does open can it collide with other objects? If it collides should it force those objects out of the way or does it clip through them? Can a player block the door to keep it open with another object? (Collision issues apply to any object that animates and decisions should be consistent.)
• Proximity Doors Doors in modern and sci-fi settings can automatically open when the player approaches them (this is less plauisible in fantasy settings, though if made part of the world design, might be explained). This approach simplifies many of the interaction and animation issues raised, above. It does have a few challenges of its own however.
  • Not all doors should automatically open because in some encounters players must prepare for the battle beyond the door. This can be mitigated by good level design. Providing sufficient hallway “resting” space between doors, with appropriate visual or narrative clues that a major battle is ahead, is often sufficient.
  • If doors automatically open, do they also automatically close? What if the characters are being chased by enemies? Would the door close on them or does the door need logic to prevent closing as objects approach it. Likewise, can the player (or an NPC) force an automatic door to remain open by dropping an object in its path?
  • If some doors are intended to be opened by picking locks (or hacking control panels) then obviously these doors cannot automatically open. But once unlocked, should such doors open immediately or require another character interaction?
• Can NPCs Open Doors? If using an automatic door system, then the answer is likely yes. In more traditional systems, the practicalities of this must be established.
  • First, this is another reason to avoid mixing room-loading and door-opening together, because a particularly eager patrol guard might open every room in the area, consequently loading every room into memory!
  • What if the NPC walks into a hostile encounter (either getting killed or unleashing a monster that then hunts down the player’s characters, overwhelming them while they are engaged in fighting during another encounter)? Or is this your intended design?
  • The open or closed state of doors often assists a player’s memory of where they have explored. When players enter an area they know that closed doors mean rooms they have not explored. So in some ways a bunch of open doors might actually confuse players because they do not know where they have been and where they need to be. An NPC moving around the area opening and closing doors might really confuse them. Again, for a particular design this might be the intention (if you are a mean designer).
• Can Characters Lock Doors? If so, what is the mechanism for this? A useable ability on the interface? A suboption off of a menu appearing on the door when clicked? Are NPCs able to bash through locked doors (or figure out a way to unlock them)? If not, does this create unbalanced combat, if crafty players can corral enemies into locked rooms, triggering traps (such as poisonous gas) to kill them off in great numbers? Or again, is this intended gameplay?
  • Locking doors is trickier in automatic door systems because as the player nears any door, it will open (so they need a way to force it to close again before locking it).
  • If player controlled characters can lock doors can NPCs be scripted to lock doors? This might be a patrol moving around locking unlocked doors while players race against them, trying to escape all the doors are locked.
• Can Scripting Open Doors? Generally I would say this is required. Even if NPCs should not open doors, it is useful for design to have this capability, even if it is simply to open a door during a cutscene to suggest a recommended path for the player.

So, as you can see, even opening a door is non-trivial. These what if questions and answers need applying to every object system in the game. A large part of my time was devoted to answering these sorts of questions, sometimes during the engine development phase of a project, but (too) often once were into full production where the wrong answer (even if it was the correct answer) might significantly derail the game’s schedule.

How about on the player side of things? Any quirks you love/hate about door systems?