Schlagwort-Archive: Spacola Eclipse

spacolaeclipse054

Seit Oktober kein Lebenszeichen von SPACOLA Eclipse, und auch das versprochene neue Vorschau-Video hat inzwischen drei Monate Verspätung? Ja, das klingt eindeutig nach mir. Aber ich kann Entwarnung geben: Bislang war ich eigentlich „nur“ zu faul, euch mittels Blog-Beiträgen auf dem laufenden zu halten, und auch das Produzieren, Schneiden und Hochladen des Videos war mir bisher zu mühselig. Dennoch bearbeite ich jeden Monat durchschnittlich 40 „Issues“ an dem Spiel, so dass es immer weiter vorangeht. Sogar an diesem Wochenende habe ich wieder eine ganze Stange an unliebsamen Problemen behoben, die mich schon recht lange stören.

Mit unliebsamen Themen meine ich solche Codeänderungen, die sich nicht auf das Gameplay auswirken, über die es sich daher eigentlich auch nicht lohnt, in einem Beitrag zu schreiben. Die Vortex-Klasse kann jetzt die Animationen der Sterne und Spielobjekte darstellen, außerdem ist die Animation des Wurmlochs selbst jetzt deutlich näher am Original. Die Displays in der HUD-Seitenleiste sind jetzt allesamt numerische oder hexadezimale „FlapDisplays“, also solche Anzeigen, bei denen die einzelnen Ziffern bei Wertänderungen erst nacheinander umklappen – genau wie im Original. Daneben gibt eine ganze Menge an Änderungen bezüglich der Programmablaufkontrolle. Was passiert z.B. wenn man im Intro F5 drückt, oder ESC im Levelauswahlbildschirm? Wie lange wird das Hauptmenü angezeigt und wohin soll das Programm dann springen? Genau solche Dinge musste ich stundenlang im Originalspiel analysieren und ins Remake einbauen. Das ist wahnsinnig viel kleinfitzeliger Kram, der aber leider nötig ist.

Dafür habe ich endlich die Bedingung für das erfolgreiche Beenden des Spiels implementiert. Sobald alle 64 Levels abgeschlossen sind, wird das Zertifikats-Modul ausgeführt, welches es im finalen Spiel erlaubt, das persönliche Zertifikat anzuzeigen oder auszudrucken. In der Testphase wird hier allerdings nur eine Meldung angezeigt, dass es sich noch um eine Testversion handelt. Zusätzlich habe ich das Verifikations-Modul eingebaut, das im Original verwendet wird, um beim Laden von Savegames zu prüfen ob der Spieler auch wirklich den Sternenatlas besitzt. Im Remake wird dieses Modul zwar nicht direkt benötigt, aber es gehört eben trotzdem dazu. Tatsächlich funktioniert die Prüfung sogar perfekt, denn SPACOLA Eclipse beinhaltet seit einigen Monaten den kompletten Inhalt des Sternenatlas. Möglich wurde das durch die Unterstützung eines Hackers, der das Originalspiel mit einem Disassembler dazu gebracht hat, alle 29568 Codes auszuspucken.

Auch erscheint nun beim Klick auf „Neues Spiel“ ein kleines Menü, in welchem man den Spielmodus (dargestellt durch eine entsprechende Grafik) auswählen kann. Im Moment ist das nur das Monochrom-Remake mit dem Codenamen „SPACoLASSIC“. Im Verlauf von späteren Versionen gibt es hier auch die verbesserte Farbversion und den Multiplayer-Modus zur Auswahl. Das eingebaute Cheat-„Navigationssystem“ (der Richtungspfeil) zeigt nun nette kleine Icons an den Pfeilen, um zu verdeutlichen wohin der Pfeil eigentlich deutet. Denn neuerdings wird dem Spieler nicht nur die Richtung zum Ziel ausgewiesen, sondern auch zu bestimmten Powerups.

Ach, Moment. Eine große Gameplay-Änderung habe ich dann doch zu vermelden: Der Minenleger ist fertig. Dieser äußerst unangenehme Gegner fliegt im Spiel auf den Spieler zu und wirft ihm eine Mine direkt vor die Füße. Das Teuflische an diesen Gegnern ist, dass wenn sie vom Spieler zerstört werden, sie diesen mit einer weiteren Mine oft noch mit in den Tod reißen können. Doch auch hier gibt es leider eine Beobachtungsungenauigkeit von mindestens 20%, so dass ich nicht garantieren kann, dass die Bewegungen oder das Schießverhalten wirklich genau wie im Original sind. Aber besser wird es leider nicht.

