onli blogging

Gestern war ich auf der Froscon. Nur kurz, es reichte für zwei Talks: Einmal eine nette kleine Einführung in node-red (was mich aufgrund von Pipes interessierte), dann noch in den englischen Let's talk about Desktop Linux Platform Issues. Ich ging da mit gemischten Gefühlen raus: Die Diskussion am Ende funktionierte nicht, aber der Sprecher wirkte nett und ehrlich an der Verbesserung von Linux interessiert. Er präsentierte AppImage als mögliche Lösung. Zwar weiß ich nicht, ob das Verfügbarmachen von Software per Binaries wirklich das große Problem des Linux-Desktops ist. Andererseits ist das Verteilen von Software unter Linux ja wirklich nicht so einfach wie es sein soll. Ich markierte mir also AppImage als Möglichkeit dazu vor.

Heute stolperte ich via Thomas über Please stop making the library situation worse with attempts to fix it. Im Artikel geht es nicht wirklich darum, dass AppImage und die anderen Versuche alles schlimmer machen würden, sondern darum, dass AppImage nicht richtig funktioniere. Bei aller (bewusst) zur Schau gestellten Naivität des Sprechers probono im Vortrag: Damit hatte ich nach der guten Darstellung nun nicht gerechnet. Also wollte ich mir das schon jetzt einmal selbst anschauen.

Mein Beispielprogramm ist simdock. Dem Programm könnte die Verteilung als AppImage helfen, es ist ein ziemlich gutes Dock, mit meiner Nischendistro fällt es mir aber schwer, es ordentlich für Ubuntu etc. zu verpacken. Ausgangssituation: Es gibt ein Github-Repo mit dem Quellcode, dort liegt auch ein debian-Ordner mit dem ganzen Boilerplate zum Bauen des .debs, zusätzlich gibt es ein ppa. Das Makefile ist simpel und listet alle Abhängigkeiten, sauber mit pkg-config. Es gibt sogar ein PKGBUILD im AUR. Einen besseren Kandidat für AppImage dürfte es nicht geben.

Hier ist die Anleitung. Es werden sechs Wege gezeigt:

1. Nutze den Open Build Service (OBS)
2. Konvertiere bestehende Binärpakete
3. Travis CI builds wiederverwenden
4. linuxdeployqt für Qt-Anwendungen
5. electron-builder
6. Ein AppDir erstellen

Nur eins oder zwei kann ich mir vorstellen. Travis CI benutzt simdock nicht. Simdock ist auch keine Qt-Anwendung. Electron passt sicher auch nicht, wir sind am anderen Ende des Stacks. Ein AppDir manuell zu erstellen wäre zum einen dauerhafte zusätzliche Arbeit (und die Aktion soll mich ja auf Dauer entlasten, nicht belasten), die Anleitung existiert aber auch nicht. Sie sei verschoben nach https://github.com/AppImage/docs.appimage.org/blob/master/source/packaging-guide/manual.md, das wirft einen 404. Wenn ich mich aber nicht vertue müsste ich dafür Binärpakete des Programms und der Abhängigkeiten von einer möglichst alten Distribution wie Ubuntu 14.04 besorgen, das wäre keine Option.

Der Verweis zu OBS führt mich zu https://github.com/AppImage/AppImageKit/wiki/Using-Open-Build-Service. Dort steht auch, dass Inhalt verschoben wurde, nach https://github.com/AppImage/docs.appimage.org/blob/master/packaging-guide/obs.md. Aber das ist auch nur ein weiterer 404. Immerhin, der Link zum OBS-Buildservice führt mich auf diese Seite:

Aber das hilft mir nicht viel. Es ist mir überhaupt nicht ersichtlich, was ich dort tun kann. New Image vielleicht, obwohl ich nicht damit gerechnet hätte, dass die Funktion im OBS schon so heißt, und obwohl das Icon nicht wie der primäre Button der Seite aussieht. Dort kann ich dann auch tatsächlich AppImage als Template(?) auswählen, und unten meiner Appliance (ich dachte ich erstelle ein Image?) einen Namen geben. Der Button unten Create Appliance bleibt aber weiterhin ausgegraut. Das funktioniert also gar nicht.

Und ich glaube, ich scheiterte vor Jahren schon einmal an OBS, daran dass die Webseite einfach völlig kaputt war. Ich glaube das war, als ich dann stattdessen auf Launchpad ein PPA für simdock erstellte.

Bleibt der zweite Weg: Das Erstellen eines AppImages über das bestehende Paket. Da ich ein ppa mit .debs habe sollte das ja auch der einfachste Weg sein. Tatsächlich führt mich die Anleitung aber nur zu einem Bash-Script, ohne Erklärung wie es zu benutzen ist. Und zu Beispielen von yaml-Dateien, mit denen man wohl das Skript konfiguriert. Hier das von Geany, das sieht immerhin einfach aus und benutzt ein PPA. In dem Repo gibt es dann auch doch noch ein Beispiel dafür, wie man das Skript benutzt:

bash -ex ./pkg2appimage recipes/XXX.yml

Also habe ich das Geany-yaml genommen, auf simdock umgebogen, und den obigen Befehl ausgeführt. Das war das Ende der Ausgabe:

++ grep -e '^http'
./pkg2appimage: line 250: apt-get: command not found
+ URLS=

Das kann nicht gehen, ich habe weder Debian noch Ubuntu auf dem Rechner, natürlich findet es apt-get nicht.

Meine versuchte Erstellung eines AppImage für simdock war zu diesem Zeitpunk also erstmal gescheitert.

Warum das Steckenbleiben an diesem Punkt schade wäre

Bei seinem Vortrag hat probono viel davon geredet, dass Windows und MacOS eine Sache besser machen als Linux: Dort ist das Betriebssystem eine relativ stabile Plattform, sodass einmal darauf ausgelegt Programme fast dauerhaft dort laufen. Unter Linux dagegen müssen Programme sich immer wieder der sich ändernden Umgebung anpassen, vor allem, wenn ihr Quellcode nicht verfügbar ist (aber nicht ausschließlich nur dann, wie ich auch selbst mit simdock mehrfach schon erfahren musste). AppImage will das ändern, es ist als Erleichterung für Anwendungsentwickler gedacht. Aber in meiner Erfahrung funktioniert genau das eben nicht: AppImage erfordert von mir viel Arbeit, und es sieht absolut nicht einfach aus. Wo ist der Service, der ein Git-Repo nimmt, die Abhängigkeiten aus dem Makefile zieht, das Programm kompiliert und das Ergebnis als Makefile verpackt?
Stattdessen war ausgerechnet der klassische Weg in manche Distros einfach: Um das Programm nach Arch zu bringen musste ich gar nichts machen, ein Nutzer erstellte das PKGBUILD. Bei izulu – einem anderen Programm von mir – war es auch ein Nutzer, der es nach AUR packte. Ich weiß, dass es sehr einfach ist, für Gentoo ein overlay zu erstellen und es so verfügbar zu machen. Nur in die großen Distros komme ich mangels Popularität des Programms nicht, ohne mir Unmengen an Arbeit aufzuhalsen. Das Problem liegt also vor allem an Distributionen wie Debian, bei denen ich den Maintainer spielen müsste und zudem als Bittsteller auftreten würde, um in das Repository zu kommen.

Deswegen ist die Komplexität hinter AppImage schade: Ich würde mit sehr gerne davon helfen lassen, dann über AppImage wie per AUR meine Pakete in Distros verteilen können. AppImage scheint dafür aber derzeit der falsche Weg zu sein. Vielleicht liegt das an dem Fokus auf Binärpakete. Die zu vereinfachen, das scheint das große Ziel zu sein. Dafür will es Stabilität in den Library-Wirrwarr zu bringen, der im Vortrag auch sehr überzeugend gezeigt wurde. Meiner Erfahrung nach aber funktioniert in der Praxis aber nur der umgekehrte Ansatz: Mache es einfach, Quellcode zu kompilieren und direkt in die Distrospezifischen Pakete zu verpacken. Das erschlägt dann ebenfalls den Library-Dschungel, weil einfach immer der Quellcode entsprechend neu kompiliert wird.

Travis CI zur Rettung

Bevor ich diesen Artikel veröffentlichte habe ich mit den Leuten von AppImage Kontakt aufgenommen. Der einfachste Weg ging wohl an mir vorbei: Travis CI. Es ist einfacher als ich dachte bei jedem Commit den Kompilierungsvorgang zu starten, und AppImage kann sich hier reinhängen. Dann wird bei jedem Commit nicht nur automatisch das Programm erstellt, sondern auch das AppImage. Ich glaube allerdings nicht, dass ich ohne weitere Hilfe zurechtgekommen wäre, denn die Dokumentation ist auch dafür schwach (dafür weiß ich jetzt, dass eine neue Dokumentation gerade aufgebaut wird). Diese .travis.yml war der Startpunkt für Simdock:

language: cpp
compiler: gcc
sudo: require
dist: trusty

install:
  - sudo apt-get -y install pkg-config libglib2.0-dev libgconf2-dev libgtk2.0-dev libwnck-dev libwxgtk3.0-dev libxcb1-dev libxcb-ewmh-dev xcb-proto librsvg2-dev

