Spacola

SPACOLA Eclipse ist ein 2D-Weltraum-Ballerspiel mit 360° Bewegungsfreiheit und monochromer Pixelgrafik. Es handelt sich um ein originalgetreues Retro-Remake von SPACOLA, das 1991 von Dongleware für den Atari ST veröffentlicht wurde. Das Remake ist momentan noch in einem frühen Entwicklungsstadium und wird von mir vollständig in Java für moderne Betriebssysteme geschrieben. Da mir der Original-Quellcode leider nicht zur Verfügung steht, muss ich zwangsläufig alles vollständig aus der Beobachtung nachimplementieren. Meinolf Amekudzi, einer der beiden Programmierer des Originals, wurde insbesondere bekannt durch seine fantastischen Spielreihen Bolo und OXYD.

Diese Spiele zeichneten sich durch detailreiche, für damalige Verhältnisse hochauflösende Monochromgrafik aus, durch witzigen Sound, durch anfangs sehr simples, aber trotzdem schnell komplexer werdendes Gameplay. Bolo war ein Breakout-Klon. OXYD selbst war ein Murmelspiel, das Dongleware damit perfektioniert hatte. Spacola war dagegen ein Asteroids-Klon, allerdings deutlich aufwändiger, und mit wesentlich mehr lebendigen Gegnern als Asteroiden. Von Bolo gab es später noch einige Umsetzungen, unter anderem für den PC. Von OXYD gab es Umsetzungen, Fortsetzungen und Remakes für alle möglichen Systeme. Einzig SPACOLA war zum Sterben mit dem Atari ST verurteilt. Schade eigentlich, dabei hatte gerade dieses Spiel seinen ganz eigenen Charme, weil es ausnahmsweise kein Geschicklichkeits- oder Knobelspiel war, sondern viel nervenaufreibende Action bieten konnte.

Als intergalaktischer Handelsreisender beliefern Sie die irdischen Raumstationen in den Galaxien mit lebensnotwendigen Waren. Eigentlich ein langweiliger Job, wenn da nicht überall im Universum diese gierigen Piraten wären, die es auf Ihr teuer bezahltes Schmugglergut abgesehen haben. Da Sie aber daran interessiert sind, den Empfang Ihres Rentenbescheides noch zu erleben, setzen Sie sich mit äußerst wirkungsvollen Mitteln zur Wehr! Und da auf die Piraten ein Kopfgeld ausgesetzt ist, können Sie so manche Spacedollars mit dem Einsammeln schiffbrüchiger Besatzungen machen.

Test Test

Video Preview – Version 0.9.6


Features

  • Originalgetreue Monochrom-Grafik in 640 x 400 Pixeln
  • Spacige Titelmusik und 6-KHz-Sound wie beim ST-Original
  • Optionale Ingame-Musik
  • Kampagne mit 64 Levels
  • 27 verschiedene Gegner
  • 8 verschiedene Warentypen
  • 12 Original-Powerups
  • Intuitive Maussteuerung zum Drehen, Beschleunigen und Schießen
  • Animierter Radarschirm
  • Schiffbrüchige Piraten, Asteroiden, Fracht, Schwarze Löcher, Minen
  • HUD-Anzeige für Koordinaten und Punktezahl
  • Pixelbasiertes Partikelsystem für Schub und Explosionen
  • Komplettes Intro mit Titeln, Highscore, Kurzanleitung, Level-Ende-Screen
  • Menüleiste für die wichtigsten Funktionen, zusätzlich zum Hauptmenü
  • Multilingual, Deutsch und Englisch bereits integriert, problemlos erweiterbar
  • Lauffähig auf jedem Betriebssystem mit Java
  • Geringe Hardwareanforderungen

Weiterhin geplant

  • Originalgetreue Gegner-KI
  • HUD-Anzeige ausblendbar und Spielbildschirm im Vollbildmodus
  • Wechsel zwischen Classic-Modus, Enhanced-Modus (Farbe) und HD-Modus
  • Verschiedene Schwierigkeitsgrade
  • Multiplayer-Modus mit Duell- und Coop-Kampagne oder Schnellrunde
  • Spiel jederzeit Laden und Speichern
  • Farbversion auf Basis der Originalgrafik (koloriert)
  • HD-Version mit hochauflösenden, besseren Sprites
  • Einfach wechselbare Spritesets
  • Zusätzlich erweiterbar, z.B. andere Gegner, andere Fracht, andere Effekte

Entwicklungsfortschritt

  • Derzeitige Version: v0.9.14 alpha
  • Nächster Schritt: Vollständiger Kampagnenmodus
  • Finale Monochrom-Version (Classic) (v1.0) (when it’s done)
  • Kolorierte Farbversion mit höherer Auflösung (v1.1) (when it’s done)
  • Spielbarer Multiplayer-Modus (v1.2) (when it’s done)
  • HD-Version mit hochauflösender Grafik (v2.0) (when it’s done)

