» » » Retro Game Programming: Teil 1

Retro Game Programming: Teil 1

in Tutorials | 0

Retro Game Programming - Teil 1

Los geht’s: Die Spielidee

Im Forum von Pixelor.de diskutieren wir immer wieder begeistert über aktuelle Spiele-Entwicklungen für Homecomputer der 80er-Jahre. Da stellt sich die Frage: Warum eigentlich nicht mal selber machen? Genau: Warum eigentlich nicht? Und schon geht’s los!

Genau genommen wollte ich in den letzten Jahren schon immer meinen alten Atari-8-Bit-Computer aus der Mottenkiste kramen, wiederbeleben und ein Spiel für ihn programmieren. Das Ganze verbinde ich nun gleich mit einer Serie an Beiträgen hier auf Pixelor.de, in denen ich alle möglichen und nötigen Überlegungen zu so einem Projekt festhalten werde. Das, was ich hier machen möchte, soll bewusst kein »Überflieger-Spiel« werden. Ganz im Gegenteil: Es soll eher eine Fingerübung sein. Ein kleines Spiel, welches hoffentlich schnell fertig gestellt ist und mit dem ich einfach mal wieder in 8-Bit-Gefilde reinschnuppern kann.

Eine der wichtigsten Voraussetzungen: Es soll auf jeden Fall Spaß bringen. Und damit steht am Anfang …

Die Spielidee

Ich bin in mich gegangen und habe mir überlegt, was es eigentlich für ein Spiel werden soll. Da gehe ich natürlich von meinen eigenen Vorlieben aus. Zum Beispiel mag ich Labyrinth-Spiele. Sprich: Eine Spielfigur wird irgendwo an einem unbekannten Ort ausgesetzt und muss gegen allerlei Gefahren kämpfen. Erinnerungen an »Berzerk« [1] sind durchaus gewollt. Außerdem gefällt mir »Yars‘ Revenge« [2] (Original: Atari VCS 2600). Also mit einer Barriere, durch die man sich hindurch schießen muss. Nach weiterem kurzen Nachdenken fällt mir folgendes ein, was ich einfach mal aufschreibe:


Die Spielfigur erscheint in einem rechteckigen Raum, aus dem sie zunächst nicht heraus kommt. Das Geschehen wird von oben gezeigt und Ausgänge in allen vier Himmelsrichtungen sind zwar eingezeichnet, aber noch verschlossen. Genauer gesagt bedeutet eine Berührung mit den Wänden des Raumes den Verlust eines Spiele-Lebens. Von links oder rechts nähert sich nun langsam eine gleißende und ebenfalls tödliche Energie-Barriere. Sie füllt die komplette Höhe des Raumes aus und Ausweichen ist also nicht. Aber die Spielfigur kann schießen. Sie muss nun eine Lücke in diese Barriere schießen, die so groß ist, dass die Spielfigur hindurch passt und die Barriere sie nicht berührt.

Wenn die Spielfigur einen gewissen Teil der Barriere zerschossen hat, taucht innerhalb der Umrandung der Barriere ein Energiefeld auf. Dieses muss der Spieler ebenfalls zerstören. Hat er das geschafft, öffnen sich die Ausgänge und der Spieler kann einen weiteren Raum betreten.

Insgesamt gibt es 4 mal 4 Räume, die der Spieler bewältigen muss, um das Spiel zu gewinnen. Ein Radar zeigt an, in welchem Raum sich der Spieler gerade befindet. Jeder Treffer bringt Punkte, jeder erledigte Raum noch einmal zusätzliche Punkte. Ab einer bestimmten Punktzahl gibt es ein Extraleben.

Stirbt die Spielfigur durch Berührung der Wände oder der Energiebarriere, dann wird ein Leben abgezogen und der gerade gespielte Raum wird erneut gespielt. Sind keine Leben mehr übrig, ist das Spiel vorbei.


Sodele, das war kurz und schmerzlos. Ich möchte betonen, dass das erst einmal nur eine grobe Skizze des Spiels ist, also eher eine Art »Brainstorming«. Es ist bei weitem keine Blaupause, die man genau so programmiert und dann ein fertiges Spiel hat. Im Laufe der Entwicklung tauchen bestimmt Probleme auf, so dass das Spielprinzip abgewandelt werden muss. Aber irgendwo muss man ja mal anfangen, und das ist meine Ausgangssituation. Nebenbei und für mich privat gefühlt könnte dieses Spiel auch aus dem Film »Tron (1991)« stammen. Für ein Retro-Spiel ist das also nicht die schlechteste Ausgangssituation.

Retro Game Programming: Mockup
Eine erste Layout-Idee des Spielbildschirms

Aber noch einmal kurz zum wichtigsten Kriterium eines Spiels, und zwar egal welches: Es soll Spaß bringen! Es soll den Spieler motivieren, und es darf weder zu einfach noch zu schwer sein. Passt das bei dieser Spielidee? Kurz mal nachdenken: Die Motivation kommt nach einer ersten Abschätzung – alles noch in Gedanken, es ist noch keine Zeile programmiert – dadurch zustande, dass man als Spieler alle Räume »schaffen« will. Obendrein will man einen möglichst hohen Score erspielen. Motiviert das? Ja, ich denke schon. Das sind schon mal zwei Faktoren, die für die Spielidee sprechen.

