Gruescript ist einerseits noch in der Beta-Phase [...]

Bei den Systemen, die ich mir so vorstelle, denke ich selten an Gruescript. : )

Ich stelle mir eher ein modulares, weniger striktes System vor, bei dem weniger vorgegeben ist.

Gruescript hat ein mehr oder weniger vorgegebenes Modell ‒ das Scott-Adams-Modell mit einem zusätzlchen Konversations-Modus, also das Modell von Detectiveland. Man kann zwar einiges konfigurieren, aber im Grunde bleibt das Modell immer gleich.

Aber würde sich ein System zwischen Parser und Multiple Choice nicht anbieten für ein Spiel, das nur aus Konversation besteht, wie Weird City Interloper? Oder ein Spiel, das zwar eine Art Inventar hat, aber keine konkreten Aktionen zu den einzelnen Gegenständen anbietet, wie Bigger Than You Think?

Ich denke, solche Spiele würden sich gut mit einem Gruescript-artigen Ansatz vertragen. Jon Ingold meint, dass Choice-Spiele interessanter sind als Parser-Spiele, weil die Illusion, alles eingeben zu können, eben nur eine Illusion ist. Der Spieler weiß das und hält sich sowieso an die Grenzen, die der Autor vorgibt. Trotzdem sind komplexe Spiele was den Entwicklungsprozess angeht näher an Parser-Spielen als an reinen Abenteuerbüchern. (Andrew Plotkin schreibt eine Replik, stimmt letzten Endes aber weitestgehend zu.)

Es gäbe also vielleicht Bedarf an einem "allgemeineren" Gruescript. (Vielleicht wird dieser Bedar aber schon von Twine und Co. gedeckt, das weiß ich nicht.)

Um etwas mehr Erfahrung mit Gruescript zu bekommen, übertrage ich gerade das Passage-Fragment nach Gruescript. Mich würde interessieren, wie unsere Autoren das Entwickeln des Spiels mit dem GS-Editor im Browser fanden.

Man kommt schon einigermaßen schnell zurecht und das Syntax-Highlighting ist eine gute Unterstützung. Man ist auch relativ frei bei der Organisation des Quelltexts.

Mir ist aufgefallen, dass Fehler in den Ausführungsblöcken Laufzeitfehler sind. Wenn ich sage "verb examine grmblf", wird beim Kompilieren gemeckert, dass grmblf kein Objekt ist. Wenn ich aber sage "give grmblf" oder nur "grmblf", kommt der Fehler erst, wenn der Block ausgeführt wird.

Martin:

Bei den Systemen, die ich mir so vorstelle, denke ich selten an Gruescript. : )

Ach so, das hatte ich in dem Zusammenhang missverstanden, sorry. Ich dachte, dass die Idee sei, Modifikationen von Gruescript anzubieten, die das prinzipiell als zugrundeliegendes System benutzen, jeweils mit Abwandlungen im Layout und ggf. auch in Teilen der Funktionalität.

Aber die Vorteile (für Einsteiger und Fortgeschrittene) und der Vorschlag mit der Sammlung auf Github würden natürlich auch für ein allgemeineres System gelten.

[...] solche Spiele würden sich gut mit einem Gruescript-artigen Ansatz vertragen. Jon Ingold meint, dass Choice-Spiele interessanter sind als Parser-Spiele [...]

Es gäbe also vielleicht Bedarf an einem "allgemeineren" Gruescript. (Vielleicht wird dieser Bedar aber schon von Twine und Co. gedeckt, das weiß ich nicht.)

Ich mag im Allgemeinen Parser-Spiele lieber, durchaus auch wegen der Vielfalt nicht-vorgegebener Befehle und der Illusion der Freiheit, aber ich finde komplexe Choice-Spiele auch nicht uninteressant.

Im Prinzip kann man Twine beliebig durch JS erweitern, wobei das vorausgewählte Storyformat Harlowe das wohl bewusst etwas schwieriger macht, während es bei anderen Formaten (z.B. Sugarcube, Snowman) etwas leichter ist.

Insofern kann man eigentlich fast alles damit machen. Es gibt einige Twine-Spiele, die sich nicht auf ein paar Verzweigungen einer Geschichte beschränken, sondern die eine (ggf. einfache) Form von internem Weltmodell haben und ein Inventar bieten, und die verschiedene Orte präsentieren, zwischen denen man sich relativ frei bewegen kann.

Das sind z.B. 4x4 Archipelago, The Bones of Rosalinda, Hallowmoor, 16 Ways to Kill a Vampire at McDonalds, A Long Way to the Nearest Star.

Wenn man also in Richtung eines "Point-and-Click Text-Adventures" gehen will, könnte es sich bestimmt lohnen, mit Twine zu experimentieren.

Alternativ könnte man sozusagen umgekehrt vorgehen, indem man Inform mit Vorple benutzt, also "unter der Haube" ein Inform-Spiel laufen hat und eine passende vereinfachte UI mit HTML/CSS/JS + Vorple realisiert.

Ich mag im Allgemeinen Parser-Spiele lieber.

Ich eigentlich auch, aber wahrscheinlich ist es wieder eine Frage des richtigen Interfaces für das jeweilige Spiel. Mein Ideal ist, glaube ich, ein Parser ohne Menüs. Dass "talk to" mit Dialogmenü mittlerweile Standard ist, gefällt mir nicht, weil mir diese (von Grafikadventures übernommene) Art der Konversation nicht gefällt. Und statt eines unfangreichen Hilfemenüs reichen ein paar Meta-Anweisungen wie INFO oder DANKE.

Im Prinzip kann man Twine beliebig durch JS erweitern, wobei das vorausgewählte Storyformat Harlowe das wohl bewusst etwas schwieriger macht, während es bei anderen Formaten (z.B. Sugarcube, Snowman) etwas leichter ist.

