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.23 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.23 alpha / Build 931
Datum: 24.03.2024
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.23 – March 2024

  • started implementing junit test cases for Vector2D math class
  • added a new 2024 build splash image to the project
  • updated the project from using ProGuard version 7.3.2 to version 7.4.2
  • fixed a bug where the game statistics dialog could not be opened anymore
  • rewrote gathering of all statistics metrics for the statistics dialog
  • added more log warning output for the game statistics
  • removed obsolete setters in the game statistics class
  • implemented replay method to determine if the replay version is compatible
  • tried fixing massive swing problems that have occurred for no reason
  • implemented a test window class to find the cause of the swing problems
  • removed old jar in jar loader dependency from eclipse runnable jar feature
  • added creating a dst folder for distribution of dependencies/libraries
  • all jar dependencies will now be extracted and repackaged when building the jar
  • the runnable fat jar of the game now also works with Java 17 again
  • removed showing an unnecessary warning when parsing an empty level patch configuration
  • confirmed that the game client runs with Java 21 but the audio is broken then
  • switching to Java 21 actually solves the mysterious Swing problems with all dialogs
  • fixed including duplicate library classes in the proguard ant targets
  • cleaned up the build process and removed redundant folder handling
  • added several demo classes for software line audio mixing and tone generation
  • started rewriting audio playback using software mixing for a single source line
  • implemented fixes for narrow no-break spaces appearing in newer java formatted time
  • fixed a bug with debris explosions being drawn when their base explosion is inactive
  • fixed an old bug in the station trapper that prevented creating more than one mine layer
  • deprecated an old station trapper method and removed redundant call to trap index setter
  • fixed a bug that left the starlaser without a weapon after station trap placement
  • tried finding a way to retrieve another mixer on newer Java versions under linux
  • added icedtea-sound.jar including libicedtea-sound as a dependency to the game libraries
  • implemented loading the shared library libicedtea-sound.so located in the workspace
  • implemented retrieving a PulseAudioMixer as default audio device with Java 21
  • finally the game can play more than one sound simultaneously again using PulseAudioMixer
  • modified the ant build script to include icedtea-sound and its native library
  • implemented extracting native libraries into the game folder to allow loading them
  • the jar file can now extract the native icedtea-sound library and use it for audio
  • implemented initializing the audio playback device and showing information and warnings
  • fixed potential problem with the wrong object being terminated when enemies collect ware
  • implemented object based collision handling methods for collisions with floating aliens
  • implemented object based alien collision handling method for the player ship
  • implemented default implementation alien collision handling for enemy ships
  • the level will now check all enemies for collisions with all alien objects

v0.9.22 – November 2023

  • implemented utility methods to determine hostname and ip address of the current machine
  • starting the multiplayer server now logs the hostname and ip address that it is using

