Hast du eventuell Lust noch etwas mehr Zeit in die Entwicklung des Tools zu investieren? Wenn nicht, hast du mein vollstes Verständnis dafür. Außer mir wird es sehr wahrscheinlich ohnehin keiner verwenden.
Ich hatte primär an eine Version für AFdZ gedacht. Die verwendeten Tabellen sind die gleichen, haben aber einen anderen Aufbau. Die ChildMapping Tabelle funktioniert hervorragend bei linearen Dialogen. Sobald aber mehrere Antworten des Helden oder unterschiedliche Antworten des NPCs aufgrund von Proben ö.ä. möglich sind, ist das bisher nicht vorgesehen. Das Letztere ist wahrscheinlich nicht so einfach zu realisieren, ist aber auch nicht notwendig. Das kriege ich auch so hin.
Das mit AFdZ ist kein Problem. Dafür brauche ich den Aufbau der Tabellen. Bei den Entscheidungen innerhalb eines Dialogs habe ich an eine rekursive Vorgehensweise gedacht. Das ist wahrscheinlich möglich. Im Moment sind mir die Einzelheiten aber nicht klar, so dass ich das nicht fest zusagen kann.
_Locale
Der Aufbau der Tabelle _Locale ist genauso wie in Drakensang. Einen wichtigen und hilfreichen Unterschied gibt es dennoch: das Feld LocaId darf jetzt einen frei wählbaren Inhalt haben, der dann genauso in der Tabelle _Story_DialogTakes verwendet wird. Das umständliche Umwandeln von Identifikatoren in Blobs hat sich also erledigt. Bei mir fangen alle LocaId Einträge mit txt an, dann kommt der Dialogname abschließend eine fortlaufende Nummer, z.B. txt_soeldner_taverne_orks_01, txt_soeldner_taverne_orks_02 usw.
_Story_Dialogs
Hier hat sich der Aufbau etwas verändert. DAs Feld Dialogname fällt weg, dafür ist das Feld GenericDialogId hinzugekommen, belibt aber i. d. R. leer. Der Aufbau ist jetzt folgender: DialogGUID, DialogId, DialogSpeaker, DialogGroup, DialogAsConversation,GenericDialogId.
INSERT INTO "someTable" VALUES (X'D80CA70F3DE8B99582FCF5A9C065DD4E',"c_locr02_soeldner_taverne_id","locr02_soeldner_taverne01","","0","");
_Story_DialogTakes
Wie in Drakensang weicht auch hier die erste Zeile eines Dialogs von den eigentlichen Dialogzeilen ab. Bei dieser Tabelle sind neue Felder hinzugekommen, außerdem wurde bei einigen Feldern der Felddatentyp geändert.
TakeGUID: BLOB, eindeutig
DialogGUID: BLOB, DialogGUID aus _Story_Dialogs
DialogId: Text, DialogId aus _Story_Dialogs
TakeId: Text. eindeutige Bezeichnung für jeden Take (ich verwende die DialogId mit fortlaufender Nummer), bei der ersten Zeile StartState
TakeSpeaker: Text, üblicherweise ein NPC, für erste Zeile leerer String
TakeListener: Text, Hero oder der Name eines anderen NPCs, für erste Zeile leerer String
TakeType: Take (NPC) oder Response (Held), bei der ersten Zeile StartState
TakeEmote: Text, (leerer String)
TakeSound: Text, (leerer String)
ConditionRef: BLOB, X'00000000000000000000000000000000'
ConditionBlock: BLOB, X'00000000000000000000000000000000'
StatementRef: BLOB, X'00000000000000000000000000000000'
StatementBlock: BLOB, X'00000000000000000000000000000000'
TakeLocaId: Text, LocaId aus Tabelle _Locale, bei der ersten Zeile 00000000-0000-0000-0000-000000000000
TakeTimeStamp: 0
TakeShortTextLocaId: Text, irgendein Identifikator, das Feld wird ohnehin nicht benötigt, bei der ersten Zeile 00000000-0000-0000-0000-000000000000
_Story_DialogTakeChildMapping
Der Aufbau ist im Prinzip wie in Drakensang, ein Feld ist am Anfang dazugekommen, jede Zeile hat noch eine eindeutige Guid als BLOB.
(22.11.2016, 13:36)Rabenaas schrieb: So scheint es mir jetzt zu stimmen.
Ja, klappt wunderbar. Leider fehlt noch ein Eintrag in der ChildMapping. Nach "Ich möchte doch etwas kaufen" müsste eigentlich nochmal "Schau her" kommen. Bei Dialogen mit NPCs, die man mehrmals anspricht, müsste man eigentlich auch noch eine weitere Dialogzeile einbauen. Die Vorstellung findet ja sonst jedes Mal statt. Du siehst, selbst einr relativ einfacher Dialog kann schoch ziemlich komplex werden.
Noch eine kleine Anmerkung: es muss <FullName heißen, nicht <heroName>.
Und eine Frage: hat sich der Aufbau der xml Datei geändert? Wo und wie wird festgelegt, welche Zeile auf welche folgt?
Im Prinzip gilt der Aufbau aus #26. Die Reihenfolge ergibt sich aus der Abfolge von <a>, <b> und <auswahl>, wobei <auswahl> eine Verzweigung kodiert. Mit dem zweiten "Schau her." sieht das so aus:
Code:
<drasa_dialog>
<daten>
<inhalt id="einkauf_id" npc="loc01_bobo">Einladung</inhalt>
<redner kennzeichen="a" id="loc01_bobo">Bobo</redner>
<redner kennzeichen="b" id="">Held</redner>
</daten>
<texte>
<a>Hallo.</a>
<b>Hallo. Mein Name ist <heldenname/>.</b>
<a>Willst du etwas kaufen, <heldenname/>?</a>
<auswahl>
<texte>
<b>Ja.</b>
<a>Schau her.</a>
</texte>
<texte>
<b>Nein.</b>
<a>Dann bis später.</a>
<auswahl>
<texte>
<b>Ich möchte doch etwas kaufen.</b>
<a>Schau her.</a>
</texte>
<texte>
<b>Bis später.</b>
</texte>
</auswahl>
</texte>
</auswahl>
</texte>
</drasa_dialog>
Nach dem <daten>-Teil kommt ein <texte>-Element, das eine Folge von <a>- und <b>-Elementen und zum Abschluss ggf. ein <auswahl>-Element enthält. Ein <auswahl>-Element enthält wieder ein oder mehrere <texte>-Elemente.
Wie das mit der geänderten Begrüßung aussehen könnte, ist mir gerade nicht klar. Vielleicht eine <auswahl> als erstes Kindelement vom ersten <texte>? Das ist im Moment noch nicht vorgesehen.
Wir müssen uns entscheiden, ob der Antworten-Baum zyklisch oder nichtzyklisch sein soll. Letzteres ist einfacher umzusetzen. Man könnte ggf. ein weiteres Element <alternativen> für Zyklen einführen.
Mit der geänderten Begrüßung meinte ich folgendes: beim ersten Ansprechen stellen NPC und held sich gegenseitig mit Namen vor. Bei einem zweiten Besuch beim Händler ist das natürlich nicht notwendig, deshalb würde da etwas wie "Da seid Ihr ja wieder. Wollt Ihr einen Blick auf meine Waren werfen?" nehmen. Wäre dann im Dialog auch eine Auswahl zwischen "Hallo" und "Da seid Ihr ja wieder". Welche dann tatsächlich aktiviert wird, wäre dann von einer Condition abhängig, die ja im Moment in der DialogTakes noch nicht mit einem Wert geffüllt sind. Ist aber auch in diesem Moment absolut nicht notwendig.
So wie es im Moment aufgebaut ist, muss man also für Schau her zwei Datensätze anlegen, da der Text auch zweimal vorkommt. In den Dialogen im Spiel gibt es aber keine doppelten Dialogzeilen, hier wird einfach wieder zurück verwiesen.
Nur in der ChildMapping gäbe es dann zwei Einträge, die auf verschiedene DialogTakes Einträge verweisen. Würde dann so aussehen.
Code:
INSERT INTO "_Story_DialogTakeChildMapping" VALUES (X'1d31c37b6780ba49b9c758d3f9d80d1d', "einkauf_030001", 0, X'46ec6ee07797914ea84efb23dc1bd791');
INSERT INTO "_Story_DialogTakeChildMapping" VALUES (X'2cea34df113c034abfa2b8e8f385a0e0', "einkauf_030001", 0, X'46ec6ee07797914ea84efb23dc1bd791');
Es wird also rekursiv vorgegangen, indem man einfach wieder zurückverweist und der daran hängende Dialogbaum erneut durchlaufen wird. Ein prima Beispiel dafür ist der Dialog mit dem Sitzenden in der Diebesgilde in Nadoret. Hier kann man den Dialog in einer Schleife immer wieder neu durchlaufen. Eine Abbruchbedingung zum Aussteigen ist natürlich auch implementiert.
23.11.2016, 12:17 (Dieser Beitrag wurde zuletzt bearbeitet: 23.11.2016, 12:22 von Rabenaas.)
Die Begrüßung wäre mit einem <auswahl> gleich zu Anfang erledigt. Dann muss beim derzeitigen Stand allerdings der gesamte Baum dupliziert werden. Einen entscheidenden Nachteil sehe ich bei gedoppelten Locales nicht, verstehe aber die Entscheidung von RL, das nicht zu wollen.
Man könnte <a>, <b> und <auswahl> bei Bedarf Marken als Attribute geben, die sich dann mit einem goto explizit anspringen lassen. Man verabschiedet sich damit aber von der Baumstruktur, die hat den großen Vorteil Einfachheit hat. Aber Endlosschleifen gibt es halt nicht umsonst.
23.11.2016, 12:40 (Dieser Beitrag wurde zuletzt bearbeitet: 23.11.2016, 12:40 von Lord Demon.)
Bei unserem Beispiel wäre eine doppele Zeile in der _Locale sicher zu verschmerzen. Allerdings würde es auch eine doppelte Zeile in der DialogTakes bedeuten. Bei manchen Dialogen wäre es aber eine ganze Reihe von doppelten Einträgen, da eben manchmal auch ein ganzer Dialogzweig von einer Zeile ausgeht. Und das würde den Dialog unnötig aufblähen.
Muss aber nicht sein. Ich wäre schon mit der Version (für AFdZ) zufrieden, die mir die Arbeit für lineare Dialoge abnimmt. Also so, wie es in Version 0.1.4 war. Letztendlich hält sich die Tipparbeit in Grenzen, da man viel mit Copy & Paste machen kann. Außerdem habe ich mir in Notepad+ einige Makros angelgt, mit denen der SQL Code dann erzeugt wird.
23.11.2016, 13:33 (Dieser Beitrag wurde zuletzt bearbeitet: 23.11.2016, 13:48 von Rabenaas.)
Mit den Sprungmarken ließe sich viel Redundanz einsparen bei vertretbarem Aufwand. Lass mich mal schauen.
Ich würde immer die letzte Version nehmen, da ich nebenher auch noch Bugs fixe. Eine Ausgabe für AFdZ bekommst Du, wenn Du -afdz vor die XML-Datei schreibst.
EDIT: Also z.B.
Code:
<auswahl>
<texte>
<a>Seid gegrüßt.</a>
<b>Hallo.</b>
<a marke="kauf">Wollt ihr etwas kaufen?</a>
<b>Na klar.</b>
</texte>
<texte>
<a>Hallo mal wieder.</a>
<b goto="kauf">Moin</b>
</texte>
</auswahl>
Du musst natürlich die Condition von Hand eintragen. Kommt die bei StartState hin, oder bei den Takes von "Seid gegrüßt." und "Hallo mal wieder."?
Die Conditions kommen immer in die jeweilige Dialogzeile, in dem Fal also in "Hallo". Die trage ich ohnehin meistens erst nachträglich ein. Außerdem ändern die sich auch schon mal nachträglich. Müssen also, genauso wie die Statements, bei der Dialogerstellung nicht berücksichtigt werden.
In der DialogTakes werden einige Felder falsch ausgefüllt. In der ersten zeile steht im Feld TakeLocaId StartState, hier muss 00000000-0000-0000-0000-000000000000 stehen. Das letzte Feld wird mit einem Blob ausgefüllt, hier muss ein beliebiger Identifikator (229e71a2-74b5-7b94-d83c-be5911f32158) stehen. Wenn der Held spricht, wird der Wert Player verwendet, bei Listener muss es allerdings Hero heißen. Ansonsten wäre es noch schön, wenn die Texteinträge in der _Locale am Ende keinen Identifikator bekommen, sonder nur eine fortlaufende Nummer. Das macht es für mich einfacher, den Text zu einem DialogTake Eintrag zu finden, wenn es später darum geht, die entsprechenden Statements und Conditions einzufügen.
(24.11.2016, 08:20)Lord Demon schrieb: Das macht es für mich einfacher, den Text zu einem DialogTake Eintrag zu finden, wenn es später darum geht, die entsprechenden Statements und Conditions einzufügen.
Man könnte über ein Attribut in der XML-Datei angeben, dass eine Condition verlinkt werden soll und für diese einen Dummy erzeugen, so dass nur noch der eigentliche ConditionContent eingetragen werden muss.
![[Bild: kaesetoast.png]](https://www.crystals-dsa-foren.de/images/smilies/kaesetoast.png)