Wiederbelebung eines toten Dune-RTS: EmperorLauncher

 (wheybags.com)
1 Punkte von GN⁺ 2024-07-15 | 1 Kommentare | Auf WhatsApp teilen
  • Das RTS Emperor: Battle for Dune von 2001 war unter modernem Windows beim Ausführen, Installieren und Online-Spielen gleichermaßen problematisch; EmperorLauncher ist ein Patch, der es wieder spielbar macht
  • Die wichtigsten Verbesserungen konzentrieren sich auf High-Resolution-Support, ein 60-FPS-Limit, direkten IP-Online-Multiplayer, einen Koop-Kampagnenmodus und das Umgehen des defekten Installationsablaufs
  • Die Umsetzung besteht aus einem Ersatz-Launcher für Emperor.exe, DLL-Injection in Game.exe, Funktions-Patching mit Microsoft Detours, Direct3D-7-Rendering-Hooks, Winsock-Intercepting und einem einfachen WOL-Server
  • Für Online-Partien wird die bisherige Struktur aus P2P, zufälligen Ports und NAT Punching in eine einzelne Client-zu-Server-Verbindung getunnelt, sodass sich nur noch der Server-Host um die Netzwerkkonfiguration kümmern muss
  • Vom Kopieren der Original-CD-Dateien über das Extrahieren von .cab-Dateien, das Anwenden des offiziellen v1.09-Patches, das Umgehen der COM-Registrierung von WOLAPI.DLL bis hin zur Win32-Launcher-UI deckt das Tool alles von Installation bis Start ab

Wo Emperor: Battle for Dune blockiert war

  • Emperor: Battle for Dune ist ein Echtzeitstrategiespiel von Westwood Studios aus dem Jahr 2001 und der Nachfolger von Dune 2000
  • Auf modernen Systemen gibt es mehrere Probleme, die das Spielen verhindern
    • Keine Ausführung in hohen Auflösungen, die zu heutigen Bildschirmen passen
    • Im Multiplayer ist die Geschwindigkeit der Spielsimulation nicht begrenzt und wird dadurch viel zu hoch
    • Westwood Online (WOL) funktioniert nicht mehr, wodurch Multiplayer außerhalb des LAN schwierig ist
    • Die Koop-Kampagne ist eine reine Online-Funktion und kann nicht im LAN genutzt werden
    • Das auf der Disc enthaltene Installationsprogramm ist defekt
    • Bei hohen Framerates moderner PCs gehen mehrere visuelle Effekte kaputt
  • EmperorLauncher ist ein Patch zur Behebung dieser Probleme; Download-Dateien und Source Code sind öffentlich verfügbar

Ersatz für Emperor.exe und Initialisierung von Game.exe

  • Die Emperor.exe des Spiels ist nicht die eigentliche Spieldatei, sondern ein dünner Wrapper, der Game.exe startet
  • Wenn man Game.exe direkt ausführt, passiert nichts; daher musste der von Emperor.exe durchgeführte Initialisierungsprozess analysiert und im Ersatz-Launcher nachgebildet werden
  • Für die Analyse wurde IDA verwendet
    • IDA kann ausführbare Dateien disassemblieren und Teile des Codes in C-ähnlicher Form dekompilieren
    • In einem Binary ohne Typ- und Strukturinformationen mussten Funktionsaufrufe und die Nutzung der Windows-API nachverfolgt werden
  • Vor dem Start von Game.exe erstellt Emperor.exe eine Mutex und ein Handle auf ein anonymes File Mapping, verarbeitet aus Emperor.dat gelesene Daten und kopiert sie anschließend in das Mapping
  • Der Elternprozess sendet eine Windows-Nachricht an die Main-Thread-ID des Kindprozesses, die er über CreateProcessA erhalten hat, und übergibt damit den Wert des File-Mapping-Handles
    • Als Custom-Message-ID wird 0xBEEF verwendet
    • Die File-Mapping-Daten bestanden aus den drei Strings "UIDATA,3DDATA,MAPS" und wurden an den Asset-Loading-Code des Spiels weitergereicht
  • Statt den Entschlüsselungscode direkt neu zu implementieren, wurde anstelle von Game.exe ein Dump-Tool eingesetzt, das die übergebenen Daten auf die Festplatte schrieb; der Launcher führt anschließend dieselbe Sequenz aus

