rendall
commented
3 years ago Thinking out loud about some of the concepts. I'm not sure this is exactly what you were going for @rendall?
Brainstorming at this stage, so, yes. Anything and everything is welcome. We're developing a vocabulary to talk about these concepts, and discussing ideas at a high level are a great way to do that, I think.
I'd be especially interested in examples that don't work well in this model? In the view presented below, quests are simply Objects like any other, they have no special status. In a dialogue-based game, you would also need another primitive, Dialogue, which represents the tree of possible player choices, which can be combined with pre/postconditions. However, Dialogues would still be dependent on the other primitives, and dialog choices, just like actions, change Facts.
Dialogues and conversations might often be considered a kind of branching narrative itself, especially the way that they are often used in games. They are similar in that they (potentially, depending on the model) have states (e.g. "start", "learns about the McGuffin", "becomes angry", "suggests a quest") and transitions ("What is the best way to town?", "Tell me in your own words only the good things that come to mind about your mother.") and terminal states ("Adios, Mama!", "Time to die!"). The particular exit from a conversation might be an essential element in another quest.
Facts - facts are statements about Objects, for example:
The ball is green The chest is locked The NPC wields a hammerActions - actions represent changes to Facts. They have pre- and postconditions, which are Facts, and which respectively specify when the action can be undertaken, and what happens on its completion. For example:
I like this idea as an expressive way to deal with the inevitable necessity of variables, and how transitions (or Actions) will necessarily change some variables.
Objectives - represent the goal of the game. Objectives are Facts. For example:
Dragon is slain Player has 10 diamonds The princess is rescuedThis can be formally analyzed. We start with the Objectives and figure out whether it is possible to arrive at them by analyzing the initial Facts and the pre- and postconditions of the Actions. The syntax for this formal language is more or less as written in the examples, so a game world can be represented in almost plain English. It is also a declarative language, we simply specify the facts about the world and how they change, not how this is implemented on a statement by statement level.
I wonder if the most challenging task now is to find one or more good solutions to enable writers to expressively create and visualize the structure of a branching narrative.
Today I began converting Zork into xstate - and I realized this is probably the wrong approach right now. I mean, at some point we probably will want Zork as a statechart, but creating it by hand is still basically programming. Getting into the nuts and bolts of which variable belongs in which FSM and how we can represent objects is where we are (well, at least, I for one am) most comfortable, and so I think we (or I, anyway) should carefully resist tweaking the engine under the hood before we design the look and feel.
Or maybe not! Maybe "zork as a statechart" is exactly the proof of concept necessary right now! Dunno. I'm open.
We maybe want to spend some time analyzing quests in games and getting at their overall structure and seeing how we can express them using structured data, that later could be transpiled to something more... wonky?
I'm thinking a writer might think something like:
*Sir Gawain will be challenged to hold fast to his values against overpowering temptation, and his measure as a man and a knight will be revealed at the end"
Then
He will face 3 trials, but which trial he faces depends on his success or failure at the previous trial
Then
First, he will be challenged to a dual to the death by The Green Knight. If he wins the dual, the story ends. If he loses, the Green Knight will spare his life only if promises upon his Word as a Knight to seek out the Green Knight, to be beheaded, in one year.
If Gawain keeps his promise, and ventures out to meet The Green Knight, he is hosted by the nearby Lord of the Manor as he awaits the arrival of the Green Knight. If however, Sir Gawain does not keep his promise, he loses troth, and the Green Knight returns and mortally wounds him.
While the Lord of the Manor is away hunting, the Lady of the Manor attempts to seduce Gawain. If he succumbs, he loses troth, and the Green Knight beheads him. If he angers the Lady, the Lord of the Manor throws him out, and the Green Knight beheads him.
etc....
Then within each state described above, it might go something like.
The Lady of the Manor enters the guest chambers of Sir Gawain. "Sir Gawain," she says. "I am so hot. Do you mind if I remove my sweater?"
1. "My Lady, let me dampen the fire for you and open the window."
2. "Yes, and come lay here beside me." Sir Gawain loses troth
3. "How dare you! You have a husband! Get out of here at once!" Lady of the Manor is angered
and
"Sir Gawain", says the Green Knight, "You have demonstrated Knightly Virtue by coming here to me, knowing that it meant your certain death. Come and kneel before me."
1. [Sir Gawain draws his sword and readies to defend himself] "Never!" he shouts. Gawain loses troth
2. [Kneels, as The Green Knight asks] Gawain meets 3rd challenge
If we could find a way besides actual natural language processing to get this information into structured data, the parts that you and I feel comfortable with should be able to follow.
Does that make sense?
toinbis
kiwih
Thinking out loud about some of the concepts. I'm not sure this is exactly what you were going for @rendall? I'd be especially interested in examples that don't work well in this model? In the view presented below, quests are simply Objects like any other, they have no special status. In a dialogue-based game, you would also need another primitive, Dialogue, which represents the tree of possible player choices, which can be combined with pre/postconditions. However, Dialogues would still be dependent on the other primitives, and dialog choices, just like actions, change Facts.
Theory
A game consists of (at least) the following things:
Objects - objects can represent the player, NPCs, monsters, keys, gems and other items that are in the game world, but also meta-objects like quests and achievements
Facts - facts are statements about Objects, for example:
Actions - actions represent changes to Facts. They have pre- and postconditions, which are Facts, and which respectively specify when the action can be undertaken, and what happens on its completion. For example:
Objectives - represent the goal of the game. Objectives are Facts. For example:
This can be formally analyzed. We start with the Objectives and figure out whether it is possible to arrive at them by analyzing the initial Facts and the pre- and postconditions of the Actions.
The syntax for this formal language is more or less as written in the examples, so a game world can be represented in almost plain English. It is also a declarative language, we simply specify the facts about the world and how they change, not how this is implemented on a statement by statement level.
If necessary, it is also possible to split a game into Scenes, which are distinct collections of Objects, Facts, Actions, and Objectives.
Example
Objects:
Small chest Large chest Small key Large key Diamond Quest
Facts:
Small chest contains Large key Small chest contains Diamond Large chest contains Small key Small chest is locked Large chest is locked Quest is not completed
Events (or Actions):
"Retrieve Diamond" { preconditions: player.has? Diamond, postcondition: quest.completed! }
"Unlock small chest" { preconditions: player.has? Small key, postconditions: small_chest.is! unlocked }
"Take Diamond from small chest" { preconditions: small_chest.is? unlocked, postconditions: player.has! Diamond -small_chest.contains! Diamond }
"Take Large key from small chest" { preconditions: small_chest.is? unlocked, postconditions: player.has! Large key -small_chest.contains! Large key }
"Unlock large chest" { preconditions: player.has? Large key, postconditions: large_chest.is! unlocked }
"Take Small key from large chest" { preconditions: large_chest.is? unlocked, postconditions: player.has! Small key -large_chest.contains! Small key }
Objectives:
quest.completed
NB: in an actual game, unlock and take would be more generic, and automatically attached to containers e.g.
"Unlock container" { preconditions: player.has? container.key postconditions: container.is! unlocked }
"Take object from container" { preconditions: container.is? unlocked postconditions: player.has! object -container.contains object }
"Retrieve the diamond" is then the only action that needs to be written for this particular quest.
To determine whether a quest can be completed, we start with the objective. If it is among the starting facts, it is complete. If it is not, we find the actions whose postconditions fulfill it, "Retrieve Diamond". We then find the actions whose postconditions fulfill these actions' preconditions, "Take Diamond from small chest", and so on. At some point, we will either arrive at an action whose preconditions are true (from the initial facts), in which case the quest can be completed, or we will not. In the latter case, we either loop indefinitely, like in this example, or we simply do not find the necessary postconditions in any action. Checking for errors is easily automated.