Weiterhin peile ich den Oktober als Termin für eine erste richtig gut spielbare Version an. Ob diese Version dann das komplette Spiel beinhalten wird oder doch nur den ersten Level, das mache ich davon abhängig wie gut ich bis dahin vorankomme.

Wieder einmal in drei Wochen nicht einen einzigen Beitrag geschrieben. Aber heute schaffe ich es. Ich habe ein freies Wochenende, ich habe Motivationsmusik laufen, ich habe Kaffee gemacht, ich muss mich nur noch konzentrieren! Tschakka! Nein, SuccessDenied wird nicht eingestampft, aber die Zahl der regelmäßigen Beiträge hat sich leider wieder einmal reduziert. Beruflich bin ich zur Zeit derart eingespannt, dass ich abends nur noch froh bin, wenn ich nichts mehr machen muss. Manchmal wundere ich mich selbst, wie ich überhaupt noch zu etwas komme. Nunja, in acht oder neun Wochen ist ja schon wieder Urlaub. Bis dahin versuche ich möglichst viel auf Autopilot unterwegs zu sein.

Trotz all der Widrigkeiten arbeite ich weiterhin im kleinen und im ganz kleinen Rahmen an meinem SPACOLA-Remake. In genau einem Jahr soll die Monochromversion fertiggestellt sein. Das ist ein sportliches Ziel, wenn man sich vor Augen führt, dass ich seit fünf Jahren an dem Spiel bastle, und mir täglich mehr Dinge auffallen, die ich leider nicht richtig hinbekommen oder komplett vergessen habe. Die To-Do-Liste wird erstaunlicherweise niemals kürzer, nur noch länger und länger. Die aktuelle Version 0.49 vom Oktober 2015 hat die 30000 Zeilen übersprungen. Hier eine kleine, unvollständige Liste der Dinge, die kürzlich hinzugekommen sind:

Kollisionsauflösung

Die Gegnerschiffe im Originalspiel können (bis auf eine einzige Ausnahme) sich im Flug niemals gegenseitig berühren, sie können lediglich mit dem Spieler und den Asteroiden kollidieren, durch andere Entitäten fliegen sie immer hindurch. Auch die Asteroiden selbst fliegen immer durch andere Asteroiden hindurch. Inzwischen habe ich meiner kleinen 2D-Engine einen Algorithmus verpasst, der es erlaubt, unter Spielobjekten wechselseitig auf Kollisionen zu prüfen. Mit steigender Anzahl der Objekte steigt der Rechenaufwand leider enorm, das Spiel wird spürbar langsamer, daher muss gewährleistet sein, dass diese Methode nur auf eine überschaubare Anzahl von Objekten angewandt wird. Hinzu kommt, dass eine Kollisionserkennung bzw. -vermeidung leider nicht ausreicht, wenn die Objekte z.B. von der Schwerkraft permanent in dieselbe Richtung gezogen werden. Schnell ergibt sich so die Situation mehrfacher Überlagerungen, oder von Objekten, die gerade durch Anwendung des Abprallvektors wiederum in ein anderes Spielobjekt hineingeschoben werden.

Es musste eine Methode zur aktiven Kollisionsauflösung gefunden werden, die auch in einer großen Ansammlung von Spielobjekten funktioniert. Einige aufwändigere Algorithmen dazu habe ich mir angesehen, leider waren diese in meinem Fall nicht gut umsetzbar. Im Endeffekt versuchte ich mich mittels Trial and Error selbst an einer Lösung. Im Prinzip werden nun für jeden Frame alle auftretenden Kräfte ausgerechnet und schrittweise auf die Objekte angewandt. Jedes Objekt wird dabei nur so weit bewegt, bis eine Kollision auftreten würde, anschließend wird immer die Richtung korrigiert. Wenn am Ende des Updates doch eine Kollision erkannt wird, die sich trotz aller Vorsicht nicht vermeiden ließ, dann werden auf die „Streithähne“ jeweils Penalty Forces angewandt, also Strafvektoren, die die Objekte mit Schwung auseinanderspringen lassen. Das Ergebnis ist fast vergleichbar mit dem, was etablierte 2D-Physik-Engines leisten können.

