alphabreed

Tipps für Einsteiger

Zum Spielen von Interactive Fiction sind einige Grundlagen erforderlich. Diese will ich hier ein wenig beleuchten.

Spiele downloaden

Wenn man sich entschlossen hat, sich mit Interactive Fiction auseinander zu setzen, benötigt man sinnvollerweise zuallererst ein Spiel. Das Interactive Fiction Archive stellt eine große Auswahl von Spielen zum freien Download zur Verfügung, allerdings ist es dort etwas unübersichtlich und genauere Informationen zu den Spielen erhält man dort auch nicht. Als Entscheidungshilfe kann an dieser Stelle Baf's Guide to the IF Archive dienen. Dort kann man die Spiele nicht nur komfortabel nach verschiedenen Kriterien durchsuchen sondern sich auch kurze Reviews zu jedem Spiel durchlesen. Der Guide verlinkt direkt auf das IF-Archive für die Downloads der Spiele und zeigt auf, in welchem Format sie vorliegen.

Starten der Spiele

Hat man nun das Spiel der Wahl heruntergeladen dann steht man in den meissten Fällen vor dem Problem, dass es nicht in einer direkt ausführbaren Form (z.B. .exe-Datei) sondern als Story-Datei vorliegt. Für solche Spiele benötigt man einen passenden Interpreter, ein Programm welches in der Lage ist, das Spiel abzuspielen. Welchen Interpreter man für ein bestimmtes Spiel benötigt kann man entweder den beigefügten Informationen (z.B. Readme-Datei oder Baf's Guide) entnehmen oder man muss sie recherchieren. Als Anhaltspunkt kann folgende Liste der gängisgsten Dateinamens-Suffixen von Story-Dateien dienen:

Suffix Story-Format
.a3c, .acd Alan
.agx AGT
.cbm Quill
.d$$, .da1, .da2, .da3, .da4, .da5, .ttl AGT (werden alle benötigt!)
.gam TADS
.gblorb, .glb Glulx (In Bundle verpackt)
.gfx Magnetic Scrolls (Grafik-Datei, optional)
.hex Hugo
.mag Magnetic Scrolls
.t3 TADS
.taf Adrift
.tag T.A.G.
.ulx Glulx
.z3, .z4, .z5, .z6, .z8 Z-code
.zblorb, .zlb Z-code (In Bundle verpackt)

Weiss man aber erstmal in welchem Format das Spiel vorliegt dann kann man sich einfach einen passenden Interpreter aussuchen. Hier zwei Multitalente, die beide ein großes Spektrum der gängigen Story-Formate abdecken:

Gargoyle (Windows, Linux)
Unterstütze Story-Formate:
AGT, Alan, Z-code, Glulx, Hugo, Level 9, Magnetic Scrolls, Adrift, TADS

Spatterlight (Mac OS X)
Unterstütze Story-Formate:
AGT, Adrift, AdvSys, Alan, Glulx, Hugo, Level 9, Magnetic Scrolls, TADS, Quill, Z-code

Natürlich gibt es noch wesentlich mehr Interpreter mit den verschiedensten Eigenschaften und und darüber hinaus noch viel mehr Autorensysteme mit den unterschiedlichsten Datei-Formaten.

In der Regel ist es allerdings eine gute Idee, sich einen der multifunktionalen Interpreter wie diese beiden zu besorgen. Wenn man kein allzu exotisches Spiel spielen will können sie es mit recht hoher Wahrschenlichkeit ausführen.

Der größte Nachteil dieser Interpreter ist allerdings, dass sie Spezialfähigkeitden der einzelnen Systeme wie z.B. Grafiken häufig nicht unterstützen. In solchen Fällen benötigt man dann doch einen spezialisierten Interpreter und sollte sich einfach mal im IF-Archive umsehen.

Erste Schritte

Die erste Herausforderung eines neuen Spielers in einem Textadventure ist die Bewegung. Standardmäßig wird dies der Einfachheit halber über die Himmelsrichtungen sowie ein Paar weitere Spezialfälle geregelt. Da die Bewegung ein integraler Bestandteil so gut wie jedes Textadventures ist, gibt es für alle Bewegungsrichtungen auch Abkürzungen. Richtungen und Abkürzungen können der folgenden Tabelle entnommen werden:

Richtung Kommando
Norden bzw. Vorne north/n
Süden bzw. Hinten south/s
Westen bzw. Links west/w
Osten bzw. Rechts east/e
Nordwesten bzw. Vorne-Links northwest/nw
Nordosten bzw. Vorne-Rechts northeast/ne
Südwesten bzw. Hinten-Links southwest/sw
Südosten bzw. Hinten-Rechts southeast/se
Oben up/u
Unten down/d
Hinein in
Heraus out

Die Orienterung anhand von Himmelsrichtungen mag auf den ersten Blick etwas seltsam anmuten, denn wer läuft schon permanent mit einem Kompass durch die Gegend? Bei näherer Betrachtung macht es aber durchaus Sinn, wenn man bedenkt, dass es sich dabei nur um ein Hilfsmittel handelt um eine allgemeingültige Form der Orientierung zu implementieren. Es ist also nicht wichtig dass man bei «north» auch wirklich nach Norden geht, sondern dass man in die gleiche Richtung geht, egal ob man den Raum von Links oder Rechts betreten hat. Die Kommandos "links" und "rechts" wären dafür nicht geeignet, da es sich dabei um eine Richtung handelt, die abängig von der derzeitigen Blickrichtung des Spielers ist.

Natürlich kann man in Textadventures nicht nur durch die Gegend laufen sondern kann auch mit ihr interagieren, z.B. Dinge aufheben oder Knöpfe drücken. Dazu gibt es eine recht lange Liste von Kommandos die bei Kenntnis der englischen Sprache eigentlich weitesgehend selbsterklärend sind. Hier ein kleiner Auszug der gängisgsten:

Kommando Tätigkeit
inventory/i Gegenstände im Inventar auflisten
look/l Im Raum umschauen / Raumbeschreibung anzeigen lassen
examine/x Name Einen Gegenstand genauer untersuchen
wait/z Eine Runde warten / Keine Aktion ausführen
take/get Name Einen Gegenstand in Reichweite mitnehmen
put Name in/on Ort Einen Gegenstand aus dem Inventar an einen anderen Ort legen
drop Name Einen Gegenstand aus dem Inventar fallen lassen
push Name Einen Gegenstand drücken oder schieben
pull Name An einem Gegenstand ziehen
open Name Einen Gegenstand öffnen, falls möglich
close Name Einen Gegenstand schließen, falls möglich
hit/attack Name Einen Gegenstand oder eine Person angreifen
talk to Name Eine Person ansprechen
ask Name about Thema Eine Person nach einem bestimmten Thema fragen
tell Name of/about Thema Einer Person etwas über ein bestimmtes Thema erzählen

Dies sind natürlich bei weitem nicht alle Befehle eines Standard-Textadventures, vor allem da jeder Autor sein Spiel beliebig um neue Kommandos erweitern kann, aber sie geben vielleicht einen ungefähren Eindruck davon, was alles möglich ist. Bei den ersten vier Einträgen der Tabelle handelt es sich um sehr häufig gebrauchte Kommados, weshalb die wie auch schon die Bewegungsrichtungen über Abkürzungen verfügen.

Die Welt verstehen

Kann man sich erstmal bewegen hat man die schwierigste Hürde eigentlich schon überwunden. Vermutlich hat man die grundlegenden Konzepte der Anzeige auch bereits begriffen, aber hier nocheinmal in aller Kürze:

Die Spielwelt ist in Bereiche aufgeteilt, die «Räume» genannt werden. Dabei muss es sich nicht zwingend um tatsächliche Räume in einem Gebäude handeln, sondern es sind auch andere Orte wie z.B. ein Seeufer als virtueller «Raum» denkbar.

Wenn man einen Raum betritt wird die Beschreibung des Raumes ausgegeben. Diese beinhaltet das allgemeine Aussehen des Raumes, seine prominenten Einrichtungsgegenstände (Tische, Schränke, usw.) sowie die Türen oder anderweitige Passagen, die aus ihm hinaus in andere Räume führen. Letzteres wird manchmal auch vergessen, jedoch handelt es sich dann in den meissten Fällen um einen Designfehler des Autors. Man kann sich die Beschreibung des Raumes, in dem man sich befindet, mittels des look-Kommandos jederzeit erneut anzeigen lassen.

Mit den meisten Dingen, die in der Raumbeschreibung erwähnt werden, kann man daraufhin interagieren. Das wichtigste Hilfsmittel ist dabei das examine-Kommando. Mit seiner Hilfe kann man sich genauere Informationen zu den Gegenständen beschaffen und unter Umständen auf diese Weise sogar noch mehr Gegenstände entdecken. Ein wichtiges Buch wird so vielleicht nur erwähnt (und so für den Spieler existent) nachdem er ein Bücherregal genauer untersucht hat.

Nachdem man sich durch Umsehen und Untersuchen ein gutes Bild von seiner Umgebung gemacht hat, kann man anfangen sie zu verändern, Dinge mitzunehmen, Schränke zu öffnen und Knöpfe zu drücken. Hier ist der Einfallsreichtum des Spielers gefragt, um die Rätsel zu lösen, die der Autor für ihn ausgestreut hat.

Von allzu todesmutigen Taten sollte man vielleicht besser absehen, denn im Gegensatz zu den meissten neueren Point & Klick Adventures kann man in vielen Textadventures durchaus sterben. Normalerweise ist das kein großes Problem und kann sofort korrigiert werden, indem man den letzten Zug ungeschehen macht. Dennoch sollte man vorsichtig sein.

Fazit

Im allgemeinen lassen sich alle Tipps eines Grafikadventures auch auf ein Textadventure übertragen: Untersuche alles, sprich mit jedem, nimm alles mit was du finden kannst und kombiniere es wenn angebracht mit allen neuen Gegenständen.

Das sollte an Tipps ausreichen um euch auf den Weg zu bringen. Nun gehet hin und spielt ein paar Textadventures!

Autorensysteme

Es gibt heutzutage die verschiedensten Hilfsmittel um Textadventures zu erstellen. Sie reichen von einfachen Compilern bis hin zu aufwändigen integrierten Entwicklungsumgebungen. Nachfolgend möchte ich eine kleine Auswahl davon vorstellen. Von den reinen Fähigkeiten her haben die meisten dieser Autorensysteme selten klare Vorteile gegenüber anderen, was die Wahl eines Systems im Allgemeinen zu einer Frage der persönlichen Vorlieben macht.

Inform 7

Inform 7 besitzt eine integrierte Entwicklungsumgebung (IDE), die die Erstellung des Programmcodes stark vereinfacht. Der Code selber besitzt eine Sprachsyntax, die an die englische Umgangssprache angelehnt und so unter Umständen etwas eingänglicher für Nicht-Programmierer ist. Diese Syntax ist auf dem älteren Inform 6 Code aufgesetzt und produziert als Ausgabe wahlweise die verschiedenen Z-code-Formate oder das neuere Glulx-Format. Inform 7 ist ein sehr gutes Autorensystem und vereint in sich alles was man benötigt um ein Textadventure zu programmieren. Das System lässt sich sehr einfach mit Plugins für spezielle Anwendungen erweitern. Für Programmierer ist die ungewöhnliche umgangssprachliche Syntax stark gewöhnungsbedürftig, aber nach einer gewissen Eingewöhnungszeit kann sie dennoch gut funktionieren.

Inform 6

Im Gegensatz zu Inform 7 ist Inform 6 keine komplette Entwicklungsumgebung sondern nur ein Compiler. Der Programmcode muss in einem Texteditor erstellt werden und kann dann auf Kommandozeilen-Ebene in Z-code übersetzt werden. Der Code wird in einer klassischen formalisierten Programmiersprache erstellt, die mit der umgangssprachlichen Syntax von Intorm 7 nichts gemeinsam hat. Versierte Programmierer werden sich hier daher wesentlich mehr zu Hause fühlen als bei der Nachfolgerversion. Auch für Inform 6 gibt es eine Reihe von Erweiterungen, die jedoch weit weniger komfortabel eingebunden werden können. Hat man das Ganze allerdings erstmal nach seinen Wünschen eingerichtet funktioniert es sehr gut als Autorensystem.

TADS

TADS bietet eine direkte Alternative zu Inform 6 und ungefähr den gleichen Funktionsumfang. Die Syntax ist ebenso formalisiert, sieht jedoch komplett anders aus. Ebenso gibt es Erweiterungen die es um bestimmte Funktionen erweitern können. Als Ausgabe produziert es keinen Z-code sondern eben das TADS-eigene Story-Format, für das man einen anderen Interpreter benötigt. Viele gute Textadventures wurden mit TADS geschrieben und es schwören ebenso viele Autoren auf darauf wie auf Inform 6.

Adrift

Bei Adrift handelt es sich wieder um eine komplette Entwicklungsumgebung, die darauf ausgerichtet ist möglichst einfach bedient werden zu können. Der Programmcode wird beinahe komplett von den verschieden Editoren verborgen. Neue Räume und Aktionen können einfach mit einer Eingabemaske erstellt werden. Auf diese Weise geht es sehr schnell und einfach, ein simples Textadventure zu erstellen. Darin liegt aber auch gleichzeitig das Problem: alles was von Standardfunktionen abweicht ist schwierig umzusetzen und neue Kommandos können nur sehr unzureichend definiert werden. Das Erstellen von Spielen ist somit zwar vereifacht worden, die Ergebnisse lassen von technischer Seite jedoch häufig zu wünschen übrig. Nichtsdestotrotz eignet es sich gut für Anfänger im Erstellen von Textadventures. Die Adrift Entwicklungsumgebung ist mittlerweile ebenfalls kostenlos. Um Spenden wird gebeten.

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.

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 daveo 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.

Spieleempfehlungen

Im folgenden werde ich einige Textadventures anderer Autoren vorstellen. Für die Links zu den Spielen selber verlinke ich sofern möglich auf die Homepage des jeweiligen Autors und andernfalls auf das Interactive Fiction Archive. Zum Starten der Spiele ist in der Regel ein Interpreter für das entsprechende Story-Format notwendig. Zu empfehlen sind da Spatterlight für Mac OS X und Gargoyle für Windows und Linux. Beide unterstützen alle gängigen Story-Formate.

Photopia von Adam Cadre

In Photopia begleitet man ein junges Mädchen durch gewisse Schlüsselmomente in ihrem Leben, die immer wieder durchsetzt sind mit fantastischen Geschichten aus ihrer Vorstellung. Die Geschichte ist sehr linear aufgebaut und selbst wenn dem Spieler Entscheidungsmöglichkeiten vorgegaukelt werden kann er keinerlei Einfluss auf den Verlauf der Geschehnisse nehmen. Das Spiel besitzt ein menügesteuertes Dialogsystem und verzichtet beinahe komplett auf jegliche Form von Rätsel. Was in jeder Situation zu tun ist wird entweder spätestens nach kurzem überlegen aus der Situation heraus offensichtlich oder wird nach ein paar Runden automatisch gelöst. Großartig an Photopia ist aber vor allem die Erzählung. Adam Cadre spielt gekonnt mit verschiedensten Stilelementen um Situationen zu schaffen, die den Spieler emotional stark an die Hauptfigur fesseln.

Shrapnel von Adam Cadre

Eine verstörende Geschichte über die Bewohner eines einsamen Hauses auf dem Land und eines neu angekommenen Gastes, in dessen Rolle der Spieler schlüpft. Im Laufe der Geschichte wird schnell klar, dass dort einiges im Argen liegt und sogar die Realität selber sich über alle Maßen seltsam verhält. Shrapnel ist das beste Beispiel für einen unkonventionellen Umgang mit dem Tod der Spielerfigur, das ich kenne. Wie auch Photopia ist es sehr linear und bietet so gut wie keine wirklichen Rätsel. Die Story selber ist sehr verwirrend und häufig vermutet man einen Fehler gemacht zu haben, wenn dies jedoch in Wahrheit nur der vollkommen normale Spielverlauf ist. Hat man sich aber erstmal mit diesen unwägbarkeiten abgefunden bietet Shrapnel ein wirklich interessantes Spielerlebnis.

Spider and Web von Andrew Plotkin

In dieser Geschichte stellt der Spieler scheinbar einen Touristen in einer fremden Stadt dar, der sich unglücklicherweise verlaufen hat. Oder steckt vielleicht doch mehr dahinter? Andrew Plotkin spielt gekonnt mit der Unwissenheit, die der Spieler am Anfang der Geschichte von seiner Spielfigur hat. Es wird viel mit Flashbacks gearbeitet, so dass der Spieler häufig zwischen zwei verschiedenen Zeitabschnitten hin und her springt und immer ein wenig mehr über seine eigene Spielfigur erfährt. Das Spiel verwendet vorwiegend recht simple Kombinationsrätsel und ein Dialogsystem, das zumeist die anderen Figuren reden lässt und dem Spieler nur "Ja" und "Nein" als Antwortmöglichkeiten erlaubt. Dies funktioniert in dem Setting jedoch erstaunlich gut und kann elegant darüber hinwegtäuschen, dass das Spiel dennoch vollkommen Linear ist.

Starrider von Max Kalus

Eines der leider nur sehr wenigen guten deutschen Textadventures. Man spielt einen blinden Passagier an bord eines Raumschiffs, der, als er endlich sein Versteck verlässt, die Crew des Schiffs tot vorfindet. Es handelt sich um ein klassisches Textdaventure mit einer soliden Story, das stark von dem gut durchdachten Universum des Pen&Paper Spiels Chalybes profitiert. Die Rätsel funktionieren weitesgehend sehr gut, fallen in einzelnen Fällen aber auch mal übermäßig knifflig und weit hergeholt aus. Nichtsdestotrotz ein gutes Spiel, um das man im deutschsprachigen IF-Raum eigentlich gar nicht herum kommt.

Meine Spiele

Hier stelle ich meine eigenen kleinen Versuche aus, Textadventures zu schreiben. Als Sprache verwende ich wozu ich gerade Lust habe. Über das Sub-Menü rechts gelangt man zu den einzelnen Spielen, von denen es bisher allerdings nur ein einziges unfertiges zu sehen gibt. Ich hoffe, dass sich diese Rubrik mit der Zeit weiter füllen wird.

Die Online Previews laufen unter dem JavaScript-Interpreter Parchment und benötigen dementsprechend aktiviertes JavaScript.

Seraphim (Online Preview)

Seraphim ist das Spiel an dem ich derzeit arbeite. Die Geschichte handelt von einem jungen Mann, der in nicht allzu ferner Zukunft die Erde verlässt und sich auf den Weg macht, sein Glück im Weltall zu suchen. Leider verläuft dabei nicht alles nach Plan und schon bald steckt er bis zum Hals in Schwierigkeiten.

Das Spiel wird in Englisch geschrieben sein und bietet eine lineare Story und situationsbedingte Rätsel, nichts kompliziertes. Seraphim ist noch lange nicht fertig, aber bei Interesse gibt es schon eine (sehr) kurze Kostprobe des Prologs online zu testen.