Statistiken

Version: 0.9.14 alpha / Build 840
Datum: 06.03.2022
Grafikdateien: 1439
Audiodateien: 64
Codezeilen: 58.794
Pakete: 29
Klassen: 342
Größe Quellcode: 3,5 MByte
Größe JAR/EXE: 8,0 MByte

Development Screenshots

2014  

Das Remake stellt sich vor.

WIP-Version 0.32: Das Remake stellt sich vor.

Einen eigenen GEM-Texteditor bringt das Spiel auch mit.

WIP-Version 0.32: Einen eigenen GEM-Texteditor bringt das Spiel auch mit.

2013  

WIP-Version 0.22: Komplettes HUD

WIP-Version 0.22: Komplettes HUD

WIP-Version 0.22: Statusmeldungen und Gegnerhorde

WIP-Version 0.22: Statusmeldungen und Gegnerhorde

2012 / Neue Architektur  

WIP-Version 0.19: Preis- und Fahndungslisten sind fast fertig

WIP-Version 0.15: Splash-Screen

WIP-Version 0.19: Schub mit Partikeleffekten und Extraleben-Powerup

WIP-Version 0.19: Spielfortschritt auf der Karte sichtbar

WIP-Version 0.15: Hauptmenü

WIP-Version 0.15: Schutzschild zu Beginn

2010 / Alte Architektur  

WIP-Version 0.06

WIP-Version 0.03


Ältere Videos – Version 0.39 / 0.29


Q & A

Für welches Betriebssystem wird das Remake entwickelt?

Software, die in Java geschrieben ist, läuft im Prinzip auf jedem Betriebssystem, auf dem eine Java VM läuft. Primär entwickle und teste ich unter Ubuntu Linux und bei Bedarf unter Windows 10. SPACOLA Eclipse sollte problemlos auch unter Mac OS laufen, sowie anderen Betriebssystemen. Entsprechende aussagekräftige Tests sind geplant, sobald das Spiel veröffentlicht werden kann.

Java? Wieso ausgerechnet Java? Wieso tust du uns das an?

Die aktuelle Anti-Java-Hysterie in den Medien kann von niemandem geteilt oder nachvollzogen werden, der selbst in Java entwickelt. Meist werden Sicherheitslücken in den obsoleten Java-Browserplugins mit Sicherheitslücken in Java verwechselt. Java ist nicht sicherer oder unsicherer als die konkurrierende Microsoft .NET Laufzeitumgebung, dennoch wird gerade unter Laien eine Hexenjagd auf alles was mit Java zu tun hat veranstaltet. Ich setze bewusst auf Java, weil ich täglich damit zu tun habe, weil die Arbeit damit Spaß macht, und weil es mir eine gewisse Plattformunabhängigkeit ermöglicht.

Wann wird SPACOLA Eclipse veröffentlicht?

Aktuell ist kein Releasedatum bekannt. Jedes bisher gesetzte Releasedatum habe ich leider verpasst, so dass ich zum gegenwärtigen Zeitpunkt kein Datum mehr nennen kann. Bis zum finalen Release möchte ich auf jeden Fall noch einige Beta- und Milestone-Releases zum Download freigeben, die schon weitgehend spielbar sein werden. Leider ist noch nicht absehbar, wann dies soweit sein wird.

Seit wann ist das Remake in Entwicklung?

An dem Remake arbeite ich inzwischen fast exakt genau so lange wie es Success Denied gibt. Genauer gesagt seit dem 19. August 2010. Seitdem arbeite ich mit mehr oder weniger langen Pausen daran (leider meistens längere). Neben meinem Beruf finde ich außerdem nicht immer die Zeit, um mein Hobbyprojekt nennenswert voranzutreiben. Meist packt mich das Thema erst wieder, wenn ich eine entsprechende Inspiration gefunden habe.

Sind Apps für Android und iPhone bzw. iPad geplant?

Auf jeden Fall. Über eine Umsetzung für Android denke ich bereits seit dem ersten Tag nach. Da die Dalvik VM für Android-Betriebssysteme ähnlich wie die Java VM funktioniert, dürfte das mit recht geringem Portieraufwand machbar sein. Eine iOS-Version ist ebenfalls machbar, wenngleich der Aufwand etwas höher sein dürfte. Genaueres lässt sich sagen, wenn die Dinge konkret werden.

Wieso denn ein SPACOLA-Remake? Warum nicht gleich OXYD?

