Beiträge mit tag "Java

Spacola_Disks1

SPACOLA Eclipse WIP 0.42

0

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.

Spacola_Disks1

SPACOLA Eclipse WIP 0.39 – Preview Video

0

Endlich fertig mit dem Video. Mensch, war das ein Act. Ich bin froh, dass es dieses Jahr wirklich noch geklappt hat, wo ich das Ding doch schon seit Monaten ankündige. Hier also das neueste Preview-Video zur aktuellen Version 0.39 meines Spiele-Remakes SPACOLA Eclipse, das einige neue Spielelemente seit dem letzten Video demonstrieren darf. Da ich unbedingt auch die Mehrsprachigkeit zeigen wollte, ist wieder ein Teil des (relativ langen) Intros dabei – genervte Zuschauer können da natürlich ohne schlechtes Gewissen vorspulen bis zum spannenderen Teil. Das ziemlich genau zehnminütige Video ist mit kleinen Einblendungen versehen, die auf neue Aspekte hinweisen.

YouTube Preview Image

Ich hoffe die kleine Ballerei sieht inzwischen schon deutlich mehr nach Spiel aus, obwohl es sich natürlich weiterhin eher im Rahmen einer “Techdemo” bewegt. Hier der Text zum YouTube-Video:

Enjoy the SPACOLA Eclipse WIP v0.39 Preview, which shows the current development state as of December 2014.

SPACOLA Eclipse is my own small remake of the classic Atari ST Dongleware game Spacola – a top down 360° 2D space shoot’em up. Spacola was released in 1991 and was developed to be played in the ST monochrome high resolution (640×400). The remake is written entirely in Java (17.700 LoC atm) and doesn’t even use any major game frameworks/libraries.

This project aims primarily for a 100% remake accuracy (with a few enhancements here and there – which you can choose to enable), and beyond that, there are plans for a completely colorized version and HD resolutions.

Please keep in mind, although I’m working (well, now and then) on this game for over 4 years, it is still considered “early alpha”. Lots of stuff is totally unfinished, many things aren’t even in the remake yet. E.g. all enemy AI is a dummy – in no way do they resemble original enemy behaviour. The game probably won’t be finished in the upcoming year, but I really keep working on it.

Thanks for watching.

spacolabooks_sidebar

SPACOLA Eclipse WIP 0.34

2

Eine reichlich produktive Woche liegt hinter mir. Ein paar müßige Woche mussten nämlich ausgeglichen werden, jedenfalls im Bereich der Spieleentwicklung. Aber seit Montag konnte sich meine Entwicklungsumgebung nicht über zuwenig Aufmerksamkeit beklagen. Es gibt daher schon wieder einen kleinen Update-Bericht zu SPACOLA Eclipse.

spaclipse034

Als erstes möchte ich bekanntgeben, dass ich eine gedankliche Schwelle überschritten habe: Ich bin mir jetzt hundertprozentig sicher, dass ich das kleine Retro-Spieleprojekt eines Tages wirklich zum Abschluss bringen muss. Nachdem ich bisher stets darauf hingewiesen habe, dass ich keine Garantie dafür geben werde, dass ich meine kaum spielbare Monochrom-Demo nicht eines Tages doch noch aus plötzlichem Desinteresse wieder einstampfe, bin ich nun sicher, dass mir das nicht mehr passieren kann. Zuviel Mühe, Zeit und Erfahrung stecken inzwischen in dem bald 13000 Zeilen langen Quellcode.

Außerdem ist das zwar noch weitestgehend unfertige Spiel längst mit einem tatsächlich recht drolligen Gameplay gesegnet. Auf dem Bildschirm wuseln und explodieren schon eine ganze Menge Raumschiffe hektisch umher, ballern aus allen Rohren, Geschütztürme verfolgen aufgeschreckt jede Bewegung des Spielers. Selbst die winkenden Männchen in den Raumstationen trinken schon gierig ihre Cola, wenn man sie mit der wertvollen Ware beliefert. Mit maximalem Schub versucht man der Anziehungskraft schwarzer Löcher zu entkommen, oftmals vergeblich. Ja tatsächlich, Geschütztürme und schwarze Löcher sind in dieser Woche fertig geworden.

Ich habe endlich meine neue Vortex-Klasse für Strudel- bzw. Wirbeleffekte (z.B. Intro-Animation und Gameover-Animation) in Betrieb genommen. Für den Wirbeleffekt (logarithmische Spirale) und für die Gravitationsberechnung schwarzer Löcher musste ich mir wieder mal eine ganze Menge Mathematik anschauen. Selten habe ich soviel über irgendwelchen Formeln gebrütet wie die letzten Tage, aber es hat sich ausgezahlt. Der Effekt ist wirklich spannend und funktioniert sehr gut. Den neuen Code für die Gravitation konnte ich auch gleich für zwei Sammler-Powerups und für die Container einbauen, so dass das Thema auch abgehakt wäre. Von seiner eigenen Code-Kreation brutal über den Haufen geschossen oder ins Nirvana gezogen zu werden, das macht einen auch irgendwie stolz.

