Skip to main content

Telling a story; Creating a Compelling Narrative.

Telling a story; Creating a Compelling Narrative.

In this blog I will talk about my own recent brush with story telling and go on to talk about how tools from creative wring can help you to better author the narrative in your games, whether they have a traditional linear narrative or a procedurally generated interactive narrative.

Narrative and structure in traditional fiction 

 

last week I started writing a story set in the world I'm developing for my game Vinland: 1936.

I hope the story will help me to flesh out my game world and develop my own expanded universe which will be a good place to set my games in the future.

After about a week of work, on and off I've progressed the story to outline stage. For each character thread I have half a dozen chapters which plot a course through the events of the story. Each thread is told from the perspective of a different character.


Actually I started writing as soon as I had my outline, but I've since gone back and deleted what I wrote. The problem was that the scenes just weren't compelling. They read like summaries of a boring office meeting or lecture.

Why? There simply wasn't any conflict, the characters didn't have clear goals, and when they did they achieved them too easily.

I spent some time talking to my old school friend, a Teacher of literature in the UK. He teaches creative writing and has written his own book, which I read last year called "Ape Flesh".

I told him I had actually looked at some online "How to..." posts about writing and they suggested using certain tools. Not computer apps, but formalist tools. Things like the "action-reaction cycle" and "Goal-Conflict-Outcome". I wanted to know if these were things that writers actually use.

Yes, it turns out they do.

Here's a pair of scenes from my Friend's scene map which he was generous enough to show me:



What is a scene map? Well it's what a novel is before it's written. It's an outline of each chapter, scene by scene.

You can see that scene number 69 is an "action" scene. This doesn't mean that it contains action, but that it is the POV character doing something (or trying to do something) while scene 70 is a "reaction" scene, i.e. the POV character reacting to what's happened.

The Action scene can be broken down in to three components:

It has a Goal; to get to the van. 
You need a goal or else your story becomes directionless. The characters float around not really knowing what they are doing (pretty common in bad novels).

It also has a Conflict; It's difficult because of darkness and mud. 
If the goal was too easy then it's not an interesting scene. Conflicts help to make the story interesting.

Finally it has an Outcome or a "disaster". They get separated.

Not every scene has to end in a disaster, but if it doesn't, and the character achieves their goal, there should be some bad side effect that negates their victory. If there's no disaster then the scene stalls and the book becomes difficult to read.

The reaction scene also has three components:

First is the Reaction; Eva is scared.
It's important to know how your characters are feeling, how they deal with stress and failure. This helps the reader to empathize with them. The reaction stage is a place you can do this without breaking up the flow of the story.

Next is the Dilemma; Is she lost?
Think of this part as the character's thought process. How do they go from failure to success, how do they move past their current obstacle. They have to identify the obstacle first and then come up with some possible choices.

Lastly is the Decision; Lewis finds her and they continue to the van.
The character has to choose a new goal. This will take you back to the start of the next Action scene.
The example here shows how the decision doesn't always have to come from the character. An outside source can force an unexpected result to the dilemma, for good or bad.

Here's one of my scenes written in the same way:


Now it is starting to sound like a real story!

Action/Reaction cycle in games

 

Anyway, this made me think about how this can be useful not just for novels but also for making games. This month's Blender Game Making Challenge is soon to start and the theme is "Tell a story".

So how do games tell a story?

Sometimes a game has a linear narrative, just like a novel. Other times it has a non-linear or interactive narrative. The tools I talked about above can be useful in any case.

If you google "Action-Reaction cycle in games" You will find a lot of articles on the subject with graphics like this:


Actually this structure is very naturally applied to games. It's how games work. Consider the following scene map:


To be complete we should consider the situation from the AI's (or GMs) perspective. it also has an action and reaction cycle which runs parallel to the player's. That's what's shown in the Action/Reaction/Processing/Decision cycle graphic above.

This is non-linear, interactive storytelling, a story that writes itself through the player's actions. So in fact we can't describe it as a linear map at all, we should use a tree:


This type of action-reaction cycle can be authored, you can design the game this way, or it can be procedurally generated. Because of the way the branching of decisions could easily become unmanageable (1>2>4>8>16>32>64>128 etc...) procedural generation is an option.

