Archiv für den Monat: Juni 2015

Vor zwei Tagen ist Eclipse Mars (Version 4.5) erschienen. Voller Vorfreude habe ich mir das neue Release direkt am Erscheinungstag installiert, sowohl im Büro als auch zuhause. Heute habe ich das blöde Mistding immer noch nicht fehlerfrei am laufen. So lautet mein Fazit nach zwei verschwendeten Tagen, in denen ich weitestgehend irgendwelche Fehlermeldungen googlen durfte: Eclipse Mars ist einfach scheiße. Die Vorgängerversion Eclipse Luna hat mir in einem ganzen Jahr nicht soviel Ärger gemacht.

Wo sind „Check for Updates“ und „Install New Software“ hin?

Nach dem Entpacken und dem ersten Start sieht das „Help“-Menü folgendermaßen aus:

eclipsemarsfirst

Auch wenn ich Eclipse mehrmals schließe und wieder starte, ändert sich nichts. Doch sobald ich irgendein Plugin installiere, und Eclipse mich zum Neustart auffordert, verschwinden im „Help“-Menü alle wichtigen Menüpunkte:

eclipsemarssecond

Und sie tauchen auch nicht mehr auf. Neuinstallieren hilft, dann sind die Menüpunkte wieder da, bis sie irgendwann erneut verschwinden. Bis jetzt konnte ich nichts darüber herausfinden. Eclipse mit Administratorrechten zu starten, macht die Menüpunkte kurzzeitig sichtbar, aber nie wieder als normaler User, außerdem ist das kein befriedigender Workaround für diesen Fehler. Andere scheinen von diesem Problem ebenfalls betroffen zu sein, aber eine funktionierende Lösung oder eine Begründung dafür gibt es nicht.

Eclipse%20Mars

Im Büro hatte ich Eclipse zuerst mehr oder weniger versehentlich in einen Pfad mit Leerzeichen installiert. Sowas würde normalerweise gar nicht auffallen, da Programme seit mindestens 15 Jahren damit umgehen können, doch nicht Eclipse: Ein Ant-Build-Script ließ sich ums Verrecken nicht mehr ausführen, da die Eclipse-Ant-Version, die ohne ersichtlichen Grund von irgendeinem Additional Task im Zusammenhang mit SWT abhängig ist, die entsprechende JAR-Datei im Eclipse-Pfad nicht finden konnte. Die Fehlermeldung dazu sah ungefähr wie folgt aus:

The archive: C:\Program%20Files\Eclipse%20Mars\plugins\org.eclipse.swt.win32.win32.x86_64_3.104.0.v20150528-0211.jar which is referenced by the classpath, does not exist.

Stundenlanges Recherchieren im Netz brachte mich nicht weiter, nicht einmal die unnötige Abhängigkeit ließ sich rausnehmen, da der „Remove“-Button schlauerweise immer ausgegraut ist. Der Fehlermeldung konnte ich schließlich bei genauerem Hinsehen entnehmen, dass Ant das Leerzeichen im Pfad mit „%20“ kodieren wollte, was im lokalen Dateisystem nicht funktioniert. Eclipse-Ant versteht offenbar keine Leerzeichen. Das Umbenennen des Installationsverzeichnisses hat dann geholfen, aber eine Lösung ist das ja nicht. Schade um die vergeudete Zeit. Danke für nichts, Eclipse.

Nachtrag vom 29.06.: Inzwischen habe ich herausgefunden, dass dieser Fehler ein registrierer Bug in Eclipse 4.5 ist. Ich bilde mir also zum Glück noch nichts ein.

Zuhause überraschte mich mein eigenes Ant-Build-Script in Eclipse Mars neuerdings mit dieser Fehlermeldung:

No editor descriptor for id org.eclipse.ant.ui.internal.editor.AntEditor

Wenn ich die External Tools Configuration aufrufen will, hagelt es weitere Fehlermeldungen, z.B.:

Exception occurred creating launch configuration tabs

Reason:
No tab group defined for launch configuration type
org.eclipse.ant.AntLaunchConfigurationType

