Dynamic Story Point

[timgarrels]

The current data architecture of the story does not allow dynamic story changing. The user can choose paths, but the paths are the same for all players and do not have any possibility of preconditions.

Say we have a reply "Open the door" and we want this path only to be possible if the player picked up a key earlier (precondition). Thats not possible yet. Same thing with the key pickup: Say we have a reply "Pick up key", that we want to hide, once it's taken. Thats not possible either. Neither the storage of "has picked up key"-boolean nor the dynamic hide of the reply based on that bool.

We have the problem, that our current data structure for the story does draw paths between storypoints and supplies the points and paths with messages/replies, but we can not script anything between them.

We might need a structure that

• [ ] is human readable
• [ ] allows preconditions
• [ ] allows postconditions
• [ ] allows side-effects
• [ ] allows dynamic path decisions

I wrote a few text base adventures, where I scripted everything. All storyPoints where objects and the options where functions. But as @Paulpanther noted, that is 1. not human readable and 2. not shareable (the current json is)

Any ideas? @Paulpanther @ADimeo @robinwersich

[robinwersich]

I came up with the following structure, which I think is ok concerning readability and allows preconditions, side-effects and dynamic path decisions (I could not find a useful scenario for postconditions).

Story Structure

state representation

• current story node
• dictionary with story information like {"keyPickedUp": true, "cluesFound": 3}

story graph

• a normal story node includes the messages of the bot, possible user replies and an evaluation array:

  "ask-for-game": {
  "messages": [
    "Hello, I am a friendly bot.",
    "Do you want to play a game?"
  ],
  "reply-options": {
    "absolutely!": "yes",
    "I love games!": "yes",
    "not really": "no"
  },
  "evaluation": [
    {
      "reply": "yes",
      "condition": "userHappy",
      "next-node": "play-game"
    }, {
      "reply": "yes",
      "message": "I only play games with happy people.
                  Let me cheer you up",
      "next-node": "cheer-up-user"
    }, {
      "reply": "no",
      "side-effects": ["set_userLikesGames=false"],
    }, {
      "reply": "no",
      "condition": "!userHappy",
      "message": "thats ok. Maybe you want to,
                  after I've cheered you up a little",
      "next-node": "cheer-up-user"
    }, {
      "reply": "no",
      "message": "I can't believe it!",
      "next-node": "end-conversation"
    }, {
      "message": "This shouln't be reachable",
      "next-node": "end-conversation"
    }
  ]    
  }

• the evaluation works like a switch statement: if "reply" matches the users reply and the "condition" is satisfied (if non-existent, both evaluate to true), the "message" is sent, possible "side-effects" get activated (see below) and the story progresses to the "next-node" (following evaluation options are ignored). If there is no next node, messages and side-effects will be activated (this can be helpful sometimes), but the evaluation will continue with the next option. This way, it is not only possible to have dynamic path decisions and side-effects, but the branching mechanism also can be used to check preconditions.
• During the evaluation, side-effects can be triggered under certain conditions. Each side-effect is prefixed with its type:
  • set_ sets a dictionary entry, like set_userLikesGames=false
  • exec_ executes the given function (could be needed e.g. to send a photo)
  • increment_ could be helpful for things like tracking found clues
• It would also be possible to include a general "side-effects" field for the whole story node, e.g. to log that the user got a new clue (which is not dependent on the previous reply but on the fact the story node was reached)

[timgarrels]

@Paulpanther made the remark that we are basically replicating UML. Assuming he meant BPMN hes correct. We probably use BPMN to save our story structure, especially because we then can rely on existing, well tested tools to create, edit and visualize the story. And the process of loading and actually executing the story (data format to run time behavior) would be significantly less work

[timgarrels]

This was omitted as we realized how complex such a task would be.