DLL-Injection und Funktions-Patching

  • Um den Patch anzuwenden, musste eigener Code innerhalb des Game.exe-Prozesses ausgeführt werden; dafür wurde die Methode CreateRemoteThread + LoadLibrary genutzt
  • Die Injection läuft in dieser Reihenfolge ab
    • Im Speicher des Zielprozesses wird mit VirtualAllocEx ein Buffer allokiert
    • Der DLL-Pfad-String wird mit WriteProcessMemory kopiert
    • Die Adresse von LoadLibrary und der Buffer mit dem DLL-Pfad werden an CreateRemoteThread übergeben, um die DLL im Zielprozess zu laden
    • Während DllMain der DLL ausgeführt wird, läuft der Patch-Code
  • Der Prozess wird im suspended-Zustand gestartet, danach wird die DLL injiziert, damit Codeausführung vor main sichergestellt ist
  • Für das Ändern bestehender Funktionen wird Microsoft Detours verwendet
    • Detours ersetzt die ersten Instruktionen der ursprünglichen Funktion durch eine Sprunganweisung, die Aufrufe an eine Ersatzfunktion weiterleitet
    • Die überschriebenen Originalinstruktionen werden in einen separaten Speicherbereich kopiert; anschließend wird ein Wrapper erzeugt, der zum Rest der ursprünglichen Funktion zurückspringt, sodass auch Aufrufe der Originalfunktion möglich bleiben
  • Da Speicherseiten mit Funktionscode aus Sicherheitsgründen nicht beschreibbar sind, müssen die Rechte mit VirtualProtect geändert werden; nach der Änderung ist FlushInstructionCache aufzurufen

Wiederherstellung der Debug-Logs

  • Im Binary gab es Aufrufe, die wie Debug-Logs wirkten, doch die tatsächliche Zielfunktion war eine leere Funktion, die nur ret enthielt
  • Vermutlich wurden im Release-Build mehrere leere Funktionen zu identischem Code zusammengeführt; eine davon war der Debug-Logger
  • Zunächst wurde eine Heuristik genutzt, die das erste Argument als String-Pointer interpretierte und prüfte, ob es druckbare ASCII-Zeichen enthält
    • Zugriffe auf ungültige Pointer wurden über Windows-SEH-Exceptions abgefangen und ignoriert
    • Dieser Ansatz funktionierte teilweise, ließ aber false positives und false negatives übrig
  • Später wurden die Log-Callsites mit der Patch-Funktion von IDA und Python-Skripten auf eine separate leere Funktion verschoben
    • Einige wurden heuristisch gefunden, andere über das Muster, dass ein String-Literal gepusht und anschließend ein Aufruf ausgeführt wird
    • Die verbleibenden mehreren Hundert Callsites wurden manuell kommentiert
  • Die wiederhergestellten Logs halfen beim Debugging des WOL-Multiplayers
    • Anhand des Assert-Logs "MyId == INVALID_ID" während der Verarbeitung von SC_MESSAGE_YOUR_DETAILS wurde in einem Wireshark-Dump bestätigt, dass der GAMEOPT-Befehl fälschlicherweise an alle Spieler gesendet wurde

Grafik-Patch für Direct3D 7

  • Emperor ist ein Spiel auf Basis von Direct3D 7, und die Direct3D-7-Unterstützung moderner Windows-Versionen ist nicht vollständig
  • Das Problem mit hohen Auflösungen hing mit einer maximalen Texturgröße von 2048 in der Direct3D-7-Wrapper-Schicht zusammen; gelöst wurde es mithilfe von Code aus UCyborgs LegacyD3DResolutionHack
  • Das Spiel kann mit Bildformaten außerhalb von 4:3 nicht korrekt umgehen
    • Das Rendering selbst funktioniert, aber die UI wirkt übermäßig vergrößert und fehlerhaft
    • Auch der spielinterne Maus-Rendering-Offset verschiebt sich abhängig vom Abstand zur Bildschirmmitte
  • Die Lösung ist 4:3-Letterboxing
    • Wird das Spiel im Fenstermodus ausgeführt, sind beliebige Auflösungen möglich
    • Der Fensterrahmenstil wird entfernt, und das Spielfenster wird erneut als Child eines schwarzen Vollbildfensters gesetzt
    • Zusätzlich wird Mouse Capture eingebaut, damit Edge Scrolling bei Multi-Monitor-Setups oder im Fenstermodus nicht kaputtgeht
  • Das Framerate-Limit wird durch Patchen von IDirect3DDevice7::EndScene auf 60 FPS gesetzt
    • EndScene wird einmal am Ende jedes Frames aufgerufen und eignet sich daher gut, um die Verzögerung zu berechnen und den Thread schlafen zu legen
    • Da der EndScene-Pointer nicht direkt exportiert wird, werden nacheinander Aufrufe von DirectDrawCreateEx und IDirect3D7::CreateDevice gehookt, um den Funktionspointer aus der vtable zu erhalten

