Hallo in die Runde,
kurz vor Weihnachten und nach fast 6 Monaten der Entwicklung möchte ich hier gerne mal eine kleine Zwischenbilanz ziehen und ein paar kleine zusammenfassende Einblicke geben, wie sich der Weg von CoE gestaltet hat ...
Caverns of Eris soll die geschichtliche Fortsetzung von Battle of Eris werden, ist aber optisch und technisch völlig anders.
Ich wollte mit diesem Projekt ein reines Ballerspiel nach dem Vorbild von Zybex bauen, dabei aber auch experimentell einige Dinge für mich entwickeln und hoffte das dann alles in einen schönen Shooter zusammenzubringen.
Zunächst habe ich mich um das Parallax Scrolling gekümmert. Dabei habe ich gelernt, wie man mittels mehrerer DLI´s das horizontale Scrolling in verschiedenen Geschwindigkeiten ausführen kann - am Ende scrollt der hintere Teil langsamer, als der vordere und es entsteht der gewünschte Parallax-Effekt. Viel später habe ich das dann ganz anders gelöst, der ganze erste Teil ist in meinem Programm inzwischen entweder abgeschaltet oder gelöscht.
Danach habe ich sehr lange überlegt, wie ich die Player und die Landschaft baue. In Battle of Eris geht viel Rechenpower ins Scrolling - wenn man nicht aufpasst kann das schnell instabil werden mit den ganzen DLI´s und VBI usw.
Gleichzeitig fand ich die Thematik mit den Softwaresprites sehr mysteriös wie spannend. Das wollte ich unbedingt erlernen, weil ich glaubte, daß sich mit den Softwaresprites eine Menge Möglichkeiten ergeben - so war es dann auch.
Ich habe dann über AtariAge einen Code gefunden, der einen großen SSprite darstellt und erklärt. Den Code habe ich analysiert und auf MADS umgeschrieben - irgendwie ist aber jeder Code spezifisch und komplett durchdrungen habe ich ihn auch nicht. Das Prinzip war aber klar. Ich habe dann den Code komplett verworfen und das selber Schritt für Schritt hergeleitet, was einige Wochen in Anspruch genommen har.
Als nächstes habe ich dann beide Codes miteinander verbunden und eine erste Testlandschaft gebaut... und dabei leider festgestellt: Das System wird instabil! Das lag sicherlich auch an der Gesamtkonstruktion der DLI´s und der Architektur meiner Displaylist. Das habe ich aber zu spät gemerkt, daß ich da in eine Art Sackgasse gelaufen bin und beim Versuch das ganze umzuschreiben, habe ich gemerkt, daß ich alles ganz neu konstruieren müsste. Das hätte mich um sicherlich 3-4 Monate zurückgeworfen. Ich habe mich dann dagegen entschieden und es anders gelöst:
Die Idee war auf alles Fein-/Grobscrolling zu verzichten und alles komplett mit Player/Missile und Softwaresprites zu machen. Die große Frage war dann eigentlich nur wie viele Sprites kann ich auf den Bildschirm bringen mit noch ausreichender Geschwindigkeit. 5 Alienraumer + 5 Schüsse waren für mich gesetzt + x große Landschaftssprites. Bei 16 großen Sprites war im Grunde Schluss... 8 oben und 8 unten. Janko - mein Freund und kritischer Tester - meinte dann: "Die Dinger bewegen sich jetzt wie in Zeitlupe" und leider hatte er Recht! Ich habe also die nächsten Wochen zunächst nur Code-Optimierung gemacht. Die Landschaftssprites wurden deutlich optimiert - 2 oben weniger, 2 unten mehr. Variables Shading per Zufall, keine Animation dafür und nur eine Bewegung (von rechts nach links). Oben langsamer als unten - mein Parallax!
Nun war mir doch schon auch bald sehr klar, daß ich nicht nur ein CPU-Leistungsproblem bekomme, sondern auch ein Speicherproblem. Ich entschied ich also dafür, das ganze Spiel für den Atari 130 XE zu bauen mit Bankswitching. Das war also dann meine nächste Lerneinheit. Und wenn man sich mit den Dingen beschäftigt und sie versteht, dann geht das plötzlich auch ganz einfach... fast zeitgleich erzählte mir Janko, er hätte für sein Spiel RAM unter ROM genutzt... und den VBI eigens umgebaut und für sich und diese Zwecke selber gebaut. Spannend.... das sind ja ca. 14kB mehr im normalen RAM!! Brauche ich!!! Also habe ich es mir mit großer Hilfe von Janko ebenfalls angeeignet und nun läuft mein Spiel mit RAM unter ROM - also das gesamte Betriebssystem wird während des Spiels abgeschaltet. Ich werde es nur brauchen für den Highscore....
Speicher habe ich nun also genug, ein erster Endgegner ist fertig und der gesamte Programmablauf läuft in nun mittlerweile 7 Alienwellen bis zum ersten Endgegner und startet nach dessen Vernichtung wieder von vorne. Ein Durchlauf läuft ca. 25 Minuten, ich plane mindestens 3-4 Durchläufe (Phasen) - also man sollte somit fast 90 Minuten Dauerballerei mit verschiedensten Aliens und Landschaften / Endgegnern bekommen. Mal sehen, was ich da alles noch so reinbekomme.
Zwischendurch habe ich ganz intensiv immer wieder an der Kollisionserkennung gearbeitet - hier gibt es Hitboxen und Schutzschirme - man muss also den Alienraumer relativ zentral treffen und das auch mehrmals bis er explodiert. Das eigene Raumschiff besitzt ebenfalls einen Schutzschirm - geht also nicht beim ersten Treffer kaputt.
Soundeffekte und im Hintergrund laufende Musik ist bereits implementiert, das habe ich ganz am Anfang gemacht.
Thema Dauerfeuer: Ein Ballerspiel braucht Dauerfeuer und mehrere Schüsse. Das habe ich dann kürzlich eingebaut. Man hat also nun maximal 4 Schüsse, die man als Dauerfeuer ständig abfeuern kann... aber aufgepasst, die Aliens haben das auch
Als nächstes habe ich die gesamte Bewegungssteuerung und Systematik der Aliens umgearbeitet - hat mich 2 intensive Wochen gekostet - mit dem Effekt, daß die nun sich deutlich schneller und homogener bewegen. Auch die Variabilität der Bewegung ist nun quasi ohne Einschränkung... ich kann nun alles simulieren. Notwendig dazu war jetzt noch die Möglichkeit des selbstmodifizierenden Codes, was ich mehrfach inzwischen nutze.
Seit ein paar Tagen nun beschäftige ich mich mit einem weiteren großen Gebiet: Die verschiedenen Items und Schussarten.
Dabei waren folgende Fragen zu klären: Welche verschiedenen Item sollen rein und welche Schussoptionen sind sinnvoll und überhaupt möglich. Und wie schaltet man um während man ballert und steuert, ohne die Tastatur oder die Sondertasten zu benötigen...
Mittlerweile habe ich 3 Schussoptionen drin und ein Sonderitem. Das Sonderitem funktioniert wie eine Bombe und zerstört alle Aliens sofort, die verschiedenen Schussoptionen haben unterschiedliche Durchschlagskräfte und Aussehen. Das Umschalten gelingt mittels einer Art Rotationsbewegung des Joysticks und funktioniert sehr gut.
Nun musste ich noch ein weiteres Problem lösen: Die Explosion der Alienraumer laufen folgendermaßen ab:
Die Animation der Softwaresprites (des getroffenen Aliens) wird auf eine Explosionsanimation umgebogen, alles läuft direkt hintereinander mit kleiner Warteschleife ab. Das war einfach zu programmieren, mir war aber immer klar, daß ich das noch ändern müsste, da man immer bei der Explosion einen kleinen Stop bemerkt. Und wenn dann mehrere Aliens zugleich explodieren - was vorkommt und erwünscht ist - ist der Stop dann logischerweise etwas länger und fällt unangenehm auf.
Ein ähnliches Problem musste ich schon bei Battle of Eris lösen und das war schwierig und aufwendig.
Das habe ich jetzt gestern umgesetzt und es funktioniert - mit 2 kleinen Bugs - schon richtig gut.
Nun baue ich in den nächsten Wochen weiter an den verschiedenen Items und Schussoptionen, dann kommen die ganzen Score/Ships/etc. - Anzeigen mit Programmabläufen wie Programmende / Neustart wenn alle Schiffe verbraucht sind usw.
Danach muss ich quasi nur noch weitere Wellen / Phasen bauen ... also Design, denn die ganzen Programmstrukturen stehen dann bereits. Dann kann ich auch erst absehen, wieviel Platz ich dafür habe.
Ein Highscore kommt zwingend rein.
Ganz am Ende mache ich noch das Intro / Extro - allerdings: Wenn es mit dem Speicher eng wird, dann verzichte ich lieber auf ein komplexes Intro zu Gunsten des Spiels.
6 Monate Entwicklungszeit bislang... Hälfte habe ich
Am Ende wird ein reines Ballerspiel entstehen, mancher wird es mögen, andere nicht... die Technik dahinter jedenfalls ist extrem komplex!
Ich hoffe mit dem Artikel, Euch ein wenig mehr Einblick geben zu können, was da so alles im Hintergrund passiert...
Allen noch ein gutes Gelingen und allen eine frohe Vorweihnachtszeit!
Peter