Beiträge mit tag "Java

spacolabooks_sidebar

SPACOLA Eclipse WIP 0.34

0

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.

spacolabooks_sidebar

SPACOLA Eclipse WIP 0.33 – Eine explosive Version

0

Neuer Eintrag für das vielfach gelesene Entwicklertagebuch: Hallo Fans, ich habe eine Kleinigkeit in Bezug auf mein Java-Remake SPACOLA Eclipse zu vemerken. Nachdem ich in der letzten Version bedauerlicher- aber nötigerweise nur unbedeutende Dinge vorstellen konnte, wollte ich dieses Mal einige neue Features für das Gameplay implementieren. So in den letzten Tagen geschehen. Ein Screenshot sagt dabei mehr als tausend Worte.

alpha033

Der Screenshot ist mir leider nicht besonders gelungen, ich hätte da gerne ein paar Gegner im Bild gehabt und so. Screenshots zu machen ist nämlich eine echte Kunst, habe ich festgestellt, und oft ist es schwierig, im richtigen Moment den “Auslöser” zu drücken. Nun sei es drum, jenes kleine Bild demonstriert gleich mehrere Aspekte, die kürzlich mehr oder weniger fertig geworden sind:

1. Der Spieler kann jetzt theoretisch jedes beliebige Raumschiff lenken (also auch Piratenschiffe), mittlerweile insgesamt sechs an der Zahl. Nützlich wird so etwas für etwaige Fuchsjagd-Multiplayer-Modi oder sowas, also überall da wo jemand die Rolle der fiesen Gegner übernehmen möchte. Im Screenshot ist es eines der Gegnerschiffe, die erst nach Level 8 oder später auftauchen.

2. Komplette Minenfelder sind endlich im Spiel: Dazu habe ich die beiden Standardminen eingebaut, wovon eine nur unter Beschuss explodiert, die andere einen Annäherungssensor hat, der die Mine bei Spielerkontakt zur Detonation bringt. Wenn man da versehentlich hineinfliegt, geht auf dem Bildschirm wirklich die Post ab.

3. Der Station-Trapper, der eine beliebige Raumstation mit einer ganzen Batterie an Minen eines beliebigen Typs bestückt. Die Klasse kennt alle möglichen Defaults für SPACOLA-typische Formationen (unterschiedlich aufgebaute Minenfelder, wie sie eben im Spiel vorkommen), oder man gibt selbst Werte wie Anzahl Elemente, Abstand und Radius vor. Als kleine Erweiterung kann man Minen nicht nur kreisförmig wie im Original, sondern auch in rechteckiger Formation um eine Station platzieren (im Screenshot rechts oben zu sehen), was im Original so niemals vorgekommen ist. Für einen Leveleditor eine vielleicht ganz nützliche Funktion.

4. Explosionen mit Trümmerteilen (Debris explosions) sind endlich fertig, so wie diese im Original von Minen oder bestimmten Piratenschiffen erzeugt wurden. Explodiert eine Mine, so werden viele sich drehende Trümmerpartikel freigegeben, die dem Spieler sogar schaden können. Einzelne Partikel teilen sich dabei auf und verglühen nach einer Weile. Diesen Mechanismus hinzubekommen, da habe ich eine Weile basteln müssen. Das Zeichnen aller Trümmerexplosionen mit den vielen Partikeln habe ich dabei sogar rekursiv implementiert: Wenn die Monochrom-Grafikengine eine Partikelexplosion zeichnen soll, ruft dieselbe Methode sich selbst nochmals mit jedem einzelnen Trümmerteilchen auf. Toll, dass man sowas mal in der Praxis verwenden kann.

dev snapshot small 200x125Leider fehlt noch mindestens das “Game Over” und die Eingabe der Highscore, daher noch immer keine spielbare Demo. Ich denke als nächstes müsste ich mich auch mal um Turrets, also Abwehrgeschütztürme von Stationen kümmern, aber dazu könnte ich tatsächlich mal ein oder besser zwei Wochen Urlaub gebrauchen. Aber immerhin habe ich das Dongleware-Museum Anfang der Woche mal um einige Einträge erweitert, ein paar Beschreibungen ergänzt, Tippfehler korrigiert und Screenshots ersetzt. Manche Dinge muss ich noch einpflegen, dazu komme ich hoffentlich noch. Für Fans lohnt sich ein Blick.