Online-Multiplayer und Ersatz für WOL

  • Ziel war direkter IP-Multiplayer, der ohne Lobby- oder Hosting-Infrastruktur auskommt und nur Port Forwarding sowie IP-Eingabe benötigt
  • Der LAN-Modus funktioniert, sucht Server aber per UDP-Broadcast und eignet sich daher nicht für Internet-Partien
    • Im LAN-Menü gibt es keine manuelle IP-Eingabe
    • Anfangs wurde versucht, den LAN-Chat so zu patchen, dass eine IP angegeben werden kann; nachdem sich herausstellte, dass die Koop-Kampagne WOL-exklusiv ist, wurde dieser Ansatz aufgegeben
  • Um WOL wiederzubeleben, waren zwei Dinge nötig
    • Ein gefälschter WOL-Master-Server, damit das Spiel weiß, wohin es sich verbinden und welches Spiel es starten soll
    • Ein Proxy, damit Spielpakete über die direkte IP-Verbindung funktionieren
  • In der ursprünglichen WOL-Struktur gab es neben dem Master Server auch einen „Mangler“-Server, der offenbar NAT Punching koordinierte
    • Der ursprüngliche Mangler-Server ist verschwunden, und das Spiel bleibt beim Warten auf dessen Antwort hängen
    • Im Patch wurden die Mangler-Aufrufe entfernt
  • Emperor verwendet ein P2P-Netzwerkmodell, öffnet für jedes Spielerpaar bidirektionale Verbindungen und wählt zufällige Ports
    • Diese Struktur setzt voraus, dass alle Clients offene Ports annehmen können, und passt nicht zu heutigen Internetumgebungen
  • Die Lösung besteht darin, Winsock-Funktionen abzufangen und sämtliche Verbindungen in eine einzelne Client-zu-Server-Verbindung zu tunneln
    • Nachrichten, die ein Client an den Server oder an andere Clients senden will, werden abgefangen, mit einem Header umhüllt und über eine einzelne Verbindung übertragen
    • Ein Thread auf Serverseite empfängt die Nachrichten und verteilt sie an die Zieladresse
    • Das Spiel glaubt weiterhin, wie im P2P-Modus zu arbeiten, tatsächlich muss sich aber nur der Server-Host um die Netzwerkkonfiguration kümmern
  • Mit dieser Konfiguration konnten Koop-Kampagnenpartien gestartet und ihnen beigetreten werden

Implementierung eines einfachen WOL-Servers

  • Der WOL-Master-Server war vom Aufbau her eher ein IRC-Server
  • Auf xwis.net gab es einen offenbar von Fans betriebenen Server, der zum Zeitpunkt der Erstellung anscheinend auch Zugriff auf den ursprünglichen DNS-Eintrag servserv.westwood.com des Spiels hatte
    • Emperor funktionierte auf xwis zwar nicht ohne Weiteres korrekt, war aber als Referenz für das Erstellen und Beitreten von Lobbys nützlich
  • Auch die öffentliche WOL-Server-Implementierung handle_wol.cpp von pvpgn-server wurde als Referenz genutzt
  • Ein eigener Server wurde gebaut, weil es keine Garantie gibt, dass ein externer Server dauerhaft erhalten bleibt
    • Ziel ist nicht der Betrieb einer konkurrierenden Community, sondern die Bereitstellung der minimalen Funktionen, die zum Starten von Multiplayer-Spielen nötig sind
  • WOL mischt Standard-IRC mit Custom-Verhalten
    • Spiellobbys sind spezielle Channels
    • Lobby-Informationen verwenden das IRC-Topic
    • Lobby-Chat verwendet PAGE statt PRIVMSG
    • Die Synchronisation der Spieleinstellungen nutzt GAMEINFO-Nachrichten mit Nicht-ASCII-Inhalten
  • Die grundlegende WOL-Server-Implementierung wurde per Trial and Error fertiggestellt; abseits des normalen Pfads ist sie nicht robust, funktioniert aber

