Schlagwort-Archive: OXYD

Wieder einmal in drei Wochen nicht einen einzigen Beitrag geschrieben. Aber heute schaffe ich es. Ich habe ein freies Wochenende, ich habe Motivationsmusik laufen, ich habe Kaffee gemacht, ich muss mich nur noch konzentrieren! Tschakka! Nein, SuccessDenied wird nicht eingestampft, aber die Zahl der regelmäßigen Beiträge hat sich leider wieder einmal reduziert. Beruflich bin ich zur Zeit derart eingespannt, dass ich abends nur noch froh bin, wenn ich nichts mehr machen muss. Manchmal wundere ich mich selbst, wie ich überhaupt noch zu etwas komme. Nunja, in acht oder neun Wochen ist ja schon wieder Urlaub. Bis dahin versuche ich möglichst viel auf Autopilot unterwegs zu sein.

Trotz all der Widrigkeiten arbeite ich weiterhin im kleinen und im ganz kleinen Rahmen an meinem SPACOLA-Remake. In genau einem Jahr soll die Monochromversion fertiggestellt sein. Das ist ein sportliches Ziel, wenn man sich vor Augen führt, dass ich seit fünf Jahren an dem Spiel bastle, und mir täglich mehr Dinge auffallen, die ich leider nicht richtig hinbekommen oder komplett vergessen habe. Die To-Do-Liste wird erstaunlicherweise niemals kürzer, nur noch länger und länger. Die aktuelle Version 0.49 vom Oktober 2015 hat die 30000 Zeilen übersprungen. Hier eine kleine, unvollständige Liste der Dinge, die kürzlich hinzugekommen sind:

Kollisionsauflösung

Die Gegnerschiffe im Originalspiel können (bis auf eine einzige Ausnahme) sich im Flug niemals gegenseitig berühren, sie können lediglich mit dem Spieler und den Asteroiden kollidieren, durch andere Entitäten fliegen sie immer hindurch. Auch die Asteroiden selbst fliegen immer durch andere Asteroiden hindurch. Inzwischen habe ich meiner kleinen 2D-Engine einen Algorithmus verpasst, der es erlaubt, unter Spielobjekten wechselseitig auf Kollisionen zu prüfen. Mit steigender Anzahl der Objekte steigt der Rechenaufwand leider enorm, das Spiel wird spürbar langsamer, daher muss gewährleistet sein, dass diese Methode nur auf eine überschaubare Anzahl von Objekten angewandt wird. Hinzu kommt, dass eine Kollisionserkennung bzw. -vermeidung leider nicht ausreicht, wenn die Objekte z.B. von der Schwerkraft permanent in dieselbe Richtung gezogen werden. Schnell ergibt sich so die Situation mehrfacher Überlagerungen, oder von Objekten, die gerade durch Anwendung des Abprallvektors wiederum in ein anderes Spielobjekt hineingeschoben werden.

Es musste eine Methode zur aktiven Kollisionsauflösung gefunden werden, die auch in einer großen Ansammlung von Spielobjekten funktioniert. Einige aufwändigere Algorithmen dazu habe ich mir angesehen, leider waren diese in meinem Fall nicht gut umsetzbar. Im Endeffekt versuchte ich mich mittels Trial and Error selbst an einer Lösung. Im Prinzip werden nun für jeden Frame alle auftretenden Kräfte ausgerechnet und schrittweise auf die Objekte angewandt. Jedes Objekt wird dabei nur so weit bewegt, bis eine Kollision auftreten würde, anschließend wird immer die Richtung korrigiert. Wenn am Ende des Updates doch eine Kollision erkannt wird, die sich trotz aller Vorsicht nicht vermeiden ließ, dann werden auf die „Streithähne“ jeweils Penalty Forces angewandt, also Strafvektoren, die die Objekte mit Schwung auseinanderspringen lassen. Das Ergebnis ist fast vergleichbar mit dem, was etablierte 2D-Physik-Engines leisten können.

spacolaeclipse049

OXYD-Rotoren als Spaßgegner

Um mein kleines 2D-Physik-Experiment zu testen musste ich kurzfristig einen Spaßgegner ins Spiel einbauen, der definitiv miteinander reagiert. Im Dongleware-Klassiker OXYD gab es mit dem Rotor einen solchen Gegner. In ein oder zwei Landschaften gab es die Situation, dass zwei Rotoren gemeinsam die Spielerkugel jagten. Die drehenden Rotoren stießen sich dabei jeweils voneinander ab, wenn sie versuchten, denselben Punkt zu erreichen. Im SPACOLA-Remake werden die drehenden Rotoren nun von den Stationen losgeschickt, und sie werden direkt vom Raumschiff des Spielers angezogen. Die Anzahl gleichzeitig existierender Rotoren habe ich dabei stark erhöht, um zu testen, ob die Abstoßung auch im Pulk einwandfrei funktioniert. Das Ergebnis ist wirklich nett anzusehen und wirkt dank passendem OXYD-„Glas“-Soundeffekt auch sehr authentisch.

Stationsanimationen fertig

Alle zehn Stationsanimationen sind nun komplett fertiggestellt, die bisher bestehenden wurden verbessert. Die Timings habe ich Frame für Frame aus dem Original übernommen, dazu habe ich stundenlang Bildchen im Emulator mitgezählt und jeweils die Anzahl notiert. Dafür kann ich jetzt garantieren, dass das Remake sich in dieser Hinsicht absolut nicht mehr vom Original unterscheidet. Tests mit den jeweiligen Soundeffekten zeigen, dass die Animationen wirklich perfekt passen.

Neues Titel-Artwork und Swing-GUI

Ich habe ein neues Titel-Artwork entworfen, da mir die Abstände zwischen den Buchstaben noch nicht gefallen haben. Wenn ich schon dabei war, wollte ich die Grafik des Schriftzugs diesmal perfekt gestalten, so dass ich daran nie mehr etwas ändern müsste. Der Schriftzug wirkt jetzt plastischer, die Abstände sind optimiert, und sogar der Schattenwurf wurde an die Vorgaben im großen Dongleware-Vorbild OXYD angelehnt. Zusätzlich habe ich den Dongleware-Font invertiert und mit einem schwarzen Rand versehen, damit es ebenfalls näher am Original ist. Die Swing-GUI habe ich mit dem Dongleware-Font und mit einem einheitlichen Hintergrund etwas aufgehübscht. Doch das Ziel ist damit noch lange nicht erreicht. Ein einheitliches Optionsmenü fehlt weiterhin.

spacolaeclipse049_2

Magnetismus-Code verbessert

Den Magnetismus-Code habe ich deutlich verbessern können. Die Lösung des Problems war nicht, den Code physikalisch korrekt zu gestalten, wie ich das zuerst versucht habe, sondern – im Gegenteil – eine eher unlogische Herangehensweise. Objekte, die magnetisch angezogen werden, werden nicht mehr ausschließlich in Richtung des „Magneten“ beschleunigt, sondern vollziehen zusätzlich dessen Bewegung iterativ nach. Dadurch wird eine weichere Anziehungsbewegung ermöglicht, und es wird verhindert, dass Objekte wie Satelliten immer um den Mittelpunkt kreisen. Die exakten Werte versuche ich allerdings weiterhin durch Ausprobieren und Korrigieren herauszufinden.

Nachdem ich wochenlang nicht nur praktisch nichts auf meinem vernachlässigten Blog habe verlautbaren lassen, sondern sogar das fünfjährige Bestehen von SuccessDenied total verschlafen habe, darf ich an dieser Stelle nun wenigstens meine grenzenlose Freude über immerhin einige wenige Tage Urlaub bekunden, die ich seit einigen Wochen wirklich dringend nötig hatte. Jetzt kann ich zwei Wochen lang soviel Sport machen wie ich will, mich endlich so richtig um den Haushalt kümmern, mein Spiele-Remake fertigbasteln und all die anderen wichtigen Dinge, die ich mir für den Urlaub ganz fest vorgenommen habe. Ich setze mich nur noch mal ganz kurz auf die Couch und … Ach, mal gucken was grade so im Fernsehen läuft.

Tatsächlich leide ich im Moment ein bisschen unter Ideenlosigkeit was ergiebige Themen für Artikel angeht. Ich habe zwar eine lange Liste von Dingen, über die ich irgendwann mal schreiben müsste, aber im Endeffekt fehlt mir dann doch die Energie, die Stichpunkte in einen lesbaren, ausgewogenen Artikel zu gießen und diesem den nötigen Feinschliff zu verpassen. Der notorisch unmotivierte Webseitenbetreiber wendet also stattdessen einmal mehr das Minimalprinzip an und schreibt einen weiteren einfachen Lückenfüller-Artikel, der aber zumindest inhaltlich zur Webseite passt, um sich mehr Zeit für richtige Themen zu verschaffen.

Es geht um Dongleware-Spiele. Eigentlich ganz und gar nicht aktuell ist die Neuigkeit, dass Enigma in der Version 1.21 veröffentlicht wurde. Und zwar schon letzten Dezember. Ich sollte deren Webseite vielleicht doch öfter als zweimal pro Jahr besuchen. Ganze 51 Landschaften sind im aktuellen Release des aufwändigen OXYD-Remakes dazugekommen, darunter scheinbar auch vereinzelt bei den „Deja-vu“-Levelpaketen für Esprit, OXYD, OXYD2, Oxyd Magnum und Oxyd Extra. Diese sind mir als Fan der Originale sehr wichtig, daher betrübt es mich besonders, dass die Entwickler es bis heute noch nicht hinbekommen haben, die alten Levels vollständig zu portieren. Ich wüsste nur noch gerne, ob es mehr eine Sache des Nicht-Wollens oder des Nicht-Könnens ist, da auch das beste OXYD-Remake leider noch nicht gut genug ist, wenn ich darin nicht alle Original-Levels wiederfinde.

Zwischenzeitlich habe ich ein weiteres eigentlich vielversprechendes Dongleware-Remake gefunden: RemBolo (Remake-Bolo?), das vom Dongleware-Klassiker Bolo inspirierte Breakout-Spiel will das Spielgefühl und die Mechaniken des 95’er PC-Bolos imitieren, aber auch das Ur-Bolo vom Atari ST scheint ihm noch als dankbare Vorlage zu dienen. Der scheinbar deutschsprachige Entwickler arbeitet mindestens seit 2008 an der C++-Implementation unter Verwendung vorgefertigter 2D-Physikbibliotheken. Sogar einen recht gut spielbaren 2D-Prototyp von RemBolo bot er damals bereits zum Download an, den ich bis heute sehr beeindruckend finde. Mir wäre es sogar am liebsten gewesen, wenn man diesen Prototyp als Grundlage für die weitere Entwicklung des Remakes gewählt hätte. Stattdessen entschied der Programmierer sich für einen kompletten Neustart zugunsten von 3D-Grafik. Die ersten Screenshots dieser 2.5D/3D-Version sehen auch schon recht beachtlich aus, besonders der Glaseffekt des Schlägers ist wirklich schön anzusehen.

Illustration von der RemBolo-Webseite

Illustration von der RemBolo-Webseite

Leider steht die Kommunikation bei RemBolo deutlich im Hintergrund, so gab es zwischen den Jahren 2010 und 2015 kein Lebenszeichen des Remake-Projekts. Erst im Februar diesen Jahres wurde die Early-Alpha des neuen Leveleditors auf einem Screenshot gezeigt. Sonstige Fortschritte werden nicht genannt. Da ich weiß wie mühsam es ist, quasi im Alleingang ein komplettes Remake zu bauen (unabhängig davon wie minimalistisch die Grafik sein mag oder auch nicht), erhoffe ich mir einige tolle Neuigkeiten von dem Projekt in den kommenden Jahren. Schon da dieses sich als Schwesterprojekt zu Enigma betrachtet, fände ich die Möglichkeit wirklich reizvoll, dass wir eines Tages (mindestens) zwei nahezu perfekte Dongleware-Remakes hätten.

spaclipse042_2

Bevor hier tatsächlich noch Schimmel ansetzt, belästige ich die werte Leserschaft lieber nochmal mit den aktuellsten Vorgängen in Bezug auf die Webseite und SPACOLA Eclipse. Hierzu habe ich mir eine kleine Liste bereitgelegt, die ich jetzt in einem mehr oder weniger kurzen Artikel abfrühstücken möchte. Am liebsten hätte ich die Gelegenheit genutzt, meine Meinung zur kürzlich angekündigten st-computer-Ausgabe kundzutun, doch wie es scheint, bekommen die Käufer die Februar-Ausgabe frühestens Mitte März, daher wird das wohl noch etwas dauern.

Stattdessen habe ich die Aufmerksamkeit für mein kleines Dongleware-Museum in kreative Energie umgewandelt und einige Einträge hinzugefügt bzw. erweitert. Hinzugekommen ist das wenig bekannte Spiel „The Dragon’s Power“, das von Dongleware 1994 vertrieben wurde, von welchem ich erst vor wenigen Monaten erfuhr. Ebenfalls ist mir entgangen, dass ich doch tatsächlich eines der Schneider’schen TOS-Gimmicks vergessen habe: Das Accessory „Blackhole“, das den Papierkorb in ein schwarzes Loch verwandelt. Es war eigentlich nur eine Beilage zum TOS-Gimmick „Trashy“. Die Beschreibungen der Gimmicks habe ich zusätzlich erweitert und mir auch die Quelltexte der kleinen Programme abgespeichert. Einen Teil der Codes kann ich vielleicht in das Remake-Projekt einbringen.

Besonderen Dank möchte ich an dieser Stelle übrigens einer Leserin des Blogs aussprechen, die mir aus heiterem Himmel ihr OXYD-Buch (guterhalten), und das passende Spiel auf CD per Post geschickt hat. Das war eine äußerst schöne Überraschung. Eine kleine Aufwandsentschädigung habe ich ihr dafür natürlich zukommen lassen. Meine Dongleware-Büchersammlung wurde auch durch einen weiteren SPACOLA Sternenatlas vergrößert, den ich für nicht einmal vier Euro bestellen konnte. Der Einband ist leider ein wenig beschmiert, und auch kleine Eselsohren waren wie erwartet drin, aber ich denke ich kann mich nicht beklagen. Damit habe ich nun also vier SPACOLA-Codebücher in meinem Besitz. Einem weiteren Leser und fleißigen Bolo-Spieler ist es zu verdanken, dass ich bei nächster Gelegenheit eine kleine Levelgalerie für Bolo (1995) und Dia-Bolo einweihen kann. Diese ist zwar nicht ganz vollständig, aber was nicht ist, kann ja noch werden. Der nächste Urlaub ist insoweit schon verplant.

Was gibts über SPACOLA Eclipse zu sagen? Der Fortschritt ist unverändert langsam, aber beständig. Der Zähler steht jetzt bei 20.000 Java-Codezeilen. Jeden Tag bemühe ich mich um ein oder zwei Änderungen, ein paar Fehler zu beheben, ein paar Grafikdateien zu korrigieren, etc. Die Februar-Version steht ganz im Geiste der Originaltreue und Platzersparnis. Ich habe herausgefunden, dass das PNG-Dateiformat sogar 1-Bit-Farbtiefe kennt (echt monochrom!) und habe sämtliche 700+ Grafikdateien einzeln umgewandelt und neu gespeichert. Am Ende hatte ich 64 Kilobyte von 415 gespart. 15% unnötige Daten entfernt, also wenn das nichts ist. Außerdem ist es mir gelungen, mit einem Hexeditor und viel Geduld in mühsamer Kleinstarbeit den SPACOLA-Rentenbescheid aus einem Memory-Dump des ST-Spiels zu extrahieren, und zusätzlich (endlich byte-genau) fast alle SDD-Sounddateien, also exakt so wie sie vor der „Kopierschutz-Kompression“ aussahen. Anschließend habe ich die Soundbibliothek meines Remakes so erweitert, dass sie die Original-8-Bit-PCM-Dateien importieren und verwenden kann. Damit wäre ich wieder einen kleinen Schritt näher am Atari-Vorbild.

spaclipse042_1

Nachdem ich mich also im Februar weitestgehend nur um die Technik unter der Haube gekümmert habe, ist diesen Monat wieder mal das Gameplay dran. Die letzten Tage gelang es mir, alle 14 Minenfeld-Konstellationen aus den Levels des Originals zu analysieren und in meinem Code umzusetzen. Nun steht dem geplanten Parser für die Levelkonfiguration der ST-Version nicht mehr viel im Wege. Das Level-„Skript“ habe ich inzwischen zu etwa 80% entschlüsselt, nur einige wenige Parameter, die etwa das Standardverhalten der Gegner ändern, oder Häufigkeitsmodifikatoren sind mir leider nicht ganz klar. In meinem Analyseprozess ist mir übrigens aufgefallen, dass die Entwickler in ihrer Levelkonfiguration eindeutig einen Fehler gemacht haben: In Level 14 müssten laut Skript sämtliche Sektoren mit Minenfeldern ausgestattet sein, doch da taucht kein einziges auf. Das Problem ist, dass sich dort im Skript jemand vertippt hat, so dass gar keine Minenfelder erzeugt werden. Im Debugger konnte ich bereits nachstellen, dass sich das Level deutlich ändert, wenn man den Tippfehler im Speicher korrigiert. Wenn ich nicht von dem Spiel besessen wäre, wäre das wahrscheinlich nie jemandem aufgefallen.

Jetzt stehe ich vor einer merkwürdigen Entscheidung: Tippfehler im Remake korrigieren und das Level so nachstellen, wie die Entwickler es sich eigentlich gedacht hatten – oder Tippfehler beibehalten, und das Level so nachstellen, wie es das Originalspiel auch wirklich dargestellt hat? Vor einem ähnlichen Problem stand vor einigen Jahren der Entwickler des Dungeon-Keeper-Remakes „KeeperFX“, der bei seiner Reverse-Engineering-Odyssee herausgefunden hat, dass die Bullfrog-Programmierer einen ganz blöden Fehler im Zusammenhang mit dem „Machtwort“-Zauberspruch nie richtig beheben konnten. In der Folge war der Zauberspruch viel schwächer als er eigentlich sein müsste. Nachdem er den Fehler nun also gefunden und im Remake behoben hatte, und der Zauberspruch plötzlich genau die Wirkung zeigte, wie es von Anfang an gedacht war, war das Balancing im Spiel leider total im Arsch. Logisch: Das Spiel war immer nur mit dem „verkrüppelten“ Zauberspruch getestet und feingeschliffen worden. Tatsächlich gibt es im Remake nun die Möglichkeit, den Fehler für die Originalkampagne wieder zu „aktivieren“, um das bekannte Spielbalancing nicht zu verändern. Vielleicht sollte ich das Problem auch via Optionsmenü lösen, und so dem Spieler die Entscheidung überlassen.

Der erste Vormittag des ersten Urlaubstages ist schon fast vorbei, da wollte ich die vielen montagmorgendlichen Stunden, denen ich bereits jetzt nachtrauere, nicht gänzlich unproduktiv stehen lassen. Um mal wieder so richtig gepflegt abzuhängen und gar nichts zu tun, war doch eigentlich schon das vergangene Wochenende da. Es ist jetzt an der Zeit, mal wieder einen Gang hochzuschalten und Dinge abzuarbeiten. Mal davon abgesehen, dass ich nach fast einem Jahr nun einen Kleiderschrank bestellt habe (Adios, Umzugskartons!), sowie ein wenig Hardware für mein zukünftiges neues generalüberholtes Homeoffice, habe ich in den letzten Tagen fast jeden Abend zumindest einige wenige Codezeilen in mein kleines Spieleprojekt investiert. Das am wenigsten Uninteressante dürfte die Tatsache sein, dass ich inzwischen sämtliche Artworks des SPACOLA Sternenatlas „restauriert“ habe.

spacolaguide1

Dazu habe ich alle entsprechenden Buchseiten mit relativ hoher Auflösung eingescannt und die Zeichnungen ausgeschnitten. Darunter waren fünf große Illustrationen von Wolfgang Keller aus Karlsruhe (der zusammen mit seiner Frau Gaby Keller bei den diversen OXYD-Spielen unter den Landschaftsgestaltern bzw. Betatestern gelistet wird), als auch zwölf kleinere Abbildungen, die die einzelnen Powerups darstellen. Zusätzlich habe ich 18 Sprites (Gegner etc.) aus dem Buch eingescannt, die aber allesamt direkt im Spiel vorkommen, und daher nicht von mir grafisch bereinigt werden müssen. Mir ist allerdings aufgefallen, dass im Handbuch die Seitenleiste gezeigt wird, wie sie wohl in einer früheren Version des Spiels ausgesehen haben muss: Die Powerup- und Status-Anzeige fehlt hier völlig, die Extraleben werden dafür in doppelte Breite angezeigt. Mein größtes Interesse galt aber den Zeichnungen.

Das Problem waren hauptsächlich das leicht angegilbte Papier, und die Tatsache, dass die Buchseiten beim Scannen deutlich durchscheinen, so konnte man etwa Text spiegelverkehrt lesen, der eigentlich auf der Rückseite steht. Zum Glück bin ich heute nicht mehr ganz hilflos im Umgang mit GIMP. Schlüssel zum Erfolg war der vorsichtige Einsatz des selektiven Gauß’schen Weichzeichners, der unscharfen Maskierung, und zuletzt die Anwendung von Schwellwerten, um alle Farbtöne zwischen Schwarz und Weiß auszuschalten. Das Ergebnis waren einige einwandfreie Schwarzweißgrafiken. Die Tatsache, dass das Bild nun nicht mehr aus Millionen Graustufen und endlos weichen Übergängen bestand, äußerte sich auch extrem deutlich am Platzbedarf der PNG-Datei: Aus 6,42 MByte wurden so 106 KByte. Das sind kaum 2 Prozent der ursprünglichen Dateigröße. Wohlgemerkt ohne die Auflösung zu verringern oder die Qualität zu reduzieren.

spacolaguide2

Selbstverständlich war genau das aber nun der nächste logische Schritt, denn die Auflösung war mit 2700×1700 Pixeln viel zu hoch. Die Vorlage der Originalbilder war meines Erachtens gerade mal 640 Pixel breit, also die übliche ST-Monochrom-Auflösung. Die bereinigten Scans musste ich daher völlig ohne Interpolation (denn sonst wären wieder weiche Übergänge berechnet worden) auf ein Viertel verkleinern. Pixelidentisch würde es so niemals werden, das war mir klar, aber wenn man die rohen Scans zum Vergleich hernimmt, kommen die pixeligen Kanten schon recht nah. Bei den Zeichnungen ist das ganz gut gelungen, bei den Piktogrammen der Powerups leider nicht so gut.

Und wieso der Aufwand überhaupt? Ganz klar: Die Strichzeichnungen, die ich so hervorbringe, will niemand sehen. Ich würde die Bilder gerne auch ins Remake einbringen, zum Beispiel in einer integrierten Hilfedatei bzw. Online-Anleitung. Das Handbuch selbst habe ich ja schon vor Monaten komplett abgeschrieben, weswegen ich auch den Text in modifizierter Form verwenden könnte. Nicht dass ich für irgendwas davon schon die Erlaubnis hätte, aber man weiß ja nie was kommt. Das Cover des Sternenatlas habe ich ebenfalls schon vor Monaten aufwändig digitalisiert und vollständig restauriert, schon allein weil ich nichts von dem (wenigen) Material ungenutzt lassen möchte. Einzelne Schriftzüge kann man hinterher immer noch problemlos ändern.