Von OXYD gibt es viele Fortsetzungen und Neuauflagen und bis zum heutigen Zeitpunkt zwei(!) unabhängige Remakes, die auf aktuellen Betriebssystemen, sowie Smartphones laufen. Welchen Wert hätte ein weiteres Remake? SPACOLA ist insofern Brachland, außerdem schätze ich es als die etwas einfachere Implementation ein, was ich angesichts meines ersten kleinen Spieleprojekts, an dem ich in meiner knappen Freizeit arbeite, eher begrüße. Obwohl ich selbst wahrscheinlich auch viel mehr Zeit mit OXYD verbrachte, hat mir SPACOLA ebenfalls sehr viel Freude bereitet. Warum also nicht?

Brauche ich wieder den „Spacola Sternenatlas“ (SPACOLA-Codebuch) wie im Original?

Nein, der Spacola Sternenatlas wird NICHT benötigt, schon allein da er heute sehr selten und kaum noch zu bekommen ist, und weil er bei vielen SPACOLA-Fans sicher auch schon vor Jahren auf dem Dachboden verschollen ist. Das Spiel soll grundsätzlich jeder in vollem Umfang spielen können, daher werden für den Spielfortschritt keine Buch-/Code-Abfragen eingebaut. Ich überlege allerdings, ob ich als witziges Gimmick ein kleines Cheatmenü o.ä. in das Remake einbauen soll, das sich z.B. nur bei korrekter Eingabe eines Codes aus dem Sternenatlas öffnen wird – und dann auch nur in dafür ausgewählten Spielmodi, nicht in der Kampagne. Das wäre meine erste Idee gewesen, wie man die Besitzer des Originals auf humorvolle Weise belohnen könnte, ohne das Spiel für den Rest unzugänglich zu machen.

Warum sieht die Grafik so hässlich aus? Warum ist alles nur schwarzweiß?

Nun, Schönheit liegt im Auge des Betrachters. Manche finden diesen ganz besonderen Stil der Monochromgrafik sehr reizvoll, da sie nur wenig Spielraum lässt und die Kreativität daher auf eine ganz eigenartige Weise fordert. Ich für meinen Teil bleibe (vorerst) bei Schwarzweißgrafik weil, 1. die Fans SPACOLA gar nicht anders kennen – das Original IST einfach so, und 2. weil es mir die Entwicklung einfacher macht und ich nicht mehr Zeit mit Grafikbearbeitung verbringen muss als das sowieso schon der Fall ist. Dennoch: Eine Farbversion und eine hochauflösende HD-Version sind längst geplant. Nur Geduld.

Welche speziellen Game-Frameworks bzw. Libraries werden im Code verwendet?

Tatsächlich verwende ich bisher KEINE Game-Frameworks, und nur eine einzige externe Library (für das Dekodieren von OGG-Vorbis-Audio). Mir ist es im Moment aus autodidaktischer Sicht wichtiger, möglichst viele der üblichen essentiellen Mechanismen zur Spieleentwicklung selbst zu erarbeiten und zu entwickeln, darunter so Dinge wie Timing, Buffering, Animationen, sowie Maus- und Tastatur-Handling. Mit einem Game-Framework wäre die Arbeit vermutlich leichter und das Spiel bestimmt am Ende auch performanter, aber ich möchte derzeit möglichst unabhängig von externen Bibliotheken sein. Es mag nicht die intelligenteste Entscheidung sein, aber es ist meine Entscheidung.

Development Log

v0.9.14 – March 2022

  • implemented a game object method to traverse the origin object tree upwards to the root
  • implemented a shot object method to find out if it is a player shot
  • implemented a ship object method to find out if it is the origin of a specified shot
  • minedropper shots will now spawn debris objects depending on who the origin object was
  • fixed calls to various shot constructors that have changed
  • started implementing object based collisions and destruction for player shot updates
  • implemented shot collision methods for various enemy types and other game objects
  • simplified rescue capsule opening logic by removing redundant opening attribute
  • cleaned up huge and complicated update method for player shots
  • started implementing object based collisions and destruction for sector object updates
  • fixed updating enemies and bouncing enemies even though they might be already dead
  • finally rewrote all the game object update methods to use object based collisions
  • finished rewriting game object classes to offer object based collision handling
  • reverted removing objects before updating them because of regression problems
  • fixed regression with collecting aliens where they could be collected several times
  • added more log output messages to collecting aliens and triggering status messages
  • pulled alien collecting code from the solar system class into the playership class
  • added more log output messages to collecting ware
  • pulled ware collecting code from the solar system class into the playership class
  • fixed regression with collecting ware where it could be collected several times
  • fixed regression with enemies not being removed when trying to deliver stolen cargo
  • implemented a menubar item to quickly start a demo game from the file menu
  • fixed the player bot to always wait until the vortex animation is finished
  • made the player bot fly a little more naturally by implementing a motion threshold

