Vince

Vince

(267 Kommentare, 328 Beiträge)

Ein Mann kann etwas verändern.

Homepage: http://www.successdenied.com

Beiträge von Vince
Hardware

Die Festplatte – Unendliche Weiten

6

Noch vor wenigen Jahren habe ich jedem gegenüber meine tiefste Verachtung zum Ausdruck gebracht, der mich zum Thema Festplattengrößen fragte, “wer denn soviel Platz bräuchte”. Jeder, der durch solche und ähnliche Pauschaläußerungen seine gnadenlose Beschränktheit offenbarte, ist mir meine teure Zeit und Hirnkapazität eigentlich nicht wert, erst recht keine selbsternannten IT-“Experten”, die sich dann dummerweise durch solche Sprüche entlarven. Inzwischen würde ich die Thematik vielleicht sogar schon etwas lockerer sehen, denn man ist heute in der wahnsinnig komfortablen Situation, dass man nicht nur exorbitant große Festplatten für wirklich wenig Geld bekommt, sondern auch, dass die bislang – gemessen am Preis pro Gigabyte – unbezahlbaren SSD-Festplatten längst in angenehmere Preisregionen gefallen sind.

Im Grunde genommen bin ich nun zum ersten Mal seit Beginn meiner Nutzung diverser Computer in den späten 80er Jahren nicht mehr ständig auf der Suche nach mehr Speicherplatz. Tatsächlich fällt es jetzt sogar mir als Datenhamster und -messie wirklich schwer, den verfügbaren Speicherplatz zu füllen. Wo ich früher im Prinzip täglich jede Menge Datenkrempel auf große Stapel voller CD-Rohlinge auslagern musste, da die Festplatten immer bis zum Anschlag voll waren, habe ich heute soviel Platz, dass ich mir überhaupt keine Sorgen machen muss. Ich habe sogar derart viel Platz, dass ich mir terabyteweise Redundanz leisten kann – vor 15 Jahren mit dem knappen Taschengeld eines Teenagers undenkbar, und auch vor zehn Jahren mit BAföG kaum machbar. Schlimmer noch, musste ich schon damals im Jahresabstand neue Festplatten hinzukaufen, um nicht Gefahr zu laufen, kostbare Daten löschen zu müssen: 1997 noch mit mickrigen 2,1 Gigabyte, 2005 dann mit gefühlten endlosen 500 GB. Beide waren in ungefähr der gleichen Zeit gefüllt. Das Speicherplatz-Wettrüsten war erstmals mit dem Kauf einer 6 TB-Festplatte Ende 2014 beendet, seitdem kann ich mich entspannt zurücklehnen.

Jahrelang tat sich nichts im Bereich Festplattenkapazitäten. Längst hatte ich Angst, dass bei den 4 TB-Modellen eine unüberwindbare physikalische Grenze erreicht war, quasi das Ende der Fahnenstange. Gleichzeitig änderte sich aber eine ganze Menge bei den immer populärer werdenden SSDs, und daher wollten diesen Umstand die Techniklaien dieser Welt als das (warum auch immer) herbeigesehnte Ende der herkömmlichen Festplatten verstehen. Schaut man sich heute mal bei den üblichen Hardware-Versandhändlern um, so findet man endlich 8 TB-Festplatten für nur noch 250 Euro. Die Technik für 10 TB und sogar 20 TB liegt bereits in den Schubladen der Festplattenhersteller. Solche Festplatten werden bewusst teilweise mit dem Namenszusatz “ARCHIVE” versehen, da solche Massenspeicher sich in Sachen Zugriffszeiten, sowie Datenübertragungsraten mit den SSDs sowieso nicht messen können. Aber sie haben den gigantischen Vorteil ihrer Kapazität, und den kann noch keine SSD ersetzen. Vielleicht noch eine ganze Weile nicht. Die größten Consumer-SSDs mit 2 TB sind zwar schon im Handel erhältlich, jedoch für knapp 1000 Euro in keinster Weise vergleichbar, meiner Ansicht nach auch dann nicht, wenn man versucht, mit der höheren Geschwindigkeit zu argumentieren.

Aber eines beweist mir die aktuelle Situation dann doch: Noch vor wenigen Monaten las ich in einem Technikforum die Behauptung, dass es technisch nicht möglich sein dürfte, in den kommenden Jahren SSDs mit Kapazitäten jenseits der Terabytegrenze zu bauen, da hierfür extreme Strukturverkleinerungen nötig wären. Inzwischen zweifle ich doch sehr stark an dieser Aussage. Es würde mich schon nicht mehr wundern, wenn die Consumer-SSDs in einigen Jahren mit den magnetischen Festplatten gleichziehen würden. Aber bis es soweit ist, werde ich die verblödeten SSD-Nazis auch weiterhin in die Schranken weisen. Storage ist vielen Menschen bei Festplatten eben deutlich wichtiger als reine Geschwindigkeit.

Java

Java Toolkit-Sync verschluckt Interrupted-Flag

