Chaos mit Zeitreisen: Super Time Force Ultra
Monday, 25. October 2021
Der ewige Traum der Zeitreise wird in Filmen und Spielen ja meist zu einem Alptraum, weil kaum eine Geschichte mit Zeitreise als Storyelement vernünftig umgehen kann und dadurch inkohärenter Quark wird. Super Time Force Ultra rennt da mit offenen Augen rein und versucht es gar nicht erst – die Story ist komplett absurdistischer Unsinn. Es gibt einen Antagonisten, der eure verschiedenen Zeitmanipulationen zu verhindern sucht. Belanglos. Es geht allein um die innovative Spielmechanik: Stirbt einer der Pixelcharaktere, kann der Spieler zu einem beliebigen Zeitpunkt zurückspulen und nochmal probieren, diesmal ohne zu sterben das Levelende zu erreichen oder den Bossgegner zu töten. Aber, und das ist das neue, der vorherige Versuch wird ab dem gewählten Zeitpunkt parallel abgespielt, die damals abgegebenen Schüsse und Schläge haben vollen Effekt.
Alle Level sind sind so angelegt, dass diese Vervielfachung der Spielfiguren genutzt werden muss um sie im kurzen Gesamtzeitlimit abschließen zu können. Wodurch auch ein riesiges Chaos und ein entprechender Kugelhagel entsteht: Praktisch ein umgedrehter Danmaku-Shooter, in dem man selbst nach und nach die vielen Projektile hinzufügt, die auch nur Gegnern schaden.
Wobei nicht alle der Spielfiguren schießen können. Eine der Startfiguren hat stattdessen ein Schild und wirft Projektile auf die Gegner zurück. Andere später freischaltbare Figuren haben Nahkampfangriffe, wie der Dino auf dem Skateboard. Durch dieses Freischalten wird das Arsenal des Spielers im Spielverlauf immer größer, wobei manche der Charaktere auch durch Einsammeln der Goldmünzen und nicht in den Level selbst aktiviert werden.
Moment, Dino? Jop, denn wie erwähnt wird es absurd. Die Zeitabschnitte sind in freier Abfolge auswählbar und führen nicht einfach in nahe Vergangenheit und Zukunft, sondern eben auch in eine Dinozeit mit humanoiden Echsen oder mal eben nach Atlantis. Neben passenden regulären Gegnern gibt es dabei auch immer einen Bossgegner. Wer besonders schnell ist kann in den vorherigen Abschnitten ohne Boss auch eine Speedrunchallenge versuchen, mir ist sie nie gelungen.
Super Time Force Ultra nimmt ziemlich erfolgreich eine nette Idee, das Wiederabspielen vorheriger Versuche, und bläst es zu einem effektvollen Spiel auf. Kombiniert mit den Spezialfähigkeiten der Charaktere sowie einem Level- und Gegnerdesign, das die effiziente Nutzung der Kernspielfunktion dauernd einfordert, wird das Spiel weder zu simpel noch zu chaotisch – selbst wenn das nach jedem Level präsentierte Video des Endergebnis der kombinierten Spielerversuche definitiv chaotisch aussieht. Mir ist die Story und das ganze Drumherum zu gewollt absurd gehalten, doch schadet das dem Spiel nicht zu sehr.
Das Spiel war im Humblebundle, wer es dadurch schon hat, dem sei ein Antesten empfohlen
Linksammlung 42/2021
Friday, 22. October 2021
Crazy Ex-Girlfriend
Monday, 18. October 2021
Crazy Ex-Girlfriend ist eine lustige Musicalserie. Ein Meisterwerk wie die FAZ sehe ich in der Serie zwar nicht, aber eine komplett sehenswerte und ziemlich einzigartige Alternative zum sonstigen Serienprogramm.
Das Setting wird im Piloten so vorgestellt: Rebecca lebt als Anwältin in New York, ist unglücklich, dann trifft sie durch Zufall Josh. Den kennt sie von früher, eine Jugendliebe. Als er ihr erzählt wie viel besser es in West Covina, Kalifornien doch sei und dass er dorthin zurückkehren wird, kündigt sie und zieht ihm hinterher – als verrückte Ex, die wieder mit ihm zusammenkommen will.
Komplette Schnulze, oder? Aber die Serie ist eben nicht einfach eine romantische Komödie mit Gesangseinlagen. Sie ist mehr die anti-romantische Komödie. Zwar ist auch hier eine gehörige Portion Fantasieerfüllung mit dabei, aber das ist mehr zum Erträglichmachen des Ganzen. Denn davon abgesehen werden die klassischen Erzählungen kritisiert. Besonders das Hauptthema: Rebecca als psychisch angeknackste Stalkerin wird hier eben nicht einfach zu einer positiven und geheilten Figur weil sie verliebt ist, sondern ganz im Gegenteil ist ihr Verliebtsein komplett destruktiv.
Das wird in absurden Humor verpackt. Statt wie bei den typischen Filmen wie Hitch eine Schnulze mit ein paar Gags anfangs zu verkleiden und danach ohne weitere Witze dem Standardrezept zu folgen, ist Crazy Ex-Girlfriend konstant witzig. Nicht immer zum losbrüllen, aber mindestens etwas absurder Humor findet sich in jeder Folge. Entsprechend schräg wird die weitere Geschichte, wie Rebecca sich in West-Covina einlebt, wie das mit Josh und den Alternativen weitergeht. Ernstere Themen gibt es auch, die psychische Instabilität der Hauptdarstellerin ist da nur eines von mehreren Einfallstoren.
Zu jeder Folge gehören eigene Musicalsongs. Alle davon wurden für die Serie geschrieben, jede Folge hat mehrere. Viele davon sind lustig, parodieren Genres, einige bleiben im Ohr. Die Mitguckerin und ich – ich soll hier anmerken, dass ich die Serie ihr vorschlug, nicht andersrum – zitierten oft und zitieren immer noch einzelne der Lieder. Ich mein, schau dir einfach im ersten Song der Serie an, wie die Passanten die singende Rebecca verdutzt angucken. Solche kleinen Witze finden sich durch die Serie zuhauf.
Wer Musicals hasst oder die Gags im ersten Song so gar nicht lustig findet, der wird mit dieser Serie nichts anfangen können. Aber wer Musik in Filmen als Storyelement (wie bei Blues Brothers) mag, der hat zu Crazy Ex-Girlfriend eigentlich gar keine akzeptable Alternative. Dann passt auch der Rest.
Deus Ex mit weiblichem Hauptcharakter spielen
Wednesday, 13. October 2021
Es war wohl ursprünglich schon für das Release vor 20 Jahren geplant, statt dem männlichen JC Denton auch eine weibliche Version der Hauptfigur spielen zu können. Doch das wurde geschnitten. Jetzt aber ist es möglich: Das Lay D Denton Project baut mit einem Mod das Originalspiel dafür um.
Und dabei macht es viel mehr, als man jetzt vielleicht im ersten Moment erwarten würde. Hier wird nicht einfach das Charaktermodell gewechselt und die Tonart der Sprache des Protagonisten erhöht. Sondern die Sprachausgabe von JC wurde von einer Sprecherin komplett neu vertont, dazu Texte und NPCs samt ihrer Spracheausgabe so angepasst, dass sie JC nicht als Mann anreden. Sogar ein paar neue NPCs wurden eingefügt (komplett vertont!) und wo es passte Situationen abgeändert.
Anfangs wirkt die weibliche JC sehr ungewohnt. Nicht nur, dass es sich mit jahrzehntelanger Gewöhnung beißt – damit der Spieler sich mit der Hauptfigur besser identifizieren kann war schon im Original die Sprache bewusst unbetont (las ich, finde aber gerade keine gute Quelle), was jetzt hier wiederholt wurde und die Sache bestimmt unheimlich schwierig machte. Auf jeden Fall ist ein Riesenaufwand betrieben worden. Das Ergebnis wirkt ziemlich professionell; Nochmal mehr mit der früher oft amateurhaften Modszene von Deus Ex als Maßstab.
Den Mod kann man auf moddb herunterladen. Zum Installieren einfach ins Deus-Ex-Verzeichnis (~/.local/share/Steam/steamapps/common/Deus Ex) entpacken. Dokumentation gibt es auch, es gibt eine Installationsanleitung und eine Projektübersicht. Und schließlich einen Trailer, den ich mir um die Änderungen nicht zu spoilern nur bruchstückhaft angesehen habe:
Der darin benutze Remix ist auch auf Youtube.
Passende Mods
Als kleine Ergänzung: Natürlich hat auch mich dieser Mod dazu gebracht, Deus Ex nochmal zu installieren und von vorne anzufangen. Fertig bin ich noch nicht, kann aber schonmal ein paar andere passende Mods und Hilfsprogramme erwähnen:
- Crispy Deus Ex skaliert die Originaltexturen hoch, ohne irgendetwas am Stil zu ändern. Für die Installation werden nur ein paar Texturdateien ersetzt.
- Joe Wintergreen's Deus Ex Lipsync Mod verbessert tatsächlich die Lippensynchronisation sehr deutlich, eine einzige Datei muss ersetzt werden.
- Da die DirectX-10-Version von Deus Ex mit Proton nicht funktioniert, habe ich für den Renderer wieder auf den Enhanced OpenGL Renderer zurückgegriffen. Auch er er verbessert die Grafik, und hat anders als der DirectX-9-Renderer keine Inkompatibilitäten mit diesem Mod
- Und schließlich benutze ich Deus Exe als Starter, was auf modernen Systemen ein paar Probleme vermeiden soll, wobei das unter Proton wahrscheinlich unnötig ist.
Gerne hätte ich Lay D Denton auch mit dem Transcended-Mod kombiniert, der einige Bugs und Inkonsistenzen aus dem Originalspielt entfernt. Aber leider bin ich daran gescheitert. Zukünftige Versionen dieses Mods sollen die Kompatibilität verbessern, vielleicht gibt es auch bald eine fertige integrierte Versionen mit Transcended als Partnermod.
Ein Jahr mit Flutter
Monday, 11. October 2021
Gut ein Jahr ist es her, dass ich angefangen habe mit Flutter zu arbeiten. Der Auftrag: Eine nutzerfreundliche Anwendung für Android und iOS mit einer gemeinsamen Codebasis zu bauen. Ich fand das Framework zur Mobilanwendungsentwicklung zu Beginn ziemlich toll. Wie sieht es jetzt aus?
Ich finde Flutter immer noch gut, aber habe inzwischen auch mehr von den Schwachstellen mitbekommen. Eine Liste der positiven und der negativen Erkenntnisse folgt.
Gut: Der Widgetbaum
Bei Flutter baut man die Oberfläche, indem die von der Sprache bereitgestellten Widgets in der Build-Funktion eigener Widgets kombiniert werden. Da hat dann eine Row zwei Columns, in denen jeweils drei Buttons sind, schon hat man ein Grid von Buttons mit zwei Spalten und drei Zeilen. Angelehnt am Material-Design gibt es alle wichtigen Widgets vordefiniert, wenn das nicht reicht können aus ihnen neue gebaut oder mit Plugins fertige eingebunden werden.
Das funktioniert einfach sehr gut. Was in anderen Programmiersprachen in den imperativen Aufrufen unweigerlich zum Chaos wird, bleibt mit diesem Prinzip mit nur wenig benötigter Disziplin gut beherrschbar. Die so entstehenden UI-Files sind viel lesbarer und doch auch mächtiger, als wenn es XML-Dateien wären, aber die Zustandsverwaltung und damit die Logik der App soll eindeutig extern definiert werden. Diese propagierte Trennung funktioniert gut, kann für einfache Screens aber trotzdem ignoriert werden, die Logik wird dann mit in die UI gepackt. Aber das macht man selten. Das ist genau die richtige Mischung aus einem guten Konzept und der benötigten Entwicklerfreiheit.
Gut: Zustandsverwaltung mit GetX
Als ich anfing war GetX bei uns umstritten. Ich hatte mir das und als Alternative Bloc angesehen und dann darauf bestanden, dass wir GetX zumindest auch benutzen. Mittlerweile hat GetX sich voll bewährt.
Mit GetX definiert man im Controller der UI spezielle Variablen. Wenn eine davon sich ändert, ändern sich auch die UI-Stelle an denen die Variable verwendet wird. Zum Beispiel hat man im Controller ein Set, baut in der UI daraus eine Liste, und wenn das Set ein Element mehr bekommt wird auch die UI-Liste länger. Das gelingt GetX auf der einen Seite mit möglichst wenig Deklarationen, aber gleichzeitig ist der Voodoo-Aspekt viel geringer als bei Bloc. Dass es keine unnötigen abstrakten Konzepte wie Cubits hat kommt noch dazu.
GetX hat ein paar Stolperfallen, so erkennt es nicht automatisch wenn sich der Inhalt eines Elements des Sets ändert. Da muss man nachhelfen, aber immerhin geht das. Insgesamt ermöglicht es eine effiziente Anwendungsentwicklung ohne Bullshit.
Gut: Die Pluginauswahl
Mit pub.dev gibt es eine klare und hilfreiche Anlaufstelle für Plugins. Dort gibt es Plugins für alles was wir bisher gebraucht haben. Einen kompletten Kalender, Kryptographie, Loginformular, Benachrichtigungen, das oben erwähnte GetX – noch viel mehr und insgesamt alles wurde abgedeckt, mit oft hochqualitativ wirkenden und konfigurierbaren Plugins.
Diese zentrale Quelle zu haben ist viel besser als die mühsame Library-Suche bei Android und auch besser als bei allen anderen Programmiersprachen bzw Frameworks, die ich kenne.
Gut: Dart
Dart hat mich nicht enttäuscht. Ich erwartete das anfangs: Zu hübsch und trotz der Typisierung Ruby-artig war diese Sprache, das konnte nicht wahr sein. Aber es ist wahr. Dart ist einfach ganz wunderbar.
Nicht so dynamisch wie Ruby zu sein schadet ihr an manchen Stellen, vor allem bei der fehlenden Serialisierbarkeit und dem immer noch äußerst umständlichen Umwandeln von Objekten nach JSON (und wieder zurück) schlägt das zu. Aber das erwartete überraschende Fehlverhalten, die frusterregenden Implementierungsfehler – all das blieb aus. Dart würde ich sogar außerhalb von Flutter verwenden, zumindest wenn Ruby nicht verfügbar wäre; vielleicht sogar wenn Ruby verfügbar wäre.
Schlecht: Respektlose Weiterentwicklung
Das größte Problem Flutters ist die respektlose Weiterentwicklung des Frameworks, daher fange ich damit an. Es fehlt den Google-Entwicklern jeglicher Respekt vor der Zeit der Frameworknutzer, was sich in unverschämten und unnötigen Änderungen und völliger Missachtung der Abwärtskompatibilität niederschlägt.
Flutter ist in diesem Jahr von 1.x auf 2.x geklettert. Die große – aber nicht die einzige – Änderung war Null–Safety, was theoretisch optional bleibt aber faktisch durch Plugins erzwungen wird. Null-Safety bedeutet, dass Variablen nicht mehr null werden können, sind sie nicht entsprechend deklariert worden. int? x darf ich auf null setzen – die ?-Syntax-Deklaration ist neu –, int x nicht. Entsprechend muss all der Code der mit einem vorher definierten int x arbeitet angepasst werden, sodass er niemals x ein null zuweisen kann, oder die Deklaration angepasst und dann der Zustand von x an den Schnittstellen zu anderem null-sicheren Code überprüft werden.
Das vermeidet Abstürze, aber es ist ein Riesenwechsel für bestehende Anwendungen. Gut, es gibt ein Migrationstool – aber es funktioniert nicht. Schon bei unserer vergleichsweise simplen App war es überfordert und quittierte nach Tausend Fehlermeldungen den Dienste. Ich habe die Migration komplett per Hand machen müssen.
Es ist auf der einen Seite verständlich, dass ein junges Framework sich noch ändert. Aber alten Code so unbrauchbar zu machen, Migrationstools beiseite zu stellen die schlicht nicht funktionieren, dafür gibt es keine Entschuldigung.
Und bei dieser einen Änderung bleibt es ja nicht. Im gleichen Atemzug wurden beispielsweise auch einfach mal die bisherigen Buttonklassen deprecated. Und die neuen haben eine völlig andere API, sie werden mit viel kompliziertem Code angepasst. Es ist okay ein neues System für Buttons dem Framework hinzufügen, aber die alten abzuschaffen ist eine völlig unnötige Gängelung.
Hier schlägt das System Google durch: Tausende Entwickler arbeiten am Framework, die kleinen frameworknutzenden Entwicklerstudios verbringen dann ihre Zeit damit den dauernden Änderungen hinterherzurennen. Das ist einerseits monopolsichernd und andererseits ein Strukturproblem der Organisation Google, aber die Ursache zu verstehen hilft in der Praxis wenig.
Schon deswegen würde ich Flutter nicht für ein FOSS-Projekt empfehlen, es ungern selbst in meiner Freizeit nutzen, sogar Firmen gegen die Nutzung raten. Wobei: Android und iOS nativ zu bespielen ist auch nicht besser, wenn eine Mobilanwendung wirklich sein muss ist Flutter immer noch besser als das. Aber was für eine vertane Chance Flutter doch ist, nur durch schlechtes Google-Projektmanagement.
Schlecht: Die Pluginweiterentwicklung
Was für die Sprache gilt, gilt für die Plugins nur noch mehr: Da wird in einem durch fröhlich alter Code kaputtgemacht. Es ist zwar alles auf dem Papier SemVer, doch in der Praxis hält das die wenigsten Entwickler davon ab mit Patch- und Funktionsupdates alten Code invalid zu machen. Migrationsguides sind dann unvollständig und versteckt in Github-Issues, eine Kryptolibrary kann den eigenen Ciphertext nicht mehr lesen, ein Router (ein Modul um die Ansicht zu wechseln) wird so vollständig umgebaut dass jeder Aufruf angepasst werden muss, ohne dass die Dokumentation das auch nur erwähnt. Und spätestens durch Null-Safety wurden die Upgrades nicht-optional, man kann sich ihnen nicht entziehen.
Wenn man es vorher wüsste würde man nur Abhängigkeiten auf Module vernünftiger Entwickler aufbauen. Aber das sieht man im Vorhinein eben nicht immer. Und im Flutterland scheinen die besonders selten zu sein. Vielleicht kommt das aus der früheren Javascript-Herkunft.
Schlecht: Kompilierzeiten und -aufwand
Meine Firma macht die Flutterentwicklung mit Visual Studio Code und hat mir ein nettes Laptop gestellt, mit einem Ryzen 7 3700U und 16GB Ram. Das reichte nicht. Ich brauchte zuerst ein Ramupgrade, um beim Kompilieren (mit Emulator und Browser offen, klar) nicht immer wieder ein einfrierendes System zu haben. Und trotz dem modernen und starken Prozessor (und natürlich einer SSD) dauert das Bauen der Androidanwendung inzwischen einfach lange. Schon eher Minuten als Sekunden. Und dabei ist die von uns gebaute App nicht riesig.
Es gibt zwar wie bei Android Studio ein Hot Reload, aber das bringt bei Änderungen der Controller wenig, denn die bleiben bei ihrem alten Zustand. Das genügt also nur in den seltensten Fällen, daher wird viel kompiliert und dabei gewartet. Ich müsste im Grunde an einer Threadripper-Workstation arbeiten. Das macht bei meiner Dauer-Heimarbeit ja sogar Sinn, nur war die ungeplant und sollte das für die Mobilanwendungsentwicklung auch einfach nicht nötig sein.
Schlecht: Webapps
Flutter kann auch Webapps bauen, aber das Ergebnis sind Javascriptmonster die sich an keine Webkonventionen halten. Nutzer können nichtmal Text kopieren, wird das Standard-Textwidget benutzt. Völlig unverständlich, solche Macken blockieren komplett die Adaption des Frameworks im Webbereich.
Ambivalent: Limitierungen der Mobilplattformen bleiben erhalten
Genug von den klar negativen Eigenschaften. So wie Flutter gute und schlechte Seiten hat, sind manche Eigenschaften des Frameworks weder klar negativ noch positiv.
So umschifft Flutter die tieferen Limitierungen der mobilen Betriebssysteme einfach genau gar nicht. Arbeiten im Hintergrund beispielsweise geht unter Android manchmal, unter iOS praktisch nicht. Aber es das Framework hat keine Infrastruktur, um das doch zuverlässig zu können, nichtmal unter dem eigenen Betriebssystem Android. Anderes Beispiel: Geplante Benachrichtigungen beschränkt iOS auf 64, Android auf mehrere Hundert, Flutter und seine Plugins lässt den Entwickler in diesen Unterschied schlicht reinrennen. Unter Android kann man aus einem Formular Zurück-Swipen und dann in einem Dialog vor verlorengehenden Daten warnen, unter iOS geht das nicht. 2018 hat ein Entwickler das Problem nicht verstanden, seitdem ist es im Kern ungefixt.
Wäre Flutter nicht von Google könnte man dem Framework solche Limitierungen nur schwer anlasten. Aber weil Google mit seiner Größe und Rolle als Androidentwickler die Möglichkeiten hätte hier Lösungen anzubieten, kann ich das dem Framework nicht einfach durchgehen lassen. Es stellt zwar in manchen Bereichen eine brauchbare gemeinsame Basis für die Entwicklung von iOS- wie Androidanwendungen her, das ist der positive Teil. Aber es übertüncht die Unterschiede ungenügend, aber macht es dabei trotzdem schwerer die Stärken von Android zu nutzen, wie dessen eigentlich funktionierende Hintergrundthreads via WorkManager oder Vorgängerlösungen. Und das macht Flutters Vorzüge etwas kaputt.
Ambivalent: Die deklarative Widgetverwaltung
In Flutter werden Widgets einmal deklariert, dabei konfiguriert, später reagieren sie nur noch auf Interaktionen vom Nutzer oder Zustandsänderungen. Das ermöglicht den oben gelobten expliziten Widgetbaum, das ist positiv. Aber Widgets so gar nicht imperativ manipulieren zu können ist manchmal hochproblematisch. Wie schließt man zum Beispiel auf Knopfdruck das geöffnete Overlay eines Autocomplete-Widgets? Nur durch einen Hack, indem man mit dem FocusManager dem Widget den Fokus entzieht.
Andere Dinge gehen manchmal einfach gar nicht. Hier müssten die Entwickler eine bessere Mischung zwischen Konzepttreue und Entwicklerbefähigung finden.
Ambivalent: Performance
Flutter will Anwendungen mit 60 FPS zeichnen, inzwischen sogar mit 120 FPS auf entsprechenden Geräten. Was ist mit 360 FPS bei Webanwendungen? Okay, bleiben wir fair. Aber auch das erklärte 60-FPS-Ziel ist illusorisch, wenn beim ersten Öffnen einer App es an allen Ecken und Enden laggt. Da müssen z.B. noch die Shader kompiliert werden, was gerade unter iOS massiv zu Einschränken führt. Erst die gerade veröffentlichte Version 2.5 schafft da vielleicht Abhilfe.
Es stimmt, dass die gebauten Oberflächen ansonsten meist performant laufen. Deswegen ist der Punkt nicht unter den schlechten Seiten eingeordnet. Aber können das nicht im Grunde alle Frameworks zur mobilen Appentwicklung? Sobald etwas im Hintergrund rennt muss das auch bei Flutter manuell in einen Thread geschoben werden, was nicht immer geht, dazu kommen dann die Shader-Stotter. Vielleicht bewerte ich hier Flutter sogar zu positiv.
Ambivalent: Die Testumgebung
Und schließlich ist da noch die Testumgebung. Flutter kann Unit-, Widget- und nun auch Integrationstests. Bei Unittests sollen einzelne Bestandteile des Codes getestet werden, mit Widgettests der gewünschte Aufbau der UI kontrolliert, mit Integrationtests der Ablauf der kompletten App. Das ist alles eingebaut und Tests zu schreiben ist mit dem System keine Qual, immerhin.
Aber andererseits sind die Testumgebungen für Unit- und Widgetttests lächerlich beschränkt. Unittests können im Grunde nichts machen außer lokal Dart-Code ausführen, aber nicht mit dem System interagieren, keine HTTP-Requests senden. Soll eine API-konsumierende Funktion getestet werden darf man die API dann mocken. Es gibt zwar Leute, die das für die richtige Art halten Unit-Tests zu schreiben. Aber ich halte das für eine irrige Position, denn es führt zu einen riesigen Aufwand und verhindert, dass Tests echte Fehlerfälle erkennen.
Bei bei den Integrationtests gibt es diese Beschränkungen zwar nicht, aber dafür gibt es sie erst seit kurzem. Integrationtests funktionieren erst seit einem Umbau des Systems, der erst jetzt fertig wurde. Davor waren sie undokumentierterweise einfach kaputt, ich zumindest kriegte sie partout nicht zum Laufen. Und das ging wohl vielen so. Sie müssen auch immer noch auf simulierten oder echten Geräten laufen, was in einer CI-Infrastruktur aufwendig und damit im Zweifel teuer ist.
Flutter ermöglicht das Testen des Codes. Vielleicht macht es das besser als andere Frameworks in dem Bereich. Aber es ist viel komplizierter als ideal.
Fazit: Die rosa Brille ist weg
Ich mag Flutter immer noch. Man muss sich vor Augen halten, wie hochproblematisch die native Anwendungsentwicklung sein kann, schon wirken die Probleme des Frameworks weniger gewichtig. Dart ist sogar toll. Insgesamt schafft mein kleines Team tolle Arbeit und auch ich fühle mich mit Flutter produktiv. Meine Nutzertests bestätigen den positiven Eindruck des Ergebnis, das war dann sogar großartig.
Aber es ist dann eben doch ein Google-Framework, seine hässlichen Seiten passen genau dazu. Serendipity versucht wahrscheinlich seit fast 20 Jahren mit einem Mini-Team Abwärtskompatibilität beizubehalten, bei Flutter kriegt ein Milliardenunternehmen es nicht mein erstes aktive Jahr hin.
Auch die Stärken passen: Cross-Plattformanwendungen mit wenig Aufwand und einem so guten Konzept bauen zu können passt zu der technischen Leistungsfähigkeit dieses Unternehmens. Die sieht man am Anfang, daher damals mein erster sehr positiver Eindruck. Die Schwächen sieht man dann später, daher mein jetzt etwas durchwachsenerer.
Ich hoffe, meine Bewertung kann dem einen oder anderen Leser bei seiner Entscheidung helfen, ob er Flutter verwenden sollte oder nicht. Ich möchte wirklich nicht zu stark von abraten – die beworbenen Stärken sind ja da. Nur sollte man sich der Schwächen des Frameworks ebenfalls bewusst sein.
Deus Ex - NYC Streets [Chillwave Cover] || Mairiba
Sunday, 10. October 2021
Linksammlung 40/2021
Friday, 8. October 2021
Temi Oh: Do You Dream of Terra-Two?
Monday, 4. October 2021
Zwischendurch war ich genervt: Das sollte wirklich das Buch sein, das so gelobt wurde? Do You Dream of Terra-Two ist das Erstlingswerk von Temi Oh. Eine Science-Fiction-Geschichte über eine Weltraummission zu einem entfernten Planeten. Bei den guten Kritiken hatte ich mich hierdrauf sehr gefreut.
Aber ich war erstmal irritiert. Zum einen fokussiert sich die Geschichte sehr auf die jungen Astronauten und ähnelt damit auf dem ersten Blick den Szenarios der Sexgeschichten, die andere Autorinnen als SciFi-Romane vermarkten. Und zum anderen ist es zum Haare ausreißen, wie unfähig und ungebildet die Astronauten in der Handlung manchmal sind. Es braucht Geduld und Aufmerksamkeit um zu verstehen, was für einen Roman man da gerade wirklich liest, dass er vorsichtig konstruiert, nichts zufällig ist. Und dass er tatsächlich und bis zum Ende niemals in die Blödheit und Vulgarität der Humble-Bundle-Frauenromane abgleitet. Nachdenklich ist er, kritisch, melancholisch, bis auf ein paar Ausnahmen langsam – und ja, damit sehr anders als andere Science-Fiction-Romane. Aber doch ist das Genre kein Anstrich, wie auch ich dann merkte.
Dass Goodreads ihn bei "Young Adults" einordnet halte ich daher für ziemlich daneben. Die wenigsten Jugendlichen dürften mit dem Buch etwas anfangen können. Klar kann man die Handlung auch oberflächlich durchlesen, aber dann wird der Roman nur frustrieren. Dafür ist er zu kompliziert, denn der Leser muss diesem Text erstmal auf die Schliche kommen und hat selbst dann noch genug Spielraum für eigene Interpretationen.
Linksammlung 39/2021
Friday, 1. October 2021
Outland
Wednesday, 29. September 2021
Outland ist ein nativ unter Linux laufendes Spiel, das ich mehr als Plattformer denn als Metroidvania einordnen würde.
Ihr kontrolliert eine Spielfigur, die im Laufe des kurzen Spiels immer mehr kann. Primär Springen und Angreifen, aber vor allem auch die Farbe wechseln kommt sehr schnell dazu. Ob rot oder blau gewählt ist macht dann blaue oder rote Gegner verwundbar, während die herumfliegenden Energiekugeln nur in der Gegenfarbe gefährlich sind.
So immer mehr zu können und die Spielwelt frei zu durchlaufen, wobei mit den neuen Fähigkeiten neue Gebiete freizuschalten werden, das würde zu einem Metroidvania passen. Aber in Outland wird die richtige Route immer vorgegeben. Das Spiel ist also komplett linear, selbst wenn diese Route mal wieder in vorherige Gebiete zurückführt. Wobei es sich regelmäßig lohnt, die Ecken der Karte abseits der Hauptroute abzusuchen um Upgradeschreine zu finden sowie Gold für diese einzusammeln.
Die Geschichte um mörderische Götterschwestern aus Licht und Schatten (rot und blau?) ist belanglos, sie ist klar nur dazu da die Levels etwas zu verbinden. Dafür sieht das farbenfrohe Design wirklich gut aus. Mit den Farbwechseln, den Gegnern und den vielen Energiekugeln wird Outland später schon herausfordernd, aber es fordert nur an ganz wenigen Stellen annähernd die Konzentration eines Bosskampfes bei Hollow Knight, auch die Sprungpassagen sind kürzer und einfacher. Dazu hat Sterben aufgrund der häufigen Checkpoints praktisch keine Konsequenzen.
Wer diese Art von Spielen gerne spielt kann auch Outland spielen und bekommt damit einen kurzen Lückenfüller, der die Spielzeit über durchaus Spaß macht. Denn das Leveldesign ist gelungen, es bietet immer wieder neue Herausforderungen zum Knobeln. Aber der große Wurf ist es leider nicht geworden, trotz des wirklich netten Designs. Dafür fehlt an spielerischer Tiefe und insgesamt an Atmosphäre.
Mein Rückblick aufs Studium, Teil 1: Bachelor Informatik TU Darmstadt
Monday, 27. September 2021
Ich habe viel Zeit an der Uni verbracht, darüber aber hier nur selten geschrieben. Mittlerweile arbeite ich seit ein paar Jahren und das Studium wird mehr und mehr eine ferne Erinnerung. Zeit, ein paar Erfahrungen festzuhalten.
Der Start war ein Informatikstudium an der TU Darmstadt, das ich vor fast genau einer Dekade abgeschlossen habe. Es war nur ein Bachelorstudium, den Master machte ich anderswo. Die Rahmenbedingungen waren gut: Die TU galt als gute Uni. Auch wenn es noch Diplomstudenten gab – einer davon wurde unser D&D-Dungeonmaster – war der Umstieg vom Diplomsystem mittlerweile fertig, es gab auch keine Wahl mehr, das schuf Fakten und Klarheit. Unsicherheit kam von den asozialen Studiengebühren, doch die wurden mir im ersten Semester erlassen und im zweiten dank Ypsilanti ganz abgeschafft. Das Studium selbst war von Seiten der Universität ziemlich toll organisiert, aber es war viel Arbeit und die Zeit insgesamt für mich ziemlich chaotisch.
Der Ablauf des Studiums
Da es keine Zulassungsbeschränkung gab saß ich am Anfang des Studiums mit sehr vielen anderen neuen Studenten in völlig überfüllten Hörsälen. Am schlimmsten war da Mathe 1, da passten die Leute nichtmal mehr auf die Stufen neben den Stühlen. Das blieb natürlich nicht so: Es würde mich sehr wundern, wenn mehr als 50% das Studium abgeschlossen haben, zudem sparten sich bald selbst viele die weitermachten die Vorlesungen.
Die Übungen waren sowieso wichtiger: In ihnen kam der Stoff vor, der dann in den Prüfungen getestet wurde. Geleitet wurden diese Übungen meist von Studenten, als Nebenjob. Alle meine Prüfungen waren schriftlich, mündliche Prüfungen gab es in anderen Kursen, aber sie waren selten und galten als schwierig. Bei allen regulären Vorlesungen gab es am Ende stattdessen eine schriftliche Prüfung. Ohne irgendeinen Tests an Scheine zu kommen war mit dem Diplomsystem so ziemlich abgeschafft worden, ging aber noch in Seminaren – da wurde dann eine Präsentation bewertet. Das war natürlich der große Stressfaktor: Dass man durch Prüfungen und nach dreimaligen Scheitern an einer Prüfung sogar durch das ganze Studium durchfallen konnte. Zum Glück blieb mir der Drittversuch erspart, aber nicht alle Prüfungen konnte ich auf Anhieb bestehen. Auch deswegen war es die oben erwähnte chaotische Zeit.
Die Massenvorlesungen am Anfang deckten die Grundthemen ab. Grundlagen der Informatik (GDI), Formale Grundlagen der Informatik (FGDI), Technische Grundlagen der Informatik (TGDI), Mathe. Davon gab es jeweils drei Kurse, nur TGDI blieb bei zweien. Nach den ersten Semestern kamen dann Kanonikfächer hinzu, "Einführung in X" – Computational Engineering, Computer Microsystems, Foundations of Computing, Human Computer Systems, Data and Knowledge Engineering und Net Centric Systems.
Gegen Ende gab es noch Wahlpflichtfächer, wo man sich aus einer Auswahl von Themen die seinen raussuchen konnte, das war die minimale Spezialisierungsmöglichkeit. Bei mir wurde das Kryptographie, Mensch-Computer-Interaktion (HCI) und Künstliche Intelligenz. Man musste ein Bachelorpraktikum abliefern, aber was da die Optionen waren krieg ich nicht mehr zusammen. War das mit der Bachelorarbeit kombiniert? Denn die galt es ganz zuletzt zu schreiben, wobei man dafür noch einen Kurs besuchen konnte und dann mit Kommilitonen den Fortschritt besprach, was sehr hilfreich war.
Studiumsinhalte
Worum ging es jeweils? Ich werde nicht alles durchgehen, will aber einen Eindruck der wichtigsten Inhalte geben.
In GDI ging es ums Bauen von Software. Am Anfang schlicht ums Programmieren: Wir lernten erst Scheme (jetzt Racket, ein LISP), dann Java, programmierten zusammen ein Spiel und lernten über die Komplexität von Algorithmen (O-Notation). Und das war alles GDI 1. An spätere Inhalte erinnere ich mich weniger gut. Ein kurzer Abschnitt wurde in C programmiert. Aber wir müssen auch Stoff über Wasserfallmodelle, Pflichtenhefte, Designpatterns und UML gehört haben – das meiste davon war anders als die erste Vorlesung im Nachhinein irrelevant, aber gut zu wissen dass es das mal gab. Spezielle Algorithmen wie Quicksort kamen später auch vor, das war schon hilfreicher, auch Datenstrukturen wie Bäume waren ein wichtiges und nützliches Thema.
FGDI war Logik. Meine Anleitungen um einen Zustandsautomaten zu mimieren und zum Markierungsalgorithmus stammen daher, ob das nun FGDI 1 oder 2 war ist mir unklar. Anfangs ging es um Grundlagen wie Prädikatenlogik. Ich habe es gehasst, die Artikel landeten im Blog um mir Inhalte ins Hirn zu prügeln und anderen zu helfen. Ich muss aber zugeben, dass es später hilfreich und notwendig war solche formalen Logikausdrücke lesen zu können. FGDI 3 war etwas anders: Da ging es um die Verifikation von Programmen. Die wurden dafür in einer Spezialsprache geschrieben und ihre Richtigkeit musste dann Annahme für Annahme bewiesen werden. Auf der einen Seite absurd komplett nicht praxistauglich, auf der anderen konnte man sich vorstellen, wie das irgendwann doch praxistauglich werden könnte, es hieß sogar Prozessorhersteller würden das bereits machen (und später las ich, sie hätten das größtenteils aufgegeben).
TGDI hasste ich nicht, aber diese technischen Grundlagen hatte ich nie gehabt. Und-, Oder-, XOR-Schaltungen, Verilog und damit irgendwas anfangen – ich schnappte ein paar Grundlagen auf und kam durch die Prüfung. Im zweiten Kurs ging es dann mehr um Prozessorarchitekturen. Ob wir hier oder in GDI in Assembler programmiert haben krieg ich nicht mehr zusammen, aber das war auf jeden Fall spaßig.
Bei Mathe kann ich kaum noch auch nur die Inhalt benennen. Mathe 1 und 2 war ein wilder Mischmasch von irgendwelchen Mathematikkenntnissen – irgendwas mit Reihen, Ableitungen, Beweisen. Mathe 3 war Computation (und Statistik?), also Mathematik vom Computer lösen lassen, was oft andere Ansätze braucht. Das hatte etwas Berechtigung. Aber Mathematik wie es dort zuvor gemacht wurde war ein pures Aussiebefach und vermittelte wenig, was irgendwie hängenblieb oder ich bisher nochmal gebraucht hätte. Teilweise wiederholten sich Inhalte in den spezialisierteren Fächern, die waren dann relevant und gut sie schonmal gehört zu haben, Gruppen beispielsweise. Aber hätte es kein Siebfach gebraucht hätte man Mathe schlicht weglassen und die Inhalte dort lehren können wo sie benutzt wurden.
Bei den "Einführung in X"-Fächern ging es um ganz verschiedene Themen. Bis jetzt lernten wir ja nur allgemeine Grundlagen. Net Centric Systems z.B. konnte dann über Netzwerke und über das Internet reden. Es ging auch darum grob die Forschungsbereiche der Informatik abbilden. Die Wahlpflichtfächer gingen da dann später etwas tiefer, für die, die Interesse an einem bestimmten Thema hatten.
Besondere Inhalte und Lektionen
Besonders prägend war Grundlagen der Informatik. Wegen dem Fach mit seinen Inhalten waren die meisten Studenten in dem Studiengang, mich eingeschlossen. Tatsächlich lernte man dort dann auch viele Konzepte, die für jeden Programmierer völlig relevant sind: Objektorientierte und funktionale Programmierung, Datentypen, Rekursion, Komplexität, aber auch generell das Entwerfen von und Arbeiten mit Algorithmen sowie das Planen von Programmen.
Trotz diesem praktischen Aspekt des Studiums wurde gepredigt, dass ein Informatiker Konzepte lernt und die dann in jeder beliebigen Programmiersprache anwenden kann. Ich merkte später: Das stimmt nur so halb. Um abstrakte Konzepte wirklich anzuwenden muss man die Sprache beherrschen, das braucht Übung mit ihr. Bevor ich Ruby lernte – eigenständig im Master – konnte ich zum Beispiel faktisch kaum Serveranwendungen bauen, völlig egal ob ich die Konzepte drauf hatte. Aber es stimmt, dass sich viel übertragen lässt, und zwischen ähnlichen Sprachen zu wechseln ist kein großes Problem. Es stimmt aber auch der Vorwurf am Hochschulstudium, dass selbst das Bachelorstudium noch zu abstrakt ist um den Studenten wirklich das Programmieren beizubringen. Das müssen sie aus eigenem Antrieb zusätzlich oder später machen, selbst GDI mit seinem Praxisteil schafft nur wenige Grundlagen. Oder zumindest war das damals so.
Was stimmte: Die Predigt vom Dekan ziemlich am Anfang des Studiums, dass er keinen von uns in gewöhnlichen Studentenjobs sehen will, wir seien alle jetzt schon als Programmierer beschäftigbar. Naja, vielleicht galt das nicht für alle, aber tatsächlich waren die Anfangsinhalte die wichtigsten und Firmen hätte mit den motivierteren Studenten definitiv arbeiten können.
Wieviel weiteres nützliches man aus dem Studium ziehen konnte hing aber auch von den Wahlpflichtfächern ab. Meine Themenwahl sehe ich heute noch mit Wohlwollen.
Künstliche Intelligenz war vor dem aktuellen Boom, neuronale Netze ein veraltetes Nischenthema. Trotzdem oder gerade deswegen war die Vorlesung super – denn KI hat im Kern das Thema, das mich an Informatik anfangs so faszinierte, nämlich wie man mit Algorithmen Probleme lösen kann. Der auf einem Infotag präsentierte Dijkstra-Algorithmus, der ein Wegfindeproblem lösen kann, hatte damals erst den Ausschlag gegeben dieses Studium zu wählen. Ich sehe KI als die komprimierte Essenz der Informatik, entsprechend spannend war die Vorlesung. Wobei ich wenig konkrete Inhalte aus ihr bisher anwenden konnte, wohl aber viele Ansätze.
Kryptographie zu belegen war überraschend lohnenswert, weil IT-Sicherheit in jedem Projekt ein Thema ist und die Grundlagen von damals mich immer noch tragen. Zudem war der Professor Johannes Buchmann, der es einfach drauf hatte die Vorlesung interessant und verständlich zu halten. Ich glaube, das war auch die Vorlesung für die ich RSA in Bash implementierte, was ein bisschen zeigt wie locker man das Thema angehen konnte.
Außerdem war HCI ein prägender Kurs zu Usability. Als Informatiker fand ich das besonders toll, weil es einen Weg vorwärts versprach wie man alles andere anwenden konnte. Nicht nur viel wissen, sondern auch herausfinden können was man überhaupt bauen soll und womit Nutzer umgehen können. Damit wollte ich weitermachen, also wurde das Thema mein Masterstudium – was nicht ganz klappte, aber dazu später mal mehr.
Und schließlich, etwas allgemeiner: Diese übliche Prophezeiung, dass im Studium viele gute Leute zusammenkommen und die dann auch oft besser sind als du, in Darmstadt stimmte das für mich. Auch eine Erfahrung.
Leben als Student in Darmstadt
Nach etwas Eingewöhnungszeit wurde das Studieren zum Alltag. Ich besuchte die Vorlesungen fast immer, nahm an den Übungen teil, und füllte die verbliebene Zeit mit anderen Dingen.
Am Anfang hatte ich keine Zeit über, denn anfangs bin ich von meinem Heimatort nach Darmstadt gependelt, was großer Mist war. Dass ich seitdem mit einer kurzen Ausnahme nie wieder gependelt bin ist kein Zufall. Erstens kriegte ich anfangs vom Studentenleben wenig mit, zweitens fühlte ich mich wegen der unsicheren Heimreise in Darmstadt nicht wohl, drittens schadete es der Motivation an den Vorlesungen und Übungen teilzunehmen und damit dem Studium. Gerade kommt mir der Gedanke: Man konnte beides damals nicht von Zuhause machen, vielleicht ginge zumindest die fachliche Seite mittlerweile trotz der Distanz etwas besser?
Später wohnte ich im Studentenheim, das half sehr. Es gab dort aber die absurde Situation, pfeilschnelles Internet zu haben, aber nur 10 oder 20 GB Traffic, danach wurde die Leitung für den Monat abgeschaltet. Ich hoffe, das ist heute Geschichte – ah, sie sind jetzt bei 120GB, das sind immer noch nur 2 AAA-Spiele. Peinlich. Und es half anfangs nicht gerade beim Sicherheitsgefühl in der neuen Heimat.
Studentenjobs an der Uni dagegen waren eine gute Sache für mich. Eine Weile war ich Mentor für Erstsemester, ihr einer Pflichttermin. Diese Tätigkeit hatte das außerhalb der üblichen Anliegen der Menties so gar nichts mit Informatik zu tun, das war eine interessante Erfahrung. Später als Tutor in Übungen lernte ich immerhin noch, wie schwer diese Rolle ist und wieviel man von dem Stoff auch wieder vergessen hat.
In meiner Freizeit verbrachte ich als Informatiker viel Zeit vor dem Rechner, klar. Von Darmstadt habe ich nicht viel mitbekommen, um in Cafes rumzusitzen zum Beispiel hätte mir auch schlicht das Geld gefehlt. Aber so ein bisschen Studentenleben nahm ich doch mit: Mit Jugger eine ungewöhnliche Sportart; Serien bekamen durch das Studentennetzwerk eine neue Bedeutung, Filme ebenso durch den Mathefilmabend (mit schlechten Filmen) und dem Studentenkino im Audimax (mit besseren); auf Vorschlag einer Kommilitonin lernte ich mit ihr Salsa, ich war und bin darin untalentiert, aber es war aus Gründen später eine der wichtigsten Sachen die ich hätte lernen können. Die D&D-Gruppe erwähnte ich oben über den Spielemeister, eine Brettspielgruppe fand sich auch, meine erste. Ein paar Klischees erlebte ich zudem: Den sich nie als nützlich erweisenden Sprachkurs, krude Charaktere in WGs, sogar eine für mich gescheiterte WG, ein paar wenige Studentenfeiern.
Man kann sich ja gerade bei Informatik auf den Standpunkt stellen, dass das Studium nicht lohnt. Einfach alles relevante online lernen, oder eine Ausbildung im Unternehmen machen und so früh wie möglich mit dem Arbeiten anfangen, beides bringe am Ende durch die gesparte Zeit mehr Gehalt. Stimmt monetär vielleicht. Aber wenn nicht gerade eine Pandemie alles sowieso blockiert, dann verpasst man so eben auch dieses Leben. Das zwar bei all der Arbeit, dem geringen Einkommen und dem dauernden Prüfungsstress auch nicht immer toll war, aber im Nachhinein echt keine schlechte Zeit.
Fazit
Man wurde im Informatikstudium mit Stoff bombardiert. Das schaffte viele Grundlagen, um Neues zu verstehen und auch anzuwenden. So brauchte ich beispielsweise diesen Schubs, um die praktische Funktion von Datenbanken zu verstehen und in meine Projekte einbauen zu können. Generell wurde alles was irgendwie praxisrelevant war besonders interessant: Beispielsweise auch der Bayes-Algorithmus wegen meinem Bayes-Spamblockplugin. Aber das funktionierte auch andersrum: Praktisch alles, für das ich einen Zugang finden konnte – was mir nicht komplett unergründlich war – hatte in den Folgejahren nochmal irgendwie eine Relevanz. Selbst manche der Mathematikkenntnisse, sogar die Logikformeln aus den formalen Grundlagen erleichterten später mindestens das Lesen mancher Veröffentlichungen.
Gut, manches war zu speziell oder ist mittlerweile veraltet. Das Wasserfallmodell als Entwicklungsmodell mit Lasten und Pflichtenheft zum Beispiel – klar gibt es das noch, aber es ist aus gutem Grund nicht der Standard. UML-Diagramme hätte man auch weniger machen können, damit Programme zu planen wurde sicher nicht die Zukunft der Programmierung. Wobei: No-Code-Programmierung baut ja irgendwo schon auf den gleichen Ideen auf, dafür gibt es derzeit verstärkt Aufmerksamkeit. Bei den Software-Designpatterns weiß ich nicht mehr, ob meine bis heute anhaltende kritische Haltung vom Dozent vermittelt wurde oder ob ich damals schon ihre Probleme wahrnahm. Aber das Thema zeigt die Gefahr, dass man an der Uni auch Dinge lernen kann, die einem Programmierer in der Praxis eher schaden – wie das übertriebene Anwenden von Desingpatterns.
Doch insgesamt: Für jemanden, der später Software bauen wollte, war das Informatikstudium in Darmstadt eine gute Wahl. Dass ich mir ein eigenes Bachelorarbeitsthema aussuchen konnte, direkt einen tollen Betreuer fand und daran dann auch noch bei der Telekom arbeiten konnte war dann noch ein guter Endpunkt eines guten Studiums. Rückblickend muss ich auch loben, wie gut die Uni ausgestattet war (schon der PC-Pool im Keller mit sauber funktionierenden Linux-Computern), wie fähig die Professoren Vorlesungen hielten und wie gut das Studium organisiert war, abgesehen nur vom damals fast unschaffbar überfrachteten dritten Semester.
Müsste ich nochmal von vorne anfangen, würde ich direkt wieder dieses Studium wählen und auch wieder nach Darmstadt gehen. Stattdessen ging es mit einem Master weiter, über den es auch einiges zu erzählen gibt.
Linksammlung 38/2021
Friday, 24. September 2021
Die Geschichte der Game Developers Conference
Wednesday, 22. September 2021
Review zu Murdered: Soul Suspect
Monday, 20. September 2021
Murdered: Soul Suspect beginnt, als eigentlich alles schon vorbei ist. Der Serienmörder wirft den Polizisten Ronan, den ihr spielen werdet, durch ein Fenster und erschießt ihn. Doch er steht wieder auf – als Geist, gefangen auf der Erde im Ort Salem. Um ihr zu entfliehen muss erst der verbliebene Fall gelöst werden.
Rätseln…
Das versucht ihr dann also in den nächsten Stunden. Siebeneinhalb beschäftigte mich das Spiel, bis es komplett zu Ende war. Spielerisch gibt es dabei gar nicht so viele Elemente.
Zum einen gibt es Tatorte zu untersuchen. Es wird angezeigt wie viele Indizien es zu finden gibt, das sind dann zum Beispiel die Glassplitter des durchbrochenen Fensters oder gar die Mordwaffe, aber auch phantastischere Elemente wie verbliebene Hologramme, die ihr interpretieren müsst. Sind genug oder alle gefunden müssen in einem kleinen Puzzle die relevanten Fakten ausgewählt werden, wobei die Fragestellung dazu eingeblendet wird. Das ähnelt L.A. Noire, nur mit abschließender Faktenauswahl statt Verhören.
Als Geist sind eure Möglichkeiten abseits und während dieser Aufgaben beschränkt. Ihr könnt in Menschen hineinfliegen und ihre Gedanken lesen, an vorgegebenen Stellen durch Auswahl von vorher gefundenen Indizien ihre Gedanken beeinflussen, oder selten durch ihre Augen Indizien sehen. Katzen könnt ihr ganz steuern, das ermöglicht das Erreichen von versteckten Orten. Manchmal können Geisterweltelement eingeblendet oder entfernt werden, sodass dann neue Bereiche zugänglich werden. Und schließlich kann als Polstergeist noch Technik gestört werden, was dann z.B. Wachen ablenkt und euren Verbündeten an ihnen vorbeischleichen lässt.
Denn ganz alleine seid ihr nicht: Neben anderen Geistern können auch Medien euch sehen, Ronan wird im Laufe der Handlung mit einem Medium zusammenarbeiten. Die Gespräche zwischen den beiden sind ganz nett gemacht. Auch Ronans Hintergrundgeschichte wird im Laufe der Zeit weiter ausgebreitet, sie ist nicht umwerfend originell, aber ausreichend um das Spiel etwas auszuschmücken. Gleiches gilt auch für die Haupthandlung – den Serienmord mit seinen natürlich okkulten Elementen aufzudecken überrascht selten und ist auch nicht besonders spannend erzählt, ist aber gerade ausreichend motivierend.
…und Dämonen vermeiden
Gefahr drohte in den oben beschriebenen Spielmechaniken nicht, nur Rätsel nicht beantworten zu können wird nach drei Fehlversuchen zum Problem. Das wäre arg gemächlich, dachten sich wohl die Entwickler, und bauten noch Dämonen ein. An wenigen Stellen fliegen die auf festen Routen durch die Gegend. Ronan kann sie von hinten erwischen und dann mit einem Quicktimevent exorzieren. Verkackt ihr den oder sehen die Dämonen euch davor, muss man sich in festen Geistersilhouetten verstecken, zwischen ihnen hin- und herwechseln wenn die Gegner diese prüfen und dann abwarten, bis die Dämonen die Suche aufgeben. Scheitert das Verstecken geht es zum letzten Checkpoint.
Quicktimeevents gibt es auch wenn ihr auf einen Höllenschlund tritt. Bei einem Scheitern geht es hier direkt zurück zum letzten Checkpoint, der zum Glück meist sehr nah ist.
Diese Mechaniken empfand ich eher als nervig denn als spannend, vor allem die Dämonen. Einmal erwischt dann schon wieder warten zu müssen ist einfach nicht spaßig. Gleichzeitig sind die Quicktimeevents im Grunde zu einfach. Entweder hätte es da ein anderes Kampfsystem geben sollen, oder gar keins (ein Entdecken den direkten Tod bedeuten), oder die Dämonen einfach nicht im Spiel sein sollen.
Fazit
Das Rumwarten bei den Dämonen wird nervig, aber der Rest des Spiels nicht. Dafür ist es zu kurz und größtenteils zu kompetent gemacht, sodass es ein unterhaltsames Spiel bleibt. Nur selten funktionieren die Rätsel einfach nicht, dann ist der eine fehlende Hinweis nur durch Zufall zu entdecken. Beispielsweise muss einmal nach Entdecken von anderen Hinweisen die Gedanken eines Zeugen gelesen werden, dessen Gedanken man aber schon vorher lesen konnte und der da nur belangloses von sich gab. Darauf konnte man nicht kommen. Auch bei den in den Leveln verteilten (und belanglosen) Sammelobjekten haben die Entwickler danebengegriffen – fast in jedem Level war genau eines unauffindbar.
Die Grafik ist nicht beeindruckend, und wohl thematisch passend sind die Szenen sowieso leider immer dunkel. Dafür läuft das Spiel auch mit schwacher Hardware stabil und gut, und hässlich sieht es nun auch nicht aus.
Insgesamt wirkt Murdered: Soul Suspect (das von 2014 ist) wie eines dieser selten gewordenen Mid-Budget-Spiele. Nicht Indie, nicht AAA; nicht schlecht, aber auch nicht herausragend. Ist es per Bundle schon in der Spielesammlung ist es durchaus spielenswert, mehr noch wenn man Lust auf ein Detektivspiel hat, dann darf man sogar bei einem Sale zugreifen. Nur zu hohe Erwartungen sollte man dabei nicht haben.