script:
  - make -j$(nproc)
  - make install DESTDIR=$(readlink -f appdir) ; find appdir/
  - mkdir appdir/usr/share/applications/ ; cp simdock.desktop appdir/usr/share/applications/
  - mkdir appdir/usr/share/icons/hicolor/256x256/apps ; touch appdir/usr/share/icons/hicolor/256x256/apps/simdock.png # FIXME
  - wget -c -nv "https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage"
  - chmod a+x linuxdeployqt-continuous-x86_64.AppImage
  - unset QTDIR; unset QT_PLUGIN_PATH ; unset LD_LIBRARY_PATH
  - export VERSION=$(git rev-parse --short HEAD) # linuxdeployqt uses this for naming the file
  - ./linuxdeployqt-continuous-x86_64.AppImage appdir/usr/share/applications/*.desktop -appimage

after_success:
  - find appdir -executable -type f -exec ldd {} \; | grep " => /usr" | cut -d " " -f 2-3 | sort | uniq
  - bash upload.sh Simdock.AppImage
  
branches:
  except:
    - # Do not build tags that we create when we upload to GitHub Releases
- /^(?i:continuous)/

Ich glaube, hier muss das Projekt noch arbeiten: Erstens die Dokumentation dafür verbessern, und zweitens vielleicht auch einen Weg finden, diese Integration mit weniger Code umzusetzen. Denn als Lösung ist dies ja nahezu perfekt: Sich in Travis CI zu integrieren bedeutet, sich in den Github/Gitlab-Entwicklungsflow zu integrieren. Läuft das einmal muss der Entwickler darauf kaum noch achten und es werden trotzdem immer aktuelle AppImages für das Projekt erstellt. Aber es ist noch ein bisschen viel Voodoo.

Nun rödelt Travis, die Warteschlange ist gerade voll. Wahrscheinlich kommt aus dieser Aktion aber ein funktionierendes AppImage für simdock heraus. Ich bin gespannt, ob das Programm dann auch tatsächlich funktioniert. Unter Ubuntu 14.04 habe ich es lange nicht getestet, und das wäre hier die Basis.

Es hat sich gezeigt, dass die Technik selbst funktioniert. Aber dass das Projekt noch an seiner Dokumentation arbeiten muss. Die notwendigen Kompetenzen um AppImage als Lösung zu etablieren scheinen definitiv vorhanden zu sein. Ich drücke die Daumen, und versuche mein AppImage für simdock beizubehalten.

Valve hat heute die Beta von Proton aktiviert (via). Proton ist ein (ebenfalls freier) Port von Wine und nutzt dazu DXVK, es ist also eine Software, mit der man Windowsanwendungen unter Linux starten kann. Bisher war es ja so, dass nur Linux-Ports mit Steam installierbar waren. Nicht alle waren echte Ports, man denke an Witcher 2. Aber es waren dedizierte Linuxversionen, wovon es deutlich weniger als reine Windowsspiele gibt.

Proton wird diese Situation ändern, da durch diese Software auch reine Windows-Spiele unter Linux laufen. Das wird nicht mit jedem Spiel funktionieren, und dass die so behandelten Spiele schneller als unter Windows laufen wird auch nicht die Regeln sein. Aber es vergrößert die Spielauswahl unter Linux, potentiell enorm. Noch dazu soll gerade DXVK hervorragend funktionieren. Ich habe es noch nicht selbst getestet, aber die Berichte über damit laufende Spiele waren beeindruckend.

Proton wird nicht auf gut Glück für alle Windowsspiele aktiviert, sondern Valve hat einige Spiele ausgewählt. Das ist die Anfangsauswahl:

Ich sage seit Jahren: Damit Linux auf dem Desktop gegen Windows bestehen kann braucht es Unterstützung für die kommerziellen Computerspiele. Es ist einer der zwei fehlenden Bausteine (der zweite ist arbeitsrelevante Software wie Adobe Photoshop, aber dort sind die freien Alternativen inzwischen hervorragend) für den Desktop. Seitdem hat sich viel getan, es gibt für Pinguinfans eine echte und gute Spieleauswahl. Genug, um Spielern und Linuxern wie mir Windows vollständig zu ersparen. Aber die größte Gruppe an überzeugten Computernutzern sind die Core-Gamer, und für die ist ein fehlendes Call of Duty, Battlefield oder was auch immer gerade angesagt ist ein zu großes Manko, um sich Windows zu sparen.

Natürlich: Wine gibt es schon länger. Und DXVK, das DirectX zu Vulkan umwandelt und so unter Linux lauffähig macht, funktioniert auch außerhalb Steams. Aber erstens hat Valve hier in die Entwicklung investiert, zweitens ist all das nur durch den von Valve getriebenen Push zu besseren Treibern möglich. Und drittens und vor allem geht es nicht nur darum, Spiele mit Arbeit und nur eventuell zum Laufen zu bringen. Sondern es muss komfortabel und zuverlässig funktionieren. Genau das kann die Steamintegration bewirken.

Der Rest des enormen Spielekatalogs soll später getestet und Spiele wo möglich aktiviert werden. Wenn das klappt wie erhofft, wird das eine große Erleichterung für Spielefreunde unter Linux bringen. Und dem Linux-Desktop mittelfristig einen wesentlich größeren Marktanteil.

Kleiner Verweis: Im Blog von pc-kombo habe ich einen Artikel geschrieben, den ich sonst hier ins Blog getan hätte:

Heute mal etwas anderes: Ich bespreche einen Build für einen kleinen Heimserver, warum genau diese Komponenten gewählt wurden und welche Alternativen es gibt.

Szenario

Der Server ist nicht für mich, sondern für jemanden, dessen alter Heimserver kaputtgegangen ist. Der war andauernd im Gebrauch, 24 Stunden am Tag. Die 3.5”-Festplatte soll wiederverwendet werden. Auf dem Server wird Linux laufen, und er soll möglichst klein, energiesparsam und leise sein.

Ein paar von euch könnten erraten, für wen der Server sein wird. Und vielleicht sind die Überlegungen zur Komponentenauswahl auch für den ein oder anderen hier interessant.

Ich für meinen Teil bin auf den fertigen Build gespannt. Drückt die Daumen.

Die Anweisung mesa_glthread=true kann man dem Startbefehl eines Spiels voranstellen, um OpenGL-Multithreading zu aktivieren. In manchen Spielen bringt das einen starken Geschwindigkeitsvorteil, besonders wenn der Prozessor der Flaschenhals ist. Ich fragte mich, ob auch Mankind Divided davon profitieren würde. Dem war nicht so:

Zumindest auf meinem System war das Ergebnis eindeutig. Das Spiel verliert in jeder Kategorie mehrere FPS, die Funktion zu aktivieren wäre also eine blöde Idee. Das war in Hitman und Stellaris noch anders.

Es dauerte lange, bis ich Mankind Divided spielen konnte. Erst war es mir zu teuer, dann lief es nicht auf meinem System – der Linux-Port hat eine SSE-Abhängigkeit, die Phenoms disqualifiziert. Ich war aber auch gar nicht zu sehr an dem Spiel interessiert: Zu kontrovers war der Launch mit seinen schlecht gemachten Abzocker-DLCs, aber auch die Kritik an Story und Spieldesign war nicht gerade einladend.

Das letzte Deus Ex ist aber doch ein gutes Spiel geworden.

Sicher, es hat einige Macken, und ich werde mit ihnen anfangen. Viele der Grundprobleme waren schon in Human Revolution, treten aber im neuen Teil voll zutage. Da wäre zum Beispiel die Hintergrundstory. In Human Revolution war der Spalt in der Gesellschaft noch halbwegs nachvollziehbar, aber vor allem die Begeisterung für Augmentierungen war unrealistisch. Kann sich jemand wirklich vorstellen, dass in zehn Jahren große Teile der Gesellschaft sich freiwillig Arme und Beine abhacken und mit mechanischen Geräten ersetzen? Und dann noch für immer von einer teuren Droge abhängig sind? In Mankind Divided ist die Stimmung gegen Augmentierungen gekippt und dieser Aspekt des Spielweltuniversums ausgeblendet, stattdessen ist die Gesellschaft noch gespaltener. Das wird übertrieben, das Verhältnis der Gesellschaft zu Augmentierten ist so offensichtlich eine Analogie für Rassismus, samt Apartheid und Segregation, dass es nur in ganz wenigen Momenten realistisch wirkt. Warum machen die neue Spiele das so viel schlechter als der erste Teil mit seinen einfachen und doch schlüssigen Verschwörungstheorien?

Es hakt auch etwas an der Spielerführung. Mankind Divided spielt zum größten Teil in Prag. Die Stadt ist in Sektoren aufgeteilt, verbunden mit der Metro, mit ziemlich langen Ladezeiten. Eigentlich ist Prag gut gemacht: Mehr noch als in den Stadt-Hubs des Vorgängers sind hier viele Nebenquests, Händler und Geschehnisse verteilt. Der Spieler sollte also viel Zeit damit verbringen, all das zu entdecken. Stattdessen aber drängt das Spiel über die Hauptstory dazu, genau das eben nicht zu tun, sondern schnellstmöglich die Verschwörung aufzudecken. Gerade am Anfang überfordert das völlig, wenn erst die Augmentierungen nicht funktionieren, dann korrupte Polizisten den Hintereingang zum Reperaturort blockieren und so die Erledigung eines Nebenquests erzwingen, und gleichzeitig Miller – der neue Chef – über das Interlink mehrfach befiehlt endlich auf der Arbeit aufzutauchen. Er hört dann zwar mit einem "Okay, komm wenn du kannst" damit auf, aber eine richtige Atempause um den Nebenquests zu folgen gibt das Spiel nicht. Die muss der Spieler sich nehmen und dafür negative Konsequenzen befürchten.

Außerdem sind viele Aspekte der Story sind völlig vorhersehbar. Natürlich stimmt mit der Psychologin was nicht, deren Charaktermodell besonders hübsch ist und die einfach zu nett mit Jensen redet. Immerhin merkt der das zwischendurch selbst. Aber warum kann ich dann das nächste Gespräch mit ihr nicht entsprechend schroff führen, sie abweisen und ignorieren?

Nebenbei: Die Psychologin ist vor allem deshalb wahrnehmbar hübsch, weil viele andere Personen komisch aussehen. Die Gesichter auch, aber vor allem die Körperformen. Besonders bei leichtbekleideten Frauen ist auffällig, dass da mit den Brüsten und der ganzen Körperform etwas nicht stimmt. Davon abgesehen ist die Grafik gut, aber das Spiel fordert viel zu viel Leistung von Prozessor und Grafikkarte. So gut ist die Grafik dann doch nicht, zumindest nicht auf den Einstellungen die mein System schafft. Witcher und Human Revolution (unter Windows zumindest) machten das besser.

Nochmal zur Vorhersehbarkeit. Es gibt einen Nebenquest, in dem eine Frau ermordet und ihre Augmentierungen entfernt wurden. Nach zwei Minuten mit der Zeugin sage ich mir "Mit der stimmt was nicht, sie ist sicher der Mörder." Direkt danach wird ein Serienmörder mit Augmentierungen ins Spiel gebracht, der aber im Gefängnis gestorben ist. "Über Augmentierungen lebt der Mörder in der vermeintlichen Zeugin weiter", sage ich mir. Natürlich war es dann auch praktisch genau so. Manchmal kann so etwas okay sein, wenn der Spieler dann auch entsprechend der Offensichtlichkeit handeln kann, man denke an den bombenlegenden Mechaniker im ersten Deus Ex. Hier aber musste dann noch Unmengen erledigt werden: Eine Polizeistation durchsuchen (samt verräterischen Emails der psychisch instabilen Frau, die unkommentiert bleiben), zwei andere Verdächtige entlasten, den Quest erstmal abhaken, dann später ihre Wohnung durchsuchen, mit einem an den Experimenten beteiligten Psychologen reden, in die Kanalisation steigen und dann den Quest auf einem von drei verschiedenen Wegen beenden. All das, obwohl nach zwei Minuten die Sache völlig klar war.

Es hilft auch nicht, wenn im Ladebildschirm mir Eigenschaften von Personen verraten werden, die erst kurz darauf in der Handlung eine wichtige Rolle spielen werden, und diese Eigenschaft offensichtlich eine Überraschung sein sollte. So passiert beispielsweise bei der Identität der Mutter des Maschinengott-Kultes.

Und doch hat mir Mankind Divided viel Spaß gemacht. Vor allem liegt das an den vielen Lösungsmöglichkeiten. Das macht es eigentlich noch besser als die beiden Vorgänger (und auch besser als der Konsolenfork Invisible War). Schleichend, hackend, schießend, durch Gespräche – die Quests lassen wirklich immer viele Lösungsmöglichkeiten zu. Die Spielwelt ist hervorragend darauf ausgelegt, alle möglichen Spielstile und aktivierten Augmentierungen zu unterstützen, ohne dass die alternativen Wege zu künstlich platziert wirken. Nichtmal die Bosskämpfe ändern daran etwas, denn sie können alle ohne tödliche Gewalt gelöst, alle sogar umgangen werden. So war direkt mein erster Spieldurchlauf pazifistisch. Mankind Divided ist das erste Deus Ex, das diese Spielstilfreiheit direkt richtig macht!

Adam Jensen hat eine Reihe neuer möglicher Augmentierungen. Ich fand sie teilweise etwas redundant: Jetzt gibt es eben zwei Schilde, und mehrere Möglichkeiten ohne Waffen aus der Ferne Gegner auszuschalten. Aber es sind auch ein paar nette Ideen darunter, wie der Dash. Insgesamt fand ich die Augmentierungen wieder ziemlich cool, sie geben durch die gute Unterstützung des Leveldesigns dem Spieler irre viele Möglichkeiten. Gerade im Vergleich zum ersten Teil hat sich die Serie hier sehr gut entwickelt, als viele der Augmentierungen noch nutzlos waren. Und so schafft es das Spiel wunderbar, dass der Spieler langsam immer mächtiger wird – sogar wenn man wie in meinem Fall gar nicht kämpft.

Mir hat auch die Hauptstory gefallen. Trotz den oben erwähnten Plausibilitätsproblemen des Szenarios ist die Geschichte selbst spannend, die Verschwörung mysteriös und fesselnd genug. Besonders die Rolle Jensens in TF29 und seine Verbindung zum Juggernaut-Kollektiv ist interessant und passt wunderbar zu Deus Ex. Der Kniff im Abspann lässt da auch für den Nachfolger hoffen, auf dass der große Storyrahmen noch richtig spannend wird. Ich hatte auch kein Problem mit dem Punkt, an dem das Spiel aufhört. Vielen ist wohl das Ende übel aufgestoßen, denn anders als in den Vorgängern gibt es bei Mankind Divided noch einige klar gestellte, aber ungelöste Fragen. Doch ich fand das okay, denn die erlebte Story ist eine komplette Geschichte mit spannendem Anfang und zufriedenstellendem Ende. Dass da offensichtlich noch mehr kommen soll verleidet mir das nicht. Das würde ich vielleicht etwas anders sehen wenn es wirklich keinen Nachfolger geben sollte, aber diese Gerüchte waren glücklicherweise wohl falsch – eigentlich offensichtlich, wer würde so doof sein und eine so beliebte und auch kommerziell erfolgreiche Spieleserie nicht weiterführen wollen.

Technisch bin ich mit der Linuxversion nicht ganz zufrieden. Es ist zwar an sich schon toll, dass ein solches AAA-Spiel unter Linux läuft. Ohne Grafikfehler, ohne Pulseaudio-Abhängigkeit, mit funktionierendem Sound. Aber dass es mit Phenoms nicht startet ist eigentlich inakzeptabel, diese alten 6-Kern-Prozessoren sind gerade in Spielen kaum schwächer als die FX-Prozessoren, die ja durchaus unterstützt werden. Ich hatte gelegentlich Abstürze, manchmal frierte das Bild ein. Alle Ladezeiten sind zu lang, besonders der erste Start, aber auch das Wechseln des Stadtgebietes per Metro (und dabei war es schon auf einer schnellen SSD installiert). Die FPS könnten besser sein. Meine Hardware ist wohl etwas zu alt für das Spiel, das muss ich akzeptieren, finde aber, dass dafür die Grafik nicht ausreichend gut aussieht. Wahrscheinlich haben die Entwickler hier einfach kompliziertere und vollgepacktere große Gebiete umgesetzt, die in Human Revolution so noch nicht möglich waren – wobei die höheren Einstellungen doch wirklich deutlich besser aussehen als der Vorgänger, der das nur mit seinem Goldschleier etwas kaschierte.

Mankind Divided ist ein gutes Deus Ex geworden. Viele Handlungsmöglichkeiten, gute Story, interessante Charaktere. Ich habe es jetzt nochmal angespielt und muss sagen, dass auch der Shooter-Teil des Spiels gut geworden ist, den ich ja in meinem ersten Stealth-Durchlauf nicht erlebt habe. Natürlich kann es den ersten Teil nicht erreichen, und es hat nicht alle Stärken seines direkten Vorgängers, wie den einzigartigen visuellen Stil. Aber es hat seine eigenen Stärken, zu denen ich sogar die Handlung zählen würde, auf jeden Fall aber die Auflistung der Konsequenzen der eigenen Entscheidungen am Ende, die Unterstützung verschiedener Spielstile, das vollgepackte Prag mit seinen Nebenquests. Am Ende überzeugte mich besonders die finale Mission, die im Grunde Jensen als klassischen Geheimagenten einsetzt, was hervorragend zu Deus Ex passt und doch noch nie in der Serie umgesetzt wurde.
Mankind Divided bietet Fans der Serie also richtig viel. Du solltest es spielen.

Ich habe Planescape: Torment vor vielen Jahren durchgespielt, nachdem ich mich von der Idee verabschiedet hatte, ausgerechnet dieses textlastige Spiel als Übung auf Französisch zu spielen. Ich erinnere mich vage an die Story um den namenlosen Unsterblichen, an den fliegenden Skelettschädel. In meiner Erinnerung war das Kampfsystem schwach, es gab wirklich sehr viele Text, ich hörte nebenbei Metal und die Geschichte in diesem sehr anderem Universum war irritierend, besonders das Ende.

Torment: Tides of Numenera ist ein spiritueller Nachfolger zu Planescape: Torment. Hat der Nachfolger schon einen sehr seltsamen Namen, stiftet noch etwas zur Verwirrung bei: Fast gleichzeitig mit dem spirituellen Nachfolger wurde der Vorgänger in einer überarbeiteten Version neu aufgelegt. Sehr viel Interesse also für dieses alte Rollenspiel, das zwar als eines der Genregrößen gilt, aber schon damals verwirrend und wenig zugänglich war. Und doch ist es wohl eine der besseren Vorlagen für diese Renaissance der Computer-Rollenspiele.

Tides of Numeneria nimmt viel von dem Vorgänger auf. Der Hauptcharakter ist kein gewöhnlicher Spielecharakter, die Begleiter sind etwas absurder als in anderen Rollenspielen, es gibt mehr Texte und Entscheidungen als üblich. Besonders aber ist es eben noch ein Spiel alter Schule: Praktisch 2D und so weit wie möglich entfernt von den actionlastigen modernen RPGs wie Mass Effect.

Wieder ist der Spielercharakter ein Gotteskind und beginnt ohne Erinnerung, nachdem er (oder sie) gestorben ist. Diesmal aber stürzte er vom Himmel. Man begegnet nach dem Aufwachen direkt zwei möglichen Begleitern und startet mit dem ersten Quest im Logbuch.
Typisch für das Spiel ist die Folgesituation: Schatzsucher kommen angerannt, angelockt vom Himmelssturz. Die kann man nun im rundenbasierten Kampf ausschalten, dabei die in der Umgebung verteilten Artefakte nutzen. Alternativ lügt man sie an, überzeugt sie so, dass der Schatz in einem anderen Bereich der Karte ist. Oder man schüchtert sie ein. Für diese Gesprächsfähigkeiten können die drei Fähigkeitspools – Macht, Geschwindigkeit, Intelligenz – genutzt werden, die sich so aber auch bis zur nächsten Rast verbrauchen. Auch in Kämpfen werden diese Pools benutzt, selbst zum Aufladen normaler Schläge, man sollte also gut haushalten.

Das Verhalten in Gesprächen bestimmt auch das Karma. Da gibt es nicht gut oder böse, sondern mehrere farbkodierte Ausprägungen, von denen zwei zugleich aktiv sein können. So steht Gold für Selbstlosigkeit, Silber für Standesbewusstsein, Blau für Interesse an Wissen. Auf dieses Karma reagieren die anderen Menschen und es gibt einen Begleiter, der sogar darüber Boni auswählt. Zudem können in manchen Gesprächen bestimmte Optionen nur Dank des richtigen aktiven Karmas gewählt werden. Doch leider erklärt das Spiel das Karmasystem schlecht und zeigt nur selten seinen Einfluss, wodurch die Funktion schwächer ausgebaut wirkt als sie eigentlich ist.

Es ist ein echtes Rollenspiel, also gibt es Erfahrungspunkte und Levelaufstiege. So kann der Charakter stark spezialisiert werden, auf Kampffertigkeiten oder einem defensiverem Spielstil. Das entscheidet auch mit welchem Fähigkeitspool er hauptsächlich arbeitet. Kämpfe können oft vermieden werden, ich glaube aber nicht immer; das zu widerlegen und pazifistisch zu spielen wäre vielleicht eine interessante Herausforderung.

Typisch: Es gibt ein Artefakt, mit dem Gedanken lesbar werden und so andere Gesprächsoptionen möglich sind. Versteckt ist das im letzten Spielabschnitt bei einem einzigen Händler. In einem normaleren Rollenspiel wäre so etwas Teil der regulären Fähigkeiten, man denke an den Gesprächsanalysator per Implantat in Deus Ex: Human Revolution. Numenera dagegen versteckt so etwas zum Spielende in einem abgelegenen Winkel. Auch andere Boni sind immer wieder in der Spielwelt verteilt, gerade Attributssteigerungen nicht auf das Aufleveln beschränkt. Das ist so seltsam irregulär wie der Vorgänger und lockert das Spiel auf, macht es aber auch nicht gerade zugänglicher.

Die Hauptstory hat mir gut gefallen. Ohne zuviel verraten zu wollen: Der vermeintliche Schöpfer des Protagonisten spielt noch eine wichtige Rolle und es gilt große Entscheidungen zu treffen, welche die ganze Welt beeinflussen werden. Diese Geschichte wird direkt am Anfang eingeführt und verliert sich auch nicht im Spielverlauf. In der Hinsicht ähnelt es Pillars of Eternity, mit dessen Engine das Spiel auch umgesetzt wurde. Leider teilt es sich dabei dessen Problem: Für eine so episch angelegte Story sind die 26 Stunden Spielzeit zu kurz. Zu dem Zeitpunkt lebt der Spieler noch nicht völlig in dieser Welt. Wobei Numenera doch sehr viel richtig macht, um den Spieler trotz der relativen Kürze so stark wie möglich in die Spielwelt eintauchen zu lassen.

Ein Teil davon und sehr schön gelungen sind manche der Nebenquests und auch die Hintergrundgeschichten der Begleiter. Eine will ich teilweise erzählen: Die von Erritis. Den von einem goldenen Schimmer umgebene Kämpfer findet man in der Stadt neben einem abgestürzten Luftschiff, was absolute Verwunderung auslöst, denn die Dinger seien nahezu unmöglich zum Absturz zu bringen. Erritis stürzt sich in jeden Kampf, aber was die Realität und was Gefahren sind scheint er nicht zu überblicken. In mehreren Situationen kann er den Tod der Gruppe verursachen, in dem er die dümmstmöglichste Aktion wählt, dann muss man neu Laden. Er scheint von etwas getrieben zu sein, wovon wird man natürlich wird im Laufe der Geschichte erfahren.

Numenera lebt auch von solchen Geschichten und von seiner ungewöhnlichen Hintergrundgeschichte. Die Welt ist nicht einfach eine magische, sondern eigentlich eine SciFi-Welt. In der aber sind so viele Zivilisationen vergangen, dass die verbliebenen Artefakte wie Magie wirken – und es gibt auch Effekte, die im Kanon der Welt magisch sind, nicht technisch, aber oft ist das gar nicht klar entscheidbar. Die Spielwelt ist über diesen riesigen Hintergrund von vielen vergangenen und auch parallel noch bestehenden Zivilisationen aufgebaut, was viele ungewöhnliche Szenarien erlaubt. Das Spiel hat so angenehmerweise keinen Grund, auf die Klischees der Hochfantasie mit edlen Elfen in Wäldern und bösen Orks zurückzugreifen.

Ich habe Tides of Numenera sehr gerne gespielt. Vielleicht spiele ich es sogar nochmal, um die Auswirkungen alternativer Handlungen zu sehen. Die Linuxversion lief an sich hervorragend, nur der Sound hatte ein Knattern, das scheint aber kein übliches Problem zu sein. Die Karten sehen wieder hübsch aus und es ist ein fesselndes Rollenspiel geworden, das sehr viele verschiedene Möglichkeiten bietet. Selbst die Kämpfe fand ich gut gelungen, sie sind gewinnbar und doch fordernd, mit den Fähigkeiten der Charakteren sind sie kein stumpfes Hauen und Stechen, aber es wird auch nicht übermäßig komplex.
Ich verstehe aber auch, dass Tides of Numenera nicht jedem gefallen kann: Zu absonderlich ist die Welt, zu altbacken der Spielablauf, und wie bei Pillars of Eternity fehlt da noch etwas, um die Großen des Genres zu erreichen. Aber keinesfalls ist es schlecht. Es sei hiermit jedem empfohlen, der gerne noch ein neues klassisches Computer-Rollenspiel erleben will. Diesmal in einem etwas anderen Universum.

Eines der besten Upgrades für einen älteren PC ist der Wechsel von einer mechanischen Festplatte auf eine Solid State Drive. SSDs sind teurer als HDDs, aber sie haben einige Vorteile: Sie unterstützten schnellere Datentransfers, sie haben eine bessere Latenz und da sie digital funktionieren sind sie komplett lautlos. Schon vor einigen Jahren (wobei ich scheinbar nie darüber geschrieben habe) gönnte ich meinem System eine 120GB SSD als Upgrade und nutzte sie als / für Linux. Der Effekt war enorm: Alles startete schneller, besonders Firefox, das ganze System fühlte sich responsiver an, Ladezeiten in Spielen waren kürzer. Dass sich das System schneller anfühlt ist vor allem der Effekt der besseren Latenz.

120GB sind aber auf Dauer etwas wenig. Doch glücklicherweise sind SSDs so günstig wie nie. Ihre Preisentwicklung ist generell interessant. Sie waren erst sehr teuer, wurden dann aber konstant günstiger. Bis dann letztes Jahr zusammen mit den Rampreisen der Preis enorm anstieg. Jetzt aber sind die Preise wieder über einen längeren Zeitraum gefallen. Es ist unklar, ob das so weitergeht: Wahrscheinlich ist wohl, dass sich die Preise etwas stabilisieren werden. Man kann nicht sicher sein, aber vielleicht ist jetzt ein guter Moment um eine größere – oder gar die erste – SSD zu kaufen!

Es gibt verschiedene Protokolle, Geschwindigkeiten und Formgrößen, aus denen man das passende auswählen muss. Zum Glück ist es nicht wirklich kompliziert.

NVMe

Oben stehen die NVMe SSDs wie die Samsung 970 Evo. NVMe ist der Nachfolger von SATA, das schon früher für Festplatten genutzte Protokoll. Der neue Standard unterstützt schnellere Datentransferraten und verbessert nochmal die Latenz. Allerdings bestimmt vor allem die Latenz die gefühlte Geschwindigkeit bei der Alltagsnutzung, und da ist der Sprung längst nicht mehr so groß wie der von einer Festplatte zu einer SSD. NVMe SSDs kommen normalerweise im M.2 Formfaktor, moderne Motherboard haben dafür ein oder zwei Anschlüsse.

Moderne SATA-SSDs

Dann gibt es die modernen SATA-SSDs. Sie sind langsamer als die NVMe SSDs, aber auch günstiger. Ihre Latenz ist wie erwähnt immer noch sehr viel besser als die von Festplatten. Es gibt sie in beiden Formen: Im gewöhnlichen 2.5"-Format für den Festplattenkäfig, oder als moderne M.2-Riegel. 2.5" brauchen Strom und SATA-Kabel und sind daher etwas unpraktischer beim Einbau, andererseits blockieren sie keinen der raren NVMe-Anschlüsse auf dem Mainboard. SATA-Anschlüsse sind häufiger, üblich sind sechs. Die Crucial MX 500 ist eine solche moderne SATA-SSD und derzeit besonders günstig.

Ältere SATA-SSDs

Dann gibt es noch die älteren SATA-SSDs. Eigentlich gilt das gleiche wie bei den modernen, der Unterschied ist in den internen Bausteinen. Die älteren SSDs nutzen noch kein 3D-NAND, sie sind dadurch langsamer. Oft genug sind sie nicht dementsprechend günstig, deswegen hier aufpassen. Beispielsweise ist die SanDisk Plus im Vergleich zur Crucual MX 500 viel zu teuer.

Meine Wahl

Mir waren die NVMe-SSDs zu teuer, zudem hätte ich einen Adapter gebraucht, um den M.2-Riegel am PCI-E-Anschluss zu nutzen. Hätte ich noch keine SSD gehabt wäre es die 250GB Team Group L5 Lite 3D geworden, sie ist besonders günstig und sei doch schnell. Aber ich wollte eine größere, damit da Linux samt Spielen draufpasst, und die 500GB-Variante hat einen weniger attraktiven Preis. Daher wurde es die Crucial MX 500.

Mein erster Eindruck ist positiv: Sie funktioniert, und sie ist fühlbar schneller als meine bisherige SSD.