spacolaeclipse049

OXYD-Rotoren als Spaßgegner

Um mein kleines 2D-Physik-Experiment zu testen musste ich kurzfristig einen Spaßgegner ins Spiel einbauen, der definitiv miteinander reagiert. Im Dongleware-Klassiker OXYD gab es mit dem Rotor einen solchen Gegner. In ein oder zwei Landschaften gab es die Situation, dass zwei Rotoren gemeinsam die Spielerkugel jagten. Die drehenden Rotoren stießen sich dabei jeweils voneinander ab, wenn sie versuchten, denselben Punkt zu erreichen. Im SPACOLA-Remake werden die drehenden Rotoren nun von den Stationen losgeschickt, und sie werden direkt vom Raumschiff des Spielers angezogen. Die Anzahl gleichzeitig existierender Rotoren habe ich dabei stark erhöht, um zu testen, ob die Abstoßung auch im Pulk einwandfrei funktioniert. Das Ergebnis ist wirklich nett anzusehen und wirkt dank passendem OXYD-„Glas“-Soundeffekt auch sehr authentisch.

Stationsanimationen fertig

Alle zehn Stationsanimationen sind nun komplett fertiggestellt, die bisher bestehenden wurden verbessert. Die Timings habe ich Frame für Frame aus dem Original übernommen, dazu habe ich stundenlang Bildchen im Emulator mitgezählt und jeweils die Anzahl notiert. Dafür kann ich jetzt garantieren, dass das Remake sich in dieser Hinsicht absolut nicht mehr vom Original unterscheidet. Tests mit den jeweiligen Soundeffekten zeigen, dass die Animationen wirklich perfekt passen.

Neues Titel-Artwork und Swing-GUI

Ich habe ein neues Titel-Artwork entworfen, da mir die Abstände zwischen den Buchstaben noch nicht gefallen haben. Wenn ich schon dabei war, wollte ich die Grafik des Schriftzugs diesmal perfekt gestalten, so dass ich daran nie mehr etwas ändern müsste. Der Schriftzug wirkt jetzt plastischer, die Abstände sind optimiert, und sogar der Schattenwurf wurde an die Vorgaben im großen Dongleware-Vorbild OXYD angelehnt. Zusätzlich habe ich den Dongleware-Font invertiert und mit einem schwarzen Rand versehen, damit es ebenfalls näher am Original ist. Die Swing-GUI habe ich mit dem Dongleware-Font und mit einem einheitlichen Hintergrund etwas aufgehübscht. Doch das Ziel ist damit noch lange nicht erreicht. Ein einheitliches Optionsmenü fehlt weiterhin.

spacolaeclipse049_2

Magnetismus-Code verbessert

Den Magnetismus-Code habe ich deutlich verbessern können. Die Lösung des Problems war nicht, den Code physikalisch korrekt zu gestalten, wie ich das zuerst versucht habe, sondern – im Gegenteil – eine eher unlogische Herangehensweise. Objekte, die magnetisch angezogen werden, werden nicht mehr ausschließlich in Richtung des „Magneten“ beschleunigt, sondern vollziehen zusätzlich dessen Bewegung iterativ nach. Dadurch wird eine weichere Anziehungsbewegung ermöglicht, und es wird verhindert, dass Objekte wie Satelliten immer um den Mittelpunkt kreisen. Die exakten Werte versuche ich allerdings weiterhin durch Ausprobieren und Korrigieren herauszufinden.

spacolaeclipse047

Gestern auf den Tag genau vor fünf Jahren tippte ich die ersten 50 Quellcodezeilen von etwas, das ein paar weiße Pixel auf einem schwarzen Hintergrund bewegte. Heute sind es ziemlich genau 28.500 Zeilen mehr, und es sind leider immer noch weiße Pixel auf schwarzem Hintergrund. So ein Pech aber auch. Nein, heute ist es ein Spiel, das einem originalgetreuen SPACOLA-Remake tatsächlich sehr nahe kommt. Originaltreue ist mir am wichtigsten. Ich verändere nur Details, die mir sinnvoll erscheinen und sich nicht vermeiden lassen. Jede zusätzliche Änderung, jedes weitere witzige Extra wird immer optional sein. Im Moment arbeite ich mich recht fleißig durch die vielen offenen Punkte, und darauf möchte ich in diesem Update-Artikel zu sprechen kommen.