Für ganz Neugierige hänge ich hier noch einen kleinen Eindruck meiner Entwicklungsumgebung an, also das Ding, das ich mir manchmal stundenlang anschaue und merkwürdigen Text eingebe, damit irgendwann hoffentlich mal ein Spiel rauskommt. Ob der Plan aufgeht, wird sich Ende des Jahres vielleicht mal zeigen.

Java

Kleines Quellcode-Gruselkabinett

0

In meinem Beruf komme ich sehr oft mit den Quelltexten vieler Kollegen in Kontakt, deren Programmierwerke ich lesen, verstehen und erweitern können muss. Man gewöhnt sich daran, dass jeder irgendwo seinen eigenen Stil hat, und dass eben jener manchmal besser und manchmal schlechter lesbar ist. Auch ich habe schon Code geschrieben, auf den ich nicht stolz bin, aber man lernt ja schließlich aus Fehlern. Umso amüsanter ist es, wenn man als erfahrener Entwickler hin und wieder zu lesen bekommt, was sich ein blutiger Anfänger so aus seinen Hirnwindungen drückt.

So geschehen vor einigen Monaten, als ein unerfahrener Praktikant (nennen wir ihn im Folgenden einfach “Praktikant”) eine unbedeutende Erweiterung für ein Softwareprojekt schreiben sollte, für das ich teilweise die Verantwortung trage. Ich gehe zwar nicht näher auf die Details der Implementierung ein, aber ich habe drei kleine kuriose Codeschnipsel gesammelt, die mir in seinem Quellcode so aufgefallen sind. Das ist übrigens derselbe Praktikant, der (um mir einen Screenshot zu zeigen) eine Bilddatei in ein leeres Microsoft Word-Dokument eingefügt hat, damit er das Dokument als PDF-Datei exportieren konnte, um es mir dann per E-Mail zu schicken.

Achtung, der folgende Beitrag könnte für Nicht-Programmierer äußerst uninteressant sein.

Fangen wir mit etwas Leichtem an. Die obige, mehrfach verschachtelte Collection beweist zwar, dass der Praktikant einen sicheren Umgang mit Collections haben muss, aber diese einzeilige Ausgeburt der Hölle beweist leider auch, dass er nicht weiß, dass man im Idealfall gegen Schnittstellen programmiert, und dass er es wohl gern übertreibt. Was auch immer in diesem “Ding” gespeichert wird, es klingt jedenfalls nicht gesund.

Diese Zeile bekommt Sonderpunkte, weil ich darüber erst einen Augenblick nachdenken musste. Mal davon abgesehen, dass der Praktikant sich hier weder an die Namenskonvention für Boolean-Variablen hält, noch verstanden hat, dass eine Boolean-Variable bereits die Antwort auf die Frage ist, bestaunte ich die kreative logische Verknüpfung. Während ich mich ungläubig fragte, ob der Compiler einen “umgedrehten Ungleich-Operator” wirklich durchgehen lässt, fiel mir dann doch auf, dass das eigentlich eine Zuweisung ist, wobei dem zugewiesenen Wert (false) ein NOT vorangestellt wird (also true). Dieser “Vergleich” ergibt immer true, der IF-Block wird immer ausgeführt. Dieses Codekonstrukt ist absoluter Käse. Vielleicht wollte uns der Praktikant aber auch nur ein wenig erheitern.

Das ist der Gewinner in der Kategorie “Kreativster Schundcode”. Drei Dinge sind absolut bemerkenswert: Zunächst testet man immer mit dem Gleichheitsoperator (==) auf null, definitiv nicht mit equals. Außerdem testet man normalerweise deshalb auf null, weil man eine NullPointerException vermeiden möchte, während der Praktikant hier sogar noch selbst eine werfen will. Und überhaupt: Der Test auf null mit equals kann niemals funktionieren, denn wenn someObject tatsächlich null sein sollte, wird mit equals bereits implizit eine NullPointerException geworfen, wo versucht wird, explizit eine zu werfen. Für das Fazit lasse ich den von mir sehr geschätzten, leider kürzlich verstorbenen Harold Ramis als Dr. Egon Spengler zu Wort kommen: “Kurz, aber völlig sinnlos.”

Und dann war da noch dieser eine unwahrscheinliche “interne” Fehler der Eclipse IDE, den ich wohl versehentlich verursacht habe, als ich während eines Debugging-Durchlaufs versuchte das Workbench-Fenster horizontal zu verkleinern. Die Fehlermeldung, die schon beinahe als Realsatire durchgehen könnte, lasse ich im Folgenden einfach mal für sich selbst sprechen:

internalerror eclipse

nach oben