FR

Réalités Parallèles

Ergonomie et conception de jeu vidéo

Full Indie 2016 - Design constrains in narrative exploration games

  1. 1 – Shackled by the premises
  2. 2 – Present tense is hard
  3. 3 – Communicating information to the player is hard
  4. 4 – Narrative is all there is
  5. 5 – Playtesting is hard
    1. Nels experience of playtesting Firewatch
  6. My two cents as a games user researcher
    1. Give roleplaying a try on your next narrative exploration game
    2. Here’s some reasons to try out roleplaying in your company
    3. The challenges of roleplaying as a user research technique
    4. What you can expect from “roleplay-testing” your game

Nels Anderson shared some of the things he has learnt making Firewatch during 2016th Full Indie summit. Being more of a systems designer, he has learnt a lot working on a narrative exploration.

Unlike puzzle games like the Talos Principle or The witness, narrative exploration games (sadly known as walking simulators) don’t rely on puzzles to keep the player going. Unlike Life is Strange or Tales of Borderlands, the player is the one deciding where he’s taking the adventure.

As a result, Nels had to learn to face five challenges which he shared with us : being shackled by the premises, working in present tense, communicating information to the player, making the game work when narrative is all there is, and playtesting this kind of game.

1 – Shackled by the premises

In narrative exploration games, suspension of disbelief is extremely fragile. In other types of games, you can work backwards, and player will be forgiving if something doesn’t completely make sense.

In walking simulators, they won’t. Things that don’t matter and you can usually skip over can make or break the game in a walking simulator. You can’t handwave stuff away. Optional things become mandatory, specially in an open environment like Firewatch.

Firewatch strongly draws the player on the main path, but despite knowing what you’re showing the player, you can never be sure about when it is going to happen. As a result, the level design needs to be thought out carefully to make sure the player gets what’s happening.

2 – Present tense is hard

It’s easier to tell a story which happened in the past. The player can explore and piece information together from clues about the past. When things happen in the present, the plot is unfolding around the player. How to make sure he’s actually there ? Also, the game takes place over a whole summer. How to fast forward to the interesting bits during the duration of the game ?

Cuts are needed to progress through time, but they often came at surprising moments, discouraging players of exploring outside the main plot line.

3 – Communicating information to the player is hard

There’s nothing in Wyoming, no houses with poeple who wrote stuff on notes, no personal belongings to tell the story of inhabitants… Firewatch relies a lot on Delilah, a radio operator the player can communicate with. But she also has her limits, many things the player needs to know can’t go through her, because it wouldn’t make sense she’d know about them.

The player can give her some information, but even then, you can’t control what dialog options the player is going to use.

4 – Narrative is all there is

Since the game relies solely on narrative, it better be good. How to make it tangible ? A lot of the narrative goes through dialogs here, and Valve’s tech for managing context in dynamic dialogs played a big role in telling a compelling story.

For Firewatch, a lot of context is stored during the game, and dialogs used many weighted possible answers to take in account the context. Lots of the context is never used in the end, but it helps giving the most interesting dialogs.

The fine polish of these interactions requires a lot of creativity, but the good news is : it is still cheaper than to add a new boss to a game in a different genre.

5 – Playtesting is hard

Nels experience of playtesting Firewatch

Firewatch was playtested weekly, one player a week. It was easy for the developers to figure out when something was broken. It was easy to notice when a player didn’t get something, or was having problems.

One of the benefits of playtesting, other than identifying issues and fixing them to improve the player’s experience was that playtesting uncovered ways to add more interactivity to the game.

The big challenge, when something didn’t work as intended was to figure out why ? Understanding and making sense of playtest results was the hard part.

It was also hard because the developers had to test near shipping quality content before knowing if it would work. They made all the content in order.

Now I don’t agree with that last point. If you’re testing the game, so many tiny factors can have a huge effect on player behavior in game that it does need to be quite polished. It is however possible to identify many of the factors before even having a prototype. How ?

My two cents as a games user researcher

What struck me with this conference is the repeated confirmation that developers struggle with testing narrative elements of games. I have contributed to a few interactive stories, worked on an immersive and abstract storytelling installation, text based adventures, tested an interactive book for children on tablet… And I’ve found one opportunity to take some pain out of designing narrative exploration.

Give roleplaying a try on your next narrative exploration game

Table top roleplaying, my friends. LARP or real life simulations can help. I’ve used this method before, and we spared a lot of time, efforts and frustrations thanks to roleplaying. We identified many issues and requirements during the roleplaying sessions. Roleplaying gave us a comprehensive understanding of how players tried to interact with our game, what caught their attention and how to draw it where we wanted it. We had a comprehensive list of audio cues and visual elements to use and where to place them. And we were extremely happy to gain these insights during week 2, not two weeks before the demo was due, when we finally had a playtest-ready prototype.

Here’s some reasons to try out roleplaying in your company

The challenges of roleplaying as a user research technique

Roleplaying does require some practice to be an efficient way of uncovering opportunities and anticipating issues before developing anything.

What you can expect from “roleplay-testing” your game

Roleplaying won’t make it easier to figure out one way to systematically replicate a certain behavior but it makes experimenting easier, cheaper and faster. It helps

It will help you to have a structurally sound concept to begin with. You’ll still have to playtest polished versions of the game, but it’s less likely that you need to change whole, costly chucks of the game.

Posted by Cornelia on 2017-07-27. Last updated on 2020-08-15

Articles on similar topics

Full Indie 2016 - How to create 4D games

Game development conference, Full Indie conference,

Full Indie 2016 - Skill or illusion of skill

Game development conference, Full Indie conference,

Full Indie 2016 - Learning from Brigador’s mistakes

Game development conference, Full Indie conference,

Full Indie 2016 - A love letter to Alt Games

Game development conference, Full Indie conference,

Full Indie 2016 - Mixed reality trailers

Game development conference, Full Indie conference,

Full Indie 2016 - Alt Ctrl – innovating in the hardware scene

Game development conference, Full Indie conference,