Installationsprogramm und Anwendung des v1.09-Patches

  • Das ursprüngliche Installationsprogramm ist defekt, sodass Nutzer den CD-Inhalt auf die Festplatte kopieren und ein alternatives Setup darüberkopieren mussten
  • EmperorLauncher enthält eine Installationsfunktion, die Dateien von der Original-CD kopiert und .cab-Dateien extrahiert
    • .cab ist ein zip-ähnliches Archivformat, und Windows bietet eine Schnittstelle zum Extrahieren
  • Das Anwenden des letzten offiziellen Patches v1.09 war schwieriger
    • Die Methode, EM109EN.EXE einfach mit 7zip zu extrahieren, um die aktuellen Binaries zu erhalten, funktionierte nicht
    • In den Windows-Ressourcen wurde eine große Ressource gefunden, in der ein Executable-Header sichtbar war
    • Die ersten 4 Bytes dieser Ressource sind die Dateigröße; danach folgt die eigentliche Datei
  • EM109EN.EXE extrahiert eine eingebettete DLL in eine temporäre Datei, lädt sie und führt anschließend die interne DLL-Funktion RTPatch32@12 aus
    • RTPatch war ein Tool für Binary-Diff-Patches
    • Unter Bezug auf das Tool myRTP wurde die eingebettete DLL direkt geladen und ausgeführt
  • Da die DLL den Pfad nicht aus dem als Argument übergebenen Installationspfad, sondern aus der Registry las, wurde der erwartete Registry-Key gefälscht, um den Patch anzuwenden

Umgang mit Westwood Online Shared Internet Components

  • Zur Originalinstallation gehören neben Emperor selbst auch die Westwood Online Shared Internet Components
  • Ohne diese Komponente funktioniert WOL nicht; die wichtigste Datei ist WOLAPI.DLL
  • WOLAPI.DLL ist eine COM-Class-Library, und Emperor erzeugt die COM-Objekte in der DLL mit CoCreateClass
  • Die übliche COM-Registrierung registriert CLSID und DLL-Pfad systemweit unter HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
    • Diese Methode erfordert Administratorrechte
    • Sie wirkt über den Spielprozess hinaus auf das gesamte System
  • Im Patch wird die Registrierung pro Benutzer mittels Registry Redirect und OaEnablePerUserTLibRegistration behandelt
    • Eine Möglichkeit, eine Class Library nur für einen einzelnen Prozess zu registrieren, wurde nicht gefunden
    • Der Versuch, DllGetClassObject direkt zu verwenden, funktionierte nicht

