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.39


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.88 alpha
  • Nächster Schritt: Vollständiger Kampagnenmodus (ab 0.90)
  • Beta-Release, erste spielbare Version (v0.90) (2020)
  • Finale Monochrom-Version (Classic) (v1.0) (Oktober 2021 oder so)
  • Kolorierte Farbversion mit höherer Auflösung (v1.1) (Ende 2021)
  • Spielbarer Multiplayer-Modus (v1.2) (when it’s done)
  • HD-Version mit hochauflösender Grafik (v2.0) (when it’s done)

Statistiken

Version: 0.88 alpha / Build 665
Datum: 01.09.2019
Grafikdateien: 1419
Audiodateien: 62
Codezeilen: 50.290
Pakete: 27
Klassen: 303
Größe Quellcode: 2,9 MByte
Größe JAR/EXE: 5,4 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.29 / 0.21


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 Windows 7. Auch unter Linux wurde erfolgreich getestet. 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?

Das finale Veröffentlichungsdatum der ersten komplett spielbaren Version habe ich auf den Oktober 2021 festgelegt, also pünktlich zum 30-jährigen Jubiläum des Originals. Bis dahin möchte ich aber 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.88 – September 2019

  • created 7 colored magic gimmick sprites and added them to the resources
  • created 6 megaroids big and small ufo sprites as a homage to the original atari st game
  • added the megaroids ufo sprites to the enum gfx lib and to the ship selector
  • implemented fireworks particle explosions and sound effects in the closing credits
  • implemented more enhanced explosion particles being ejected on mine destruction
  • created 9 colored minedropper shot sprites and added them to the resources
  • implemented minedropper shots spawning enhanced explosion particles on detonation
  • fixed wrong pixels in 4 colored station rant animation sprites
  • created 2 colored station cola animation sprites and added them to the resources
  • fixed log output class for several commands in the command manager
  • implemented destroying station objects for future game options
  • implemented station destruction command for the command manager
  • changed classic gfx engine to avoid rendering invisible game objects
  • fixed not drawing mine objects on the radar when they’re deployed by stations
  • fixed not drawing the player surfing animation even when the visible flag is not set
  • added playing fanfare/credit sound effect in the beginning of the closing credits

v0.87 – August 2019

  • fixed frozen object logic in the 2d vectors time based update method
  • created and added 83 flyex gimmick sprites to the resources and to the gfx lib
  • started implementing a generic time based update method for the game object class
  • added time based mileage and ticks calculation methods
  • implemented a generic method to create an animation sample from an Anims type sprite
  • implemented a ship decorator method to create an animation sample for the flyex fly
  • added the flyex fly to the ship selector object for testing purposes
  • implemented an overriding toString method for the abstract shot object for debugging
  • implemented a basic laser weapon class
  • modified Kleptomaras, Tornados and Wafers to allow using the laser weapon
  • the laser shot will now be more flexible to use in the laser weapon class
  • fixed error when updating the laser shot, the shot is now drawn correctly
  • implemented convenience methods to calculate an object vectors radians and degrees
  • the player can now finally shoot with the laser weapon
  • added weapon enum constants for the weapon factory
  • implemented a weapon switcher debug menu and corresponding commands
  • added common tostring method for the abstract weapon class
  • fixed a bug that prevented ships from firing micro shots
  • fixed a labelling problem for mines in the weapon switcher menu
  • implemented calculating the correct laser shot alignment when using smart aiming
  • implemented the pirate weapon class which can also be used by the players ship now
  • the pirate weapon can now also re-steal cargo from enemies and steal surplus aliens
  • fixed pirate shots not dissolving when hit an enemy that has no ware or surplus aliens
  • added the rocket object to the ship selector dialog grid
  • fixed pirate shots destroying asteroids
  • fixed pirate shots destroying various other types of game objects and not dissolving
  • confirmed and fixed animation phases for the solar selector clicked field
  • started implementing a generic minedropper weapon class
  • measured and implemented the size of the minedroppershot debris objects
  • made all the minedropper shot objects extend the abstract shot
  • replaced references to the playership in the minedropper shots with generic game objects
  • replaced instanceof in weapon factory with flexible enum types and switches
  • the minedropper will now also use the weapon interface classes
  • fixed a bug where the players weapon is initialized before the playerships own type
  • the player can now use the minedropper weapon and drop mines itself
  • added weapon enum types to all the weapon classes to determine their types
  • removed redundant code from force gameover command
  • fixed a bug that left the player dropped mines without motion
  • the playership object now also makes use of the alive attribute
  • the player now drops mines on destruction just as the minedropper enemies do
  • created and added 16 megaroids ship sprites to the resources and to the gfx lib
  • added the megaroids ship sprite to the ship selector as a homage to the atari st game
  • turned the weapon, cargo and border selection menus into radio button menus
  • reduced log level for restoring default parameters in the configuration file
  • fixed a menubar bug where the screen was resized twice on startup
  • fixed a new bug that made missiles unable to target the player properly
  • fixed a bug that made the player respawn animation not show
  • the gfx engine will no longer silently ignore inactive game objects
  • fixed an exception when explosions were drawn after they went inactive
  • fixed a very old unnoticed bug that made armed sector objects not disappear completely
  • fixed explosion and alien updating code to properly check on alive status AFTER updates
  • fixed surf animation not drawing after destruction of the players ship
  • fixed a bug that made the piraton unable to target when the player is not alive
  • fixed a bug that made the wrong station show animations triggered by events
  • implemented more checks to allow piratons to update even without a given target
  • confirmed that dgss(1) (station trap) is pixel perfect
  • changed the playerweapon long distance constant to 252 pixels (half game screen width)
  • measured the max distance for laser shots of starlasers, which seems to be 215 pixels
  • created 15 colored debris sprites and added them to the resources
  • created 62 colored explosion sprites and added them to the resources
  • measured and guessed the upper limit for debris spark particles ejection
  • guessed the debris spark particles ejection limit
  • fixed debris particles being ejected with too much force
  • confirmed number of debris particles in debris explosions for mine h3/8 objects
  • pulled some of the debris particles constants into the game config class
  • measured rectangular debris alive time to be at least 2.3 seconds (168 frames)
  • moved debris particles alive time constant into the game config class
  • fixed an old bug that made rectangular particles not dissolve correctly
  • fixed a bug that made starlaser shots go on infinitely
  • made the starlaser at least basically use a laser weapon object
  • fixed removing of inactive debris particles in the debris explosion class
  • fixed animation handling of debris spark particles which always happens synchronously
  • fixed random animation phase for debris spark particles
  • reduced debris particles max alive time to 2.5 seconds

