Player agency in an open world, versus combinatorial explosion

An open world game needs to allow players to change the world. Destroy a bridge. Kill the king. Forge an alliance. World-changing actions can come in many varieties, but it’s helpful to talk about quests. Quests tie these actions into meaningful packages — with motivations, characters and stories. Without those elements, the open world can feel like a literal sandbox, where nothing really matters.

  • Some of these consequences can be incremental, like “the village’s wealth increases by 20 coins” or “the wizard’s reputation decreases by 6 points”. But there must also be major consequences like “the forest bridge no longer exists”, “the dwarves are now allies”, or “the player knows about the secret passage”. In spades.
  • This is especially important for a non-visual medium like Egamebook. Text generally needs broader strokes — the player’s new sword can’t be slightly nicer than the current broadsword, it must be Orcthorn, the bane of the ancient Orc king. The village can’t have a few more people on the streets — it must be suddenly bustling with life. A new combat move can’t just make +3 more points of damage. It must be chopping enemies’ arms.
  • These consequences combine. Outcomes of previous quests influence the next quest (among other things). Combining incremental consequences can be easy (20 coins + 10 coins => 30 coins), combining major consequences is most definitely not.
  • This is a major source of pain in development. And a major source of bugs.
  • As the number of quests increases linearly (e.g. 1 quest a week), the number of combinations of their consequences increases exponentially (e.g. 3 consequence combinations first week, 9 next, 27 after that). That is called a combinatorial explosion.
  • This can grind a project to a halt when the number of combinations explodes. Suddenly, no one wants to touch anything in fear that they’ll miss some important implication.

An example

To give you a concrete example, let’s say the player has done all these things in the past quests:

  • Burned a bridge in their territory, which stopped an undead army from attacking the elves, but made that army turn around and lay siege to the dwarven fortress for months.
  • Killed a famous dwarven hero in a duel.
  • Maneuvered a large and dangerous beast away from a city and to the vicinity of a ford near the dwarves.
Illustration by Adolf Ehrhardt, 1852.
  • How do they feel about the player at this point? Is the alliance with player’s kingdom more important to them than the fact that they had to endure months of siege? How much do they blame the player for that?
  • If they say yes, how do they march? Will they try to swim in the river? Go a long way around? Try the ford, knowing that there is a monster there? Do they know? Should the player automatically tell them? Should they have a choice to tell them?
  • If they don’t say yes, which of the reasons not to go should they mention, if any? Can they be persuaded to reconsider (e.g. by killing the monster at the ford, or by giving a legendary weapon to adorn the grave of their fallen hero, or by simply giving them gold)?

Rules

  1. Put logic in the consequence, not the predicate.
  2. Limit effects spacially and temporally.
  3. If there are more effects of the same kind, pick the strongest one and ignore the rest.
  4. One type of effect per scene.
  5. Quests should be explicitly about one effect.
  6. Build a framework for the most usual effects.
  7. Hold quests until they’re fun.

1) Put logic in the consequence, not the predicate

This is an implementation detail, but widely applicable, so I’m putting it first. You can safely skip this if you’re not in the business of programming games, and you’re here for the game design solution.

  • Player conspires with the butler.
  • Later that week, player sneaks into the aristocrat’s house through a window that the butler intentionally left open, and murders the aristocrat.
Illustration by J. S. Dodd, 1858.
  1. When the fatal night comes and we need to see whether the butler has opened the window, just query the history.
  • You have all the logic about a consequence in one place — right next to it. You don’t need to go hunting for all the different if-else statements in other parts of your code.

2) Limit effects spacially and temporally

This one is easy. Avoid having things that affect huge areas of the world, forever. You probably will have some of those, but in general, be conservative.

3) If there are more effects of the same kind, pick the strongest one and ignore the rest

This one might be controversial, especially for the more simulation-minded people like me — but I think it’s worth following nevertheless.

  • Pay some brigands to fake an attack at the stronghold, creating a diversion.
Illustration by Mary Hallock Foote, 1877.
  1. Combine manually. Prepare for the eventuality that the guards are both drunk and under faked attack. Create new writing for that. “Hey, Capt’n. Capt’n. Wake up. There’s’n assault. Hic! On the south wall.” Make sure the player has extra easy time sneaking into the stronghold in this scenario.

    This is less work than the simulation above, but not by much. You’ll have to write special code for basically all the possible combinations of effects. Again: combinatorial explosion.

4) One type of effect per scene

First off, some definition. A scene in a game like Egamebook is a single step of the quest. It’s usually bound to a single place. For example, the quest of retrieving a magic sword from a wizard’s tower can have the following scenes:

  • Combat with two of the wizard’s minions on a patrol.
  • Entering the tower in disguise as a minion.
  • Finding the right room with the artefact.
  • Breaking into the chest containing the sword.
  • Combat with minions on the staircase.
  • Stealing a horse.
  • Chase through the wasteland.
Illustration by Albert Robida, 1891.
  • whether it will be possible to persuade the minions not to fight (the minions are more loyal to the former lieutenant than to the wizard)
  • how easy it will be to find the room (the former lieutenant draws a plan for the player)
  • how easy it will be to open the chest (the former lieutenant gives the player the key)

5) Player actions should be explicitly about one effect

This is a companion to the previous rule. When you give the player a chance to influence the future, make it explicit that the influence will be limited to one effect.

6) Build a framework for the most usual types of effects

Even when you’ve diligently used all the rules above, you will start seeing effects that are very similar across quests, and that don’t feel repetitive despite heavy use.

  • magic powers (e.g. necromancy allows raising and commanding any dead body)
  • deterrence (e.g. a terrifying look will make enemies run from the battle earlier, and will make forceful interrogation more effective)
  • surprise (e.g. an ambush will have profound effects on the first few moments of combat)
  • anatomy (e.g. chopping off an arm will prevent its owner from using it)

7) Hold quests until they’re fun

This last rule doesn’t directly prevent combinatorial explosion but it’s somewhat related to the idea of previous actions influencing future quests.

Illustration by unknown artist, 1883.

Conclusion

I hope this was an interesting read. I’m glad it’s out of my system. If nothing else, this will be a great way to introduce newcomer writers to Egamebook.

Developer and manager working on Google’s Dart programming language and Flutter SDK; gamebooks enthusiast; https://filiph.net

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store