Eine interaktive Erzählung (als was ich den englischen Ausdruck Interactive Fiction, kurz IF, übersetzen möchte) lässt sich in der Herstellung irgendwo zwischen Schauspiel, Erzählung und Spiel einordnen. Je nachdem ob man sein Produkt nicht nur als Rätsel oder Spiel geplant, sondern auch auf einen erzählerischen Fluss, auf eine umfassende Handlung Wert gelegt hat. Was zugegebenermaßen bisher wegen der Rahmenbedingungen, siehe IF – Spielen oder Lesen?, schwierig war.
Wenn wir einmal davon ausgehen, dass es irgendwann IF-Systeme gäbe, die die Gestaltungs- und Benutzungsmöglichkeiten moderner Endgeräte voll ausnutzen würden, es somit Lesern/Spielern leichtgemacht würde, sich mit interaktiven Erzählinhalten zu beschäftigen – was müsste man dann als gewiefter Schreiberling tun, um Interaktivität in seine Geschichte zu bekommen? Das soll hier kurz demonstriert werden.
Das Inventar der IF-Welt
Grob gesagt beinhaltet eine IF-Welt folgende Bestandteile:
- Orte
- Objekte
- NPCs
- den Stellvertreter, Avatar des Spielers (häufig “Player” genannt)
Letzterer ist die Figur, über die der Leser/Spieler die IF-Welt wahrnimmt und diese auch manipuliert. Sie ist fest in die Umgebung eingebaut, kann nur begrenzt vom Autor verändert werden. Der Spieler verkehrt mit seinem Avatar übrigens meist in der zweiten Person Singular, ein kleiner Unterschied zur Literatur, wo das ja meist die erste oder dritte Person ist.
Mit Ort sind hier die jeweiligen Bühnenbilder gemeint, die man als Autor erstellen muss. Es muss mindestens eines geben. Mit Objekten sind alle Dinge gemeint, die vom Spieler oder den NPCs manipuliert werden können. Das führt uns zu den NPCs, den non-player characters, womit der Rest der teilnehmenden Schauspieltruppe gemeint ist. NPCs werden vom Autor als lebendige – im Gegensatz zu Objekten – Mitspieler erstellt, meist sind es Figuren, die den Spieler in bestimmten Situationen helfen oder behindern sollen.
Bühnenbild und Ausstattung – Beispiel “Galatea”
Statt die gesamte Szenerie und alle Objekte seiner Handlung im Kopf zu jonglieren, muss der IF-Autor sie explizit machen, die Szenerie programmieren. Man muss sich entscheiden, welche Teile einer Geschichte einfach ausgegeben werden soll, als passiver Text, und welche für die Interaktion modelliert werden sollen. Dabei geht es darum, einzelne Objekte für die Implementierung heraus zu greifen und explizit zu machen, damit der Leser/Spieler mit ihnen interagieren kann. Der Rest wird als Szenerie oder reine Textausgabe implementiert, die zwar im Spiel vorhanden ist, aber nicht so stark zur Komplexität beiträgt wie aktive Objekte.
Hier ein Spiel-Protokoll von Galatea, der zeigt, welche Objekte vorhanden sind. Die Hauptperson, die Statue Galatea, wird hier ignoriert: (x = examine)
The Gallery’s End
Unlit, except for the single spotlight; unfurnished, except for the defining swath of black velvet. And a placard on a little stand.
On the pedestal is Galatea.
>x pedestal
It’s hard to see it, under the sweep of the gown.
>x velvet
Heavy black velvet, making her skin seem even paler and more alien by contrast.
>x spotlight
The glare blinds you momentarily. You blink to clear your eyes of the spots.
>x placard
Large cream letters on a black ground.
47. Galatea
White Thasos marble. Non-commissioned work by the late Pygmalion of Cyprus. (The artist has since committed suicide.)
Originally not an animate. The waking of this piece from its natural state remains unexplained.
Galatea wurde in Inform 6 geschrieben, daher erfolgt die Demonstration in derselben Sprache. Inform 6 demonstriert einen Stand der Technik, wie er für Autorensystemen für Spiele typisch zu sein scheint. Es ist stark vom objekt-orientierten Ansatz geprägt. Auch das andere weitverbreitete System für IF, TADS, verfolgt diesen Ansatz.
Mit Inform 6 bekommt man einen Einblick in die Herstellung von IF, die auf einer relativ technischen Ebene stattfindet. Im Gegensatz dazu steht der Nachfolger, Inform 7. Inform 7 hat sich zum Ziel gesetzt, die Herstellung von IF so zu vereinfachen, dass auch Menschen, die sich noch nicht mit dem Thema Programmiersprachen auseinander gesetzt haben, ihre Ideen für interaktive Erzählungen umsetzen können. Daher hat man sich dort für eine Syntax entschieden, die fast menschlich ist. Unter dieser Schicht syntaktischen Zuckers liegt aber weiterhin Inform 6, auf das man in schwierigen Situationen auch direkt von Inform 7 aus zurück greifen kann. Insofern lohnt es sich auch heute noch, sich mit den Grundprinzipien von Inform 6 zu beschäftigen.
Nach soviel Vorrede nun zum Code, den man erstellen muss, um zum Text zu gelangen.
Object Plakette "Plakette"
with name 'plakette',
description "Große, cremefarbene Buchstaben auf schwarzem
Grund.^^47. Galatea^^Weißer Thasos-Marmor. Nicht-beauftragtes Werk des
Pygmalion von Zypern. (Der Künstler hat inzwischen Selbstmord
begangen.)^^Im Originalzustand nicht lebendig gewesen. Das Erwachen
dieses Exponats aus seinem natürlichen Zustand bleibt unerklärlich."
has female scenery;
Object Podest "Podest"
with name 'podest',
description "Überdeckt vom Faltenschwung der Robe ist es nur schwer zu
erkennen.",
has neuter scenery;
Object Samt "Samt"
with name 'samt' 'stoff',
description "Im Kontrast zu diesem schweren schwarzen Samt erscheint
ihre Haut nur noch bleicher und fremdartiger.",
has male scenery;
Object Galatea "Galatea"
with name 'galatea' 'statue',
description "Hello",
has female animate scenery;
[ Initialise;
location = Galerie;
move Plakette to Galerie;
move Podest to Galerie;
move Samt to Galerie;
move Galatea to Galerie;
];
Orte und Objekte
Das obige Code-Beispiel zeigt meine Interpretation des Anfangs von Galatea, da er der Quellkode dazu bislang nicht veröffentlicht wurde. Das hat den Vorteil, dass ich die Umsetzung hier in Deutsch zeigen kann. Das erste Beispiel ist der Ort der Handlung, der ein einfaches Objekt ist. Inform 6 ist eine objekt-orientierte Sprache und daher wird fast alles über die Definition und Manipulation von Objekten erledigt.
Der Ort der Handlung, das Ende der Galerie, ist ein einfach strukturiertes Objekt, das primär aus seinen Bezeichnungen und der auszugebenden Beschreibung besteht. Insofern ist es gut dafür geeignet die Wichtigkeit der Namensgebung zu verdeutlichen. Es gibt nämlich grob gesagt drei Arten von Namen in einem solchen System.
Interne Namen dienen dazu das Objekt innerhalb des Codes zu identifizieren. Der interne Name des Handlungsortes ist der, der direkt nach der Auszeichnung Object folgt, hier also Galerie. Möchte ich den Handlungsort im Code ansprechen, nutze ich diesen Namen, wie z.B. in der Funktion, die die Erzählung startet. Mit dem Ausdruck location = Galerie; lege ich fest, dass der erste Handlungsort eben unsere Galerie ist.
Was dem Leser/Spieler am Bildschirm dann präsentiert wird, ist der Text, der dem internen Namen folgt, in Anführungszeichen, da es sich um längere Texte mit Leerzeichen dazwischen handeln kann. In unserem Fall also: “Am Ende der Gal
erie”. Das wäre der zweite Name, sozusagen die externe, gedruckte Repräsentation gegenüber dem Leser.
Nun ist dies ja ein interaktive Erzählung, d.h. der Leser möchte nicht nur lesen, wo er ist, er möchte vielleicht mit dem Ort interagieren. Um dies dem Spieler einfach zu machen, gibt es eine dritte Art von Namen, die dazu genutzt werden können. Der Ausdruck in Zeile 2 ‘name ‘galerie’ ‘ende'” definiert, dass der Spieler entweder Galerie oder Ende nutzen könnte, um den Ort der Handlung anzusprechen. Man definiert dafür gewöhnlich die Bestandteile des gedruckten Namens, und/oder alltägliche Entsprechungen. Da wir es hier mit einer Ein-Raum-Geschichte zu tun haben, hätten wir auch noch Raum oder einfach Hier hinzufügen können. Der Spieler könnte dann etwa folgenden Befehl eingeben, um sich umzuschauen:
"beschreibe galerie" oder "schau hier"
Dann würde die Beschreibung des Galerie ausgegeben. Ein Versuch zeigt aber, dass der Konjunktiv berechtigt war:
>beschreibe galerie
Damit brauchst du dich in diesem Spiel nicht zu beschäftigen.
>schau ende an
Damit brauchst du dich in diesem Spiel nicht zu beschäftigen
Warum bekommen wir hier diesen Hinweis? Weil wir die Galerie als Szenerie definiert haben, in Zeile 8 mit has scenery. Szenerie meint, dass es sich um ein Objekt handelt, dass primär als Hintergrund vorhanden ist. Sein Zweck ist es Kontext und Beschreibung zu liefern, wenn der Handlungsort betreten wird, damit sich der Spieler orientieren kann. Szenerie-Objekte sind normalerweise nicht für Interaktionen gedacht, daher gibt das Laufzeitsystem – die Library genannt – eine Standardmeldung aus, die den Spieler darauf hinweist, dass weitere Versuche fruchtlos wären. Natürlich könnte ein Autor auch diese Meldung in seinem Sinne verändern.
Um sich in den verschiedenen Spielphasen neu zu orientieren, kann der Spieler einfach den Befehl “schau umher” eingeben. Dann antwortet das Laufzeitsystem mit der Beschreibung des aktuellen Ortes und einer Aufzählung aller Objekte, die nicht zu Szenerie gehören. Um diesen Unterschied zu verdeutlichen, habe ich der Galatea-Szene ein weiteres Objekt hinzugefügt, einen Hammer:
Object Hammer "Hammer"
with name 'hammer',
description "Ein schöner, solider Hammer, wie ihn wohl auch
Pygmalion gern benutzt hätte.",
before [;
ThrowAt:
if (second == Galatea) {
move Hammer to location;
print_ret "'Oh, nein. Da mach' ich nicht mit!', sagt sich der Hammer und fällt
Dir aus der Hand.";
}
],
has male;
Somit hätten wir hier drei Arten von Objekten:
- dem Szenerie-Objekt Galerie, das gleichzeitig der Handlungsort ist
- den Szenerie-Objekten Galatea, Podest, Plakette, Samt und Licht
- dem Objekt Hammer
Schaut sich der Spieler nun um, kann man anhand der Beschreibung durch das Laufzeitsystem sehen, wie die verschiedenen Objektarten behandelt werden:
Am Ende der Galerie
Unerleuchtet, bis auf das einsame Spotlight; eher leer, bis auf eine konturierende Hülle aus schwarzem Samt. Und eine, an einem kleine Ständer befestigte, Plakette.
Auf einem Podest steht Galatea.
Du siehst hier einen Hammer.
Alles bis auf die letzte Zeile gehört zur Beschreibung des Szenerie-Objektes Galerie. Da es der Handlungsort ist, wird seine Beschreibung ausgegeben. Die aller anderen Szenerie-Objekte unterbleibt. Um die zu sehen, muss man sich die jeweiligen Gegenstände explizit ansehen:
>beschreibe podest
überdeckt vom Faltenschwung der Robe ist es nur schwer zu erkennen.
Aktive Objekte wie der Hammer werden aber immer beschrieben. Die Logik dabei ist, dass dies ein Objekt ist, das der Autor explizit für Nutzung durch den Spieler modelliert hat. Daher sollte darauf hingewiesen werden.
Verhalten von Objekten
Nach Namen, Beschreibung und Eigenschaften fehlt jetzt nur noch das Verhalten, um den Kurzüberblick der IF-Objekte zu vervollständigen. Alle bisher genannten Punkte definierten die statische Struktur von Objekten. Eine Umgebung, die nur aus unveränderlichen Objekten besteht, ist aber eher langweilig. Wir hatten es ja auf eine interaktive Erzählung abgesehen, also muss sich etwas verändern lassen können.
Um dies kurz zu demonstrieren nutzen wir unseren Hammer – ein etwas gefährliches Objekt in einer Galerie. Es gibt verschiedene vordefinierte Aktionen, die ein Autor bei der Definition des Verhaltens nutzen kann. Natürlich kann man auch eigene dazu erfinden. Der Einfachheit halber nutze ich hier aber die vordefinierte Aktion ThrowAt, die ausgeführt wird, wenn der Spieler etwas das Kommando wirf hammer gegen statue eingeben würde.
Die Verhaltensdefinition, die man in Zeile 6-11 (siehe oben) sehen kann bedeutet, dass sich das Verhalten des Hammers je nach Zielobjekt unterscheidet. Würde der Spieler den Hammer gegen das Objekt Galatea werfen, würde der Hammer sich weigern und zu Boden fallen – wir wollen hier ja nicht zur Zerstörung von Kunstwerken aufrufen.
>nimm hammer
In Ordnung.
>wirf hammer gegen statue
‘Oh, nein. Da mach’ ich nicht mit!’, sagt sich der Hammer und fällt Dir aus der Hand.
Bei allen anderen Objekten würde der Hammer dagegen keine Einwände erheben, die habe ich im Code nicht erwähnt. Also probieren wir es noch einmal, diesmal werfen wir den Hammer gegen die Samtverkleidung:
>wirf hammer gegen samt
Stoff zerreißt als der Hammer den aufgespannten Samt trifft und hinter ihm verschwindet. Ein dumpfer Aufschlag, gefolgt von einem Poltern, lässt vermuten, dass der Hammer nun irgendwo an der Wand liegt.
Wie kommt diese Beschreibung zustande? Nun, nach dem Ausgangsobjekt der Handlung (noun), dem Hammer, befragt das Laufzeitsystem auch das Zielobjekt (second), den Stoff, nach Reaktionen. Dort habe ich Verhalten für den Fall definiert, dass etwas auf den Samt geworfen wird, in der Methode ThrownAt.
Object Samt "Samt"
with name 'samt' 'stoff',
description "Im Kontrast zu diesem schweren schwarzen Samt erscheint
ihre Haut nur noch bleicher und fremdartiger.",
before [;
ThrownAt:
if (noun == Hammer) {
self.description = "Im Kontrast zu diesem schweren
schwarzen Samt erscheint Galateas Haut nur noch
bleicher und fremdartiger. In der Mitte klafft
ein großer, häßlicher Riss, der das Mauerwerk
durchscheinen läßt - als wäre etwas Schweres
hindurchgeflogen.";
remove noun;
print_ret "Stoff zerreißt als der Hammer den
aufgespannten Samt trifft und hinter ihm
verschwindet. Ein dumpfes Aufschlagen, gefolgt
von einem Poltern, läßt vermuten, dass der
Hammer nun irgendwo an der Außenwand liegt.";
}
],
has male scenery;
Auch hier gibt es wieder eine Verhaltensunterscheidung. Ist das Ausgangsobjekt (noun) nicht der Hammer, verfolgt man das vordefinierte Standardverhalten. Ist es aber der Hammer, dann ändert sich die Beschreibung des Stoffes, der ja nun durch den Hammer zerrissen wurde. Bei künftigen Betrachtungen des Stoffes wird diese neue Beschreibung ausgegeben. Um dem Spieler gleich eine Rückmeldung zu geben, wird auch eine passende Reaktion ausgedruckt. Außerdem wird der Hammer aus dem Spiel genommen (remove noun), da er ja nun seinen Zweck erfüllt hat.
Dieses beschriebene Verhaltensmuster sollte einen Eindruck davon geben, was es bedeutet, eine Erzählung interaktiv zu machen. Je mehr aktive Objekte es gibt, desto mehr Verhaltensregeln muss ein Autor definieren. Er muss dabei einberechnen, dass die Lösungsansätze der Spieler variieren.
Gibt es nämlich nur genau einen Weg, ein Rätsel zu lösen, ein Hindernis zu überwinden, dann besteht die Gefahr, dass die Situation als zu einfach und damit als langweilig bewertet wird. Das andere Extrem ist, wenn der Spieler viel raten muss, um das richtige Objekt und die richtige Aktion zu finden, was oft frustrierend ist. Um das zu vermeiden kann man alternative Lösungspfade bereitstellen, dies aber um den Preis, dass sich die Verhaltensregeln vervielfachen, weil man wesentlich mehr Objekt-Aktion-Kombinationen berücksichtigen muss.