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

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.



The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.


I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.


You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...


..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.


Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …

Skynet

Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.


The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …