Spacola

spacola_splash_web

Drei Spiele, die mich in meiner Kindheit ganz besonders begeistert haben? Da würde ich bestimmt Super Mario Bros. auf dem NES nennen, und Cadaver auf dem Atari ST, und sowas wie Test Drive II auf dem Amiga. Würde ich bestimmt, wenn da nicht vorher ganz andere Spiele gewesen wären, die mich auf eine völlig andere Weise begeistern konnten. Drei Spiele, die ich in einem Atemzug nennen kann: Bolo, OXYD und Spacola. Drei Spiele für den Atari ST, die alle zufällig von einem Entwickler sind: Meinolf Amekudzi.

Diese Spiele zeichneten sich durch detailreiche, hochauflösende Monochromgrafik aus, durch witzigen Sound, durch anfangs unglaublich 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 verdammt. Schade eigentlich, dabei hatte gerade dieses Spiel seinen ganz eigenen Charme, weil es kein typisches Geschicklichkeitsspiel war, sondern auch viel Action bieten konnte.

Spacola Eclipse ist ein von mir derzeit entwickeltes Remake von Spacola, also eine möglichst detailgetreue Nachbildung für moderne Betriebssysteme, und da mir der Original-Quellcode leider nicht zur Verfügung steht, muss ich zwangsläufig alles vollständig aus der Beobachtung nachimplementieren. Das Remake wird in Java entwickelt und wird somit theoretisch unter jedem System lauffähig sein. Sobald es denn mal fertig ist.

Test Test

Video Preview – Version 0.39

YouTube Preview Image

Features

Bereits implementiert

  • Originalgetreue Monochrom-Grafikengine (Classic-Modus)
  • Titelmusik und Sound wie beim ST-Original, zusätzliche Ingame-Musik
  • Intuitive Maussteuerung zum Drehen, Feuern und Beschleunigen
  • Animierter Radarschirm
  • 11 Powerups, 13 Gegnertypen, Raumstationen
  • Schiffbrüchige Piraten, Asteroiden, Fracht, Schwarze Löcher, Minen
  • HUD-Anzeige für Koordinaten und Punktezahl
  • Parallaktischer Sternenhintergrund
  • Pixelbasiertes Partikelsystem für Schub und Explosionen
  • Komplettes Intro mit Titeln, Highscore, Kurzanleitung, Level-Ende-Screen
  • Fünf verschiedene Mauszeiger im ST-Stil (z.B. TOS-Biene, Zielvisier, Rakete)
  • Dongleware-typisches Titel-Fading mit Dithering
  • Menüleiste für die wichtigsten Funktionen, zusätzlich zum Hauptmenü
  • Multilingual, Deutsch und Englisch bereits integriert, problemlos erweiterbar
  • Fake-TOS-Ladebildschirm und Splashscreen
  • Lauffähig auf jedem Betriebssystem mit Java
  • Geringe Hardwareanforderungen

Weiterhin geplant

  • Mehr Gegner
  • 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.44
  • Nächster Schritt: Übrige Powerups, mehr Gegner (v0.45)
  • Danach: echter Kampagnenmodus (v0.50)
  • Beta-Release, erste spielbare Version (v0.5) (Frühjahr 2015)
  • Komplett spielbare Milestones (v0.6 – v0.9) (Sommer 2015)
  • Finale Monochrom-Version (Classic) (v1.0) (Oktober 2016)
  • Kolorierte Farbversion mit höherer Auflösung (v1.1) (Ende 2016)
  • Spielbarer Multiplayer-Modus (v1.2) (when it’s done)
  • HD-Version mit hochauflösender Grafik (v2.0) (when it’s done)

Statistiken

Version: 0.44 alpha / Build 177
Datum: 15.05.2015
Grafikdateien: 810
Audiodateien: 53
Codezeilen: 21799
Pakete: 20
Klassen: 181
Größe Quellcode: 1 MByte
Größe JAR/EXE: 4,7 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

In welcher Programmiersprache wird SPACOLA Eclipse programmiert?

Das Remake SPACOLA Eclipse wird komplett in Java geschrieben. Auf dem Atari ST wurde Spacola soweit mir bekannt mit dem Megamax Modula-2-Compiler entwickelt, die zeitkritischen Komponenten (Grafik, Sound) direkt in 68k-Assembler.

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.

Wann wird SPACOLA Eclipse veröffentlicht?

Leider kann ich SPACOLA Eclipse erst veröffentlichen, wenn es spielbar ist. Im Moment läuft es, und es macht auch so einiges, aber das vorliegende Programm eignet sich höchstens als Demo. Im Moment ist noch nicht absehbar, wann es soweit sein wird. Mit etwas Glück möglicherweise noch 2015.

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 ausgerechnet 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.44 – May 2015

  • replaced all 16 harakiri enemy sprites with newly rotated ones (more like maforians)
  • fixed score indicators now blinking perfectly like in the original game
  • added a utility method that converts target frame rate to frame time
  • the frame stopwatch class can handle differing update rates and frame rates
  • created a much better algorithm to distribute a reduced number of redraws among updates
  • made vortex updates independent from draw calls
  • fixed a recently introduced bug where tailspinning turrets would vanish by shooting at them
  • fixed precalculating 0 vortex coils for some stars, which looked awful
  • fixed a bug in the vortex class that ignored random coils if enhanced transitions were disabled
  • fixed a calculation bug in the methods that convert level coordinates to screen coordinates
  • fixed a bug in the vortex class that made objects be drawn off centered
  • finally implemented game objects being used in the vortex intro animation
  • fixed a newly introduced bug where the vortex would not be updated during gameover animation
  • finally implemented game objects in the vortex gameover animation too
  • fixed a bug in the vortex which made it unable to determine the distance of a vortex element
  • reinstated hiding elements that are very close to the vortex center
  • added origin attribute to game objects to allow calculating their distance in pixels
  • added method to game objects to get their distance from origin
  • confirmed and added the value how far player shots can go without LONG powerup
  • implemented incrementing travelled distance attribute for all game objects
  • changed the way how the game calculates when to dissolve player shots
  • added more log output to audio playback methods
  • changed all derived game objects to always update the base object instead of only their vector
  • renamed rotatingstar enemy to rotorstar

