Player Roles: Observers and Participants

Some conjecture : Ideal observer/participant relationships

In the interest of fleshing out this theory, or at least showing how it could be fleshed out, I’ve taken the liberty of very quickly drawing up a graph of what an ideal observer/participant relationship might look like when plotted over the course of an entire game.

This is a trivial exercise that I haven’t put much thought into, so I expect that a more thoroughly researched graph would look somewhat different than what I present here.

A healthy player engages with media along a continuum of the two roles.  The player balances between which role has primary control of the experience at any given moment, allows the two roles to, in a sense, converse with each other.  In the interest of sparking discussion, a simplified version of an ideal relationship is shown below.

A quickly constructed graph of what an ideal curve *might* look like

The marked areas can be described as follows:

  1. A player hears about your game and purchases it.
  2. A player starts playing your game.  He/she goes through some type of intro or gets a feel for the base mechanics/story.  Investment is (preferably) high enough to make him/her switch from a primarily observer role to a participant.
  3. The main portion of the play experience.  Your player becomes more invested in the game as it continues.
  4. Your game reaches its climax and ending.  The player entirely embodies the role of the participant.
  5. Post game content : new game+, optional quests, replay value, etc…  Your player has seen (functionally) most of what your game has to offer, or at the very least, you won’t be throwing new ideas at them.  Eventually your player will put the game away and move on.
  6. The player moves on from your game.  He/she is able to more objectively analyze the entire experience.  The observer takes dominance, but ideally the player does not fully shift out of the participant role for some time.

Again, I want to iterate that this graph is pure conjecture of the most trivial and thoughtless kind.  I would expect these curves to look very different in the real world, for a variety of reasons.  For example:

  • A game might be designed to be replayed multiple times.
  • A game might not be designed to be finished at all or to have a specific ending.
  • A game might be very short, designed to demonstrate a concept very quickly rather than engage the audience.
  • A game might transform its experience while it is played, via a twist or a shift in gameplay, causing the player to shift back and forth between roles more rapidly.
  • A game might end very abruptly, including no post-game content.
  • A game might be designed to lead directly into a sequel.

Even working under the assumption that the graph I put together is actually accurate, any number of changes would effect the way this curve looks.

How all this can actually be used then

  • Build player trust:  

Build portions of your game around the concept of proving credibility. Behind the scenes, this is a way of speaking directly to the player (observer), and convincing him/her that your game should be engaged with.

  • Use player trust:  

Build portions of your game around engaging directly with the participant.  Your game should transition away from the justification phase: you should be able to ask the player to do things they’re uncomfortable with from both a narrative and gameplay perspective.  These are the sections where you can be most creative, and where you have the opportunities to create the most memorable experiences.

  • Don’t encourage players to stay in one role for too long:

This can often be a problem with community driven games.  At some point, you will need to transition your players from observer roles to participant roles.  This means that at some point they need to stop giving you input or to have some type of signal to begin trusting you.  This is a shift between asking , “What do I want this game to be?”  and “What is the game and how should I interact with it?”

Similarly, it’s unhealthy for players to stay as participants for too long.  Players that are unable to transition back to observers are more likely to start devolving their experience into escapism.  A healthy community is an intelligent community, so you should periodically encourage them to take a step back and examine/evaluate their experiences. Why elements do they like?  What didn’t work?  What would they like to see in the future? A well established community views itself as existing in a supportive, almost team-like role. Encourage your players to be discerning, and they will in turn encourage you to make the best experiences possible.

  • Give players predictable indications of when their roles are meant to change: 

Related to the above point, try to minimize any subconscious confusion your player may have about what role you are asking them to be in.   My goal here isn’t to define exactly when people should be in each role for your specific game, so there are a number of ways you might approach this, depending on if you’re building a narrative experience, or a pure-gameplay experience, or a mood-driven game, or so on and so on.

  • Adjust your perspective on what you’re supposed to be delivering:  

There’s a trend in modern gaming to consider players as having nearly identical roles to designers throughout the entire process of making a game.  Community driven games are awesome, but even in the most successful cases, they work because of strong, rigid structures and barriers between players and developers.

Your role as a designer is more akin to a teacher than a servant.  Players want to experience games as participants.  You should enable them to do so, even at the risk of removing some of their control from the development experience.  Be wary of how you implement player suggestions like, “It would feel awesome to have x…”, or “Y would be amazingly addictive.”  No one can simultaneously be a player and a designer, so try not to force your community into an uncomfortable dichotomy.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">