MAGAZIN | donkey.bas im Unterricht
Unseren Hörer Sebastian Thurau kennen Spieler von Das Schwarze Auge als Autor zahlreicher Abenteuer-Bände, im Hauptberuf ist er aber Informatiklehrer. Als solcher hat er einen Spiele-Klassiker als Unterrichtsmaterial aufbereitet: donkey.bas.
Sebastian, du hast ein 60-seitiges Dokument mit einer detaillierten Erklärung und Analyse des BASIC-Quellcodes von donkey.bas geschrieben. Wie kam es dazu?
Sebastian: Schuld hatte Stay Forever, vor allem aber Henner. Donkey.bas ist ja zu einem inoffiziellen Maskottchen für Stay Forever geworden, und Henner hatte auch schon etwas zur Entstehungsgeschichte erzählt. Ich wollte mir das Spiel dann mal anschauen und bemerkte, dass es aus gerade einmal 131 Zeilen Quellcode besteht. Meine ersten Programmiererfahrungen habe ich mit Turbo Pascal im Jahr 1994 gemacht, mit BASIC hatte ich dagegen noch nie programmiert. Irgendwie war meine Neugier geweckt, und donkey.bas war ein guter Anlass, sich mit Hilfe eines uralten Handbuchs in BASIC einzuarbeiten. Und als Informatiklehrer habe ich das Privileg, aus diesen spleenigen Ideen gleich noch Unterricht machen zu können. Deswegen ist dann auch das Skript entstanden.
Kannst du für die wenigen unserer Leserinnen und Leser, die donkey.bas nicht kennen, kurz die Bedeutung des Spiels erklären?
Donkey.bas gilt als erstes PC-Spiel, wobei man hier „PC“ definieren müsste als Computer, auf denen ein Microsoft-Betriebssystem läuft. Im Spiel selbst lautet der Name nur Donkey, aber das Spiel ist heutzutage unter seinem Dateinamen donkey.bas bekannt – die Endung steht für eine BASIC-Datei. Der Legende nach wurde das Spiel von Bill Gates und Neil Konzen auf einem frühen Prototyp eines IBM-PCs entwickelt, der aus vertraglich vereinbarten Sicherheitsgründen in einem abschließbaren Raum stehen musste. Da Microsoft damals noch eine recht kleine Firma war, war der abschließbare Raum ein Wandschrank, in dem die beiden je nach Quelle an einem Wochenende oder in einer Nacht das Spiel programmiert haben, um die Leistungsfähigkeit der mit MS-DOS mitgelieferten BASIC-Umgebung zu demonstrieren.
Das Spiel ist simpel: Der Spieler steuert ein Auto auf einer zweispurigen Straße, durch einen Druck auf eine Taste wechselt es die Spur. Im oberen Bereich taucht ein Esel auf einer der beiden Spuren auf. Der Esel bewegt sich auf dem Bildschirm recht zügig nach unten, wobei der animierte Mittelstreifen simuliert, dass das Auto fährt und sich so dem Esel nähert. Wenn man mit dem Esel kollidiert, scheitert man. Weicht man elf Eseln am Stück aus, erhält man einen Punkt.
Du kommst in deiner Analyse zur überraschenden Erkenntnis, dass donkey.bas gar kein Geschicklichkeitsspiel sei. Wieso das?
In der deutschen Wikipedia steht, dass donkey.bas ein Rennspiel sei. Das ist definitiv falsch, weil man sich mit niemandem ein Rennen liefert. Das Spiel mutet an wie ein Geschicklichkeitsspiel, weil man ja den Eseln ausweichen muss. Außerdem rutscht das Auto immer ein bisschen weiter nach oben, so dass sich die Reaktionszeiten verkürzen.
Man muss donkey.bas aber nicht als Geschicklichkeitsspiel spielen. Der Esel erscheint scheinbar zufällig auf der linken oder der rechten Spur. Sein Erscheinen wird zwar mit einem in BASIC typischen Zufallsbefehl bestimmt, aber tatsächlich ist die Erscheinungssequenz immer gleich.
Wie kommt das? Zufälle gibt es in einem Computer nicht, nur scheinbare Zufälle. Eine Funktion bekommt einen Startwert und berechnet dann ein Ergebnis, das dem Anwender wie ein Zufallswert erscheint. Der nächste „Zufallswert“ ist dann vom vorherigen „Zufallswert“ abhängig. Das geht dann immer so weiter. Damit man einen für Spielende zufälligen Spielablauf hat, muss der Startwert variieren, weil sonst immer die gleiche Sequenz an Zufallszahlen generiert wird. Das kann man zum Beispiel dadurch realisieren, dass man den Startwert von der Systemzeit oder dem Systemdatum abhängig macht. Das ist bei donkey.bas aber nicht der Fall, die dafür notwendigen Zeilen befinden sich nicht im Quellcode. Die Zufallssequenz ist daher nicht zufällig, sondern immer gleich, weshalb man den ersten Level schafft, wenn man den ersten Esel rechts passiert und dann links, links, rechts, rechts, links, links, links, links, links und noch einmal links fährt.
Sollte man einen Fehler machen und mit dem Esel kollidieren, dann werden sieben zufällige Töne abgespielt, wodurch man in eine zweite Zufallssequenz wechselt. Kollidiert man dann erneut, werden wieder sieben Zufallstöne abgespielt und man wechselt auf die ursprüngliche Zufallssequenz zurück, wenn auch zu einem später Zeitpunkt. Spielt man fehlerfrei, muss man aber nur die erste Sequenz lernen. Ähnlich wie z.B. Dragon’s Lair ist donkey.bas also eigentlich ein Merkspiel, das sich als Geschicklichkeitsspiel tarnt.
Außerdem stellst du die These auf, dass der eigentliche Protagonist des Spiels der Esel sei.
Wenn man die wenigen Bildschirmtexte liest, stellt sich schon die Frage, ob man da nicht gegen Superesel antritt, das eselige Äquivalent zu Superman.
Zunächst heißt das Spiel donkey.bas, nicht donkeys.bas. Es geht als nicht um mehrere Esel (die wohl ursprünglich einmal Kühe sein sollten, das Sprite sah dann aber doch eher wie ein Esel aus, weshalb das Spiel umbenannt wurde), sondern nur um EINEN Esel. Dieser erscheint vor dem Auto. Weicht man dem Esel aus, muss er das Auto offensichtlich außerhalb des Bildschirms überholen und wirft sich dann erneut auf die Straße.
Jetzt kann man sich natürlich über das kleine „s“ am Ende streiten, aber es wird noch kurioser: Wenn man als Spieler elfmal dem Esel ausgewichen ist, erhält man einen Punkt. Der Esel bekommt aber ebenfalls Punkte, und zwar immer dann, wenn er sich anfahren lässt. Weicht man ihm oft genug aus, erscheint eine Texteinblendung, die aber nicht dem Spieler zum Ausweichen gratuliert, sondern „Donkey loses!“ verkündet. Der Esel verliert also, wenn er es nicht schafft, oft genug mit dem Auto zu kollidieren. In der Narration des Spiels möchte der Esel offenbar gar nicht überleben, sondern durch sein Selbstopfer in mehrere Teile zerlegt werden. Zu einem solchen Verhalten passen andere Tiere vermeintlich besser, donkey.bas hätte also eigentlich lemmings.bas heißen müssen …
Wie beurteilst du die Qualität von Bill Gates‘ BASIC-Code in donkey.bas?
Quellcode ist selten perfekt, und der von donkey.bas ist es auch nicht. Man findet darin unnötige Zeilen und ungenutzte oder zu großzügig dimensionierte Variablen. Manche Probleme werden auf verschiedene Arten gelöst, etwa das Anlegen der Variablen für die Grafik von Esel und Auto, das Zeichnen von verschiedenen Teilen des Autos und verschiedene Abfragen von fehlenden Tasteneingaben. Das liegt vermutlich an der Zusammenarbeit von zwei Programmieren. Andere Teile sind nicht so elegant implementiert worden, wie es möglich gewesen wäre, etwa das Darstellen des Spiels auf dem Bildschirm oder das mehrfache Setzen der Position des Autos.
Dennoch zaubert donkey.bas in gerade einmal 131 Zeilen ein Spiel auf den Bildschirm, das die Möglichkeiten eines IBM-PCs im Jahr 1981 in Sachen Grafik und Sound genutzt hat.
Schaut man sich den Code genauer an und unterscheidet in vollkommen unnötige, weil fehlerhafte oder nur für Anmerkungen genutzte Zeilen, reduziert sich der Code um 11 Zeilen auf gerade einmal 120 Zeilen. Würde man dann den Teil zum Abprüfen auf das Vorhandensein einer CGA-Grafikkarte und die etwas aufwändigere Fehlerbehandlung verzichten, würde der Code noch einmal 21 Zeilen kürzer ausfallen, womit das Spiel nur noch 99 Zeilen lang wäre. Rechnet man dann noch die 16 Zeilen für den Titelbildschirm heraus, erhält man ein mit 83 Zeilen sehr kompaktes Spiel. An manchen Stellen könnte der Code noch etwas optimiert werden, aber dafür zeigt er sehr viele Aspekte von BASIC für MS-DOS.
Hat dich irgendwas an donkey.bas beeindruckt?
Ich bin mir nicht sicher, ob Bill Gates eine didaktische Mission in dem Quellcode gesehen hat, aber man kann das Programm wunderbar als Basis für ein BASIC-Tutorial nutzen. Es geht um Ein- und Ausgaben, Fallunterscheidungen und Schleifen, erst um einfache Variablen und dann um Arrays. Zuerst wird der Textmodus genutzt, danach der Grafikmodus. Es gibt Töne, die abgespielt werden, Grafiken werden gezeichnet und schließlich sogar animiert. Dabei wird der Anspruchsgrad wunderbar gesteigert, so dass man beim Nachvollziehen des Codes mit zunehmend komplexeren Aufgaben konfrontiert wird.
Dabei gibt es auch ein paar findige Kniffe, etwa wenn durch bitweise Additionen die Farbe eines Pixels von weiß auf schwarz gewechselt wird, nur um dann etwas später mit derselben Operation wieder von schwarz auf weiß zurückzugehen. Auch bewegen sich grafische Elemente, die nicht etwa als Datei abgespeichert sind, sondern prozedural vom Programm erzeugt werden. Nach dem Titelbildschirm werden das Auto und der Esel auf den Bildschirm gezeichnet, anschließend als Sprites gespeichert und immer wieder genutzt. Da gibt es also ein paar elegante Lösungen, und wenn man sich überlegt, was im Jahr 1981 auf einem PC mit wenig RAM, einer CGA-Grafikkarte und dem internen Speaker möglich war, dann demonstrieren die wenigen Codezeilen schon sehr gut, welche technischen Spielereien ein IBM-PC damals bot.
Dein Dokument ist für den Unterricht gedacht, an wen richtet sich das, wie setzt du es ein?
Ich würde heutzutage BASIC nicht als erste textbasierte Programmiersprache unterrichten, dafür eignet sich z.B. Python mit Pygame deutlich besser, aber ich habe immer wieder besonders interessierte Schülerinnen und Schüler, denen sich hier eine neue Herausforderung bietet. Der Code ist an manchen Stellen deutlich hardware-näher als moderner Quellcode, manche heute einfach lösbaren Probleme mussten damals anders gelöst werden. Im Rahmen von Differenzierung können hier also nicht nur neue Herausforderungen gestellt werden, gerade die an Computern (und oft auch Computerspielen) interessierten Schülerinnen und Schüler können hier auf eine historische Reise gehen, die zu den Anfängen ihres Hobbys führt.