Levelparser/Levelgenerator und Kampagnenmodus

Der Parser für die Levelkonfiguration mit dem Levelgenerator sind weitgehend fertig. Der Parser liest die Original-Levelskripte ein, teilt die Anweisungen im Skript in Tokens und Parameter ein und „interpretiert“ diese, indem er dem Levelgenerator Anweisungen gibt, wie das nächste Level aufgebaut werden muss. Das funktioniert schon perfekt für Level 1. Ab Level 2 aufwärts werden allerdings weitere Befehle eingeführt, die ich erst noch verstehen und vor allem einbauen muss. Damit ist der Kampagnenmodus jetzt theoretisch vorhanden und benutzbar, und wird auch mit jedem weiteren umgesetzten Befehl besser.

Spielen ohne Spacola Sternenatlas

Zwei Änderungen, die nötig sind um das Spiel ohne Buch sinnvoll spielen zu können, habe ich nun umgesetzt. Im Levelauswahl-Bildschirm kann man mit dem Mauszeiger über die Levels fahren und rechts im Statusfenster wird jetzt das darin befindliche erste Sektor-Powerup eingeblendet. Dieses musste man sonst aus dem Buch herauslesen. Ohne das Buch hätte man aber keine Möglichkeit mehr, diese an sich wichtige taktische Entscheidung noch zu treffen, darum hilft das Remake hier nach. Die zweite Änderung, die mir wichtiger ist: Wie soll der Spieler erfahren, wohin es die Waren auszuliefern gilt? Im Jahre 1991 hatte ich dazu das Buch mit der richtigen Seite aufgeschlagen an der oberen Kante unter die Tastatur geklemmt, um die Tabelle immer sofort griffbereit zu haben. Mit dem Finger konnte ich so Zeile und Spalte entlangfahren und schon ging es los. Ohne das Buch muss ich den Zielsektor logischerweise direkt rechts einblenden, was auch der Fall ist. Aber um die Sache spannender zu gestalten, experimentiere ich im Moment damit, dem Spieler den Zielsektor nur zeitverzögert zu verraten, so dass man sich erst noch ein paar Sekunden alleine mit der Spielwelt befassen muss, ehe man sich auf die Reise macht. Derzeit sieht es so aus, dass rechts in der Leiste eine Art „Dekodierung“ angezeigt wird, die nacheinander die X- und Y-Koordinate „entschlüsselt“. Das wäre meine Idee, wie man diesen Aspekt sci-fi-mäßig ohne Buch umsetzen könnte, ohne es noch simpler zu machen.

Alle Powerups fertig

Das „Kantinenruf“-Powerup wurde kürzlich von mir implementiert, und auch das Abfeuern von Lenkraketen funktioniert jetzt einwandfrei. Es sieht sogar schon recht witzig aus, wie die kleinen Lenkraketen zielsicher die Gegnerschiffe verfolgen und alles explodiert. Inzwischen kann ich also stolz vermelden: Alle 12 Original-Powerups sind funktional! Mit der Taste F12 kann man im Spiel neuerdings jederzeit Screenshots abspeichern lassen. War nicht wichtig, aber kam mir irgendwie selbstverständlich vor, dass der Client sowas können sollte. Außerdem merkt der Client sich jetzt endlich alle Einstellungen, die der Spieler vornimmt. So werden etwa Grafikeinstellungen in eine CFG-Datei persistiert und beim Programmstart geladen. Im Cheatmenü gibt es ein neues Untermenü für alle verfügbaren Powerups, die man hier einzeln anwählen kann. Das macht das Testen etwas einfacher.

Richtungspfeil und Testversions-Hinweise