Mit Twine habe ich mich noch nicht beschäftigt, das ist ein blinder Fleck auf meiner IF-Karte. Erst vor ein paar Tagen habe ich gesehen, dass man bei Twine verschiedene Storyformate zur Verfügung hat.

Aber, ehrlich gesagt, Javascript durch den Hintereingang in in bestehendes Gerüst einzubauen, schränkt doch auch wieder ein. Da würde ich lieber etwas ganz Neues machen.

Ein Multiple-Choice-System in Javascript zu schreiben, ist jetzt nicht besonders schwer. Die Grundlage für meine Version 1 der Passage hatte ich bestimmt an einem Abend geschrieben, als ich Michaels Beagle Rock getestet hatte und mein erster Gedanke war: "Uh, das ist hässlich, das geht doch bestimmt besser."

Ich weiß, Twine bietet noch mehr: Dass man zu bestimmten Auswahlen zurück gehen kann und natürlich muss der Zustand gespeichert werden, wenn man die Seite verlässt. Das kann die Passage nicht und dort liegen wohl auch noch einige Stolpersteine.

Das sind z.B. 4x4 Archipelago, ...

Vielen Dank! Es gibt ja mittlerweile so viel, dass es schwierig ist, das wenige Gute zu finden, deshalb bin ich für soclhe Empfehungen dankbar.

(Auf den ersten Blick sieht der Archipel interessant aus, die Vampire bei McDonalds weniger. Vielleicht habe ich mich bislang noch nicht mit Twine beschäftigt, weil mir viele Spiele nicht gefallen: Diese langen Texte immer. Und diese Fixierung auf verzögernde Texteffekte. Und überhaupt, die jungen Leute ...)

Alternativ könnte man sozusagen umgekehrt vorgehen, indem man Inform mit Vorple benutzt.

Die Möglichkeiten von Vorple sind interessant, aber wie oben bei Twine + Javascript glaube ich, dass Vorple der falsche Ansatz ist.

Ich bin mittlerweile der Auffassung, dass es sich auch bei Parser-Spielen lohnen würde, von den Storyfiles weg und direkt zu HTML zu gehen. Parchment, Quixe und Co. waren der richtige Schritt, um bestehende Spiele in den Browser zu bringen. Seitdem hat sich aber vieles verändert: Es wird mehr im Browser gespielt. Javascript, CSS und HTML sind durch die "immergünen" Browser viel zuverlässiger geworden und haben auch viele neue Optionen dazubekommen. Und Spiele werden in der Regel immer kürzer, was vielleicht den vielen Comps und Jams geschuldet ist.

Die Z-Maschine und Glulx haben einige Einschränkungen, die man sich mit Javascript sparen könnte: Wörterbucheinträge müssten nicht mehr abgeschnitten werden. Überhaupt könte man das Wörterbuch einmal ordentlich organisieren. Manipulation von Text muss nicht mehr über den Umweg eines Textpuffers mit fester Größe passieren. Unicode ist einfach da. Und alles das, was Vorple mitbringt, auch.

(So ganz will ich die Storyfiles aber nicht abschreiben. Längere Spiele oder Spiele, bei denen ich Transkripte anlege, wie für Betatests oder Comp-Beiträge, habe ich gerne auf meiner Festplatte. Trotzdem postuliere ich hier mal frech HTML als die Zukunft. Und Inform durch Javascript aufzuhübschen ist ein wenig so, als ob man einen Screenshot faxt, dann einscannt und dann als hochauflösende Grafik darstellt.)

Die Frage bleibt aber natürlich: Wie schafft man es, dass Leute, die am kreativen Prozess des Spieleschreibens interessiert sind, die sich aber nicht in die kleinteiligen Niederungen von Javascript, CSS und HTML begeben wollen, Spiele schreiben?

Jon Ingold meint, dass Choice-Spiele interessanter sind als Parser-Spiele, weil die Illusion, alles eingeben zu können, eben nur eine Illusion ist.

Boah, solche Artikel nerven! Jetzt mal völlig zur Seite geschoben, dass Herr Ingold ja auch ein kommerzielles Interesse hat und zur Verfassenszeit hatte für seine Meinung: Die Prämisse ist doch schon grundlegend falsch. Und auf Basis einer falschen Prämisse kann man bekanntermaßen Beliebiges entwickeln und belegen.

Diese "Illusion" gab es nie, gibt es nicht und wird es auch nie geben. Nein, der Parser ist kein "falsches Versprechen" (Emily Short) oder was auch immer. Er ist in Spiele eingeführt worden als direkte Übertragung der damals einzig möglichen Eingabemethode für Computer. Als Computerbenutzer noch verstanden, dass – ja – ein Eingabeprompt natürlich mit einer festen Syntax arbeitet. Was auch sonst?

Und was ist er heute? Immer noch die flexibelste, bei Weitem effizienteste Eingabemethode für Computerinteraktionen aller Art. Hat sich also nichts geändert.

Hannes: Boah, solche Artikel nerven!

Na, Puls wieder normal?

Dass die Eigaben eine bestimmte Form haben müssen und dass selbst in dieser Form nicht alle Eingaben verstanden werden, wird wohl jedem Spieler klar sein.

Der gesamte Umfang der möglichen Verben ist dem Spieler aber nicht unbedingt bekannt. Manchmal kommen explizit neue Verben hinzu: der Roboter im Sektor 471 bekommt ein neues Modul oder der Enchanter findet einen Zauberspruch. Manchmal möchte der Autor auch, dass der Spieler diese Verben selber findet. Wenn das nicht gut gemacht wird, kommt es zum guess the verb – die Schlüsselszene in Die rote Blume funktioniert halt oder sie funktioniert nicht.

Wenn dem Spieler die gängigen Verben mit einem Beispiel-Transkript oder einfach in einer Liste gezeigt werden, endet das oft mit dem Hinweis: Das sind aber nicht alle Verben!

"Illusion, alles eingeben zu können" oder "Mythos der Freiheit", wie es Ingold in seinem Artikel sagt, ist übertrieben, aber der Hinweis, dass es noch mehr gibt, ist schon da. (Natürlich nicht bei allen Spielen.)

Und was ist er heute? Immer noch die flexibelste, bei Weitem effizienteste Eingabemethode für Computerinteraktionen aller Art.

Na ja. Da wolltest Du jetzt selbst mal eine Quatschbehauptung raushauen, oder?

Wenn man die Syntax kennt, kann man mit der Texteingabe effizient sein. Die meisten Benutzer kennen die Syntax aber nicht und wollen sie auch nicht lernen. Ich weiß nicht, was Du hier genau mit "flexibel" meinst, aber die Syntax ist ja vorgegeben und falsche Eingaben müssen durch geeignete Fehlermeldungen angezeigt werden. Und für "Computerinteraktionen aller Art"? Ich stelle mir gerade einen Parser für MS Paint vor ...

Hat sich also nichts geändert.

Ich glaube, seit den Siebzigern hat sich schon einiges geändert. Wo ist eigentlich der Lochkartenleser beim Smartphone? ; )

Wenn man die Syntax kennt, kann man mit der Texteingabe effizient sein. Die meisten Benutzer kennen die Syntax aber nicht und wollen sie auch nicht lernen.

Von Zugänglichkeit habe ich ja nicht gesprochen, sondern von Effizienz.

Ich weiß nicht, was Du hier genau mit "flexibel" meinst, aber die Syntax ist ja vorgegeben und falsche Eingaben müssen durch geeignete Fehlermeldungen angezeigt werden.

Da denke ich an die Erweiterbarkeit. Bau' mal ein neues Feature in einer Point & Click-Oberfläche ein. Einen neuen Workflow für was-weiß-ich-was. Da bist du schnell bei mehrlagigen Untermenüs, bedingten Abfragedialogen usw.

Und für "Computerinteraktionen aller Art"? Ich stelle mir gerade einen Parser für MS Paint vor ...

Ja, mit Imagemagick verarbeite ich beliebige Mengen von Bildern innerhalb kürzester Zeit, wofür ich mit jeglichen Klickoberflächen Stunden bräuchte. Zuschneiden, Größe Ändern, Filter drüberlegen, Metadaten ändern, kompromieren, kovertieren... Gutes Beispiel, vielen Dank!

Ich glaube, seit den Siebzigern hat sich schon einiges geändert.

Daran, dass es die effizienteste Eingabemethode für Computerbedienung ist, hat sich nichts geändert. Gut, ich gestehe ein: Sofern man mehr machen möchte, als von oben nach unten zu scrollen oder passiv Videos anzustarren, was zugegeben heutzutage 99% aller Anwendungsfälle auszumachen scheint.

Wenn dem Spieler die gängigen Verben mit einem Beispiel-Transkript oder einfach in einer Liste gezeigt werden, endet das oft mit dem Hinweis: Das sind aber nicht alle Verben!

Ganz genau, und damit sind sie um Längen intelligenter als diese Ingold-Ausführungen. Denn, was auch I. ganz bestimmt klar ist, und was wir hier im Thema ja auch bereits mehrfach festgestellt haben: Diese Vergleiche führen zu wenig, da sie immer schief und meist grundlegend falsch sind. Das Spieldesign muss eben anders geschehen. Der spielerische Anteil verlagert sich je nach Welt- und Spielmodell auf andere Ebenen. Siehe Gruescript: Alles wird explizit gemacht. Womit viele Dinge einfach nicht mehr funktionieren.

die Schlüsselszene in Die rote Blume funktioniert halt oder sie funktioniert nicht.

Wieder ein tolles Beispiel. Für mich hat sie hervorragend funktioniert! Und es wäre eben erzählerisch keinesfalls möglich gewesen in einem Anklick- und sonstwie expliziten Interface. Die gesamte Erzählung wäre emotional zusammengefallen, wenn da plötzlich ein neuer Button mit dem "neuen" Verb aufgetaucht wäre.

Wieso gibt es eigentlich keine Artikel, die solche Stärken beleuchten, solche Möglichkeiten aufzeigen, anstatt sich immer nur für angebliche Schwächen eines Parsers zu entschuldigen und defensiv zu rechtfertigen? Dabei gibt's da doch genug Anschauungsmaterial, von Zorks Schlauchboot angefangen.

Martin:

Dass "talk to" mit Dialogmenü mittlerweile Standard ist, gefällt mir nicht, weil mir diese (von Grafikadventures übernommene) Art der Konversation nicht gefällt.

Würdest du dann bei dem klassischen, reinen "FRAG NPC NACH X" bleiben, oder eher so eine Variante "FRAG NPC NACH X" mit Themen-Vorschlägen, wie es z.B. TADS oder auch die Erweiterung Threaded Conversation für Inform anbieten; also "(Du könntest NPC nach X, Y, Z fragen.)"? Oder ein anderes System?

[Re: Twine-Spiele] Diese langen Texte immer.

Hehe, die stören mich auch des öfteren. Es kann sich manchmal lohnen dranzubleiben, wenn es nur am Anfang bei der Einleitung auftritt. Aber wenn es in einem Spiel dauerhaft so weitergeht, dass lange Textabschnitte nur von sporadischen Interaktionsmöglichkeiten unterbrochen werden, kann es sehr nerven.

Und diese Fixierung auf verzögernde Texteffekte.

Das ist mit das Schlimmste. Ich glaube, das kommt von dem fehlgeleiteten Versuch, Filme oder Cut Scenes in graphischen Spielen zu simulieren.