v0.9.21 – September 2023

  • implemented enemy ships having their own tailspinning duration values
  • reduced tailspinning time for maforian enemies and increased their bounce mass
  • reduced acceleration for maforian enemies to the same value as the players ship
  • implemented object based collision handling methods for station collisions
  • changed maforians to just fly through the station while delivering stolen cargo
  • fixed enemy ships exploding when being despawned by the station during delivery
  • fixed redeployment for piraton enemies after object based station collision handling
  • removed now redundant destroy method from neutralroamer and neutraldeliverer class
  • rewrote generic returnware enemyship method to handle returning stolen ware
  • removed two older returnware methods that contained lots of redundant and bad code
  • rechecked all 16 mothermaforian mono sprites by comparing to the SHL file
  • recreated all 16 mothermaforian mono sprites for the sprites archive
  • created all 16 mothermaforian color sprites and added them to the resources
  • added SPI_DTAM shapelist file to the resources and created entries in the library
  • removed the 16 mothermaforian mono sprites from the png file resources
  • implemented returning shapes for the mothermaforian object
  • implemented an enemypool class for stations which handles instantiating enemies
  • implemented creating maforian formations when they are detected in the enemypool
  • rewrote enemyship deployment and redeployment for stations to make use of enemypools
  • stations will now be able to (re)deploy several enemies at once if the queue suggests it
  • fixed neutral ships accidentally destroying stations upon arrival
  • deployment of mothermaforians with two maforians as a group now basically works
  • implemented maforians following the mothership and turning towards the target
  • maforians in formations will now get unlocked as soon as their mothership is destroyed
  • implemented object based collision with station handling method for the playership
  • fixed playership being able to interact with stations that are not alive
  • simplified enemy deployment logic in the level and removed redundant code
  • implemented a play method that makes use of basic sound panning
  • changed the default line audio format from mono to stereo
  • reimplemented using pan or balance audio line controls if they are available
  • finally got a single sound to play with panning enabled successfully for the first time
  • implemented more methods in the sound engine to get mixer lines and line formats
  • implemented debug methods to get and print a list of available audio formats for a line
  • rewrote all the sound engine methods to get mixers, audio lines and audio formats
  • implemented methods to print all combinations of audio lines and supported formats
  • implemented method to print all mixers with all audio lines and all supported formats
  • using stereo channels seems to destabilize the audio of the game, so only mono for now
  • tried finding a way to get the maforian formation code to work authentically
  • confirmed that maforians locked to mothership can steal cargo, but won’t return it
  • fixed a bug where the time played was cast to the wrong type in the statistics
  • readded idle time after deployment to help deploying maforian formations
  • added follower number as a maforian attribute to define their position in the formation
  • maforians in formations will be pulled towards certain wing points behind the mothership
  • finally got the maforian formations to work and it looks almost fine for now
  • fixed a bug where neutral deliverers exploded when delivering their cargo
  • removed code that despawned neutral roamers as soon as they touch a station
  • fixed generating shieldmothermaforian images for the ship selector buttons
  • fixed ship selector animations not using shapes for the mothermaforians and harakiris
  • created empty dummy method for gameobject collisions with ware objects
  • implemented object based ware collision handling method for the player ship
  • implemented default implementation ware basic collision handling for enemy ships
  • moved delayed playback of ingame song into delayed game event handler
  • fixed a bug where maforians would never return their ware even when no longer locked
  • changed define invader can shoot parameters from local to global in the levelstxtparser
  • the level will now check all enemies for collisions with all ware objects
  • added cantina call powerup to the ‚grant all powerups command‘
  • moved all cantina call code into the powerup manager and thus made it player specific
  • removed check tick events method in the solar system class
  • implemented an update method for the powerup manager to handle updates to powerups
  • removed shield and cantina call checks from the playership update code
  • confirmed that the players motion is taken into account for cantina call enemy behaviour
  • increased the time that enemies need to reach their cantina call flight motion
  • implemented vector2d methods to merge base+current motions or merge them into base
  • implemented method to unlock a formation maforian from its mothership
  • fixed a bug where a formation maforian loses most of its momentum when unlocked
  • implemented a method to help explicitly updating a base object for any derived object
  • tried fixing problems with unequal object updates becoming apparent at high speeds
  • implemented a single method to add all new game objects for all types
  • new game objects will now be added only at the beginning of every game update
  • renamed old remove-methods in the solar system to reflect them removing all entities
  • implemented a single method to remove all inactive game objects for all types
  • dead or inactive game objects will now only be removed at the end of every game update
  • changed all remaining types for object type specific collections to gameobject
  • fixed cast to wrong data type for mileage statistics after ending a level
  • implemented log warnings when level script commands are not terminated properly
  • implemented floodfilling modifier for asteroid level script command
  • confirmed that station script command without fill modifier is not applied to the level
  • reconfirmed all default values and value ranges for the station script command
  • added new level station parameters constants with proper naming to the game config
  • removed some redundancy in station config modifier code and added more cleanup code
  • properly inserted all station default values and value ranges in the levels text parser
  • refactored station deployment variables and used the new default values
  • confirmed that sector range parsing must use 0 as default value for all unset params
  • switched order of parameters for sector range parsing in level scripts from x-y to y-x
  • rechecked all 8 explosion ‚e‘ mono sprites by comparing to the SHL file
  • recreated all 8 explosion ‚e‘ color sprites and added them to the resources
  • added SPE_SPR5 shapelist file to the resources and created entries in the library
  • removed the 8 explosion ‚e‘ mono sprites from the png file resources
  • fixed the order of explosion animations to make SPE_SPR5 to become explosion ‚e‘
  • implemented returning shapes for the explosion ‚e‘ object
  • added a sprite from the space trader palm os game to the optional project graphics

Show complete changelog