Einen weiteren Cheat habe ich diese Woche verwirklicht: Einen Richtungspfeil am Bildschirmrand ähnlich wie in GTA, der immer den kürzesten Weg zu einem frei wählbaren Spielobjekt anzeigt, also z.B. die Zielstation. Sobald das Objekt sich dann mal tatsächlich auf dem Bildschirm befindet, zeigt der Pfeil auch direkt darauf. Dieser Pfeil wird in der klassischen Kampagne natürlich nicht enthalten sein, da er das Spiel zu sehr vereinfacht, aber ich fand es gut, dass ich sowas mal verfügbar habe für alle Fälle. Analog zu den Spezialhinweisen in der TOS-Demo von SPACOLA habe ich (pixelgenau positioniert versteht sich) auch in mein Remake einige Hinweise bezüglich seiner Unvollständigkeit hinterlegt. Das könnte man als erste Vorbereitung für einen öffentlichen Beta-Release werten, der definitiv in nächster Zeit nötig sein wird, wenn die Entwicklung in diesem Tempo weitergeht.

Präzise Messungen beim Schießverhalten

Das Schießverhalten des Spielerschiffes ist nun sehr viel näher am Original. Durch witzige Messmethoden habe ich versucht, herzuleiten, welche Parameter im Original verwendet werden. Hierzu muss ich Screenshots des Originals anfertigen, und dann die Distanz in Pixeln messen, die die abgefeuerten Schüsse in einer zuvor gezählten Anzahl an Frames zurückgelegt haben. Bei den 72 Hertz, die der Atari ST darstellt (wobei SPACOLA im Gegensatz zu OXYD nur jedes zweite Bild zeichnet, also eigentlich 36 fps), kann ich dann eine Umrechnung in Pixel pro Zeiteinheit als Schussgeschwindigkeit vornehmen, die ich im Remake wiederum verwende, um sie auf die gewählte Zielframerate aufzuteilen. Auch die Schussfrequenz bei Dauerfeuer konnte ich so mit Hilfe von Screenshots messen. Wenn beim Messen dann mal keine ganz krumme Zahl herauskam, wusste ich, dass ich auf der richtigen Spur bin. Die Herumrechnerei führt dazu, dass im Remake endlich deutlich authentischere Werte verwendet werden. Hierbei ist mir auch aufgefallen, dass das Weitschuss-Powerup anders als im Handbuch behauptet, die Schussgeschwindigkeit nicht erhöht, sondern die Kugeln nur weiter fliegen lässt.

Grafikbearbeitung abgeschlossen

In den vergangenen zwei Monaten habe ich die Original-Designvorlagen von SPACOLA wirklich ausgiebig analysiert, in stunden- und tagelanger Fleißarbeit ausgeschnitten, mit meinen eigenen Dateien etwa bezüglich Transparenz, Rotation und Reihenfolge verglichen und dadurch unzählige kleine und große Korrekturen an hunderten von Sprites vornehmen können. Dieser Prozess ist jetzt zu 99,9% abgeschlossen, und damit fallen die teilweise recht lästigen Pixeldoktoreien mit GIMP weg, und ich kann mich endlich vollkommen auf den Code konzentrieren. Mann, das wird ein Spaß. Aber der schwierigste und wichtigste Teil von allen kommt ja erst noch: Die Gegner-Intelligenz so wie im Original hinbekommen.

spacolaeclipse045

Wo ich gerade schon bei Spielen mit der Grafik noch aus der Zeit der Weimarer Republik bin, spreche ich am besten direkt das nächste passende Thema an: Spiele mit Grafik aus der Steinzeit. Es folgt ein diesmal etwas längerer Artikel über den aktuellen Entwicklungsfortschritt meines Hobby-Dongleware-Remake-Projekts SPACOLA Eclipse. Es gibt viel zu berichten, weil ich in letzter Zeit viel daran gearbeitet habe. Die neueste Work-in-progress-Version vom Juni 2015 führt einige neue Gameplay-Features ein, allerdings auch viele tolle Neuerungen unter der Haube, die das Arbeiten an dem Projekt endlich deutlich interessanter machen, was wohl auch der Grund für meinen unerwarteten Eifer ist.

Mehrspieler-Modus

Ich habe in letzter Zeit die Serialisierbarkeit der meisten Spielobjekte überarbeitet und damit angefangen, den Mehrspieler-Modus zumindest grundsätzlich mit Leben zu füllen. Nachdem man bislang den Server lediglich vorbereiten, und sich als Client nur theoretisch registrieren lassen konnte, startet nun in der neuen Version tatsächlich ein Spiel, sobald die Mindestanzahl der Teilnehmer erreicht ist. Als nächsten Schritt sorgte ich dafür, dass die Spieler-Objekte untereinander ausgetauscht und dargestellt werden können. Die Mitspieler werden sich jetzt zwar auf dem Bildschirm gegenseitig sehen, aber davon abgesehen wird noch nichts synchronisiert, jeder spielt ein völlig eigenständiges Spiel. Mein Ziel war damit bereits erreicht, denn es ging mir vorerst um das Programmgebilde außenrum. Als nächstes wäre eine Lobby nötig, damit man einen Spielmodus und das Level auswählen, sich absprechen, und die Teilnehmerzahl festlegen kann.