Javascript durch den Hintereingang in in bestehendes Gerüst einzubauen, schränkt doch auch wieder ein. Da würde ich lieber etwas ganz Neues machen.

Kann ich gut verstehen. Klar, ein bestehendes Format zu erweitern würde nur dann Sinn ergeben, wenn man sich im Prinzip mit einem der Twine-Storyformate als Basis anfreunden kann, und wenn man keine konzeptionell gegenläufigen Erweiterungen plant, und man außerdem bei der Erweiterung weniger Arbeit reinstecken müsste, als wenn man ein System von Grund auf neu programmiert.

Allerdings ist mir der angestrebte Funktionsumfang und auch das, was davon in welcher Form den Autoren bereitgestellt werden soll (so dass es für sie leicht nutzbar ist), noch nicht ganz klar.

Ich meine, im Zusammenhang mit deiner sehr richtigen Frage:

Wie schafft man es, dass Leute, die am kreativen Prozess des Spieleschreibens interessiert sind, die sich aber nicht in die kleinteiligen Niederungen von Javascript, CSS und HTML begeben wollen, Spiele schreiben?

... würde ich eigentlich nicht davon ausgehen, dass die Leute JS lernen. Jedenfalls nicht als Voraussetzung, sondern höchstens, nachdem sie bereits "Blut geleckt" haben und dann tiefer einsteigen und mehr modifizieren wollen.

Das legt ja aber nahe, dass man für das neue System eine von zwei Möglichkeiten wählt:

1) Es folgt einer rigide vorgegebenen Logik, und die Anwender (Autoren) können im Grunde nur Datensätze definieren, um ihre Spiele zu schreiben; so ähnlich wie man manchmal graphische Spiele modden kann, indem man z.B. eine JSON- oder YAML-Textdatei umschreibt, in der Gegenstände und Quests etc. definiert sind. Das wäre einfach anzuwenden, aber klingt für mich nicht so flexibel, wie wir es eigentlich anstreben.

2) Oder man gibt den Autoren die Möglichkeit, auf einer bestimmten Ebene in die Auswertungslogik einzugreifen, also eigene Konditionale einzubauen und ähnliches, kurz: eine einfache Form des Programmierens, ohne JS lernen zu müssen. Das könnte in Form einer domänenspezifischen Mini-Skriptsprache geschehen, oder mit dem, was z.B. Twine/Sugarcube "Macros" nennt.

Dann wird allerdings der Implementierungsaufwand für das System schon eine ganze Ecke größer, und es könnte sein, dass es darauf hinausläuft, Twine und/oder Gruescript zu re-implementieren.

Das muss an sich natürlich nichts Schlechtes sein. Wenn man es gut hinkriegt, gibt es für ein solches System bestimmt einen Platz.

Ich wollte es nur erwähnen, weil es auch ein bisschen an Greenspuns Spruch erinnert: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Zugegeben, ein etwas anderer Kontext, aber das Phänomen kennt man: zuerst will man nur eine einfache Möglichkeit, ein System zu modifizieren, und dann baut man auf einmal eine halbe Programmiersprache nach.

Ich bin auch nicht supertief in der Twine-Thematik drin, aber mir kommt es dort zuweilen so ähnlich vor: der ursprüngliche Reiz ist, dass man mit ein bisschen Markup eine interaktive Geschichte schreiben kann, die überall spielbar ist. Dann verlangen die Autoren mehr Features und Flexibilität, und dann landet man schnell dabei, einen Wrapper um verschiedene JS-Sprachelemente zu schreiben, bis die Syntax a) zwischen verschiedenen Formaten divergiert, und b) in der Komplexität einer Programmiersprache nahekommt.

[...] von den Storyfiles weg und direkt zu HTML zu gehen. [...]

Die Z-Maschine und Glulx haben einige Einschränkungen, die man sich mit Javascript sparen könnte

Dass der Browser als plattformübergreifende Abspiel-Engine wohl die Zukunft ist, finde ich plausibel.

Aber hier ist mir auch nicht so ganz klar, worauf der Vorschlag hinausläuft. (Ist nicht böse gemeint! Auch rein spekulative Überlegungen sind ja völlig okay.)

Ein neues Parser-System zu schreiben ist ja nochmal eine ganze Nummer aufwendiger als selbst ein komplexes Choice-System wäre. Also da bin ich mir ehrlich gesagt nicht sicher, ob sich der Aufwand lohnt; wobei man natürlich wie bei vielen IF-Projekten auch sowieso sagen kann: wenn es Freude macht, ggf. als selbstzweckhaftes Spaßprojekt, war es nicht vergebens.

Wenn man die Frage, wie man die Leute heranholt, die vor allem am kreativen Prozess des Spieleschreibens interessiert sind, nochmal im Kontext von Parser-Spielen stellt, fallen mir erstmal drei mögliche Antworten ein:

1) Menübasierte Erstellung von Adventures; wie bei Adrift. Vorteil: kein Code nötig.

2) Browserbasierte Erstellung mit einer relativ einfachen Sprache; wie bei Adventuron. Wobei ich denke, dass der Erfolg dort auch spezifisch mit der Präsentation und dem Ansprechen einer Retro-Klientel zu tun hatte -- was absolut nichts Schlechtes ist, aber nicht automatisch zu drastischer Vergrößerung der Zielgruppe beiträgt.

3) Pseudo-natürlichsprachlicher Code; wie bei Inform 7. Was auch immer man davon hält, es hat mit Sicherheit (nach Aussagen verschiedener Autoren und engl. Forumsteilnehmer) viele Leute in die IF-Entwicklung gebracht, die (aus welchen Gründen auch immer) keine traditionellere Sprache angefasst hätten.

