Is there anything more tiresome than having something you already understand explained to you? In media, nobody likes characters who monologue their way through extensive flashbacks to events you watched a few episodes ago. “I already know this!” you silently scream. “Release me!”
But I’d say that when games do this it’s especially annoying, since the player’s role is as the master of pace. Players set the tempo in most games, by choosing difficulty in The Last of Us, choosing the song in Beat Saber, and choosing whether to blast through Fallout rabidly or take the time to wander every dusty road. So as soon as the game limits the player to the dialogue option “Who are you?” with a character they already know, it has failed. The player, trained to control, is suddenly confronted with an unskippable explanation of something they already know, and things can get heated. This is because the game has incorrectly anticipated the player’s knowledge, in this case by underestimating it.
The opposite can also happen. The game can overestimate the player’s knowledge and throw them some information they can’t yet understand. They might be told to “Deliver this letter to the Guildleve”, but if they haven’t yet been introduced to a ‘Guildleve’, they’re again frustrated: “What the hell is a Guildleve?!”. The player’s role as master of pace requires them to know how to move the game forward, and failing to give them enough information is just as bad as doling it out when unnecessary.
Games of all stripes, then, need to model the player’s knowledge. This means that the game’s designer needs to be aware of roughly what the player knows about controlling their character, the game world, and all sorts of other things. This lets us ensure balance is always maintained, that the player is neither infantilised nor befuddled.
Although this is a problem across most game design disciplines, it’s a particularly hard one for writers and narrative designers since our work usually encapsulates the most convoluted, nuanced knowledge found in a game: characters, worlds, histories, and plots. There are, broadly speaking, three ways of tackling this problem. Most games use a mix of these approaches for the multiple types of knowledge within, but tend to favour one core approach.
The simplest way for your game to correctly model what the player knows is for it to be linear. In a linear model game, the order in which game content occurs is predetermined, and no game content can be experienced without having completed, and therefore presumably understood, the previous piece of content. The classic example of this is the Campaign Mode of games such as Uncharted or Halo. In these games, there is only one possible order in which a new player can make their way through its various environments, cutscenes, and encounters. When the player ‘reunites’ with their companion character in act two, the writer knows the relationship was established in act one, and needs no reintroduction – if there was one, it’d be weird. It is the storyteller’s job to simply smooth the daisy chain of events until the player’s knowledge is always where the game needs it to be.
This isn’t always so easy, however. Sometimes, as in Divinity: Original Sin 2, the player can ignore the companion character in act one, leaving them on the beach without so much as a glance. Writing the ‘reunion’ scene in act two now becomes much harder. If I were to write a ‘one size fits all’ encounter, it would feel unspecific, likely a little cold for players who are best buds with the companion, and overwrought for those who’ve not paid them any mind. Bear in mind, there are many shades of familiarity between those points, too!
So instead, we model the player’s knowledge using state tracking. To do this we plant little flags in the computer’s memory whenever the player receives new information, such as meeting a character, learning a secret, or being given a quest. That way, we can make the game’s story divergent. The script for our reunion scene might begin with a simple check: has the player met this character? If not, play the ‘introduction’ version of the scene. If so, begin the standard version wherein the character explains that they have a child who’s been missing for years, and they disappeared to chase a rumour about them. We could perhaps have added another check to that second outcome: has the player already learned this character’s backstory? If so, modify the scene with a warmer greeting, and skip the ‘reveal’ about the missing child. State tracking allows us to always deliver the appropriate content to the player.
Some games solve this problem by putting the player fully in charge. In the above examples, there is an order to events; the player will complete act one, then move to act two, and so on. But this doesn’t have to be the case. Telling Lies, for example, simply presents all of its story as video snippets in a keyword-searchable database. Searching at random, the player is entirely likely to discover information they either already know or lack the context for. But in Telling Lies this isn’t the game’s fault, and isn’t frustrating, because responsibility for the delivery of information itself is shifted onto the player. If the player has entered a search term that’s led them to old information, that’s on them: they have to be more discerning. Alternately, if the player stumbles across something they lack context for, this is no longer a barrier to progress. In this model, information they don’t yet understand is an opportunity to move the game forwards, an avenue of inquiry for yet more searches.
So, next time you start noodling around with a game idea, ask yourself: how will I model the player’s knowledge? Deciding on an approach early can help avoid later setbacks, and trust me, you don’t want to watch your game completely fail to engage its first playtesters