Aktives Rendern, höhere Auflösungen, Vollbildmodus

Es war eine kleine und interessante Herausforderung, als ich damals mein eigenes Double-Buffering schrieb für das Zeichnen von 50 Bildern pro Sekunde ins Fenster, aber wenn ich ehrlich bin, war das eine rein autodidaktische Mission und überhaupt nicht nötig. Double-Buffering gehört zur Standardausstattung von Swing. Für meine Verhältnisse war meine Methode lange Zeit absolut ausreichend, aber für höhere Auflösungen leider unbrauchbar langsam. Inzwischen habe ich die 2D-Grafikengine von SPACOLA Eclipse auf aktives Rendern umgestellt, das den ausbremsenden Swing-Overhead umgeht und das Zeichnen des Fensters selbst steuert. Der Unterschied in der Performance ist beeindruckend. Als Bonus habe ich Echtzeit-Skalierung eingebaut, die das Bild stufenlos vergrößert, sogar mit Interpolation. Inzwischen läuft SPACOLA Eclipse in 1280×800 Pixeln, und das absolut ruckelfrei und noch dazu viel responsiver was die Mauseingaben angeht. Ach stimmt, einen exklusiven Vollbildmodus gibt es jetzt auch, den man wahlweise ganz normal mit ALT+Enter oder F8 umschaltet. Die Menüleiste ist mit dem Vollbildmodus noch nicht so ganz einverstanden, aber daran arbeite ich noch.

Farbsprites

Die ersten Vorbereitungen für den Farbmodus sind endlich getroffen. Meinen ganzen alten Monochrom-only-Code habe ich durch pseudomonochrome Grafikobjekte ersetzt, die zur Farbdarstellung in der Lage sind. Ein erster Test mit ins Spiel eingebauten Farbsprites verlief erfolgreich, der Rest ist also nur noch eine Sache von wochenlanger Kolorierung in Fleißarbeit und Search & Replace. Angefangen habe ich damit bereits teilweise. Außerdem gelang es mir, die ersten Farbsprites, die von Meinolf Amekudzi im Jahr 1993 für eine nie in Entwicklung gegangene SPACOLA-Farbversion angefertigt wurden, endlich richtig auszulesen. Die Grafiken sehen wirklich sehr spannend aus. Es müsste mir also möglich sein, diese Designs bald zu komplettieren, und einen Farbmodus ins Remake einzubauen.

Neue Gegner-KI

Die alte provisorische Gegner-KI ist bald Geschichte. Bislang war das Flugverhalten der Dummy-Gegner doch sehr merkwürdig, da sie im Weltraum Haken schlagen konnten und auch nur endlos dem Spieler folgten. Längst gelang es mir, das Flugverhalten deutlich realistischer zu machen. So müssen die Gegner jetzt genau wie der Spieler genügend Gegenschub liefern, damit sie ihre Richtung anpassen können. Endlich driften die kleinen Piratenschiffe halbwegs glaubwürdig über das Pixelbild, verfehlen auch mal das Ziel, und müssen dann ständig wieder den Kurs korrigieren. Darüber hinaus machen die Piraten zum ersten Mal das, was sie eigentlich sollten: Sie knöpfen dem Spieler seine Waren ab oder suchen freischwebende Waren, und fliegen damit zur feindlichen Station, um sie unter Gelächter dort abzugeben. Das klappt wirklich erstaunlich gut, ist nur leider noch nicht so ganz am Original dran. Und wenn die Gegner mal gut gelaunt sind, dann fliegen sie schiffbrüchigen Kameraden hinterher und retten diese.

Rettungskapseln, neue Powerups

