FDG 2011 comments

A few comments from FDG 2011. My points are [inside brackets], the rest comes from their respective authors.

In the last Madden NFL game, people tended to play the same kinds of games and rarely changed to different types/modes.

[The Player Experience workshop had roughly 5/15 papers accepted. 3/5 accepted paper authors were not here. What's the goal of a workshop then?]

Secondary game objectives should support the primary objectives, otherwise they distract, frustrate or make the player lose. Mario side-scrollers coins sometimes make the player go off-path, but the player always has to go from left to right. Player should be told when an objective is secondary.

Minimalist game design (from one of the designers of Osmos): few rules, few mechanics, few choices, deep (combinatorial) complexity (eg NP complete), simple controls, abstract, tightly-coupled systems.

CRPG guidelines: balance should be based on player expertise or avatar skills, not on character level or XP. Avatar background should affect the game. If the avatar is supposed to have lived in the game world for years, then the game should not remind the player of the avatar background, and NPC should not meet the avatar for the first time. [Possible solution: player's avatar could start as a toddler and ages as the player spends more time IG]

Weak ties make social storytelling. [Add to this that being socially active means connecting your weak ties together (you play the go-between). Therefore, in a distant future, there should not be any social storytelling anymore because everybody will be friend (ie strong tie) with everybody. In fact, Dunbar's number says you can't be friend with more than 120 people (the other people are just contacts, not actual friends). Hence, people will keep trying to (re)connect their weak ties together! Cf also Harris and Nardi's paper on collaborative play in WoW]

Mateas: computational media is a research field in which computer science is seen as a tool for expression.

If you want a domain to progress, and the industry does not care about that domain to progress, then you have to go try academia. [Maybe a good approach in many domains, but it does not work in MMOG because building one requires hundreds of man-years]

Frustration arises when player fails to overcome a challenge. Frustration makes players impatient.

[Literature] Fundamentals of Game Design, ch 7: Storytelling and narrative

Include stories in games because they

• give context,
• attract a wider audience than bare gameplay,
• keep players interested and offer variety in long games,
• can be marketing/advertising tools

A game needs a story if it has characters, it's not too abstract (unlike Creepsmash), or if the designer wants to convey emotions.

Concepts

A story is a credible, coherent, and dramatically meaningful series of events. Interactive story contains player-performed, NPC-initiated, and narrative events. Narrative is presentational, non-interactive. Its goal is to explain why things happen in the game world.

Players want to act, but narrative is passive. Always give the player a way to skip narrative materials.

Dramatic tension happens when a viewer realizes something important is happening and he wants to know what happens next. Dramatic tension is the essence of storytelling, thanks to cliffhangers and climax. It depends on the reader's identification with a character (ability to identify and sympathize). Dramatic events should not be repetitive or happen randomly.

Gameplay tension happens when a player wants to overcome a challenge. It is caused by uncertainty of success. Can happen randomly and be repetitive (Tetris).

Linear stories

Players can't change linear stories (but still interacts with them). Require less content. Storytelling engine does not have to store critical player decisions (because player does not decide anything, illusion of choice).Guarantee that the story makes sense and is consistent with previous events. Player has no dramatic freedom, but the story has a greater emotional power.

Non-linear stories

Branching

Branchpoint is determined by in-game (NPC) events or player events. Player events consist of effort to overcome a challenge (resulting in success or failure) or a decision about the story.
Consequence of a choice can be immediate or deferred, and punctual or cumulative (ie throughout the game). Player should know which actions have which kind of consequences, otherwise it can seem unfair.
The story engine stores a story tree and the player's current position in the tree. There can be different starts based on character skills/status or randomly. Consistency requires the same node to never be visited twice.
Advantages: player has dramatic freedom, can try to explore story tree when re-playing from start.
Drawbacks: need lot of content, expensive to implement, player has to re-start a lot to see a significantly different story branch,

Foldback

Compromise between linear and branching. Players think they have control over the story the first time they play through the game, but not when they replay. Some events have no turning back because they are critical (eg death of a sidekick/ally). The designers want those events to be inevitable to convey emotions.

Emergent narrative

Story comes from play in itself. The story engine is the mechanics engine. The Sims is kind of like that. Hard because mechanics are maths, and procedurally generating emotionally meaningful stories is hard with maths.

Endings

Generate emotions. Multiple endings if you want to reflect player's dramatic choices. Choices taken when overcoming challenges do not need multiple endings (they're not emotionally meaningful).

Granularity

How often the game presents narrative elements to the player. RTS have rare cut-scenes between 2 levels, their story has large granularity. Minuscule granularity means player actions are the actual story.

Mechanisms for advancing the plot

• Series of challenges or choices: the plot advances as player overcomes challenges. Usual in large-grained games.
• Journey: travel is a key component. Player can stay in an area at will, therefore she controls the pace.
• Drama: advances at its own pace (player is just watching)

Emotional limits of interactive stories

Stories have characters. When player identifies/sympathizes with one, he can feel emotions. When the player takes decisions for his avatar, the designer has to accept them. However, bad decisions may result in a meaningless ending. Therefore, the designer may want to allow a single meaningfully emotional ending. Readers hardly believe that the narrator will die in the middle of the story. In games, player's avatar is telling the story. If he dies, the story has to stop. Avatar friends can die, though. Be a game designer, not a film maker. Interactivity is crucial.

Episodes

• Unlimited series: each episode opens and closes a plot strand. Episodes have no order. Ex: Simpsons
• Serials: Plot strands start and end in any episode. Cliffhangers are used to keep viewer interested. There's no ending, and the plot focuses on a group of people rather than on a single person. Ex: soap operas
• Limited series: plot is season-long and episodes contain sub-plots. Ex: Harry Potter movies, Dexter, 24.
• Multi-part stories: each end of an episode should resolve a conflict. Ex: Star Wars and Terminator movies.

Player-developer communication in EVE Online

CCP has an interesting take on community management. The developer's blog of EVE contains interesting behind-the-scene technical information. What is even more interesting is that these articles do not seem to be filtered or censored by any community manager. Articles are direct from the development team. I guess that the management team originally thought this communication policy was a good idea, and the developers were more than happy to post about their work. In any case, this communication policy has advantages and drawbacks.

Drawbacks

On the one hand, revealing to your players that a major database update requires a 14-hour downtime and may result in more bugs in the game (October 2010) is kind of risky. Another developer article (February 2011) started with:

Testing may show that the changes made are not safe and we won't be able to use them. I thought this would be interesting enough to share, but please do keep this disclaimer in mind as you read on.

Players start complaining on the forum boards, and it gets worse when the down time actually takes longer than the announced 14 hours. Moreover, when developers and players get close together, developers may get involved in the game and start giving unfair advantages to the players they like. This kind of cheating can get really messy (also look at the Wikipedia summary of the events).

Advantages, and why it works for EVE

On the other hand, EVE benefits from a huge support of its player base. A bunch of volunteer programs, composed of hardcore and loyal players, add content into the game, administrate a wiki, and provide player support at no cost for CCP. EVE designers targeted the game's steep learning curve for hardcore players. It's not because you are a hardcore player that you never need information or help. In fact, I think it's the opposite: hardcore players bookmark any possible source of information for their game. Therefore, EVE needs its active player community, and needs to keep a tight relationship with its player base. To receive fast and broad feedback, CCP opened nine player positions in the Council of Stellar Management in March 2008. Members of this council were elected for six months by all EVE players and invited to the development studio. They gave feedback to the developers in person. This council may have also been a marketing coup from CCP, as the studio also invited various journalists to cover the event.

So far, tight player-developer communication has been a winning strategy on many fronts for CCP. Yet, EVE does not put forward any charismatic developer. Maybe is it better like this?