Nur kurz, Hannes, weil klar ist, dass Du nicht an einer ernsthaften Diskussion interessiert bist, sondern hier Deine Meinung setzen und auch irgendwie Deine Abneigung gegen Jon Ingold und Emily Short dokumentieren willst.

Ich finde Text-Interfaces auch gut und arbeite gerne in der Shell. Damit bin ich aber eine Ausnahme. Ich versuche, meine Kollegen sanft dazu zu bewegen, in diese Richtung zu gehen. Sie sehen den Nutzen, haben aber keine Zeit oder keine Lust, sich damit zu beschäftigen. Wenn es mal wieder was gibt, bei dem sie nicht weiterkommen, kommen sie halt zu mir. (So viel zu "Gib einem hungrigen Mann einen Fisch.")

Die Zugänglichkeit kommt also zuerst und ist für die meisten eine Hürde. Wer daran scheitert, kommt auch nicht in den Genuss der Effizienz. (Oder den Genuss der Möglichkeiten, die ein parser bietet.)

Und manche Programme sind halt als grafische Anwendungen besser. Ich möchte ja nicht haufenweise Bilder nach Schema F bearbeiten, wofür ein Batch-Modus tatsächlich besser wäre, sondern Grafiken selbst erstellen. MS Paint war natürlich kein gutes Beispiel, aber sagen wir mal mit Inkscape oder Krita.

Aber du wolltest da einen billigen Punkt machen. Der sei Dir gegönnt.

Daran, dass es die effizienteste Eingabemethode für Computerbedienung ist, hat sich nichts geändert.

Das mag für Dich so sein, für die meisten Menschen gilt das nicht. Nicht jeder möchte jeden Tag den Kernel neu konfigurieren, CLI-Anwendungen für die Shell schreiben und die Welt durch die Augen von Lynx sehen. Manche Leute möchten Grafiken erzeugen, Videos schneiden, Musik komponieren und natürlich auch im Internet surfen und die vielen Grafiken, Videos und Musikstücke konsumieren.

[rote Blume] Wieder ein tolles Beispiel.

Für mich hat das übrigens auch funktioniert. Das ist gutes, etwas riskantes Spieldesign, das sich mit anderen Systemen nicht umsetzen lässt.

Dass der Parser seine Stärken hat, darüber sind wir uns gewiss einig. Man braucht aber keine Artikel darüber zu schreiben, es genügt ja, wenn man diese Stärken in einem Spiel umsetzt. Zehn Jahre später loben dann zwei Fuzzies in einem obskuren Forum das Spieldesign.

Erfüllung sieht für einen Autoren gewiss anders aus. Insofern lohnt es sich schon, über Systeme mit expliziten Handlungsmöglichkeiten nachzudenken. Das Spieldesign sieht dann natürlich anders aus.

StJohn Limbo: Würdest du dann bei dem klassischen, reinen "FRAG NPC NACH X" bleiben, oder eher so eine Variante "FRAG NPC NACH X" mit Themen-Vorschlägen, wie es z.B. TADS oder auch die Erweiterung Threaded Conversation für Inform anbieten; also "(Du könntest NPC nach X, Y, Z fragen.)"? Oder ein anderes System?

Ich glaube, dass sich Parser-Spiele besser zur Objektmanipulation als für Konversationen eignen. Wenn ein Spiel hauptsächlich aus Konversationen besteht, sollte man überlegen, ob man es nicht vielleicht als Multiple-Choice-Spiel anlegt.

Aber Spiele ohne NPCs sind natürlich etwas leblos. Man will ja nicht alles aus etwas gekünstelten Tagebucheinträgen ("Was steckt unter der Kellertreppe? Muss morgen nachforschen, bin jetzt zu müde. Moment, es klingelt gerade ...") erfahren. Und den Trick, dass man stumm ist oder sich in einer fremden Umgebung befindet und die örtliche Sprache nicht kennt, kann man auch nicht immer anwenden.

Also ja, Konversation. Prinzipiell finde ich "FRAG NPC NACH X" nicht schlecht. Im Idealfall ergibt sich durch die Konversation ein Graph, der zu weiteren Themen führt, so wie eine Raumbeschreibung zum Untersuchen von Objekten und deren Unterobjekten führt.

Es gibt natürlich einige Schwierigkeiten: Soll man zwischen "frage nach" und "erzähle von" unterscheiden? Sind NPCs nur Lexika, die voneinander unabhängige Antworten zu vielen Themen geben? Gibt es "Hauptthemen" zu denen jeder etwas zu sagen hat. (NAME? JOB?) Gibt es einen Kontext? (Gewiss theoretisch interessant, aber praktisch schwer umsetzbar.) Wie behandelt man Wiederholungen? Soll man weiterführende Themen in den Anworten der NPCs kennzeichnen?

Dass man sich Themen, die man kennt, mit einem Befehl ("Themen", "T"?) anzeigen lassen kann, ist gewiss nicht schlecht. Ich würde diese Themen aber nicht von vorneherein präsentieren. Und vielleicht gibt es auch "scenery topics", bei denen keine Standard-Antwort kommt, sondern klar ist, dass das Thema hier (und auch bei anderen) nicht weiterführt. "Das interessiert den Herrn Rat doch nicht" bzw. "Dazu weiß der Herr Rat bestimmt nichts zu sagen" oder vielleicht ganz platt "Das ist gewiss kein geeignetes Gesprächsthema", also quasi die Themen-Variante von "Damit musst Du dich nicht weiter befassen."

Was mir nicht so gut gefällt, ist der Ansatz, bei dem einem viel mehr Optionen angeboten werden: "Du kannst dich bedanken, fragen, wo er gestern Abend war oder ihm eine Banane anbieten." Das ist eigentlich ein Menü, in dem ich die Optionen abtippen muss.

