3
\$\begingroup\$

I've been fascinated by this talk ever since I watched it: GDC Vault Jon Ingold (Inkle) - Narrative Sorcery: Coherent Storytelling in an Open World

It proposes an implementation to simplify the complexity of quests in text-based games, but I bet there are some tools in there that can help any game with quests.

Here's the typical game's quest structure:

Meet someone, go somewhere, get something, go back, get reward

And here are some limitations of it:

Common complaints about game quests

Here's how this company modeled a quest system that actually has answers to those questions:

Wolf and peasant states

It's possible to progress along each of those linked lists independently:

Partial progress along these states

And the current state can indicate some very complex possibilities:

Peasant gets impatient, tries to kill wolf themselves, dies, is avenged

Anyway, it is not my intent to deconstruct this video back into its slides. Just know that everything above is a gross oversimplification. In fact, it may be difficult to answer my question unless you've watched it, but I hope not. Before I ask said question, allow me to present a concrete example:

You start a quest to kill imps in the forest and give the heads to someone who will pay you for them. You can...

  1. ...do the quest and get paid.
  2. ...wait and steal the heads from somebody else who did the quest.
  3. ...kill the man that will pay you and steal the reward.

So basically, a quest starts at one node and branches into three choices. In my mind, this proposed system seems more work than the traditional approach and I'm not seeing the benefits. This is how I would model it using state machines:

Imp Quest
o-> "Did the MC meet the man who pays for imp heads?" -> "Give imp heads to man."
o-> "Kill imps"
o-> "Steal heads from somebody else."
o-> "Kill the man and steal the reward."

I have o-> "Kill imps" on its own because you could kill imps, then steal more from somebody else. In fact, you could do that in the opposite order, therefore, o-> "Steal heads from somebody else." needs to be its own list, too?

Most of my quest ideas devolve into lists with a single node and that makes me feel like I'm doing it wrong. Because, at that point, it would be easier to use boolean variables with the traditional quest structure. I must be misunderstanding something from the talk, and I want to know what it is.

Am I modeling these lists incorrectly, am I using a bad example, or am I missing some context that makes this state machine system valuable?


Notes:

I inferred from the edit to the title that this might be a Ink language concept so I googled "Inkle State Machines". This resource that might be relevant and/or contain the answer: https://github.com/inkle/ink/blob/master/Documentation/WritingWithInk.md I haven't had time to read it yet.

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

I believe you should think in terms of the state of the NPCs instead of a quest line. The player advances the state of the NPCs instead of advancing a quest.

I would argue that it is a good thing that these quests are becoming wide instead of deep (they are a list of interactions that can happen independently, instead of a sequence of interactions that must happen one after the other).

It means there can be multiple ways the players approaches, or even becomes aware of a "quest", instead of having a single designated quest giver. It also means that you can add alternative ways to do things without messing with existing NPCs. In other words these interactions are decoupled.

So, the fact that your idea of a quest is devolving into a list of interactions which would not be hard to model with bools is a good thing.

My take away would be the change of perspective over quest design, plus the idea of having an uniform representation over the state of the world (granted that it does not have to be the representation proposed in the talk).


With that in mind, you can have:

The Player:

o-> "No Imp heads" -> "Got Imp heads" -> "Got reward for imp heads"
o-> "Does not know about Imp heads reward" -> "Knows about imp heads reward".

The NPC who pays for the imp heads:

o-> "No reward given" -> "Reward given"

The other NPC who might get the reward:

o-> "No Imp head" -> "Got Imp heads" -> "Got reward for imp heads"

Oh, in fact that last one could be more interesting if we allow to steal the head without killing it:

o-> "No Imp head" -> "Got Imp heads" -> "Lost Imp heads"
o-> "No reward" -> "Got reward for imp heads"

Here it could lose the imp heads either because it got the reward, or because the player stole them preventing it from getting the reward.

In fact, this require to advance these values in lockstep. For example, getting the reward from the NPC means the player goes from "Got Imp heads" to "Got reward for imp heads" at the same time as the NPC goes from "No reward given" to "Reward given".

Depending on the current state there would be different dialog for the interaction with with NPC, and these interaction would update the states accordingly. For example the NPC that pays for the imp heads could say something different if you already had the head before it told you about the reward.

Note: I'm assuming all that can be killed already has a way to track that state, so I'm not including "Alive" -> "Dead" in any of these.

\$\endgroup\$
3
  • \$\begingroup\$ Thank you for the thorough answer, it's definitely clarified a lot. Here's one thing I'm still confused about. You say, "the fact that your idea of a quest is devolving into a list of interactions which would not be hard to model with bools is a good thing." In those scenarios, why should I bother using state machines? I'll take a stab at my own question. It's about maintainability: if I later realize I want to break that bool down into 2+ pieces, it's almost trivial. Is that the value of a 1 node state machine? \$\endgroup\$ Feb 3, 2023 at 22:48
  • 1
    \$\begingroup\$ @DanielKaplan That is the idea. Initially these interactive fiction solutions would handle dialogue trees. That quickly was co-opted to handle knowledge (if you got the interaction where you become aware of X, it means you know of X) and inventory (if you got the interaction where you get item Z, it means you got item Z). Going from bool to int plus some other modifications it can handle losing items, stacks of items, money, or positive and negative interactions with NPCs (a first approximation to how much the NPC likes the player for dating simulations). Of course it can do quests. \$\endgroup\$
    – Theraot
    Feb 3, 2023 at 22:58
  • 1
    \$\begingroup\$ @DanielKaplan The core idea is that instead of a bool that goes from false to true, it is an int counter. But then you can do arithmetic and comparisons over them (e.g. how many items you got minus how many items you lost). In this case the int is the index of the state you currently are. \$\endgroup\$
    – Theraot
    Feb 3, 2023 at 23:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .