________________________________________________________________________
[<<] [Inhalt] [>>] III. Beispiele

17. Allgemeine Tips und Tricks

17.1.   Hilfsvariablen
17.2.   Größe eine Spiels

17.1. Hilfsvariablen

TAG ermöglicht keine lokalen Variablen bei den Aktionen und Ausführungen. Das erfordert einiges Umdenken beim Programmieren mit TAG, wenn man an das Programmieren mit prozeduralen Sprachen gewöhnt ist.

Dies ist zugegebenermaßen ein Manko von TAG, das noch dadurch schlimmer wird, daß man Bedingungen nicht ineinander schachteln kann und daß man keine arithmethischen Ausdrücke angeben kann, sondern den Umweg über die "Taschenrechnermethode" gehen muß, bei der man jede Operation in eine eigene Befehlszeile schreibt und Klammerausdrücke sogar auf Hilfsvariablen zwischenlagern muß.

(Dieser große Nachteil wird vielleicht in einer der späteren Versionen behoben werden. Das ursprüngliche Konzept von TAG war jedoch, die Behandlung und Definition der Objekte und Räume so einfach wie möglich zu machen. Daraus entstanden die etwas an BASIC erinnernden Anweisungen. Bei komplizierteren Adventures wird dann aber leider der Code unschön.)

Ich definiere zu Beginn daher in paar Hilfsvariablen, die nie eine Bedeutung für den Spielverlauf haben und die daher gut als lokale Variablen benutzt werden können:

        Flagge Aux1
        Flagge Aux2
        Flagge Aux3
        ObjVar xObj
        ObjVar yObj
        [...]

Diese kommen dann während des Spiels als Zählvariablen für Schleifen oder als Marker für Klammerausdrücke oder Bedingungen zum Zuge. Dies ist natürlich vom Blickwinkel eines Informatikers aus gesehen nicht sehr elegant, aber wenn man sich an diese Vorgehensweise gewöhnt hat, kommt man gut zurecht. (Ich bin übrigens kein Informatiker.)

17.2. Größe eines Spiels

Adventures, die mit TAG geschrieben werden, sind in ihrer Größe begrenzt. Die wichtigste Einschränkung ist sicherlich der Arbeitsspeicher. Insbesondere bei der Anzahl der möglichen Definitionen gelten in TAG aber die folgenden Beschränkungen:

Objekte:
Es können maximal 250 Objekte, Dekorationen und Objektklassen definiert werden. (TAG benötigt weitere 4 Variablen für die Hilfsobjekte ich, du, Zitat und Zahl.) Die Anzahl der Vokabeln für ein Objekt ist unbeschränkt.

Räume:
Es können insgesamt maximal 255 Räume, Raumklassen, Antworten und Wege definiert werden.

Befehle:
Es können bis zu 255 Befehle und Befehlsvariablen definiert werden. Meta-Befehle, Pseudo-Befehle, und Befehle, die keinen eigenen Ausführungsblock besitzen, zählen dazu. Die Anzahl der Verben, die zu einem Befehl angegeben werden können, ist unbeschränkt. Etwa vierzig Verben sind schon vordefiniert.

Variablen:
Es können 255 Flaggen, je 64 Objektvariablen und Raumvariablen, sowie je 32 Integer-, Richtungs- und Zustandsvariablen definiert werden. Außerdem können 32 Felder mit maximal je 256 Elementen und 32 Strings definiert werden.

Texte:
Es können bis zu 255 Textblöcke mit je 255 Texten definiert werden. Die Länge der einzelnen Texte ist unbegrenzt, aber alle Texte eines Blocks dürfen zusammen höchstens 32 Kilobytes belegen. (Bei der automatischen Belegung ohne Blockangaben wird das berücksichtigt.)

Ausführungsblöcke:
Jeder Ausführungsblock kann maximal 8 Kilobytes belegen. Texte zählen nicht zu den Ausführungsblöcken.

Sonstiges:
Es können 32 Richtungen, 32 Zustände und je 64 Objekt- und Raumattribute definiert werden. Die Anzahl der Synonyme ist unbegrenzt.

Das hört sich nicht nach besonders viel an, und man hat sich an ganz andere Datenmengen gewöhnt. Ich denke aber nicht, daß diese Beschränkungen bei einem Spiel von normaler Größe zum Tragen kommen.

Die Text-Adventures von Infocom, die in der 80ern sehr populär waren und bereits einen sehr hohen Standard hatten, mußten mit insgesamt 255 Objekten auskommen, wozu auch Räume und Richtungen zählten. Durch geschickte Pro- grammierung und durch den Sparzwang bei den Objekten waren die Spiele aber sehr gut organisiert und vermieden dadurch langweilige Passagen, in denen nichts passierte, und nutzlose Objekte. (Ein Spiel mit den Ausmaßen und der Komplexität von Graham Nelsons "Curses" wäre allerdings mit TAG wahr- scheinlich nicht möglich.)

Sollten dennoch die Ressourcen einmal knapp werden, so gibt es veschiedene Möglichkeiten, dies in den Griff zu bekommen:

  • Dekorationen können an bis zu drei Orten sein. Gibt man anstatt des Orts ein Raum-Attribut an, so befindet sich diese Dekoration in allen Räumen, die dieses Attribut besitzen. Wenn man die Beschreibung der Dekos allgemein hält, kann man auch mehere Dekorationen zusammenfassen. So könnten ein Garten, die Bienen, die darin dekorativ herumsummen, die Blumen und die Büsche eine einzige Dekoration sein.

  • Viele ähnliche Räume, etwa in einem Labyrinth, können zu als ein Raum programmiert werden (s. 10.1.3/4), wenn man Felder benutzt.

  • Man kann verschiedene Antworten zu einer zusammenfassen, indem man sie über eine Aktion steuert (10.1.5).

  • Verschiedene Objekte können auch als ein einzelnes Programmiert werden, wenn man den Parser mit ObjParser anpaßt. Feste Gegenstände, die ähnlich sind und sich alle in verschiedenen Räumen befinden, kann man auch ohne Anpassung des Parsers als ein Objekt implementieren.

  • Ausführungsblöcke können gesplittet werden: Eine Hauptaktion ruft weitere mit der Ausf-Anweisung auf.

  • Wenn die globalen Flaggen knapp werden, kann man oft auf Variablen für Objekte oder ein Hilfsfeld umsteigen.

Die beste Lösung ist aber wahrscheinlich, das Spiel noch einmal anzuschauen und 'auszumisten': Es gibt bestimmt den ein oder anderen Raum, der überflüssig ist oder ein paar Dekos, die nicht unbedingt notwendig sind.

Martin Oehm, 04.02.2000 Vorheriges KapitelInhaltsverzeichnisNächstes Kapitel