Dass Konversationen oft in einem eigenen Modus stattfinden ("Das geht nicht, solange Du noch im Gespräch mit dem Kapitän bist"), finde ich auch nicht gut. Meinetwegen sollen vor dem ersten und nach der letzten Frage kurze Floskeln ausgetauscht werden, aber ein formelles Umschalten in einen Gesprächsmodus würde ich vermeiden.

Allerdings ist mir der angestrebte Funktionsumfang und auch das, was davon in welcher Form den Autoren bereitgestellt werden soll (so dass es für sie leicht nutzbar ist), noch nicht ganz klar.

Mir auch nicht.

Meine losen und vermutlich nicht ganz zu Ende gedachten Gedanken für ein Gruescript++ gehen in etwa in diese Richtung:

Der Autor erstellt sein Werk aus mehreren Dateien:

Das Gerüst ist eine HTML-Datei plus CSS und Javascript. Das Gerüst gibt vor, wie das Layout und das Interface gestaltet ist. Meine beiden Versionen der Passage hätten verschiedene Gerüste. Es gibt eine Bibliothek von Gerüsten. Diese Gerüste werden in der Regel nicht von den Autoren selbst geschrieben.

Der eigentliche Quelltext des Spiels besteht aus einer oder mehreren Dateien in einer eigenen Sprache. Letzten Endes wird hier das JS-Object game gefüllt. Man könnte also JSON nutzen, aber eine reduzierte Sprache ist gewiss einfacher und hätte auch weniger Kommas und geschweifte Klammern:

pistol:
    name: `die Pistole`
    location: player
    portable: true
    description: `Diese kleine Manufrance hast du
        der Comtesse abgenommen, damit sie keine Dummheiten macht.`

wird zu:

pistol: {
    name: `die Pistole`,
    location: 'player',
    portable: true,
    description: `Diese kleine Manufrance hast du
        der Comtesse abgenommen, damit sie keine Dummheiten macht.`,
},

Dann gibt es noch optionale Module, mit denen man zum Beispiel eine bestimmte Sprache oder bestimmre Verhaltensweisen einbinden kann, wenn man möchte. Diese Module sind entweder in der GS++-Spache geschrieben oder in Javascript. Dann kann man mit einer Sondersyntax ein Interface zu GS++ schreiben:

@macro demonic-bg
function demonic_bg() {
    document.body.style.backgroundColor = 'black';
    document.body.style.color = 'tomato';
}

und es im Quelltext nutzen:

if player.shape is human:
    verb offenbare dich:
        player.shape = demonic

        demonic-bg
        say Du änderst deine Gestalt ...

Es gibt die Varianten @macro, @cond für Bedingungen und @say für eigene Textbefehle wie "[Der self] [ist] heute [moody self.mood]."

Das ist ähnlich wie (- ... -) in Inform 7, nur dass die darunterliegende Sprache Javascript von mehr Leuten geprochen wird. Ein Autor könnte also, wenn er tiefer einsteigen möchte, mit jemandem, der HTML kann, kooperieren.

Damit würde dann, so die Hoffnung, zumindest die bugbehaftete, langsame Implementierung einer weiteren Zwischensprache wegfallen. Das Problem, dass dann zig Gerüste entstehen und dass dann vermutlich wieder mehr auf die Form als den Inhalt geachtet wird, sehe ich aber schon.

Viellecht ist das aber auch alles nicht nötig, weil Twine das schon kann. Außerdem ist der "Markt" für Gruescript-Spiele wohl gar nicht so groß: Der Grand Prix hat den Pool an Gruescript-Spielen um 50% vergrößert, um 20%, wenn man Robin Johnson's Vorgänger mitzählt.

[Weg von Z-Maschine und Glulx] Aber hier ist mir auch nicht so ganz klar, worauf der Vorschlag hinausläuft. (Ist nicht böse gemeint! Auch rein spekulative Überlegungen sind ja völlig okay.)

Dazu habe ich natürlich auch noch was zu sagen. Später. Es klingelt gerade ...

Martin:

[... gute Überlegungen zum Thema Konversation ...]

Soll man zwischen "frage nach" und "erzähle von" unterscheiden? Sind NPCs nur Lexika, die voneinander unabhängige Antworten zu vielen Themen geben? [...] Gibt es einen Kontext? (Gewiss theoretisch interessant, aber praktisch schwer umsetzbar.) [...] Meinetwegen sollen vor dem ersten und nach der letzten Frage kurze Floskeln ausgetauscht werden

Das Konversationssystem in TADS (Choosing a Conversation System, Programming Conversations with NPCs) oder auch die entsprechenden Erweiterungen von Eric Eve für Inform 7 bieten da ein paar Möglichkeiten, den Unterhaltungen einen gewissen "Flow" zu geben. Also dass es z.B. automatische Begrüßungen und Verabschiedungen gibt; dass manchmal NPCs ihrerseits eine Frage stellen können und auf einer Antwort beharren; dass es Themenvorschläge gibt.

Hier aus der Dokumentation zu Eves "Conversation Package" für I7:

Conversation Framework [...] provides greeting protocols (saying hello and goodbye), and allows abbreviated forms of conversational commands (A Y, ASK FOR Y, T Y) once conversation is under way.

Conversation Responses [is] particularly useful for defining responses for more than one command, e.g. "Response of Bob when asked-or-told about Sally" defines a common response to ASK BOB ABOUT SALLY and TELL BOB ABOUT SALLY.

Conversational Defaults [...] for handling default responses, i.e. the responses NPCs make to topics we have not explicitly allowed for.

Conversation Suggestions [...] for suggesting which topics of conversation it may be worth to pursue

Conversation Nodes provides a means of structuring conversations via points in the conversation ('nodes') when a particular set of responses become relevant (e.g. answering yes or no to a question an NPC has just asked).