Und damit lässt sich das Build-Script weder vernünftig bearbeiten noch in irgendeiner Form ausführen oder konfigurieren. Wurde Eclipse-Ant heimlich aus der „Eclipse IDE for Java Developers“ entfernt? Eigentlich scheint Apache Ant 1.9.4 dem Paket wie erwartet beizuliegen, aber in der IDE selbst wurde jede Ant-Referenz entfernt. Google weiß zu dem Thema auch nichts. In Eclipse Luna hat das alles noch einwandfrei funktioniert. Beim erneuten Entpacken des Programms war Ant plötzlich wieder da – fragt sich nur wie lange noch. Egal woran es hängt, die Fehler gehen mir mächtig auf die Nerven, und ich hätte gerne, dass das behoben wird.

Cannot complete the install wegen was auch immer

Eclipse ist hässlich, aber zum Glück gibt es Abhilfe: Das Plugin „Jeeeyul’s Eclipse Themes“ lässt die Entwicklungsumgebung einigermaßen brauchbar aussehen und verbessert die Laune beim Arbeiten erheblich. Seit zwei Jahren bin ich ein echter Fan dieses Plugins, und so wollte ich auch Eclipse Mars damit ein wenig aufhübschen. Offenbar ist die Installation aber total schwierig:

Cannot complete the install because one or more required items could not be found. Software being installed: Jeeeyul’s Themes 2.3.0.I20150604-134826 (net.jeeeyul.eclipse.themes.feature.feature.group 2.3.0.I20150604-134826) Missing requirement: Jeeeyul’s Themes 2.3.0.I20150604-134826 (net.jeeeyul.eclipse.themes.feature.feature.group 2.3.0.I20150604-134826) requires ‚org.eclipse.xtend.lib 0.0.0‘ but it could not be found

Im Anschluss bietet der Eclipse Marketplace mir als mageren Ersatz eine hoffnungslos veraltete Version des Plugins an, die mit Eclipse Mars überhaupt nicht kompatibel ist und das Programm entweder im Betrieb zum Absturz bringt, oder erst gar nicht starten lässt, je nachdem ob die Theme bereits im Workspace hinterlegt war, oder erst nachträglich gewechselt wird. Der Eclipse Marketplace ist nicht nur völlig unfähig darin, eine bestimmte Abhängigkeit für mich aufzutreiben, wenn ich ein Plugin installieren will, er ist auch noch so unfähig, dass er mir eine total falsche Version installiert, die die Eclipse-Installation im Endeffekt unbrauchbar macht.

Wegen solch lästiger Kinderkrankheiten erwäge ich zum ersten Mal nach elf Jahren Eclipse endlich links liegen zu lassen, und es stattdessen doch mal mit einer professionellen Entwicklungsumgebung zu versuchen, die mich nicht mit Fehlermeldungen überhäuft und Menüpunkte versteckt.

Nachtrag vom 29.06.: Weiter gehts. Noch nicht einmal ein Update klappt richtig, wenn denn der Menüpunkt ausnahmsweise mal auftaucht:

Unable to read repository at http://download.eclipse.org/releases/mars.
No repository found at http://download.eclipse.org/technology/epp/packages/mars/.

spacolaeclipse045

Wo ich gerade schon bei Spielen mit der Grafik noch aus der Zeit der Weimarer Republik bin, spreche ich am besten direkt das nächste passende Thema an: Spiele mit Grafik aus der Steinzeit. Es folgt ein diesmal etwas längerer Artikel über den aktuellen Entwicklungsfortschritt meines Hobby-Dongleware-Remake-Projekts SPACOLA Eclipse. Es gibt viel zu berichten, weil ich in letzter Zeit viel daran gearbeitet habe. Die neueste Work-in-progress-Version vom Juni 2015 führt einige neue Gameplay-Features ein, allerdings auch viele tolle Neuerungen unter der Haube, die das Arbeiten an dem Projekt endlich deutlich interessanter machen, was wohl auch der Grund für meinen unerwarteten Eifer ist.

Mehrspieler-Modus

Ich habe in letzter Zeit die Serialisierbarkeit der meisten Spielobjekte überarbeitet und damit angefangen, den Mehrspieler-Modus zumindest grundsätzlich mit Leben zu füllen. Nachdem man bislang den Server lediglich vorbereiten, und sich als Client nur theoretisch registrieren lassen konnte, startet nun in der neuen Version tatsächlich ein Spiel, sobald die Mindestanzahl der Teilnehmer erreicht ist. Als nächsten Schritt sorgte ich dafür, dass die Spieler-Objekte untereinander ausgetauscht und dargestellt werden können. Die Mitspieler werden sich jetzt zwar auf dem Bildschirm gegenseitig sehen, aber davon abgesehen wird noch nichts synchronisiert, jeder spielt ein völlig eigenständiges Spiel. Mein Ziel war damit bereits erreicht, denn es ging mir vorerst um das Programmgebilde außenrum. Als nächstes wäre eine Lobby nötig, damit man einen Spielmodus und das Level auswählen, sich absprechen, und die Teilnehmerzahl festlegen kann.