Dongleware! Mein kleines aber feines Museum ist inzwischen um zwei weitere Ausstellungsstücke erweitert worden. In regelmäßigen Abständen grase ich Ebay nach diversen Schnäppchen ab, falls jemand zufällig Atari-Bücher bzw. Dongleware-Produkte zum Spottpreis verticken möchte. Da muss ich sofort zur Stelle sein, sowas würde ich nämlich ungern verpassen, sind diese Dinge doch heutzutage recht selten geworden. Manche scheinen das mit dem Seltenheitswert aber doch etwas zu ernst genommen zu haben, so kann ich immer noch Angebote für ein 95 Euro teures SPACOLA-Buch mit welligem Papier und ein – Achtung, jetzt kommt’s – Per.Oxyd-Buch für 498 Euro finden, und das trotz fehlender Seiten. Na hoffentlich bekommt der Verkäufer das Ding zu dem Preis nicht irgendwann los.

oxydmagnum_futuredelic_smallZurück zu meinen neuesten Anschaffungen: Es handelt sich um die Oxyd magnum! Box von 1993 und, was eigentlich noch viel interessanter und deutlich seltener ist: Die Techno-Compilation Futuredelic vom Mai 1994. Moment, Techno? Eine Musik-CD? Was hat das mit Dongleware zu tun? Tja, meine Damen und Herren. Der Dongleware-Verlag war, wie der Name vielleicht vermuten lässt, ein Verlag, und verlegt werden kann vieles wenn es Geld einbringt. Allerdings war Futuredelic meines Wissens der einzige Exkurs von Dongleware im Musikbereich, die wahrscheinlich einzige Audio-CD auf der Welt mit dem OXYD-Logo drauf. Die CD hatte nämlich ebenfalls einen Daten-Track mit spielbaren Demoversionen von Tubular Worlds und OXYD General Edition für Atari ST, IBM-PC und Mac. Aber es hatten wohl nur die wenigsten ein teures CD-ROM-Laufwerk für den Atari ST.

Die Musik-CD wurde von Obsession Records produziert und enthält Trance und Techno von deutschen Künstlern wie Christian Vogel, Affie Yusuf, Purple Plejade, Roland Casper und Christopher Just. Lauter Leute von denen ich keinen einzigen kenne, obwohl ich mich durchaus schon recht lange für elektronische Musik begeistern kann. Tatsächlich kann ich mir so einige Songs von der CD ganz gut anhören, während mir andere wiederum doch zu experimentell sind. Die CD wurde zwar in Deutschland produziert, ich musste sie aber aus Taiwan bestellen, so selten ist die scheinbar schon. Kennt jemand eine gute CD-Rip-Software, die Lesefehler sauber korrigieren kann? Irgendwie habe ich lauter eklige Hüpfer in meinen FLAC-Dateien, weil die CD wohl nicht mehr die jüngste ist.

Die Oxyd magnum! Box ist natürlich auch ein sehr wertvoller Neuzugang für meine Sammlung. Original mit Handbuch, 3,5″-Floppy, und sogar die niedliche schwarze Oxyd-Murmel war dabei. Das ist ein sehr passendes Gimmick für so ein Spiel. Habe mich sehr gefreut als ich etwas im Paket herumrollen gehört habe, denn ich wusste sofort was das ist. Der Verkäufer hat nicht zuviel versprochen, auch wenn der Karton leider relativ sichtbar eingedellt ist, aber das ist in 20 Jahren wohl kaum vermeidbar im Alltagsgebrauch. Beide Artikel wurden wie immer in allen möglichen Posen auf den Scanner gelegt, damit meinem Archiv digitaler Schätze nichts entgeht. Demnächst werde ich also die Seite meines Spielemuseums entsprechend aktualisieren können. Es gibt noch viel zu tun.