Inhalt

1. Einleitung
1.1. Von CoreWar zu RoboCom
1.2. Entwicklungsumfeld

2. Das Spielkonzept
2.1. Das Spielbrett - ein unbegrenzter Hintergrund
2.2. Roboterdesign
2.2.1. Das Referenzfeld und die Blickrichtung
2.2.2. Instruktions-Sets
2.2.3. Eigenschaften eines Roboters
2.2.4. Speicherbänke
2.3. Die RoboCom-Programmiersprache
2.3.1. Parameter
2.3.2. Konstanten
2.3.3. Variablen
2.3.4. Remotes
2.3.5. Grundgerüst eines RoboCom-Programms
2.3.6. Instruktionen und ihre Bedeutung
2.3.7. Kommentare
2.3.8. Labels
2.4. Auto-Reboot
2.5. Ausnahmen und Fehler
2.5.1. Tolerierbare Ausnahmen
2.5.2. Laufzeitfehler (fatale Ausnahmen)
2.5.3. Data Hunger
2.5.4. Eliminationen

3. Jetzt geht's los!
3.1. Aufruf von RoboCom
3.1.1. RoboCom Version 1.x
3.1.2. Das Shellsystem
3.1.3. Windows-Version
3.2. Ein einfaches Programm
3.3. Der Initialroboter und die Produktion weiterer Roboter
3.4. Programmvielfalt oder Einheitsbrei?
3.5. Arbeitsweise verschiedener RoboCom-Programme
3.5.1. Mine
3.5.2. Black Jacks
3.5.3. 4Lunch
3.5.4. MetaMORFosis
3.5.5. Pesticide
3.5.6. Wall Dry
3.5.7. Persuaders
3.5.8. MegaMorf
3.5.9. Die "Clausthal-Epoche"
3.5.10. Neuere RoboCom-Programme
3.6. Typische Fehler, die eigentlich keine sind
3.7. Zeit für eine Inspektion - der RoboCom Debugger

4. Schluß
4.1. Kritischer Rückblick - Zielsetzung und Ergebnis
4.2. Aktuelles, Ausblick

5. Literatur- und Linkverzeichnis

Anhang A. Laufzeitfehlerverzeichnis

1. Einleitung

Ich hatte mir vorgenommen, ein Computerspiel zu entwerfen, bei dem die Spieler während des Ablaufs keinen Einfluß mehr auf das Spielgeschehen haben: jeder Teilnehmer sollte vor Beginn ein Assembler-ähnliches Programm schreiben, das dann später alle nötigen Entscheidungen zu treffen und das Spiel eigenständig für
sich zu entscheiden hat.

Als Spielumgebung wählte ich ein quadratisches Spielbrett, ähnlich einem Schachfeld. Die Spielfiguren (Roboter) sollten durch gerichtete Fünfecke repräsentiert werden. Ziel des Spiels ist es, die Roboter der anderen Spieler ausser Gefecht zu setzen und dabei selbst funktionsfähig zu bleiben. Wer sich nun an ein Militärspiel erinnert fühlt, liegt falsch: 'Waffen' gibt es nicht; die einzige Möglichkeit zur Manipulation anderer Roboter liegt in der Übertragung von Daten. Nach der Entwicklung des Interpreters mussten nun eigene Programme entworfen werden. Wie später noch deutlich werden wird, gibt es dabei erstaunlich viele verschiedene Strategien, die alle auf eine andere Weise erfolgreich sind.

1.1. Von CoreWar zu RoboCom

Der ein oder andere wird sich beim Lesen der Einleitung an CoreWar erinnert haben - tatsächlich hat mich dieses Spiel massgeblich inspiriert.

CoreWar ist ein sehr altes Computerspiel, das von Programmierern in ihrer Freizeit entworfen wurde, um ihre programmatischen Fähigkeiten zu messen. Auch hier werden Programme vor dem Spiel geschrieben und laufen dann nur noch ab - im (eindimensionalen) Speicher eines virtuellen Computers. Programmiert wird in einem Assembler-Dialekt genannt "RedCode". Das faszinierende an diesem Spiel ist die Tatsache, daß dort Praktiken, die ein guter Programmierer sonst lieber vermeidet, an der Tagesordnung sind. Es gibt kaum ein gutes CoreWar-Programm, dass sich nicht selbst modifiziert, Clones von sich herstellt oder zumindest scheinbar planlos in den Speicher schreibt. Das hat allerdings auch zur Folge, dass Programme schnell unübersichtlich werden und von Dritten bald nicht mehr durchschaubar sind. CoreWar eignet sich deshalb vorrangig nur für erfahrene Assembler-Programmierer. Dieses Faktum störte mich am meisten, denn ich kannte niemanden, gegen dessen Programme ich meine antreten lassen konnte.

Deshalb beschloß ich, ein an CoreWar angelehntes Spiel zu schreiben, das jedoch weniger abstrakt ist, und so einfach, dass es auch von Basic- oder Pascalprogrammierern auf Anhieb verstanden werden kann. Während bei CoreWar Speicher und Spielfeld identisch sind (Prozesse "bewegen" sich als Pointer durch den Speicher und arbeiten den dort stehenden Code ab), hat bei RoboCom jeder Roboter einen eigenen Speicher. Das Spielfeld dient als zweidimensionaler Hintergrund, auf dem sich die Roboter bewegen. Die Sprache ähnelt ebenfalls Assembler und ist auf wenige Instruktionen begrenzt.

1.2. Entwicklungsumfeld

Ich entschied mich für die Programmiersprache Turbo Pascal 6.0, die die Möglichkeit der objektorientierten Programmierung bietet. Die mausgesteuerte Benutzerschnittstelle des RoboCom-Interpreters programmierte ich auf BGI-Basis im Modus VgaHi.

Seit April 1998 gibt es sogar eine Windows-Version von RoboCom. Das Spiel wurde dazu in Delphi komplett neu geschrieben und hinsichtlich Speicherverbrauch und Geschwindigkeit optimiert. Die Benutzeroberfläche der Windows-Version entwickelte ich zusammen mit Jens Rupp aus Erlangen.

2. Das Spielkonzept

2.1. Das Spielbrett - ein unbegrenzter Hintergrund

Beginnen wir mit dem "Spielbrett" - der Fläche, auf der sich (im wahrsten Sinne des Wortes) alles abspielt. Dieses besteht aus n*n gleichen Feldern, die wie bei einem Schachbrett angeordnet sind. n kann frei gewählt werden - in der Praxis haben sich Werte zwischen 10 und 30 Feldern pro Reihe und Spalte bewährt.