Aktives Rendern, höhere Auflösungen, Vollbildmodus

Es war eine kleine und interessante Herausforderung, als ich damals mein eigenes Double-Buffering schrieb für das Zeichnen von 50 Bildern pro Sekunde ins Fenster, aber wenn ich ehrlich bin, war das eine rein autodidaktische Mission und überhaupt nicht nötig. Double-Buffering gehört zur Standardausstattung von Swing. Für meine Verhältnisse war meine Methode lange Zeit absolut ausreichend, aber für höhere Auflösungen leider unbrauchbar langsam. Inzwischen habe ich die 2D-Grafikengine von SPACOLA Eclipse auf aktives Rendern umgestellt, das den ausbremsenden Swing-Overhead umgeht und das Zeichnen des Fensters selbst steuert. Der Unterschied in der Performance ist beeindruckend. Als Bonus habe ich Echtzeit-Skalierung eingebaut, die das Bild stufenlos vergrößert, sogar mit Interpolation. Inzwischen läuft SPACOLA Eclipse in 1280×800 Pixeln, und das absolut ruckelfrei und noch dazu viel responsiver was die Mauseingaben angeht. Ach stimmt, einen exklusiven Vollbildmodus gibt es jetzt auch, den man wahlweise ganz normal mit ALT+Enter oder F8 umschaltet. Die Menüleiste ist mit dem Vollbildmodus noch nicht so ganz einverstanden, aber daran arbeite ich noch.

Farbsprites

Die ersten Vorbereitungen für den Farbmodus sind endlich getroffen. Meinen ganzen alten Monochrom-only-Code habe ich durch pseudomonochrome Grafikobjekte ersetzt, die zur Farbdarstellung in der Lage sind. Ein erster Test mit ins Spiel eingebauten Farbsprites verlief erfolgreich, der Rest ist also nur noch eine Sache von wochenlanger Kolorierung in Fleißarbeit und Search & Replace. Angefangen habe ich damit bereits teilweise. Außerdem gelang es mir, die ersten Farbsprites, die von Meinolf Amekudzi im Jahr 1993 für eine nie in Entwicklung gegangene SPACOLA-Farbversion angefertigt wurden, endlich richtig auszulesen. Die Grafiken sehen wirklich sehr spannend aus. Es müsste mir also möglich sein, diese Designs bald zu komplettieren, und einen Farbmodus ins Remake einzubauen.

Neue Gegner-KI

Die alte provisorische Gegner-KI ist bald Geschichte. Bislang war das Flugverhalten der Dummy-Gegner doch sehr merkwürdig, da sie im Weltraum Haken schlagen konnten und auch nur endlos dem Spieler folgten. Längst gelang es mir, das Flugverhalten deutlich realistischer zu machen. So müssen die Gegner jetzt genau wie der Spieler genügend Gegenschub liefern, damit sie ihre Richtung anpassen können. Endlich driften die kleinen Piratenschiffe halbwegs glaubwürdig über das Pixelbild, verfehlen auch mal das Ziel, und müssen dann ständig wieder den Kurs korrigieren. Darüber hinaus machen die Piraten zum ersten Mal das, was sie eigentlich sollten: Sie knöpfen dem Spieler seine Waren ab oder suchen freischwebende Waren, und fliegen damit zur feindlichen Station, um sie unter Gelächter dort abzugeben. Das klappt wirklich erstaunlich gut, ist nur leider noch nicht so ganz am Original dran. Und wenn die Gegner mal gut gelaunt sind, dann fliegen sie schiffbrüchigen Kameraden hinterher und retten diese.

Rettungskapseln, neue Powerups

Es gibt im Original Gegnerschiffe, die bei ihrem Abschuss mehrere Rettungskapseln freigeben. Diese öffnen sich dann wiederum in ausreichendem Abstand zum Spieler von selbst und geben die üblichen hilferufenden kleinen Männchen frei. Die Rettungskapseln sind jetzt auch im Remake enthalten. Bei den Powerups sind immerhin eineinhalb dazu gekommen: Der Molekularduplikator, der soweit ich es erkennen kann in genau einem von 64 Levels vorkommt, funktioniert jetzt perfekt. Beim Raketen-Powerup habe ich immerhin das Einladen mal fertiggestellt. Das Abfeuern derselben fehlt noch.

