Da der diesjährige IFGP abgeschlossen ist, der ja scheinbar unter dem Motto "Reise Richtung Norden" stand (selbst die Tataki schippert anfangs gen Nordosten), wollte ich auch kurz meine Gedanken zu Gruescript schreiben (im Folgenden alles nur sehr subjektiv):

Allgemein zu Gruescript:

Eher Vorteile:

• Man kommt recht schnell in die Sprache rein. Es gibt neben Beispielprogrammen ein sehr ausführliches Manual, das eigentlich keine Fragen offen lässt.
• Man kann, im Gegensatz zu klassischen Parser-Text-Adventures, sehr schnell sein Spiel umsetzen, da einem nächtelanges Abarbeiten von Beschreibungen und Verb-Reaktionen auf Scenery-Objekte wegfallen (wenn man das nicht so mag).
• Da die Eingabe der Spieler deterministisch ist, ist das Beta-Testen und allgemein die Fehlersuche wesentlich leichter (auch wenn dafür der Wahnsinn und die Unberechenbarkeit eines Parser-Spiels natürlich etwas verloren geht). Die Spiele lehnen sich etwas mehr an CYOA-Spiele an.
• Die Spiele sind auf dem Smartphone vernünftig spielbar, z.B. auf dem Weg zur Arbeit im Zug, also imho gerade für Casual Gaming geeignet, wenn man nicht mit Karopapier, Cola und Pizza sich einen Abend frei nehmen will, um ein klassisches Infocom-Spiel zu spielen (und dann im drehenden Raum kein weiteres Rätsel lösen kann und mit Cola und Pizza nach 5 Minuten wieder vor den Fernseher umzieht).
• "Guess-the-right-word"-Rätsel entfallen.

Eher Neutral:

• Die Rätsel sind in der Tendenz eher einfacher als in klassischen IF.
• Beta-Testing bleibt aber unabdingbar um Ungeschliffenheiten und Bugs zu finden (hier nochmal tausend Dank an meine Tester).
• Der Source-Code des Spiels ist aus der Spiel-Datei mit einem Texteditor direkt lesbar.
• Kombinationsrätsel, wie die richtige Reihenfolge für etwas finden oder den richtigen Code in einen Safe eintippen, funktionieren sehr gut.

Eher Negativ:

• Objekt-Rätsel funktionieren etwas schlechter, gerade wenn ein neuens Verb "aufploppt" um die Aktion zu beschreiben (z.B. "verbinde Schrubber mit Haken"). Wenn aber eine Aktion immer möglich ist (wie z.B. "blase in Vuvuzela") und nur an einer Stelle dann das erwünschte Ergebnis bringt, ein Rätsel löst oder die Geschichte voranbringt, dann funtkionieren sie aber imho durchaus.
• Gruescript funktioniert "Out of the Box". Wenn man das Spiel aber etwas schöner haben will, muss man sich dann doch mit CSS und Javascript auseinandersetzen.
• Es gibt keine hilfreichen Abkürzungen wie in Inform mit "[first time]...[only]", "[only one]...[or]...[at random]" oder überhaupt "if-then-else"-Verzweigungen für Texte. Man muss (zumindest hatte ich keine bessere Methode dafür gefunden) erst vor der Ausgabe des Textes eine Prozedur aufrufen, die diese Abfragen macht, dann den entsprechenden Text in eine globale Variable schreiben und darauf diese im Text daselbst ausgeben.
• Die ganzen versteckten Gags, wie in Parserspielen, lassen sich schwer umsetzen. Der Protagonist in meinem Spiel wird an mehreren Stellen als "Zerstörer von Welten" betitelt. Normalerweise würde man eine launige Reaktion auf die Eingabe "zerstöre welt" schreiben (zusammen mit einem Hinweis auf die Undo-Funktion). In Gruescript müsste man im Interface einen Button anlegen, was für so einen simplen Gag einfach zuviel wäre und ihn auch gleichzeitig killen würde.
• Die eigentlich nie eingehaltene Metapher von "ich unterhalte mich mit dem Computer wie mit einem Menschen in einem anderen Raum: Ich tippe etwas, er antwortet im selben Medium, ich tippe etwas,..." geht verloren (man denke an "Eliza" in der frühen ChatBot-Geschichte).

Gruescript für deutschsprachige Spiele:

Dem Programm liegt eine beispielhafte Übersetzung des "Mantel der Dunkelheit" ins Spanische bei, was sehr hilft. In der aktuellen Beta ist man aber gezwungen, da einige Default-Texte nicht mit Variablen ersetzbar sind, doch einiges im Quellcode von Gruescript zu ändern. Das dürfte aber eigentlich für keinen ein Problem darstellen, der rudimentäre Erfahrung hat, wie typische Programmiersprachen aufgebaut sind. So wird z.B. auch fest ein Komma gesetzt vor dem "und" in Aufzählungen. Ich hatte dem Entwickler eine Mail mit einer Aufzählung dieser Probleme geschickt, in der Hoffnung, dass er die Punkte in eine spätere Version von Gruescript mit einfließen lässt. Ansonsten muss man sich etwas behelfen und weitere "Default"-Variablen in seinem Spiel definieren (z.B. für Akkusativ-Formen von Objekten, damit es heißt "Du siehst einen Tisch und ein Haus." und nicht "Du siehst ein Tisch und ein Haus.". Evtl. können bessere Programmierer hier eine bessere/automatischere Lösung wie in Inform schreiben. Genauso hatte ich auf Dauer zu allen eigenen Verben die Prompt-Ausgabe direkt angegeben: Klickt man auf "lesen" hinter dem Objekt "Buch", so habe ich die Promptangabe "lies das Buch" direkt angegeben und das nicht über Variablen gelöst. Schön ist aber, dass das alles überhaupt möglich ist und Spiele umsetzbar sind, denen man nicht anmerkt, dass sie in einem System, das zuvorderst für englischsprachige Spiele entwickelt wurde, programmiert wurden.

Meines Erachtens eignet sich das Programm gut, um kleine Puzzler zu bauen (im Handbuch zu Gruescript wird explizit Bezug auf Scott-Adams-Spiele genommen), oder aber umfangreiche, erzählende Spiele, wenn der Autor keine Lust hat, sich mit zuvielen Scenery-Objekten, etc. rumzuschlagen. Michael Baltes "Geheimnis von Beagle's Rock" weist da imho stark in diese erzählende Richtung. Auch hat Michael gleich Grafik mit umgesetzt, was vielleicht auch zur Darstellung einer Kompassrose genutzt werden könnte (wie z.B. in den Legend-Entertainment-Titeln).

In dem Forum fiel, mangels u.a. echten Objekträtseln in Gruescript-Spielen, der Vergleich zu Render-Adventures (zumindest in der Art der Rätsel und Erzählstruktur) und er ist nicht ganz von der Hand zu weisen. Allerdings gibt es hier neben all den "Türme von Hanoi / Schiebepuzzle"-Spielen auch durchaus Perlen wie Riven, die imho absolut überzeugend funktionieren. Oder man nimmt die Künstlichkeit der Rätsel als Erzählprämisse, wie es z.B. aktuell bei den "The Room"-Spielen von Firework Games der Fall ist. Es gibt bestimmt Autoren, die auch in diesem System ganz großartige, fordernde Rätsel schaffen können (wie ich ja auch immer mal wieder in CYOA-Spielen gelingt). Ich persönlich würde hoffen, dass weitere Spiele in dem Längen-Format "30-60 Minuten" geschrieben werden.

Edit (02.05.23 / 12:54): Ich vergaß noch den Punkt, dass man in Gruescript dank der Button-Struktur leicht neue Funktionalitäten ("schau in die Zukunft", "verteidige Torso") einführen kann, ohne sie durch eine Anleitung am Anfang des Spiels erklären zu müssen oder didaktisch vorbereiten zu müssen. So müsste man in einem Parser-Spiel zu dem Beispiel "verteidige Torso" frühzeitig in dem Spiel eine Situation schaffen, bei der man angegriffen wird und darauf hingewiesen wird, dass man sich ja verteidigen könnte (z.B. durch einen betrunkenen Partygast, der einem immer wieder etwas zu fest auf die Schulter haut und sich darüber lustig macht, dass man ja gar nicht die Flanke verteidigt (solange bis man zum richtigen Zeitpunkt "verteidige Flanke" eingibt)), so dass am Ende des Spiels, wenn man diese Funktion als Teil des End-Rätsels braucht, der Spieler gesichert weiß, dass er diese Option ja überhaupt hat.

Edit (08.05.23 / 10:16): Ein Punkt, der aus einer Diskussion auf https://intfiction.org/t/german-language-if-grand-prix-2023/ hervorging und vielleicht irgendwann mal zum Tragen kommen kann, wenn Maschinenübersetzungen noch etwas stärker werden: Man kann Gruescript-Spiele in einem entsprechenden Browser aus einer anderen Sprache automatisch übersetzen lassen und ohne echte Kenntnisse der Ausgangssprache spielen. Das Spiel erscheint dann komplett in der eigenen Sprache. Dasselbe gilt zwar auch für Parser-Spiele, die man in einem Browser startet, allerdings müssen die Befehlseingaben hier in der Ursprungssprache gemacht werden. Da allerdings unklar bleibt, wie einzelne Objekte im Ursprung hießen (z.B. "a box" für entweder "eine Kiste" oder "ein Kästchen", ...) muss man doch das Originalspiel wenigstens parallel spielen und rudimentäre Kenntnisse in der Ursprungsspache haben).

Der Vollständigkeit halber gerade noch, mehr als Archivar, die Links zu den Reviews, die sich auch detailliert mit dem System auseinandergesetzt haben:

• https://if-forum.org/topic.php?id=1295 (Thread zu "Das Geheimnis von Beagle's Rock")
• https://if-forum.org/topic.php?id=1297 (Thread zu "Ich, Shub-Jagaroth")
• http://martin-oehm.de/adv/gruescript.html (allgemein zu Gruescript von Martin Oehm)

Vielen Dank, Heiko, für diese umfangreiche Bewertung von Gruescript aus der Autorenperspektive.

... Reviews, die sich auch detailliert mit dem System auseinandergesetzt haben: ...

Oh, jetzt muss ich meinen vollmundig angekündigten Artikel über Gruescript ja doch zügig zu Ende schreiben. Ich habe mich natürlich nicht so intensiv mit der Sprache selbst beschäftigt und werde das Ganze aus Spielersicht betrachten.

Du hast ja schon geschrieben, dass sich nicht alle Arten von Rätseln, die man aus Parserspielen kennt, gleich gut in Gruescript umsetzen lassen, und ich schließe mich Deiner Meinung an, dass man mit umsichtigem Rätseldesign gewiss gute Gruescript-Spiele schreiben kann.

Und ich denke, dass vor allem beim Layout noch viel Luft nach oben ist. Ich bin jedenfalls mal gespannt, was da noch auf uns zukommt. Vielleicht die von Dir gewünschten kurzen Puzzler?

Sehr interessant! Ich schließe mich Martins Aussage auf seiner Webseite vorbehaltlos an, es ist gut, dass wir diese zwei Spiele bekommen haben.

Ich habe den Vergleich mit den Renderadventures habe ich verbrochen. Also kurz dazu. Heiko hat recht, in jeder Darstellungsform gibt es gute Spiele. ziemlich wörtlich habe ich das vor ein paar Tagen über die allseits gescholtenen FMV-Adventures der 90er Jahre gesagt. Leider ist die erste Assoziation aber eine andere. Nämlich irgendwelche dummen Springerprobleme, das Öffnen von Kisten oder Türen mit farbigen, verschieden geformten Bauklötzen usw.

Es bedarf einem anderen Medium eben neuer Gedanken, wie man ein gutes Spiel macht. Diese Findungsphase befindet sich für Gruescript ganz sicher noch am Anfang. Experimente, was funktioniert und was nicht, werden noch viele stattfinden müssen.

Generell scheint, was Interaktion angeht, das Denken bislang in Richtung Wissensrätsel zu gehen. Das ergibt Sinn, weil dies ja im Spiel nicht durch das Interface verraten wird, wie es bei mechanischen Rätseln der Fall ist. Doch auch hier gibt es Abstufungen. Michaels Rätsel mit den Statuen empfinde ich spontan als positives Beispiel. Seine Süteßterlinnotiz dagegen als negativ, da dann praktisch überhaupt kein Anteil der Lösung mehr im Spiel selbst stattfindet.

Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren. Was ja in Krimiadventures immer wieder ein ungelöstes Problem ist.

Auch bewusst erwähnt hatte ich ja in dem Kontext auch Ren'Py. Dem stand ich anfangs sehr negativ gegenüber. Doch mittlerweile habe ich auch darin Spiele entdeckt, die mir insgesamt gefallen haben. Man muss halt den passenden Spielinhalt für die Darreichungsform finden. Nur, in Ren'Py wie in Twine usw. ist der Löwenanteil der Spiele eben leider unerträglich. Was die ganzen Medien herunterzieht. Wie früher Render- oder FMV-Adventures.

Auch von mir danke für den detaillierten Einblick mit Pro- und Contra-Aspekten, Heiko!

Ich habe mich in den Rezensionen relativ kritisch zu Gruescript als System geäußert, freue mich aber darauf, was ggf. an weiteren Spielen und Experimenten/Entwicklungen kommen wird. Hab auch schon überlegt, mal ein eigenes Projekt damit zu starten.

Hannes:

Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren. Was ja in Krimiadventures immer wieder ein ungelöstes Problem ist.

Finde ich auch sehr interessant, weil ich selbst mit einem Krimiadventure liebäugele. Hast Du schon eine bestimmte Mechanik vor Augen, z.B. in Richtung "Verbinde Spur A mit Zeugenaussage B"? (Oder vllt. auch gerade das nicht?)

Das System aus "Detective Grimoire" (Graphikadventure) fand ich vor einiger Zeit ganz witzig. Da musste man die Zusammenhänge herstellen, indem man quasi einen Satz aus vier Variablen bildete; zwei Leerstellen waren für eine Reihe vorgegebener Textbausteine vorgesehen, zwei weitere für Bezüge auf Tatsachen, NPCs, Gegenstände (siehe Screenshot im Anhang).

StJohn Limbo:

Hannes:

Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren. Was ja in Krimiadventures immer wieder ein ungelöstes Problem ist.

Finde ich auch sehr interessant, weil ich selbst mit einem Krimiadventure liebäugele. Hast Du schon eine bestimmte Mechanik vor Augen, z.B. in Richtung "Verbinde Spur A mit Zeugenaussage B"? (Oder vllt. auch gerade das nicht?)

Das ist so das beste, was ich bislang gesehen habe in ein paar Spielen, denn damit wird der Wissenserwerb immerhin überhaupt im Spiel modelliert. Gar nicht mag ich es, wenn Protagonisten plötzlich einfach irgendwelche Schlüsse ziehen oder Wissen haben, den ich mir als Spieler überhaupt noch nicht erschlossen habe. Weil die Autoren davon ausgehen, ich müsse das jetzt ja bereits "offline" verstanden haben. Aber auch ein solches System ist aber immer noch weit von einem Idealzustand, finde ich. Es geschieht dabei immer noch häufig, dass durch das mechanische Verknüpfen von Informationen innerhalb des Spiels es zu Schlüssen kommt, die gar nicht dem entsprechen, was ich im Kopf hatte. Ich also sozusagen durch Zufall etwas "löse", obwohl mein Denken in ganz andere Richtungen ging. Zugegeben, das gleiche kann bei mechanischen Objekträtseln auch passieren. Durch "Benutze Nagel mit Brett" will ich vielleicht ausdrücken, ersteres solle eingeschlagen werden, aber dann macht der Protagonist vielleicht doch einfach ein Loch darein, um hindurchzusehen.

Leider haben aufwändigere Systeme in Detektivspielen anscheinend die Angewohnheit, dann sehr, sehr komplex zu werden. Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948. Sehr ausdrucksstark und erlaubt sehr feine Abstufungen, aber man verliert praktisch sofort den Überblick. Das Zusammenklicken der Aussagen und Fragen dauert außerdem viel zu lange, so dass man schnell die Motivation verliert.

Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948.

Dass das noch jemand kennt, wow.

Hannes:

auch ein solches System ist aber immer noch weit von einem Idealzustand

Ja, schwieriges Problem, sehe ich auch so. Teils werden durchs Kombinieren ganz andere oder weitreichendere Schlüsse gezogen, als man erwarten würde, und das nimmt einem dann den Spaß an der Lösung. Und teils ist es so, dass man vorm Bildschirm schon selbst die richtigen Überlegungen angestellt hat, aber man nicht weiß, welche obskure Aktion man jetzt im Spiel noch auslösen muss, damit die Spielfigur auch auf den Stand kommt.

StefanH:

Hannes: Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948.

Dass das noch jemand kennt, wow.

Ich nicht, muss ich zugeben.

Ich hab mir ein paar Screenshots angeguckt; sieht interessant aus, aber auch tatsächlich etwas umständlich.

Hannes: Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren.

Der berühnte "Gedankenpalast". Oder natürlich das Whiteboard im Kommissariat, auf dem Fotos von Verdächtigen und Beweisstücke in Verbindung gebracht werden.

Wie man das aber in einem Interface mit expliziten Optionen umsetzt, ohne dass dem Spieler Logiksprünge in den Kopf gesetzt werden und ohne dass man alles ausprobieren kann, bis es passt, weiß ich nicht, aber ich denke nicht, dass sich Gruescript besonders gut dazu eignet. Vermutlich müsste man ein eigenes Interface entwickeln.

StJohn Limbo: Hast Du schon eine bestimmte Mechanik vor Augen, z.B. in Richtung "Verbinde Spur A mit Zeugenaussage B"? (Oder vllt. auch gerade das nicht?)

Oder man müsste drei Dinge miteinander verknüpfen: Zwischen A und B besteht eine (mögliche) Verbindung über Indiz X.

Vielleicht modelliert das Spiel auch nicht, was der Spieler über die Tat weiß, sondern was er meint zu wissen, so dass er sich in seinem Gedakenpalast quasi verlaufen kann: A und B werden verknüpft, weil es ein Indiz X gibt und das ist dann wiederum ein Indiz Y, mit dem man C und D verknüpfen kann, nur dass die Annahme, dass A und B verknüpft sind, bereits falsch ist.

(Das zu programmieren ist aber eine Herausforderung: Wenn man eine früh im Spiel getroffene Annahme widerruft, ribbelt sich das ganze danach gesponnene Gedankennetz wieder auf.)

Und teils ist es so, dass man vorm Bildschirm schon selbst die richtigen Überlegungen angestellt hat, aber man nicht weiß, welche obskure Aktion man jetzt im Spiel noch auslösen muss, damit die Spielfigur auch auf den Stand kommt.

Wenn die Aktion nicht obskur wäre, sondern sich eindeutig aus den gesammelten Indizien ergäbe, wäre das tatsächich eine fast ideale Lösung. Vielleicht müsste man dazu noch nicht einmal den Wissensstand im Spiel ausdrücklich modellieren. Aber natürlich ist die Gefahr, dass so etwas für viele Spieler dann doch wieder obskur ist, zu groß.

[Detective Grimoire] Da musste man die Zusammenhänge herstellen, indem man quasi einen Satz aus vier Variablen bildete; zwei Leerstellen waren für eine Reihe vorgegebener Textbausteine vorgesehen, zwei weitere für Bezüge auf Tatsachen, NPCs, Gegenstände

Etwas Ähnliches scheint The Case of the Golden Idol zu machen, wo man Lücken im Text füllen muss. (Hab's aber nicht gespielt, nur davon gehört.)

Martin:

Oder man müsste drei Dinge miteinander verknüpfen: Zwischen A und B besteht eine (mögliche) Verbindung über Indiz X.

Gute Idee, das würde es etwas komplexer machen.

Vielleicht modelliert das Spiel auch nicht, was der Spieler über die Tat weiß, sondern was er meint zu wissen

Interessant! Also den Spieler erstmal machen lassen und nicht gleich "falsch!" ausgeben... dadurch würde man wohl auch das stumpfe "alles mit allem Ausprobieren" verhindern, da es nicht sofort Rückmeldung gibt. Und man kriegt wirklich das Gefühl, frei kombinieren zu können.

(Das zu programmieren ist aber eine Herausforderung: Wenn man eine früh im Spiel getroffene Annahme widerruft, ribbelt sich das ganze danach gesponnene Gedankennetz wieder auf.)

Das könnte ich mir ziemlich cool in Form einer im doppelten Sinne graphischen Repräsentation vorstellen: Das Gedankennetz als gerichteter Graph, auch visuell auf dem Bildschirm. Wenn der Spieler eine Annahme widerruft, leuchten die Folgerungen auf und werden aufgeribbelt, abgetrennt oder als "unbegründet" dargestellt. Sie müssen ja nicht per se falsch sein; könnten evtl. noch auf andere Weise begründet werden. Wenn der Spieler dagegen auf Beweise stößt, die ihn zwingen, eine der Folgerungen aufzugeben, könnte vielleicht ähnlich wie beim modus tollens die Kette entgegen der Implikationsrichtung aufgerollt werden und die Annahmen als "widerlegt" gekennzeichnet werden.

(Ich schreibe "ähnlich wie", weil ja nicht ganz klar ist, ob man Annahmen und Folgerungen hier in so einem Spielkontext als streng deduktiv betrachten kann; je nachdem, wie genau man alles repräsentiert. Das Vorhandensein von Zigarrenasche plus das Wissen, dass Onkel Eduard Zigarre raucht, legen den "Schluss" nahe, dass Onkel Eduard hier war. Aber man kann, falls man erfährt, dass Eduard definitiv nicht hier war, also dass die Folgerung falsch ist, in diesem Fall nicht plausibel den Rückschluss ziehen, dass eine dieser Annahmen falsch gewesen sein muss, also dass doch keine Asche vorlag oder dass Eduard doch kein Zigarrenraucher ist. Stattdessen wird man eher den Rückschluss ziehen können, dass eine versteckte Annahme vorhanden war, sowas wie "niemand sonst raucht Zigarre", und dass diese Annahme falsch gewesen sein muss. Daher schwierig zu modellieren. Aber wäre interessant, mal zu gucken, wie weit man so ein Interface umsetzen könnte. Wobei wir uns damit zugegebenermaßen schon deutlich aus Gruescript rausbewegen.)

Etwas Ähnliches scheint The Case of the Golden Idol zu machen, wo man Lücken im Text füllen muss.

Ah, das sieht auch cool aus, kannte ich bisher nicht; ist vorgemerkt.

StefanH:

Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948.

Dass das noch jemand kennt, wow.

Habe ich vorletztes Jahr zuletzt gespielt. Völlig abgesehen von anderen Schwächen ist dabei halt das Versäumnis, dass es zwar die detaillierte Befragung modelliert, nicht aber das daraus resultierende Wissen. Was man erfährt, bleibt nur im Kopf des Spielers (oder auch nicht).

StJohn Limbo:

Stattdessen wird man eher den Rückschluss ziehen können, dass eine versteckte Annahme vorhanden war, sowas wie "niemand sonst raucht Zigarre", und dass diese Annahme falsch gewesen sein muss. Daher schwierig zu modellieren

Oder, noch komplizierter: Vielleicht raucht wirklich niemand sonst Zigarre, aber jemand hat die Asche dort platziert, um Onkel Eduard zu belasten.

Die Variante, Schlussfolgerungen auf Basis einer unbekannten oder unbewiesenen Behauptung stehenzulassen, und eben nicht gleich wieder "aufzuribbeln", erscheint mir recht attraktiv. So würde man praktisch "Ahnungen" modellieren. Vielleicht sogar mehrere Theorien parallen, die sich widersprechen dürfen.

Warum bin ich überhaupt auf dieses Thema gekommen? Auf Basis dieser beiden Spiele erschien mir das Spieldesign in Gruescript in Richtung Wissensrätsel zu gehen. Ist es allerdings für solch komplexe Modellierungen geeignet? Meinerseits keine Ahnung, vielleicht traue ich dem System ja zu viel zu. Aber die Hoffnung stirbt bekanntlich zuletzt

Ich habe den angekündigten Artikel zu Gruescript fertig gestellt.

Es tut mir leid, dass es so lange gedauert hat. Zum Teil liegt das daran, dass ich zwei Konzeptstudien als Alternative erstellt habe. Wer bei der Hitze keine Lust hat, sich durch den langen und gedanklich etwas mäandernden Artikel zu kämpfen, kann diese Beispiele auch direkt ausprobieren:

Passage in den Tod. Variante 1 und Variante 2.

(Es ist zweimal der kurze Anfang desselben Spiels, der auf zwei unterschiedliche Arten umgesetzt wurde. Ich habe nicht darauf geachtet, ein Spiel zu entwerfen, das sich besonders für eine Gruescript-Umsetzung eignet, etwa die von Heiko erwünschten Puzzler, sondern ich habe einfach einen Anfang genommen, den ich noch irgendwo herumfliegen hatte.)

Danke für die treffende Illustration der hier bereits angedeuteten Hauptpunkte. Insbesondere die Gedanken zum Rätseldesign finde ich interessant. Allen angehenden Gruescript-Autoren möchte ich in diesem Sinne die Spiele von Arthur DiBianca ans Herz legen. Er arbeitet grundsätzlich mit sehr reduzierten Befehlssätzen. DURCHSCHIESSE KETTE MIT REVOLVER geht dann eben nicht mehr. Die Rätsel entstehen durch Timing, Zustandsänderungen usw. Gelingt manchmal besser, manchmal weniger gut.

Hannes: Allen angehenden Gruescript-Autoren möchte ich in diesem Sinne die Spiele von Arthur DiBianca ans Herz legen.

Oh, die kannte ich noch gar nicht. Ich habe mir den Temple of Shorgil mal angeschaut. Das ist ja ein reines Rätselspiel, es erinnert mch ein wenig an die Spiele von Topologika, die aber in alter Adventure-Manier verschiedene Rätsel wild vermischt haben. Etwas speziell, aber bis jetzt gefällt es mir.

So etwas lässt sich sicher gut mit der Gruescript-Philosophie umsetzen, vielleicht sogar besser als mit Text.

Martin:

Ich habe den angekündigten Artikel zu Gruescript fertig gestellt.

Danke für den Artikel und die Beispiele!

Mir gefällt Variante 1 ganz gut; sie schlägt sowohl Variante 2 als auch das Gruescript-Default-Layout.

Man könnte überlegen, ob man eine zweite Objektspalte rechts neben der bestehenden einbaut. Das Interface verlöre dann etwas an Eleganz, aber es ließen sich dafür mehr Gegenstände im Spiel unterbringen. Alternativ könnte man Bildlaufleisten zulassen -- durchs Inventar zu scrollen ist zwar lästig, aber im Prinzip macht man das in Graphikadventures ja auch.

Bei Variante 2 stört der zusätzliche Klickaufwand, ganz wie du sagst.

Was ich dort auch nicht so gut fand: dadurch, dass das "Betrachten"-Kommando wegfällt und die Beschreibungen (zum Beispiel des Kellners, der Angestellten etc.) nur noch im Popup stehen, verschwinden sie aus dem "Transkript". Die Links im Fließtext sind nicht unbedingt schlecht, aber dann würde ich bei einem Klick auf einen solchen Link vielleicht eher den Befehl "... betrachten" in die (Pseudo-)Befehlszeile einspeisen und ausführen, so dass diese Beschreibungen Teil der fortlaufenden Geschichte werden.

Von Arthur DiBianca kann ich auch "Trouble in Sector 471" empfehlen.

Es macht mir tendenziell nicht ganz so viel Spaß wie ein Spiel mit dem vollen Parser-Verbumfang (angenommen sonst gleiche Implementierungsqualität), aber man kann ganz gut sehen, was sich mit reduziertem Repertoire machen lässt, wie Hannes schon sagte.

Inhaltlich zur "Passage in den Tod": Ein cooler Anfang, der Lust auf mehr macht! Ich mag Detektivgeschichten, und das Setting ist schön gewählt. Ich kann es mir gut vorstellen: ein trister November im Paris der kleinen Leute; und dann wahrscheinlich die düsteren Machenschaften derer, die mächtig sind oder es werden wollen.

Würde mich freuen, wenn Du das Spiel weiterschreibst, sei es in Gruescript oder in einem anderen System.

StJohn Limbo: Was ich dort auch nicht so gut fand: dadurch, dass das "Betrachten"-Kommando wegfällt und die Beschreibungen (zum Beispiel des Kellners, der Angestellten etc.) nur noch im Popup stehen, verschwinden sie aus dem "Transkript".

Ja, das beißt sich mit der von mir postulierten Vorgabe, dass man den Haupttext wie ein Textadventure lesen können sollte.

Ich wollte das trotzdem einmal ausprobieren, weil ich irgendwo gelesen oder gehört hatte, dass manche Grafikadventures einen Beschreibungstext für die Hotspots bereits beim Drübermausen anzeigen, so dass man sich das Augen-Icon oder die Unterscheidung zwischen Links- und Rechtsklick spart.

(Wie gesagt, das weiß ich nur aus zweiter Hand. Dieser Text wird dann wohl nicht mit Sprachausgabe vorgelesen. Vielleicht ging es auch um ein Spiel, das sowieso keine Sprachausgabe hatte. Ich weiß es leider nicht mehr.)

Aber ja, Grafik- und Textadventures sind natürlich verschieden und ich stimme Dir zu, dass es eher nicht gelungen ist. Man kann natürlich hier nur eine ganz einfache Beschreibung anzeihen und "betrachten" als zusätzliche Option anbieten, wie es beim Foto gemacht wurde. (Dort musste ich es machen, weil die Beschreibung sehr lang ist.)

Ein cooler Anfang, der Lust auf mehr macht! [...] Würde mich freuen, wenn Du das Spiel weiterschreibst, sei es in Gruescript oder in einem anderen System.

Danke! Dieser Anfang ist ursprünglich entstanden, als ich versucht hatte, ein Spiel auf Deutsch mit Adventuron umzusetzen, was eher nicht so gut geklappt hat. Wahrscheinlich hatte ich kurz vorher einen Comic gelesen.

Das Problem ist, dass es nur Versatzstücke sind ohne eine konkrete Geschichte dahinter. Vielleicht sollte ich mir unsere Diskussion darüber, wie man Wissen in Spielen berücksichtigen kann, weiter oben hier im Thread noch einmal durchlesen ...

Wahrscheinlich hatte ich kurz vorher einen Comic gelesen.

Keinen schlichten Comic, sondern ein Meisterwerk des unvergleichlichen Tardi!

Stefan, der später auch noch was on-topic schreibt

Ach so, noch etwas:

StJohn Limbo: Man könnte überlegen, ob man eine zweite Objektspalte rechts neben der bestehenden einbaut. [...] Alternativ könnte man Bildlaufleisten zulassen [...] würde ich bei einem Klick auf einen solchen Link vielleicht eher den Befehl "... betrachten" in die (Pseudo-)Befehlszeile einspeisen [...]

Es ist wohl so, dass verschiedene Adventures verschiedene Intrfaces benötigen. Es wäre natürlich schön, wenn der Autor das ändern könnte: In einem reduzierten Interface bekommt der Text mehr Platz. In einem Spiel mit sehr vielen Gegenständen (wie zum Beispiel Detectiveland) gibt es Scrollbalken. Vielleicht gibt es sogar eine Art von Spiel, bei der die Variante mit den Pop-up-Fenstern nützlich ist, wer weiß.

Heiko: Gruescript funktioniert "Out of the Box". Wenn man das Spiel aber etwas schöner haben will, muss man sich dann doch mit CSS und Javascript auseinandersetzen.

Meiner Auffassung nach ist das Grundgerüst in Gruescript, also die Aufteilung in Textfenster und Bedienbereich und wie dort die Gegenstände und Aktionen angezeigt werden, vorgegeben. (Ich weiß es nicht genau. Dass zum Beispiel die Konversation immer in einem gesonderten Bereich über den anderen Optionen angezeigt wird, lässt mich das aber vermuten.)

Man kann dieses Gerüst zwar konfigurieren, aber wohl nur in einem bestimmten Rahmen. Beagle Rock hat ja die sprite-artigen Vignetten und bei Ich, Shub-Jagaroth gibt es das modale Fenster, in dem Tipps angezeigt werden. Aber das Layout ist in beiden Spielen mehr oder weniger gleich.

Ich könnte mir ein System vorstellen, bei dem man ein Template auswählt, das das Layout vorgibt und das bestimmt, was wo stehen soll und wie es in jedem Zug aktualisiert wird. Auf dieser Basis schreibt man dann sein Spiel.

Weil die Art des Interfaces einen Einfluss auf das Spiel hat, muss man diese Entscheidung allerdings früh festlegen. Wahrscheinlich ist es auch aufwendig, die Templates aktuell zu halten. Und wenn Autoren eigene Templates schreiben können, hat man schnell eine Sammlung mit vielen ungepflegten Templates. Naja, war nur so eine Idee.

Martin: Ich könnte mir ein System vorstellen, bei dem man ein Template auswählt, ...

Ich sehe gerade, dass Twine mit den "Story Formats" etwas Ähnliches macht. Vielleicht geht das sogar noch weiter: Jedes "Story Format" scheint eine eigene Syntax zu haben.

Martin:

Ich könnte mir ein System vorstellen, bei dem man ein Template auswählt, das das Layout vorgibt und das bestimmt, was wo stehen soll und wie es in jedem Zug aktualisiert wird.

Ich finde die Idee gut, und vielleicht gerade bei einem System wie Gruescript sehr nützlich, das einigermaßen für Einsteiger geeignet ist, und bei dem die Leute neben der eigentlichen Implementierung nicht unbedingt noch mit HTML/CSS/JS herumbasteln wollen. Und es wäre natürlich auch für fortgeschrittene Autoren sehr angenehm, nicht immer das Rad neu erfinden zu müssen.

Wahrscheinlich ist es auch aufwendig, die Templates aktuell zu halten. Und wenn Autoren eigene Templates schreiben können, hat man schnell eine Sammlung mit vielen ungepflegten Templates.

Guter Punkt, das ist schwer abzuschätzen. Gruescript ist einerseits noch in der Beta-Phase, wurde aber (wenn man auf die Git-Commits schaut) im November zuletzt aktualisiert, und davor im letzten Sommer, also scheint der momentane Stand relativ stabil zu sein.

So eine Template-Sammlung könnte ich mir gut auf Github vorstellen, mit schönen Screenshots und Links zu ausführbaren Beispielen; vielleicht als ein Repository bei einer Dachorganisation "German IF", die ja schonmal in anderen Threads angedacht wurde.