Jetzt die schwierigere Frage: Stimmt der Schwierigkeitsgrad dieser Spielidee? Ehrlich Antwort: Ich habe nicht den Schimmer einer Ahnung! Das kann man »auf dem Papier« nicht abschätzen, denn die obige Beschreibung könnte auch der Klappentext eines Spiels sein. Und wie oft hat man sich beim Lesen solcher Zeilen gedacht: »Oh, klasse!« Und beim ersten Spielen war es dann der letzte Rotz. Außerdem hängt sehr viel von der Steuerung ab und wie sich das Spiel allgemein »anfühlt«. Das wird man also einfach alles sehen müssen und ich werde das Spiel dann entsprechend anpassen.

Ich ganz persönlich habe noch ein paar weitere technische Anforderungen an das Spiel. Nämlich …

Rahmenbedingungen

  1. das Spiel soll auf einem Atari-8-Bit-Computer laufen
  2. das komplette Spiel soll in 4 KByte passen
  3. es soll mit 16 KByte RAM auskommen
  4. es soll auf NTSC wie PAL laufen

Ich erläutere die Punkte mal der Reihe nach. Der erste ist ganz einfach erklärt: Ich selber kenne die Atari-8-Bit-Computer sehr gut (also nicht »Atari ST«, sondern die Vorgänger-Generation) und muss wenig bis gar nichts dazulernen. Das ist übrigens für ein erstes Spiele-Projekt ein nicht unerheblicher Faktor. Denn ich will mich ja erst einmal darauf konzentrieren, überhaupt ein spielbares Spiel zu entwickeln. Wenn ich dann auch noch zusätzlich die Eigenheiten einer mir unbekannten Hardware lernen müsste, dann kostet das einfach zusätzliche Zeit. Natürlich würde ich auch gerne mal etwas für »Mega Drive« oder »Dreamcast« programmieren. Nur habe ich im Moment von diesen Spielkonsolen eine programmiertechnische Ahnung, die nahe an Null heran reicht. Also lieber erst einmal nicht.

Punkt 2 ist einfach … naja … ich nenne es mal »sportlich« gemeint. Ich will einfach sehen, ob so etwas geht. Außerdem gehöre ich selber noch zu einer Generation, die den Wert eines einzelnen Bytes zu schätzen weiß. Wenn es partout nicht klappen will oder ich während der Entwicklung die Mega-Idee habe, durch die das Spiel noch mehr Spaß bringt und es dadurch nicht mehr in 4 KByte passem sollte … ja dann … so what? Dann wird’s es eben größer. Aber erst mal halte ich daran fest.

Punkt 3 ist der Architektur der 8-Bit-Computer geschuldet: Es gibt Modelle mit 16, 64 und 128 KByte RAM, die untereinander auf- und abwärtskompatibel sind. Ein Spiel auf einem 16-KByte-Computer läuft – ein paar Kleinigkeiten beachtet – auch auf den größeren Modellen. Und damit liefe dieses Spiel auf allen Atari-Computern (Ausnahme: Atari 1200XL, den es aber in Europa nicht zu kaufen gab). Außerdem ist es aufgrund von Punkt 2 unwahrscheinlich – so mal rein über den krummen, zitternden Daumen gepeilt – dass ich mehr RAM benötigen werde.

Punkt 4 hat ebenfalls etwas mit der Atari-Architektur zu tun, trifft aber auch auf andere Homecomputer und ältere Konsolen zu. Zum einen geht es um die Geschwindigkeit, mit der der Bildschirmaufbau erfolgt. NTSC-Computer laufen mit 60 Hz Bildwiederholrate, PAL-Geräte dagegen mit 50 Hz. Das ist für das interne Timing des Spiels wichtig (dazu komme ich in einem späteren Teil). Hier nur so viel: Bei 50 Hz hat man zwischen zwei Bildaufbauten ein wenig mehr Zeit für interne Berechnungen. Optimiert man ein Spiel für PAL, läuft dieses evtl. nicht mehr auf einem NTSC-Gerät. Darauf also aufpassen! Außerdem gibt es noch eine Spezialität des Atari-Computers: Das PAL-Gerät stellt mehr Bildschirmzeilen zur Verfügung. Das alles umgehe ich, indem ich das Spiel grundsätzlich im NTSC-Modus entwickle und zwischendurch immer mal wieder schaue, ob es auch noch auf PAL läuft. Eine Geschwindigkeitsanpassung der dargestellten Grafik – Bewegungen von Barriere, Spielfigur und was mir sonst noch einfällt – werde ich nicht vornehmen. NTSC läuft schneller! Basta!