If you're going to author the story directly (by designing the levels and story by hand), you need to find a way to limit the branches of the story. This can easily make the game seem restrictive if it is done wrong, you might make it so there is only one dungeon accessible at any time for example. It would be better to make sure there is something in the dungeon that you need before you can realistically visit another one. Character levels and level appropriate monsters make a great organic method of channeling the player. In games without character levels you could use a MacGuffin.

Even if you're using Procedural generation, limiting narrative choices can be an important part of your job. Procedurally generated games can easily become boring if there is no clear narrative thread, if there's no goal or direction, or if the generated content is too random (see no-man's sky).
Again, character levels can help. Equipment and loot can be used as ongoing goals to drive the player onward. Creating prefabs or epic items can help to stop the game from being too random. This is why the procedural generation model works so well in roguelikes which have so many of these elements.

Conclusions

 

If you're making a game, whether a linear narrative like a point and click adventure, or a non-linear narrative like a roguelike it pays to think about the action-reaction cycle:
  • Think about character goals: Does the player have a clear idea of what they are supposed to be doing fro the start?
  • Think about conflict: Is the game too easy or too hard? This can make it boring.
  • Think about disaster: Does the player have something to lose, or can they just reload a recent save game? If you haven't explored the idea of permadeath, now's a good time to look it up. 
  • Think about Reaction: How does the game make the player think and feel? Do they react to it? Maybe you need to think about atmosphere. 
  • Think about dilemmas: Does the player have an meaningful decisions to make? Does what gear they use or what tactics they use make any difference to the game?
  • Think about decision: If they have decisions to make, are they too easy? Are there too few meaningful decisions?
I think that taking this approach could help you to better author your games so that they are compelling and interesting. A game which you can't put down.


Comments

Popular posts from this blog

Vinland 1936

What have I been up to this month?

Well you can see it in a couple of development blog videos, here, here and here.

Vinland 1936 is a game I've been working on (on and off) for about 3 years. It is somewhat based on the old Nirval interactive game, Blitzkrieg;





I hope you've played it since it is one of the best games ever!!! (IMHO)
Blitzkrieg was a real time tactics game. You didn't build a base, or spawn units. It wasn't about rushing the enemy. You got a small number of troops and vehicles that could be replenished or repaired if you had access to a supply base and the right supply trucks, but couldn't be replaced if lost. Once your vehicles were destroyed and your infantry killed you were finished. You couldn't just churn out some more from your factory and have another go at rushing the enemy guns. This made you invest a lot in each of your units. They really mattered.

It was also procedurally generated. Each mission (except for the historical missions) was…

Reboot / Remake / Restart

Although the roguelike project was going well I had a few issues with some parts of the code, and the sheer size of the project was something I could see stretching away in front of me for years with no guarantee that people would actually want to play it when it's finished.

It's time to try something a little less ambitious.
I'm going full rogueLITE!

Using a lot of the code from the roguelike project, I started making a more limited game.
There will be a single character, combat will be more arcade like, there will still be a chance to upgrade and develop your character's stats, but they represent only a single class and have fixed equipment.

I've got a fun character, an interesting setting and an exciting story lined up. It still utilizes my low poly style, but things are going to be a little more cartoony.

Game play involves mostly chucking bombs at the enemy.

But there's also a lot of platforming, jumping from multiple levels is part of the game. And you ca…

Materials.

I'm currently working on the inventory and items system.
I've got a good idea of how it's going to work, and I've made a few test demos in blender so I know how it should fit together, but one area I had some trouble with is how to make the items more interesting.

I don't want to have just sword +1, necklace of AC +5 etc... I want items to feel like they are unique. So I'll be designing a few base item types and then having them generate some qualities.



The first quality is status. An old broadsword, or a rusty helm. Or spoiled meat. These will be limited by item type, so you don't end up with rusty meat or rancid chain-mail. They add a modifier to elements of the item's stats, either a positive or a negative modifier.

The second quality is wear and tear. This is more dynamic since it can change, as you take or deal damage. This might not be seen in the item's name, but rather in a status bar or something. However, it could cause the item to lose so…