Es gibt im Original Gegnerschiffe, die bei ihrem Abschuss mehrere Rettungskapseln freigeben. Diese öffnen sich dann wiederum in ausreichendem Abstand zum Spieler von selbst und geben die üblichen hilferufenden kleinen Männchen frei. Die Rettungskapseln sind jetzt auch im Remake enthalten. Bei den Powerups sind immerhin eineinhalb dazu gekommen: Der Molekularduplikator, der soweit ich es erkennen kann in genau einem von 64 Levels vorkommt, funktioniert jetzt perfekt. Beim Raketen-Powerup habe ich immerhin das Einladen mal fertiggestellt. Das Abfeuern derselben fehlt noch.

Der Quellcode umfasst jetzt mehr als 24.000 Zeilen und wurde von mir in den vergangenen Wochen ausgiebig gepflegt und verbessert. Einige verschluckte Exceptions beim Soundplayer habe ich so aufgespürt, was sich vermutlich auch auf die Performance ausgewirkt hat. Das Logging habe ich deutlich erweitert und auch hier einige Fehler behoben, die mir vorher nie aufgefallen waren. Insgesamt ist das Projekt spürbar aufgeräumter und ausgereifter geworden, so dass die faulen Phasen hoffentlich der Vergangenheit angehören dürften. Inzwischen ergibt selbst ein richtiges Optionsmenü Sinn, in dem man Grafikmodus und Audiotreiber und diverse andere Technikaspekte einstellen könnte. Das nächste große Thema ist ein funktionierender Kampagnenmodus mit wechselnden Levelkonfigurationen. Das Ding habe ich jetzt lange genug vor mir hergeschoben.

spaclipse042_2

Bevor hier tatsächlich noch Schimmel ansetzt, belästige ich die werte Leserschaft lieber nochmal mit den aktuellsten Vorgängen in Bezug auf die Webseite und SPACOLA Eclipse. Hierzu habe ich mir eine kleine Liste bereitgelegt, die ich jetzt in einem mehr oder weniger kurzen Artikel abfrühstücken möchte. Am liebsten hätte ich die Gelegenheit genutzt, meine Meinung zur kürzlich angekündigten st-computer-Ausgabe kundzutun, doch wie es scheint, bekommen die Käufer die Februar-Ausgabe frühestens Mitte März, daher wird das wohl noch etwas dauern.

Stattdessen habe ich die Aufmerksamkeit für mein kleines Dongleware-Museum in kreative Energie umgewandelt und einige Einträge hinzugefügt bzw. erweitert. Hinzugekommen ist das wenig bekannte Spiel „The Dragon’s Power“, das von Dongleware 1994 vertrieben wurde, von welchem ich erst vor wenigen Monaten erfuhr. Ebenfalls ist mir entgangen, dass ich doch tatsächlich eines der Schneider’schen TOS-Gimmicks vergessen habe: Das Accessory „Blackhole“, das den Papierkorb in ein schwarzes Loch verwandelt. Es war eigentlich nur eine Beilage zum TOS-Gimmick „Trashy“. Die Beschreibungen der Gimmicks habe ich zusätzlich erweitert und mir auch die Quelltexte der kleinen Programme abgespeichert. Einen Teil der Codes kann ich vielleicht in das Remake-Projekt einbringen.

Besonderen Dank möchte ich an dieser Stelle übrigens einer Leserin des Blogs aussprechen, die mir aus heiterem Himmel ihr OXYD-Buch (guterhalten), und das passende Spiel auf CD per Post geschickt hat. Das war eine äußerst schöne Überraschung. Eine kleine Aufwandsentschädigung habe ich ihr dafür natürlich zukommen lassen. Meine Dongleware-Büchersammlung wurde auch durch einen weiteren SPACOLA Sternenatlas vergrößert, den ich für nicht einmal vier Euro bestellen konnte. Der Einband ist leider ein wenig beschmiert, und auch kleine Eselsohren waren wie erwartet drin, aber ich denke ich kann mich nicht beklagen. Damit habe ich nun also vier SPACOLA-Codebücher in meinem Besitz. Einem weiteren Leser und fleißigen Bolo-Spieler ist es zu verdanken, dass ich bei nächster Gelegenheit eine kleine Levelgalerie für Bolo (1995) und Dia-Bolo einweihen kann. Diese ist zwar nicht ganz vollständig, aber was nicht ist, kann ja noch werden. Der nächste Urlaub ist insoweit schon verplant.