Aber mal ganz grundsätzlich gefragt: Warum belaste ich mich eigentlich zusätzlich mit diesen Rahmenbedingungen? Ist die Programmierung für ein 8-Bit-System im Jahre 2017, in dem aktuelle PCs mit 32 GByte RAM ausgerüstet sind und damit rund 8 Millionen mal mehr RAM als mein Spiel zur Verfügung haben, ist das nicht sowieso schon kompliziert und ungewöhnlich genug? Ich sag mal so: Nichts motiviert mich (wirklich mich persönlich) so sehr, wie Limitierungen. »Viel hilft viel« kann jeder. Etwas mit wenig zu schaffen ist dagegen eine Kunst.

Aber das muss jeder für sich abschätzen.

Entwicklung einer Spielidee

Im Folgenden möchte ich noch einmal ganz grundsätzlich ein paar Zeilen zur Entwicklung einer Spielidee loswerden. Die sind sicherlich auch sehr persönlich und privat. Aber mal so unter uns Pastorentöchtern und bewusst provokant formuliert:

Neue Spielideen gibt es nicht! Punkt!

Damit meine ich ganz grundsätzliche Spielmechaniken, die sich in den letzten 35 bis 40 Jahren entwickelt und etabliert haben. Sämtliche Spielmechaniken von 2D-Spielen basieren auf Abwandlungen der Arcade-Klassiker eben der letzten vier Dekaden. Denkt also am Anfang gar nicht darüber nach, was man vielleicht noch anders machen könnte. Denn selbst, wenn ihr eine neue Idee findet, bedeutet es noch lange nicht, dass diese auch Spaß bringt.

Retro Game Programming: Berzerk
Für das Spiel steht definitiv Berzerk (hier Atari 800) Pate

Was es aber gibt, sind neue Ansätze, wie man was macht. Für das erste Spiel sollte man sich also nicht scheuen, einfach links und rechts zu schauen, was es schon gibt, eigene Ansätze hinzufügen und das dann einfach mal zu machen.

Und das ist vor allem wichtig: Einfach mal machen! Dann sieht man, ob das einem überhaupt liegt. Für mich ist das hier auch ein Experiment, denn ich habe noch nie ein Spiel entwickelt. Viel wichtiger ist aber, dass man zu einem gewissen Teil vorausdenkt, aber diese Gedankenplanung ab einem bestimmten Punkt auch wieder abbricht. Sonst macht man sich evtl. viel zu viele Gedanken über Probleme in der Entwicklung, die eventuell gar nicht auftauchen werden.

Konkretes Beispiel: In diesem Spiel gibt es 16 Räume. Ich habe mir außerdem selber den Speicherplatz auf 4 KByte beschränkt. Kann man darin überhaupt 16 unterschiedliche Räume abbilden? Ja, natürlich! Zum einen sieht der Raum nahezu immer gleich aus. Es werden lediglich vielleicht mal neue Wände in den Raum gesetzt. Der Programmteil zum Erzeugen aller Räume wird also immer derselbe sein. Lediglich für die Wände gibt es ein paar unterschiedliche Optionen. Die Programmierung traue ich mir durchaus zu.

Und an dieser Stelle breche ich meine Überlegungen ab. Ich habe ein ganz gutes Gefühl, dass ich mit meinem bisherigen Erfahrungsschatz hinzubekomme. Sollten tatsächlich Probleme auftauchen, lasse ich mir zum gegebenen Zeitpunkt etwas einfallen. Und zur allergrößten Not ist das Spiel dann eben nicht 4 KByte sondern 5, 8 oder 16 KByte lang (aber wirklich nur notfalls). Auf jeden Fall habe ich diesen Punkt schon mal abgehakt und kann mich auf anderes konzentrieren.

Ach so, allgemein zum Thema »Nachdenken«: Bei mir hilft es, komplett artfremde Dinge zu tun. Also zum Beispiel: »Zimmer aufräumen«, »Garten umgraben«, »Küche sauber machen« usw. oder auch einfach mal entspannt in der heißen Badewanne liegen. Dabei kommen mir meistens die nettesten Ideen. :-)

Wie geht’s weiter

Im nächsten Teil stlle ich die Programmierwerkzeuge vor, die ich für dieses Spiel benutzen werde. So viel sei schon mal verraten: Ich werde nicht auf Originalhardware programmieren, sondern einen Emulator benutzen und die eigentliche Programmierung mit einem auf dem PC laufenden Cross-Assembler leisten. Die Idee ist aber, dass das Spiel auch auf einer originalen Hardware läuft.

So viel erst einmal dazu. Ich würde mich darüber freuen, wenn ihr mit mir im Forum von Pixelor.de über das Projekt diskutiert. Den Link zum Thread findet ihr weiter unten.

Links:
[1] Kraut & Rüben & Videospiele 41 – Berzerk
[2] PELKITSCH #138: Yars´Revenge für das Atari VCS 2600
[3] Diskussionsthread im Forum vom Pixelor.de

Update:
28-Mär-2017; dank an Acrid für die Korrekturvorschläge

Kommentare sind geschlossen.