Boundary Conditions.

In any simulated system there are boundaries, points at which the model being used breaks down, where player behaviour is no longer accounted for. The most obvious of these are the physical boundaries of the game space, the chasm too wide to cross or the wall too high to climb. To a large extent the methods for dealing with these physical boundaries are well developed and understood; though it’s still not uncommon for the occasional invisible wall to appear blocking progress along what looks like a valid route.

Another form of boundary found within the simulated systems of video games are those between supported player actions and unsupported player actions. In his GDC 2004 lecture (.zip file) on the subject Clint Hocking details three ways in which a game can deal with this type of simulation boundary. They can either “extend the design” by adding additional abilities so as to extend the bounds of the simulation further; “support the failure” by allowing the simulation to break but providing alternate means of progress; or “end the game” with a game over screen or a similarly absolute resolution.

Each of these approaches has its benefits and drawbacks, extending the design offers more possibilities to the player but is little more than a way of moving the goal posts. Supporting failure again serves to provide additional possibilities as success at a given task is no longer the only means of progression, unfortunately supporting all failure states can lead to actions feeling like they have no consequence. Ending the game has the benefit of being the clearest means by which to resolve player action at the boundary but it is also the most artificial and heavy handed.

In a recent article on Dishonored, Robert Yang describes a way in which that game deals with a simulation boundary he encountered within the opening moments. My initial reaction to this criticism was that it seemed petty to criticize what is ostensible a tutorial for limiting player agency for the sake of teaching something. This was narrow-minded of me, Robert is raising an interest point about the manner in which Dishonored handles simulation boundaries, and how that compares to the games it is drawing its design influences from. Instead of softly accounting for any errant behaviour and shepherding players back into the supported space Dishonored instead chooses to set a hard boundary identified in some instances by an explicit game over screen. It’s a choice that, as he points out, runs contrary to the approached traditionally adopted by the “immersive sim”. Instead of extending the design or supporting failure as the likes of Deus Ex and System Shock do Dishonored instead resorts of ending the game when certain boundaries are crossed.

The benefit of such an approach is that the feedback is clear and unambiguous: this is an unsupported action, refrain from attempting it again. The same hard boundary can be enforced at many different points at the limits of the simulation, any actions that are unaccounted for can be dealt with in the same absolute fashion. A benefit of this approach is that it avoids one of the problems associated with softer boundaries which is that of repetition of behaviour  If I perform an unsupported action once, such as  jumping on an NPC’s head, it makes sense for this to elicit a response. Consider the Metro Cops in the opening sections of Half-Life 2. When you throw something at them, or otherwise antagonize them, they will push you back and tell you to stop, if you persist they will draw their stun batons and beat you. That is as far as the simulation allows them to go, you can keep throwing things at their head and keep getting beaten for as long as you like nothing further will happen.

Dishonored 01

Apparently jumping on the head of the High Overseer is a Capital Offense in Dunwall. The game over screen is an inelegant but certainly unambiguous means of dealing with unsupported behavior.

When considering the different ways in which games like Deus Ex, Thief and Dishonored deal with simulation boundaries what stands out is that the times at which these games resort either to hard boundaries, or explicitly limiting player behaviour  is when players are required to interact with other characters. It comes as little surprise then that the series that relies most on resolving boundary infractions softly is System Shock, where there are no living characters with whom the player can directly interact.

In Dishonored the approach of presenting a hard boundary is exclusively reserved for dealings with NPC’s, specifically those the game has identified as allies. Dishonored is attempting, by means of hard simulation boundaries, to establish an identity for it’s protagonist Corvo Attano. This is why these boundaries are most obvious in the the prologue section (where Corvo is still the Lord Protector and the Empress is still alive), and in the Hound Pits sections between missions.  Certain parts of Corvo’s identity are defined, certain parts are not and the way Corvo treats the people deemed to be his allies is part of the former and something the player has little influence over.

Dishonored‘s design metaphor (that of being a supernatural assassin) doesn’t effectively account for Corvo having allies. As an assassin he only really has targets, and characters or objects that are preventing him from reaching those targets. Though appropriate fictionally even the notion of a non-lethal means of dealing with his targets starts to push at the bounds of that design metaphor. In the missions themselves where there are no explicit allies the approach Dishonored takes to simulation boundaries is to support failure. One of the side effects of which, as Clint Hocking describes, is that this serves to makes the game easier, there is almost always an alternate means of performing a required tasks or reaching a specific objective.

Corvo, and by extension the player, is assumed to be acting in the interests of the Loyalists even if they are not shared interests. This leads to the perception that the only meaningful actions are those related to people you are not required to be nice to, these are the only ones where player actions remain largely unrestricted and thus have direct consequences. In Dishonored the way you treat your “friends” is largely irrelevant. You are only judged by how you choose to treat people you don’t need to treat well.

For all that has changed in game design in the thirteen years since System Shock 2, games like it are still using conceptually similar means of dealing with living characters. These hard boundaries and limits on player agency are inelegant and often binary solutions that are jarring when set beside the softer less absolute means by which other forms of player behaviour are handled.

Tags: , , , , , , , , , ,

3 Comments

  • Hey Justin, having been absent from reading blogs for the past year and a half, it’s pleasing to return to something smart and well written like this piece.

    Would not a simple solution to the final paragraph be to include social systems/mechanics similar to games like Fallout, offer multiple outcomes and opt for the “support the failure” option?

    • Justin Keverne says:

      The current models used for social interactions tend to be discrete and based around a limited range of options. Other parts of the game can be built upon the simulation of light, sound, or rigid body physics. Such models are continuous and analogue, having a greater range of possible inputs and outputs. If you only have the option to say one of four things that’s an obvious boundary to the simulation. It’s softer than the explicit game over screen, but it can still be jarring when juxtaposed with the more systemic aspects of the game.

      A answer would be to systematise social interactions, which is something I’ve thought a lot about, but that is still a significant challenge.

  • Sure. I see what you’re saying. Thanks. I’ll go off and read the other article now.

Leave a Reply

XHTML: You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>