Im diesjährigen Grand Prix sind zwei der Beiträge – die beiden punktgleichen Gewinner – mit Gruescript geschrieben worden. Dieses Entwicklungssystem wurde zuvor schon in einer längeren Diskussion im IF-Forum erwähnt, in der es darum ging, wie der Stand der Entwicklungssysteme für Textadventures auf Deutsch ist.
Das Konzept von Gruescript ist, dass man klassische Textadventures im Browser auch auf mobilen Geräten ohne Tastatur spielbar machen kann, wenn man den Parser durch anklick-, beziehungsweise antippbare Optionen ersetzt. Die mit Gruescript geschriebenen Spiele versuchen wie die alten Textadventures, die Spielwelt zu modellieren. Damit setzen sie sich von den ebenfalls mobil spielbaren Multiple-Choice-Spielen ab, bei denen eher Szenen abgebildet werden.
Basis dafür ist das Modell der Spiele von Scott Adams, die Graham Nelson im Nachwort zu Craft of Adventure als „Knobelbox mit sorgfältig gefertigten Teilen“ bezeichnet. Aus dem Vorwort der Dokumentation für Gruescript:
Modern parser games are no longer limited by memory, of course, but I feel that there’s still a place, a purpose, and an audience for games in that ‘puzzlebox’ style. Writing under constraints can be an enjoyable and challenging sort of creativity in itself, like composing a haiku. And the terse prose of these games would make them perfect for a phone or tablet screen – if it weren’t for the need for the player to type.
Moderne Spiele mit Textparser haben natürlich keine Einschränkungen des Speicherplatzes mehr, aber ich denke, dass es immer noch ein Publikum für solche Knobelspiele gibt. Mit Einschränkungen zu schreiben kann eine vergnügliche und herausfordernde schöpferische Arbeit sein, wie etwa ein Haiku zu schreiben. Und mit ihren knappen Texten würden sich diese Spiele perfekt für Smartphones oder Tablets eignen – wenn der Spieler seine Eingaben nicht eintippen müsste.
Gruescript ist relativ jung, aber das Konzept hat der Autor Robin Johnson schon in früheren Spielen angewandt. Sein zweites Spiel, Detectiveland hat sogar die IFComp 2016 gewonnen. Gruescript soll lediglich das zuvor verwendete Javascript-Framework Versificator für Autoren ohne Programmierkenntnisse über eine eigene, einfache Skriptsprache zugänglich machen.
Das Demo-Spiel für Gruescript ist The Party Line, das als old-school und als minimalistisch beworben wird: Auf einer Party im Sinister Mansion sollen fünf Schätze gefunden und danach ein Fluch aufgelöst werden.
Nachdem man im ersten Zug mit knock an die Tür geklopft hat,
sieht das Spiel in meinem Desktop-Browser so aus:
Ich finde mich hier nur sehr schlecht zurecht. Es gibt mehrere Bereiche, die nur durch eine Farbnuance voneinander abgesetzt sind. Im oberen Teil, in dem man auch scrollen kann, wird der Text ausgegeben. im unteren Teil werden die Ausgänge, die Objekte im Raum und die Objekte, die der Spieler bei sich trägt, angezeigt, zusammen mit den Handlungsmöglichkeiten. Außerdem gibt es noch einen dritten Bereich am unteren Rand, der selten benötigte Steuerbefehle wie options und undo anbietet und der eigentlich nur Platz wegnimmt.
Der mittlere Bereich ändert sich natürlich in jedem Raum und mit jeder Aktion. Das wäre vielleicht nicht so schlimm, wenn die Schaltflächen für die Verben und die Ausgänge vertikal wie in einer Liste angeordnet wären, aber durch die horizontale Anordnung ist mir das zu unruhig.
Das alles wird in einer modernen Variante der 8×8-Pixel-Schriftart des Commodore 64 präsentiert. Man kann die Schriftart ändern, aber die Buttons erscheinen immer in der klobigen C64-Schrift.
Der englische Fachbegriff für diesen Stil ist, glaube ich, dog’s breakfast.
Gruescript will ja Textadventures auf mobile Geräte wie Smartphones
oder Tablets bringen. Schauen wir uns also einmal an, wie die Szene oben
auf einem Smartphone aussieht. (Ich habe hierzu die Vorschau für verschiedene
Bildschirmgrößen im Firefox benutzt und hoffe, dass die Anzeige in etwa
das wiedergibt, was auf einem iPhone oder Galaxy erscheinen würde.)
Das ist alles sehr gedrängt. Im unteren Teil des interaktiven Bereichs überlagern sich die Texte und es wird nicht alles angezeigt. Trotzdem ist Platz für die selten benutzen Metaverben. Und dieser Screenshot ist ganz am Anfang aufgenommen worden, wenn der Spieler nur eine Einladung bei sich hat. Im Verlauf des Spiels sammelt man aber sehr viele weitere Objekte, für die dann wohl erst recht kein Platz mehr ist. (Im Vorgänger Detectiveland schleppt man am Ende das ganze Gerümpel mit sich, das man beim Lösen von drei Fällen angehäuft hat.)
Das Spiel selbst ist auch nicht ideal für das mobile Spielen entworfen worden. Eines der ersten Rätsel, das man löst – und über das ich in diesem Absatz etwas verrate –, betrifft die Band. Das Rätsel wird in mehreren Schritten gelöst. In einem Schritt muss man die Musiker durcheinanderbringen und ihnen dann wieder die richtigen Instrumente zuordnen. Die Invisiclues zum Spiel, die allerdings nicht vom Autor geschrieben wurden, empfehlen, sich dazu zu notieren, welcher Musiker welches Instrument spielt. Gute Idee, aber, hey! – ich liege ja gerade gemütlich auf der Couch oder sitze in der Straßenbahn. Wenn das Spiel schon ohne Tastatur spielbar sein soll, dann auch ohne Notizen, ob auf einem Zettel oder in einer Notiz-App.
Man kann gewiss für ein paar Züge die Zuordnung der vier Namen zu den Instrumenten im Kopf behalten, aber die Mechanik, mit der das zeitabhängige Rätsel umgesetzt wurde, ist schon sehr kleinteilig und man muss außerdem noch im Blick behalten, dass man nicht zu viele Gegenstände bei sich hat. Fun, fun, fun!
Wie gesagt, Gruescript wurde von Scott Adams inspiriert, und das heißt:
I’m in a dismal swamp.
Obvious exits: North, South, East, West, Up.
I can also see: cypress tree · evil smelling mud · swamp gas · floating patch of oily slime · chiggers
Ich bin in einem trostlosen Sumpf.
Sichtbare Ausgänge: Norden, Süden, Osten, Westen, hoch.
Außerdem sehe ich: Zypresse · übel riechender Schlamm · Sumpfgas · öliger Schleimteppich · Insekten
Diese minimale Raumbeschreibung war natürlich dem knappen Speicherplatz auf den Heimcomputern der Achtziger geschuldet. Knappe Beschreibung hin oder her, damals haben viele Leute ihren Spaß mit den Spielen von Scott Adams gehabt.
Die Idee von Gruescript ist, diese reduzierte Beschreibung als Interface zu benutzen. Die Ausgänge werden zu anklickbaren Schaltflächen. Den aufgelisteten Objekten werden Buttons mit möglichen Aktionen zugeordnet: Hebel ziehen drücken
Manche Spiele machen den Namen des Objekts interaktiv und beschreiben es beim Anklicken, damit kein Platz für ein explizites untersuchen verschwendet wird.
Zusätzlich zu den Objekten und Personen am jeweiligen Ort gibt es natürlich noch die Gegenstände, die der Spieler bei sich hat, das Inventar. Der Spieler kann viele Gegenstände mit sich führen, aber immer nur einen in der Hand halten. Dieser Gegenstand ist dann aktiv und bekommt Aktionsknöpfe wie die Objekte am Ort. Je nach Art des Gegenstands können sich aber auch die Handlungsmöglichkeiten der anderen Gegenstände ändern. Nimmt man zum Beispiel einen Schraubenzieher in die Hand, taucht bei einem Lüftungsgitter vielleicht die Aktion aufschrauben auf.
Der eigentliche Text der Erzählung wird fortlaufend in einen anderen, nicht interaktiven Bereich geschrieben. Die ausgewählten Aktionen werden dabei wie in einem klassischen Textadventure nach einem Prompt ausgegeben, so als ob man die Eingabe per Tastatur gemacht hätte. Dadurch ergibt sich eine schöne Gliederung des Texts in einzelne Züge.
Soweit die gute Grundidee von Gruescript. Warum werde ich mit den Gruescript-Spielen nicht recht warm?
Ein häufig geäußerter Kritikpunkt ist, dass das Interface von Gruescript zu viel vorgibt und dem Spieler durch die explizit vorgegebenen Aktionen die Lösung eines Rätsels quasi in den Schoß gelegt wird.
Das gilt eigentlich nur für Rätsel, in denen Gegenstände nicht in ihrer Hauptfunktion angewendet werden.
Heiko Spies beschreibt in seiner Bewertung von Gruescript ein Beispiel aus Ich, Shub-Jagaroth: Man kann einen Haken an einem Schrubber befestigen und so einen Enterhaken erzeugen. Dazu gibt es beim Haken im Inventar die etwas sperrige Option mit Schrubber verbinden. Beim Schrubber gibt es die entsprechende Option auch. Bei einem Parser müsste man hier selbst auf diese Aktion kommen und hoffen, dass „verbinde Haken mit Schrubber“ oder „stecke Haken auf Schrubber“ verstanden wird. In einem Grafikadventure müsste man Haken und Schrubber miteinander kombinieren und hoffen, dass damit gemeint ist, einen Enterhaken zu bauen.
Viele Rätsel lassen sich aber schon gut umsetzen, Umgebungsrätsel zum Beispiel, in denen Aktionen eine nicht unbedingt offensichtliche Wirkung haben: Wenn man ein Fenster öffnet, ensteht ein Luftzug, der eine Kerze ausbläst oder ein Feuer anfacht. Das Myst-Genre ist voll von Hebeln, die gezogen, Knöpfen, die gedrückt und Rädchen, die gedreht werden können.
Schon in Adventureland von Scott Adams gab es viele Rätsel, bei denen es nicht auf die eine Aktion ankam, sondern auf das Zusammenspiel der verschiedenen Objekte: Zum Beispiel lassen einen die Insekten in Ruhe, wenn Schlamm in der Nähe ist. Man kann den Schlamm mitnehmen, muss ihn aber feucht halten und der Drache reagiert sehr empfindlich auf den Geruch des Schlamms.
Codes und Passwörter können auf verschiedene Weise in Gruescript umgesetzt werden: Für das Passwort und den Enigma-Code im Geheimnis von Beagle’s Rock hat Michael Baltes für (fast) jede Taste einen Aktionsknopf erzeugt. Der Safe in Ich, Shub Jagorath bietet einem eine Handvoll zufällig erzeugter Codes an. Erst, wenn man alle Elemente der Zahl kennt, wird einem auch die richtige Kombination angeboten. Das ist eine elegante Lösung, die aber nur dann funktioniert, wenn man die einzelnen Bestandteile des Codes nicht noch in einem letzten Schritt zusammenfügen muss.
Als Autor muss man die Rätsel auswählen, die zum System passen. Genug Auswahl gibt es.
Ein viel größeres Problem ist meiner Meinung nach das schlechte Layout der Spiele.
Weil der Aktionsbereich, in dem sich die interaktiven Schaltflächen befinden, nicht in der Nähe der letzten Ausgabe ist, richtet man sein Augenmerk eher auf den Aktionsbereich und liest die Texte im Ausgabebereich nicht richtig. Mir jedenfalls geht das so.
Dem gegenüber steht das klassische Modell der Textadventures: Eingabe und Ausgabe wechseln sich ab, so dass was gerade ausgegeben wurde immer im direkten Zusammenhang mit der Ausgabe steht. (Das ist auch das Modell von interaktiven Shells und Notebook-Interfaces wie Jupyter. und Mathematica.)
Die folgenden
Eye-Tracking-Daten
sind komplett ausgedacht, geben aber meine Erfahrung mit den beiden Varianten
von Gruescript wieder:
Der wichtigste Text ist der, der zuletzt ausgegeben wurde. In Gruescript überfliegt man diesen Text, aber das Augenmerk ist auf das Interface gerichtet. Das ist verständlich, weil sich ja auch dort unter Umständen etwas ändert: eine neue Situation wird beschrieben oder ein Objekt bekommt eine neue Handlungsmöglichkeit.
Bei einem Textadveture mit Parser tritt das „Interface“, eigentlich ja nur eine Eingabezeile, in den Hintergrund. Der neue Text steht so im Vordergrund und bekommt die Aufmerksamkeit des Spielers.
(Es ist natürlich auch nützlich, dass das eigentliche Interface hier nicht explizit grafisch umgesetzt wird, sondern im Kopf des Spielers ist. Man muss also nicht mit den Augen zwischen Text und Interface hin- und herspringen. Der Nachteil dieses impliziten Interfaces ist natürlich, dass es zu nicht erkannten Eingaben und zu guess the verb kommen kann.)
Ein weiteres Problem bei Gruescript ist, dass besonders im Hochformat die einzelnen Bereiche nicht deutlich genug voneinander getrennt sind und dass der Steuerbereich sehr ungeordnet ist. Wenn sich etwas ändert, etwa weil ein Gegenstand auftaucht oder eine neue Option bekommt, verschiebt sich oft das gesamte Layout des Steuerbereichs.
Gruescript nutzt den Webbrowser als Plattform und hat damit HTML und CSS zur Gestaltung zur Verfügung. In den letzten fünfzehn Jahren oder so haben sich diese Auszeichnungssprachen sehr stark weiterentwickelt. Single-page applications, also Webseiten, die eigentlich wie eine Anwendung auf einem Desktop oder einem mobilen Gerät sind, sind sehr verbreitet. Es muss doch möglich sein, Interface und Erzählfenster besser zu integrieren, so dass sich das Look-and-feel der alten Textadventures erreichen lässt.
Es gibt zwei Ortsbeschreibungen in Gruescript: die Beschreibung im Hauptbereich und die Beschreibung im Bedienbereich, in der die Schaltflächen für Personen und Objekte mit ihren Aktionen sind.
Die Beschreibung im Hauptbereich ist eigentlich nur der mehr oder weniger statische Beschreibungstext des Orts. Die Gegenstände und die Personen im Raum werden nicht ausgegeben. Man kann das in den Einstellungen ändern, aber dann wird alles, was im Raum ist, in eine generische Liste am Ende gepackt: „Große Portraits säumen die Wände. Du siehst hier Dani, Portraits, einen Klamottenberg und einen Schrubber.“
Der Spieler hat also die Auswahl zwischen unvollständigen Texten, die den Ort zwar allgemein, aber nicht in seinem jetzigen Zustand beschreiben, und Texten mit oft redundanten Aufzählungen. Ich verstehe den Wunsch, mit dem unter Umständen knappen Platz hauszuhalten, aber ich fände es gut, wenn im Hauptbereich, in dem ja die Geschichte so ausgegeben wird, als ob man ein Textadventure spielt, eine klassische Beschreibung käme:
Provisorische Garderobe
Dieser Empfangsraum wurde kurzerhand zu einer Garderobe umfunktioniert. Große Portraits säumen die Wände.Gelangweilt bewacht Dani einen Berg wahllos hier abgelegter Klamotten.
Außerdem siehst du hier einen Schrubber
Das erzeugt natürlich eine Redundanz zur zweiten Ortsbeschreibung, die ja als Interface dient. Vielleicht kann man diese Redundanz auf Kosten des Interfaces umgehen?
Ich denke, dass die Grundidee von Gruescript nicht schlecht ist, aber mir gefällt die Trennung der Raumbeschreibung mit Interface vom Textfenster nicht.
Ich habe einmal ein kleines Beispiel in zwei verschiedenen Varianten umgesetzt. Das Beispiel ist der Anfang eines Krimis, der vielleicht gar nich so gut für dieses System geeignet ist. Das einzige Gegenstandsrätsel lässt sich nicht lösen.
Die erste Variante ist sehr nahe am ursprünglichen Gruescript, allerdings wird das Interface als vertikale Liste umgesetzt. Ich finde, solche Listen lassen sich besser lesen und überfliegen als die Listen mit horizontal angeordneten Schaltflächen.
Das Interface befindet sich in einer eigenen Spalte unten rechts, wenn genug Platz dafür ist, oder in drei Spalten unterhalb der Eingabe im Hochformat. Dadurch soll das knappe Interface nahe an den zuletzt ausgegebenen Texten stehen.
Eine weitere Änderung gibt es: So wie man immer nur einen Gegenstand in der Hand halten kann, ist auch immer nur ein Gegenstand im Raum aktiv. Nur zu diesem Gegenstand werden Aktionen angeboten.
Im Browser spielen: Passage in den Tod (Variante 1)
Ich bin mit dieser Variante ganz zufrieden. Man muss als Autor aber aufpassen, dass man die Bezeichnungen für Objekte und Aktionen knapp hält, damit sie in die Spalte passen. Außerdem eignet sich das Inteface nicht für Spiele, bei denen man viele Gegenstände mit sich schleppt.
Die zweite Variante benutzt Pop-up-Fenster, in denen dann zu jedem Objekt eine kurze Beschreibung und die möglichen Aktionen stehen. Die Links, mit denen diese Fenster geöffnet werden, stehen direkt im Haupttext.
Für das Inventar gibt es eine besondere Auswahl, mit der man einen Gegenstand in die Hand nehmen kann. Zu diesem Gegenstand kann man sich dann in einem Pop-up Aktionen anzeigen lassen.
Im Browser spielen: Passage in den Tod (Variante 2)
Ich hatte mir von dieser Variante einiges versprochen, bin aber enttäuscht. Es ist schon viel Herumgeklicke, insbesondere, wenn man einen Gegenstand erst in die Hand nehmen muss, um ihn anzuwenden.
Vielleicht muss man das Inventar anders gestalten, so dass die Gegenstände alle sichtbar sind. Dann würde aber die besondere Bedeutung des einen Gegenstands, den man in der Hand hält, wegfallen. Ich finde diese Unterscheidung aber gut: Zum Gegenstand, den ich in der Hand halte und zum aktiven Gegenstand am Ort werden mir auch die möglichen Aktionen angezeigt, die beide Gegenstände gemeinsam betreffen. Das ist wie ein „benutze X mit Y“, bei dem mir explizit gesagt wird, was „benutze“ genau bedeutet.
Etwas unglücklich ist auch, dass die Links zur Fortbewegung direkt funktionieren, die Links für die Objekte über das Pop-up-Fenster. Wenn man für die Richtungen auch ein Pop-up verwenden würde, müsste man aber noch mehr klicken. Durch die vielen Links sind die Texte (wie in einem Wikipedia-Artikel) etwas unruhig.
Vielleicht eignet sich diese Variante aber für ein Spiel, bei dem man Objekte manipuliert, die man nicht bei sich tragen muss oder bei dem es mehr auf das Wissen über bestimmte Dinge ankommt als auf die Gegenstände selbst.
Gruescript hat den interessanten Ansatz, eine an die Klassiker von Scott Adems angelehnte, stichpunktartige Ortsbeschreibung als grafisches Interface zu nutzen, das einen Textparser ersetzt. Spiele, die mit diesem System geschrieben werden liegen zwischen den beiden Extremen, dem klassischen Textadventure, dessen Grundlage meist Orte und Objekte sind, auf der einen Seite und dem Multiple-Choice-Adventure, das sich eher an Szenen und Personen orientiert, auf der anderen.
Ich finde die Idee gut, mich stört allerdings die Umsetzung, die nicht nur mit den skeletthaften Beschreibungen, sondern auch mit der äußeren Gestaltung voll auf die Retro-Karte setzt.
Ich habe zwei Varianten des Interfaces geschrieben, die die Idee von Gruescript beibehalten, die aber ein ansprechenderes Layout haben. Diese Varianten sind gewiss nicht rundum gelungen, aber mir gefallen sie besser als die mit Gruescript geschriebenen Spiele.
Passage in den Tod