Am 02. Dezember wurde mehr oder minder überraschend mitgeteilt, daß das offizielle Iron Maiden-Spiel “Legacy Of The Beast” zum Jahresende 2024 eingestellt und die Server heruntergefahren werden.
Bis dahin kann im Rahmen der Sunset Celebration vieles ausprobiert werden, was bisher mühevoll erarbeitet werden wollte: Drop-Rates wurden erhöht, Kosten verringert und alle Echtgeld-Angebote aus dem Shop entfernt.
Eigentlich sollte an dieser Stelle ein detaillierter Blick auf “Encased: A Sci-Fi Post-Apocalyptic RPG” stehen, aber letztendlich waren es (mal wieder) technische Unzulänglichkeiten, welche den Spielspaß nicht nur getrübt, sondern das Erreichen des Spielendes beinahe erfolgreich verhindert hätten.
Encased ist - kurz zusammengefasst
“A very good RPG in the spirit of Fallout (1, 2)” [Quelle]
oder wie Peter Bathge bei “Gamestar” schrieb
A Sci-Fi Post-Apocalyptic RPG lautet der Untertitel und stellt damit die Weichen für die Erwartungshaltung des unbedarften Spielers. Nach dem Test hätte ich jetzt aber einen passenderen Untertitel für Encased: »Das Fallout-Wasteland, das ich immer wollte … [Quelle]
Den ersten Fehler findet man leider schon nach einer ersten Proberunde - man kann das Spiel nämlich nicht regulär verlassen. Klickt man im Menü auf “Exit” passiert exakt nichts, außer daß sich das Spiel in eine Endlosschleife begibt. Der Fehler wurde u.a. im Oktober 2022 unter “Trying to Exit Freezes the Game” im GOG Forum dokumentiert und offensichtlich nie behoben. Glücklicherweise fragt irgendwann GNOME von selbst, ob man den Prozess manuell beenden möchte, alternativ kann auch ein thematisch passender “kill”-Befehl an der Kommandozeile abgesetzt werden.
Innerhalb der einzelnen Orte läuft Encased stabil - bis man versucht, einen anderen Ort oder die Weltkarte zu betreten. Hier kommt es gefühlt in rund einem Zehntel aller Wechsel zu einem Absturz und der Spieler landet unerwartet auf dem Desktop. Dieses Problem ist nervig, aber leicht abzumildern und man gewöhnt sich im Laufe des Spielens daran, vor jedem Ortswechsel sicherheitshalber mit “F5” eine Schnellspeicherung vorzunehmen. Abstürze scheinen bei Encased aber generell bei vielen Spielern aufzutreten, wie eine Suche über die Foren bei Steam zeigt.
Absolut frustrierend ist aber, daß das Spiel kurz vor dem Epilog reproduzierbar an der gleichen Stelle abstürzt, was auf Reddit im Beitrag “Game crashes every time I try to descend to the landing pad at Concord” und auch bei Steam unter “Possible Linux crash solution” dokumentiert wurde. Dort ist auch ein potentieller Workaround zu finden - zusammen mit der Frage
I now wonder if all the crahes I encountered playing through the game would have not happened if I had used that option from the beginning. [Quelle]
Tatsächlich kann man - wie bei Reddit beschrieben - mit der Windows-Version problemlos den Ortswechsel zum Landing Pad vollziehen, den Workaround mit dem Kommandozeilenparameter habe ich erst im Nachgang gefunden.
Schade, eigentlich hätte ich gerne eine weitere Runde in der Welt gedreht und ein paar alternative Handlungsoptionen ausprobiert - so wurde das Spiel nach dem Epilog und anschließendem erneutem Crash stattdessen direkt deinstalliert und die Gamestar-Überschrift “Das Rollenspiel, das ihr euren Freunden empfehlen werdet” trifft zumindest für mich nicht zu.
Daß Software Fehler hat ist leider unumgänglich und daß noch so viele Tests nicht alle Fehler aufdecken können leider auch. Wenn aber schwerwiegende und reproduzierbare Fehler nicht behoben werden, dann ist das aus Spielersicht nicht nur ärgerlich, sondern dem Käufer gegenüber schlicht eine Unverschämtheit.
Nach einem Betriebssystem-Update von Debian 11 auf Debian 12 wollte Torchlight 2, das vor dem Update problemlos lief, nicht mehr starten: nach dem Klick auf das Icon erschien nur noch kurz der Spash-Screen … und das war’s - vom eigentlich erwarteten Startschirm fehlte jede Spur.
Als erste Möglichkeit zur Fehlersuche bietet sich meist ein Start des Programms über die Kommandozeile an, in der Hoffnung, dadurch vielleicht in paar Statusmeldungen zu sehen. Dies funktioniert auch beim Start von Torchlight 2, welches eine ganze Menge an Meldungen ausgab, bevor es letztendlich mit einem “Speicherzugriffsfehler” abbrach.
$ ./Torchlight2.bin.x86_64
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
...
Loading library RenderSystem_GL
Path for saving is ...
...
Compressing memory size is: 246
Compressing memory size is: 4559
Speicherzugriffsfehler
Leider führte die Kombination von “Torchlight 2” und “Speicherzugriffsfehler” bei der Suche nach Lösungsmöglichkeiten nicht zu hilfreichen Ergebnissen. Auch Tips, die in Richtung von Bibliothekskonflikten gingen halfen nicht, das Programm wieder zum Starten zu bewegen.
Zum Ziel führte letztendlich ein Blick in die Datei “ogre.log”, die auf den ersten Blick identisch mit den Ausgaben beim Programmstart aussieht, allerdings noch ein paar zusätzliche Ausgaben enthält:
$ cat ~/.local/share/Runic\ Games/Torchlight\ 2/ogre.log
11:57:15: Creating resource group General
11:57:15: Creating resource group Internal
11:57:15: Creating resource group Autodetect
...
11:57:15: Loading library RenderSystem_GL
11:57:15: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL. System Error: libGLU.so.1: cannot open shared object file: No such file or directory in DynLib::load at /builddir/Torchlight2/ogre170/OgreMain/src/OgreDynLib.cpp (line 94)
11:57:15: Path for saving is ...
...
11:57:16: Compressing memory size is: 246
11:57:16: Compressing memory size is: 4559
So war der entscheidende Hinweis zwischen den Zeilen “Loading library RenderSystem_GL” und “Path for saving is” versteckt, im konkreten Fall ein
System Error: libGLU.so.1: cannot open shared object file: No such file or directory
der sich durch Installation des Pakets libglu1-mesa letzendlich leicht beheben ließ.
Seit kurzem steht hier eine PlayStation 4 und passend dazu habe ich als Sonderangebot Red Dead Redemption II gekauft - ein hochgelobes Action-Adventure im Western-Setting von Rockstar Studios.
Ohne Zweifel ist die Präsentation gelungen: die Welt sieht richtig schick aus, egal ob einzelne Spuren im Schnee, Rauch oder viele andere Details - es macht einfach Spaß auch ohne konkretes Ziel durch die Gegend zu reisen und die Landschaft zu bewundern.
Zum Spiel selbst gehört aber natürlich mehr als Sightseeing zu betreiben und in diesem Punkt schwächelt Red Dead Redemption II gewaltig. Eine spielerische Herausforderung ist in vielen Situationen nur rudimentär vorhanden, die meisten zu spielenden Sequenzen erinnern an Dragon’s Lair:
eine Spielfigur in einem interaktiven Zeichentrickfilm … Der Spieler musste mit bestimmten Joystickbewegungen zum richtigen Zeitpunkt in die laufende Handlung eingreifen. [Quelle]
Sowohl Mitglieder der eigenen Bande als auch andere NPCs bieten zahlreiche Beschäftigungsmöglichkeiten - eine wirkliche Entscheidungsfreiheit oder alternative Lösungswege sind aber weitestgehend Mangelware. Wer vorher Spiele wie The Witcher oder Cyberpunk 2077 gespielt hat, wird sich wahlweise eingeschränkt und / oder unterfordert vorkommen.
Die eigentliche Geschichte rund um Spielercharakter Arthur Morgan ist erschreckend unflexibel und alles andere als gelungen inszeniert. Spätestens wenn man über einige der im Spiel versteckten Goldbarren stolpert und anschließend trotz voll ausgebautem Lager immer noch in Geld schwimmt, wird das ständige “Wir brauchen Geld!"-Gerede als Motivation unglaubwürdig und nervig. Wie schön wäre es, einfach “Wie viel brauchst Du denn?” antworten zu können und gut ist, statt mir mehreren tausend Dollar in der Tasche zwangsweise eine “Eine handvoll Dollar”-Mission starten zu müssen.
Dazu kommt, daß Arthur Morgan auch massiven Stimmungsschwankungen zu unterliegen scheint: Rettet er im einen Moment noch eine Damsel in Distress oder verschenkt Arznei an einen jammernden Passanten am Wegesrand, ist in der nächsten Storymission “schlagen statt fragen” die einzige Handlungsmöglichkeit. Kontinuität und Handlungsoptionen sehen anders aus.
Richtig nervig wird es beim Speichern bzw. Laden von Spielständen: wer auch immer dieses Speichersystem ausgedacht hat, hat das Spiel wohl selbst nie damit spielen müssen.
Die theoretische Möglichkeit, jederzeit frei Speichern zu können wird dadurch ausgehebelt, daß während einer Mission eben kein Speichern möglich ist. Nun ist der Umfang einer Mission (und somit deren zeitliche Dauer) im Voraus nicht abschätzbar und mittendrin nicht speichern können bedeutet, daß man Missionen eigentlich nur beginnen kann bzw. sollte, wenn man anschließend beliebig viel Zeit hat, die Mission unabhängig von ihrer Dauer zu Ende spielen zu können - sonst geht es wieder von vorne los.
Geht innerhalb einer Mission etwas schief, hilft ein Checkpoint-System nach dem Motto “Live. Die. Repeat.” den Abschnitt so oft wiederholen zu können / müssen, bis sich der vorprogrammierte Erfolg einstellt oder gar die Möglichkeit zum Überspringen einer Sequenz erscheint, was im Gegensatz zur Spieldauer den Spielspaß nicht unbedingt erhöht.
Als wäre das alles nicht bereits nervig genug, kamen die Entwickler auch noch auf die Idee, beim Laden eines gespeicherten Spielstandes Spawnpunkte zu verwenden.
Konkret bedeutet dies, daß nach dem Laden der Protagonist die Welt nicht wieder genau an dem Punkt betritt, an dem der Spielstand gespeichert wurde, sondern an einem Platz mehr oder minder in der Nähe des Speicherpunktes. Dies kann dann gerne auch mal ein ganzes Ende vom ursprünglichen Speicherpunkt entfernt sein.
Gerade als Gelegenheitsspieler habe ich mir in Open-World-Spielen angewöhnt, Speicherpunkte auch als To-Do-Merker zu verwenden, d.h. im Normalfall so zu speichern, daß der Charakter beim Laden genau dahin schaut, wo ich weitermachen möchte: zum Beispiel bei einer Schatzsuche genau mit Blick auf die Felsformation zu speichern, die demnächst zu erklimmen ist. Hilft nur leider nix, wenn man beim Laden an einer ganz anderen Ecke wieder auftaucht und den Weg zur Felsformation erneut oder aus einer ganz anderen Richtung zurücklegen muss - sofern man sich noch daran erinnert.
Red Dead Redemption II war durchgänig ein heißer Kandidat für “Warum breche ich Spiele ab?”. Erst im humorvoll inszenierten Epilog rund um John Marston blitzte sowas wie Freude am Spiel auf und dieser hat auch ein wenig für den Rest des Spiels entschädigt.
Was mit Quake 2 funktioniert, funktioniert auch mit Doom 3 - zumindest mit der Doom 3 BFG-Edition. Für diese wurde das ursprüngliche Doom 3 nicht nur überarbeitet, sondern auch um die Missionspakete “Resurrection of Evil” und “The Lost Mission” sowie die Vorgängerspiele Doom und Doom 2 ergänzt.
Die am weitesten verbreitete Portierung der Spiele-Engine stammt von Robert Beckebans, der das Projekt “RBDOOM-3-BFG” bis heute kontinuierlich pflegt und auftretende Fehler bereinigt.
RBDOOM-3-BFG is based on DOOM-3-BFG and the goal of this port is to bring DOOM-3-BFG up to latest technology in 2023 making it closer to Doom 2016 while still remaining a DOOM 3 port regarding the gameplay. [Quelle]
Die benötigten Dateien können entweder direkt von der Projektseite auf Github heruntergeladen oder - sofern verfügbar - aus den offiziellen Paketquellen einer Linux-Distribution installiert weden:
$ sudo apt install rbdoom3bfg
Wie üblich sind bei der Spiele-Engine keinerlei Inhalte enthalten, diese müssen zusätzlich bereitgestellt werden. Der einfachste (legale) Weg führt entweder über einen Kauf bei Steam oder GOG.com, die weitere Vorgehensweise ist auf der Projektseite beschrieben.
Sofern die Installationsdatei von GOG.com vorliegt, kann diese auch - statt wie empfohlen umständlich über Wine installiert - direkt mit “innoextract” entpackt und anschließend verwendet werden:
$ innoextract setup_doom_3_bfg_1.14_\(13452\).exe
Sobald die Spieldaten entpackt wurden, können diese an einen beliebigen Ort “MEIN-PFAD” kopiert werden:
$ mkdir -p /MEIN-PFAD/Doom3BFG/
$ cp -r --preserve=timestamp app/base /MEIN-PFAD/Doom3BFG/
Anschließend sollte noch das Konfigurationsverzeichnis erzeugt und eine “autoexec.cfg” darin abgelegt werden, welche die Sprache auf die gewünschte Version setzt - bei den Installationsdateien von GOG.com wird sonst automatisch “Japanisch” als Standardsprache gewählt.
$ mkdir -p ~/.local/share/rbdoom3bfg/base/
$ echo 'seta sys_lang "english"' >> ~/.local/share/rbdoom3bfg/base/autoexec.cfg
Dann kann Doom 3 BFG gestartet werden, wobei zu beachten ist, daß es keinerlei Parameter gibt, um das Datenverzeichnis anzugeben. Das ausführbare “rbdoom3bfg” ist im Ordner “MEIN-PFAD” zu starten.
Wer möchte, kann sich den Start noch mit Hilfe einer “.desktop”-Datei erleichtern.
$ cp --preserve=timestamp app/language_setup.png /MEIN-PFAD/Doom3BFG/
$ vi ~/.local/share/applications/Doom3BFG.desktop
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Doom 3 BFG
Exec=/usr/games/rbdoom3bfg
Icon=/MEIN-PFAD/Doom3BFG/language_setup.png
Path=/MEIN-PFAD/Doom3BFG/
Terminal=false
Categories=Game
Auch hier ist “MEIN-PFAD” mit dem oben gewählten Pfad zu ersetzen.
Optional kann auch noch ein AppArmor Profil erzeugt und in “/etc/apparmor.d” abgelegt werden. Folgendes Profil reicht (hier) aus, um RBDOOM-3-BFG mit einer NVidia-Graphikkarte zu spielen:
# 2023-03-02 athul/initial
#include <tunables/global>
/usr/games/rbdoom3bfg {
#include <abstractions/X>
#include <abstractions/base>
#include <abstractions/audio>
#include <abstractions/nvidia>
deny network,
@{HOME}/.local/share/rbdoom3bfg/** rwk,
/MEIN-PFAD/Doom3BFG/** r,
/sys/devices/** r,
/var/lib/dbus/machine-id r,
/proc/** r,
/dev/nvidia* rw,
}
Zu beachten ist die Anpassung von “MEIN-PFAD” sowie das anschließende Neuladen der AppArmor-Profile, nachdem “rbdoom3bfg” hinzugefügt wurde.