Aber ich will niemandem etwas vormachen: Die Todo-Liste wird eher länger statt kürzer. Für jedes Feature, das ich mühsam umsetze, fallen mir zwei neue ein. Und das schließt Ideen für Erweiterungen und Bugs nichtmal ein. Alle paar Monate meldet sich mal ein SPACOLA-Fan bei mir, was mich immer ganz besonders freut. Manchmal ist das sogar die nötige Motivation, die ich brauche, um mich nach faulen Phasen mal wieder ins Gefecht zu stürzen. Und ich bin noch optimistisch, dass das Projekt Ende des Jahres wirklich vorzeigbar wird! Bis dahin wird es noch ein weiteres Gameplay-Video geben, das alle neuen Funktionen demonstriert und dass man nun sogar das Spiel verlieren und seinen Highscore-Eintrag hinterlassen kann. Wenn die vielen Spielmechaniken mal irgendwann alle fertig implementiert sind, dann kann ich mich endlich um das wirkliche Spieldesign kümmern, also um die Levels, das Feintuning, ein korrektes Gegnerverhalten, uvm.

Degree

Oracle Certified Associate, Java SE 7 Programmer

8

ocajpKönnen Klassen in Java “protected” oder sogar “private” sein? Welchen Case springt ein Switch mit einem null-String an? Ist ein statischer Konstruktor ein Konstruktor mit “static”-Modifier? Werden Methoden oder Variablen dynamisch oder statisch gebunden? Können Interfaces von mehreren anderen Interfaces erben? Kompiliert eine Klasse mit der Methode “private static void main” und ist diese startfähig? Wer solche Details nicht weiß, braucht sich über das Thema Zertifizierung noch keine Gedanken machen. Ich mache mir bereits seit Monaten Gedanken.

Seit Anfang der Woche bin ich offiziell ein von Oracle zertifizierter Java-Programmierer – endlich! Die hierzu nötige Prüfung habe ich mit 85% bestanden. Zum Bestehen brauchte man 63% der richtigen Antworten, dieser Wert variiert je nach Schwierigkeitsgrad des Aufgabenkatalogs. In meinem Fall handelte es sich um ziemlich schwere Aufgaben. Zum Vergleich: Nur wenige Jahre zuvor waren zum Bestehen stolze 77% nötig, die Aufgaben also wesentlich einfacher. Zweieinhalb Stunden hat man Zeit, sich beinahe 90 hirnverknotende Codebeispiele durchzulesen, im Kopf zu interpretieren und dann via Multiple-Choice die richtige Antwort anzuklicken – weniger als zwei Minuten pro Aufgabe. Ansatzpunkte gibt es natürlich keine. Ein paar kümmerliche Alibi-Wissensfragen zwischen den endlosen Zeilen voller Quellcode sollen wohl beruhigend wirken. Am Ende hat mir die Zeit gerade so gereicht.

Die fast 200 Euro teure Zertifizierung (Schulungsmaßnahmen nicht eingerechnet) zum sogenannten “Oracle Certified Associate, Java SE 7 Programmer” (kurz OCAJP) ist die erste, die man als Java-Programmierer absolvieren kann, sie ist mittlerweile Voraussetzung für sämtliche weiteren. Jetzt habe ich die Möglichkeit, mich irgendwann sogar als professioneller Java-Programmierer (OCPJP) zertifizieren zu lassen, was ich definitiv plane, aber bis dahin wartet noch sehr viel mehr an Vorbereitung und Training auf mich. Das gedruckte Zertifikat sollte in den nächsten sieben Wochen bei mir eintreffen, bis dahin kann ich mich an der PDF-Version ergötzen.

Wer sich mit dem Thema noch nie befasst hat, aber neugierig auf die Prüfung ist, sollte gewarnt sein. Die Fragen sind wirklich knallhart. Es wird nie nach den allgemeinen Dingen gefragt, die jeder Java-Programmierer beantworten kann. Es werden gezielt die Schwachstellen abgeklopft, all jene Aspekte und Grenzfälle abgeprüft, die viele eben nicht kennen. Die Prüfung spekuliert darauf, dass viele etwa den einfachen Unterschied zwischen String s = “Hallo”; und String s = new String(“Hallo”); nicht kennen, und fragt dann gerne ganz genau nach, wieviele Objekte der Garbage Collector der JVM aufräumen darf.

Ich bin voller Stolz, diese Hürde erfolgreich genommen zu haben. Der OCAJP war der nächste große Schritt, mich im Bereich Softwareentwicklung bzw. Java-Programmierung zu beweisen und zu etablieren. So ein Zertifikat kann eines Tages den Unterschied zwischen Arbeitslosengeld und Gehalt ausmachen. Oder zwischen Gehalt und Gehalt++. Das muss sich alles noch herausstellen. Bis dahin werde ich weiterhin Erfahrung sammeln und Bücher wälzen.

