@Leana: Falls es nur einen Dialog gibt hast du recht.
Aber es gibt auch Texte mit bis zu 4 Fragen, die man dem NPC stellen kann, und dann bräuchte man für jede Kombination von Dialog schon mal gelesen(1) | noch nicht gelesen(0) eine eigene Event-Seite.
0000
0001
0010
0011
0100
... und so weiter.
Damit kommt auf bis zu 16 Seiten und die muss man auch noch richtig verknüpfen mit Bedingungen etc.
Dann wird es schon recht kompliziert und unübersichtlich - besonders, wenn man nachträglich was ändern möchte.
...
Eddy, du denkst zu kompliziert
Normalerweise macht man diese Gelesen-/Nichtgelesen-Auswahl nur zu Beginn eines Dialoges und nicht bei "Unterdialogen". Aber selbst in diesem Fall lässt sich das Ganze leicht lösen (zumindest beim RM2k3):
Im Dialog-Event wird für jeden "Unterdialog" jeweils 1 Eventseite erstellt und diese Eventseite ruft man dann bei Bedarf auf. So muss man nur überprüfen, ob der Text schon gelesen wurde. Bei "Nein" -> zugehörige Eventseite aufrufen, bei "Ja" Abfrage und falls Antwort = Ja -> Eventseite aufrufen.
Eddy, du denkst zu kompliziert
Normalerweise macht man diese Gelesen-/Nichtgelesen-Auswahl nur zu Beginn eines Dialoges und nicht bei "Unterdialogen". Aber selbst in diesem Fall lässt sich das Ganze leicht lösen (zumindest beim RM2k3):
Im Dialog-Event wird für jeden "Unterdialog" jeweils 1 Eventseite erstellt und diese Eventseite ruft man dann bei Bedarf auf. So muss man nur überprüfen, ob der Text schon gelesen wurde. Bei "Nein" -> zugehörige Eventseite aufrufen, bei "Ja" Abfrage und falls Antwort = Ja -> Eventseite aufrufen.
...
Stimmt, so könnte es auch gehen!
Dann hat man nur die Abfrage und 2 Eventseiten für jede Dialogauswahl.
Das macht es etwas einfacher.
Vor allem da ich nie mit dem 2k/3 gearbeitet habe (bzw. wenn, dann ist das schon so lange her, das ich es schon wieder vergessen habe ^^ ) und nicht weiß wie das System da genau funktioniert.
Ich gehe wohl immer viel zu schnell davon aus, dass die Maker sich alle so ähnlich wie der VX und der MV verhalten, da der Unterschied zwischen denen von der Benutzung her auch kaum Unterschiede hat.
So wie ich mir das vorgestellt habe, funktioniert es leider nicht. \:
Jetzt wird nach jeder Textbox abgebrochen, egal welche Taste man drückt.
Das Label 101 ist jeweils immer am Ende eines Dialogs. Der Switch "text abbruch" wird mit einem Parallel Process auf on gestellt, sobald man Esc drückt.
Irgendwas übersehe ich da doch. Muss ich den Switch auf "toggle on/ off" stellen?
Wenn du den Switch nicht wieder ausstellst, ist die Bedingung natürlich immer wahr. D.h. du musst ihn wieder auf "off" stellen, nachdem der Text abgebrochen wurde.
Hm, wo genau im Code muss ich denn das "Control Switches turn off" setzen, damit es funktioniert?
Ich habe viel rumprobiert; irgendwie komme ich nicht drauf. \:
Wobei mir gerade auffällt, dass du noch einen Switch am Anfang des Dialogs brauchst, um den Parallel Process zu starten - sonst fragt der die Taste ja immer ab und aktiviert möglicherweise den Switch auch außerhalb einer Textbox.
Den Switch kannst du dann bereits im Parallel Process ausschalten, nachdem der andere eingeschaltet wurde.
Klingt jetzt vielleicht doof, aber: Wer die Dialoge unterhaltsam/interessant genug schreibt und inszeniert brauch auch keine Funktion zum Abkürzen. o_o"
Du gibst ja damit indirekt zu, dass deine Dialoge irrelevant und uninteressant sind.
Das gleiche auch bei überspringbaren Intros - hat so gut wie jedes Makerspiel und ich hinterfrage es jedes mal wieder.
Klingt jetzt vielleicht doof, aber: Wer die Dialoge unterhaltsam/interessant genug schreibt und inszeniert brauch auch keine Funktion zum Abkürzen. o_o"
Du gibst ja damit indirekt zu, dass deine Dialoge irrelevant und uninteressant sind.
Das gleiche auch bei überspringbaren Intros - hat so gut wie jedes Makerspiel und ich hinterfrage es jedes mal wieder.
...
Wer Dialoge in einem Spiel beim ersten Mal überspringt ist ja auch selber doof. Aber beim zweiten oder dritten Durchlauf/ bei mehrfach-Game Over finde ich die Möglichkeit Dialoge zu überspringen durchaus sinnvoll. Du kannst halt so interessante Dialoge schreiben wie du willst, aber wenn man gezwungen ist, sich das ganze öfter hintereinander reinzuziehen, oder alles mittlerweile auswendig kennt, hilft das halt auch nicht mehr .
Klingt jetzt vielleicht doof, aber: Wer die Dialoge unterhaltsam/interessant genug schreibt und inszeniert brauch auch keine Funktion zum Abkürzen. o_o"
Du gibst ja damit indirekt zu, dass deine Dialoge irrelevant und uninteressant sind.
Das gleiche auch bei überspringbaren Intros - hat so gut wie jedes Makerspiel und ich hinterfrage es jedes mal wieder.
...
Finde ich überhaupt nicht. Ich bin sehr glücklich und dankbar, dass zumindest Vorspulfunktionen in kommerziellen Spielen allmählich Standard werden. Nicht, weil ich die Texte so furchtbar finde, sondern, weil ich evtl. versehentlich den NPC nochmal angeklickt habe, weil ich nen alten Save geladen habe, weil ich im NG+ bin und einfach nicht alles mehrfach hören möchte.
Ich finde, man muss nicht explizit fragen "Möchtest du skippen?", da das durchaus suggeriert, dass die folgende Szene unwichtig ist. Aber die Möglichkeit, gerade längere Sachen beschleunigen zu können ist super. Und da der Maker ja leider von Haus aus sehr beschränkt in seinem Message-System ist, ist Skippen da leider die einzige Möglichkeit.
@G-Brothers: "Irrelevant" will ich nicht sagen, aber viele der Dialoge sind weniger für die Handlung relevant, sie sollen vielmehr zum Worldbuilding beitragen. Dass man selber entscheiden kann, ob man diese Dialoge nun wegklickt oder sie durchliest, finde ich eigentlich okay.
Hab's gerade mal im Maker getestet. Theoretisch funktioniert es soweit, aber aus irgendeinem Grund klappt es nicht, den Jump to Label-Befehl aus einem Call Event heraus auszuführen, wenn das Label sich im "übergeordneten" Event befindet - ergo: Abfragen direkt nach jeder Textbox.
Auch ist etwas irritierend, dass der Text erst abgebrochen wird, nachdem der Spieler die aktuelle Textbox bestätigt hat, aber das geht leider mit dem Standardsystem nicht anders (und aus eigener Erfahrung weiß ich, dass eigene Messagesysteme mit dem Maker eine Katastrophe sind, da man den Text entweder vorgefertigt als Pic anzeigen oder jeden Buchstaben einzeln dem Maker als Zahl füttern muss (womit Texte erst in Zahlenstränge "übersetzt" werden müssen...) Waren sie schon mit PicPointer-Patch, ohne darf ich's mir echt nicht vorstellen).
@BDraw: Also bei mir sieht das ganze jetzt so aus:
etc.
"text abbruch" ist ein Parallel Process mit dem switch "text abbruch2". In "text abbruch" wird bei Drücken von Escape der Switch "text abbruch" auf "off" gestellt. Ich kriege es hin, dass beim ersten Mal Dialog-Abspielen der Dialog mit Esc abzubrechen ist; beim zweiten Mal funktioniert es schon nicht mehr. Irgendwas ist da noch nicht richtig.
@Cepanks: Was soll ich sagen? Ich steh auf Knoten im Kopf. \:
Anstelle von Esc fände ich die Laufen-Tasten sogar noch besser. D. h. dass der Dialog aufhört, wenn man sich von der Person entfernt. Ist wahrscheinlich auch nicht ganz einfach zu programmieren...
Das CE ist ein PP, der auf Switch #2 reagiert. In dem PP wird eine Taste abgefragt und bei Druck wird Switch #1 eingeschaltet. Außerdem wird Switch #2 ausgestellt.
Das eigentliche Event schaltet erst Switch #1 ein, dann kommt der Text. Nach jeder Textbox wird abgefragt, ob Switch #1 an ist - wenn ja, wird zu einem Label gesprungen, das ganz am Ende platziert ist und dem nur noch folgt, dass Switch #1 ausgeschaltet wird.
Wenn dein Script beim ersten Mal klappt aber dann nicht mehr, hast du irgendwo einen Switch nicht wieder aus- bzw. eingeschaltet.
@StorMeye:
Wie gesagt, so nicht möglich. Die Textbox muss in jedem Fall zuerst vom Spieler weitergeklickt werden. Einfaches "rauslaufen", wie Pokémon das bspw. mit Schildern gemacht hat, geht nicht. Klar kann man jede beliebige Taste zum abbrechen nehmen, aber die Textbox muss erst zuende angezeigt werden. Das Script sorgt insofern genau genommen nicht für einen Abbruch der aktuellen Textbox, sondern verhindert nur das anzeigen weiterer Textboxen.
@StorMeye:
Wie gesagt, so nicht möglich. Die Textbox muss in jedem Fall zuerst vom Spieler weitergeklickt werden. Einfaches "rauslaufen", wie Pokémon das bspw. mit Schildern gemacht hat, geht nicht. Klar kann man jede beliebige Taste zum abbrechen nehmen, aber die Textbox muss erst zuende angezeigt werden. Das Script sorgt insofern genau genommen nicht für einen Abbruch der aktuellen Textbox, sondern verhindert nur das anzeigen weiterer Textboxen.
...
Aber könnte man durch einen Keypatch die Funktion der Enter-Taste nicht einfach auf die Richtungstasten kopieren?
Dadurch würde man die aktuelle Textbox beenden und weitere Abbrechen und danach würden die Tasten wieder zur normalen Belegung zurückkehren.
Falls man die Tasten im laufenden Spiel ändern kann, wäre das eine Möglichkeit.
Oder - aber das wäre ja dann wieder ein ganz anderer Fall - wenn man mit Bildern arbeitet, die die Textboxen ersetzen (also Bilder, die jeweils aus einer Textbox bestehen der Reihe nach anzeigen lassen).
Dann wäre das ganz einfach umsetzbar (neben dem Mehraufwand der Textbox-Bilder).
Aber könnte man durch einen Keypatch die Funktion der Enter-Taste nicht einfach auf die Richtungstasten kopieren?
Dadurch würde man die aktuelle Textbox beenden und weitere Abbrechen und danach würden die Tasten wieder zur normalen Belegung zurückkehren.
...
Hab den springenden Punkt mal Fett markiert. Du müsstest dann trotzdem erst eine Pfeiltaste drücken, loslassen, und dann nochmal drücken um dich zu bewegen.
Klar könnte man alle Texte im Vorfeld als Bild im Grafikprogramm erstellen und so das Maker-Messagesystem komplett umgehen, aber das bedeutet auch, dass man nichts mal eben ändern kann. Jeder Tippfehler würde heißen, eine völlig neue Grafik erstellen und importieren müssen - davon, dass das ein ziemliches Chaos im Pic-Ordner gäbe mal abgesehen.
Aber klar, damit könnte man was sehr schönes bauen was sich exakt so verhält, wie man will, inkl. Skip, Fast Forward, einstellbarer Textgeschwindigkeit, etc. Ist bloß die Frage, ob man sich den dauerhaften Mehraufwand wirklich antun will.
Bedenk allerdings, dass "einfach" hier auch sehr relativ ist: Wenn du bspw. möchtest, dass der Text nicht von Anfang an komplett erscheint, musst du schon wieder tricksen und mehrere Bilder verwenden; darüber hinaus wäre eine transparente Textbox damit nicht möglich. Um nur mal die Nachteile anzureißen, da gibt's noch einige mehr.
Unmöglich ist das mit ein paar Tricks alles nicht, explodiert aber sehr schnell entweder vom Aufwand oder von der Beeinträchtigung der Komfortabilität beim Makern Aufwand her.
Hab den springenden Punkt mal Fett markiert. Du müsstest dann trotzdem erst eine Pfeiltaste drücken, loslassen, und dann nochmal drücken um dich zu bewegen.
Klar könnte man alle Texte im Vorfeld als Bild im Grafikprogramm erstellen und so das Maker-Messagesystem komplett umgehen, aber das bedeutet auch, dass man nichts mal eben ändern kann. Jeder Tippfehler würde heißen, eine völlig neue Grafik erstellen und importieren müssen - davon, dass das ein ziemliches Chaos im Pic-Ordner gäbe mal abgesehen.
Aber klar, damit könnte man was sehr schönes bauen was sich exakt so verhält, wie man will, inkl. Skip, Fast Forward, einstellbarer Textgeschwindigkeit, etc. Ist bloß die Frage, ob man sich den dauerhaften Mehraufwand wirklich antun will.
Bedenk allerdings, dass "einfach" hier auch sehr relativ ist: Wenn du bspw. möchtest, dass der Text nicht von Anfang an komplett erscheint, musst du schon wieder tricksen und mehrere Bilder verwenden; darüber hinaus wäre eine transparente Textbox damit nicht möglich. Um nur mal die Nachteile anzureißen, da gibt's noch einige mehr.
Unmöglich ist das mit ein paar Tricks alles nicht, explodiert aber sehr schnell entweder vom Aufwand oder von der Beeinträchtigung der Komfortabilität beim Makern Aufwand her.
...
Da kenn ich micht nicht gut genug mit aus, wie der Patch funktioniert.
Könnte mir aber vorstellen, dass auch drückenlassen ausreichend ist: Man nimmt den Pfeiltasten ja nicht die Funktion die Figur zu bewegen, sondern fügt der Taste die Funktion hinzu, den Text abzubrechen.
Ob man dann weiterläuft oder man dennoch die Taste wieder drücken müsste, müsste man dann testen.
Und die alten Maker können Bilder nicht halbtransparent anzeigen lassen?
Und selbst wenn, hat man dennoch wesentlich mehr Möglichkeiten als die 2-3 (?) Standardeinstellungen des Makers.
Selbst beim MV ist man da ziemlich eingeschränkt :Rahmen + Wiederholendes Muster im Hintergrund. Dazu noch halbdurchsichter Schatten im Hintergrund oder komplett ohne, also nur mit Text.
Ansonsten immer eckig, immer die selbe Größe und nur an 3 festen Punkten erscheinbar.
Die alten Versionen werden da nicht besser sein (eher eingeschränkter)
Mit Bildern kann man sich da viel mehr austoben.
Und wenn man einmal die Routine drin hat, dann ist das nicht viel aufwendiger als mit den Hauseigenen Mitteln.
Bei History of Planet Bryyo wurde das zum Beispiel so gemacht, und es ist ziemlich gut geworden.
Was letztlich die beste Methode ist, bleibt denke ich Geschmackssache
Drückenlassen funktioniert nicht Sonst wäre es bspw. möglich, dass der Spieler Enter gedrückt hält und dadurch den NPC direkt nochmal anspricht. Der Tastenpatch würde da auch nicht helfen, da der die Tasten selbst nicht beeinflusst, er erlaubt es lediglich, über Switches und Variablen alle Tasten abzufragen. Mag natürlich sein, dass DynRPG da eher was reißen kann (sehr wahrscheinlich sogar), aber das hat dann ja nichts mit makern im herkömmlichen Sinne zu tun (was nicht heißen soll, dass das keine valide Lösung ist, sondern, dass das den Rahmen der Diskussion hier und das Wissen aller bisher beteiligten deutlich sprengt).
Was ich mit der Transparenz meinte: Wenn du möchtest, dass dein Text Buchstabe für Buchstabe erscheint, geht dies mit vorgefertigten Text-Bildern nur, indem du ein zweites Bild darüberlegst, was die Zeichen ersteinmal verdeckt. Dieses kannst du dann bewegen, um es aussehen zu lassen, als würden die Buchstaben nach und nach erscheinen. Da du hier aber mehrere Bilder übereinander legst fällt die Transparenz weg, da das nur funktioniert, wenn das verdeckende Bild auch wirklich komplett undurchsichtig ist.
Ein weiteres Problem bei der Methode sind Zeilenumbrüche: Wenn du nicht willst, dass unschöne Wartezeiten nach kürzeren Zeilen entstehen, musst du dem maker theoretisch für jede Zeile vorher sagen, wie breit sie ist. Da Zeichen bei der Schrifart des Makers immer die selbe Breite haben, musst du somit zwar nur die Zeichen zählen, aber es ist eben ein weiterer Punkt, der es verkompliziert, eine einfache Textbox anzuzeigen.
Zeichen zählen, für jeden einzelnen Text das Grafikprogramm öffnen, das ganze passend speichern, importieren, anzeigen, etc. sind für sich alles sehr kleine Aktionen, aber in der Summe ist das deutlich aufwendiger als im Maker einfach den Show Message-Befehl anzuklicken und gut ist, zumal das ja alles von vorne losgeht, wenn man später merkt, dass man sich vertippt hat oder einen Dialog ändern möchte. Dazu kommt, dass Sachen wie einzelne Variablen für Heldennamen, Items, etc. auslesen auch so ohne weiteres nicht mehr geht. Da hilft Routine auch nichts, der Workflow ist zu gut Deutsch beschissen.
Wenn ich mir überlege wie viel Arbeit so ein Spiel ist (und wie viele Projekte gecancelt werden), würde ich mir sehr gut überlegen, wie wichtig mir solche Features sind, die dem 0815-Spieler vermutlich ziemlich egal sind, einem selbst aber dauerhaft in den Füßen liegen werden.
Ab dem RMXP aufwärts (oder Rm2k3 mit DynRPG?) mag das anders aussehen, da man das da deutlich komfortabler einmal über RGSS regelt und gut ist, aber beim 2k/3 für sich lohnt sich ein eigenes Messagesystem imho einfach nicht. Außer man macht eine Visual Novel, und dann ist der Maker da eigentlich auch nicht für geeignet.
@BDraw: Ich habe deinen Code soweit umgesetzt; allerdings bricht der Dialog jetzt immer nach der ersten Textbox ab, egal welche Taste man drückt.
Das dazugehörige CE ist ein PP mit dem Switch "text abbruch 2". In ihm wird bei Druck auf Esc der Switch "text abbruch" auf on gestellt & danach "text abbruch 2" auf off.
Zitat von Eddy131
Zitieren