Der Quellcode umfasst jetzt mehr als 24.000 Zeilen und wurde von mir in den vergangenen Wochen ausgiebig gepflegt und verbessert. Einige verschluckte Exceptions beim Soundplayer habe ich so aufgespürt, was sich vermutlich auch auf die Performance ausgewirkt hat. Das Logging habe ich deutlich erweitert und auch hier einige Fehler behoben, die mir vorher nie aufgefallen waren. Insgesamt ist das Projekt spürbar aufgeräumter und ausgereifter geworden, so dass die faulen Phasen hoffentlich der Vergangenheit angehören dürften. Inzwischen ergibt selbst ein richtiges Optionsmenü Sinn, in dem man Grafikmodus und Audiotreiber und diverse andere Technikaspekte einstellen könnte. Das nächste große Thema ist ein funktionierender Kampagnenmodus mit wechselnden Levelkonfigurationen. Das Ding habe ich jetzt lange genug vor mir hergeschoben.

Die britischen Entwickler von Stainless Games haben dieser Tage ihr neuestes Brutalo-Crash-Derby-Spiel Carmageddon Reincarnation offiziell veröffentlicht, nachdem es lange Zeit nur ein Early-Access-Titel war. Als langjähriger Fan der Carmageddon-Spielereihe wollte ich mir die Gelegenheit, ein aufpoliertes Remake heute noch einmal spielen zu können, nicht entgehen lassen. Als die erste Demoversion des Ur-Carmageddon 1997 auf einer Beilage-CD der Spielezeitschrift „PC Action“ enthalten war, wusste ich zuerst noch gar nicht, was ich da eigentlich vor mir hatte – bis mich der Reiz der Spielidee endgültig packte. Mit Destruction Derby oder Twisted Metal gab es bisweilen vereinzelte Konkurrenz, aber an Carmageddon kam für mich kein anderes Spiel heran.

Eine meiner ersten Missionen seinerzeit auf meinem brandneuen PC war es, das eklige Demo-Zeitlimit aus der Demoversion mit einem Hexeditor und der grenzenlosen Geduld eines spielesüchtigen Teenagers herauszupatchen, damit ich die stark eingeschränkte Version halbwegs ungestört spielen konnte. Dies gelang mir leider nur teilweise. Witziger war es, die dutzenden Konfigurationsdateien des Spiels zu manipulieren, und so manche Fahrzeuge entweder federleicht oder schwer wie ein Flugzeugträger zu machen. Die Spielphysik honorierte solche Versuche mit teils aberwitzigen Schadensmodellen bei den Karambolagen. Und schließlich schrieb ich sogar einen kleinen Patch, der die blöden Roboter aus der deutschen Zensurversion durch die menschlichen Fußgänger aus dem Original austauschen konnte. Der Patch fand im Freundeskreis relativ großen Anklang, und ich konnte ihn auch noch gebrauchen, nachdem ich mir endlich die Vollversion des Spiels bestellen konnte.

Nachdem das kleine Kickstarter-Projekt Carmageddon Reincarnation jetzt offiziell fertig ist, versuchen sich manche Online-Spielemedienportale irgendwie an einer Bewertung des Spiels, und es scheint als wollten sie sich alle gegenseitig in Schmäh-Superlativen überbieten. In einem Testvideo der PC Games ist gar von „der Grafik von 1928“ die Rede. Andernorts wird ernsthaft erklärt, dass die Grafik sich ja kaum weiterentwickelt habe. Ich bin sicher, diese Leute haben das Original nie gespielt, oder haben wenigstens völlig verdrängt, wie dieses eigentlich aussah: Dank dichtem Nebeleffekt war die Sichtweite auf vielleicht zehn Meter beschränkt, die Fahrzeuge teilweise kaum texturiert, die Levelarchitektur grobschlächtig und schmucklos, die hohe Auflösung auf 640×480 Pixel beschränkt, die selbst auf einem Pentium 200 damals nicht flüssig spielbar war.