Was gibts über SPACOLA Eclipse zu sagen? Der Fortschritt ist unverändert langsam, aber beständig. Der Zähler steht jetzt bei 20.000 Java-Codezeilen. Jeden Tag bemühe ich mich um ein oder zwei Änderungen, ein paar Fehler zu beheben, ein paar Grafikdateien zu korrigieren, etc. Die Februar-Version steht ganz im Geiste der Originaltreue und Platzersparnis. Ich habe herausgefunden, dass das PNG-Dateiformat sogar 1-Bit-Farbtiefe kennt (echt monochrom!) und habe sämtliche 700+ Grafikdateien einzeln umgewandelt und neu gespeichert. Am Ende hatte ich 64 Kilobyte von 415 gespart. 15% unnötige Daten entfernt, also wenn das nichts ist. Außerdem ist es mir gelungen, mit einem Hexeditor und viel Geduld in mühsamer Kleinstarbeit den SPACOLA-Rentenbescheid aus einem Memory-Dump des ST-Spiels zu extrahieren, und zusätzlich (endlich byte-genau) fast alle SDD-Sounddateien, also exakt so wie sie vor der „Kopierschutz-Kompression“ aussahen. Anschließend habe ich die Soundbibliothek meines Remakes so erweitert, dass sie die Original-8-Bit-PCM-Dateien importieren und verwenden kann. Damit wäre ich wieder einen kleinen Schritt näher am Atari-Vorbild.

spaclipse042_1

Nachdem ich mich also im Februar weitestgehend nur um die Technik unter der Haube gekümmert habe, ist diesen Monat wieder mal das Gameplay dran. Die letzten Tage gelang es mir, alle 14 Minenfeld-Konstellationen aus den Levels des Originals zu analysieren und in meinem Code umzusetzen. Nun steht dem geplanten Parser für die Levelkonfiguration der ST-Version nicht mehr viel im Wege. Das Level-„Skript“ habe ich inzwischen zu etwa 80% entschlüsselt, nur einige wenige Parameter, die etwa das Standardverhalten der Gegner ändern, oder Häufigkeitsmodifikatoren sind mir leider nicht ganz klar. In meinem Analyseprozess ist mir übrigens aufgefallen, dass die Entwickler in ihrer Levelkonfiguration eindeutig einen Fehler gemacht haben: In Level 14 müssten laut Skript sämtliche Sektoren mit Minenfeldern ausgestattet sein, doch da taucht kein einziges auf. Das Problem ist, dass sich dort im Skript jemand vertippt hat, so dass gar keine Minenfelder erzeugt werden. Im Debugger konnte ich bereits nachstellen, dass sich das Level deutlich ändert, wenn man den Tippfehler im Speicher korrigiert. Wenn ich nicht von dem Spiel besessen wäre, wäre das wahrscheinlich nie jemandem aufgefallen.

Jetzt stehe ich vor einer merkwürdigen Entscheidung: Tippfehler im Remake korrigieren und das Level so nachstellen, wie die Entwickler es sich eigentlich gedacht hatten – oder Tippfehler beibehalten, und das Level so nachstellen, wie es das Originalspiel auch wirklich dargestellt hat? Vor einem ähnlichen Problem stand vor einigen Jahren der Entwickler des Dungeon-Keeper-Remakes „KeeperFX“, der bei seiner Reverse-Engineering-Odyssee herausgefunden hat, dass die Bullfrog-Programmierer einen ganz blöden Fehler im Zusammenhang mit dem „Machtwort“-Zauberspruch nie richtig beheben konnten. In der Folge war der Zauberspruch viel schwächer als er eigentlich sein müsste. Nachdem er den Fehler nun also gefunden und im Remake behoben hatte, und der Zauberspruch plötzlich genau die Wirkung zeigte, wie es von Anfang an gedacht war, war das Balancing im Spiel leider total im Arsch. Logisch: Das Spiel war immer nur mit dem „verkrüppelten“ Zauberspruch getestet und feingeschliffen worden. Tatsächlich gibt es im Remake nun die Möglichkeit, den Fehler für die Originalkampagne wieder zu „aktivieren“, um das bekannte Spielbalancing nicht zu verändern. Vielleicht sollte ich das Problem auch via Optionsmenü lösen, und so dem Spieler die Entscheidung überlassen.