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

• Roleplaying is cheap: it fully leverages the imagination of players, limiting the production cost to the brainstorming before roleplaying sessions and the time of two persons during the roleplaying sessions : a game master (usually the game designer) and an observer (preferably someone experienced in observation techniques)
• Roleplaying reveals useful information: what motivates players, what they try to do and what information they need or what incentive works best to get them to the next part of the story as soon as there is an idea drafted out.
• Roleplaying allows designers to iterate faster, improvise alternative paths and change a design without any cost between each sessions, or stray from the original path planned for a specific session (which can also be a risk if it happens too early or too often)

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.

• The game designer needs to practice to tell the tale realistically, as the player would experience it in game. They need to become comfortable in the game master’s role. It’s important to keep in mind the clues that can and can not be given in the game to tell a realistic simulation.
• Although improvisation is one of the strength of roleplaying sessions, the game master needs to have a clear idea that he wants to refine. It’s easy to get side tracked or tell a story that works but can never be implemented the same way in game. Each session should start with a clear path to test, boundaries of what is possible or not in the actual game, hypothesis on player behavior. The output should document viable and non viable solutions tried live and what developments or assets are needed to implement them.
• It’s a two persons job. You can’t run the game and make sense of the player’s behavior at the same time. You need someone experienced in observation techniques to take notes, ask questions, give feedback (both on the game mastering biases and the player experience itself) and discuss the takeaways. It’ll help the gamemaster to deliberately practice his design skills through this method, as much as increase the quality of results you get from the roleplay based playtesting.

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

• to identify the conditions for a specific behavior you expect of the player.
• to figure out how to convey information efficiently to encourage or discourage a behavior.
• to understand why something works or doesn’t.
• to anticipate what players will percieve and if they will see the plot unfold around them, or miss the action completely.
• to generate new ideas, use the premises to tell the story and make it believeable.

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.