Consider it stolen: Developer Moments

You’ll have to forgive me for the amount of cited text in this post. The only excuse I have is “Dammit, Corvus is on to something very interesting here and I need to steal it”. Well, not steal steal, I’m just going to use this idea in my future posts and the way I design games.

Anyway, a couple of days ago Corvus published two posts that were trying to come up with a broader and more comprehensive definition of what we previously viewed as “cutscenes”, since most discussions about them never went anywhere. They almost always devolved into addressing the definition of the word, for example, if being rendered in real-time or being pre-rendered actually mattered. (If you ask me, it matters in a very very tiny way:  because there’s less of a visual separation between actual gameplay and the cutscene itself. Like I said: Tiny.)

In those two posts, Corvus came up with a broader term to encompass all of the instances where the designer takes a portion of the control away from the player, but with one exception:

Developer Moment: Any time the player’s available verbs are restricted beyond what can be attributed to a clear narrative device.

Furthermore, he defined three categories of Developer Moments:

Exposition: These DMs give the player insight into the world. They establish history, set up scenes, and show character moments that can’t be easily revealed through gameplay. Beyond Good & Evil made great use of Exposition DMs. When people defend cut scenes, they most often reference this classification of DMs. They are also the easiest to get right and probably the hardest to implement as actual gameplay.

Foreshadowing: These DMs are the other half of the narrative coin. Instead of showing what is, or what has been, they harbinger what is to come. Yesterday I referenced Tombraider’s camera swoops that show you where you need to go in a level. That’s a use of Foreshadowing DMs. In Castle Crashers there’s a level where you can’t advance until you’ve watched an animal shit itself to death in fear of something. Since you can normally advance after dispatching all the enemies on a screen, I consider that a Foreshadowing DM as well.

Puppeteering: These DMs involve ensuring the player behaves in a manner consistent with the developers’ expectations. Puppeteering DMs typically involve showing the player’s character performing actions that could normally be performed by the player. For example: moving the player’s avatar to a specific point in a room to keep them from colliding with an incoming boss, which happened Blood Omen 2: Legacy of Kain, or switching to a cut scene to show them walking them through a door they’ve just opened, as happened in Star Wars: Knights of the Old Republic.

To me, a Developer Moment is a concept that begs to be used in the analysis of game design, as opposed to the concept of “Cutscene”. Though I have to admit that it took me a few days to start thinking about game design in this way.

You know, for the last two years I’ve seen people discuss how Valve handles their Developer Moments in Half-Life. Some don’t like them because they can’t be skipped like a normal cutscene, but most of us love them for letting the player free at all times, even if “free” only means having control over the character within a limited space with only one way of progressing through the area. The thing is, with Corvus’ definition of Developer Moment stuck in my head, now I see more clearly why Valve’s philosophy struck a chord with so many people: They refuse to treat the player like a puppet.

And that’s a design philosophy I can get behind.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s