Dialog - Bastelschublade/trinity GitHub Wiki

Diese Seite erwartet eine Überarbeitung!

Jedem NPC wird maximal ein Dialog zugeordnet, der zu Spielbeginn oder bei NPC spawn, aus einer JSON Datei geladen wird. Dieser Artikel beschreibt wie diese Datei aufgebaut wird:

Unterteilung in views

Der gesamte Inhalt der Datei ist ein dictionary und daher in { } gefasst. Jeder Eintrag (durch , getrennt) stellt einen text mit antwortmöglichkeiten da und wird im folgenden als view bezeichnet. Jeder view hat eine ID oder einen Schlüssel über den er gefunden wird und durch einen : getrennt die zugehörigen Inhalt. Der view mit dem Schlüssel "1" wird beim ersten Öffnen automatisch geladen.

Aufbau eines views

Der Inhalt eines views ist wiederum ein dictionary, das mindestens die Schlüssel "text" und "choices" enthält. Der Text ist das, was anschließend im oberen Teil des Dialogfensters angezeigt wird. Also was der NPC sagt. Die choices sind eine Liste (-> [ ]) aus möglichen Antworten. Die Antworten sind wiederum ein dictonary, die den text so wie mögliche damit verbundene Aktionen enthalten. Eine übliche Aktion ist zB. der Eintrag "view":"2", der beim Klick auf diese Antwort zum view mit der ID "2" springt, der natürlich existieren muss. Weitere Aktionen im nächsten Kapitel.

Mögliche Aktionen

  1. "view": "1" Der Schlüssel des views zu dem gesprungen wird.
  2. "review": "1" Der view, der Angezeigt wird, wenn der Dialog das nächste mal begonnen wird.
  3. "condition": {<cond>:<val>} Bedingungen die Erfüllt sein müssen damit diese Antwort möglich ist (nächstes Kapitel über mögliche Bedingungen).
  4. "show_disabled": false Ob Antwort dargestellt werden soll, wenn Bedingung nicht erfüllt ist (grau und nicht klickbar)
  5. "receive_item":{<item_id>:<amount>} Was der Spieler bekommt, wenn diese Antwort geklickt wird.
  6. "provide_item":{<item_id>:<amount>} Was dem Spieler genommen wird, wenn Antwort geklickt wird.
  7. "can_provide_item":{<item_id>:<amount>} Abk für provide_item gekoppelt mit condition -> has_item
  8. "receive_skill":{<skill_id>:<amount>} ...
  9. "reputation": 5 Ruf beim NPC erhöht zB um 5 (negativ zum verlieren)
  10. "exit": true Dialog wird geschlossen.
  11. "set_flag": "quest1324done"
  12. "remove_flag": "quest1324done"
  13. "set_kill_counter": {"name":<id/name>, "target": , "number": },
  14. "notify": <Notification Text> Text wird mittig oben für eine sekunde angezeigt.

Bedingungen

Die Bedingungen sind extra etwas komplexer und dafür nochmal als Unterkapitel beschrieben. Der Grund dafür ist die Möglichkeit mehrere Bedingungen mit einer beliebigen Logik verknüpfen zu können um so mit einfachen Mitteln dynamische und interaktive Dialoge erstellen zu können. Dies ist wichtig um Spiellogik in Dialoge zu verpacken, bespielsweise für Quests bzw. Questreihen. Die Bedingungen werden in einem Dictionary angegeben "condition": {c1:v1, c2:v2, c3:v3}. Dabei können Einzelbedingungen c aus der unten stehenden Liste gewählt werden. Bei mehr als einer Bedingung, müssen ALLE dieser Einzelbedingungen erfüllt sein, damit die "condition" als erfüllt gilt. Möchte man, dass nicht ALLE sondern nur mindestens eine (ODER) der Einzelbedingungen erfüllt ist, kann dies durch {"logic": "or"} (default ist "logic": "and"} erreicht werden. Ebenfalls besonders ist der Schlüssel {"condition": {...} }, der ein weitere Untergruppe von Bedingungen (Einzel-Einzel-Bedingungen) einleitet, die wiederum eine andere "logic" haben können. Durch die beliebig tiefe Verschachatelung können komplexe Bedingungen realisiert werden.

Der Ruf bei einer Person ist sowas wie der Progress bei sehr langen Charakteren, um nach und nach neuen Content und Quests frei zu schalten. (Vgl Rufsystem TODO: falsche seite)

  1. "rep_min": 22
  2. "rep_max": 12
  3. "has_item": {<item_id>:<amount>}
  4. "hp_min": 13
  5. "hp_max": 20
  6. "has_flag": "quest1324done"
  7. `"has_killed": <kill_counter_name/id>

TODO: custom data im NPC/Spieler speichern, die durch dialoge erstellt und durch trigger im spiel verändert werden können.. zB killcounter etc.. TODO: Flags können einfache boolsche bedingungen für spätere/andere dialoge zwischenspeichern, aber keine strukturierten daten. Außerdem sind diese nicht mit dem Spiel (nur mit anderen dialogen) verknüpft.

⚠️ **GitHub.com Fallback** ⚠️