Java

Kleines Quellcode-Gruselkabinett II

14

Weil es so lustig war und ich neues Material gesammelt habe, denke ich, dass es an der Zeit ist, das Quellcode-Gruselkabinett mit einem zweiten Artikel fortzusetzen, womöglich zu beenden. Der (nicht näher definierte) Praktikant aus dem ersten Teil hat wieder zugeschlagen und hocheffizienten und extrem sinnvollen Java-Code produziert. Diese Glanzleistung moderner Softwareentwicklerkunst wollte ich denjenigen meiner Leser, die über Programmierkenntnisse (und Englischkenntnisse) verfügen, auf keinen Fall vorenthalten. Wer von Programmieren überhaupt nichts versteht, der wird an diesem Artikel wie gewohnt leider nichts finden können.

Der Praktikant ist offenbar ein großer Fan davon, toString() auf String-Objekten aufzurufen, vielleicht erhofft er sich dadurch noch stärkere Typsicherheit mit Netz und doppeltem Boden oder sowas. Jedenfalls Code wie der obige begegnet mir leider immer häufiger. Solchen Murks mache ich bei Sichtung auch sofort wieder raus.

Ebenfalls ein ständiger Begleiter in seinem Code: Die Angst, dass eine neu (=leer) angelegte Collection vielleicht doch nicht so leer ist, wie sie vorgibt zu sein. Anders kann ich mir nicht erklären, wieso der Praktikant gleich nach dem Erstellen einer leeren Collection diese leert. Womöglich hat er sich hierbei etwas gedacht, ist aber völlig unnützer Code. Ein damit sehr verwandtes Problem ist das folgende:

Aus der API-Dokumentation der oberen Methode: “The Calendar returned is based on the current time in the default time zone with the default locale.“. Der Knackpunkt ist, dass das zurückgegebene Kalender-Objekt immer bereits mit der gegenwärtigen Uhrzeit initialisiert ist. Hier (zur Sicherheit oder aus Unkenntnis) nochmals Uhrzeit und Datum zu setzen und dafür extra ein neues Date-Objekt zu erstellen, ist kompletter Unfug. Überhaupt: Wieso geht er davon aus, dass der parameterlose Konstruktor von Date() die aktuelle Uhrzeit liefert, aber bei Calendar soll selbiges System nicht funktionieren? Nett auch die Wahl des Variablennamens “actCal” für den Kalender. Er dachte wohl, “actual calendar” sei eine brauchbare Übersetzung für das, was er ausdrückten wollte. Ich lese da aber irgendwie immer nur “Aktkalender”.

Auch so ein Codekonstrukt, worüber man diskutieren sollte: die Getter-Methode für private Konstanten. Wieso nicht gleich die Konstante als public deklarieren, dann kann man sich das Rumgeeiere sparen. Bei Konstanten durchaus sinnvoll. Aber als verwandtes Problem sei angemerkt, dass der Praktikant zum Beispiel ganz gerne auch mal simple Getter-Methoden innerhalb derselben Klasse aufruft, in der sie definiert werden – anstelle der sichtbaren Variable. Kapselung schön und gut, aber damit ist doch eigentlich Kapselung von der Außenwelt gemeint. Das scheint jemand nicht so richtig verstanden zu haben.

Namenskonventionen für Methoden sind auch so ein Problem für den Praktikanten. Der Name der Methode sagt leider nichts darüber aus, was der Rückgabetyp sein könnte. Im Fall von “componentParser” ist noch nicht einmal eine Tätigkeit erkennbar. Da meldet die als Frage formulierte Methode “isActive” eine komplexe Hashmap zurück, und die etwas umständlich benannte Methode “getTheParsedSysInfoComp” liefert nicht etwa “die kompletten Systeminformationen” zurück, sondern einen Wahrheitswert – was auch immer dieser aussagen soll. Immer wieder lustig mitanzusehen sind Methodennamen, die erkennen lassen, dass sich dabei wohl jemand beim Ausdenken einen abbrechen musste, etwa “isLoadTimeFromOneSystemOverTime”.

Englisch scheint ohnehin nicht so seine ultimative Stärke zu sein, vor allem wenn die (netterweise konsequent, wenn auch unnötigerweise) im Englischen gehaltenen Kommentarzeilen nur so vor Denglisch triefen. Da wird aus “Pfade herausfiltern” schonmal “filter the path outside”, oder das weibliche Possessivpronomen “her” wird auf Systeme und _ihre_ Eigenschaften angewandt. Wenn man kein Englisch kann, sollte man vielleicht nicht unbedingt versuchen, alles immer englisch schreiben zu wollen, oder zumindest mal ein paar Vokabeln nachschlagen, bevor man in die Tasten haut.

nach oben