Launcher-UI und Endergebnis

  • Der letzte Schritt war eine einfache Launcher-UI zur IP-Eingabe und Änderung grundlegender Einstellungen
  • Die UI wurde mit rohen Win32 Controls geschrieben
    • Für eine statische und einfache UI war das ausreichend, aber die direkte Erstellung einer Win32-UI war eine raue Erfahrung
  • EmperorLauncher ist am Ende ein Tool geworden, das die Ausführung auf modernen Systemen, hohe Auflösungen, ein 60-FPS-Limit, direkten IP-Multiplayer, Koop-Kampagnen sowie Installation und Patch-Anwendung umfasst

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-15
Hacker-News-Kommentare

  • Dieses Spiel hat für das gesamte Genre der Echtzeitstrategie eine ziemlich große Bedeutung. Wenn man an Echtzeitstrategie denkt, stellt man sich oft das Muster vor, dass Arbeiter Ressourcen abbauen und man diese dann schützen muss, und Dune RTS war diesem Urbild sehr nahe.
    Allerdings lag das auch an der Originalvorlage als Roman. Sonst hätte sich das Genre vielleicht in eine ganz andere Richtung entwickelt. Zum Beispiel hätte man die Ressourcen direkt in der Basis abbauen können, während der Gegner eher Gebäude schikaniert, oder die Belohnung für Kartenkontrolle hätte etwas anderes sein können als bloß besserer Ressourcenzugang

    • Genau genommen geht es in diesem Artikel nicht um Dune 2, sondern um Emperor: Battle for Dune
    • Wie jemand anderes schon angemerkt hat, ist das hier vermutlich der Nachfolger von Dune 2, an den du gerade denkst.
      Dune 1 hat ebenfalls das Fundament gelegt. Anfangs ist es eher ein Point-and-Click-Adventure, aber gegen Ende wird es zu einem Spiel mit Ressourcenverwaltung und -abbau, Truppenproduktion, Kämpfen und Terraforming.
      Den späten Spielverlauf habe ich überhaupt nicht verstanden. Das Ziel schien zu sein, den Planeten wieder grün zu machen, aber sobald alles begrünt war, gab es kein Spice mehr. Gleichzeitig verlangte der Imperator immer mehr Spice-Lieferungen, und wenn man die Quote nicht erfüllte, war das Spiel vorbei.
      Möglich, dass ich als Kind einfach nicht richtig verstanden habe, was da passiert. Ich sollte es wohl noch einmal spielen, aber nach heutigen Maßstäben ist es entweder nicht besonders gut gealtert oder es dauert ziemlich lange, bis man es durchgespielt hat.
      Edit: Ich wusste nicht, dass Dune 1 und 2 im selben Jahr erschienen sind. Dann war Dune 2 entweder schon in Entwicklung, oder sie haben Engine und Spiel in weniger als einem Jahr gebaut. Selbst heute ist das mit Indies und besseren Tools kaum vorstellbar
    • Ich habe The Settlers(https://en.wikipedia.org/wiki/The_Settlers_(1993_video_game)) immer für das erste Echtzeitstrategiespiel gehalten.
      Es erschien im Juni 1993 und damit ein paar Monate nach Dune, aber wenn beide Spiele gleichzeitig in Entwicklung waren, könnte das ein Fall gewesen sein, in dem mehrere „Erfinder“ unabhängig zur gleichen Idee kamen. The Settlers soll von „Götterspielen“ wie Populous(https://en.wikipedia.org/wiki/Populous_(video_game)) beeinflusst worden sein. Dort hat der Spieler gottähnliche Fähigkeiten wie das Verändern der Landschaft, steuert aber die Einheiten nicht direkt
    • Dawn of War ist ein gutes Beispiel für Echtzeitstrategie abseits des typischen Erzabbau-Paradigmas
    • Vielleicht wäre es am Ende sowieso in diese Richtung gegangen. Die Geschichte stützt sich stark auf das Muster „Bauern sind ressourcenbasiert, Herrscher sind Strategen“.
      Nicht nur Dune, sondern eigentlich die Geschichte insgesamt funktioniert bis zu einem gewissen Grad so

  • Toller Artikel und großartige Arbeit. Ich habe vor etwa zehn Jahren etwas Ähnliches gemacht, damals an Tiberian Sun, und dort ging es darum, den Netzwerkcode zu patchen.
    So tief in fremden Code einzusteigen, fühlt sich irgendwie an, als würde man eine gemeinsame Verbindung teilen. Schrecklicherweise habe ich entdeckt, dass es für Modem-Spiel einen komplett separaten Stack gab. Es wurde also nicht einfach TCP/IP über das Modem geschickt.
    Irgendjemand muss monatelang benutzerdefinierten Code für Framing, Synchronisation, Fehlerbehandlung und die Frage geschrieben haben, wie neu gewählt wird, wenn die Verbindung abbricht. Und schon als das Spiel erschien, war dieser Code praktisch fast nutzlos

    • Das hatte vermutlich einen anderen Grund. Ziel war wohl nicht, sich ins Einwahl-Internet einzuwählen, sondern direkt ein anderes Modem anzurufen.
      Ich habe das selbst nie benutzt, aber viele alte Spiele hatten so eine Option

  • Schön. Dieser Teil im Artikel ist mir aufgefallen:
    „Westwood Online (WOL) funktioniert nicht mehr, daher ist Multiplayer nur noch über LAN möglich“
    Ich mochte Command & Conquer als Kind sehr und kenne Westwood Online ein wenig von der Client-Seite.
    Wenn ich mich richtig erinnere, hat XWIS.net nach der Abschaltung von WOL viel Unterstützung geleistet. Der Autor könnte mal versuchen, die kleine Entwickler-Community dort zu kontaktieren. Allerdings könnte die Szene inzwischen auch wirklich am Verschwinden sein.
    Was die Leute von XWIS gemacht haben, wurde sogar von EA anerkannt, und soweit ich mich erinnere, hat es ziemlich geholfen, den WOL-Support für C&C Renegade weiterzuführen.
    Außerdem gibt es noch das FreeRA-Projekt, das so etwas wie der direkte Vorfahre der neueren C&C-Neuveröffentlichungen auf Steam und anderswo ist. Vielleicht könnten sie ebenfalls helfen, WOL wiederzubeleben.
    Da WOL als eigene Bibliothek hineingedrückt wurde, ist ein Austausch der Bibliothek vermutlich deutlich einfacher, als den WOL-Stack komplett rückwärts zu analysieren.
    Edit: Beim Weiterlesen im Artikel sehe ich, dass auch die WOL-Komponenten repariert wurden. Umso besser

  • Großartiger Artikel. Der Autor wirkt wie jemand, mit dem ich abends gern auf ein Bier rausgehen würde: interessant und klug.
    Die niedlichen ausklappbaren Erklärungen gefallen mir sehr und sind auch nützlich. Beim Lesen hatte ich das Gefühl, eine Art Choose-your-own-adventure-RPG zu spielen, was eine ziemlich neue Erfahrung war.
    Und noch etwas zu der Stelle „CS:GO wurde erst 2023 in den Ruhestand geschickt“: Ich dachte, CS:GO sei einfach zu CS2 umbenannt worden. Liege ich da falsch?

    • CS2 wird von manchen als Rückschritt gegenüber CS:GO gesehen. Ich sehe das genauso.
      Ich habe gehört, dass selbst Turnier-PCs in CS2 keine ordentlichen Bildraten halten konnten, obwohl dieselbe Hardware CS:GO problemlos stemmte. Auch von Nutzern mit High-End-PCs gibt es viele ähnliche Berichte.
      Valve wollte, dass CS2 als Fortsetzung von CS:GO wahrgenommen wird, hat den Wechsel aber nicht dadurch erreicht, dass es ein besseres Spiel gebaut hat, das das alte natürlich ersetzt hätte, sondern indem es der Spielerschaft die Veränderung aufgezwungen hat. Weil CS:GO ein großartiges Spiel war, werden ich und viele andere darüber noch eine Weile verbittert sein
    • CS2 wurde zwar unter derselben Application ID wie CS:GO veröffentlicht, ist aber ein komplett neu gebautes Spiel auf einer neuen Engine. Es ist kein Rebranding
    • CS2 nutzt im Gegensatz zum früheren, auf Source 1 basierenden CS:GO die Source-2-Engine mit einem DX11- oder Vulkan-Renderer

  • Ich finde es wirklich interessant, dass moderne, mit Werbung vollgestopfte und auf Pay-to-win getrimmte Massenware gegen alte Klassiker verliert.
    Schon ein einziger Hacker kann helfen, dass das Publikum solchen Schrott verdrängt. Bei beständigen Medien scheint es so zu sein, dass die guten Dinge aus der Vergangenheit die mittelmäßigen Dinge der Gegenwart am Ende schlagen

  • Großartiger Artikel und großartige Arbeit. Vielleicht lässt sich das irgendwie mit unserer Arbeit bei CnCNet zusammenführen. Komm doch mal bei CnCNet vorbei und lass uns darüber reden

  • „Da hängt ein 28.8-BPS-Modem dran.“
    Aktivmatrix. Eine Million psychedelische Farben

    • RISC-Architektur wird alles verändern

  • Sehr interessanter und tiefgehender Artikel. Mir gefällt die Menge an Details und geteiltem Wissen darüber, wie man solche aufgegebenen Spiele rückwärts analysiert und patched.
    Ich habe dieses Spiel einmal in einem lokalen Secondhand-Laden gesehen, es aber liegen lassen, weil ich nur Dune II RTS gespielt hatte. Jetzt werde ich es mir auf jeden Fall holen

    • Ich frage mich, ob es unter Wine läuft

  • Passend dazu gibt es auf Steam ein modernes Dune-Echtzeitstrategiespiel.
    https://store.steampowered.com/app/1605220/Dune_Spice_Wars/

    • Das als Echtzeitstrategie zu bezeichnen, ist etwas weit hergeholt. Es ist eher ein 4X-Spiel, läuft langsam und der Kampf ist nicht besonders wichtig
    • Unabhängig davon, dass andere Spice Wars als 4X bezeichnen, war das, was einem modernen Dune-Echtzeitstrategiespiel tatsächlich am nächsten kam, Homeworld: Deserts of Kharak

  • „UI-Design ist meine Leidenschaft.“
    Wirklich gut. Solche Texte vermisse ich. In vielerlei Hinsicht erinnert mich das an Blogposts von Steve Yegge