Der Nachteil ist, dass es einiges an Overhead bedeutet und ziemlich viel Arbeit macht, eine Konversation damit wirklich gründlich zu implementieren.

Wie behandelt man Wiederholungen?

Eine relativ gute Lösung ist m. M. n. eine Kurzzusammenfassung in indirekter Rede:

>FRAG ALICE NACH AMULETT
Alice hat dir bereits erzählt, dass das Amulett gestohlen wurde.

Damit vermeidet man, dass der NPC wie ein Papagei immer dasselbe ausspuckt.

Ein Nachteil ist natürlich die Mehrarbeit für den Autor.

"scenery topics", [...] also quasi die Themen-Variante von "Damit musst Du dich nicht weiter befassen."

Finde ich gut, aber ist natürlich schwierig, da eine Formulierung zu finden, die immer passt, so dass keine inkongruent wirkende Kombination von Thema und Ablehnungs-Meldung rauskommt (z.B. wenn man den Herrn Rat nach seiner Frau, seiner Heimatstadt oder seinem Beruf fragt). Insofern spricht das für trockene Formulierungen wie das vorgeschlagene "Das ist [gewiss] kein geeignetes Gesprächsthema" oder so etwas wie "Das ist kein Thema, das dich weiterbringen würde" oder "Das ist hier nicht von Belang".

Was mir nicht so gut gefällt, ist der Ansatz, bei dem einem viel mehr Optionen angeboten werden: "Du kannst dich bedanken, fragen, wo er gestern Abend war oder ihm eine Banane anbieten." Das ist eigentlich ein Menü, in dem ich die Optionen abtippen muss.

Ich denke, ein gewisser Reiz bei dem System ist, dass man damit Handlungen einbauen kann, die in ihrer Formulierung und ihrer Granularität nicht gut zu einem reinen ASK/TELL-System oder zu einer physischen Weltmodell-Handlung passen.

Zum Beispiel: "Du kannst Abbitte leisten, die Invasion des Nachbarreiches befehlen, oder den Ketzer ins Verlies werfen lassen." Da müsste man erstmal ziemlich umformulieren, um es in Form von "FRAG NACH / ERZÄHL VON ..." auszudrücken. Eine Zuordnung zu Spielerhandlungen in der Modellwelt wäre auch schwierig (vllt. "BEUG KOPF" [aber Achtung, guess-the-verb], "ZERREISS FRIEDENSVERTRAG", so ungefähr). Da bietet so eine Vorschlagsliste ganz interessante Möglichkeiten.

Aber an deinem Einwand ist auf jeden Fall was dran. Man kann dadurch leider etwas aus dem Parser-Modus rauskommen bzw. kann die Mischung verschiedener Eingabeformen (frei vs. Quasi-Menü) als störend empfinden.

[Gedanken für ein Gruescript++]

Danke für das Beispiel und die Erläuterungen, das hilft auf jeden Fall schon mal, es sich genauer vorzustellen! Sieht so auch für Einsteiger ganz gut verständlich aus, denke ich.

Viellecht ist das aber auch alles nicht nötig, weil Twine das schon kann.

Jein, schwer zu sagen. Also wie oben gesagt kann Twine theoretisch alles, was Javascript kann. Aber praktisch gesehen muss man vermutlich ziemlich herumbasteln, bis man von einer Twine-typischen verzweigten Hypertext-Erzählung zu einem adventure-ähnlichen Interface mit Inventar, Weltmodell, Ortsnavigation kommt.

D.h. wenn das hypothetische neue System es einem Autor leicht macht, ein Spiel im Stil der "Passage in den Tod" oder im Stil von Gruescript zu machen (aber flexibler/schöner als Gruescript), dann könnte das durchaus lohnenswert sein. Aber ich würde auf jeden Fall auch empfehlen, nur zur Probe ein oder zwei kurze Anfänge in Twine zu realisieren, einfach um die Vergleichsmöglichkeit zu haben.

Martin:

klar ist, dass Du nicht an einer ernsthaften Diskussion interessiert bist, sondern hier Deine Meinung setzen und auch irgendwie Deine Abneigung gegen Jon Ingold und Emily Short dokumentieren willst. [...] Aber du wolltest da einen billigen Punkt machen. Der sei Dir gegönnt.

Na, das sind ja ganz schön scharfe Worte und eine harte Unterstellung. Immerhin bin nicht ich derjenige, der einen salbadernden Trollartikel ins Internet gestellt hat, der in einem Handstreich und ohne jeglichen Versuch eines Belegs oder auch nur es nachvollziehbar zu machen "den Menschen" irgendwelche Deutungen und Interpretationen unterstellt. Im Übrigen seltsam, solche Reaktionen zu bekommen, wenn du mir gleichzeitig anscheinend weitgehend in den Hauptpunkten zustimmst.

Mal sehen, vielleicht entspricht ja Folgendes deinen Ansprüchen an eine "ernsthafte Diskussion":

John I.

Having the game not let me type a command that it won’t understand is a good way to teach me to interact with parsers, but it’s still the game saying “no” to wrong input. Instead, why shouldn’t the game do that filtering of the context for me?

If it did – if it filtered all the possible input down to what’s sensible and interesting, and then presented them as a choice – surely then the game is reinforcing my presence and position in that world, and not detracting from it. In this new game, every action I take is interacting directly with something which has been determined to be interesting, rewarding and worth my attention. I am in a loop of meaningful activity.

Öhm... nö. Dann klicke ich nur noch Option für Option durch. Treffe also faktisch keine Entscheidungen mehr. Nicht meine Definition von "meaningful".

Es sei denn, die Optionen schließen sich gegenseitig aus. Womit wir dann wieder beim Punkt wären: Es braucht dann ein anderes Spieldesign. Andere Aufgabenstellungen. Was John aber in seinen Ausführungen nicht vorsieht. Er spricht explizit davon, einen Parser mit einem Auswahlinterface zu ersetzen, 1:1 auf dem gleichen Spiel. Er sagt dieses sogar explizit, direkt davor:

During the construction of Sorcery! 2, and as we move into Sorcery! 3, which is going to be even more open-world-ish – these possibility are starting to mess with my head. The more I write like this, the more I’m turning off the multiple-choice part of my brain, and turning back on the parser-IF design side. The design process of locations, puzzles and interactions is starting to feel more the process behind The Mulldoon Legacy or Make It Good than the process behind games like The Intercept.

Er sagt also, er designt sein Spiel wie ein Parserspiel, verwendet dann aber keinen Parser. Ich habe seine Sorcerys nicht gespielt, kenne aber immerhin die Bücher, auf denen es basiert. Ebensowenig kenne ich sein 80 Days. Derlei Statements schrecken mich ganz klar ab, sie jemals auszuprobieren, denn ich habe kaum einziges gutes Spiel, das aus derlei Designphilosophie entstanden ist, erlebt. Weshalb?

Andrew P.

The same goes for attempts to "port" parser games to a choice-based UI. I have nothing against remakes of a game. (Coloratura, for one example, is a parser game that was remade by the author in Twine.) But this is a design process, akin to translating a book into a movie or vice versa. You can't slap a new UI system onto a game and expect it to be "the same game but now accessible to more people".

Ja, genau deswegen.

Alle meine Ausführungen gelten selbstverständlich auch andersherum: Ein Multiple-Choice-Spiel in Parser zu übersetzen geht meist genauso schief.

Hannes: Im Übrigen seltsam, solche Reaktionen zu bekommen, wenn du mir gleichzeitig anscheinend weitgehend in den Hauptpunkten zustimmst.

Vermutlich haben wir hier keine sehr unterschiedliche Meinung, aber die Vehemenz, mit der Du auf den Artikel reagiert hast, hat mich schon erstaunt.

Dann klicke ich nur noch Option für Option durch. Treffe also faktisch keine Entscheidungen mehr. Nicht meine Definition von "meaningful".

Ich kenne werde die Sorcery!-Spiele noch die Bücher, aber das hört sich für mich nach einem klassischen Kampf-Rollenspiel an. ("An epic adventure through a land of monstars, traps and magic" sagt die Website.) Und wenn nur Zeit ist, eine oder zwei der angebotenen Aktionen durchzuführen, dann sind die schon eher "meaningful".

Er spricht explizit davon, einen Parser mit einem Auswahlinterface zu ersetzen, 1:1 auf dem gleichen Spiel. Er sagt dieses sogar explizit, direkt davor:...

Das tut er meiner Meinung nach gerade nicht. Dass man alle Optionen in einer Situation, die in einem Parser-Spiel eine sinnvoll wären, herausfiltert und sie dann als Optionen anbietet, ist ein Gedankenexperiment, auf dem das Design von Sorcery! aufbaut. Er spricht von "stabs in that direction" und wie sich dadurch der Prozess der Entwicklung vom Gefühl her mehr in dem Prozess in seinen Parser-Spielen nähert.

Gruescript ist das System, das die Design-Philosophie von Parser-Spielen 1:1 in ein Interface ohne Parser übertragen will.

StJohn Limbo: Hier aus der Dokumentation zu Eves "Conversation Package" für I7: ...

Ja, das Feld der Konversationen in Textadventures ist schon ordentlich beackert worden.

[Re: "scenery topics"] Finde ich gut, aber ist natürlich schwierig, da eine Formulierung zu finden, die immer passt, so dass keine inkongruent wirkende Kombination von Thema und Ablehnungs-Meldung rauskommt.

Ich sehe da eine Analogie von Spielobjekten ...

> öffne Schüssel
Die Schüssel lässt sich nicht öffnen.

> öffne Fenster
Mit dem Fenster musst du dich nicht weiter beschäftigen.

> öffne Sesam
Ich kenne das Wort "Sesam" nicht.

... mit Gesprächsthemen:

> frage Wirt nach Burg
Der Wirt schaut dich an: "Darüber weiß ich nichts."

> frage Wirt nach Baum
Der Baum ist gewiss kein geeignetes Gesprächsthema.

> frage Wirt nach Gin
Das Wort "Gin" kenne ich nicht.

Der jeweils erste Fall ist eine Aktion, die fehlschlägt. Der zweite Fall auch, aber dem Spieler wird gesagt, dass er sich nicht weiter mit dem Objekt als manipulierbarem Gegenstand bzw. als Gesprächsthema beschäftigen soll. (Und wenn man den Wirt nicht nach dem Baum fragen kann, soll man auch niemand anders über den Baum fragen können. Ob etwas ein Thema ist oder nicht, ist universell.)

Der letzte Fall ist natürlich ein Fehler, der im Parser auftritt. Ich mag explizite Fehlermeldungen und würde auch die Gesprächsthemen als "[topic]", also als zusätzlich angegebenes Vokabular, sondern als Objekt umsetzen, auch wenn man zusätzliche Objete definieren muss, die nur als Thema dienen.

Mit dem Begriff "scenery" wolle ich diese Analogie verdeutlichen, aber man würde natürlich umgekehrt vorgehen und die verstandenen Themen als "topic" oder so kennzeichnen.

Vielen Dank, Martin, für das ausführliche Behandeln des Themas mit den Überlegungen zu Puzzledesign und Layout und das Ausarbeiten der beiden Design-Varianten.

Da schon viel diskutiert wurde, nur kurz noch mein Kommentar (was aber so scheinbar Konsens ist): Ich finde Variante 1 sehr schick und recht elegant. Variante 2 ist zwar toll und aufgeräumt mit den Kontextmenüs, aber imho stört etwas, dass man einfach (gefühlt) zu viel Klicken muss.