Designrichtlinien

Mit den Möglichkeiten eines aktuellen Textadventure-Entwicklungssystems ein kurzes Spiel auf die Beine zu stellen ist relativ einfach, insbesondere da dazu keine weiteren Fähigkeiten außer der reinen Programmierung nötig sind. Ein Spiel erstellen zu können muss allerdings noch lange nicht heissen, dass es dabei auch tatsächlich gut wird. Wie auch bei jeder anderen Art von Computerspielen muss das Design eines Textadventures gut durchdacht werden und alle seine Elemente müssen fliessend zusammenarbeiten, um dem Spieler ein fesselndes Spieleerlebnis bieten zu können.

Eine gute Ausdrucksfähigkeit kommt dem Spiel natürlich zugute, ist aber meisstens eher nebensächlich. Erfahrungsgemäss sind Spieler viel eher bereit, einen schlechten Umgang mit Prosa zu verzeihen als konzeptionelle Fehler zu ignorieren. Es ist naheliegend: Was die Grafik für ein Grafikadventure ist, ist der Text für ein Textadventure. Auch die schönste Grafik allein macht kein gutes Spiel, wenn die Bedienung zu umständlich ist oder man permanent dazu angehalten wird Dinge zu tun, auf die man beim ersten mal schon keine Lust hatte. Andererseits kann eine gute Grafik - und analog dazu gute Prosa - durchaus dazu gereichen, ein Spiel mit einem stimmigen und gut funktionierenden Konzept aus der Masse der übrigen Spiele herauszuheben. Im folgenden werde ich einige Punkte ansprechen, auf die man meiner Meinung nach insbesondere beim Design von Textadventures achten sollte.

Zwischensequenzen

Der Einsatz von Zwischensequenzen erscheint naheliegend, vor allem wenn man versucht, eine dichte Story zu übermitteln. Diese Mentalität entspringt vermutlich zum Teil aus Erfahrungen mit aktuellen 3D-Spielen, in denen die Storyelemente häufig in filmartigen Sequenzen ohne Interaktionsmöglichkeiten erzählt werden. Dabei wird aber leider ausser Acht gelassen, dass es sich im Rest dieser Spiele zumeinst um völlig andere, viel straffere Spielkonzepte handelt, als sie im durchschnittlichen Textadventure reproduziert werden könnten.

In einem modernen Egoshooter sind die Zwischensequenzen eine Gelegenheit sich kurz von dem ganzen Gerenne und Geschiesse zuvor zu erholen und gleichzeitig mit einem weiteren Teil der Story belohnt zu werden. Bei einem Textadventure geht dieses Prinzip nicht auf. Dort entfaltet sich die Sequenz nicht fließend wie ein Film sondern brachial wie ein gewaltiger Block Text, der plötzlich auf dem Bildschirm erscheint und den Spieler ersteinmal einschüchtert: «Ohje, DAS muss ich mir jetzt alles durchlesen?».

Es besteht natürlich die Möglichkeit, diesen Effekt bedeutend abzuschwächen, indem man die Sequenz beispielsweise in mehrere kleine Häppchen unterteilt, die der Spieler immer erst durch das Drücken einer Taste bestätigen muss, um den nächsten Abschnitt angezeigt zu bekommen. Das funktioniert natürlich und wird auch häufig in Textadventures eingesetzt.

Ich wage jedoch zu behaupten, dass das stupide drücken einer Taste kein besonders gutes Designelement für ein Spiel darstellt. Das Genre heisst nicht umsonst «Interactive Fiction» und nicht «Push-A-Button Fiction». Derartige Sequenzen sind in einer eher statischen Form der Prosa wie beispielsweise einem Buch gut aufgehoben, haben in einem Textadventure nichts zu suchen.

Eine wesentlich bessere Lösung ist es, den Spieler die Sequenz ausspielen zu lassen. Anstatt einen automatisch ablaufenden Dialog ablaufen zu lassen könnte man den Spieler die Informationen von seinem virtuellen Gegenüber interaktiv erfragen lassen. Anstatt den Spieler in letzter Sekunde einer gefährlichen Situation automatisch entkommen zu lassen könnte man sich die Sequenz rundenweise entfalten lassen, wärhend der Spieler auf jedes neu aufkommende Problem passend reagieren muss, um zu überleben. Dies bedeutet für den Autor natürlich einen wesentlich größeren Programmieraufwand, der es allerdings absolut wert ist. Seine Spieler werden es ihm danken. Vor der möglichen Konsequenz des Spielertodes sollte man als Autor an dieser Stelle auch nicht unbedingt zurückschrecken, was uns zum nächsten Punkt bringt:

Tod und Auferstehung

In der frühen Zeit der Textadventures war der Spielertod ein Element, das man an jeder Ecke der Spielwelt angetroffen hat. Oft war die Konsequenz des Ablebens anhand der auslösenden Handlung noch nicht einmal nachvollziehbar. Wenn man beispielsweise auf einem Waldweg die linke anstatt der rechten Abzweigung nahm, so war es durchaus möglich, auf der Stelle zu sterben weil dort ein menschenfressendes Monster gelauert hat, welches man vorher nicht bemerkt hat. Eine solche Spielwelt zu erkunden konnte also mitunter recht frustrierend werden.

Dies führte in späteren Text- und Grafikadventures dann dazu, dass es überhaupt nicht mehr möglich war zu sterben. Aufgrund der eingeschränkten Interaktionsmöglichkeiten in Grafikadventures ist dies ein durchaus vertretbares Konzept, greift in Textadventures aber nur bedingt. Es gibt dort einfach keinen wirklich unbestreitbaren Grund, dem Spieler Aktionen zu verweigern, die seie Spielfigur eigentlich auszuführen in der Lage sein müsste. Der Befehl, jetzt bitteschön in den Abrund zu springen, sollte also auch zu eben dieser Aktion und dem Spielertod als logischer Konsequenz führen, anstatt eine sinnfreie Ablehnung wie «Ich will nicht.» anzuzeigen. Es besteht absolut keine Notwendigkeit, den Spieler krampfhaft am Leben zu halten, wenn er sich bewusst in eine offensichtlich lebensbedrohliche Situation begibt.

Auf unvorhersehbare Tode sollte man allerdings tatsächlich verzichten, da diese wirklich nur Frustration schüren und so gut wie nie positiv von Spielern aufgenommen werden. Bei Toden, die zwar bei näherem betrachten logisch, auf den ersten Blick aber nicht unbedingt offensichtlich sind, gibt es mehrere Möglichkeiten: Man sollte dem Spieler entweder eine oder mehrere Runden Zeit geben, sich der Situation wieder zu entziehen oder man sollte vorher zumindest einmal und offensichtlich darauf hinweisen, dass gewisse Handlungen an dieser Stelle der Gesundheit abträglich sein könnten. Bei einer Luftschleuse, die ins Vakuum des Alls führt, könnte man in der Beschreibung etwa erwähnen, dass sich dahinter Luftleerer Raum befindet in dem Atmen schwierig wird. Alternativ könnte man den Spieler die Schleuse öffnen lassen, worauf die Luft aus dem Raum entweicht, aber erst nach 3 Runden vollkommen leer ist und zum Tod führt. Zeit genug, die Schleuse wieder zu schliessen, so man keinen Selbstmord begehen will.

Sollte auf diese Weise doch einmal der Tod eingetreten sein, so ist dies im Normalfall auch kein Beinbruch. Die meissten Textadventure-Systeme stellen standartmässig die Möglichkeit zur Verfügung, die letzte Runde ungeschehen zu machen. Dies rettet den Spieler zwar nicht aus schon längere Zeit ausweglosen Situationen, aber man kann eine einzelne Fehlentscheidung auf diese Weise rückgängig machen und stattdessen etwas anderes probieren. Dies ist eine elegante Interaktionsmöglichkeit, die es dem Spieler auch erlaubt etwas herumzuexperimentieren, ohne gleich fürchten zu müssen das Spiel zu verlieren. Diese Option sollte man als Autor definitiv in seinem Spielekonzept berücksichtigen und damit arbeiten, es sei denn sie behindert das restliche Konzept. In dem Fall sollte man es besser komplett deaktivieren und am Anfang des Spieles oder in den Hilfe-Ausgaben darauf hinweisen, um den Spieler gar nicht erst in falscher Sicherheit zu wiegen.

Im Rahmen der Story und des Spielkonzepts gibt es natürlich noch viele weitere Möglichkeiten, den Spieler sterben oder auferstehen zu lassen. Diese müssen dann aber von den jeweiligen Autore explizit einprogrammiert werden und deren Regeln müssen entsprechend individuell von Spiel zu Spiel betrachtet werden. Ein hervorragendes Beispiel hierfür ist das Spiel «Shrapnel» von Adam Cadre, in dem die Fähigkeit des Spielers zu sterben und wieder aufzuerstehen integral notwendig zum erreichen des Spielziels ist.

Beschreibungen

Beschreibungen von Gegenständen und Räumen sind ein sehr zentraler Aspekt von Textadventures. Entsprechend wichtig ist es demnach, sie ordentlich darzustellen. Schlechte Beschreibungen gibt es leider wie Sand am Meer, gute muss man aber oft mit der Lupe suchen. Im allgemeinen sollte man auf Formulierungen wie «Du stehst in …» oder «Dies ist der Raum XY» besser verzichten. Beides ist über alle Maßen offensichtlich und trägt nichts zur Aussage des Textes bei. Die allgemeine Beschreibung eines Raumes sollte vielmehr versuchen, die Atmosphäre einzufangen. Eine simple Auflistung aller Einrichtungsgegenstände erfüllt diesen Zweck meisstens nicht sehr gut, weshalb Autoren sich ruhig auch etwas poetisch angehauchtere Formulierungen ausdenken können. Man hat zum Beispiel eine ziemlich gute Vorstellung davon, wie das Büro eines heruntergekommenen Privatdetektivs der 60er Jahre beschrieben werden sollte. Dies muss man nur noch auf andere Räume übertragen und schon hat man ein «Feeling» für die Beschreibung von Räumen.

Gegenstände, mit denen der Spieler interagieren soll oder die auf andere Weise wichtig für die Spielwelt oder die Story sind, sollten gesondert von der Hauptbeschreibung des Raumes erwähnt werden. Die «initial»-Routine von Objekten in Inform 6 wäre dazu beispielsweise der richtige Ort. Bei alltäglichen Gegenständen, deren Aussehen oder Zweck im Raum offensichtlich ist, kann man sich diese Beschreibungen ganz sparen und sie nur zusammengefasst in einem einzigen Satz erwähnen lassen. Die meissten Entwicklungssysteme tun dies automatisch, wenn man keine spezielle Beschreibung hinterlegt hat.

Allgemein sollte man als Autor bei der Raumbeschreibung Zurückhaltung üben. Eine solche Beschreibung überfliegt den Raum schliesslich nur auf den ersten Blick. Details zu jedem Gegenstand kann sich der Spieler auf Wunsch durch näheres Untersuchen beschaffen. Dies trägt sehr zur Spieltiefe bei, da der Spieler das Gefühl bekommt, die Welt wirklich zu entdecken anstatt sie nur vorgesetzt zu bekommen. Ein netter Nebeneffekt ist natürlich auch, dass Raumbeschreibungen auf diese Art kurz und Übersichtlich gehalten werden. Auch hier gilt: In der Kürze liegt die Würze!

Rätsel

Rätsel sollten sich immer in die Szene einpassen um nicht künstlich zu wirken. Nichts ist schlimmer für einen Spieler als in einer spannenden Atmosphäre plötzlich dazu genötigt zu werden, irgendein zusammenhangloses Logikpuzzle zu lösen, um mit der Geschichte fortfahren zu dürfen. Der Spieler wird zu etwas gezwungen, woran er nicht interessiert ist und was er möglicherweise noch nicht einmal so ohne weiteres bewältigen kann. Diese Form von Rätsel sollte man auf jeden Fall vermeiden.

Darüber hinaus können die Rätsel so einfach oder komplex werden wie man möchte. Soll das Spiel schwierig oder Rätsellastig werden dann baut man lange und komplexe Rätsel ein, andernfalls eben einfache und kurze.

Man sollte nur auf zwei Punkte achten: selbst wenn sie nur sehr einfach sind müssen auf jeden Fall Rätsel eingebaut werden, damit das Spiel nicht langweilig wird. Desweiteren sollte man Konzepte für komplexe Rätsel nicht überstrapazieren. So mach es z.B. keinen Sinn, ein Rätsel einzubauen, bei dem man mit 20 Handgriffen eine Kaffeemaschine reparieren muss. Da sollte man sich schon etwas besseres einfallen lassen.

Dialoge

Grundlegend gibt es zwei Möglichkeiten, ein Dialogsystem zu implementieren: Fragen- oder Menübasiert. Dazu kommen natürlich noch die verschiedensten Mischformen der zwei. Bei der Fragen-basierten Variante wird jede Dialog-Sequenz durch eine explizite Frage oder Aussage des Spielers der Form «Frag den Lehrer nach dem Buch» oder «Erzähl dem Lehrer von dem Buch» ausgelöst. Dies hat den Vorteil dass es sich gut in den Spielfluss integrieren lässt, aber den Nachteil, dass der Spieler oft nicht weiss, was er nun alles fragen oder sagen kann. Das kann zu frustrierendem Herumprobieren führen.

Bei der zweiten Alternative wird häufig das Dialogsystem über eine Aufforderung der Art «Sprich mit dem Lehrer» aufgerufen und die eigentliche Frage oder Aussage dann aus einem Menü ausgewählt. Vortelhaft ist dabei vor allem, dass der Spieler immer weiß was er sagen kann und keine Möglichkeit übersieht. Nachteilig ist vor allem dass es unter Umständen sehr künstlich anmutet und der Spieler nicht das Gefühl hat, den Dialog wirklich durch eigenen Willen zu lenken.

Letztendlich ist die Wahl wieder eine Frage des eigenen Geschmacks. Ich persönlich bevorzuge die Fragen-Variante, allerdings solle man dann stets deutlich darauf hinweisen, was mögliche Gesprächsthemen sind.

Quips und Beats

Die Konzepte sind eigentlich offensichtlich, aber jedes Kind braucht eben einen Namen. Bei Quips handelt es sich dabei lediglich um die einzelnen Dialogpassagen, die durch einen Aufruf des Systems (Frage oder Menüpunkt, s.o.) Sie sind das gängige Mittel um längere Dialoge thematisch in kleine Häppchen zu unterteilen, die von dem Spieler leichter überblickt werden können.

Beats hingegen repräsentieren sozusagen den Herzschlag, in dem sich die Welt ein Stück weiter bewegt. Für gewöhnlich löst jede Spieleraktion einen Beat aus um zu simulieren, dass während der Spieler etwas tut der Rest der Welt auch nicht untätig bleibt.

In besonderen Situationen kann es allerdings wünschenswert sein, dass eine Aktion keinen Beat auslöst oder vielleicht sogar mehrere. Beispielsweise wären Situationen denkbar die sehr zeitkritisch sind und in denen look und examine keinen Beat auslösen sollen, schon allein um zu verhindern dass der Spieler nach jeder dieser Aktionen freiwillig ein undo eingibt um keine wertvolle Zeit zu verlieren.

Besonders lange Aktionen könnten über ihren Verlauf hinweg mehrere Beats auslösen oder in einer Konversation können mehrere ausgelöst werden um den Gesprächsteilnehmer die Möglichkeit zu geben, über ein automatisiertes Script-System eigene Kommentare abzugeben. Dies würde dann in begrenztem Rahmen sogar eine Konversation mit mehreren Personen gleichzeitig erlauben.