Game Development Reference
Leave mysteries. Hint at things and leave the payoff till later. Clicking “next”
barely qualifies as interaction. You can do better.
Let the players make real choices. Don't be afraid to use things like branch-
ing narrative and user-created content. As a player, it's nice enough to unlock
puzzles leading to the next segment of an established narrative, but it's magical
to be involved in the shaping of the narrative. Let the players influence who
wins and how. Let them participate in the story as integrated characters and
not passive audience members. This includes letting them tattle on each other
and spy for the bad guys. Embrace that in your roller coaster ride and let their
actions have real consequences. Other chapters in this topic talk about dif-
ferent ways of planning for interaction in a narrative. Use these tools to plan
ahead and let the players have some power. It can be done without blowing
up the big-picture plan.
14.3 Evolving Narrative Over Time
One thing I've heard from every ARG developer I've talked to is a reference to the
military maxim that battle plans never survive the first encounter with the enemy.
Months and months of planning ahead of the launch of an ARG often fall apart
when players take routes through the game that were never anticipated. This can
have miserable results for both developers and players. However, there are strategies
that can mitigate the damage.
Build a big-picture plan. The only way to handle a narrative that evolves and
changes before it's finished is to have a big, overarching plan. Things won't go
well if you just do the initial setup for the story then wait to see what happens.
You'll find yourself needing to generate entire websites literally overnight, and
can you be sure you can do that in a believable, quality way? More than once?
If you have a general idea of where you're headed in the end, you can manage
individual battles in such a way that you still end up going somewhere fun. I
usually start my big-picture plan by laying out two plot points—the beginning
and the end(s). If I clearly write these out for myself and the rest of the team,
we'll all be less likely to get lost. Then I connect those dots with major plot
points or event nodes (more on that later) so the path from point A to point B
is clear to the dev team, although it should be mysterious to the players at the
beginning of the game. Your starting point needs to have several elements that
are painfully unresolved so there's somewhere for your plot to go. Players want
to feel this forward motion in the story. It helps them trust that the developers
will entertain them in some way. It can also help convince the people paying
for this game that they're getting their money's worth. For a sample of the way
I do my big-picture plans, see Appendix D for a high-level sketch of the plan
for an unproduced game called Starfall .