0

Da mir im Moment der Sinn nicht ganz nach irgendeinem Politikum steht, worüber ich meinen Senf ausgießen müsste, werde ich vorerst noch mehr Softwareentwickler-Kram posten, mit dem ich die geneigten, aber uninteressierten Leser erfolgreich abschrecken kann. Wir danken für Ihr Verständnis.

Wer sich im Internet gezielt über aktives Rendering mittels Canvas in Java informiert, also etwas, das direkt im Zusammenhang mit Java-Spieleentwicklung steht, der wird wahrscheinlich irgendwann über die Methode sync() in java.awt.Toolkit stolpern, also meistens in der Form Toolkit.getDefaultToolkit().sync(). Nun gehe ich stark davon aus, dass die meisten Entwickler diese Codeschnipsel als gegeben ansehen und 1:1 in ihre eigene Klasse einfügen, da sie wahrscheinlich vielfach erprobt sind. So war das bei mir anfangs leider auch. In einem eigenen Render-Thread habe ich Bilder gerendert und anschließend brav das Toolkit “synchronisiert”, was laut Dokumentation irgendwie “gut für Animationen” ist.

Seit der Umstellung auf aktives Rendering jedoch hatte ich plötzlich Schwierigkeiten damit, den Render-Thread mittels interrupt() vorzeitig zu stoppen, also etwa wenn der Nutzer das Rendering über das Menü beendet oder wenn ein bestimmtes Ereignis auftritt. Zuvor war das nie ein Problem gewesen. Neuerdings läuft der Thread in drei von vier Fällen einfach weiter, sobald ich ihn gezielt unterbrechen will. Das war eine mittlere Katastrophe, denn ich konnte mich jetzt nicht mehr darauf verlassen, dass das Programm das macht, was ich davon erwartete. Mein Programm funktionierte so nicht mehr, und ich wusste nicht, was ich falsch gemacht haben könnte.

Etwa einen halben Tag hat es gedauert, bis ich den Fehler gefunden hatte: java.awt.Toolkit.sync() verschluckt ganz frech das Interrupted-Flag. Es scheint leider wirklich so zu sein. Die Implementation der Java Virtual Machine von Oracle ist hier offenbar fehlerhaft, denn alles funktioniert einwandfrei wenn ich auf sync() verzichte. Sobald ich die Zeile verwende, klappt das Unterbrechen des Threads nicht mehr. Meine Vermutung ist daher, dass das blockierende sync() das Interrupted-Flag mittels interrupted() abfragt (und dadurch löscht!), und dann leider nicht mehr setzt und leider auch keine Exception wirft. Es verschluckt die Thread-Unterbrechung völlig. So wird dieser Mechanismus sogar ganz offiziell in der Java-Doku erklärt:

if (Thread.interrupted()) // Clears interrupted status!

Nun hält sich Oracle selbst nicht daran. Ich habe anschließend in meinem Code keine Möglichkeit mehr, diese Unterbrechung zu erkennen und gegebenenfalls selbst eine InterruptedException auszulösen. Oracle hat hier eindeutig Scheiße gebaut, denn eigentlich ist das Konsens, das Interrupted-Flag nach dem Löschen erneut zu setzen, damit die Unterbrechung nach oben eskaliert werden kann, so dass auch andere Programmteile auf die Unterbrechung korrekt reagieren können. Hier wurde ganz einfach geschlampt.

Und was macht sync() eigentlich? Tja, keine Ahnung. So ganz scheint das nämlich niemand zu wissen. Ich liebe es, wenn die Java-Dokumentation von Oracle so explizit ist, dass man trotzdem keine Ahnung hat, was genau vor sich geht. So auch zur Methode sync() der Klasse Toolkit:

void java.awt.Toolkit.sync()

Synchronizes this toolkit’s graphics state. Some window systems may do buffering of graphics events.

This method ensures that the display is up-to-date. It is useful for animation.

Wenn jemand mal im Internet in einschlägigen Entwicklerforen versucht danach zu fragen, was das genau bedeutet, wird die Frage mit “synchronizes the graphics state” “beantwortet”, und anschließend als Off-Topic geschlossen. Zurecht wurde wenigstens noch darauf hingewiesen, dass das die Frage kaum beantwortet.

Da ich weder sagen kann, was die Methode macht, in welchen Fällen ich sie brauchen könnte, und welche Vorteile oder Nachteile damit zusammenhängen, werde ich auf sync() gerne verzichten, schon da ich mit dem Interrupt-Problem einen ziemlich schwerwiegenden Fehler entdeckt habe, den ich nicht bereit bin zu akzeptieren – ganz egal wie toll die Funktion ansonsten arbeiten möge.

goldenpoo

Eclipse Mars ist scheiße

2

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/.

Spacola_Disks1

SPACOLA Eclipse WIP 0.45

0

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.

Spiel

Das Spiel “mit der Grafik von 1928″

2

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.

Vince's RSS Feed
nach oben