Dass sich die Grafik seither nicht weiterentwickelt hat, ist dummes Zeug bzw. eine dreiste und billige Lüge, und das lässt mich doch sehr am Urteilsvermögen und an der Objektivität der Redakteure zweifeln. Ich darf wohl eher davon ausgehen, dass diese Personen ihre generelle Ablehnung des gewaltbetonten Spiels unbedingt auf sämtliche Aspekte der Wertung projizieren wollten. Daher wird in einer Tour auch über die schlechte KI, das schlechte Gameplay, die schlechte Musik, die schlechten Gewaltdarstellungen und die schlechten Spielmodi hergezogen, damit am Ende nicht etwa doch noch der Verdacht aufkommt, das Spiel sei wenigstens noch etwas für Fans.

carmageddon_reincarnation3

Keinen dieser extremen Kritikpunkte kann ich so nachvollziehen. Carmageddon Reincarnation macht trotz seiner Fehler irre viel Spaß. Inzwischen habe ich so einige wirklich witzige und auch einige teils frustrierende Spielstunden mit dem Remake verbracht. Die KI ist manchmal etwas dusselig, aber dafür bin ich eigentlich sogar dankbar, denn niemand mag perfekte Computergegner. Meistens ist die KI knallhart. Carmageddon Reincarnation war ein vergleichsweise kleines Kickstarter-Projekt mit kleinen, aber realistischen Zielen, um Fans der Spielereihe das Spielerlebnis des Original-Carmageddon auf moderner Hardware nach all den Jahren nochmals zu ermöglichen – große Veränderungen am Gameplay waren weder erwünscht noch geplant, und das erkennt man mitunter daran, dass sie viele Fahrzeuge und Strecken des Originals in aufwändig überarbeiteter Form übernommen haben.

Das Entwicklerteam war relativ überschaubar und das Ergebnis meines Erachtens dafür umso beeindruckender. Wenn man die Vorlage zum Vergleich heranzieht, so wie das eigentlich gedacht ist, erkennt man, dass das Remake in jeder Hinsicht gelungen ist, sogar und vor allem aus grafischer Sicht. Wenn die Grafik in Carmageddon Reincarnation also von 1928 ist, ist die in Minecraft dann vielleicht von 1528? Und selbst wenn, wieso muss man heute überhaupt noch Spiele für „schlechte“ Grafik abwerten?

Vor wenigen Jahren sind Indiespiele zum Massenphänomen geworden, und waren nicht länger eine unsichtbare Randerscheinung, die eines Testberichts nie würdig gewesen wäre. Doch wie bewertet man solche Spiele, die bewusst auf Einfachheit setzen, angesichts einer immer höher gelegenen Messlatte. Wollen wir einem Millionen-Dollar-Grafikblender wie Crysis 3 grundsätzlich Höchstwertungen geben, allein weil die CryEngine drinsteckt, um dann in Konsequenz jedes 1-Mann-Indie-Spiel mit Retropixel-Optik abzustrafen, weil es technisch einfach in keiner Weise mithalten kann? Wollen wir angesichts Erfolgsgeschichten wie der von Minecraft Spiele weiterhin großteilig anhand ihrer teuren Grafikpracht beurteilen, oder sollte man die optische Präsentation dem eigentlichen Spielspaß nicht vielleicht doch deutlich unterordnen, oder die Spielegrafik nicht wenigstens bezüglich völlig anderer Gesichtspunkte messen? Sollten wir nicht allmählich zu der Einsicht gelangen, Spiele, genau wie Filme, an ihrer jeweiligen Zielgruppe, im Kontext ihrer Zeit und ihrer technischen und personellen Möglichkeiten zu bewerten, da man sonst etwa Kinderfilme grundsätzlich schlecht bewerten müsste, weil ihre Handlung so primitiv und naiv ist, oder Schwarzweißfilme wegen ihrer miesen Bildqualität und ihrer Farbarmut, oder Stummfilme wegen ihrer mangelhaften Dialoge.

Und was ist mit der übertriebenen Gewalt in Carmageddon Reincarnation? Oh bitte. Wer sich im Jahr 2015 noch darüber echauffiert, dass in einem Computerspiel Autos zu Schrott gefahren und Menschen mit Vollgas überfahren werden, der soll sich bitte wieder in seine Höhle verkriechen. Darüber sind wir längst hinaus und das soll bitte auch so bleiben. Noch ist niemand bei virtuellen Verkehrsunfällen oder an Pixelblutverlust gestorben. Wer trotzdem Probleme hat „sein Frühstück unten zu behalten“, wie der werte Herr im PC-Games-Video sagt, der darf gerne weiter seine preisgekrönten und gewaltfreien Spiele wie GTA 5 spielen. Oh wait.