Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 20, 2018
arrowPress Releases
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Ideas and dynamic conversation in Heaven's Vault

by Jon Ingold on 08/22/18 09:37:00 am   Expert Blogs   Featured Blogs

1 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Heaven's Vault is an archaeolgical adventure game being made by inkle, the creators of 80 Days and the Sorcery! series.

Heaven's Vault is a narrative adventure game. But it's also highly dynamic - not merely branching, but self-assembling, both on its macro and micro levels. Locations unlock themselves in unpredictable orders (and for dynamic reasons); and within levels, the events that occur unlock themselves in a similarly dynamic way. 

Events in the narrative are connected up systemically

There's nothing random going on: the narrative engine's decisions are underpinned by a robust knowledge model, that tracks everything the player has done, seen, or theorised about the game-world. 

The knowledge model

The knowledge model we use is designed to be strong but efficient to author; so at any given moment in the script, the writer can quickly test if the game-state is appropriate for a line or action (or location!) to become available; with the test usually having two parts: 

1) Are all necessary conditions met for this action or dialogue line to make sense? 

2) Are any redundancy conditions met? Has anything happened that would invalidate the action? 

The first covers things like "unlock this door if you have the right key", but also "don't ask someone a question if you don't think they might know the answer". The second check covers things like "don't try to open a door that's already open", and "don't ask someone a question to which you already know the answer." All requirements are required; but a single redundancy is enough to fail. 

(These tests are, in many ways, the same! But we find it's useful to have both from an author's perspective because the two define the "space" in which an action can happen: when the player is between one set of discoveries and another. To put that another way, What does this action require? usually includes the triggers for an event or action; and What makes this action redundant? usually includes a list of the consequences of the action - the door is now unlocked, the fact in question is now learned, and so forth. )

For most of the game, this test is just right: if the player approaches a door, or an NPC, we can use it to figure out what options we should be providing.

But what do we do in cases where there is no context? 

Action in-between the action

As the player explores the world of Heaven's Vault, sometimes they're looking at these specific in-world props - and sometimes they're simply walking from one place to another. A core part of the storytelling happens in these moments, as the protagonist and her robot sidekick discuss ... well, whatever they like. Recent findings, backstory, their own relationship, the open mysteries of the game...

But how does the game decide which conversation options to offer when? In other words - we know what conversations options are valid... but which ones are relevant? 

For a long time, we've simply had a list of "game-wide" dialogue options which the characters run through in order. The first two that are valid, are surfaced, until they fall invalid and another one gets chosen. So the system might step through as follows:

  • Ask Six about the robot repair shop - we've never been there, so don't say this
  • Ask Six about the Fall of the Empire - we already know about this, so don't say this
  • Ask Six about flying the ship - we've not done this, so run with it! 
  • Ask Six about the Ancient script - we've not done this, but we've already got something...

The result is acceptable - the characters never talk about something that doesn't make sense. But the results aren't very realistic, because a prioritised list of conversation topics doesn't know anything about the context - and, in fact, there is always context, even if the player is simply walking along.

Because surely, if our characters are going to talk, they should be talking about whatever they're thinking about. But in a dynamic, highly self-assembled story, how do we know what are our characters are thinking about?

Knowledge states are ideas

The answer we've found - and quite late in the day! - is to re-use the existing knowledge model. Recall that every conversation line in the game is gated by what states it requires, and what states​ would make it redundant - that information is already there, and indexed in the game.

In order to tackle the problem of relevance, we've started to think of those "required" states not just as requirements, but also as ideas. We've begun recording not just which states have been set, but what was set recently. What was the last state to be set? That's what the protagonist is thinking about, right now. What were the last ten states to be set? That's what she's been mulling over in the background. 

Then, as we run through the prioritised​ dialogue list, we ask a slightly modified question: is this line valid, and were any of its trigger states set recently? If they were, then the topic is "closer to surface" of our character's mind, and should be pushed up to the player. 

In practice that means, in the list above, we still won't show choice 1 (which isn't available yet), or choice 2 (which is redundant), but the decision of whether to show choice 3 or choice 4 depends on whether we've recently learned something new about the ship - or whether we've learned something about the script of the Ancients. (And of course, if the system can't find anything relevant, we can still fall back to the previous model.)

We've been able to do this to all 10,000+ lines of dialogue overnight, because the information about required knowledge states was already attached to each line. (There are some false positives; sometimes a state has been required on a line of dialogue without being concretely relevant, but since we aren't surfacing these links to the player in any way, this manifests as slight randomness, and nothing worse.)

Other ways into conversation

It's also allowed us to trigger conversation in new ways: in Heaven's Vault, the player is an archaeologist, who records all her theories and discoveries on a timeline, covering everything from recent moment-to-moment events, to semi-mythological events that occurred millennia ago. Events on the timeline are, of course, tagged with the states in the knowledge model that unlock them.

A section of the interactive timeline interface

But we can re-use that tagged information to feed the relevance engine: so when a player looks up a piece of lore in the timeline, on returning to the game the characters may - without any further options or button presses - proceed to talk about it.

Heaven's Vault is almost complete, and we need to stop adding features! But in my opinion, we've only just begun to scratch the surface of what's possible with a robust knowledge behind a dynamically-assembled narrative, and there are lots of other spins on it and features we could try.

Perhaps a hint system that surfaces the protagonist's thoughts, based on recent, relevant knowledge states? Instancing the knowledge model for each character in a game, so NPCs can build up their own, alternative, model of the world and how it works? 


Related Jobs

Zapdot
Zapdot — Cambridge, Massachusetts, United States
[11.20.18]

Software Engineer
Zapdot
Zapdot — Cambridge, Massachusetts, United States
[11.20.18]

Senior Software Engineer
Monster Squad
Monster Squad — Seattle, Washington, United States
[11.20.18]

UE4 GAMEPLAY PROGRAMMER
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[11.20.18]

Sr. Hard Surface Artist





Loading Comments

loader image