Übersicht

Frohe Feiertage! Diesen Monat ist einiges passiert, das weitere Quality-of-Life-Verbesserungen ins Spiel bringt. Nämlich eine Überarbeitung des Speichersystems, Logging, Crash-Reporting und Live-Einstellungen! Dazu ein neues, aber noch leeres Wiki.

Ich bin super stolz auf das Live-Einstellungen-Zeug. So etwas habe ich woanders noch nicht gesehen. Wenn du das interessant findest und das Spiel spannend klingt, gib dem Spiel gern eine Wunschliste auf Steam. Das hilft enorm.

Außerdem habe ich kürzlich die öffentliche Demo von Steam genommen. Sie spiegelt inzwischen WIRKLICH nicht mehr die Qualität und den Feinschliff des aktuellen Spielstands wider. Ich plane, irgendwann einen „Demo 2"-Build auf Steam hochzuladen, der die Arbeit der kommenden Monate zeigt.

Also, hier die neuesten Arbeitsbereiche.

Speicher-Überarbeitung

Das Nervigste in einem Fabrikspiel: Du steckst einen Haufen Arbeit rein und verlierst dann den Fortschritt. Das ist ein paar Spielern passiert, also wollte ich einen soliden Ansatz finden. Hab's simpel gehalten: Ein Loop-Timer speichert das Spiel automatisch alle 5 Minuten mit einem rotierenden Set von 5 Speicherständen, wobei jeder neue den ältesten überschreibt. War ziemlich trivial mit einem Bevy-Timer und einer kleinen State Machine.

So wird automatisch gespeichert, während manuelle Speicherungen weiterhin möglich sind.

Zusätzlich kann man den neuesten Spielstand fortsetzen ODER manuell einen vorhandenen auswählen. Im Moment ist der Ladebildschirm nur ein minimales Bevy-UI-Fenster. Deutlich sicherer zu spielen für nicht viel Programmieraufwand.

Aktuell sind 5 Speicherstände im 5-Minuten-Takt Standard, aber wenn du die config.toml bearbeitest, kannst du das ändern.

Crash-Reporting & Logging-Überarbeitung

Das Top-Feature, das ich als Entwickler wollte, war ordentliches Logging und Crash-Reporting in Produktions-Builds. Zwar hab ich versucht, alles sauber zu halten, aber das Logging hab ich vernachlässigt. Ich habe wild print! println! eprint! eprintln! info! warn! error! durcheinander benutzt. Debug-Prints wurden zu permanenter Ausgabe.

Im Windows-Build konnte man die Hälfte davon nicht sehen, selbst wenn man das Spiel aus PowerShell gestartet hat. Hab das Problem in drei Schritten angegangen:

1. Alle stdout/err-Sachen rauswerfen außer info! warn! error! und panic!. Plugin für Plugin migriert.
2. Ein non-blocking Tracing-Capture-System hinzugefügt, das die Ausgabe an eine Log-Datei anhängt.
3. Logik rund um die Log-Datei geschrieben. Wenn es keinen sauberen Exit gab, bekommt der Spieler die Option, die Logs automatisch als Teil eines Crash-Reports hochzuladen.

Spieler haben jetzt Logs, die sie bei Bedarf prüfen können, und können diese Logs automatisch als Teil eines Crash-Reports hochladen. Klar, etablierte Game-Engines haben sowas eingebaut, aber ich bin einfach froh, es jetzt zu haben. Keine „was hast du gemacht, kurz bevor das Spiel abgestürzt ist?"-Diskussionen mehr.

Zuletzt habe ich eine kleine Library hinzugefügt, die Panics in der GUI anzeigt. Im allerschlimmsten Fall kann ein Spieler die Ausgabe kopieren und einfügen.

Einstellungen-Überarbeitung

Das ist das Zeug, auf das ich super stolz bin. Vor dem neuesten (internen) Build konnte man nicht auf die Einstellungen im Spiel zugreifen, und jede Änderung erforderte einen Neustart. Nicht gut.

Ich schieb's auf meine Backend-Programmier-Vergangenheit. Nachdem Spieler mir gesagt hatten, dass der Zustand der Einstellungen nicht wirklich akzeptabel war, hab ich mich an die Überarbeitung gemacht.

Hab einen ECS/Bevy-zentrierten Ansatz gewählt und finde, es ist gut gelaufen.

Die Einstellungen funktionieren jetzt so: Sie werden zur/von der config.toml-Datei serialisiert/deserialisiert und sind im Spiel als eine Reihe von Resource-Structs dargestellt.

Hab ein paar Systeme hinzugefügt, die laufen, wenn diese Structs erstellt oder geändert werden, und die Komponenten aktualisieren, die die jeweilige Einstellung widerspiegeln.

Nehmen wir zum Beispiel das Ändern der ScreenSpaceAmbientOcclusion-Einstellungen im Spiel.

In einer ECS-Welt ist das einfach. Wir finden die globale Kamera-Entity, indem wir Entities mit der Exofactory-GlobalCamera-Komponente abfragen. Da die Kamera nur ein Bundle von Komponenten ist, können wir auch die ScreenSpaceAmbientOcclusion-Komponente greifen und in Echtzeit modifizieren, synchron mit der Grafikeinstellungs-Resource.

Das Gleiche gilt für jede Einstellung.

Alle Einstellungen sind einfach Properties in einem Resource-Struct, die auf spezifische Komponenten gespiegelt werden.

Das Ergebnis: Man kann jede Einstellung jederzeit in Echtzeit ändern – inklusive Sprache, Grafik, Fenstergröße/-modus und alles andere.

Ziemlich cool, finde ich.

Wiki

Die Idee hinter dem Wiki: Ein community-orientiertes Wiki bereitstellen, das performant, verfügbar und nicht ausbeuterisch ist. Falls niemand einen besseren Ansatz hat, plane ich, das Wiki unter Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International zu lizenzieren.

Ich weiß, es ist etwas früh, das Wiki aufzusetzen, aber ich wollte es aus folgenden Gründen tun:

1. Ein echter Bedarf an Dokumentation rund um die config.toml-Datei.
2. Der Wunsch, Wikis auf weniger community-orientierten Plattformen zuvorzukommen.

Es gibt nicht viel zu sagen, außer dass das Wiki immer nützlicher wird, je näher das Spiel dem Launch kommt.

Im Moment ist die Account-Erstellung geschlossen, wird aber später geöffnet, wenn das Spiel spielbarer wird. Das gesagt: Wenn jemand ein MediaWiki-Theme-Spezialist ist, meldet euch gern. Das Standard-Theme ist okay, aber nicht gerade ideal.

Fazit

ECS zeigt mal wieder, wie cool es ist. Von „Neustart bei jeder Einstellungsänderung" zu „alle Änderungen werden live angewendet" war schockierend einfacher als erwartet.

Das und das Speichersystem MIT Crash-Reporting ist super nice.

Ziemlich happy und freu mich drauf, richtig an der viel besseren Demo 2 zu arbeiten.