[1] SPIKE: Discuss refactor of dialog/ encounters to support locations feeling like resolvable stories

[cailyn-codes]

• supporting branching
• multi-page dialog

[arie-rose]

Proposed Changes

Dialogue

• Rather than an enumerator of pages, Dialogue keeps a single reference to the current page
• Dialogue pages contain a list of up to 4 pages, corresponding with the button options, each representing a dialogue branch. They might all point to the same page (multi-choice, linear text-tree) or any combination of them can branch out. This should allow for a flexible dialogue tree of any size.
• Buttons will hold the "result" effects (currently supported), rather than being stored in the Encounter system
• Possibility to build graphically (in talks atm)

Encounters

• Containers for a single IDialogue object and a list of conditions for runnning them. The system will no longer responsible for building the IDialogue (current work moved over accordingly) or keeping anything already maintained by the Dialogue system
• Since all work is handed off to the Dialogue system, multi-page should be of no issue
• Add an OnEncounterResolved event for when it is done for good. This will allow for other encounters to chain with them (i.e. loaded, but not be interactable until previous is complete)

Proposed Design Workflow

Workflow

1) Build in an editor similar to MapEditor using a small scripting language for in-game commands and dialogue choice requirements 2) Export to CSV 3) Load at game-time and convert to C#

List of requirements

• %has {item_name} {item_count} | Item must exist in player inventory
• %encounter_complete {encounter_id} | Another encounter must have been finished prior to this one (allows chaining)
• %quest_complete {quest_id} | Quest must have been completed prior (leverages existing systems)

List of commands

(ignore the hyperlinking -- it is a product of markdown)

• \@give {item_name} {item_amount} | Give item to the player's inventory
• \@take {item_name} {item_amount} | Take item from the player's inventory
• \@resolve | Prevent the encounter from occuring again, otherwise it will

(totally willing to keep expanding these as needed)

[zzucco]

This all sounds good to me. We'll want a comprehensive list of commands. Currently, since our encounters are hardcoded, we can write lambda functions to do anything. Our CSV scripting language should be fairly powerful to match.

[arie-rose]

/// Generates an encounter with this structure
///
///     Encounter
///         |
///       Page 0
///       /    \
///   Page 1   Page 2
///       \    /
///       Page 3
///

{
 "encounters":  [
  {
   "encounter_id": 0,
   "conditions" : [
     "!encounter_complete 0"
   ],
   "town_name": "Smithsville",
   "dialogue_tree": [
    { 
      "id": 0,
      "text": "Welcome to these here parts",
      "avatar_name": "Sheriff",
      "buttons": [
        {
          "text": "Howdy, Sheriff.",
          "conditions": [],
          "effects": [],
          "next_page_id": 1
        },
        {
          "text": "Can we trade?",
          "conditions": [
            "!has food 20"
          ],
          "effects": [
            "@give scrap 30" 
          ],
          "next_page_id": 2
        }
      ]
    },
    { 
      "id": 1,
      "text": "You should check out the store later.",
      "buttons": [
        {
          "text": "Will do!",
          "conditions": [],
          "effects": [],
          "next_page_id": 3
        }
      ] 
    },
    { 
      "id": 2,
      "text": "That seems mighty fair to me!",
      "avatar_name": "Sheriff",
      "buttons": [
        {
          "text": "See ya later.",
          "conditions": [],
          "effects": [],
          "next_page_id": 3
        }
      ] 
    },
    { 
      "id": 3,
      "text": "Well it's been nice talking to you.",
      "buttons": []
    }
   ]
  }
 ]
}