v0.9.13 – February 2022

  • rechecked all 8 explosion ‚a‘ mono sprites by comparing with the SHL file
  • recreated all 8 explosion ‚a‘ color sprites and added them to the resources
  • added SPE_SPR1 shapelist file to the resources and created entries in the library
  • fixed the order of explosion animations to make SPE_SPR1 to become explosion ‚a‘
  • implemented returning shapes for the explosion ‚a‘ object
  • fixed cycles not being destroyed by the players shield like in the original game
  • started moving collision handling logic into the object classes themselves
  • started rewriting all game loop update code for game objects regarding collisions
  • oxyd rotors are the first game objects to define their own collision handling
  • implemented a default collision handling for collisions with the player ship
  • implemented object based collision handling for peashooter enemy types
  • split up collision handling method into ship collision and shot collision handling
  • fixed wrong log message for the destroy station command in the command manager
  • fixed enemies carrying ware possibly throwing a ware item with a different type
  • implemented object based collision handling for all previously defined enemy types
  • moved generic cargo throwing logic into the enemyship class
  • replaced all ship collision code with object based collision handling logic
  • created object based collision handling method for colliding with asteroids
  • made peashooters bounce and tailspin from the players shield for a better effect
  • removed duplicate code for handling dead enemies in the game loop
  • reduced method complexity from delegating collision handling to the objects themselves
  • deprecated lots of old methods that do not use object based collision handling
  • moved default implementation for game object collisions into ship object class
  • several more enemy ship types can now be deployed directly from the ship selector
  • created object based vanishing logic for game objects that need to despawn
  • implemented object based vanishing logic for aliens, ware and shots
  • cleaned up the way aliens and ware are being removed from the game object lists
  • game objects will now only be added or removed at the beginning/end of an update
  • destroy methods for all game objects will now be called upon being marked dead
  • missile objects will now handle their own emitting of spark particles
  • refactored update methods for ware, aliens and rescue capsules to improve readability
  • fixed the way rescue capsules are being removed from the game object list
  • fixed destroyed enemies possibly losing a ware item with a different type
  • implemented many missing getters and setters of addlists for different game objects
  • added calls to game object destroy methods before removing them from the object lists
  • created common methods for ejecting aliens and ware for enemy ships
  • destruction of enemy ships will now call the common eject aliens and eject ware methods
  • cleaned up update methods for enemies, enemy shots, rescue capsules, aliens and ware
  • cleaned up update methods for explosions, dissolves and score indicators
  • refactored addlists in the solar system class to clean up their names
  • removed ugly getters and setters for all addlists in the level
  • replaced all addlists getters and setters with simple to use delegate methods
  • decided to check objects for alive status in all update methods before updating them
  • added addlist delegate methods for also adding multiple game objects in one call
  • fixed setting wrong object type in the decoy shot class
  • moved piraton exact shot speed aiming into the aim helper class where it belongs
  • fixed shooting for the piraton enemy which will now shoot properly using the aim helper
  • simplified peashot class to remove redundant code in the object initializers
  • fixed initialization for all the shot classes to properly define their origin object

v0.9.12 – January 2022

  • finally added my favorite code metrics/LoC plugin (now Metrics3) to Eclipse again
  • added a new 2022 build splash image to the project
  • updated the project from using ProGuard version 7.1.0beta4 to version 7.1.1
  • rechecked all 16 piraton mono sprites by comparing with the SHL file
  • recreated all 16 piraton color sprites and added them to the resources
  • added SPI_GLID shapelist file to the resources and created entries in the library
  • implemented returning shapes for the piraton object
  • reordered key and modifier constants in the levels txt parser
  • added new modifier constant for harmful invader setting in the levels txt parser
  • implemented global level setting for harmful invader in the levels txt parser
  • fixed a bug with global harmful setting not being checked correctly
  • fixed a bug where the piraton used the wrong sprites
  • compiled the game with Java 17 and confirmed that it works perfectly using it
  • improved performance for writing sector difference debug text
  • created 4 colorized rotorstar sprites and added them to the resources
  • implemented a utility method to easily join two arrays of the same type
  • implemented a temporary fix to allow returning ship decorations as centered shapes
  • ship decorations will now work with ships that use shapes for drawing their appearance
  • implemented a method to floodfill enemy setups in a given sector range
  • implemented parsing the floodfill invader modifier and generate the level accordingly
  • implemented a basic cycle enemy ai that at least manages to circle around the player
  • implemented a method to retrieve a random position in a given distance around an object
  • fixed cycle animation not being updated anymore
  • vastly improved the cycle enemy ai which looks much more like in the original game
  • started slowly rebuilding my ST Spacola playtest and debug environment under Linux

Show complete changelog