Das Spielbrett ist relativ - das bedeutet, es gibt keine absoluten Koordinaten für ein Feld. Ein Roboter der auf der einen Seite das Spielbrett verläßt, kommt auf der gegenüberliegenden Seite wieder herein. Daher hat er nicht die Möglichkeit, herauszufinden, WO er sich befindet - eine solche Angabe wäre nämlich sinnlos, da alle Felder von der Lage her praktisch gleichberechtigt sind. Sehrwohl kann er aber erfahren, wie groß das Spielfeld ist, um beispielsweise seine Bewegungen so zu steuern, daß er möglichst alle Felder besucht.
 

2.2. Roboterdesign

Zu Beginn werden alle Roboter zufällig auf dem Spielbrett plaziert. Nun mußte ich mir Gedanken darüber machen, was einen Roboter ausmachen sollte...

2.2.1. Das Referenzfeld und die Blickrichtung

Roboter können in Kontakt mit ihrer Umgebung treten. Alle Instruktionen, die sich nicht auf den Roboter selbst, auf seine eigenen Daten oder sein eigenes Programm beziehen, wirken auf das sogenannte Referenzfeld - das Feld, das sich direkt vor dem Roboter befindet. Damit die Angabe 'vor' einen Sinn ergibt, braucht jeder Roboter also eine Blickrichtung, die festlegt, welches angrenzende Feld das Referenzfeld ist. Die Blickrichtung ist ausserdem die Richtung, in die ein Roboter sich bewegen kann.

2.2.2. Instruktions-Sets

Ich hielt es für sinnvoll, verschiedene Roboter-Typen zu ermöglichen. Deshalb teilte ich die Instruktionen der Sprache in drei Gruppen auf und führte sogenannte Instruction Sets ein. Das Set, das ein Roboter beherrscht, gibt also direkt an, welche Befehle er ausführen kann. Folgende Instruction Sets gibt es:

Basic (0) - das einfache Set enthält alle für einen Programmablauf wesentlichen Elemente, wie Vergleiche und Sprünge, dazu Rechenoperationen und Bewegungsroutinen. Dies sind schon fast alle Instruktionen. Das einfach Set beschränkt sich allerdings auf den Roboter selbst; Roboter mit diesem Set sind also nicht kontaktfähig.
Instruktionen: ADD, BJUMP, COMP, DIE, JUMP, MOVE, SET, SUB, TURN
Anm.: für Bewegungen braucht ein Roboter zusätzlich die Eigenschaft Mobilität.

Advanced (1) - das erweiterte Set enthält neben allen Instruktionen des Basic Sets auch Instruktionen zur Kommunikation mit dem Referenzfeld, bzw. dem dort stehenden Roboter.
Instruktionen: ADD, BJUMP, COMP, DIE, JUMP, MOVE, SCAN, SET, SUB, TRANS, TURN

Super (2) - das Super Set enthält alle Instruktionen. Gegenüber dem Advanced Set ist nur noch die CREATE-Instruktion hinzugekommen, die es erlaubt, weitere Roboter zu bauen.
Instruktionen: ADD, BJUMP, COMP, CREATE, DIE, JUMP, MOVE, SCAN, SET, SUB, TRANS, TURN

Der Bau eines Roboter dauert umso länger, je höher dessen Instruktions-Set sein soll. Dadurch wird verhindert, dass nur Super-Roboter verwendet werden. Die Funktion der einzelnen Instruktionen wird in Kapitel 2.3.6. erklärt.

2.2.3. Eigenschaften eines Roboters

Das folgende Diagramm gibt die Eigenschaften eines Roboters wieder:

2.2.4. Speicherbänke

Der Programmcode eines Roboters ist in sogenannten Bänken organisiert. Eine Speicherbank kann beliebig viele Anweisungen enthalten und ein Roboter kann bis zu 50 Bänke besitzen. Dahinter steckt die Idee, dass die meisten Roboter neben ihrem Programm viel Code enthalten, den sie niemals ausführen - weil er auch gar nicht für sie bestimmt ist. Viele RoboCom-Programme beruhen auf Kooperation zwischen Robotern, die verschiedene Aufgaben haben. Da man aber mit nur einem Roboter beginnt, muss dieser folglich die anderen erst produzieren und anschließend programmieren. Der Initialroboter (auch Mutterroboter genannt) muss also bereits allen Code enthalten, den seine Kinder später ausführen sollen, um ihn an sie weitergeben zu können. Um eine logische Trennung verschiedener Programm(teil)e zu erreichen, wurden Speicherbänke eingeführt.

Die BJUMP-Anweisung bewirkt, dass die Programmausführung in einer anderen Bank fortgesetzt wird, die Instruktion TRANS erlaubt es, eine Speicherbank in den Roboter auf dem Referenzfeld zu kopieren.

Die Bauzeit für einen Roboter verlängert sich mit der Anzahl seiner Speicherbänke.
 

2.3. Die RoboCom-Programmiersprache

Der Programmcode in einer Bank ist, wie auch in der Assemblersprache, eine Sequenz aus Anweisungen, wobei einige Anweisungen Parameter benötigen, die durch Kommata getrennt werden. Ein Programm sieht folglich etwa so aus: 
InstrA
InstrB param1, param2
InstrA
InstrC param1
Für die einzelnen Instruktionen habe ich benötigte Taktzyklen festgelegt, so daß die Ausführung verschiedener Instruktionen verschieden lange dauert. Diese Festlegung orientiert sich daran, daß einige Anweisungen komplexere Dinge bewirken als andere und soll das Spiel realistischer machen. Die Zeit läuft jedoch global, so dass ein Taktzyklus bei allen Robotern gleich lang ist (oder anders ausgedrückt: in der Zeit in der ein Roboter 100 Taktzyklen durchläuft, durchläuft jeder andere auch genau 100 Taktzyklen).

2.3.1. Parameter