v0.43 – April 2015

  • created a Dongleware color font image from an online source
  • added four new characters to the Dongleware mono font ( \,[,],Command )
  • fixed # character height in the Dongleware color font
  • added ß character to the Dongleware color font
  • replaced äöüß characters from video with screenshot cutouts
  • added ÜÖ characters from screenshots
  • confirmed letter X cutout
  • redid the complete Dongleware color font from scratch using a colored OXYD version
  • recompressed the Dongleware font with indexed palette
  • removed faked square brackets from mono Dongleware fonts again
  • improved the english translation of the instructions using international OXYD version
  • recompressed all 746 PNG files again (w/o bg color) to save another 36 kbytes of useless data
  • added 3 defender sprites and included them in the gfx library
  • recreated 4 blackhole shapes from TOS-Gimmick, OXYD and OXYD Color graphics
  • redid all 3 blackhole sprites using the new shapes
  • pulled VortexElement and Star into their own dedicated class file
  • version of the JRE and the operating system will now be written into the logfile on startup
  • added utility methods to generate date and time strings
  • the text resources class will now keep a default resource bundle for logging etc.
  • the max number of characters allowed in the enter highscore screen confirmed/set to 22 chars
  • the fallback highscore name entry prompt also enforces max number of characters now
  • replaced the DOLLAR.SDD sound effect with OXGELD oxyd sound, which is identical
  • added OXKLICK6 and OXKEY oxyd sound effects to the audio library
  • BING sound will be played if you exceed the max number of characters in highscore prompt
  • OXKEY sound will be played when someone presses keys during the game
  • added sector shifting and extralife events for the CommandManager
  • rewrote events through keyboard input to be invoked only in the CommandManager
  • rewrote logging for keyboard input
  • rewrote CommandManager to allow setting multiple commands per frame
  • pulled player being destroyed by bomb event out of the HUD drawing code
  • created 3 wafer sprite shapes, but i doubt that i got it right
  • added all 16 wafer (WA/WAFF) sprites to the resources
  • implemented wafer as a dummy enemy to the station deployment
  • added all 4 “lightball” (L) sprites used as an enemy in levels 59 and 60
  • added all 5 “retaliator-jet” (RJ) sprites used as an enemy in level 58 only
  • recentered the mothermaforian sprites using the shield sprites; considered pixel perfect now
  • fixed first rocket drive shape which was missing a lot of shaded pixels
  • fixed 4 rocket drive sprites (axis aligned) which had wrong shading
  • added a lightball intro title image
  • fixed third rocket drive shape which seems to be actually two different shapes
  • fixed another 4 rocket drive sprites (diagonal aligned) which had wrong shading
  • finally figured out how the game draws the rocket drive sprites onto other sprites
  • created 3 (finally correct) rocket drive shapes
  • fixed all 16 rocket drive sprites with correct shadows below their shape
  • recentered and trimmed all 16 rocket drive sprites
  • again fixed 5 rocket drive sprites by comparing them to rocket gun sprites
  • added legacy intro title images for shieldmaforian and shieldmothermaforian
  • verified through the manual the first blackhole sprite to be pixel-perfect
  • added oxyd stone, cherries and telephone menu icon
  • fixed 7 (shape 2) rocket drive sprites for the last time. Def pixel-perfect now
  • fixed wrong score for kleptomaras in the intro titles
  • fixed larger sprites (big asteroid) being drawn correctly in the price lists
  • fixed some horizontal margins for the generated pricetags with sprites
  • reduced margin between dotline and the price to 9 pixels minimum (seems correct)
  • inserted all (but one) of the new enemy and bonus object sprites to the price lists
  • deprecated old method that draws a dotline, becauses it may use wrong margins
  • fixed two white pixels on the toiletpaper cargo bay sprite
  • created 40 pricelist images that will be used instead of actual ingame sprites
  • rewrote parts of the price list code that generates price list items
  • removed sprite centering in the price lists since all images are the same size
  • finally completed intro with all price lists, even all the margins are pixel-perfect now
  • fixed a bug where enemies could retrieve cargo from the player, even if he has none
  • added some navigation and acceleration methods to enemy class
  • all enemy AIs are now able to see the whole level
  • rewrote Piraton enemy AI to make them smarter
  • Piratons can finally collect free floating aliens/ware, and deliver ware to the station
  • fixed a bug where destroyed pirates were able to recollect their own pilot
  • allowed the pirates to go faster if they try to collect aliens or cargo
  • added last two ware type images to the ShipDecorator, Ware and Hud class
  • fixed a bug the ShipDecorator where the wrong cargo sprites would be used
  • pirates which collect fellow aliens will now also release more aliens on destruction
  • wrote some automatic braking logic for enemies which are refocusing
  • the enemies will no longer unnecessarily reset the target on each frame
  • wrote a method that determines if a pirate ship is perfectly on course
  • created 3 harakiri enemy sprite shapes
  • fixed 3 harakiri sprites with wrong pixels

Show complete changelog

nach oben