v0.86 – July 2019

  • created 16 simple colored pirate turret sprites and added them to the resources
  • added a utility method to reverse the contents in a byte array
  • created a new macintosh style gem font (chicago) that was used in unknown TOS versions
  • created an info menu icon from the macintosh style gem font and added it to the resources
  • created and added a bob dobbs face menu icon from the original gem font
  • created and added a bell menu icon from the original gem font
  • grouped all gem related menu icons together into a common resource folder
  • implemented gem mac font as a subclass of the original gem font
  • the game font loader now instantiates a gem mac font and a colored gem mac font object
  • only the menu resource class creates image icons from the gfx library
  • made all other gui classes take their icons from the menu resource class
  • created 16 simple colored deadly turret sprites and added them to the resources
  • created 2 simple colored mine sprites and added them to the resources
  • created 2 simple colored starlaser sprites and added them to the resources
  • fixed framestopwatch to set the target framerate as the limit for frameskip
  • added implementational game object type sets predefined for their related object lists
  • wrote a method to determine which game object lists are affected by a given type set
  • fixed framestopwatch to reset the time deficit when it exceeds a second
  • fixed a bug that enabled the player to shoot objects with 1 shot per frame
  • rewrote getting game objects in view and getting the nearest objects in view
  • finally auto aiming only targets shootable object types and ignores indestructable ones
  • implemented an abstract shot class with basic functions common to all shot types
  • made the player shot class extend the abstract shot and removed redundancies
  • measured and predefined the player shot size in the config
  • rewrote major parts of the weapons and shot code to allow defining variable limits
  • implemented a pea cannon class that is used by peashooter enemies
  • player and enemy shots are now optionally vanishing when out of sight
  • fixed laser shots and pea shots not extending the abstract shot class
  • added vector2d methods to also conveniently subtract a specified motion vector
  • fixed reversing the aimed shot incorrectly for the reverse shooting powerup
  • fixed exception when illegally casting missile object to shot
  • fixed changing the target update rate during the game breaking frame calculations
  • implemented a game speed menu in the menubar that allows reducing the current game speed
  • renamed some constants for radar area and gamescreen view area vanishing distances
  • vanishing distances for weapons and shots will now be set and checked dynamically
  • pea shots of players will now only vanish when leaving the players field of view
  • setting the update rate in the frame stopwatch will now also limit the number of redraws
  • created 7 weapon menu icons for the menu bar to allow implementing a debug weapon menu
  • created 8 cargo menu icons for the debug menu options changing cargo ingame
  • added cargo menu icons for the cargo switcher debug menu
  • added a method to completely reset the framestopwatch
  • fixed choppy graphics after setting/resetting the update/redraw rate in the stopwatch
  • compiled and tested the game under AdoptOpenJDK 8 with Eclipse OpenJ9, works great
  • the game client will now also show the current java vendor (which is not always Oracle)
  • implemented a debug method that outputs all (known) system properties to the console
  • fixed output and refactored method for java version details text
  • added a much better method to fetch and print all available system properties
  • added a simple utility method to also detect macOS as running operating system
  • implemented a debug method to fetch and print all system environment variables
  • the game client now offers 5 different game speed settings between 72 fps to 3 fps
  • removed all versions of Oracle jdk and jre, will develop solely using AdoptOpenJDK

Show complete changelog