Parameter, die einer Anweisung übergeben werden können, lassen sich in drei Gruppen einordnen:
  • Konstanten
  • Variablen
  • Remotes (Remote-Konstanten / Remote-Variablen)

    •  

    2.3.2. Konstanten

    Konstanten können entweder Integer-Zahlen sein (wie etwa 5 oder 1524 oder -475) oder Labels (siehe Kapitel 2.3.8.) oder aber von RoboCom bereitgestellte Konstanten, die mit dem Zeichen $ beginnen. Folgende Konstanten dieser Art kann ein Roboter verarbeiten:
    $Banks  ist die Anzahl der Speicherbänke, die der betreffende Roboter hat. 
    $Mobile  ist 1, wenn der betreffende Roboter mobil ist, sonst 0. 
    $InstrSet  Das Instruction Set des Roboters (0=Basic, 1=Advanced, 2=Super). 
    $Fields  Die konfigurierte Spielbrettgrösse (Anzahl der Reihen und Spalten). 

    2.3.3. Variablen

    Alle Variablenbezeichner beginnen mit dem Zeichen #. Jedem Roboter stehen 20 Variablen des Typs 16bit signed integer zur Verfügung, die vom Programm beliebig verwendet werden können. Diese werden über die Bezeichner #1, #2, #3, ..., #20 adressiert. Weiterhin besitzt jeder Roboter die Variable #Active, die die Aktivität des Roboters bestimmt. Bei Werten grösser oder gleich 1 ist der Roboter aktiv, ansonsten inaktiv. Selbstverständlich kann ein aktiver Roboter sich selbst deaktivieren, indem er #Active auf 0 setzt. Im Gegensatz dazu kann sich ein inaktiver Roboter nicht selbst aktivieren, da er keinen Programmcode ausführt. In der RoboCom-Sprache gibt es keine Register, stattdessen werden Variablen verwendet.

    2.3.4. Remotes

    Remotes sind die Variablen und Konstanten des Roboters auf dem Referenzfeld. Alle Remote-Bezeichner beginnen mit dem Zeichen %. Die Verwendung von Remotes erlaubt es einem Roboter, Informationen über den Roboter vor ihm zu erlangen, oder ihn zu (de)aktivieren. Dies ist beispielsweise zwingend nötig, wenn weitere Roboter produziert werden sollen, da ein frisch gebauter Roboter zuerst immer inaktiv ist. Folgende Remotes kann ein Roboter verarbeiten:
    %Banks  Konstante  ist die Anzahl der Speicherbänke, des Remote-Roboters. (Konstante) 
    %Mobile  Konstante  ist 1, wenn der Remote-Roboter mobil ist, sonst 0. (Konstante) 
    %InstrSet  Konstante  Das Instruction Set des Remote-Roboters (0, 1 oder 2) 
    %Active  Variable  Aktivität des Remote-Roboters. 
    Die Remotes entsprechen den jeweiligen lokalen Variablen bzw. Konstanten des Remote-Roboters. Um Remotes verwenden zu können, ist das erweiterte Instruktions-Set (Advanced, 1) nötig. Für einen Remote-Zugriff benötigt der ausführende Roboter zusätzliche 8 Taktzyklen.

    Wie die Liste zeigt, kann auf die übrigen Variablen des Remote-Roboters (#1 bis #20) nicht direkt zugegriffen werden. So bleibt jedem Roboter eine gewisse "Privatsphäre" zugesichert. Sollte dennoch einmal der Wunsch bestehen, diese Variablen von einem anderen Roboter aus zu ändern, so kann dieser Roboter Programmcode, der auf die Variablen zugreift in den anderen Roboter transferieren.

    2.3.5. Grundgerüst eines RoboCom-Programms

    Üblicherweise beginnt ein RoboCom-Programm mit einem (optionalen) Kommentar, der angibt, daß es sich um ein RoboCom-Programm handelt (Kommentare werden in Kapitel 2.3.8. behandelt).
    Ebenfalls optional ist die Möglichkeit, den Titel, den der Autor seinem Programm gegeben hat, und den Namen des Autors anzugeben (siehe Beispiel). Diese Namen dürfen auch länger als acht Zeichen sein und Sonderzeichen enthalten (was für den Dateinamen unter DOS nicht zutrifft). Ein Programmkopf könnte etwa so aussehen: 
    ; RoboCom Programm
Name Überraschung!
Author Hans Wurst

; Hier könnte noch erklärt werden,
; wie das Programm funktioniert.
    Die neue Windows-Version erlaubt zusätzlich, das Heimatland des Programmierers anzugeben (z.B.: Country Germany).

    Als nächstes folgen die Speicherbänke. Eine Bank beginnt immer mit dem Bezeichner Bank, dahinter kann (optional) ein Name für diese Bank angegeben werden. In den folgenden Zeilen stehen die Anweisungen dieser Bank. Eine Bank endet entweder am Ende der Datei oder mit der Deklaration einer neuen Bank. Wie ein solches Programm dann aussieht, entnehmen Sie bitte Kapitel 3.2. Bänke müssen nicht benannt werden, dies ist allerdings für späteres Debuggen sehr hilfreich.

    2.3.6. Instruktionen und ihre Bedeutung

    Die RoboCom-Sprache umfaßt 12 verschiedene Anweisungen, die in der folgenden Tabelle zusammengefaßt sind.

    In der Spalte Instruktionssyntax geben a, b und c die nötige Parameteranzahl an. Dabei steht a für einen Parameter beliebiger Art, während #a für einen Parameter steht, der eine Variable sein muss, da die Anweisung einen Wert zurückliefert.

    Die Spalte ISet gibt an, welches Instruktions-Set für die Ausführung der Anweisung benötigt wird.
    Die Spalte Takte gibt an, wieviele Taktzyklen ein Roboter für die Ausführung der Anweisung benötigt.

    Die RoboCom-Sprache umfasst folgende Instruktionen:
     
    Instruktionssyntax  ISet  Takte  Funktion 
    ADD #a, b 
    0 
    6 
    		 Addiert den Wert b zur Variable #a. 
    BJUMP a, b 
    0 
    5 
    		 Führt einen unbedingten absoluten Sprung aus. Die Programmausführung wird in Bank a bei der b-ten Instruktion fortgesetzt. 
    COMP a, b 
    0 
    3 
    		 Vergleicht die Werte a und b. 
    Ist a ungleich b, so wird die Programmausführung mit der nächsten Instruktion fortgesetzt, ansonsten mit der übernächsten. Dadurch werden bedingte Sprünge überflüssig. 
    CREATE a, b, c 
    2 
    siehe
    rechts
    		 Veranlaßt den Roboter, auf dem Referenzfeld einen neuen Roboter zu bauen (sofern dieses frei ist). Der neue Roboter hat das Instruktions-Set a und besitzt b leere Speicherbänke. c gibt an, ob der zu kostruierende Roboter mobil sein soll (0 oder 1). Der neue Roboter ist zunächst inaktiv. 
    Benötigte Taktzyklen: 
       50  in jedem Fall 
    + 20  pro Bank 
    *   2   bei Mobilität 
    + 40  für Instruction Set 1
    + 80  für Instruction Set 2
    DIE 
    0 
    1 
    		 Veranlaßt den Roboter, sich nach Ablauf eines Taktzyklus selbst zu zerstören und vom Spielbrett zu verschwinden. 
    JUMP a 
    0 
    2 
    		 Führt einen unbedingten, relativen Sprung um a Instruktionen aus. 
    MOVE 
    0 
    18 
    		 Veranlaßt den Roboter, sich ein Feld vorwärts zu bewegen (sofern das Feld frei ist). Der Roboter muß mobil sein, um die Anweisung auszuführen. 
    SCAN #a 
    1 
    6 
    		 Scannt das Referenzfeld und liefert einen Wert in der Variable #a zurück. Das Referenzfeld ist bei 
    #a=0 ...leer. 
    #a=1 ...von einem gegnerischen Roboter besetzt. 
    #a=2 ...von einem eigenen Roboter besetzt. 
    SET #a, b 
    0 
    5 
    		 Setzt die Variable #a auf den Wert b. 
    SUB #a, b 
    0 
    6 
    		 Subtrahiert den Wert b von Variable #a. 
    TRANS a, b 
    1 
    siehe
    rechts
    		 Veranlaßt den Roboter, seine a-te Speicherbank in die b-te Speicherbank des Roboters auf dem Referenzfeld zu kopieren. 
    Benötigte Taktzyklen: 
    5 + (3 pro Instruktion in der Bank) 
    TURN a 
    0 
    5 
    		 Veranlaßt den Roboter, sich um 90° zu drehen, wo bei a die Drehrichtung angibt. Sie ist für a=0 links, ansonsten rechts. 
    Anmerkung: alle Taktzeiten können auf Wunsch auch beliebig konfiguriert werden. Mit alternativen Einstellungen läßt sich gut experimentieren, zumal sich einige Programme sehr anders verhalten.

    2.3.7. Kommentare

    Zur besseren Überschaubarkeit eines Programms können Kommentare eingefügt werden, die bei der Programmübersetzung ignoriert werden. Kommentare beginnen mit dem Zeichen ; und stehen entweder am Anfang einer Zeile an einer beliebigen Stelle im Programm, oder nach einer Anweisung. Beispiele: 
    ;Dies ist ein Kommentar.

Add #4, 1  ;Die Variable #4 wird um 1 erhöht.
     

    2.3.8. Labels

    Die RoboCom-Sprache unterstützt auch Labels. Diese werden vor der eigentlichen Assemblierung bereits durch Zahlen ersetzt. Prinzipiell sind Labels unnötig und müssen auch nicht verwendet werden. Sie erleichtern dem Programmierer seine Arbeit jedoch erheblich. Alle Labelbezeichner beginnen mit dem Zeichen @ und dürfen im Programm nur an einer Stelle definiert sein. Für die Definition eines Labels wird der Bezeichner im Anweisungsblock einer Bank eingefügt. Im übrigen Programm kann der Labelbezeichner als Konstantenparameter verwendet werden, der folgenden Wert liefert:
  • die relative Entfernung zur Definitionsadresse, sofern sich Definition und Referenz in der gleichen Bank befinden, bzw.
  • die (absolute) Nummer der auf das Label folgenden Anweisung in der Bank, in der das Label definiert ist, sofern sich Definition und Referenz in verschiedenen Bänken befinden.

    •  

     

    Betrachten wir ein Beispielprogramm, das auf zwei Arten realisiert wurde.
     
     

    ;RoboCom Programm
    Name Altbewährt

    Bank Hauptprogramm
      Add  #1, 1
      Turn 1
      Jump -2
     

    		 ;RoboCom Programm
    Name Jetzt-mit-Label

    Bank Hauptprogramm
      @Loop
      Add  #1, 1
      Turn 1
      Jump @Loop
     

     

    Das Programm bewirkt in beiden Fällen das gleiche: der ausführende Roboter erhöht die Variable #1, dreht sich um 90° nach rechts, und beginnt von vorn. Im Programm Altbewährt wird der Sprung durch die Anweisung Jump -2 realisiert, die bewirkt, daß die Programmausführung zwei Anweisungen davor, also bei Add fortgesetzt wird. Im Programm Jetzt-mit-Label steht vor dem Move das Label @Loop. Die Instruktion Jump @Loop verweist auf das Label. @Loop liefert hier die relative Entfernung zur Labeldefinition, also ebenfalls -2. Die beiden Quelltexte ergeben nach der Assemblierung genau das gleiche Programm, allerdings ist die zweite Methode komfortabler. Beispielsweise müsste man nach dem Einfügen weiterer Anweisungen vor dem Sprung im ersten Programm das Sprungziel neu errechnen und die -2 ersetzen, was im zweiten Beispiel entfällt. Die Verwendung von Labels beschränkt sich nicht auf Sprünge, beispielsweise wäre auch die Anweisung Comp #3, @Weiter denkbar, die den Wert von Variable #3 mit der Entfernung zu @Weiter vergleicht.

    2.4. Auto-Reboot

    Wenn die Programmausführung an eine Stelle gelangt, an der keine Anweisung mehr steht (z.B. nach der letzten Instruktion einer Bank), so wird die Programmausführung automatisch bei der ersten Instruktion der ersten Bank fortgesetzt. So kann man sich in einigen Schleifen einen Sprung sparen. Ist die erste Bank beim Auto-Reboot leer, so stirbt der Roboter.

    2.5. Ausnahmen und Fehler

    Immer wieder treten ungewollt Zustände auf, die der Programmierer nicht beabsichtigt hat. Sei es, dass ein Roboter das falsche Programm ausführt, daß er von einem gegnerischen Roboter manipuliert wurde, oder daß der Programmierer einen Fehler gemacht hat. Diese Situationen lassen sich in folgende Kategorien einteilen:

    2.5.1. Tolerierbare Ausnahmen

    Tolerierbare Ausnahmen sind unvorhergesehene Situationen für die es eine Regel gibt, die festlegt, wie sie gehandhabt werden. Wenn ein Roboter beispielsweise versucht, auf Remote-Variablen zuzugreifen, obwohl das Referenzfeld leer ist, so sind alle gelesenen Werte 0 und alle geschriebenen Werte gehen verloren. Dies dauert genauso lange, wie bei korrekter Ausführung der Anweisung. Es gibt noch eine ganze Reihe solcher tolerierbaren Ausnahmen, die hier aber nicht aufgeführt werden sollen.

    2.5.2. Laufzeitfehler (fatale Ausnahmen)

    Laufzeitfehler sind Ausnahmen, die eben nicht toleriert werden. Beispiel: ein nicht mobiler Roboter will die Move-Instruktion ausführen. Tritt ein solcher Fehler auf, stirbt der Roboter. Falls das Anzeigen von Fehlern eingeschaltet ist, wird eine Fehlermeldung generiert, die die Art des Fehlers näher beschreibt.

    2.5.3. Data Hunger

    Der sogenannte Data Hunger ist ein Spezialfall einer fatalen Ausnahme und hat keine Fehlernummer. Er tritt auf, wenn ein Roboter beim ersten Aktivieren oder nach dem Auto-Reboot die erste Speicherbank leer vorfindet.

    2.5.4. Eliminationen

    Von Zeit zu Zeit tritt die Situation auf, daß ein Roboter umprogrammiert wird und dabei den Endwert einer Schleife überschreitet. Beispielsweise wird eine Variable immer weiter erhöht und dann mit 10 verglichen, die Endbedingung wird aber nie wahr, da der Wert schon längst größer als 10 ist. Der Roboter hängt also in einer Endlosschleife ohne jegliche Produktivität. Um solche Roboter zu eliminieren, wurde der sogenannte Elimination Trigger eingeführt. Sobald eine Variable bei einer ADD- oder SUB- Instruktion einen bestimmten einstellbaren Wert über- oder unterschreitet, wird der Sonderfehler Elimination ausgelöst und der Roboter vom Spielfeld genommen.

    3. Jetzt geht's los!

    3.1. Aufruf von RoboCom

    3.1.1. RoboCom Version 1.x

    Das Spiel wird mit dem Aufruf ROBOCOM, gefolgt von den Dateinamen der spielenden Programme, gestartet. Dies können maximal fünf sein. Beispiel:

    C:\> robocom mine.rob wall3.rob pest.rob
     

    Wenn die DOS-Version von RoboCom unter Windows95 gestartet werden soll, muß ein Maustreiber geladen sein. Der RoboCom-Interpreter besitzt eine grafische Benutzeroberfläche und kann bequem mit der Maus bedient werden. Auf der linken Bildschirmhälfte wird das Spielbrett dargestellt, auf dem RoboCom die Initialroboter mit zufälliger Position und zufälliger Blickrichtung plaziert hat. Man kann dort die Bewegungen der Roboter verfolgen. Am rechten Rand befindet sich eine Leiste mit Steuerelementen. Hier können verschiedene Optionen eingestellt und der Verlauf der Simulation kontrolliert werden. Mit dem Startbutton wird die Simulation in Gang gesetzt. Übrigens wurden alle Routinen für Buttons, Scrollbars, Listboxen und die weiteren Dialogelemente auf BGI-Basis komplett selbst geschrieben.

    3.1.2. Das Shell-System

    Im Februar 1997 wurde das Shell-System RShell entwickelt. Es handelt sich dabei um ein Zusatzprogramm, das auf dem Bildschirm alle RoboCom-Programme anzeigt und eine Editierung auf Mausklick erlaubt. Ebenfalls kann der RoboCom-Interpreter aus der Shell heraus gestartet werden; die nötigen Parameter werden von RShell automatisch übergeben. RShell belegt etwa 85KB Speicher. Bei sehr speicherintensiven Simulationen ist es daher sinnvoll, auf das Shellsystem zu verzichten.

    3.1.3. Windows-Version

    Bei RoboCom 2.0 und höher handelt es sich um eine Version für Windows95 und NT, die einfach durch Anklicken des entsprechenden Icons gestartet wird. Kommandozeilen-Parameter sind nicht mehr notwendig; die zu ladenden Programme können in einem grafischen Dialog mit der Maus ausgewählt werden.

    Seit RoboCom 2.2 ist es auch möglich, Programme in einem verschlüsselten Binärformat (RBI) abzuspeichern. Werden RBI-Files wieder geladen, so zeigt der Debugger keine Informationen über den Programmcode an. Auf diese Weise kann ein Benutzer seine Programme an andere Autoren weitergeben, damit diese gegen seine Programme simulieren können, ohne jedoch sein Know-How preisgeben zu müssen.

    3.2. Ein einfaches Programm

    Dies ist ein einfaches Programm, das sogar schon eine sinnvolle Funktion hat:
    ;RoboCom Programm 
    Name Mine 

    Bank Mine            ; Erste Bank. Darin steht das Prog. 
      @Loop              ; Label am Beginn der Schleife 
      Turn 1             ; Rechtsherum drehen 
      Set %Active, 0     ; Potentiellen Gegner deaktivieren 
      Scan #1            ; Das Referenzfeld scannen 
      Comp #1, 1         ; Tatsächlich ein Gegner? 
      Jump @Loop         ; Nein, weiterdrehen 
      Trans 2, 1         ; Ja, Bank 2 transferieren! 
      Set %Active, 1     ; Reaktivieren damit er sie ausführt 
                         ; Auto-Reboot, weiterdrehen 

    Bank Giftig          ; Wer diese Bank ausführt... 
      Die                ; ...begeht Selbstmord! 
     
    Das Programm Mine erklärt sich schon weitgehend selbst. Es bewirkt, daß der Roboter sich ständig um die eigene Achse dreht und dabei jedem Gegner, den er antrifft, seine zweite Bank verabreicht, in der der Befehl zur Selbstzerstörung steht. Es erscheint vielleicht seltsam, dass Mine zuerst deaktiviert und dann scannt. Das liegt daran, daß der Gegner evtl. schneller sein könnte. Ist dieser erst einmal inaktiv, so hat Mine von ihm nichts mehr zu befürchten und kann in aller Ruhe scannen, ob dort überhaupt ein Gegner ist. Der Zugriff auf eine nicht-existente Remote-Variable (falls das Referenzfeld in diesem Fall leer ist) ist eine tolerierbare Ausnahme (siehe Kapitel 2.5.1.). Mine ist sehr einfach gehalten und transferiert sein "Gift" ausschließlich in die erste Bank des Gegners. Es kann natürlich nur wirken, wenn der Gegner diese Bank auch ausführt wird, was nicht unbedingt der Fall sein muß.

    3.3. Der Initialroboter und die Produktion weiterer Roboter

    Der erste Roboter (Initialroboter) eines Programms enthält alle Bänke, die im Quelltext deklariert wurden, hat immer das Super-Instruktions-Set (2) und ist in der Standard-Konfiguration nicht mobil. Möchte ein Spieler, daß sich seine Roboter bewegen, so muß er den Initialroboter so programmieren, daß er weitere Roboter baut. Dazu bedient sich der Spieler der Create-Anweisung. Da ein Programm oft um so erfolgreicher ist, je schneller es arbeitet, sollte man sich bei der Verwendung von Create Gedanken machen, welche Merkmale für den zu bauenden Roboter wirklich wichtig sind und auf unnötigen Luxus verzichten - schließlich dauert der Bau umso länger, je höher das Instruktions-Set und die Zahl der Bänke ist und wird durch Mobilität noch einmal extrem verlangsamt (siehe Kapitel 2.3.6.). Ein neu gebauter Roboter ist zuerst immer inaktiv, da er noch kein Programm besitzt, und sonst an einem Data Hunger sterben würde. Er muß also programmiert werden, was gewöhnlicherweise vom Mutterroboter mittels der TRANS-Instruktion getan wird.

    3.4. Programmvielfalt oder Einheitsbrei?

    Bereits in der frühen Entwicklungsphase von RoboCom hatte ich die Befürchtung, daß das Programmieren von Roboterstrategien schnell langweilig werden würde, da sich irgendwann ein Programmierschema ergeben würde, das so erfolgreich ist, daß alle folgenden Programme nur noch Abwandlungen der gleichen Strategie sind. Glücklicherweise stellte sich diese Vermutung letztendlich als falsch heraus: immer wieder gab es neue Ansätze und neue Konzepte für RoboCom-Programme, die alle auf unterschiedliche Weise erfolgreich sind. Man kann von "der" ultimativen Strategie schlechthin gar nicht sprechen, denn eine solche gibt es nicht. Alle Programme haben eigene Stärken und Schwächen. Beispielsweise gewinnt Megamorf (das zur Zeit der Entstehung dieser Anleitung erfolgreichste Programm) in den meisten Fällen gegen die meisten älteren Programme, ist jedoch einem seiner Vorgänger (MetaMORFosis), der generell sonst nicht so erfolgreich ist, weit unterlegen.

    3.5. Arbeitsweise verschiedener RoboCom-Programme

    Im folgenden werden einige Programme anhand ihrer Funktion kurz vorgestellt. Die kompletten Listings finden Sie im Internet unter http://www.cyty.com/robocom.

    3.5.1. Mine

    Das oben vorgestellte Beispielprogramm Mine arbeitet sehr defensiv. Läßt man zwei Minen gegeneinander antreten, so werden sie sich nie treffen, da Mine sich nicht bewegt (es sei denn, sie stehen zufällig auf benachbarten Feldern).

    3.5.2. Black Jacks

    Das Programm Black Jacks nimmt sich dieser Problematik an. Der Initialroboter produziert fortwährend neue Roboter, genannt Jacks. Jeder Jack bewegt sich über das Spielbrett und scannt systematisch die Felder. Jedem angetroffenen gegnerischen Roboter wird die traditionelle Bank aus der Mine (die nur die DIE-Anweisung enthält) in seine erste Bank kopiert. Schwächen von Black Jacks: 1. nur wirkungsvoll gegen Gegner, die die erste Bank ausführen. 2. Ist der Initialroboter außer Gefecht gesetzt, so werden keine neuen Jacks mehr hergestellt.

    3.5.3. 4Lunch

    4Lunch ist eine Abwandlung von Black Jacks. Die erste Bank enthält jeweils nur einen Sprung in die zweite, wo das eigentliche Programm steht. Vorteil gegenüber Black Jacks: immun gegen Gegner, die sich nur an der ersten Bank vergreifen.

    3.5.4. MetaMORFosis

    Hauptgrund für die Entwicklung von MetaMORFosis war die Tatsache, daß der Initialroboter bei Black Jacks oft früh außer Gefecht gesetzt wurde und das Programm damit so gut wie verloren hatte. Der Initialroboter bei MetaMORFosis hingegen baut MORFs (Mobile Roboter-Fabriken), diese bewegen sich über das Spielbrett und produzieren die altbekannten Jacks. Wenn es den Initialroboter erwischt, so sind meistens schon genügend MORFs aktiv, die gleichzeitig eine große Anzahl von Jacks bauen.

    3.5.5. Pesticide

    Das Programm Pesticide erinnert vom Konzept her start an MetaMORFosis. Allerdings sind die Jacks hier wesentlich intelligenter: auf die traditionelle Die-Bank wurde verzichtet, stattdessen wird das gegnerische Programm einfach gelöscht (realisiert durch das Überschreiben mit einer leeren Bank). Dies setzt den gegnerischen Roboter ausser Gefecht (Data Hunger). Außerdem ermitteln die Pesticide-Jacks die Anzahl der gegnerischen Bänke und löschen dann alle. Das dauert zwar wesentlich länger, ist dafür aber auch wesentlich sicherer.

    3.5.6. Wall Dry

    Wall Dry ist eines meiner Lieblingsprogramme. Es demonstriert anschaulich die meisterhafte Kooperation mehrerer Roboter ohne gegenseitigen Datenaustausch. Grundidee war, daß ein Roboter in den anderen Programmen weitgehend ungeschützt ist, da er sich nur über das Feld vor ihm informieren kann, während Gefahr von allen Seiten droht. Weiterhin 'vergeudet' ein herkömmlicher Roboter seine Zeit mit Bewegung, während Gegner ihn manipulieren könnten. Wall Dry baut eine defensive Struktur auf, bei der jeder Roboter eine genau zugewiesene Aufgabe hat. Wenn Wall Dry nicht gestört wird, reicht die Wand über das ganze Spielbrett.

    Die Roboter in der Mitte (die Wand selbst) tun nichts anderes, als nur den potentiellen Gegner auf dem Referenzfeld zu deaktivieren. Ausgenommen sind zwei Mittelroboter, die besondere Jacks bauen. Diese 'drängeln' sich über einen speziellen Algorithmus in die Außenreihen ein, bewegen sich praktisch 'immer an der Wand lang' und löschen die Programme der potentiellen Gegner, die auf irgendeine Weise in den Freiraum zwischen Wand und Außenreihe eingedrungen sind. Fazit: die Wand hält sich äußerst hartnäckig, auch bei vielen Gegnern. Sie kann natürlich im Normalfall nicht gewinnen, da sie nie in die Offensive geht, und nur sich selbst schützt. Das größte Problem der Wand ist jedoch, daß sie wegen störender Gegner meistens nicht dazu kommt, sich vollständig aufzubauen (der Aufbau dauert sehr lange), und dann doch nur als Ruine dasteht, die verletzlich, weil unvollständig ist. Sie arbeitet dann lange nicht so effektiv.

    3.5.7. Persuaders

    Persuaders 3.0 ist neben Wall Dry eines der interessantesten RoboCom-Programm. So makaber es auch klingen mag - die Arbeitsweise des Programms läßt sich am besten verstehen, wenn man es mit einer Sekte vergleicht. Der Initialroboter baut fortwährend weitere Roboter, genannt Gurus. Diese scannen das Spielbrett, ähnlich wie die Jacks. Wird ein Gegner entdeckt, so wird dieser nicht ausser Gefecht gesetzt, sondern bekehrt (sprich: umprogrammiert) - er wird ein Anhänger. Der Anhänger scannt nun ebenfalls wie ein Guru das Spielbrett und bekehrt weitere eigene Roboter. Nachdem drei Reihen des Spielbretts abgearbeitet wurden, gelangt das Programm eines Anhängers (im Gegensatz zum Guru) an eine DIE-Instruktion - der Roboter zerstört sich selbst. Merkmal von Persuaders ist, dass durch die doppelte Bekehrung viele Gegner in kurzer Zeit beeinflusst werden. Interessanter konsequenter Nebeneffekt: Persuaders kann seine Gegner immernoch besiegen, wenn kein einziger Persuaders-Roboter mehr existiert, so daß das Spielbrett komplett leer ist, was sonst fast nie vorkommt.

    3.5.8. Megamorf

    Das bis März 1997 erfolgreichste Programm war Megamorf, eine Synthese aus Pesticide, MetaMORFosis und dem hier nicht aufgeführten Programm 'Replicate!'. Der Initialroboter baut weitere Roboter, genannt Megamorfs, die, wie auch schon bei MetaMORFosis mobile Roboterfabriken sind. Megamorfs bauen immer abwechselnd eine spezielle Art Jack und dann einen Clone von sich selbst. Die speziellen Jacks verhalten sich ähnlich wie bei Pesticide und löschen alle Bänke. Die Klonierung der Megamorfs hat eine rapide Vermehrung zur Folge. Statistisch ist Megamorf den meisten älteren Programmen (ausgenommen MetaMORFosis) überlegen, was aber lange nicht heißt, daß ein anderes Programm nicht auch mit einer unterschiedlichen Strategie gegen Megamorf gewinnen kann. Es kommt nur seltener vor.

    3.5.9. Die "Clausthal-Epoche"

    Erfahrungsgemäß entstehen die besten Ideen, wenn viele RoboCom-Programmierer zusammenkommen, so auch auf dem Jugend Forscht Landeswettbewerb in Clausthal. Die Ideen von Persuaders und MegaMorf wurden weiterentwickelt, auch ganz neue Konzepte entstanden. Zu den wichtigsten Clausthaler Strategien zählen u.a. Flooder (Programme, die das ganze Spielbrett relativ schnell mit Robotern überfluten - Quantität statt Qualität), und auf der anderen Seite Viren (die aufgrund der hohen Roboterdichte durch Flooder natürlich ideale Verbreitungsbedingungen vorfinden). Das große Problem der Viren, das erst spät in den Griff bekommen wurde, war, daß sie sich regelmäßig selbst infizierten, so daß das Spiel nicht selten zufällig ausging. Letztlich etablierten sich mein Programm "UncleGeneration" und "Bisex" von Jörg Kubitz, die einen Virenschutz durch Selbst-Regeneration enthalten.

    3.5.10. Neuere RoboCom-Programme

    Bisher gab es immer wieder neue Programme, die besser sind als die bisherigen. So wurde mit "CopyBot" das Flooder-Konzept wieder aufgegriffen, jedoch integrierten die Autoren eine Selbstregeneration. Das Programm "Cairo" dagegen unterscheidet nicht mehr zwischen eigenen und gegnerischen Robotern und transferiert allen Artgenossen das gleiche Programm, jedoch werden die eigenen Artgenossen beim Bau mit einer Variablensignatur gekennzeichnet, die das gemeinsame Programm später einmal auswertet. "Strikers", auch ein vielversprechender Ansatz, verbreitet allgemeine Unproduktivität unter den anderen Robotern um dann später in aller Ruhe aufräumen zu können.

    3.6. Typische Fehler, die eigentlich keine sind

    Eine Zeitlang hatte ich den Eindruck, mein RoboCom-Interpreter sei von Fehlern nur so durchsetzt. Immer wieder traten Situationen auf, zu denen es eigentlich gar nicht hätte kommen dürfen. Beispielsweise verabschiedete sich ein Roboter mit der Fehlermeldung "Instruktions-Set 2 benötigt", obwohl das Programm, das ich für die Roboter seiner Farbe spezifiziert hatte, gar keine Instruktionen aus diesem Set verwendete. Ein anderer Fall waren Roboter, die in einer Endlosschleife festhingen - normalerweise sollte das Programm eine Variable auf 10 setzen und diese dann in einem Anweisungsblock dekrementieren, der solange wiederholt wird, bis die Variable den Wert 0 erreicht. Inzwischen lag der Wert schon bei -400 (also weit unter Null), und die Schleife lief immernoch. Diese Sonderbarkeiten führte ich zuerst auf Fehler im Interpreter zurück, bis ich feststellte, daß dieser völlig korrekt arbeitete und das was hier vorging nur die logische Konsequenz der Umstände war. Ich hatte bei meinen Überlegungen immer nur einen Roboter isoliert betrachtet, was nicht empfehlenswert ist. Hält man sich vor Augen, daß auf dem Spielfeld sehr viele Roboter verschiedene Dinge tun, so versteht man auch, daß es gelegentlich zu solchen Sonderbarkeiten kommen muß. Zur Verdeutlichung ein einfaches Beispiel:

    Ein Roboter hat die Absicht, auf seinem Referenzfeld einen Clone von sich zu produzieren. Dazu baut er mit Create einen zweiten Roboter mit Instruktions-Set 2. Anschliessend transferiert er in diesen sein eigenes Programm. Als die Programmausführung jedoch zur Create-Anweisung gelangt, bewegt sich ein fremder Roboter mit Instruktions-Set 1 auf das Referenzfeld. Da dieses nun belegt ist, kann der erste Roboter sein Create nicht ausführen. Er transferiert nun sein eigenes Programm, das eigentlich für den Clone bestimmt ist, in den fremden Roboter. Wenn dieser aktiviert wird, und den Code ausführt, kommt es zu einem Fehler, sobald die Programmausführung an eine Instruktion aus Set 2 gelangt, da der Roboter nur Set 1 besitzt. Auf ähnliche Art entstehen manchmal die wirrsten Situationen, die in den seltensten Fällen vorhersehbar und immer wieder faszinierend sind - denn es handelt sich um völlig logische Konsequenzen. Oft kann man die aus der näheren Untersuchung hervorgegangenen Erkenntnisse sogar in eigenen Programmen ausnutzen, indem man die beobachtete Situation bewußt und kontrolliert herbeiführt. Das Programm Persuaders beispielsweise ist so entstanden und programmiert ganz bewußt seine Gegner um.

    3.7. Zeit für eine Inspektion - der RoboCom Debugger

    In Kapitel 3.6. wurde schon angedeutet, wie komplex die Vorgänge während einer RoboCom-Session manchmal sein können. Für einen RoboCom-Programmierer ist deshalb eine Funktion sehr hilfreich, die es erlaubt, während des Spiels zu verfolgen, was die Roboter gerade tun, und diese evtl. zu beeinflussen, um zu kontrollieren, ob sich das jeweilige Programm wunschgemäß verhält. Deshalb implementierte ich in den Interpreter den RoboCom Debugger. Die Simulation kann nach Belieben schrittweise, blockweise oder kontinuierlich ablaufen, und zu beliebigen Zeiten unterbrochen werden. Klickt man während einer Unterbrechung, oder auch während der Laufzeit auf einen Roboter, so öffnet sich das Dialogfenster des Debuggers. Dieses zeigt alle Informationen über den Roboter an: Mobilität, Aktivität, das Instruktions-Set, die Anzahl der Bänke und der darin enthaltenen Instruktionen, den Inhalt aller Variablen und Konstanten, das gesamte Programm, das der Roboter derzeit besitzt und die nächste auszuführende Instruktion. Ausserdem erlaubt der Debugger dem Benutzer, den Inhalt von Variablen zu ändern, um das weitere Verhalten des Roboters zu testen. Durch den RoboCom Debugger wird die Programmierung sehr einfach und Fehler können schnell und sicher aufgespürt werden.

    Der Debugger in RoboCom 2.x erlaubt es sogar, mehrere Roboter gleichzeitig zu debuggen, während die Simulation weiterläuft!

    4. Schluß

    4.1. Kritischer Rückblick - Zielsetzung und Ergebnis

    Als mir die ersten Ideen zu diesem Projekt kamen, war ich mir - ehrlich gesagt - selbst noch nicht genau darüber im Klaren, was ich konkret entwickeln würde und orientierte mich noch stark an CoreWar. Mit der Zeit wurde die Zielsetzung jedoch immer klarer und das Projekt immer eigenständiger. Mit RoboCom habe ich das Ziel erreicht, ein Programmierspiel zu schaffen, das von Hobbyprogrammierern in kurzer Zeit erlernt werden kann, und doch für 'Insider', die sich länger damit beschäftigen möchten, immer wieder neue Ansätze bietet - die Vielfalt der möglichen Strategien ist groß. Besonders faszinierend finde ich auch die Möglichkeit der Programmierung kooperativer Systeme, wie Wall Dry (siehe Kapitel 3.5.6.).

    4.2. Aktuelles, Ausblick

    Der RoboCom-Interpreter ist eine solide und vollständige Basis für die komfortable Entwicklung von RoboCom-Programmen. In nächster Zeit wird die Windows-Version noch erweitert werden. Im wesentlichen werden neue Optionen für Experimentierfreudige hinzukommen.

    Um eine Wettbewerbsbasis für RoboCom-Programmierer zu schaffen, wurde im Frühjahr 1998 ein automatischer Internet-Server eingerichtet, der die via CGI eingesandten neuen Programme separat gegen jedes der anderen Programme antreten läßt, statistisch die Gewinnquote ermittelt und anschließend eine Rangliste erstellt; RoboCom-Programmierer können auf diese Weise unkompliziert die Effizienz ihrer Programme testen. Darüberhinaus bietet der Server RoboCom-Programme im Quellcode und im verschlüsselten RBI-Format zum Download an.

    Im April 1998 habe ich RoboCom zusammen mit dem Goethe Institut im Rahmen des Medienprojekts "Open windows on Europe" in Stockholm vorgestellt. Es gab dort fünf RoboCom-Präsentationen und einen Workshop. Außerdem fand in Stockholm auch der erste Internet-Wettbewerb statt.

    Eine weitere Idee ist die Entwicklung eines neuen Interpreters, der ständig mehrere hundert Programme auf einem riesigen Spielbrett laufen läßt, wobei neue Programme zu jedem beliebigen Zeitpunkt in die Simulation eintreten können. Diesen Interpreter könnte man ebenfalls im Internet laufen lassen. Es wäre interessant, zu erfahren, wie sich die Programme in dieser neuen Umgebung etablieren: lokal in einem Bereich des Spielbretts? Über das ganze Spielbrett verstreut? Noch viele weitere Möglichkeiten sind denkbar - es wird sich zeigen, welche davon letztendlich auf welche Weise realisiert werden. 

    5. Literatur- und Linkverzeichnis

    [1] Die RoboCom-Homepage
    http://www.cyty.com/robocom

    [2] Dennis Homepage
    http://www.provi.de/~slxbemm/dennis/

    [3] Open windows on Europe (Internet-Projekt in Stockholm)
    http://www.comedia.se/fonster98

    [4] Durham, Mark u.a.: Draft of Proposed 1994 CoreWar Standard, Version 3.2
    ftp://ftp.csua.berkeley.edu/pub/corewar/documents/icws94.0202.Z

    [5] Strack, Stefan: CoreWar Frequently Asked Questions
    http://www.stormking.com/~koth/corewar-faq.html

    Anhang A: Laufzeitfehlerverzeichnis

    RoboCom unterscheidet derzeit 12 fatale Ausnahmen. Diese sind hier jeweils mit einer kurzen Beschreibung aufgeführt. Die Angabe "Ursache" gibt nicht nötigerweise alle Fälle wieder, die zu dem jeweiligen Fehler führen. Die Konsequenz ist jeweils, daß der Roboter stirbt.

    Error 1 - Undefined instruction
    Ursache: der Roboter versucht, eine Instruktion auszuführen, die es nicht gibt.

    Error 2 - Undefined variable
    Ursache: Der Roboter verwendet eine Variable, die nicht definiert ist.

    Error 3 - Undefined constant
    Ursache: Der Roboter verwendet eine Konstante, die nicht definiert ist.

    Error 4 - Undefined remote variable / constant
    Ursache: Der Roboter verwendet eine Remote-Variable oder -Konstante, die es nicht gibt.

    Error 5 - Instruction set 1 required
    Ursache: Der Roboter versucht, eine Instruktion auszuführen, die das erweiterte Instruktions-Set benötigt, ohne dieses Set selbst zu besitzen.

    Error 6 - Instruction set 2 required
    Ursache: Der Roboter versucht, eine Instruktion auszuführen, die das Super-Instruktions-Set benötigt, ohne dieses Set selbst zu besitzen.

    Error 7 - Value expected
    Ursache: Das Programm des Roboters übergibt beim Aufruf einer Instruktion weniger Parameter, als diese benötigt.

    Error 8 - Too many parameters
    Ursache: Das Programm des Roboters übergibt beim Aufruf einer Instruktion mehr parameter, als diese benötigt.

    Error 9 - Not mobile
    Ursache: Der Roboter versucht, die Move-Instruktion auszuführen, ist jedoch nicht mobil.

    Error 10 - Constant may not be modified
    Ursache: Der Roboter versucht, eine Konstante zu ändern, oder übergibt einer Instruktion, die zwecks Ergebnisrückgabe eine Variable erwartet, eine Konstante.

    Error 11 - Invalid number of banks
    Ursache: Der Roboter versucht, einen Roboter zu bauen, der mehr als 50 Bänke hat.

    Error 12 - Source bank does not exist
    Ursache: Der Roboter versucht, eine Bank zu transferieren, die nicht existiert.

    (C) Copyright by Dennis C. Bemmann. 
    RoboCom Homepage
    Dennis Homepage
    Mail an Dennis schicken

    2B OR (NOT 2B) That is the question. The answer is FF.