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.80 alpha
  • Nächster Schritt: Originalgetreue Gegner-KI (ab 0.75)
  • Danach: Vollständiger Kampagnenmodus (ab 0.85)
  • Beta-Release, erste spielbare Version (v0.9) (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.80 alpha / Build 665
Datum: 23.12.2018
Grafikdateien: 1090
Audiodateien: 62
Codezeilen: 48.510
Pakete: 27
Klassen: 293
Größe Quellcode: 2,7 MByte
Größe JAR/EXE: 5,2 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.80 – December 2018

  • implemented an enemy factory class that contains all the enemy object instantiation logic
  • fixed showing ’null‘ as java version, shows a proper ‚unknown java‘ message
  • briefly tested running Spacola Eclipse on OpenJDK11, which works fine for now
  • started writing a small powerup scan util swing application for the atlas powerups
  • implemented pressing and releasing the control key modifier to allow key bindings for it
  • implemented drawing all the powerups directly over the level grid in the selector
  • fixed draw height for the grid powerup overlay
  • completed the powerup scan utility that helps in transcribing all powerups from the book
  • transcribed and verified the powerups on the first 3 pages of the book
  • transcribed and verified the powerups up to page 29
  • transcribed and verified more pages up to page 39
  • transcribed and verified more pages up to page 50
  • transcribed and verified more pages up to page 75
  • transcribed and verified more pages up to page 103
  • transcribed and verified more pages up to page 115
  • transcribed and verified more pages up to page 131
  • transcribed and verified more pages up to page 151
  • transcribed and verified all powerups on all pages of the space atlas
  • replaced the raw space atlas file with the one containing all the powerups
  • rewrote the raw space atlas parser accordingly to allow parsing powerups
  • codes and ids will now be stored as integer values to save lots of space
  • added methods to get the code as hex values or integer whenever needed
  • tabs will now be stored as integer values and can be returned as string or int
  • allowed retrieving tabs from the codebook using integers or string identfiers
  • implemented writing and reading the space atlas from a compressed binary file
  • added constants for the space atlas pages, tabs and rows/columns
  • implemented a method to numerically calculate the page number for a given code id
  • implemented calculating the precise book position for any given code id
  • implemented retrieving the exact code element and code string for a given code id
  • added methods to load and handle packed bytes from files
  • the game client will now load and uncompress the compressed 46 kbytes binary atlas
  • fixed wrong field alignment in the solar selector, which was inverted the whole time
  • fixed old and buggy code for retrieving the start powerup for a given level number
  • the solar selector now uses the exact same powerup layout as used in the space atlas
  • scrambling the solar selector grid randomly is now deprecated and won’t be used anymore
  • fixed wrong tab number to tab identifier conversion in code tab and code element classes
  • made the level grid layout generation dependent on the space atlas randomizer
  • fixed project not correctly being built using java 8 compiler compliance level
  • fixed using wrong upper bounds when calling the game random from the solar selector
  • created 16 maforian sprites with simple colorization as a placeholder for better sprites
  • added the new colored maforian sprites to the resources and enum gfx library
  • removed time measuring from the main client window class
  • rewrote time measurements for startup time and overall uptime
  • fixed generated uptime string being empty if less than 1 second
  • added milliseconds to the text resources and considered ms in the uptime string
  • fixed milliseconds text output for single vs. multiple milliseconds

v0.79 – November 2018

  • added an extra weapons package and started implementing a weapons interface
  • the ship interface now features the powerup manager and the engine positions
  • all enemy ships will now basically be able to retrieve powerups
  • started implementing the players standard weapon as an exchangeable class
  • introduced a new enemyship abstract class which is used to share common ship behavior
  • fixed all available enemy classes to correctly extend the enemyship class
  • now there are plain enemies (i.e. turrets), plain ships (Player, Rocket), and enemy ships
  • successfully implemented the player weapon as an exchangeable weapon
  • fixed german text grammar for the unfinished alpha instructions message
  • rewrote parts of the powerup managing class to allow generic usage in other ship classes
  • unified enemy and enemyship classes again, didn’t improve code readability
  • pulled turret aiming behaviour into the common enemy class to help generalizing shooting
  • implemented weapon cooldown for the player weapon
  • implemented turrets being able to use the player weapon
  • introduced turret motion cooldown in contrast to weapon cooldown, turrets having both
  • enemy turrets can now perfectly use the players weapon if configured to do so
  • fixed player weapon shots fired by enemies not dissolving properly
  • implemented generic direct and smart aiming methods in the enemy class
  • improved encapsulation for player weapon shot speed and shot distance calculation
  • fixed turret code that handles aiming at the player and triggering the weapon
  • fixed log output class id determination for player ship
  • implemented weapon factory class that contains the weapon configuration for all ships
  • implemented a rocket weapon that can be used for active game entities
  • implemented rocket weapons as addons for the player weapon and activating it via powerup
  • fixed rocket weapon not working as a primary weapon
  • weapon cooldowns are broken for the moment, tried fixing it, but it’s more complicated
  • fixed powerups not being shown in the hud status display anymore
  • implemented a vector method to easily reverse any given vector by a simple call
  • changed weapon interface and player weapon to enable manual and automatic shooting
  • implemented getting nearest enemy type object for a given reference object
  • implemented getting nearest sector object in a 3×3 sector range
  • split up methods between get nearest objects for player object and for reference objects
  • implemented method to calculate current sector for any game object
  • implemented methods to get a 3×3 sector range for any given reference game object
  • fixed get random from list method with correct type parameter to set the return type
  • changed specialized sector retrieving methods to reuse the more generic ones
  • changed sector object handling to use concrete classes and not generic game objects

v0.78 – September 2018

  • started implementing a host game window that allows the host to set multiplayer options

v0.77 – August 2018

  • implemented a method to reset individual properties in the config file
  • tested and verified that 1920×1200 (3x scaling) game window runs perfectly smooth
  • added real screen scaling options menu, user can choose 1x, 2x and 3x graphics scaling
  • fixed startup init order of properties and text resources before spacola splash
  • improved loading, automatic verifying and fixing of properties from the config file
  • properties will now be validated against a list of accepted properties
  • confirmed that there is a 2 frames station animation delay on bomb and win events
  • finished the delayed game event handler and added sub events for bomb and win events
  • removed station specific delay methods from the station class
  • delayed game events seem to work, but introduced other bugs
  • fixed cargo bay bomb animation throwing exception on the very last frame again
  • fixed bomb event being reset when revisiting a pirate station after rant animation
  • removed spacola splash dependency of properties and text resources
  • the spacola splash screen now shows waiting/loading dots animation instead of text
  • fixed byte array log handler losing its content when changing the debug level
  • started implementing an obfuscation class that handles encoding text like the ST game
  • tested and fixed ROL and ROR bitwise calculations and added convenience methods
  • marked ROL and ROR bitwise calculations as broken because they all create wrong results
  • implemented utility methods to convert Atari ST chars to unicode and vice versa
  • implemented more utility methods to convert between a series of hex numbers and text
  • finally implemented the complete assembler text obfuscation encoding and decoding
  • added degree and bullet sign characters to the Atari to Unicode char conversion
  • fixed debug menu win command not triggering the delayed game event handler
  • fixed a bug where the win animation state is set for the wrong station
  • added unknown/undocumented powerup ‚E‘ to the powerup map and class for accuracy reasons
  • added starlasers to the (deployable) game object map for accuracy reasons
  • implemented being able to deploy starlasers as ships via level script or by command
  • fixed old drawing method used in the solar system game class
  • started rewriting the multiplayer game class to make it work again after lots of changes
  • added multiplayer level rendering methods to the graphics engine class
  • fixed several parts that got in the way of enabling multiplayer games
  • finally got the multiplayer game to start again without any errors
  • removed redundancies from multiplayer level class by adding a common preparation method
  • fixed code occurrences where the legacy game panel is modified instead of the canvas
  • fixed multiplayer game initialized with the wrong hud view image
  • game clients will not be validated every single method call, but instead once per tick
  • started implementing sending game objects back to the server to allow seeing each other
  • fixed sound effects not stopping when a multiplayer game ends
  • tried rewriting the code that is responsible for controlling the player ship
  • pulled control related acceleration and shooting code out of the controls class
  • simplified player shooting code and split between manual and automatic shooting
  • tried fixing some occasional, mysterious slowdown issues with 72 updates/sec

v0.76 – July 2018

  • fixed some of the letters in the modified dongleware title with the original letters
  • replaced the dongleware title image with a correct one
  • fixed some of the letters in the success denied title with the original letters
  • replaced the success denied title image with a fixed one
  • fixed border errors with the dongleware switch sprite used in several title designs
  • replaced switched off dongleware title image in the resources
  • replaced game client title image with a fixed one with correct letters
  • replaced the build splash image with a new one which has a fixed digit ‚8‘
  • converted the project workspace for the new Eclipse Photon release
  • updated the project from using Launch4j version 3.11 to version 3.12
  • updated the project from using ProGuard version 5.3.3 to version 6.0.3
  • once again confirmed 6269 Hz as the correct sampling rate, appears next to the filenames
  • tried to measure sector size more precisely, but encountered too much variation
  • confirmed radar to main display ratio of 1:64 pixels once again, 62 is the highest number
  • kinda confirmed sector size by radar measurement, flythrough time, and flythrough frames
  • kinda confirmed that the original game only moves objects on frame redraws, not inbetween
  • recalculated some measurements for the sector size. Found results to come close to 4096
  • kinda confirmed that the original game accelerates the player 72 times per second
  • confirmed the acceleration calculation for the remake, 72 updates/sec are correct
  • created a new spacola dongleware font derived from the oxyd color dongleware font
  • added the new spacola dongleware font to the resources
  • changed release date in the certificate class to 2021
  • created and added new dongleware title and switch images with the new color scheme
  • fixed wrong log output class in some log output in the levels txt parser
  • added a way to load levels.txt raw file as a fallback on startup
  • fixed a problem with the wrong encoding when loading raw text files
  • created and added a new encrypted levels pac file
  • the levels txt parser now ignores all unknown level data at the end of the file
  • confirmed speed warning limits by measuring star speeds to be exactly 25 and 100
  • these values seem to strengthen the fact that the player speedup is 0.1 per frame
  • changed the cargo bay background back to dithered blue
  • created two colored instructions button images and added them to the resources
  • added math methods to add or subtract integer values using modulo
  • added a basic animation class for simple image sequences
  • tried to add key events for pressed keys, but it doesn’t work like intended in java
  • the fake tos module now always starts with the full 72 Hz redraw rate
  • at least managed to add key events for pressed and released shift keys
  • implemented own logic to prevent subsequent same key press events for shift keys
  • the level numbers in the solar selector can now be shown by pressing shift
  • added enter key handling in the solar selector which enables all levels at once
  • removed LZH decompression libraries, since they won’t be needed anymore
  • improved the animation class and added max animation count, pause frames
  • renamed animation class to simpleanimation for better distinction from library classes
  • fixed errors in the shapes of the four monochrome cargo bomb sprites
  • renamed minestar enemy to starlaser (SL), which may be the original name or similar
  • moved starlaser sprites into their own sprite folder
  • created 4 colored bomb sprites from Oxyd Magnum colored version bomb sprites
  • fixed bomb drawing code to allow drawing colored bombs with xor effect
  • fixed a bug where the bomb animation starts with an exploding bomb frame
  • fixed the order of the bomb sprites, which was wrong for both mono and colored sprites
  • confirmed length of bomb state (8 seconds) and animation phases (72) in the original game
  • confirmed pause status message blink frames to be 36 frames exactly
  • created a status screen class and pulled all status screen code out of the hud class
  • split the status screen and hud update and drawing code
  • implemented a 2 frame bomb animation delay in the player ships code
  • the bomb animation in the hud is now frame perfect and delayed by 2 frames
  • created a delayed game event handler class that handles frame delays for game events
  • fixed an encoding bug that prevented parsing the levels txt in the built jar/exe file
  • cut out all 3 fly-ex cursor sprites
  • cut out all 24 of the fly-ex fly „flying“ sprites
  • fixed the bolo border design where i somehow screwed up the left wall
  • fixed more transparent pixels in the bolo border design which i got wrong

Show complete changelog

nach oben