</th>	UASTC</th>	ETC1S</th></tr></thead>
Qualität</strong></td>	Fast verlustfrei</td>	Verlustbehaftet, niedrigere Qualität</td></tr>
VRAM-Verbrauch</strong></td>	~1 Byte/Pixel</td>	~0,5 Bytes/Pixel</td></tr>
Dateigröße</strong></td>	Größer (mit Zstd)</td>	Viel kleiner</td></tr>
Transcode-Geschwindigkeit</strong></td>	Schnell</td>	Sehr schnell</td></tr>
Geeignet für</strong></td>	Normal Maps, UI-Elemente, detaillierte Texturen</td>	Texturen, bei denen Qualität weniger kritisch ist</td></tr> </tbody></table> Für Exofactory bin ich pauschal mit UASTC gegangen, hauptsächlich aus Faulheit. Eigentlich sollte ich ETC1S für Texturen nehmen, bei denen niedrigere Qualität nicht auffallen würde und die VRAM-Einsparungen nett wären. Das ist ein TODO für später.</p> Einen Bug in Bevy rund um KTX2 gefunden</h2> Beim Umstieg auf KTX2-Dateien ist mir aufgefallen, dass Bevy die `.meta</code>-Dateien für KTX2-Dateien nicht beachtet hat. Eine kleine PR später</a> und es war gefixt. Der Fix wird in Bevy 0.18.1 enthalten sein.</p>` KTX2 richtig in GLB-Dateien verwenden</h2> Ein größeres, ernsthafteres Problem das ich gefunden hab ist, dass Bevy KTX2-Texturen in GLTF/GLB-Dateien nicht richtig unterstützt. Man kann die KTX-Textur zwar einfach in die Datei reinpacken und es funktioniert in Bevy, aber das Problem ist, dass die resultierende Datei keine konforme GLTF/GLB-Datei ist.</p> Die Ursache ist, dass Bevy gltf-rs</a> als Teil seiner GLB/GLTF-Pipeline verwendet. Die Library ist zwar robust was die offizielle GLTF-2.0-Spec angeht. Aber bei den de-facto verpflichtenden Extensions inklusive KTX2</a> ist sie echt mangelhaft. Ich hab eine PR eingereicht</a>, aber die letzte Code-Änderung war im November 2025 und ich bin nicht optimistisch.</p> Im Moment verwendet Exofactory meinen Fork der Library, aber eine langfristigere Lösung muss her.</p> Ich arbeite gerade an einem Dokument mit ein paar Ideen, die dem Bevy-Core-Team gepitcht werden sollen, basierend auf deren Anfrage.</p> Ergebnisse</h2> Nach den Verbesserungen in den oben genannten 4 Bereichen ist das Spiel massiv besser optimiert. Das Spiel ging von 7GB System-RAM auf unter 1GB. Von 7GB VRAM auf unter 2GB. Mein alter Laptop schafft jetzt 60fps auf niedrig, was mobile Entwicklung wieder möglich macht. War ein großer Push, aber absolut die Mühe wert.</p> Tooling</h1> Als kleines Nebenprojekt hab ich diesen Monat an BevyDex.dev</a> gearbeitet. Ist im Grunde ein dünner Wrapper um die crates.io</a>-API und eine Postgres-Datenbank.</p> Aber es ist immer aktuell, zeigt wichtige Details und ist blitzschnell(tm).</p> Ist ein Nebenprojekt, das nichts mit Exofactory zu tun hat. Aber es wurde gebaut, damit ich mich durch das Ökosystem sortieren kann, und ich hoffe, andere finden es auch nützlich.</p> Finanzen</h1> Zu guter Letzt: Exofactory wird bald offiziell mehrere Publisher kontaktieren. Aufgrund persönlicher Ereignisse kann ich zwar coden, aber das ganze Spiel nicht alleine finanzieren. Hoffentlich kommen da bald interessante Neuigkeiten. Falls jemand Ratschläge hat, immer her damit.</p> Fazit</h1> Ich programmiere lieber als an Pitch Decks zu arbeiten. Ich fixe lieber Bugs upstream wenn ich kann. Und ich freue mich, Sachen rauszubringen, die ich für nützlich halte.</p> Multiplayer, Bevy 0.18 und Fosdem Unknown — Wed, 04 Feb 2026 00:00:00 +0000 Überblick</h1> Diesen Monat ging es im Grunde ausschließlich darum, Multiplayer-Funktionalität einzubauen – mit einer kleinen Pause für die Bevy-0.18-Migration.</p> Wenn du das interessant findest und das Spiel spannend klingt, gib dem Spiel gern eine Wunschliste auf Steam</a>. Das hilft enorm.</p> Ich muss sagen, ich bereue es, nicht früher mit dem Multiplayer-Code angefangen zu haben. Wie bei Internationalisierung und Speicherständen ist Multiplayer etwas, das man von Anfang an in die Architektur einplanen sollte. Die gute Nachricht: Der Code war sauber genug, dass der Refactor nicht allzu</em> schmerzhaft war.</p> Ansonsten war die Migration von 0.17 auf 0.18</a> ziemlich unkompliziert. Ich musste ein paar weniger gepflegte Crates aufgeben, aber die eigentliche Migration war simpel.</p> Zu guter Letzt hab ich mir die Zeit genommen, zur Fosdem zu fahren, um die Bevy-Community zu treffen. Ich selbst hatte keinen Talk, aber Thierry Berger</a> hat einen hervorragenden Vortrag über mobile Bevy-Spieleentwicklung</a> gehalten.</p> Multiplayer</h1> </picture> Das Spiel unterstützt gleichzeitiges Hosten und Beitreten über Direct Connect, LAN und Steam-Multiplayer.</figcaption> </figure> </div> Leuten, die Spiele mit Bevy schreiben, hab ich bisher immer geraten, sich früh Gedanken über Internationalisierung, Gamepad-Unterstützung und Speicherstände zu machen. Jetzt bereue ich, dass ich den wahrscheinlich wichtigsten Faktor vergessen habe – nämlich Multiplayer und Netcode.</p> Dementsprechend meine aktualisierte Liste von Dingen, die man früh bedenken sollte:</strong></p> Multiplayer / Netcode</li> Gamepad-Unterstützung</li> Speicherstände</li> Internationalisierung</li> </ol> All das nachträglich einzubauen ist nervig und schmerzhaft. (Fragt mich, woher ich das weiß! /s)</p> Exofactory-Spezifika</h2> Exofactory ist ein Fabrikspiel, in dem man als KI spielt, die über kleine Roboter namens „Exoframes" mit der Welt interagiert. Diese müssen erst gebaut werden. Wenn man gerade keinen Exoframe steuert, kann man im globalen Kameramodus über die Fabriken fliegen.</p> Das ergibt einen ziemlich natürlichen kooperativen Ansatz: Neue Spielende können im globalen Modus beitreten, sich umschauen und bestehende Maschinen konfigurieren. Sobald ein Exoframe frei ist, kann man ihn „besetzen" und die Welt jenseits der Fabrik-Sensorreichweite erkunden und ausbauen.</p> Das führt zu einem schönen Multiplayer-Metaplot und gleichzeitig zu einer klaren technischen Aufgabenstellung für den Netcode:</p> Im globalen Modus mit der Welt interagieren, einschließlich Bauen.</li> Einen Exoframe aus einem Pool auswählen und steuern.</li> Den Rest der Welt simulieren und die relevanten Komponenten aktualisieren.</li> Sicherstellen, dass der Client die Welt korrekt sieht.</li> </ol> Für mich führt das ziemlich natürlich zu einem Server-autoritativen Modell. Die Server-Instanz des Spiels simuliert die Welt, und die Client-Instanzen nehmen einfach daran teil.</p> Bibliothek auswählen</h2> Zum Zeitpunkt auf Bevy 0.18 scheint es zwei gut unterstützte Crates zu geben: bevy_replicon</a> und lightyear</a>.</p> Ich empfehle, sich beide anzuschauen – beide haben ihre eigenen Vorteile. Nach meinem (möglicherweise fehlerhaften) Verständnis bietet lightyear mehr Features wie Client-Side Prediction</a>, deterministische Replikation</a> und Interest Management (nur relevante Daten synchronisieren), allerdings mit mehr initialem Aufwand und Komplexität. Replicon lässt diese Features standardmäßig weg, ist dafür aber einfacher aufzusetzen mit weniger Entwicklungsaufwand. Falls ich hier falsch liege, korrigiere ich das gerne – meldet euch einfach.</p> Edit:</strong> Jemand hat sich tatsächlich gemeldet! Wie sich herausstellt, unterstützt bevy_replicon doch deterministische Replikation und Interest Management. Die Features, die im Vergleich zu lightyear fehlen, sind Client->Server-Replikation, Lag Compensation, Client-Side Prediction und Interpolation. Außerdem plant lightyear, Replicon für die Replikation wiederzuverwenden.</p> Für Exofactory habe ich mich für das einfachere Replicon entschieden, weil das Spiel definitiv kein</em> hektischer Shooter ist, mein geplantes Feature-Tempo eher gemächlich ist und ich bei Netcode noch relativ grün hinter den Ohren bin.</p> Das gesagt: Wenn die Spielarchitektur bereits gut strukturiert ist, dürfte ein späterer Wechsel kein allzu schmerzhafter Prozess sein.</p> Von Singleplayer zu Multiplayer</h2> Im Kern macht Replicon zwei Dinge: Komponenten replizieren und Netzwerk-Events/Nachrichten an und von Clients verarbeiten.</p> Um Multiplayer zu ermöglichen, musste ich mehrere Systeme refactoren und logisch gruppieren.</p> </p> Autoritative Kernsysteme</h3> Diese laufen nur auf der Server-Instanz und aktualisieren die Welt (also alle Komponenten, die den Spielzustand speichern) für alles, was nicht direkt vom Spieler manipuliert wird.</p> Dazu gehören Dinge wie der Maschinenzyklus, der Eisenerz in Eisenbarren verwandelt, welche Sounds abgespielt werden sollen, und sogar die Abbaurate, die ein Exoframe hat, während man zuschaut. Es gibt noch viel mehr Systeme, aber das sind die typischen in dieser Gruppe.</p> Diese Systeme dürfen direkt in Komponenten schreiben. Replicon repliziert diese Änderungen automatisch zur Client-Instanz der Komponenten.</a></p> Player-UI-Systeme</h3> Diese laufen nur auf Spielinstanzen, in denen tatsächlich jemand spielt. Sie spielen Sounds ab, zeigen die Bau-UIs an und informieren den Spieler über den Weltzustand. Diese Systeme lesen den Weltzustand, indem sie die lokalen Komponenten lesen, die automatisch synchron gehalten werden.</p> Der Teil, der den großen Refactor erforderte: In diesen Systemen ist keine direkte Manipulation von Komponenten erlaubt. Die Clients müssen ein Event/eine Nachricht an den Server schicken</a>, der dann im Auftrag des Clients die Komponenten manipuliert und die Änderungen repliziert.</p> Netzwerk-Nachrichten & Events</h3> Im obigen Diagramm hab ich nur ein Beispiel gezeigt, aber in Wirklichkeit passiert so ziemlich alles im Spiel über „Gucken"</em> hinaus per Event oder Nachricht. Das gilt auch für den Spieler auf der Server-Instanz des Spiels.</p> Das ist meiner Meinung nach DER wichtigste Faktor, wenn man an einem Bevy-Spiel arbeitet, das irgendwann Multiplayer unterstützen soll. Hätte ich das von Anfang an so gemacht, wäre das Hinzufügen der Multiplayer-Funktionalität einfach gewesen. Auch wenn man anfangs nicht an Netzwerk denken möchte – allein sicherzustellen, dass alle Spieler-Manipulationen der Welt über die nativen Bevy-Event-Systeme</a> oder Message-Systeme</a> laufen, spart später enorm viel Zeit.</p> Auswirkungen & Ergebnisse</h2> </p> Es gab zwei interessante Nebeneffekte. Der erste war etwas, das ich eigentlich erst später angehen wollte, aber durch den Refactor deutlich einfacher wurde: eine Headless-Server-Instanz, die man per Docker/Podman etc. selbst hosten kann. So kann die Fabrik weiterlaufen, ohne dass jemand das Spiel auf dem PC offen halten muss.</p> Durch den Refactor und einen neuen Feature-basierten Build, der MinimalPlugins</a> statt DefaultPlugins</a> verwendet, bekommt man eine schlanke Headless-Server-Instanz, die so ziemlich überall laufen kann – sogar auf den meisten RISC-V-SBCs!</p> Das muss noch getestet werden, aber es sieht gut aus. Oben ist ein ähnliches Diagramm, aber für die Headless-Version des Spiels.</p> Der zweite interessante Nebeneffekt: Ich verwende deutlich weniger Bevy Resources</a>, weil Replicon keine Resources repliziert. Stattdessen nutze ich viel mehr Pseudo-Singletons</a> (also eine „leere" Entity, die nur die Komponente hat, die die Daten hält, die vorher in der Resource steckten).</p> Ich bin kein großer Fan von objektorientierten Design Patterns, also ist das schon etwas witzig und fühlt sich ein bisschen dreckig an.</p> Bevy-0.18-Migration</h1> Ich hab das Licht gesehen! Nein wirklich – jedes Bevy-Spiel mit Beleuchtung sollte die Migration priorisieren. Da wurde richtig was gemacht, und das Spiel sieht merklich besser aus. Aber auch wenn euer Spiel kein Licht verwendet, solltet ihr trotzdem migrieren.</p> Abgesehen von ein paar Shader-Bind-Group-Sachen (also BindGroupLayout -> BindGroupLayoutDescriptor</a>) und Atmosphere</a>-Änderungen war es eine einfache Migration.</p> Schön zu sehen, dass der Release-Zyklus wieder im Takt ist.</p> Allerdings muss ich sagen: Mit jedem Upgrade sehe ich mehr Plugins, die auf der Strecke bleiben. Das lässt mich die Maintainer von Plugins umso mehr schätzen. Mit Bevys Release-Zyklus Schritt zu halten, ist im Vergleich zu jeder anderen Game Engine eine ordentliche Aufgabe.</p> Fosdem!</h1> Apropos – ich hatte das Vergnügen, die Fosdem</a> zu besuchen, ein Open-Source-Treffen, das jedes Jahr in Brüssel stattfindet.</p> Wenn ihr euch für Open-Source-Game-Engines interessiert – oder ehrlich gesagt für Open Source generell – kann ich nur empfehlen, hinzugehen. Es gibt massenhaft spannende Talks, aber das Beste (zumindest für mich) ist, die Leute zu treffen, mit denen man sonst nur online redet. Das Bevy-Abendessen mit Thierry Berger</a>, Gee</a>, Niklas Eicker</a>, Firestar99</a> und einigen anderen netten Leuten war richtig gut.</p> Fazit</h1> Ich dachte, ich krieg Multiplayer in einer Woche hin, aber es hat einen Monat gedauert – wie irgendwie erwartet. Ich bin ein besserer Spieleentwickler durch die Erfahrung. Man kann sich halt nicht für alles nur auf Backend-Patterns verlassen.</p> Die Bevy-0.18-Migration war unkompliziert.</p> Ich kann die Fosdem nur empfehlen, wenn ihr die Gelegenheit habt.</p> Echtzeit-Einstellungen, Speicher-Überarbeitung & ein Wiki Unknown — Tue, 30 Dec 2025 00:00:00 +0000 Übersicht</h1> 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.</p> 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</a>. Das hilft enorm.</p> Außerdem habe ich kürzlich die öffentliche Demo von Steam genommen. Sie spiegelt inzwischen WIRKLICH</em> 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.</p> Also, hier die neuesten Arbeitsbereiche.</p> Speicher-Überarbeitung</h2> </picture> Wir können jetzt das letzte Spiel fortsetzen oder einen bestimmten Spielstand laden.</figcaption> </figure> </div> 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</a> und einer kleinen State Machine.</p> So wird automatisch gespeichert, während manuelle Speicherungen weiterhin möglich sind.</p> 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.</p> Aktuell sind 5 Speicherstände im 5-Minuten-Takt Standard, aber wenn du die config.toml</code> bearbeitest, kannst du das ändern.</p> Crash-Reporting & Logging-Überarbeitung</h2> 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!</code> println!</code> eprint!</code> eprintln!</code> info!</code> warn!</code> error!</code> durcheinander benutzt. Debug-Prints wurden zu permanenter Ausgabe.</p> 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:</p> Alle stdout/err-Sachen rauswerfen außer info!</code> warn!</code> error!</code> und panic!</code>. Plugin für Plugin migriert.</li> Ein non-blocking Tracing-Capture-System hinzugefügt, das die Ausgabe an eine Log-Datei anhängt.</li> 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.</li> </ol> </picture> Nach einem erkannten Crash können wir Logs hochladen.</figcaption> </figure> </div> 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?"</em>-Diskussionen mehr.</p> Zuletzt habe ich eine kleine Library hinzugefügt, die Panics in der GUI anzeigt</a>. Im allerschlimmsten Fall kann ein Spieler die Ausgabe kopieren und einfügen.</p> Einstellungen-Überarbeitung</h2> </video> Du kannst Grafikeinstellungen in Echtzeit ändern.</figcaption> </figure> 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.</p> 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.</p> Hab einen ECS/Bevy-zentrierten Ansatz gewählt und finde, es ist gut gelaufen.</p> Die Einstellungen funktionieren jetzt so: Sie werden zur/von der config.toml</code>-Datei serialisiert/deserialisiert und sind im Spiel als eine Reihe von Resource-Structs dargestellt.</p> 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.</p> Nehmen wir zum Beispiel das Ändern der ScreenSpaceAmbientOcclusion</a>-Einstellungen im Spiel.</p> In einer ECS-Welt ist das einfach. Wir finden die globale Kamera-Entity, indem wir Entities mit der Exofactory-GlobalCamera</code>-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.</p> Das Gleiche gilt für jede Einstellung.</p> Alle Einstellungen sind einfach Properties in einem Resource</a>-Struct, die auf spezifische Komponenten gespiegelt werden.</p> Das Ergebnis: Man kann jede Einstellung jederzeit in Echtzeit ändern – inklusive Sprache, Grafik, Fenstergröße/-modus und alles andere.</p> </video> Sprache und alles andere auch.</figcaption> </figure> Ziemlich cool, finde ich.</p> Wiki</h2> Die Idee hinter dem Wiki: Ein community-orientiertes Wiki</a> 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</a> zu lizenzieren.</p> Ich weiß, es ist etwas früh, das Wiki aufzusetzen, aber ich wollte es aus folgenden Gründen tun:</p> Ein echter Bedarf an Dokumentation rund um die config.toml</a>-Datei.</li> Der Wunsch, Wikis auf weniger community-orientierten Plattformen zuvorzukommen.</li> </ol> Es gibt nicht viel zu sagen, außer dass das Wiki immer nützlicher wird, je näher das Spiel dem Launch kommt.</p> 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.</p> Fazit</h1> 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.</p> Das und das Speichersystem MIT</strong> Crash-Reporting ist super nice.</p> Ziemlich happy und freu mich drauf, richtig an der viel besseren Demo 2 zu arbeiten.</p> Ziehbare Fließbänder, Elektrizität & Ansichtsmodi Unknown — Thu, 04 Dec 2025 00:00:00 +0000 Übersicht</h1> Diesen Monat habe ich mich auf ein paar neue Bereiche konzentriert: wichtige Spielmechaniken, Visuals und große Quality-of-Life-Verbesserungen bei der Fließband-Platzierung.</p> Wir kommen dem Ziel immer näher, das gesamte Feedback vom Oktober-Nextfest umzusetzen, das sich durch reines Programmieren lösen lässt – und ich denke, man sieht es dem Spiel an.</p> Ich bin super happy, Elektrizität hinzugefügt zu haben. Es ist ein Kern-Feature, und während das Hinzufügen selbst nicht so schwer war, war die Visualisierung kniffliger. Aber ich finde, der Shader-basierte Ansatz sieht richtig cool aus. Super zufrieden mit dem Produktivitäts-/Effizienz-Ansichtsmodus-Shader unten.</p> In den folgenden Abschnitten gehe ich etwas tiefer ins Detail.</p> Ziehbare Fließbänder</h1> </video> Fließbänder ziehen, um Gebäude zu verbinden, ist jetzt einfach.</figcaption> </figure> Ziemlich viel Zeit ging für ziehbare Fließbänder drauf. Die Band-für-Band-Platzierung wie in Factorio funktioniert zwar, aber beim Spielen wurde mir klar, dass es schnell nervt. Das Feedback war da universal einer Meinung.</p> Das Interessante ist, dass Exofactory einen "kachelbasierten" Fließband-Ansatz verwendet, weshalb der Spline-basierte Ansatz anderer Fabrikspiele nicht wirklich möglich war. Nach dem Spielen vieler anderer Fabrikspiele</del> ausgiebiger Recherche habe ich einen Ansatz gefunden, der ähnlich wie bei Shapez2</a> funktioniert – angepasst für 3D und die Eigenheiten von Exofactory.</p> Kurz gesagt: Man platziert das erste Fließband-Segment und kann dann ein gerades oder "L"-förmiges Segment beliebiger Länge herausziehen, solange man die Ressourcen dafür hat. Die einzige echte technische Einschränkung ist, dass man nur eine Biegung pro gezogenem Segment haben kann. Mehr würde nur zu Mehrdeutigkeit und unvorhersehbaren Ergebnissen führen.</p> </video> Längere Fließband-Verbindungen brauchen jetzt viel weniger Aufwand.</figcaption> </figure> Das macht das Spiel deutlich weniger mühsam und ich bin super froh, dass es fertig programmiert ist.</p> Elektrizität</h1> </video> Gebäude verbinden sich automatisch mit der nächsten Stromquelle in Reichweite.</figcaption> </figure> Ich habe auch kürzlich Strom ins Spiel eingebaut. Alle Gebäude verbrauchen jetzt Elektrizität und funktionieren ohne nicht. Gebäude im Bereich einer Stromquelle oder eines Verstärkers verbinden sich automatisch und beginnen Strom zu verbrauchen.</p> Im Moment erzeugt der Core genug Strom, um eine kleine Fabrik zu betreiben. Sobald ich Brennstoffe und Rohrleitungen richtig einbaue, wird es möglich sein, die Stromproduktion richtig hochzufahren.</p> Vom Programmier-Standpunkt aus war das ein ziemlich einfaches Feature. Einfach ein paar ECS</a>-Komponenten hinzufügen und fertig – Gebäude aktualisieren ihre Komponenten während ihrer Zyklen und die Stromsysteme fragen sie entsprechend ab.</p> Der schwierige Teil war die Visualisierung. Dazu unten mehr.</p> Ansichtsmodi</h1> Ein Feedback-Punkt war: „Was bringt der Global-Modus eigentlich?"</em> – und ehrlich gesagt ist der globale Ansichtsmodus in der Demo weniger nützlich, als er sein sollte. Der Hauptgrund: Die Ansichtsmodus-Features waren noch nicht da.</p> Jetzt kann ich sie endlich zeigen. Meine Güte, musste ich viel über Shaders</a>, Stencils</a> und Skinning</a> lernen, um das zum Laufen zu bringen.</p> Die Ansichtsmodi sind im Global-Modus über die Tab-Taste oder den entsprechenden Controller-Button erreichbar.</p> Strom</h2> </video> Man sieht die versorgten Zonen und welche Gebäude und Kabel Strom haben oder nicht.</figcaption> </figure> Dieser Ansichtsmodus zeigt, welche Gebäude Strom haben und welche nicht. Man sieht auch die versorgten Zonen und welche Kabel verbunden sind. Einfach, schnell und nützlich.</p> Obwohl die Ansichtsmodi ein Feature für den Global-Modus sind, kann man beim Platzieren von Stromverstärkern die versorgten Zonen und so weiter sehen – einfach um den Verstand zu schonen.</p> Produktivität</h2> </video> Die Farbe der Gebäude zeigt ihre Produktivität. Grün für 100%, Rot für 0%.</figcaption> </figure> Darauf bin ich ziemlich stolz und ich denke, es bringt etwas Neues ins Fabrikspiel-Genre. Der Produktivitätsmodus zeigt auf einen Blick die Produktivität einer ganzen Landschaft von Maschinen. Rote oder gelbe Bereiche einer Fabrik fallen sofort auf.</p> Im Video oben sieht man, wie die Produktivität sinkt, wenn sich der Ausgabepuffer füllt. Wie der Strom-Ansichtsmodus ist dieser Modus über die Tab-Taste im Global-Modus erreichbar.</p> Fazit</h1> Es hat sich richtig gut angefühlt, endlich mal wieder ein neues Feature hinzuzufügen nach so vielen Bugfixes. Super happy damit. Jetzt muss ich nur noch das Emotional-Core-/Dialogsystem anpassen, um diese neuen Systeme widerzuspiegeln. Viel Spaß und viel zu tun.</p> Quality-of-Life-Änderungen, welche sich für ein Fabrikspiel gehören Unknown — Sun, 16 Nov 2025 00:00:00 +0000 Übersicht</h1> In den letzten Wochen gab es zwei Haupttreiber für meine Arbeit: das Feedback aus der Demo und die Portierung von Bevy 0.16 auf 0.17</a> sowie der Wechsel zur Avian</a>-Physik-Engine.</p> Unten gehe ich auf die neuen Quality-of-Life-Verbesserungen aus dem Feedback ein, aber zuerst möchte ich erklären, warum ich zu Avian gewechselt bin und welche Arbeit das mit sich brachte.</p> Wechsel zu Avian</h2> </picture> Automatisch generierte Avian-Collider-Meshes</figcaption> </figure> </div> Ursprünglich habe ich das bewährte Rapier 3D</a> genutzt, war aber aus mehreren Gründen unzufrieden.</p> Hohe Entwicklungslatenz. Angesichts der schnellen Veränderungen im Bevy-Ökosystem und den großen Verbesserungen in jeder Version war das ein echter Motivationskiller. Zum Zeitpunkt dieses Posts unterstützt Rapier noch immer kein Bevy 0.17.</li> Etwas sperrige, nicht ganz elegante API.</li> Keine automatische Collider-Generierung.</li> </ol> Trotzdem: Rapier ist eine solide Engine, und die Arbeit von dimforge</a> für die Bevy-Community ist großartig. Sie ist einfach nicht der beste Fit für mich.</p> Der Wechsel zu Avian hat all diese Punkte adressiert und Dinge wie Raycasting</a> deutlich angenehmer gemacht.</p> Dazu kommt das hervorragende Collider-Konstruktionssystem</a>. <3 ConvexDecompositionWithConfig</a></p> Ein kleines Problem gab es dennoch: Avian hat keinen eigenen Character Controller</a> wie Rapier. Nach einem Blick in die Avian-FAQ</a> bin ich aber bei bevy_tnua</a> gelandet – eine ausgezeichnete Alternative.</p> Zeitlich hat der gesamte Port einen Tag gedauert. Ungefähr:</p> 2 Stunden für alle Collider und das Feintuning.</li> 3 Stunden, um das Raycasting auszutauschen und die Collision Layers</a> einzurichten. (Mit Enums sehr angenehm.)</li> 3 Stunden, um die komplette Spielersteuerung auf tnua umzuziehen.</li> </ul> Dank der Arbeit von Joona Aalto</a> bin ich sehr zufrieden mit Avian. Ich unterstütze ihn gern – und wenn ihr Avian mögt, könnt ihr das auch überlegen.</p> Allgemeine Quality of Life</h1> </video> Wir können jetzt springen!</figcaption> </figure> Da tnua das Implementieren eines Sprungs einfach gemacht hat, habe ich ihn direkt eingebaut. Mit einer leicht umfunktionierten Animation – mehr dazu später – war das schnell erledigt.</p> </picture> Die Baukosten werden jetzt direkt im Menü angezeigt.</figcaption> </figure> </div> Hier kommt die erste große Verbesserung basierend auf Feedback. Es wurde sehr deutlich, dass die Kosten von Gebäuden klar und zu jedem Zeitpunkt sichtbar sein müssen: davor, währenddessen und wenn man etwas nicht bauen kann. Jetzt sieht man beim Hovern oder Auswählen eines Gebäudes sofort die Kosten.</p> </picture> Beim Platzieren sieht man die Kosten plus vorhandene Ressourcen.</figcaption> </figure> </div> Maschinenproduktivität</h1> </video> Die Mining-Maschine zeigt jetzt ideale und reale Outputs.</figcaption> </figure> Hier steckt der Großteil der Arbeit drin. Durch das Feedback von Factory-Game-Fans wurde mir schmerzhaft bewusst, dass ich einen absolut grundlegenden Punkt des Genres vergessen hatte: Spieler müssen klar sehen können, was verbraucht wird, was erzeugt wird und wo sie optimieren können.</p> Ich spiele selbst gern Satisfactory</a> und Factorio</a>. Keine Ahnung, wie ich das übersehen habe. Aber jetzt ist es drin.</p> Und: Es war ein Vergnügen, das mit Bevys ECS-System umzusetzen. Für solche Berechnungen gibt es schlicht keinen besseren Ansatz. Man fragt einfach alle Maschinen ab, deren Werte aktualisiert werden müssen, verarbeitet sie parallel und macht weiter. Wunderbar.</p> </video> Der Ofen zeigt klar, was er wirklich braucht und was er produzieren sollte.</figcaption> </figure> Einstellungen</h1> Ein weiterer Grund, warum ich auf Bevy 0.17 gewartet habe, war das überarbeitete UI-System mit Observers</a>. Damit konnte ich weg von Buttons und hin zu Slidern – deutlich sauberer. Mit Observers fühlt sich UI-Programmierung weniger sperrig an. Die Einstellungsseite ist jetzt viel besser.</p> Eine wichtige Verbesserung betrifft die Controller-Anzeige. Zuvor wurden Tastatur- und Maussteuerungen angezeigt, außer man hatte einen Xbox- oder Steam-Controller eingesteckt. Das führte zu Situationen, in denen Spieler nicht die passenden Hinweise sahen. Jetzt zeigt das Spiel standardmäßig an, was zuletzt genutzt wurde. Sehr viel besser.</p> </p> </p> </p> Website-Überarbeitung</h1> Noch im Aufbau, aber ein klares Feedback war, dass die Website kaum erklärt, worum es im Spiel überhaupt geht. Eine reine Textseite ist für ein Videospiel eher unüblich. Daher gibt es jetzt eine animierte Startseite.</p> In den kommenden Wochen werde ich weitere Bereiche mit mehr Medien und Informationen ergänzen. Dranbleiben lohnt sich.</p> Fazit</h1> Viele Quality-of-Life-Verbesserungen basierend auf viel Feedback, und es kommt noch mehr. Ich bin ziemlich zufrieden damit und freue mich auf die nächsten Features.</p> Steam-Next-Fest-Nachklang Unknown — Tue, 21 Oct 2025 00:00:00 +0000 Überblick</h1> Das Steam Next Fest war ein Erfolg – wenn auch ein stressiger. Die gute Nachricht: Über Steam, Discord und andere Kanäle kam massenhaft Feedback, und viele Edge-Case-Bugs konnten schnell gefixt werden.</p> Ich wusste nicht, dass so viele Tastaturen dem Betriebssystem melden, sie seien Xbox-HID-Geräte. Verrückt.</p> Auf Basis all der Erkenntnisse kann ich den Fahrplan fürs Spiel nun klarer definieren.</p> Next-Fest-Ergebnisse</h1> Viel Gutes</h2> Zahlreiche Bugs wurden entdeckt und fixiert. Vielen Dank an alle, die sie gemeldet haben.</li> Das Spiel hat enorm viel Interesse geweckt, sowohl bei Wunschlisten als auch bei Spielzeit.</li> Es gab viele Ideen, wie man Dinge verbessern oder reparieren kann.</li> </ul> Weniger Gutes</h2> Ich habe die Hardwarevielfalt außerhalb der Soft-Launch-Tester unterschätzt. Einige Spieler:innen konnten das Spiel erst starten, nachdem mehrere Hotfixes veröffentlicht waren.</li> Ich dachte, das Spiel wäre vollständig barrierefrei für Geräte und Controller – das Feedback zeigte, dass noch Lücken bestehen.</li> </ul> Neuer Zeitplan</h1> Mit dem Demo-Feedback, dem Rat erfahrener Entwickler:innen und dem Input von Leuten, die erfolgreiche Spiele produzieren, ergibt eine Anpassung des Release-Plans Sinn.</p> Q4 2025 war schlicht unrealistisch. Punkt.</p> Also braucht es einen neuen Plan:</p> Eine deutlich funktionsreichere und polierte Demo veröffentlichen, die sich für ein Pitch-Deck eignet und die Zielqualität zeigt.</li> Prüfen, wie die weitere Finanzierung aussehen kann – etwa Kickstarter, Investment oder Zusammenarbeit mit einem Publisher.</li> Den Full Release für Ende 2026 anpeilen.</li> </ol> Wie jemand einmal sagte: „Ein verschobenes Spiel wird irgendwann gut, ein übereilt veröffentlichtes bleibt für immer schlecht.“</em></p> Ob Meme oder nicht – ich will ein Spiel veröffentlichen, auf das ich stolz bin.</p> Fazit</h1> Ich lerne ständig dazu – sowohl beim Spiel als auch bei meiner Sicht auf die Branche. Next Fest und all die Menschen, die sich gemeldet haben, haben mir unglaublich viel beigebracht. Dadurch wird das Spiel besser. Spannende Zeiten stehen bevor – jetzt gibt es einen Berg Feedback, den ich angehen kann.</p> Demo-Release und Feinschliff Unknown — Tue, 07 Oct 2025 00:00:00 +0000 Überblick</h1> Es ist viel passiert, aber das Wichtigste: Die Demo wurde als Soft-Launch auf Steam veröffentlicht – pünktlich zum Steam Next Fest. Du kannst sie über den Link am Ende dieses Beitrags laden. Es gibt Builds für Linux und Windows.</p> Die Arbeit dafür war enorm, und hier fasse ich einiges davon zusammen.</p> Steam Next Fest</h2> </picture> Der hübsche Demo-Download-Button.</figcaption> </figure> </div> Die große Neuigkeit: Wir machen offiziell beim Steam Next Fest im Oktober mit. Alles ist eingerichtet und genehmigt. Der Prozess war überraschend schwierig und deutlich komplizierter, als ich dachte. Es reicht eben nicht, einfach eine ELF</a>- oder .exe</a>-Datei hochzuladen. Man muss eine Menge Steam-spezifischer Tools</a> verwenden – immerhin laufen sie nativ auf Linux. Aber es ist viel zu lernen, besonders wenn man sich nur einen Tag zum Verpacken und Hochladen gegeben hat.</p> Mein Tipp an alle Programmierer:innen, die zu Game-Devs werden: Plant fürs Packaging mehr Zeit ein, als ihr meint zu brauchen. Für mich war ein Steam-Build härter vorzubereiten als ein RPM</a>- oder DEB</a>-Paket.</p> Die gute Nachricht: Die Deadline wurde gehalten – knapp, aber geschafft.</p> Testpannen</h2> Damit sind wir beim nächsten Punkt. Falls du dich für Alpha/Beta-Tests angemeldet hast: Du wurdest nicht vergessen. Durch</p> die ungeplanten Verzögerungen bei der Steam-Freigabe,</li> die unerwarteten Schwierigkeiten beim Packaging und</li> die vielen „Blocker“-Bugs, die ich auf Zuruf von Freund:innen und Familie gefixt habe,</li> </ol> konnte ich keine frühen Test-Keys hochladen, bevor die Demo fürs Next Fest rausmusste.</p> Sorry dafür. Künftig strukturiere ich den Entwicklungsprozess klarer – mit gezielten Phasen für Features, Tests und Polishing. Für das Hauptspiel wird es regelmäßige, besser planbare Testzeiträume geben.</p> Animationen & Mechaniken</h2> </video> Lifter, Bänder, Splitter und Merger</figcaption> </figure> Hier landete der meiste Crunch. Ein Nachteil von ECS: Unabhängige Animationen zu synchronisieren ist knifflig. Es fühlt sich an, als würde die Welt nach einer Leibnizschen prästabilierten Harmonie</a> laufen – keine expliziten Verbindungen, nur Async-Systeme, die so orchestriert werden, dass Illusion zur Realität wird.</p> Kurz gesagt: Das Spiel verhält sich jetzt wie ein echtes Spiel – mit Animationen, Sound und allem, was dazugehört.</p> Demo veröffentlicht + Trailer</h2> Der spaßige Teil: Auch wenn noch keine Mails rausgingen, lässt sich die Demo schon herunterladen und spielen. Vielleicht schaffe ich noch einen kleinen Bugfix-Build vor dem offiziellen Start des Next Fest. Wenn dir Fehler auffallen, melde sie gern im Exofactory-Bugreport-Channel auf Discord</a>.</p> Außerdem gibt es einen kurzen Gameplay-Trailer! Mangels verifiziertem YouTube-Account läuft er direkt auf der Steam-Seite.</p> Roadmap</h2> Die Demo ist nur der Anfang. Für das vollständige Spiel stehen große Verbesserungen an. Ich bin offen für Vorschläge – poste sie gern im Feature-Suggestion-Channel auf Discord</a>.</p> Eine ausführlichere Roadmap folgt bald auf dieser Website. Die Listen hier sind vorläufig und sehr unvollständig.</p> Bald</h3> </picture> Barrierefreiheit zuerst: Steam Deck und Controller</figcaption> </figure> </div> Vollständige, barrierefreie Steam-Deck- und Controller-Unterstützung.</li> Überarbeitung von Terrain- und Vegetations-Assets.</li> Massive Optimierungsrunde.</li> Erste verzweigende Tech-Tree-Pfade basierend auf deinen Entscheidungen.</li> Öffentliches Wiki – wie es sich für ein Fabrikspiel gehört.</li> Weitere Arbeit am „richtigen“ Terrain.</li> Echter Energieverbrauch.</li> Flüssigkeiten.</li> Deutsch.</li> Tests von ELF-Binaries für aarch64</a> und RISC-V</a>, sofern möglich.</li> </ul> Später</h3> Spiel-Binaries für mehr Rust Tier 1- und Tier 2-Plattformen</a>. (Wer hilft beim Test auf den BSDs?)</li> Steam-freie Spieloption à la Factorio</a>.</li> Offiziell unterstützte Flathub</a>-/Flatpak</a>-Images.</li> Laufende Arbeit am „richtigen“ Terrain.</li> </ul> Fazit</h1> Die Demo ist draußen, und ich freue mich darauf, am vollständigen Spiel weiterzuarbeiten. Ich bin gespannt, was ihr daraus macht.</p> Demo auf Steam</span> </div> </a> </div> Private Alpha, Steam & Kernfunktionen Unknown — Mon, 08 Sep 2025 00:00:00 +0000 Überblick</h1> In den letzten 30 Tagen hat das Spiel den Sprung von „ein bisschen Sorge“ zurück auf Kurs geschafft. Wir planen, beim Steam Next Fest im Oktober dabei zu sein! (Mehr unten.) Der Großteil der Arbeit betraf fundamentale Systeme – viel Code, wenig neue Optik. Aber der Code ist jetzt in einem großartigen Zustand. Nächsten Monat sollte das Demo voller neuer Visuals und Sounds sein. Der September steht im Zeichen von Grafik, Feinschliff und Tests. Spannende Zeiten!</p> Private Alpha</h2> In der zweiten Monatshälfte möchte ich eine kleine, fokussierte private Alpha zum Testen veröffentlichen. Wenn du Interesse hast, kannst du dich auf der Homepage</a> anmelden – dort findest du einen Button dafür.</p> Nur zur Warnung: Das wird eine echte technische Alpha mit potenziell vielen Bugs, UI-/UX-Problemen und Playability-Schmerzen. Wenn du einfach nur spielen möchtest, warte lieber auf das Steam Next Fest. Wenn du Lust hast zu debuggen und Feedback zu geben, bist du herzlich willkommen.</p> Steam Next Fest</h2> Wir liegen im Zeitplan und planen fest mit dem Steam Next Fest im Oktober. Die Freigabe ist da – wir müssen nur bis Ende September den finalen Demobuild einreichen.</p> Geplant ist eine kostenlose Vertical-Slice-Demo. Ziel: Lass die Leute eine Fabrik nach ihren Vorstellungen bauen und schau zu, wie sich basierend darauf die Story verändert. Ich peile eine kurze Demo an – je nach Bauweise soll sich Stimmung, Ton und Richtung aber unterscheiden. Ohne Skripts sollte jede Session zumindest ein wenig, wahrscheinlich sogar stark variieren.</p> Das Ganze steuert der emotionale Kern – und der ist ziemlich cool.</p> Zur Einordnung: Die Demo wird eher kurz (ca. 10–15 Minuten bei schnellem Spiel). Das vollständige Spiel entsteht gemeinsam mit der Community im Early Access, mit einem Full Release irgendwann 2026.</p> Förderband-Grundlagen & Logistik</h2> Der Löwenanteil der Entwicklung steckte hier drin. Ein Fabrikspiel ohne robustes, performantes Band- und Logistiksystem existiert schlicht nicht.</p> Ich denke, das habe ich jetzt. Erst seit dieser Arbeit verstehe ich, warum andere Devs über den Schmerz von Förderband-Entwicklung klagen. Ich gehöre jetzt offiziell dazu.</p> Der Vorteil: Dank Bevys ECS-Architektur bekomme ich quasi gratis Performance. Alles läuft parallel und nutzt alle CPU-Kerne, damit deine Fabrik smooth durchzieht. Wenn du die Grafik extrem aufdrehst, kannst du die FPS sicher drücken, aber die Größe der Fabrik allein sollte nie zum Problem werden.</p> Hier folgt eine grobe technische Erklärung. Überspring sie gern, wenn du magst.</p> </video> Förderbänder in Aktion</figcaption> </figure> Wie Förderbänder wirklich funktionieren</h3> Bänder organisieren sich automatisch in gerichtete „Segmente“. Segmente bestehen aus Ketten von Bändern zwischen allem, was Items ausgibt, und allem, was welche annimmt. Jede Band-Entität bekommt eine Komponente, die markiert, zu welchem Segment sie gehört. Das passiert über Observer und nur beim Platzieren/Entfernen der Bänder.</p> Zur Klarstellung: Es gibt nirgendwo eine Linked List. Wir taggen schlicht die Band-Entities mit Segment-Komponenten.</p> Verbindungen und Segmentbildung</h3> </p> Gebäude und Bänder deklarieren ihre Ein- und Ausgänge auf dem Grid. Beim Platzieren schaut der IO-Punkt ein Feld in Blickrichtung und verbindet sich nur, wenn der Nachbar kompatibel ausgerichtet ist. Bei Verbindung fügt das Gebäude dem Segment eine Quelle oder Senke hinzu. Oben die großen Debug-Würfel zeigen die überwachten Tiles.</p> Während du Bänder oder Gebäude platzierst, ordne ich die Bänder von echtem Anfang bis Ende neu, damit die Kette kohärent bleibt, und baue einen „Visual Path“-Spline direkt aus den Weltkoordinaten jedes Bandes. Entfernst du ein Band, berechne ich die verbundenen Gruppen neu, splitte Segmente bei Bedarf und weise Gebäuden die richtigen neuen Segmente zu.</p> Das waren gut 95 % der Arbeit.</p> Item-Bewegung</h3> Items bewegen sich entlang eines stückweise zusammengesetzten Satzes von Cubic-Hermite-Splines</a>, die aus den Band-Positionen erzeugt werden. Das ist super effizient, da alle Splines vorab berechnet sind. Wir verschieben die Items nur mit einem Timer, der ebenfalls vorab anhand Segmentlänge und Bandgeschwindigkeit ermittelt wird.</p> Kapazität, Durchsatz und Backpressure</h3> Kapazität wurde nach dem „as simple as possible“-Prinzip gelöst: Eine Band-Entität = ein Item. Ein Segment mit 20 Band-Entities fasst 20 Items. Einfügen klappt nur, wenn Platz ist. Maschinen mit Output-Puffer schieben Items ins Segment, sobald Luft ist. Ist das Segment voll, füllt sich der Puffer und die Produktion pausiert auf natürliche Weise; sobald die Linie frei wird, läuft alles automatisch weiter. Ähnlich funktioniert es bei Inputs.</p> Performance</h3> </p> Alles basiert auf ECS und läuft komplett parallel. Weil Segmente isoliert sind und Bevy großartig ist, kann ich einen Async-Pool aufsetzen, der so breit wie deine CPU-Kerne ist. Segmente verarbeiten ihre Items und schicken sie über das beziehungsbasierte Source/Sink-System weiter. Oben siehst du Gebäude mit hervorgehobenen IOs.</p> Neue Gebäude & Ressourcen</h2> Seit dem letzten Dev-Blog kamen einige neue Gebäude hinzu – alle ziemlich spannend.</p> Mining Platform v1</h3> </video> Die Mining Platform in Aktion</figcaption> </figure> Das ist der erste Rohstoff-Extraktor für Spielende. Er holt Erze vom Planeten, wie es die Menschen einst beigebracht haben.</p> Ancient AI Core</h3> </p> Hier sitzt der Verstand der Spieler-KI. Hier warst du … sehr lange.</p> Sneak Preview: Gasförderer</h3> </p> Hier ein erster Blick auf den Gas-Extraktor. Nicht alles ist schließlich ein Mineral.</p> Musik</h2> Ich freue mich riesig über die Zusammenarbeit mit Repto Eternef</a>. Sie erschaffen großartige Musik fürs Spiel und helfen, die Exofactory-Music-Engine aufzubauen, die wir 2026 vor Release als Open Source veröffentlichen wollen.</p> Dialog & der emotionale Kern</h2> </p> Nicht zuletzt wurde der emotionale Kern plus Dialogsystem implementiert.</p> Der emotionale Kern ist das Herzstück von Exofactory. Technisch betrachtet beobachtet er alle Aktionen der Spielenden: jedes Bauen, Zerstören, jede Bewegung, Produktion – wirklich alles. Zusammen mit einem Blick auf das Gesamtbild deiner Fabrik, die Interaktionen der Systeme und fehlende Verbindungen leitet er die Story-Richtung ab.</p> Ziel ist eine von den Spielenden getriebene Erzählung, allein basierend auf ihrer Fabrik. Ich möchte niemals ein „Wähle Option A oder B“-Popup einsetzen. Das Spiel soll deine Prioritäten kennen, weil es sieht, wie, wo und was du baust.</p> Am deutlichsten spürst du das durch den inneren Monolog der KI, dem du im Spiel zuhörst. Tonfall, Gedankenrichtung und Inhalt werden vom emotionalen Kern an das Dialogsystem geliefert, das sie anzeigt und vertont. Derzeit evaluiere ich Open-Source-TTS-Systeme, die die vielen, vielen potenziellen Zeilen einsprechen können.</p> Fazit</h1> Es gab massive Fortschritte an den Kernsystemen und alles liegt im Plan. Ich bin gespannt, wie Spieler:innen die Systeme nutzen, an denen ich arbeite. :)</p> Exofactory ist jetzt auf Steam verfügbar! Wenn dich das Spiel interessiert, würde ich mich freuen, wenn du es dort auf die Wunschliste setzt.</p> Auf Steam vormerken</span> </div> </a> </div> Animation, Bewegung & Terrain v3 Unknown — Thu, 07 Aug 2025 00:00:00 +0000 Exofactory ist jetzt auf Steam verfügbar! Wenn dich das Spiel interessiert, freue ich mich, wenn du es dort auf die Wunschliste setzt.</p> Auf Steam vormerken</span> </div> </a> </div> Überblick</h1> Mehrere große Ziele wurden erreicht: Das Spiel ist animiert, wir haben erste Ressourcen und das Terrain-System nähert sich dem Status „fertig“. Es war nicht die produktivste Periode überhaupt, aber der Kurs stimmt.</p> Außerdem habe ich auf Bornhack 2025</a> einen Vortrag über Spieleentwicklung in Bevy mit Rust gehalten. Er ist noch nicht veröffentlicht – sobald das Video online ist, verlinke ich es in einem späteren Dev-Blog.</p> Animation</h1> Es gibt jetzt Animationen im Spiel! Animationen in Bevy zu lernen hat Spaß gemacht. Der Lebensretter (und enorme Zeitersparnis) war das Bevy-Ökosystem, konkret das hervorragende Bevy/Blender-Plugin Skein</a> von Chris Biscardi</a>. Er tut unglaublich viel für die Bevy-Community und ich sehe seine Arbeit überall.</p> Skein ist ein Plugin sowohl für Bevy als auch für Blender und erlaubt 3D-Artists, Bevy-Komponenten (falls dir Bevy neu ist: Komponenten sind quasi Tags) direkt an Teilen eines 3D-Assets zu hinterlegen. Beim Export als glb/gltf werden diese Komponenten mit gespeichert.</p> Auf der Bevy-Seite liest Skein die eingebetteten Komponenten aus und stellt sie im Entity Component System</a> bereit. Das spart massig Zeit und Boilerplate.</p> </video> Programmgesteuerte Steuerung der Lifter-Animation</figcaption> </figure> Wir nutzen Skein, um Animation-Bones mit Komponenten zu versehen. So lassen sich Animationen programmatisch steuern und auf Spielereignisse reagieren, statt nur stupide Schleifen abzuspielen. Hauptsächlich setzen wir das derzeit bei den Liftern ein, wie oben zu sehen.</p> </video> Animationstransitionen</figcaption> </figure> Zusätzlich verwenden wir Bevy's Animation-Graph-System</a>. Damit wechseln wir weich von einem Animationszyklus zum anderen – ohne Ruckler oder Artefakte. Im Beispiel geht der Exoframe fließend vom Laufen in den Idle-Zustand über.</p> Ressourcen</h1> Wir haben nun Ressourcen! Den Anfang machen Eisen und Kupfer. Bald werden Maschinen richtig loslegen.</p> Hier siehst du Kupfererz und -barren. Davon wird es reichlich geben, unter anderem für stromsparende Kabel.</p> Und hier Eisen. Ich liebe die Details auf der Oberseite der Barren. Da wir als KI spielen, kann ich mir vorstellen, dass die KI den Look ebenfalls feiert.</p> Terrain v3</h1> Die Bevy-Welt ist voll von halbgar gepflegten und schlecht dokumentierten Terrain-Level-of-Detail-Systemen (LoD)</a>. Es gibt unzählige Ansätze, aber ich habe keinen gefunden, der gepflegt, funktionsreich und ordentlich dokumentiert ist. Deshalb hat Exofactory jetzt eine eigene LoD-Implementierung. Noch relativ simpel, aber sie erfüllt meine Basisanforderungen:</p> Terrain abhängig von der Position mehrerer</em> Kameras ein- und ausblenden.</li> Höher- und niedrigauflösende Meshes sowie Texturen anhand dieser Kameras austauschen.</li> LoD auch für Details wie Vegetation oder Steine handhaben.</li> Das Ganze performant und Bevy-nativ im ECS umsetzen.</li> </ol> </video> Tests des Level-of-Detail-Systems</figcaption> </figure> Oben siehst du das Testterrain, mit dem ich das System geprüft habe: Grün markiert die Kachel unter der aktiven Kamera, Gelb die höher aufgelösten Tiles, Rot die niedrigeren – und das entfernte Rot wird despawnt.</p> Das ist eine deutlich stärkere Grundlage für Terrain, auch wenn viel Arbeit aus früheren Versionen neu geschrieben werden musste. Gute Nachricht: Terrain v3 lässt sich hervorragend auf Ästhetik oder Performance abstimmen. Selbst auf meinem alten 11th-Gen-Intel-Laptop mit iGPU lief die volle Sichtweite bei 60fps. Klar, das kann sich ändern, wenn mehr Systeme hinzukommen.</p> </video> Terrain v3 nur mit Grundfarben</figcaption> </figure> Hier eine weiterentwickelte (weiterhin texturlose und noch leere) Version des Terrain-v3-Systems mit kompletter LoD-Funktionalität. Texturen und Details kommen später per Shader auf der GPU – die Grundfarben geben schon eine Idee, wohin es stilistisch geht. Sobald wir Terrain-Details ergänzen, wird das richtig gut aussehen.</p> Fazit</h1> In dem Zeitraum hätte ich gern mehr geschafft. Trotzdem war alles, was fertig wurde, sehr wirkungsvoll: Das Spiel ist spielbarer – und wichtiger in dieser Phase – besser testbar. Keine Ruckler mehr beim Überqueren von Terrain-Kacheln. Alles wirkt weich und angenehm. Und die Animationen bringen richtig Leben in die zuvor statische Welt.</p> Terrain, Animationen und jede Menge Fortschritt Unknown — Sun, 06 Jul 2025 00:00:00 +0000 UPDATE:</strong> Wir wurden freigeschaltet – Exofactory ist jetzt auf Steam verfügbar</a>.</p> Überblick</h1> Der vergangene Monat war voller Fortschritte. Das Terrain wurde komplett überarbeitet (mehr dazu gleich), dank Julef</a> gibt es zahlreiche animierte 3D-Assets, und alles ist vorbereitet, um auf Steam präsent zu sein.</p> Außerdem durfte ich an der großartigen Hacker- und Maker-Konferenz GPN23</a> teilnehmen – eine der chilligsten Veranstaltungen überhaupt (Stimmung, nicht Temperatur). Ich wurde „überredet“, einen Lightning Talk darüber zu halten, wie man Spiele mit Rust und Bevy entwickelt. Falls du Lust hast, kannst du ihn hier anschauen</a>. Das Feedback war so positiv, dass ich bald sogar einen längeren Vortrag auf einem weiteren Event halten werde.</p> Als Bonus teilt Julef</a> in ihrem ersten Blogbeitrag Einblicke in ihre Arbeit an Exofactory.</p> Mehr folgt!</p> Animationen</h1> Ein riesiger Batzen Arbeit steckt in den Animationen und 3D-Arbeiten von Julef</a>. Ich freue mich unglaublich darauf, sie ins Spiel zu integrieren.</p> </video> Wave-Animation</figcaption> </figure> </video> Walk-Animation</figcaption> </figure> </video> Idle-Animation</figcaption> </figure> </video> Szene mit Bändern und Maschinen</figcaption> </figure> Hinter den Kulissen mit Julef</h1> Hallo, hier ist Julija – Art Director und Leiterin des gesamten Art-Teams von Exofactory.</p> Ich möchte ein kurzes Kunst-Update teilen.</p> Im letzten Monat haben wir Assets verfeinert und das Terrain weiter verbessert.</p> Ein Highlight: Der Fabricator hat ein komplettes visuelles Makeover erhalten.</p> </div> Wir haben weitere Bänder der Stufen 1 und 2 ergänzt und ihnen Leben eingehaucht. Es kommt Bewegung ins Spiel!</p> </video> </figure> Auch der Exoframe wurde dank funktionierendem Rig und Animationen lebendig – großes Danke an Juan</a>, der beim Rig-Aufbau unterstützt und die Animationen erstellt hat!</p> </video> Walk-Animation</p> </div> </video> Wave-Animation</p> </div> </video> Idle-Animation</p> </div> </div> Wir haben die ersten visuellen Assets für Steam erfolgreich fertiggestellt und eingereicht.</p> </p> Und hier seht ihr, was hinter den Kulissen passiert.</p> </p> Terrain</h1> </p> Hier ist wieder Cait! Wenn das Bild oben Terrain v2 zeigt, seht ihr unten v2.5.</p> Das Terrain-System wurde überholt. Im neuen System haben wir kein Terrain mehr der Kategorie „Müll“. Ganz zufrieden bin ich trotzdem noch nicht. Wenn das hier Version 2 ist, brauchen wir wahrscheinlich mindestens v4 oder v5, bevor es wirklich gut aussieht. Aber Terrain gehört nun mal zu den härtesten Teilen des Fabrikspiel-Genres. Wenn ich eines Tages damit zufrieden bin, wäre das ein großer Sieg – bis dahin arbeiten wir weiter daran.</p> Etwas subtiler: Es gibt jetzt ein neues Terrain-Ladesystem. Es streamt Assets und Texturen dynamisch nach, während man durch die Welt navigiert. Das eröffnet spannende Möglichkeiten, beispielsweise später ein Level-of-Detail-System einzubauen.</p> Steam-Screenshots</h1> </p> Die Screenshots waren der härteste Brocken. Ursprünglich wollte ich unseren Steam-Auftritt viel</em> früher vorbereiten, aber ich bekam die Bilder nicht auf einen Stand, der dem Spiel gerecht wurde.</p> Bevy</a>, die Engine hinter Exofactory, bietet weder Szenen-Viewer noch Preview oder ein Paint-Tool – gar keine GUI. Also musste ich die Fabriken in den Screenshots durch echtes Spielen</strong> aufbauen, genau wie jemand, der das Spiel kauft. Da Funktionen wie „Gebäude löschen“ noch fehlen, kannst du dir vorstellen, wie das lief.</p> Der Vorteil: Dabei habe ich jede Menge Dinge entdeckt, die ich für mehr Komfort verbessern möchte. Ein Gewinn also.</p> Hier sind die In-Game-Bilder, die an Steam übermittelt werden. Wir rechnen mit einer baldigen Freigabe.</p> </p> </p> </p> </p> Fazit</h1> Unterm Strich war es ein produktiver Monat. Überall wurde großartige Arbeit geleistet – besonders von Julef.</p> Einziger Wermutstropfen: Durch das hohe Tempo hat sich etwas Brüchigkeit im Code eingeschlichen. Ich freue mich darauf, wieder „reine“ Programmierarbeit zu leisten und die Codebasis zu härten. Immerhin – wozu schreibt man ein Spiel in Rust, wenn man Code-Brittle zulässt?</p> Dieser Monat war großartig und bald wird diese Größe richtig solide sein.</p> Art Lead, ESC und der 3D-Umbau Unknown — Sun, 25 May 2025 00:00:00 +0000 Überblick</h2> Die letzten zwei Wochen waren voller Arbeit – größtenteils nicht programmieren. Die gute Nachricht: Sie führte zu großen Veränderungen und insgesamt deutlichen Verbesserungen für das Spiel.</p> Das Wichtigste zuerst: Exofactory hat jetzt eine Art Lead. Bald sollten also sichtbare Fortschritte bei der Optik zu sehen sein.</p> Art Lead</h2> Wie oben erwähnt, ist die große Neuigkeit, dass Exofactory nun eine Art Lead hat. Ursprünglich suchte ich nur nach einer Künstlerin für einzelne Assets. Im Gespräch mit Julija wurde aber klar, dass jemand gebraucht wird, der die künstlerische Gesamtleitung übernimmt.</p> Mir fehlt schlicht das nötige Skillset, und dem Spiel würde es nicht guttun, wenn ich die Art Direction führen würde.</p> Wir arbeiten nun seit einiger Zeit zusammen und haben eine klare ästhetische Richtung definiert.</p> Ich freue mich sehr auf die Zusammenarbeit – es gibt viel zu tun.</p> Wenn du mehr über Julija erfahren möchtest, schau dir ihr Portfolio an.</a></p> ESC</h2> Falls sich der oder die eine Lesende fragt, warum letzte Woche kein Update erschienen ist: Schuld war meine Ablenkung durch den Eurovision Song Contest!</p> Die Party und das lange Zusammensein haben den Fortschritt dieser Woche vielleicht auch etwas gebremst – aber es war jede Minute wert.</p> Wir sind jetzt 3D!</h2> </p> Die größte Aufgabe der letzten beiden Wochen war der Umstieg auf 3D. Nicht extrem schwer, aber sehr arbeitsintensiv. (Nur zur Klarstellung: Das sind keine finalen Art-Assets, also keine Sorge.)</p> Teil der Arbeit war ein prozeduraler Terrain-Generator. Egal ob das Spiel später eine unendliche Karte oder eine begrenzte, von Hand abgestimmte Welt hat – automatisch generiertes Terrain reduziert den Aufwand enorm.</p> </p> Interessanterweise dauert das Generieren des Terrains gerade lang genug, um einen Ladebildschirm zu rechtfertigen. Den gibt es jetzt also ebenfalls.</p> </p> Fazit</h2> Ich bin sehr zufrieden mit dieser Woche. Viele wichtige Arbeiten haben begonnen, und das Spiel hat nun eine klare künstlerische Richtung.</p> Kunst und Künstler:innen Unknown — Sat, 10 May 2025 00:00:00 +0000 Überblick</h2> Diese Woche stand vor allem nicht programmieren im Mittelpunkt. Ich habe mich auf ein Gebiet konzentriert, in dem ich kaum Erfahrung habe: Künstler:innen finden, sortieren und auswählen. Das war mühsam und ehrlich gesagt nicht besonders spaßig – aber es muss nun einmal erledigt werden.</p> Kunst und Künstler:innen</h2> Ich bin Programmiererin, keine Künstlerin, also habe ich ein paar Fehler gemacht. Der größte: Ich habe mich auf 2D-Künstler:innen fokussiert.</p> Das war unklug, denn wie mir eine der angefragten Personen freundlich erklärte, bräuchte ich für jedes Gebäude und jede Ausrichtung eine komplett neue Animation. Das ist enorm viel Arbeit.</p> Der Rat lautete stattdessen, eine 3D-Künstlerin oder einen 3D-Künstler zu engagieren und über eine UV-Map</a> Sprite-Sheets zu erzeugen. Nach etwas Recherche stimme ich zu. Der Hinweis war super hilfreich und hat mir die Richtung gezeigt.</p> Bevor ich diesen Tipp bekam, ist allerdings noch ziemlich cooles Konzeptart entstanden.</p> </p> Ein bisschen zu rund für meinen Geschmack, aber trotzdem spannend.</p> </p> Dieses hier mag ich besonders.</p> Leider lässt sich dieses 2D-Konzept nicht sinnvoll weiterverfolgen, aber es hilft, die Stimmung des Spiels zu definieren – also trotzdem wertvoll.</p> Fazit</h2> Die Woche war voller neuer Erfahrungen, und ich habe viel gelernt. Jetzt geht es darum, eine passende 3D-Fachkraft zu beauftragen. Bald sollte es mehr zu zeigen geben.</p> Offsets, Menüs, Barrierefreiheit und 0.16 Unknown — Sat, 03 May 2025 00:00:00 +0000 Überblick</h2> Letzte Woche hatte ich große Pläne: ein kurzer Mikro-Crunch und anschließend eine technische Vorschau. Wegen persönlicher Umstände konnte ich die nötige Zeit aber nicht investieren. Deshalb hat das Spiel nicht den Stand erreicht, den ich präsentieren wollte. Ich reiche es vermutlich später ein – Nachhaltigkeit geht vor, also musste ich das Ziel für diese Woche fallen lassen.</p> Trotzdem ist viel passiert, sowohl im Hintergrund als auch für Spieler:innen sichtbar. Und das ist alles sehr motivierend.</p> Bevy 0.16</h2> Der erste große Brocken war der Port von Bevy 0.15 auf 0.16</a>. Drei Gründe sprachen dafür:</p> Ich möchte bald mit Förderbändern beginnen und die neuen ECS Relationships</a> intensiv nutzen, um Quellen und Senken zu verwalten. Ohne sie hätte ich mir am Ende eine eigene Version davon gebaut.</li> Ich wollte die stabilisierte Input-Focus-Funktion</a> verwenden. Sie ist essenziell für Barrierefreiheit und Gamepad-Support (mehr dazu unten).</li> Bevy entwickelt sich rasant. Hinterherzuhinken wäre für Exofactory aktuell fatal. Sobald Bevy stabiler wird, ändert sich das vielleicht – bis dahin sind Upgrades Pflicht.</li> </ol> Der Port war keine große Hürde, größtenteils ging es um den Abschied von veralteten Funktionen und etwas Refactoring. Ich habe die Gelegenheit genutzt, älteren Code aus meinen ersten Bevy-Tagen aufzuräumen, vor allem durch den Wechsel von Queries</code> zu Single</code>, wo möglich. So konnte ich einige verschachtelte if let Some(x) =</code>-Blöcke entfernen – viel aufgeräumter.</p> Ein paar Abhängigkeiten waren noch nicht aktualisiert, daher habe ich vorübergehend deren 0.16-PR-Branches oder Release-Candidates eingebunden.</p> Menüs & Barrierefreiheit</h2> </p> Das zweite große Projekt war das neue, ziemlich vollständige Baumenu.</p> Ich habe damit nach 0.16 gewartet, weil ich unbedingt das neue Accessibility-/Focus-Feature nutzen wollte – hier kam es zum ersten Mal im Spiel zum Einsatz. Barrierefreiheit ist für mich Best Practice. Was Menschen mit Einschränkungen hilft, hilft letztlich allen – auch Entwickler:innen. So wird Gamepad-Unterstützung zur Kleinigkeit. Aus Code-Sicht sind Gamepads und spezialisierte Accessibility-Hardware im Grunde dasselbe.</p> Fazit</h2> Ich habe diese Woche nicht ganz die gewünschte Qualität erreicht, bin aber zufrieden mit dem, was entstanden ist. Nachhaltigkeit bleibt mir wichtig – Burn-out gilt es zu vermeiden.</p> Gebäudemenüs, Gamepads und Kurswechsel Unknown — Sat, 26 Apr 2025 00:00:00 +0000 Überblick</h2> Die Woche begann mit völlig anderen Zielen, als sie geendet hat. Der Wendepunkt kam, als Pokinsson</a> einen Aufruf für Indie-Games in jedem Entwicklungsstand startete. Nach kurzem Grübeln beschloss ich, eine Einreichung zu wagen. Bedeutet: Bis zum 7. April muss das vorhandene Material poliert werden, damit eine spielbare technische Vorschau entsteht.</p> Also habe ich die halbfertige Gamepad-Unterstützung auf Eis gelegt und den Fokus auf dieses Ziel gerichtet. Zurück bleibt ein Haufen Gamepad-Code im Beta-Zustand – das künftige Ich darf sich darum kümmern.</p> Trotzdem gab es Fortschritte.</p> Halb gare Gamepad-Unterstützung</h2> Zu Beginn der Woche, bevor ich von dem Aufruf erfahren habe, war das der Schwerpunkt. Ich nutze Xelus großartige Button-Prompts</a> – absolute Empfehlung.</p> Ich habe viele Mappings und Controller-Management-Code ergänzt. Dadurch kann ich künftig einfach so etwas tun:</p> let focus_on_exoframe: Handle<Image> = smart_prompt_collection.focus_on_exoframe.clone(); </code></pre> Das Ergebnis ist immer das richtige Prompt-Bild – egal ob Steam Deck, Xbox-One-Controller oder Tastatur und Maus.</p> Weiter kam ich in dieser Woche nicht, dafür steht jetzt eine Liste geplanter Geräte/Steuerungsschemata:</p> Steam Deck mit integrierten Controllern, Tastatur und Maus oder Xbox-One-Controller</li> Modernes Linux (Debian 11 und neuer) mit Tastatur und Maus oder Xbox-One-Controller</li> Windows 10/11 mit Tastatur und Maus oder Xbox-One-Controller</li> </ul> Andere Systeme oder Controller sollten funktionieren, werden aber nicht getestet. Mehr Infos zu eventuellen Kompatibilitäten findest du bei gilrs</a>, der zugrunde liegenden Bibliothek im Zusammenspiel mit Bevy.</p> Steuerungsübersicht</h2> </p> Außerdem gibt es jetzt ein Panel als „Steuerungsübersicht“. Es zeigt jederzeit an, welche Aktionen möglich sind, und aktualisiert sich dynamisch während des Spiels. Natürlich lässt es sich ausblenden, falls es stört.</p> Das ist sowohl für die technische Vorschau als auch fürs fertige Spiel enorm hilfreich.</p> Gebäude-Interface</h2> </p> Zum Schluss kam ein neues Kernfeature hinzu: Ein Gebäude kann nun tatsächlich etwas produzieren!</p> Fazit</h2> Insgesamt war es eine stressige Woche, und dieses Arbeitstempo soll keine Normalität werden – gerade mit meinen anderen Verpflichtungen. Aber es ist viel passiert, und der Preview-Build sollte Form annehmen.</p> UI-Grundlagen gelegt Unknown — Sat, 19 Apr 2025 00:00:00 +0000 Überblick</h2> Diese Woche drehte sich vor allem darum, grundlegende UI-Elemente hinzuzufügen, an der Exoframe-Bewegung zu arbeiten und erste Sounds ins Spiel zu bringen.</p> Aktuell verwende ich extrem einfache Platzhalter-Grafiken, weil der Schwerpunkt weiterhin auf den Kernmechaniken liegt. Rechne also mit ziemlich improvisierter Optik, die eindrucksvoll beweist, dass ich keine Künstlerin bin.</p> Insgesamt passt die Woche gut zum Zeitplan.</p> UI weiter ausgestalten</h2> Exofactory entsteht mit Bevy</a> und so sehr ich das Projekt schätze – die UI-Entwicklung macht schlicht keinen Spaß. Future Bevy</a> soll hier Abhilfe schaffen, und ich hoffe für alle Rust-Game-Devs, dass das klappt. Während Hauptmenü und Einstellungen bereits in einem guten Zustand sind, blieb das UI im eigentlichen Spiel bis diese Woche unangetastet.</p> Das hat sich nun mit der neuen oberen Leiste geändert. Sie soll der zentrale Anlaufpunkt sein, über den Spielende erkennen, in welchem „Modus“ sie sich befinden und was global passiert.</p> </p> Außerdem habe ich das Grundgerüst für Detail- und Einstellungsfenster von Gebäuden gelegt. Damit kann ich künftig schneller iterieren und den UI-Aufwand beim Einführen neuer Gebäude reduzieren. Im Moment zeigt ein Klick auf ein Gebäude lediglich einige Basisinformationen wie oben zu sehen.</p> Damit bin ich fürs Erste sehr zufrieden.</p> Sound-Experimente</h2> Als Abwechslung zur UI-Arbeit habe ich ein paar grundlegende Sounds ergänzt. Nach einigen Aufnahmen und etwas Feinschliff in Tenacity</a> gibt es nun mehrere Sounds, mit denen ich sehr happy bin. Besonders das Mouseover im Menü gefällt mir.</p> Dein Browser unterstützt das Audio-Element nicht. </audio> Einen eigenen Sound-Abschnitt im Einstellungsmenü brauche ich noch, aber das kann warten.</p> Exoframe in Bewegung</h2> </p> Zum Schluss habe ich die Exoframe-Bewegung ergänzt. Sie fühlt sich sehr direkt und zufriedenstellend an. Die Bewegungs- und Physiksysteme stammen vom großartigen Rapier-Framework.</p> Fazit</h2> Unterm Strich bin ich mit dieser Woche zufrieden. Ich plane, wöchentlich Dev-Blogs und monatliche Video-Blogs zu veröffentlichen – also bleib dran.</p>

Optimierungen, Pull Requests, Tooling & Finanzen

Unknown — Thu, 05 Mar 2026 00:00:00 +0000

Überblick</h1>
Der letzte Monat war voll mit den unterschiedlichsten Sachen. Von großen Optimierungen, über ein paar dabei gefundene Probleme, über neues Tooling, bis hin zum offiziellen Start der Suche nach einem Partner-Publisher / Investor wurde eine Menge Programmier- und Nicht-Programmier-Arbeit erledigt.</p>
Wenn du das interessant findest und das Spiel spannend klingt, gib dem Spiel gern eine Wunschliste auf Steam</a>. Das hilft enorm.</p>

Optimierungen</h1>
Der technische Hauptfokus diesen Monat lag auf Optimierung. Über das letzte Jahr hat eine Kombination aus „nicht voreilig optimieren"-Mentalität, gemischt mit einer (un?)gesunden Portion fehlendem Bevy-Domänenwissen, gemischt mit ein paar echten Bevy-Bugs zu einem extrem unoptmierten Spiel geführt, was Speicherverbrauch angeht.</p>
Beim letzten Pre-Optimierung-Build lagen wir bei 7GB System-RAM mit ungefähr der gleichen Menge VRAM. (hint here) Angesichts der Komplexität von Exofactory wusste ich, dass das Spiel nie eins von diesen 200MB-Runtime-Spielen sein würde, aber das war echt grauenhaft, und ehrlich gesagt peinlich. Es war an dem Punkt, wo ich kaum `--release</code>-Builds auf meinem (zugegebenermaßen alten) 11th Gen Intel Framework laufen lassen konnte.</p>`
`Also hab ich mich daran gemacht,` `tracy und wie es in Bevy funktioniert</a> zu lernen und mir die Zeit zu nehmen, tatsächlich mal aufzuräumen.</p>`
`Lange Rede kurzer Sinn: Ich kann tracy halbwegs benutzen, auch wenn ich mich als absolute Anfängerin bezeichnen würde. Aber ich hab's auch gefixt. Der Prozess lief im Grunde auf diese 4 Bereiche hinaus:</p>`

Alles im System-RAM speichern</h2>
Standardmäßig wird bei asset_server.load("my_thing.png")</code> das Asset in den System-RAM geladen und beim Spawnen in den VRAM. Bei einem kleineren Bild ist das nicht so wild, aber wenn man eine komplizierte .glb/.gltf</code></a>-Datei lädt, wird's schnell heftig. Wenn man eine GLB mit 6 RGBA 4096x4096 Texturen hat (also Normal, Metallic, Roughness etc.) wären das ~384MB System-RAM. Mit Mipmaps</a> eher ~512MB pro GLB-Asset. Das allein war für den GROSSTEIL des irren RAM-Verbrauchs von Exofactory verantwortlich.</p>
Die gute Nachricht ist, dass man nicht alles im System-RAM speichern muss. In Bevy kann man Dinge in MainWorld</a> oder in RenderWorld</a> oder in beidem speichern. MainWorld ist das Spiel, wie man es sich vorstellen würde. Einfach alles im System-RAM. RenderWorld hingegen ist eine Art Tag, das Dinge markiert, sodass sie nur auf der GPU leben.</p>
Ich konnte den System-RAM-Verbrauch senken, indem ich Texturen einfach nicht außerhalb der GPU gespeichert hab, wenn ich eh nichts damit vorhatte.</p>
Bevy hat mehrere Wege dafür, aber der einfachste für mich waren .meta</code>-Dateien.</p>
In Bevy liegen .meta</code>-Dateien neben den Assets und erlauben es, zu überschreiben, wie der Asset-Loader damit umgeht. Sie verwenden Bevys RON-ähnliches Format</a> und sind nach der Asset-Datei benannt, die sie konfigurieren. Also für fabricator_01_icon.ktx2</code> hätte man eine fabricator_01_icon.ktx2.meta</code>-Datei direkt daneben.</p>
Für ein einfaches Bild-Asset sieht die Meta-Datei so aus:</p>
(
    meta_format_version: "1.0",
    asset: Load(
        loader: "bevy_image::image_loader::ImageLoader",
        settings: (
            format: FromExtension,
            is_srgb: true,
            sampler: Default,
            asset_usage: RenderAssetUsages("RENDER_WORLD"),
        ),
    ),
)
</code></pre>
Die entscheidende Zeile ist asset_usage: RenderAssetUsages("RENDER_WORLD")</code>. Das sagt Bevy, die Textur nur auf der GPU zu halten und die System-RAM-Kopie komplett freizugeben.</p>
Für GLB-Dateien kann man granularer werden. Hier ein Beispiel von einem der Fließband-Gebäude-Modelle:</p>
(
    meta_format_version: "1.0",
    asset: Load(
        loader: "bevy_gltf::loader::GltfLoader",
        settings: (
            load_meshes: RenderAssetUsages("MAIN_WORLD | RENDER_WORLD"),
            load_materials: RenderAssetUsages("RENDER_WORLD"),
            load_cameras: true,
            load_lights: true,
            load_animations: true,
            include_source: false,
            default_sampler: None,
            override_sampler: false,
            convert_coordinates: None,
        ),
    ),
)
</code></pre>
load_meshes</code> behält beide: MAIN_WORLD | RENDER_WORLD</code>. Das liegt daran, dass ich Mesh-Daten im System-RAM brauche für Dinge wie Kollisionserkennung</a> und Raycasting</a>. Aber load_materials</code> (also die Texturen) ist nur auf RENDER_WORLD</code> gesetzt. Das gibt uns das Beste aus beiden Welten. Meshes bleiben im System-RAM zugänglich wo wir sie brauchen, während die Texturen, die den Großteil des Speicherverbrauchs ausmachen, nur auf der GPU leben.</p>
Das Schöne an Meta-Dateien ist, dass sie keine Code-Änderungen erfordern. Man legt sie einfach neben die Assets und der Loader nimmt sie automatisch auf. Ein kleines Fish</a>-Skript später und ich war fertig.</p>
Nicht GPU-native Bitmap-Formate verwenden</h2>
Die Meta-Datei-Änderungen oben haben beim System-RAM geholfen, aber VRAM war immer noch ein Problem. Exofactory hat PNG für eigenständige Texturen und eingebettete PNGs in GLB-Dateien verwendet, was die eigentliche Ursache für den hohen VRAM-Verbrauch war.</p>
Der Wechsel zu KTX2</a> für Texturen war die Lösung. Es ist ein Container-Format von Khronos, das viele GPU-native komprimierte Formate</a> halten kann.
Von den verfügbaren Formaten hab ich UASTC und ETC1S in Betracht gezogen, wegen nativer Bevy-Unterstützung. Die haben unterschiedliche Tradeoffs:</p>
</th> UASTC</th> ETC1S</th></tr></thead>

Qualität</strong></td> Fast verlustfrei</td> Verlustbehaftet, niedrigere Qualität</td></tr>
VRAM-Verbrauch</strong></td> ~1 Byte/Pixel</td> ~0,5 Bytes/Pixel</td></tr>
Dateigröße</strong></td> Größer (mit Zstd)</td> Viel kleiner</td></tr>
Transcode-Geschwindigkeit</strong></td> Schnell</td> Sehr schnell</td></tr>
Geeignet für</strong></td> Normal Maps, UI-Elemente, detaillierte Texturen</td> Texturen, bei denen Qualität weniger kritisch ist</td></tr>
</tbody></table>
Für Exofactory bin ich pauschal mit UASTC gegangen, hauptsächlich aus Faulheit. Eigentlich sollte ich ETC1S für Texturen nehmen, bei denen niedrigere Qualität nicht auffallen würde und die VRAM-Einsparungen nett wären. Das ist ein TODO für später.</p>
Einen Bug in Bevy rund um KTX2 gefunden</h2>
Beim Umstieg auf KTX2-Dateien ist mir aufgefallen, dass Bevy die .meta</code>-Dateien für KTX2-Dateien nicht beachtet hat. Eine kleine PR später</a> und es war gefixt. Der Fix wird in Bevy 0.18.1 enthalten sein.</p>
KTX2 richtig in GLB-Dateien verwenden</h2>
Ein größeres, ernsthafteres Problem das ich gefunden hab ist, dass Bevy KTX2-Texturen in GLTF/GLB-Dateien nicht richtig unterstützt. Man kann die KTX-Textur zwar einfach in die Datei reinpacken und es funktioniert in Bevy, aber das Problem ist, dass die resultierende Datei keine konforme GLTF/GLB-Datei ist.</p>
Die Ursache ist, dass Bevy gltf-rs</a> als Teil seiner GLB/GLTF-Pipeline verwendet. Die Library ist zwar robust was die offizielle GLTF-2.0-Spec angeht. Aber bei den de-facto verpflichtenden Extensions inklusive KTX2</a> ist sie echt mangelhaft. Ich hab eine PR eingereicht</a>, aber die letzte Code-Änderung war im November 2025 und ich bin nicht optimistisch.</p>
Im Moment verwendet Exofactory meinen Fork der Library, aber eine langfristigere Lösung muss her.</p>
Ich arbeite gerade an einem Dokument mit ein paar Ideen, die dem Bevy-Core-Team gepitcht werden sollen, basierend auf deren Anfrage.</p>
Ergebnisse</h2>
Nach den Verbesserungen in den oben genannten 4 Bereichen ist das Spiel massiv besser optimiert. Das Spiel ging von 7GB System-RAM auf unter 1GB. Von 7GB VRAM auf unter 2GB. Mein alter Laptop schafft jetzt 60fps auf niedrig, was mobile Entwicklung wieder möglich macht. War ein großer Push, aber absolut die Mühe wert.</p>
Tooling</h1>
Als kleines Nebenprojekt hab ich diesen Monat an BevyDex.dev</a> gearbeitet. Ist im Grunde ein dünner Wrapper um die crates.io</a>-API und eine Postgres-Datenbank.</p>
Aber es ist immer aktuell, zeigt wichtige Details und ist blitzschnell(tm).</p>
Ist ein Nebenprojekt, das nichts mit Exofactory zu tun hat. Aber es wurde gebaut, damit ich mich durch das Ökosystem sortieren kann, und ich hoffe, andere finden es auch nützlich.</p>
Finanzen</h1>
Zu guter Letzt: Exofactory wird bald offiziell mehrere Publisher kontaktieren. Aufgrund persönlicher Ereignisse kann ich zwar coden, aber das ganze Spiel nicht alleine finanzieren. Hoffentlich kommen da bald interessante Neuigkeiten. Falls jemand Ratschläge hat, immer her damit.</p>
Fazit</h1>
Ich programmiere lieber als an Pitch Decks zu arbeiten. Ich fixe lieber Bugs upstream wenn ich kann. Und ich freue mich, Sachen rauszubringen, die ich für nützlich halte.</p>


Multiplayer, Bevy 0.18 und Fosdem
Unknown — Wed, 04 Feb 2026 00:00:00 +0000
Überblick</h1>
Diesen Monat ging es im Grunde ausschließlich darum, Multiplayer-Funktionalität einzubauen – mit einer kleinen Pause für die Bevy-0.18-Migration.</p>
Wenn du das interessant findest und das Spiel spannend klingt, gib dem Spiel gern eine Wunschliste auf Steam</a>. Das hilft enorm.</p>
Ich muss sagen, ich bereue es, nicht früher mit dem Multiplayer-Code angefangen zu haben. Wie bei Internationalisierung und Speicherständen ist Multiplayer etwas, das man von Anfang an in die Architektur einplanen sollte. Die gute Nachricht: Der Code war sauber genug, dass der Refactor nicht allzu</em> schmerzhaft war.</p>
Ansonsten war die Migration von 0.17 auf 0.18</a> ziemlich unkompliziert. Ich musste ein paar weniger gepflegte Crates aufgeben, aber die eigentliche Migration war simpel.</p>
Zu guter Letzt hab ich mir die Zeit genommen, zur Fosdem zu fahren, um die Bevy-Community zu treffen. Ich selbst hatte keinen Talk, aber Thierry Berger</a> hat einen hervorragenden Vortrag über mobile Bevy-Spieleentwicklung</a> gehalten.</p>
Multiplayer</h1>

  
    
      
      
      
    </picture>
    
    Das Spiel unterstützt gleichzeitiges Hosten und Beitreten über Direct Connect, LAN und Steam-Multiplayer.</figcaption>
    
  </figure>
</div>
Leuten, die Spiele mit Bevy schreiben, hab ich bisher immer geraten, sich früh Gedanken über Internationalisierung, Gamepad-Unterstützung und Speicherstände zu machen. Jetzt bereue ich, dass ich den wahrscheinlich wichtigsten Faktor vergessen habe – nämlich Multiplayer und Netcode.</p>
Dementsprechend meine aktualisierte Liste von Dingen, die man früh bedenken sollte:</strong></p>

Multiplayer / Netcode</li>
Gamepad-Unterstützung</li>
Speicherstände</li>
Internationalisierung</li>
</ol>
All das nachträglich einzubauen ist nervig und schmerzhaft. (Fragt mich, woher ich das weiß! /s)</p>
Exofactory-Spezifika</h2>
Exofactory ist ein Fabrikspiel, in dem man als KI spielt, die über kleine Roboter namens „Exoframes" mit der Welt interagiert. Diese müssen erst gebaut werden. Wenn man gerade keinen Exoframe steuert, kann man im globalen Kameramodus über die Fabriken fliegen.</p>
Das ergibt einen ziemlich natürlichen kooperativen Ansatz: Neue Spielende können im globalen Modus beitreten, sich umschauen und bestehende Maschinen konfigurieren. Sobald ein Exoframe frei ist, kann man ihn „besetzen" und die Welt jenseits der Fabrik-Sensorreichweite erkunden und ausbauen.</p>
Das führt zu einem schönen Multiplayer-Metaplot und gleichzeitig zu einer klaren technischen Aufgabenstellung für den Netcode:</p>

Im globalen Modus mit der Welt interagieren, einschließlich Bauen.</li>
Einen Exoframe aus einem Pool auswählen und steuern.</li>
Den Rest der Welt simulieren und die relevanten Komponenten aktualisieren.</li>
Sicherstellen, dass der Client die Welt korrekt sieht.</li>
</ol>
Für mich führt das ziemlich natürlich zu einem Server-autoritativen Modell. Die Server-Instanz des Spiels simuliert die Welt, und die Client-Instanzen nehmen einfach daran teil.</p>
Bibliothek auswählen</h2>
Zum Zeitpunkt auf Bevy 0.18 scheint es zwei gut unterstützte Crates zu geben: bevy_replicon</a> und lightyear</a>.</p>
Ich empfehle, sich beide anzuschauen – beide haben ihre eigenen Vorteile. Nach meinem (möglicherweise fehlerhaften) Verständnis bietet lightyear mehr Features wie Client-Side Prediction</a>, deterministische Replikation</a> und Interest Management (nur relevante Daten synchronisieren), allerdings mit mehr initialem Aufwand und Komplexität. Replicon lässt diese Features standardmäßig weg, ist dafür aber einfacher aufzusetzen mit weniger Entwicklungsaufwand. Falls ich hier falsch liege, korrigiere ich das gerne – meldet euch einfach.</p>
Edit:</strong> Jemand hat sich tatsächlich gemeldet! Wie sich herausstellt, unterstützt bevy_replicon doch deterministische Replikation und Interest Management. Die Features, die im Vergleich zu lightyear fehlen, sind Client->Server-Replikation, Lag Compensation, Client-Side Prediction und Interpolation. Außerdem plant lightyear, Replicon für die Replikation wiederzuverwenden.</p>
Für Exofactory habe ich mich für das einfachere Replicon entschieden, weil das Spiel definitiv kein</em> hektischer Shooter ist, mein geplantes Feature-Tempo eher gemächlich ist und ich bei Netcode noch relativ grün hinter den Ohren bin.</p>
Das gesagt: Wenn die Spielarchitektur bereits gut strukturiert ist, dürfte ein späterer Wechsel kein allzu schmerzhafter Prozess sein.</p>
Von Singleplayer zu Multiplayer</h2>
Im Kern macht Replicon zwei Dinge: Komponenten replizieren und Netzwerk-Events/Nachrichten an und von Clients verarbeiten.</p>
Um Multiplayer zu ermöglichen, musste ich mehrere Systeme refactoren und logisch gruppieren.</p>
</p>
Autoritative Kernsysteme</h3>
Diese laufen nur auf der Server-Instanz und aktualisieren die Welt (also alle Komponenten, die den Spielzustand speichern) für alles, was nicht direkt vom Spieler manipuliert wird.</p>
Dazu gehören Dinge wie der Maschinenzyklus, der Eisenerz in Eisenbarren verwandelt, welche Sounds abgespielt werden sollen, und sogar die Abbaurate, die ein Exoframe hat, während man zuschaut. Es gibt noch viel mehr Systeme, aber das sind die typischen in dieser Gruppe.</p>
Diese Systeme dürfen direkt in Komponenten schreiben. Replicon repliziert diese Änderungen automatisch zur Client-Instanz der Komponenten.</a></p>
Player-UI-Systeme</h3>
Diese laufen nur auf Spielinstanzen, in denen tatsächlich jemand spielt. Sie spielen Sounds ab, zeigen die Bau-UIs an und informieren den Spieler über den Weltzustand. Diese Systeme lesen den Weltzustand, indem sie die lokalen Komponenten lesen, die automatisch synchron gehalten werden.</p>
Der Teil, der den großen Refactor erforderte: In diesen Systemen ist keine direkte Manipulation von Komponenten erlaubt. Die Clients müssen ein Event/eine Nachricht an den Server schicken</a>, der dann im Auftrag des Clients die Komponenten manipuliert und die Änderungen repliziert.</p>
Netzwerk-Nachrichten & Events</h3>
Im obigen Diagramm hab ich nur ein Beispiel gezeigt, aber in Wirklichkeit passiert so ziemlich alles im Spiel über „Gucken"</em> hinaus per Event oder Nachricht. Das gilt auch für den Spieler auf der Server-Instanz des Spiels.</p>
Das ist meiner Meinung nach DER wichtigste Faktor, wenn man an einem Bevy-Spiel arbeitet, das irgendwann Multiplayer unterstützen soll. Hätte ich das von Anfang an so gemacht, wäre das Hinzufügen der Multiplayer-Funktionalität einfach gewesen. Auch wenn man anfangs nicht an Netzwerk denken möchte – allein sicherzustellen, dass alle Spieler-Manipulationen der Welt über die nativen Bevy-Event-Systeme</a> oder Message-Systeme</a> laufen, spart später enorm viel Zeit.</p>
Auswirkungen & Ergebnisse</h2>
</p>
Es gab zwei interessante Nebeneffekte. Der erste war etwas, das ich eigentlich erst später angehen wollte, aber durch den Refactor deutlich einfacher wurde: eine Headless-Server-Instanz, die man per Docker/Podman etc. selbst hosten kann. So kann die Fabrik weiterlaufen, ohne dass jemand das Spiel auf dem PC offen halten muss.</p>
Durch den Refactor und einen neuen Feature-basierten Build, der MinimalPlugins</a> statt DefaultPlugins</a> verwendet, bekommt man eine schlanke Headless-Server-Instanz, die so ziemlich überall laufen kann – sogar auf den meisten RISC-V-SBCs!</p>
Das muss noch getestet werden, aber es sieht gut aus. Oben ist ein ähnliches Diagramm, aber für die Headless-Version des Spiels.</p>
Der zweite interessante Nebeneffekt: Ich verwende deutlich weniger Bevy Resources</a>, weil Replicon keine Resources repliziert. Stattdessen nutze ich viel mehr Pseudo-Singletons</a> (also eine „leere" Entity, die nur die Komponente hat, die die Daten hält, die vorher in der Resource steckten).</p>
Ich bin kein großer Fan von objektorientierten Design Patterns, also ist das schon etwas witzig und fühlt sich ein bisschen dreckig an.</p>
Bevy-0.18-Migration</h1>
Ich hab das Licht gesehen! Nein wirklich – jedes Bevy-Spiel mit Beleuchtung sollte die Migration priorisieren. Da wurde richtig was gemacht, und das Spiel sieht merklich besser aus. Aber auch wenn euer Spiel kein Licht verwendet, solltet ihr trotzdem migrieren.</p>
Abgesehen von ein paar Shader-Bind-Group-Sachen (also BindGroupLayout -> BindGroupLayoutDescriptor</a>) und Atmosphere</a>-Änderungen war es eine einfache Migration.</p>
Schön zu sehen, dass der Release-Zyklus wieder im Takt ist.</p>
Allerdings muss ich sagen: Mit jedem Upgrade sehe ich mehr Plugins, die auf der Strecke bleiben. Das lässt mich die Maintainer von Plugins umso mehr schätzen. Mit Bevys Release-Zyklus Schritt zu halten, ist im Vergleich zu jeder anderen Game Engine eine ordentliche Aufgabe.</p>
Fosdem!</h1>
Apropos – ich hatte das Vergnügen, die Fosdem</a> zu besuchen, ein Open-Source-Treffen, das jedes Jahr in Brüssel stattfindet.</p>
Wenn ihr euch für Open-Source-Game-Engines interessiert – oder ehrlich gesagt für Open Source generell – kann ich nur empfehlen, hinzugehen. Es gibt massenhaft spannende Talks, aber das Beste (zumindest für mich) ist, die Leute zu treffen, mit denen man sonst nur online redet. Das Bevy-Abendessen mit Thierry Berger</a>, Gee</a>, Niklas Eicker</a>,  Firestar99</a> und einigen anderen netten Leuten war richtig gut.</p>
Fazit</h1>
Ich dachte, ich krieg Multiplayer in einer Woche hin, aber es hat einen Monat gedauert – wie irgendwie erwartet. Ich bin ein besserer Spieleentwickler durch die Erfahrung. Man kann sich halt nicht für alles nur auf Backend-Patterns verlassen.</p>
Die Bevy-0.18-Migration war unkompliziert.</p>
Ich kann die Fosdem nur empfehlen, wenn ihr die Gelegenheit habt.</p>


Echtzeit-Einstellungen, Speicher-Überarbeitung & ein Wiki
Unknown — Tue, 30 Dec 2025 00:00:00 +0000
Übersicht</h1>
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.</p>
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</a>. Das hilft enorm.</p>
Außerdem habe ich kürzlich die öffentliche Demo von Steam genommen. Sie spiegelt inzwischen WIRKLICH</em> 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.</p>
Also, hier die neuesten Arbeitsbereiche.</p>
Speicher-Überarbeitung</h2>

  
    
      
      
      
    </picture>
    
    Wir können jetzt das letzte Spiel fortsetzen oder einen bestimmten Spielstand laden.</figcaption>
    
  </figure>
</div>
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</a> und einer kleinen State Machine.</p>
So wird automatisch gespeichert, während manuelle Speicherungen weiterhin möglich sind.</p>
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.</p>
Aktuell sind 5 Speicherstände im 5-Minuten-Takt Standard, aber wenn du die config.toml</code> bearbeitest, kannst du das ändern.</p>
Crash-Reporting & Logging-Überarbeitung</h2>
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!</code> println!</code> eprint!</code> eprintln!</code> info!</code> warn!</code> error!</code> durcheinander benutzt. Debug-Prints wurden zu permanenter Ausgabe.</p>
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:</p>

Alle stdout/err-Sachen rauswerfen außer info!</code> warn!</code> error!</code> und panic!</code>. Plugin für Plugin migriert.</li>
Ein non-blocking Tracing-Capture-System hinzugefügt, das die Ausgabe an eine Log-Datei anhängt.</li>
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.</li>
</ol>

  
    
      
      
      
    </picture>
    
    Nach einem erkannten Crash können wir Logs hochladen.</figcaption>
    
  </figure>
</div>
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?"</em>-Diskussionen mehr.</p>
Zuletzt habe ich eine kleine Library hinzugefügt, die Panics in der GUI anzeigt</a>. Im allerschlimmsten Fall kann ein Spieler die Ausgabe kopieren und einfügen.</p>
Einstellungen-Überarbeitung</h2>

  
    
    
  </video>
  
  Du kannst Grafikeinstellungen in Echtzeit ändern.</figcaption>
  
</figure>
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.</p>
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.</p>
Hab einen ECS/Bevy-zentrierten Ansatz gewählt und finde, es ist gut gelaufen.</p>
Die Einstellungen funktionieren jetzt so: Sie werden zur/von der config.toml</code>-Datei serialisiert/deserialisiert und sind im Spiel als eine Reihe von Resource-Structs dargestellt.</p>
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.</p>
Nehmen wir zum Beispiel das Ändern der ScreenSpaceAmbientOcclusion</a>-Einstellungen im Spiel.</p>
In einer ECS-Welt ist das einfach. Wir finden die globale Kamera-Entity, indem wir Entities mit der Exofactory-GlobalCamera</code>-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.</p>
Das Gleiche gilt für jede Einstellung.</p>
Alle Einstellungen sind einfach Properties in einem Resource</a>-Struct, die auf spezifische Komponenten gespiegelt werden.</p>
Das Ergebnis: Man kann jede Einstellung jederzeit in Echtzeit ändern – inklusive Sprache, Grafik, Fenstergröße/-modus und alles andere.</p>

  
    
    
  </video>
  
  Sprache und alles andere auch.</figcaption>
  
</figure>
Ziemlich cool, finde ich.</p>
Wiki</h2>
Die Idee hinter dem Wiki: Ein community-orientiertes Wiki</a> 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</a> zu lizenzieren.</p>
Ich weiß, es ist etwas früh, das Wiki aufzusetzen, aber ich wollte es aus folgenden Gründen tun:</p>

Ein echter Bedarf an Dokumentation rund um die config.toml</a>-Datei.</li>
Der Wunsch, Wikis auf weniger community-orientierten Plattformen zuvorzukommen.</li>
</ol>
Es gibt nicht viel zu sagen, außer dass das Wiki immer nützlicher wird, je näher das Spiel dem Launch kommt.</p>
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.</p>
Fazit</h1>
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.</p>
Das und das Speichersystem MIT</strong> Crash-Reporting ist super nice.</p>
Ziemlich happy und freu mich drauf, richtig an der viel besseren Demo 2 zu arbeiten.</p>


Ziehbare Fließbänder, Elektrizität & Ansichtsmodi
Unknown — Thu, 04 Dec 2025 00:00:00 +0000
Übersicht</h1>
Diesen Monat habe ich mich auf ein paar neue Bereiche konzentriert: wichtige Spielmechaniken, Visuals und große Quality-of-Life-Verbesserungen bei der Fließband-Platzierung.</p>
Wir kommen dem Ziel immer näher, das gesamte Feedback vom Oktober-Nextfest umzusetzen, das sich durch reines Programmieren lösen lässt – und ich denke, man sieht es dem Spiel an.</p>
Ich bin super happy, Elektrizität hinzugefügt zu haben. Es ist ein Kern-Feature, und während das Hinzufügen selbst nicht so schwer war, war die Visualisierung kniffliger. Aber ich finde, der Shader-basierte Ansatz sieht richtig cool aus. Super zufrieden mit dem Produktivitäts-/Effizienz-Ansichtsmodus-Shader unten.</p>
In den folgenden Abschnitten gehe ich etwas tiefer ins Detail.</p>
Ziehbare Fließbänder</h1>

  
    
    
  </video>
  
  Fließbänder ziehen, um Gebäude zu verbinden, ist jetzt einfach.</figcaption>
  
</figure>
Ziemlich viel Zeit ging für ziehbare Fließbänder drauf. Die Band-für-Band-Platzierung wie in Factorio funktioniert zwar, aber beim Spielen wurde mir klar, dass es schnell nervt. Das Feedback war da universal einer Meinung.</p>
Das Interessante ist, dass Exofactory einen "kachelbasierten" Fließband-Ansatz verwendet, weshalb der Spline-basierte Ansatz anderer Fabrikspiele nicht wirklich möglich war. Nach dem Spielen vieler anderer Fabrikspiele</del> ausgiebiger Recherche habe ich einen Ansatz gefunden, der ähnlich wie bei Shapez2</a> funktioniert – angepasst für 3D und die Eigenheiten von Exofactory.</p>
Kurz gesagt: Man platziert das erste Fließband-Segment und kann dann ein gerades oder "L"-förmiges Segment beliebiger Länge herausziehen, solange man die Ressourcen dafür hat. Die einzige echte technische Einschränkung ist, dass man nur eine Biegung pro gezogenem Segment haben kann. Mehr würde nur zu Mehrdeutigkeit und unvorhersehbaren Ergebnissen führen.</p>

  
    
    
  </video>
  
  Längere Fließband-Verbindungen brauchen jetzt viel weniger Aufwand.</figcaption>
  
</figure>
Das macht das Spiel deutlich weniger mühsam und ich bin super froh, dass es fertig programmiert ist.</p>
Elektrizität</h1>

  
    
    
  </video>
  
  Gebäude verbinden sich automatisch mit der nächsten Stromquelle in Reichweite.</figcaption>
  
</figure>
Ich habe auch kürzlich Strom ins Spiel eingebaut. Alle Gebäude verbrauchen jetzt Elektrizität und funktionieren ohne nicht. Gebäude im Bereich einer Stromquelle oder eines Verstärkers verbinden sich automatisch und beginnen Strom zu verbrauchen.</p>
Im Moment erzeugt der Core genug Strom, um eine kleine Fabrik zu betreiben. Sobald ich Brennstoffe und Rohrleitungen richtig einbaue, wird es möglich sein, die Stromproduktion richtig hochzufahren.</p>
Vom Programmier-Standpunkt aus war das ein ziemlich einfaches Feature. Einfach ein paar ECS</a>-Komponenten hinzufügen und fertig – Gebäude aktualisieren ihre Komponenten während ihrer Zyklen und die Stromsysteme fragen sie entsprechend ab.</p>
Der schwierige Teil war die Visualisierung. Dazu unten mehr.</p>
Ansichtsmodi</h1>
Ein Feedback-Punkt war: „Was bringt der Global-Modus eigentlich?"</em> – und ehrlich gesagt ist der globale Ansichtsmodus in der Demo weniger nützlich, als er sein sollte. Der Hauptgrund: Die Ansichtsmodus-Features waren noch nicht da.</p>
Jetzt kann ich sie endlich zeigen. Meine Güte, musste ich viel über Shaders</a>, Stencils</a> und Skinning</a> lernen, um das zum Laufen zu bringen.</p>
Die Ansichtsmodi sind im Global-Modus über die Tab-Taste oder den entsprechenden Controller-Button erreichbar.</p>
Strom</h2>

  
    
    
  </video>
  
  Man sieht die versorgten Zonen und welche Gebäude und Kabel Strom haben oder nicht.</figcaption>
  
</figure>
Dieser Ansichtsmodus zeigt, welche Gebäude Strom haben und welche nicht. Man sieht auch die versorgten Zonen und welche Kabel verbunden sind. Einfach, schnell und nützlich.</p>
Obwohl die Ansichtsmodi ein Feature für den Global-Modus sind, kann man beim Platzieren von Stromverstärkern die versorgten Zonen und so weiter sehen – einfach um den Verstand zu schonen.</p>
Produktivität</h2>

  
    
    
  </video>
  
  Die Farbe der Gebäude zeigt ihre Produktivität. Grün für 100%, Rot für 0%.</figcaption>
  
</figure>
Darauf bin ich ziemlich stolz und ich denke, es bringt etwas Neues ins Fabrikspiel-Genre. Der Produktivitätsmodus zeigt auf einen Blick die Produktivität einer ganzen Landschaft von Maschinen. Rote oder gelbe Bereiche einer Fabrik fallen sofort auf.</p>
Im Video oben sieht man, wie die Produktivität sinkt, wenn sich der Ausgabepuffer füllt. Wie der Strom-Ansichtsmodus ist dieser Modus über die Tab-Taste im Global-Modus erreichbar.</p>
Fazit</h1>
Es hat sich richtig gut angefühlt, endlich mal wieder ein neues Feature hinzuzufügen nach so vielen Bugfixes. Super happy damit. Jetzt muss ich nur noch das Emotional-Core-/Dialogsystem anpassen, um diese neuen Systeme widerzuspiegeln. Viel Spaß und viel zu tun.</p>


Quality-of-Life-Änderungen, welche sich für ein Fabrikspiel gehören
Unknown — Sun, 16 Nov 2025 00:00:00 +0000
Übersicht</h1>
In den letzten Wochen gab es zwei Haupttreiber für meine Arbeit: das Feedback aus der Demo und die Portierung von Bevy 0.16 auf 0.17</a> sowie der Wechsel zur Avian</a>-Physik-Engine.</p>
Unten gehe ich auf die neuen Quality-of-Life-Verbesserungen aus dem Feedback ein, aber zuerst möchte ich erklären, warum ich zu Avian gewechselt bin und welche Arbeit das mit sich brachte.</p>
Wechsel zu Avian</h2>

  
    
      
      
      
    </picture>
    
    Automatisch generierte Avian-Collider-Meshes</figcaption>
    
  </figure>
</div>
Ursprünglich habe ich das bewährte Rapier 3D</a> genutzt, war aber aus mehreren Gründen unzufrieden.</p>

Hohe Entwicklungslatenz. Angesichts der schnellen Veränderungen im Bevy-Ökosystem und den großen Verbesserungen in jeder Version war das ein echter Motivationskiller. Zum Zeitpunkt dieses Posts unterstützt Rapier noch immer kein Bevy 0.17.</li>
Etwas sperrige, nicht ganz elegante API.</li>
Keine automatische Collider-Generierung.</li>
</ol>
Trotzdem: Rapier ist eine solide Engine, und die Arbeit von dimforge</a> für die Bevy-Community ist großartig. Sie ist einfach nicht der beste Fit für mich.</p>
Der Wechsel zu Avian hat all diese Punkte adressiert und Dinge wie Raycasting</a> deutlich angenehmer gemacht.</p>
Dazu kommt das hervorragende Collider-Konstruktionssystem</a>. <3 ConvexDecompositionWithConfig</a></p>
Ein kleines Problem gab es dennoch: Avian hat keinen eigenen Character Controller</a> wie Rapier. Nach einem Blick in die Avian-FAQ</a> bin ich aber bei bevy_tnua</a> gelandet – eine ausgezeichnete Alternative.</p>
Zeitlich hat der gesamte Port einen Tag gedauert. Ungefähr:</p>

2 Stunden für alle Collider und das Feintuning.</li>
3 Stunden, um das Raycasting auszutauschen und die Collision Layers</a> einzurichten. (Mit Enums sehr angenehm.)</li>
3 Stunden, um die komplette Spielersteuerung auf tnua umzuziehen.</li>
</ul>
Dank der Arbeit von Joona Aalto</a> bin ich sehr zufrieden mit Avian. Ich unterstütze ihn gern – und wenn ihr Avian mögt, könnt ihr das auch überlegen.</p>
Allgemeine Quality of Life</h1>

  
    
    
  </video>
  
  Wir können jetzt springen!</figcaption>
  
</figure>
Da tnua das Implementieren eines Sprungs einfach gemacht hat, habe ich ihn direkt eingebaut. Mit einer leicht umfunktionierten Animation – mehr dazu später – war das schnell erledigt.</p>

  
    
      
      
      
    </picture>
    
    Die Baukosten werden jetzt direkt im Menü angezeigt.</figcaption>
    
  </figure>
</div>
Hier kommt die erste große Verbesserung basierend auf Feedback. Es wurde sehr deutlich, dass die Kosten von Gebäuden klar und zu jedem Zeitpunkt sichtbar sein müssen: davor, währenddessen und wenn man etwas nicht bauen kann. Jetzt sieht man beim Hovern oder Auswählen eines Gebäudes sofort die Kosten.</p>

  
    
      
      
      
    </picture>
    
    Beim Platzieren sieht man die Kosten plus vorhandene Ressourcen.</figcaption>
    
  </figure>
</div>
Maschinenproduktivität</h1>

  
    
    
  </video>
  
  Die Mining-Maschine zeigt jetzt ideale und reale Outputs.</figcaption>
  
</figure>
Hier steckt der Großteil der Arbeit drin. Durch das Feedback von Factory-Game-Fans wurde mir schmerzhaft bewusst, dass ich einen absolut grundlegenden Punkt des Genres vergessen hatte: Spieler müssen klar sehen können, was verbraucht wird, was erzeugt wird und wo sie optimieren können.</p>
Ich spiele selbst gern Satisfactory</a> und Factorio</a>. Keine Ahnung, wie ich das übersehen habe. Aber jetzt ist es drin.</p>
Und: Es war ein Vergnügen, das mit Bevys ECS-System umzusetzen. Für solche Berechnungen gibt es schlicht keinen besseren Ansatz. Man fragt einfach alle Maschinen ab, deren Werte aktualisiert werden müssen, verarbeitet sie parallel und macht weiter. Wunderbar.</p>

  
    
    
  </video>
  
  Der Ofen zeigt klar, was er wirklich braucht und was er produzieren sollte.</figcaption>
  
</figure>
Einstellungen</h1>
Ein weiterer Grund, warum ich auf Bevy 0.17 gewartet habe, war das überarbeitete UI-System mit Observers</a>. Damit konnte ich weg von Buttons und hin zu Slidern – deutlich sauberer. Mit Observers fühlt sich UI-Programmierung weniger sperrig an. Die Einstellungsseite ist jetzt viel besser.</p>
Eine wichtige Verbesserung betrifft die Controller-Anzeige. Zuvor wurden Tastatur- und Maussteuerungen angezeigt, außer man hatte einen Xbox- oder Steam-Controller eingesteckt. Das führte zu Situationen, in denen Spieler nicht die passenden Hinweise sahen. Jetzt zeigt das Spiel standardmäßig an, was zuletzt genutzt wurde. Sehr viel besser.</p>
</p>
</p>
</p>
Website-Überarbeitung</h1>
Noch im Aufbau, aber ein klares Feedback war, dass die Website kaum erklärt, worum es im Spiel überhaupt geht. Eine reine Textseite ist für ein Videospiel eher unüblich. Daher gibt es jetzt eine animierte Startseite.</p>
In den kommenden Wochen werde ich weitere Bereiche mit mehr Medien und Informationen ergänzen. Dranbleiben lohnt sich.</p>
Fazit</h1>
Viele Quality-of-Life-Verbesserungen basierend auf viel Feedback, und es kommt noch mehr. Ich bin ziemlich zufrieden damit und freue mich auf die nächsten Features.</p>


Steam-Next-Fest-Nachklang
Unknown — Tue, 21 Oct 2025 00:00:00 +0000
Überblick</h1>
Das Steam Next Fest war ein Erfolg – wenn auch ein stressiger. Die gute Nachricht: Über Steam, Discord und andere Kanäle kam massenhaft Feedback, und viele Edge-Case-Bugs konnten schnell gefixt werden.</p>
Ich wusste nicht, dass so viele Tastaturen dem Betriebssystem melden, sie seien Xbox-HID-Geräte. Verrückt.</p>
Auf Basis all der Erkenntnisse kann ich den Fahrplan fürs Spiel nun klarer definieren.</p>
Next-Fest-Ergebnisse</h1>
Viel Gutes</h2>

Zahlreiche Bugs wurden entdeckt und fixiert. Vielen Dank an alle, die sie gemeldet haben.</li>
Das Spiel hat enorm viel Interesse geweckt, sowohl bei Wunschlisten als auch bei Spielzeit.</li>
Es gab viele Ideen, wie man Dinge verbessern oder reparieren kann.</li>
</ul>
Weniger Gutes</h2>

Ich habe die Hardwarevielfalt außerhalb der Soft-Launch-Tester unterschätzt. Einige Spieler:innen konnten das Spiel erst starten, nachdem mehrere Hotfixes veröffentlicht waren.</li>
Ich dachte, das Spiel wäre vollständig barrierefrei für Geräte und Controller – das Feedback zeigte, dass noch Lücken bestehen.</li>
</ul>
Neuer Zeitplan</h1>
Mit dem Demo-Feedback, dem Rat erfahrener Entwickler:innen und dem Input von Leuten, die erfolgreiche Spiele produzieren, ergibt eine Anpassung des Release-Plans Sinn.</p>
Q4 2025 war schlicht unrealistisch. Punkt.</p>
Also braucht es einen neuen Plan:</p>

Eine deutlich funktionsreichere und polierte Demo veröffentlichen, die sich für ein Pitch-Deck eignet und die Zielqualität zeigt.</li>
Prüfen, wie die weitere Finanzierung aussehen kann – etwa Kickstarter, Investment oder Zusammenarbeit mit einem Publisher.</li>
Den Full Release für Ende 2026 anpeilen.</li>
</ol>
Wie jemand einmal sagte: „Ein verschobenes Spiel wird irgendwann gut, ein übereilt veröffentlichtes bleibt für immer schlecht.“</em></p>
Ob Meme oder nicht – ich will ein Spiel veröffentlichen, auf das ich stolz bin.</p>
Fazit</h1>
Ich lerne ständig dazu – sowohl beim Spiel als auch bei meiner Sicht auf die Branche. Next Fest und all die Menschen, die sich gemeldet haben, haben mir unglaublich viel beigebracht. Dadurch wird das Spiel besser. Spannende Zeiten stehen bevor – jetzt gibt es einen Berg Feedback, den ich angehen kann.</p>


Demo-Release und Feinschliff
Unknown — Tue, 07 Oct 2025 00:00:00 +0000
Überblick</h1>
Es ist viel passiert, aber das Wichtigste: Die Demo wurde als Soft-Launch auf Steam veröffentlicht – pünktlich zum Steam Next Fest. Du kannst sie über den Link am Ende dieses Beitrags laden. Es gibt Builds für Linux und Windows.</p>
Die Arbeit dafür war enorm, und hier fasse ich einiges davon zusammen.</p>
Steam Next Fest</h2>

  
    
      
      
      
    </picture>
    
    Der hübsche Demo-Download-Button.</figcaption>
    
  </figure>
</div>
Die große Neuigkeit: Wir machen offiziell beim Steam Next Fest im Oktober mit. Alles ist eingerichtet und genehmigt. Der Prozess war überraschend schwierig und deutlich komplizierter, als ich dachte. Es reicht eben nicht, einfach eine ELF</a>- oder .exe</a>-Datei hochzuladen. Man muss eine Menge Steam-spezifischer Tools</a> verwenden – immerhin laufen sie nativ auf Linux. Aber es ist viel zu lernen, besonders wenn man sich nur einen Tag zum Verpacken und Hochladen gegeben hat.</p>
Mein Tipp an alle Programmierer:innen, die zu Game-Devs werden: Plant fürs Packaging mehr Zeit ein, als ihr meint zu brauchen. Für mich war ein Steam-Build härter vorzubereiten als ein RPM</a>- oder DEB</a>-Paket.</p>
Die gute Nachricht: Die Deadline wurde gehalten – knapp, aber geschafft.</p>
Testpannen</h2>
Damit sind wir beim nächsten Punkt. Falls du dich für Alpha/Beta-Tests angemeldet hast: Du wurdest nicht vergessen. Durch</p>

die ungeplanten Verzögerungen bei der Steam-Freigabe,</li>
die unerwarteten Schwierigkeiten beim Packaging und</li>
die vielen „Blocker“-Bugs, die ich auf Zuruf von Freund:innen und Familie gefixt habe,</li>
</ol>
konnte ich keine frühen Test-Keys hochladen, bevor die Demo fürs Next Fest rausmusste.</p>
Sorry dafür. Künftig strukturiere ich den Entwicklungsprozess klarer – mit gezielten Phasen für Features, Tests und Polishing. Für das Hauptspiel wird es regelmäßige, besser planbare Testzeiträume geben.</p>
Animationen & Mechaniken</h2>

  
    
    
  </video>
  
  Lifter, Bänder, Splitter und Merger</figcaption>
  
</figure>
Hier landete der meiste Crunch. Ein Nachteil von ECS: Unabhängige Animationen zu synchronisieren ist knifflig. Es fühlt sich an, als würde die Welt nach einer Leibnizschen prästabilierten Harmonie</a> laufen – keine expliziten Verbindungen, nur Async-Systeme, die so orchestriert werden, dass Illusion zur Realität wird.</p>
Kurz gesagt: Das Spiel verhält sich jetzt wie ein echtes Spiel – mit Animationen, Sound und allem, was dazugehört.</p>
Demo veröffentlicht + Trailer</h2>
Der spaßige Teil: Auch wenn noch keine Mails rausgingen, lässt sich die Demo schon herunterladen und spielen. Vielleicht schaffe ich noch einen kleinen Bugfix-Build vor dem offiziellen Start des Next Fest. Wenn dir Fehler auffallen, melde sie gern im Exofactory-Bugreport-Channel auf Discord</a>.</p>
Außerdem gibt es einen kurzen Gameplay-Trailer! Mangels verifiziertem YouTube-Account läuft er direkt auf der Steam-Seite.</p>
Roadmap</h2>
Die Demo ist nur der Anfang. Für das vollständige Spiel stehen große Verbesserungen an. Ich bin offen für Vorschläge – poste sie gern im Feature-Suggestion-Channel auf Discord</a>.</p>
Eine ausführlichere Roadmap folgt bald auf dieser Website. Die Listen hier sind vorläufig und sehr unvollständig.</p>
Bald</h3>

  
    
      
      
      
    </picture>
    
    Barrierefreiheit zuerst: Steam Deck und Controller</figcaption>
    
  </figure>
</div>

Vollständige, barrierefreie Steam-Deck- und Controller-Unterstützung.</li>
Überarbeitung von Terrain- und Vegetations-Assets.</li>
Massive Optimierungsrunde.</li>
Erste verzweigende Tech-Tree-Pfade basierend auf deinen Entscheidungen.</li>
Öffentliches Wiki – wie es sich für ein Fabrikspiel gehört.</li>
Weitere Arbeit am „richtigen“ Terrain.</li>
Echter Energieverbrauch.</li>
Flüssigkeiten.</li>
Deutsch.</li>
Tests von ELF-Binaries für aarch64</a> und RISC-V</a>, sofern möglich.</li>
</ul>
Später</h3>

Spiel-Binaries für mehr Rust Tier 1- und Tier 2-Plattformen</a>. (Wer hilft beim Test auf den BSDs?)</li>
Steam-freie Spieloption à la Factorio</a>.</li>
Offiziell unterstützte Flathub</a>-/Flatpak</a>-Images.</li>
Laufende Arbeit am „richtigen“ Terrain.</li>
</ul>
Fazit</h1>
Die Demo ist draußen, und ich freue mich darauf, am vollständigen Spiel weiterzuarbeiten. Ich bin gespannt, was ihr daraus macht.</p>

  
    
      
      
      Demo auf Steam</span>
    </div>
  </a>
</div>


Private Alpha, Steam & Kernfunktionen
Unknown — Mon, 08 Sep 2025 00:00:00 +0000
Überblick</h1>
In den letzten 30 Tagen hat das Spiel den Sprung von „ein bisschen Sorge“ zurück auf Kurs geschafft. Wir planen, beim Steam Next Fest im Oktober dabei zu sein! (Mehr unten.) Der Großteil der Arbeit betraf fundamentale Systeme – viel Code, wenig neue Optik. Aber der Code ist jetzt in einem großartigen Zustand. Nächsten Monat sollte das Demo voller neuer Visuals und Sounds sein. Der September steht im Zeichen von Grafik, Feinschliff und Tests. Spannende Zeiten!</p>
Private Alpha</h2>
In der zweiten Monatshälfte möchte ich eine kleine, fokussierte private Alpha zum Testen veröffentlichen. Wenn du Interesse hast, kannst du dich auf der Homepage</a> anmelden – dort findest du einen Button dafür.</p>
Nur zur Warnung: Das wird eine echte technische Alpha mit potenziell vielen Bugs, UI-/UX-Problemen und Playability-Schmerzen. Wenn du einfach nur spielen möchtest, warte lieber auf das Steam Next Fest. Wenn du Lust hast zu debuggen und Feedback zu geben, bist du herzlich willkommen.</p>
Steam Next Fest</h2>
Wir liegen im Zeitplan und planen fest mit dem Steam Next Fest im Oktober. Die Freigabe ist da – wir müssen nur bis Ende September den finalen Demobuild einreichen.</p>
Geplant ist eine kostenlose Vertical-Slice-Demo. Ziel: Lass die Leute eine Fabrik nach ihren Vorstellungen bauen und schau zu, wie sich basierend darauf die Story verändert. Ich peile eine kurze Demo an – je nach Bauweise soll sich Stimmung, Ton und Richtung aber unterscheiden. Ohne Skripts sollte jede Session zumindest ein wenig, wahrscheinlich sogar stark variieren.</p>
Das Ganze steuert der emotionale Kern – und der ist ziemlich cool.</p>
Zur Einordnung: Die Demo wird eher kurz (ca. 10–15 Minuten bei schnellem Spiel). Das vollständige Spiel entsteht gemeinsam mit der Community im Early Access, mit einem Full Release irgendwann 2026.</p>
Förderband-Grundlagen & Logistik</h2>
Der Löwenanteil der Entwicklung steckte hier drin. Ein Fabrikspiel ohne robustes, performantes Band- und Logistiksystem existiert schlicht nicht.</p>
Ich denke, das habe ich jetzt. Erst seit dieser Arbeit verstehe ich, warum andere Devs über den Schmerz von Förderband-Entwicklung klagen. Ich gehöre jetzt offiziell dazu.</p>
Der Vorteil: Dank Bevys ECS-Architektur bekomme ich quasi gratis Performance. Alles läuft parallel und nutzt alle CPU-Kerne, damit deine Fabrik smooth durchzieht. Wenn du die Grafik extrem aufdrehst, kannst du die FPS sicher drücken, aber die Größe der Fabrik allein sollte nie zum Problem werden.</p>
Hier folgt eine grobe technische Erklärung. Überspring sie gern, wenn du magst.</p>

  
    
    
  </video>
  
  Förderbänder in Aktion</figcaption>
  
</figure>
Wie Förderbänder wirklich funktionieren</h3>
Bänder organisieren sich automatisch in gerichtete „Segmente“. Segmente bestehen aus Ketten von Bändern zwischen allem, was Items ausgibt, und allem, was welche annimmt. Jede Band-Entität bekommt eine Komponente, die markiert, zu welchem Segment sie gehört. Das passiert über Observer und nur beim Platzieren/Entfernen der Bänder.</p>
Zur Klarstellung: Es gibt nirgendwo eine Linked List. Wir taggen schlicht die Band-Entities mit Segment-Komponenten.</p>
Verbindungen und Segmentbildung</h3>
</p>
Gebäude und Bänder deklarieren ihre Ein- und Ausgänge auf dem Grid. Beim Platzieren schaut der IO-Punkt ein Feld in Blickrichtung und verbindet sich nur, wenn der Nachbar kompatibel ausgerichtet ist. Bei Verbindung fügt das Gebäude dem Segment eine Quelle oder Senke hinzu. Oben die großen Debug-Würfel zeigen die überwachten Tiles.</p>
Während du Bänder oder Gebäude platzierst, ordne ich die Bänder von echtem Anfang bis Ende neu, damit die Kette kohärent bleibt, und baue einen „Visual Path“-Spline direkt aus den Weltkoordinaten jedes Bandes. Entfernst du ein Band, berechne ich die verbundenen Gruppen neu, splitte Segmente bei Bedarf und weise Gebäuden die richtigen neuen Segmente zu.</p>
Das waren gut 95 % der Arbeit.</p>
Item-Bewegung</h3>
Items bewegen sich entlang eines stückweise zusammengesetzten Satzes von Cubic-Hermite-Splines</a>, die aus den Band-Positionen erzeugt werden. Das ist super effizient, da alle Splines vorab berechnet sind. Wir verschieben die Items nur mit einem Timer, der ebenfalls vorab anhand Segmentlänge und Bandgeschwindigkeit ermittelt wird.</p>
Kapazität, Durchsatz und Backpressure</h3>
Kapazität wurde nach dem „as simple as possible“-Prinzip gelöst: Eine Band-Entität = ein Item. Ein Segment mit 20 Band-Entities fasst 20 Items. Einfügen klappt nur, wenn Platz ist. Maschinen mit Output-Puffer schieben Items ins Segment, sobald Luft ist. Ist das Segment voll, füllt sich der Puffer und die Produktion pausiert auf natürliche Weise; sobald die Linie frei wird, läuft alles automatisch weiter. Ähnlich funktioniert es bei Inputs.</p>
Performance</h3>
</p>
Alles basiert auf ECS und läuft komplett parallel. Weil Segmente isoliert sind und Bevy großartig ist, kann ich einen Async-Pool aufsetzen, der so breit wie deine CPU-Kerne ist. Segmente verarbeiten ihre Items und schicken sie über das beziehungsbasierte Source/Sink-System weiter. Oben siehst du Gebäude mit hervorgehobenen IOs.</p>
Neue Gebäude & Ressourcen</h2>
Seit dem letzten Dev-Blog kamen einige neue Gebäude hinzu – alle ziemlich spannend.</p>
Mining Platform v1</h3>

  
    
    
  </video>
  
  Die Mining Platform in Aktion</figcaption>
  
</figure>
Das ist der erste Rohstoff-Extraktor für Spielende. Er holt Erze vom Planeten, wie es die Menschen einst beigebracht haben.</p>
Ancient AI Core</h3>
</p>
Hier sitzt der Verstand der Spieler-KI. Hier warst du … sehr lange.</p>
Sneak Preview: Gasförderer</h3>
</p>
Hier ein erster Blick auf den Gas-Extraktor. Nicht alles ist schließlich ein Mineral.</p>
Musik</h2>
Ich freue mich riesig über die Zusammenarbeit mit Repto Eternef</a>. Sie erschaffen großartige Musik fürs Spiel und helfen, die Exofactory-Music-Engine aufzubauen, die wir 2026 vor Release als Open Source veröffentlichen wollen.</p>
Dialog & der emotionale Kern</h2>
</p>
Nicht zuletzt wurde der emotionale Kern plus Dialogsystem implementiert.</p>
Der emotionale Kern ist das Herzstück von Exofactory. Technisch betrachtet beobachtet er alle Aktionen der Spielenden: jedes Bauen, Zerstören, jede Bewegung, Produktion – wirklich alles. Zusammen mit einem Blick auf das Gesamtbild deiner Fabrik, die Interaktionen der Systeme und fehlende Verbindungen leitet er die Story-Richtung ab.</p>
Ziel ist eine von den Spielenden getriebene Erzählung, allein basierend auf ihrer Fabrik. Ich möchte niemals ein „Wähle Option A oder B“-Popup einsetzen. Das Spiel soll deine Prioritäten kennen, weil es sieht, wie, wo und was du baust.</p>
Am deutlichsten spürst du das durch den inneren Monolog der KI, dem du im Spiel zuhörst. Tonfall, Gedankenrichtung und Inhalt werden vom emotionalen Kern an das Dialogsystem geliefert, das sie anzeigt und vertont. Derzeit evaluiere ich Open-Source-TTS-Systeme, die die vielen, vielen potenziellen Zeilen einsprechen können.</p>
Fazit</h1>
Es gab massive Fortschritte an den Kernsystemen und alles liegt im Plan. Ich bin gespannt, wie Spieler:innen die Systeme nutzen, an denen ich arbeite. :)</p>
Exofactory ist jetzt auf Steam verfügbar! Wenn dich das Spiel interessiert, würde ich mich freuen, wenn du es dort auf die Wunschliste setzt.</p>

  
    
      
      
      Auf Steam vormerken</span>
    </div>
  </a>
</div>


Animation, Bewegung & Terrain v3
Unknown — Thu, 07 Aug 2025 00:00:00 +0000
Exofactory ist jetzt auf Steam verfügbar! Wenn dich das Spiel interessiert, freue ich mich, wenn du es dort auf die Wunschliste setzt.</p>

  
    
      
      
      Auf Steam vormerken</span>
    </div>
  </a>
</div>
Überblick</h1>
Mehrere große Ziele wurden erreicht: Das Spiel ist animiert, wir haben erste Ressourcen und das Terrain-System nähert sich dem Status „fertig“. Es war nicht die produktivste Periode überhaupt, aber der Kurs stimmt.</p>
Außerdem habe ich auf Bornhack 2025</a> einen Vortrag über Spieleentwicklung in Bevy mit Rust gehalten. Er ist noch nicht veröffentlicht – sobald das Video online ist, verlinke ich es in einem späteren Dev-Blog.</p>
Animation</h1>
Es gibt jetzt Animationen im Spiel! Animationen in Bevy zu lernen hat Spaß gemacht. Der Lebensretter (und enorme Zeitersparnis) war das Bevy-Ökosystem, konkret das hervorragende Bevy/Blender-Plugin Skein</a> von Chris Biscardi</a>. Er tut unglaublich viel für die Bevy-Community und ich sehe seine Arbeit überall.</p>
Skein ist ein Plugin sowohl für Bevy als auch für Blender und erlaubt 3D-Artists, Bevy-Komponenten (falls dir Bevy neu ist: Komponenten sind quasi Tags) direkt an Teilen eines 3D-Assets zu hinterlegen. Beim Export als glb/gltf werden diese Komponenten mit gespeichert.</p>
Auf der Bevy-Seite liest Skein die eingebetteten Komponenten aus und stellt sie im Entity Component System</a> bereit. Das spart massig Zeit und Boilerplate.</p>

  
    
    
  </video>
  
  Programmgesteuerte Steuerung der Lifter-Animation</figcaption>
  
</figure>
Wir nutzen Skein, um Animation-Bones mit Komponenten zu versehen. So lassen sich Animationen programmatisch steuern und auf Spielereignisse reagieren, statt nur stupide Schleifen abzuspielen. Hauptsächlich setzen wir das derzeit bei den Liftern ein, wie oben zu sehen.</p>

  
    
    
  </video>
  
  Animationstransitionen</figcaption>
  
</figure>
Zusätzlich verwenden wir Bevy's Animation-Graph-System</a>. Damit wechseln wir weich von einem Animationszyklus zum anderen – ohne Ruckler oder Artefakte. Im Beispiel geht der Exoframe fließend vom Laufen in den Idle-Zustand über.</p>
Ressourcen</h1>
Wir haben nun Ressourcen! Den Anfang machen Eisen und Kupfer. Bald werden Maschinen richtig loslegen.</p>

Hier siehst du Kupfererz und -barren. Davon wird es reichlich geben, unter anderem für stromsparende Kabel.</p>

Und hier Eisen. Ich liebe die Details auf der Oberseite der Barren. Da wir als KI spielen, kann ich mir vorstellen, dass die KI den Look ebenfalls feiert.</p>
Terrain v3</h1>
Die Bevy-Welt ist voll von halbgar gepflegten und schlecht dokumentierten Terrain-Level-of-Detail-Systemen (LoD)</a>. Es gibt unzählige Ansätze, aber ich habe keinen gefunden, der gepflegt, funktionsreich und ordentlich dokumentiert ist. Deshalb hat Exofactory jetzt eine eigene LoD-Implementierung. Noch relativ simpel, aber sie erfüllt meine Basisanforderungen:</p>

Terrain abhängig von der Position mehrerer</em> Kameras ein- und ausblenden.</li>
Höher- und niedrigauflösende Meshes sowie Texturen anhand dieser Kameras austauschen.</li>
LoD auch für Details wie Vegetation oder Steine handhaben.</li>
Das Ganze performant und Bevy-nativ im ECS umsetzen.</li>
</ol>

  
    
    
  </video>
  
  Tests des Level-of-Detail-Systems</figcaption>
  
</figure>
Oben siehst du das Testterrain, mit dem ich das System geprüft habe: Grün markiert die Kachel unter der aktiven Kamera, Gelb die höher aufgelösten Tiles, Rot die niedrigeren – und das entfernte Rot wird despawnt.</p>
Das ist eine deutlich stärkere Grundlage für Terrain, auch wenn viel Arbeit aus früheren Versionen neu geschrieben werden musste. Gute Nachricht: Terrain v3 lässt sich hervorragend auf Ästhetik oder Performance abstimmen. Selbst auf meinem alten 11th-Gen-Intel-Laptop mit iGPU lief die volle Sichtweite bei 60fps. Klar, das kann sich ändern, wenn mehr Systeme hinzukommen.</p>

  
    
    
  </video>
  
  Terrain v3 nur mit Grundfarben</figcaption>
  
</figure>
Hier eine weiterentwickelte (weiterhin texturlose und noch leere) Version des Terrain-v3-Systems mit kompletter LoD-Funktionalität. Texturen und Details kommen später per Shader auf der GPU – die Grundfarben geben schon eine Idee, wohin es stilistisch geht. Sobald wir Terrain-Details ergänzen, wird das richtig gut aussehen.</p>
Fazit</h1>
In dem Zeitraum hätte ich gern mehr geschafft. Trotzdem war alles, was fertig wurde, sehr wirkungsvoll: Das Spiel ist spielbarer – und wichtiger in dieser Phase – besser testbar. Keine Ruckler mehr beim Überqueren von Terrain-Kacheln. Alles wirkt weich und angenehm. Und die Animationen bringen richtig Leben in die zuvor statische Welt.</p>


Terrain, Animationen und jede Menge Fortschritt
Unknown — Sun, 06 Jul 2025 00:00:00 +0000
UPDATE:</strong> Wir wurden freigeschaltet – Exofactory ist jetzt auf Steam verfügbar</a>.</p>
Überblick</h1>
Der vergangene Monat war voller Fortschritte. Das Terrain wurde komplett überarbeitet (mehr dazu gleich), dank Julef</a> gibt es zahlreiche animierte 3D-Assets, und alles ist vorbereitet, um auf Steam präsent zu sein.</p>
Außerdem durfte ich an der großartigen Hacker- und Maker-Konferenz GPN23</a> teilnehmen – eine der chilligsten Veranstaltungen überhaupt (Stimmung, nicht Temperatur). Ich wurde „überredet“, einen Lightning Talk darüber zu halten, wie man Spiele mit Rust und Bevy entwickelt. Falls du Lust hast, kannst du ihn hier anschauen</a>. Das Feedback war so positiv, dass ich bald sogar einen längeren Vortrag auf einem weiteren Event halten werde.</p>
Als Bonus teilt Julef</a> in ihrem ersten Blogbeitrag Einblicke in ihre Arbeit an Exofactory.</p>
Mehr folgt!</p>
Animationen</h1>
Ein riesiger Batzen Arbeit steckt in den Animationen und 3D-Arbeiten von Julef</a>. Ich freue mich unglaublich darauf, sie ins Spiel zu integrieren.</p>

  
    
    
  </video>
  
  Wave-Animation</figcaption>
  
</figure>

  
    
    
  </video>
  
  Walk-Animation</figcaption>
  
</figure>

  
    
    
  </video>
  
  Idle-Animation</figcaption>
  
</figure>

  
    
    
  </video>
  
  Szene mit Bändern und Maschinen</figcaption>
  
</figure>
Hinter den Kulissen mit Julef</h1>
Hallo, hier ist Julija – Art Director und Leiterin des gesamten Art-Teams von Exofactory.</p>
Ich möchte ein kurzes Kunst-Update teilen.</p>
Im letzten Monat haben wir Assets verfeinert und das Terrain weiter verbessert.</p>
Ein Highlight: Der Fabricator hat ein komplettes visuelles Makeover erhalten.</p>

  
  
</div>
Wir haben weitere Bänder der Stufen 1 und 2 ergänzt und ihnen Leben eingehaucht. Es kommt Bewegung ins Spiel!</p>

  
    
    
  </video>
  
</figure>
Auch der Exoframe wurde dank funktionierendem Rig und Animationen lebendig – großes Danke an Juan</a>, der beim Rig-Aufbau unterstützt und die Animationen erstellt hat!</p>

  
    
      
      
    </video>
    
    Walk-Animation</p>
    
  </div>
  
    
      
      
    </video>
    
    Wave-Animation</p>
    
  </div>
  
    
      
      
    </video>
    
    Idle-Animation</p>
    
  </div>
</div>
Wir haben die ersten visuellen Assets für Steam erfolgreich fertiggestellt und eingereicht.</p>
</p>
Und hier seht ihr, was hinter den Kulissen passiert.</p>

</p>
Terrain</h1>
</p>
Hier ist wieder Cait! Wenn das Bild oben Terrain v2 zeigt, seht ihr unten v2.5.</p>
Das Terrain-System wurde überholt. Im neuen System haben wir kein Terrain mehr der Kategorie „Müll“. Ganz zufrieden bin ich trotzdem noch nicht. Wenn das hier Version 2 ist, brauchen wir wahrscheinlich mindestens v4 oder v5, bevor es wirklich gut aussieht. Aber Terrain gehört nun mal zu den härtesten Teilen des Fabrikspiel-Genres. Wenn ich eines Tages damit zufrieden bin, wäre das ein großer Sieg – bis dahin arbeiten wir weiter daran.</p>
Etwas subtiler: Es gibt jetzt ein neues Terrain-Ladesystem. Es streamt Assets und Texturen dynamisch nach, während man durch die Welt navigiert. Das eröffnet spannende Möglichkeiten, beispielsweise später ein Level-of-Detail-System einzubauen.</p>
Steam-Screenshots</h1>
</p>
Die Screenshots waren der härteste Brocken. Ursprünglich wollte ich unseren Steam-Auftritt viel</em> früher vorbereiten, aber ich bekam die Bilder nicht auf einen Stand, der dem Spiel gerecht wurde.</p>
Bevy</a>, die Engine hinter Exofactory, bietet weder Szenen-Viewer noch Preview oder ein Paint-Tool – gar keine GUI. Also musste ich die Fabriken in den Screenshots durch echtes Spielen</strong> aufbauen, genau wie jemand, der das Spiel kauft. Da Funktionen wie „Gebäude löschen“ noch fehlen, kannst du dir vorstellen, wie das lief.</p>
Der Vorteil: Dabei habe ich jede Menge Dinge entdeckt, die ich für mehr Komfort verbessern möchte. Ein Gewinn also.</p>
Hier sind die In-Game-Bilder, die an Steam übermittelt werden. Wir rechnen mit einer baldigen Freigabe.</p>
</p>
</p>
</p>
</p>
Fazit</h1>
Unterm Strich war es ein produktiver Monat. Überall wurde großartige Arbeit geleistet – besonders von Julef.</p>
Einziger Wermutstropfen: Durch das hohe Tempo hat sich etwas Brüchigkeit im Code eingeschlichen. Ich freue mich darauf, wieder „reine“ Programmierarbeit zu leisten und die Codebasis zu härten. Immerhin – wozu schreibt man ein Spiel in Rust, wenn man Code-Brittle zulässt?</p>
Dieser Monat war großartig und bald wird diese Größe richtig solide sein.</p>


Art Lead, ESC und der 3D-Umbau
Unknown — Sun, 25 May 2025 00:00:00 +0000
Überblick</h2>
Die letzten zwei Wochen waren voller Arbeit – größtenteils nicht programmieren. Die gute Nachricht: Sie führte zu großen Veränderungen und insgesamt deutlichen Verbesserungen für das Spiel.</p>
Das Wichtigste zuerst: Exofactory hat jetzt eine Art Lead. Bald sollten also sichtbare Fortschritte bei der Optik zu sehen sein.</p>
Art Lead</h2>
Wie oben erwähnt, ist die große Neuigkeit, dass Exofactory nun eine Art Lead hat. Ursprünglich suchte ich nur nach einer Künstlerin für einzelne Assets. Im Gespräch mit Julija wurde aber klar, dass jemand gebraucht wird, der die künstlerische Gesamtleitung übernimmt.</p>
Mir fehlt schlicht das nötige Skillset, und dem Spiel würde es nicht guttun, wenn ich die Art Direction führen würde.</p>
Wir arbeiten nun seit einiger Zeit zusammen und haben eine klare ästhetische Richtung definiert.</p>
Ich freue mich sehr auf die Zusammenarbeit – es gibt viel zu tun.</p>
Wenn du mehr über Julija erfahren möchtest, schau dir ihr Portfolio an.</a></p>
ESC</h2>
Falls sich der oder die eine Lesende fragt, warum letzte Woche kein Update erschienen ist: Schuld war meine Ablenkung durch den Eurovision Song Contest!</p>
Die Party und das lange Zusammensein haben den Fortschritt dieser Woche vielleicht auch etwas gebremst – aber es war jede Minute wert.</p>
Wir sind jetzt 3D!</h2>
</p>
Die größte Aufgabe der letzten beiden Wochen war der Umstieg auf 3D. Nicht extrem schwer, aber sehr arbeitsintensiv. (Nur zur Klarstellung: Das sind keine finalen Art-Assets, also keine Sorge.)</p>
Teil der Arbeit war ein prozeduraler Terrain-Generator. Egal ob das Spiel später eine unendliche Karte oder eine begrenzte, von Hand abgestimmte Welt hat – automatisch generiertes Terrain reduziert den Aufwand enorm.</p>
</p>
Interessanterweise dauert das Generieren des Terrains gerade lang genug, um einen Ladebildschirm zu rechtfertigen. Den gibt es jetzt also ebenfalls.</p>
</p>
Fazit</h2>
Ich bin sehr zufrieden mit dieser Woche. Viele wichtige Arbeiten haben begonnen, und das Spiel hat nun eine klare künstlerische Richtung.</p>


Kunst und Künstler:innen
Unknown — Sat, 10 May 2025 00:00:00 +0000
Überblick</h2>
Diese Woche stand vor allem nicht programmieren im Mittelpunkt. Ich habe mich auf ein Gebiet konzentriert, in dem ich kaum Erfahrung habe: Künstler:innen finden, sortieren und auswählen. Das war mühsam und ehrlich gesagt nicht besonders spaßig – aber es muss nun einmal erledigt werden.</p>
Kunst und Künstler:innen</h2>
Ich bin Programmiererin, keine Künstlerin, also habe ich ein paar Fehler gemacht. Der größte: Ich habe mich auf 2D-Künstler:innen fokussiert.</p>
Das war unklug, denn wie mir eine der angefragten Personen freundlich erklärte, bräuchte ich für jedes Gebäude und jede Ausrichtung eine komplett neue Animation. Das ist enorm viel Arbeit.</p>
Der Rat lautete stattdessen, eine 3D-Künstlerin oder einen 3D-Künstler zu engagieren und über eine UV-Map</a> Sprite-Sheets zu erzeugen. Nach etwas Recherche stimme ich zu. Der Hinweis war super hilfreich und hat mir die Richtung gezeigt.</p>
Bevor ich diesen Tipp bekam, ist allerdings noch ziemlich cooles Konzeptart entstanden.</p>
</p>
Ein bisschen zu rund für meinen Geschmack, aber trotzdem spannend.</p>
</p>
Dieses hier mag ich besonders.</p>
Leider lässt sich dieses 2D-Konzept nicht sinnvoll weiterverfolgen, aber es hilft, die Stimmung des Spiels zu definieren – also trotzdem wertvoll.</p>
Fazit</h2>
Die Woche war voller neuer Erfahrungen, und ich habe viel gelernt. Jetzt geht es darum, eine passende 3D-Fachkraft zu beauftragen. Bald sollte es mehr zu zeigen geben.</p>


Offsets, Menüs, Barrierefreiheit und 0.16
Unknown — Sat, 03 May 2025 00:00:00 +0000
Überblick</h2>
Letzte Woche hatte ich große Pläne: ein kurzer Mikro-Crunch und anschließend eine technische Vorschau. Wegen persönlicher Umstände konnte ich die nötige Zeit aber nicht investieren. Deshalb hat das Spiel nicht den Stand erreicht, den ich präsentieren wollte. Ich reiche es vermutlich später ein – Nachhaltigkeit geht vor, also musste ich das Ziel für diese Woche fallen lassen.</p>
Trotzdem ist viel passiert, sowohl im Hintergrund als auch für Spieler:innen sichtbar. Und das ist alles sehr motivierend.</p>
Bevy 0.16</h2>
Der erste große Brocken war der Port von Bevy 0.15 auf 0.16</a>. Drei Gründe sprachen dafür:</p>

Ich möchte bald mit Förderbändern beginnen und die neuen ECS Relationships</a> intensiv nutzen, um Quellen und Senken zu verwalten. Ohne sie hätte ich mir am Ende eine eigene Version davon gebaut.</li>
Ich wollte die stabilisierte Input-Focus-Funktion</a> verwenden. Sie ist essenziell für Barrierefreiheit und Gamepad-Support (mehr dazu unten).</li>
Bevy entwickelt sich rasant. Hinterherzuhinken wäre für Exofactory aktuell fatal. Sobald Bevy stabiler wird, ändert sich das vielleicht – bis dahin sind Upgrades Pflicht.</li>
</ol>
Der Port war keine große Hürde, größtenteils ging es um den Abschied von veralteten Funktionen und etwas Refactoring. Ich habe die Gelegenheit genutzt, älteren Code aus meinen ersten Bevy-Tagen aufzuräumen, vor allem durch den Wechsel von Queries</code> zu Single</code>, wo möglich. So konnte ich einige verschachtelte if let Some(x) =</code>-Blöcke entfernen – viel aufgeräumter.</p>
Ein paar Abhängigkeiten waren noch nicht aktualisiert, daher habe ich vorübergehend deren 0.16-PR-Branches oder Release-Candidates eingebunden.</p>
Menüs & Barrierefreiheit</h2>
</p>
Das zweite große Projekt war das neue, ziemlich vollständige Baumenu.</p>
Ich habe damit nach 0.16 gewartet, weil ich unbedingt das neue Accessibility-/Focus-Feature nutzen wollte – hier kam es zum ersten Mal im Spiel zum Einsatz. Barrierefreiheit ist für mich Best Practice. Was Menschen mit Einschränkungen hilft, hilft letztlich allen – auch Entwickler:innen. So wird Gamepad-Unterstützung zur Kleinigkeit. Aus Code-Sicht sind Gamepads und spezialisierte Accessibility-Hardware im Grunde dasselbe.</p>
Fazit</h2>
Ich habe diese Woche nicht ganz die gewünschte Qualität erreicht, bin aber zufrieden mit dem, was entstanden ist. Nachhaltigkeit bleibt mir wichtig – Burn-out gilt es zu vermeiden.</p>


Gebäudemenüs, Gamepads und Kurswechsel
Unknown — Sat, 26 Apr 2025 00:00:00 +0000
Überblick</h2>
Die Woche begann mit völlig anderen Zielen, als sie geendet hat. Der Wendepunkt kam, als Pokinsson</a> einen Aufruf für Indie-Games in jedem Entwicklungsstand startete. Nach kurzem Grübeln beschloss ich, eine Einreichung zu wagen. Bedeutet: Bis zum 7. April muss das vorhandene Material poliert werden, damit eine spielbare technische Vorschau entsteht.</p>
Also habe ich die halbfertige Gamepad-Unterstützung auf Eis gelegt und den Fokus auf dieses Ziel gerichtet. Zurück bleibt ein Haufen Gamepad-Code im Beta-Zustand – das künftige Ich darf sich darum kümmern.</p>
Trotzdem gab es Fortschritte.</p>
Halb gare Gamepad-Unterstützung</h2>
Zu Beginn der Woche, bevor ich von dem Aufruf erfahren habe, war das der Schwerpunkt. Ich nutze Xelus großartige Button-Prompts</a> – absolute Empfehlung.</p>
Ich habe viele Mappings und Controller-Management-Code ergänzt. Dadurch kann ich künftig einfach so etwas tun:</p>
let focus_on_exoframe: Handle<Image> = smart_prompt_collection.focus_on_exoframe.clone();
</code></pre>
Das Ergebnis ist immer das richtige Prompt-Bild – egal ob Steam Deck, Xbox-One-Controller oder Tastatur und Maus.</p>
Weiter kam ich in dieser Woche nicht, dafür steht jetzt eine Liste geplanter Geräte/Steuerungsschemata:</p>

Steam Deck mit integrierten Controllern, Tastatur und Maus oder Xbox-One-Controller</li>
Modernes Linux (Debian 11 und neuer) mit Tastatur und Maus oder Xbox-One-Controller</li>
Windows 10/11 mit Tastatur und Maus oder Xbox-One-Controller</li>
</ul>
Andere Systeme oder Controller sollten funktionieren, werden aber nicht getestet. Mehr Infos zu eventuellen Kompatibilitäten findest du bei gilrs</a>, der zugrunde liegenden Bibliothek im Zusammenspiel mit Bevy.</p>
Steuerungsübersicht</h2>
</p>
Außerdem gibt es jetzt ein Panel als „Steuerungsübersicht“. Es zeigt jederzeit an, welche Aktionen möglich sind, und aktualisiert sich dynamisch während des Spiels. Natürlich lässt es sich ausblenden, falls es stört.</p>
Das ist sowohl für die technische Vorschau als auch fürs fertige Spiel enorm hilfreich.</p>
Gebäude-Interface</h2>
</p>
Zum Schluss kam ein neues Kernfeature hinzu: Ein Gebäude kann nun tatsächlich etwas produzieren!</p>
Fazit</h2>
Insgesamt war es eine stressige Woche, und dieses Arbeitstempo soll keine Normalität werden – gerade mit meinen anderen Verpflichtungen. Aber es ist viel passiert, und der Preview-Build sollte Form annehmen.</p>


UI-Grundlagen gelegt
Unknown — Sat, 19 Apr 2025 00:00:00 +0000
Überblick</h2>
Diese Woche drehte sich vor allem darum, grundlegende UI-Elemente hinzuzufügen, an der Exoframe-Bewegung zu arbeiten und erste Sounds ins Spiel zu bringen.</p>
Aktuell verwende ich extrem einfache Platzhalter-Grafiken, weil der Schwerpunkt weiterhin auf den Kernmechaniken liegt. Rechne also mit ziemlich improvisierter Optik, die eindrucksvoll beweist, dass ich keine Künstlerin bin.</p>
Insgesamt passt die Woche gut zum Zeitplan.</p>
UI weiter ausgestalten</h2>
Exofactory entsteht mit Bevy</a> und so sehr ich das Projekt schätze – die UI-Entwicklung macht schlicht keinen Spaß. Future Bevy</a> soll hier Abhilfe schaffen, und ich hoffe für alle Rust-Game-Devs, dass das klappt. Während Hauptmenü und Einstellungen bereits in einem guten Zustand sind, blieb das UI im eigentlichen Spiel bis diese Woche unangetastet.</p>
Das hat sich nun mit der neuen oberen Leiste geändert. Sie soll der zentrale Anlaufpunkt sein, über den Spielende erkennen, in welchem „Modus“ sie sich befinden und was global passiert.</p>
</p>
Außerdem habe ich das Grundgerüst für Detail- und Einstellungsfenster von Gebäuden gelegt. Damit kann ich künftig schneller iterieren und den UI-Aufwand beim Einführen neuer Gebäude reduzieren. Im Moment zeigt ein Klick auf ein Gebäude lediglich einige Basisinformationen wie oben zu sehen.</p>
Damit bin ich fürs Erste sehr zufrieden.</p>
Sound-Experimente</h2>
Als Abwechslung zur UI-Arbeit habe ich ein paar grundlegende Sounds ergänzt. Nach einigen Aufnahmen und etwas Feinschliff in Tenacity</a> gibt es nun mehrere Sounds, mit denen ich sehr happy bin. Besonders das Mouseover im Menü gefällt mir.</p>

  
  Dein Browser unterstützt das Audio-Element nicht.
</audio>
Einen eigenen Sound-Abschnitt im Einstellungsmenü brauche ich noch, aber das kann warten.</p>
Exoframe in Bewegung</h2>
</p>
Zum Schluss habe ich die Exoframe-Bewegung ergänzt. Sie fühlt sich sehr direkt und zufriedenstellend an. Die Bewegungs- und Physiksysteme stammen vom großartigen Rapier-Framework.</p>
Fazit</h2>
Unterm Strich bin ich mit dieser Woche zufrieden. Ich plane, wöchentlich Dev-Blogs und monatliche Video-Blogs zu veröffentlichen – also bleib dran.</p>

Einen Bug in Bevy rund um KTX2 gefunden</h2>
Beim Umstieg auf KTX2-Dateien ist mir aufgefallen, dass Bevy die `.meta</code>-Dateien für KTX2-Dateien nicht beachtet hat. Eine kleine PR später</a> und es war gefixt. Der Fix wird in Bevy 0.18.1 enthalten sein.</p>`

Multiplayer, Bevy 0.18 und Fosdem

Echtzeit-Einstellungen, Speicher-Überarbeitung & ein Wiki

Ziehbare Fließbänder, Elektrizität & Ansichtsmodi

Fazit</h1>
Es hat sich richtig gut angefühlt, endlich mal wieder ein neues Feature hinzuzufügen nach so vielen Bugfixes. Super happy damit. Jetzt muss ich nur noch das Emotional-Core-/Dialogsystem anpassen, um diese neuen Systeme widerzuspiegeln. Viel Spaß und viel zu tun.</p>

Quality-of-Life-Änderungen, welche sich für ein Fabrikspiel gehören

Fazit</h1>
Viele Quality-of-Life-Verbesserungen basierend auf viel Feedback, und es kommt noch mehr. Ich bin ziemlich zufrieden damit und freue mich auf die nächsten Features.</p>

Steam-Next-Fest-Nachklang

Next-Fest-Ergebnisse</h1>

Demo-Release und Feinschliff

Fazit</h1>
Die Demo ist draußen, und ich freue mich darauf, am vollständigen Spiel weiterzuarbeiten. Ich bin gespannt, was ihr daraus macht.</p>

Demo auf Steam</span> </div> </a> </div>

Private Alpha, Steam & Kernfunktionen

Neue Gebäude & Ressourcen</h2>
Seit dem letzten Dev-Blog kamen einige neue Gebäude hinzu – alle ziemlich spannend.</p>

Ancient AI Core</h3>
</p>
Hier sitzt der Verstand der Spieler-KI. Hier warst du … sehr lange.</p>

Sneak Preview: Gasförderer</h3>
</p>
Hier ein erster Blick auf den Gas-Extraktor. Nicht alles ist schließlich ein Mineral.</p>

Musik</h2>
Ich freue mich riesig über die Zusammenarbeit mit Repto Eternef</a>. Sie erschaffen großartige Musik fürs Spiel und helfen, die Exofactory-Music-Engine aufzubauen, die wir 2026 vor Release als Open Source veröffentlichen wollen.</p>

Animation, Bewegung & Terrain v3

Terrain, Animationen und jede Menge Fortschritt

Art Lead, ESC und der 3D-Umbau

Fazit</h2>
Ich bin sehr zufrieden mit dieser Woche. Viele wichtige Arbeiten haben begonnen, und das Spiel hat nun eine klare künstlerische Richtung.</p>

Kunst und Künstler:innen

Fazit</h2>
Die Woche war voller neuer Erfahrungen, und ich habe viel gelernt. Jetzt geht es darum, eine passende 3D-Fachkraft zu beauftragen. Bald sollte es mehr zu zeigen geben.</p>

Offsets, Menüs, Barrierefreiheit und 0.16

Fazit</h2>
Ich habe diese Woche nicht ganz die gewünschte Qualität erreicht, bin aber zufrieden mit dem, was entstanden ist. Nachhaltigkeit bleibt mir wichtig – Burn-out gilt es zu vermeiden.</p>

Gebäudemenüs, Gamepads und Kurswechsel

Gebäude-Interface</h2>
</p>
Zum Schluss kam ein neues Kernfeature hinzu: Ein Gebäude kann nun tatsächlich etwas produzieren!</p>

Fazit</h2>
Insgesamt war es eine stressige Woche, und dieses Arbeitstempo soll keine Normalität werden – gerade mit meinen anderen Verpflichtungen. Aber es ist viel passiert, und der Preview-Build sollte Form annehmen.</p>

UI-Grundlagen gelegt

Fazit</h2>
Unterm Strich bin ich mit dieser Woche zufrieden. Ich plane, wöchentlich Dev-Blogs und monatliche Video-Blogs zu veröffentlichen – also bleib dran.</p>

Exofactory Entwickler-blog

Gebäudeanimation, Trailer & Pitch-Deck-Kram

Fazit</h1>
Technisch gibt es abseits des coolen Shaders also nicht allzu viel zu sagen, aber im Hintergrund ist gerade eine Menge wichtiger Arbeit angelaufen.</p>

Optimierungen, Pull Requests, Tooling & Finanzen

Exofactory Entwickler-blog

Gebäudeanimation, Trailer & Pitch-Deck-Kram

Fazit</h1> Technisch gibt es abseits des coolen Shaders also nicht allzu viel zu sagen, aber im Hintergrund ist gerade eine Menge wichtiger Arbeit angelaufen.</p>

Optimierungen, Pull Requests, Tooling & Finanzen

Einen Bug in Bevy rund um KTX2 gefunden</h2> Beim Umstieg auf KTX2-Dateien ist mir aufgefallen, dass Bevy die .meta</code>-Dateien für KTX2-Dateien nicht beachtet hat. Eine kleine PR später</a> und es war gefixt. Der Fix wird in Bevy 0.18.1 enthalten sein.</p>

Multiplayer, Bevy 0.18 und Fosdem

Überblick</h1> Diesen Monat ging es im Grunde ausschließlich darum, Multiplayer-Funktionalität einzubauen – mit einer kleinen Pause für die Bevy-0.18-Migration.</p>

Echtzeit-Einstellungen, Speicher-Überarbeitung & ein Wiki

Übersicht</h1> 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.</p>

Ziehbare Fließbänder, Elektrizität & Ansichtsmodi

Fazit</h1> Es hat sich richtig gut angefühlt, endlich mal wieder ein neues Feature hinzuzufügen nach so vielen Bugfixes. Super happy damit. Jetzt muss ich nur noch das Emotional-Core-/Dialogsystem anpassen, um diese neuen Systeme widerzuspiegeln. Viel Spaß und viel zu tun.</p>

Quality-of-Life-Änderungen, welche sich für ein Fabrikspiel gehören

Allgemeine Quality of Life</h1> </video> Wir können jetzt springen!</figcaption> </figure> Da tnua das Implementieren eines Sprungs einfach gemacht hat, habe ich ihn direkt eingebaut. Mit einer leicht umfunktionierten Animation – mehr dazu später – war das schnell erledigt.</p>

Fazit</h1> Viele Quality-of-Life-Verbesserungen basierend auf viel Feedback, und es kommt noch mehr. Ich bin ziemlich zufrieden damit und freue mich auf die nächsten Features.</p>

Steam-Next-Fest-Nachklang

Next-Fest-Ergebnisse</h1>

Demo-Release und Feinschliff

Testpannen</h2> Damit sind wir beim nächsten Punkt. Falls du dich für Alpha/Beta-Tests angemeldet hast: Du wurdest nicht vergessen. Durch</p> die ungeplanten Verzögerungen bei der Steam-Freigabe,</li> die unerwarteten Schwierigkeiten beim Packaging und</li>

Fazit</h1> Die Demo ist draußen, und ich freue mich darauf, am vollständigen Spiel weiterzuarbeiten. Ich bin gespannt, was ihr daraus macht.</p>

Private Alpha, Steam & Kernfunktionen

Neue Gebäude & Ressourcen</h2> Seit dem letzten Dev-Blog kamen einige neue Gebäude hinzu – alle ziemlich spannend.</p>

Ancient AI Core</h3> </p> Hier sitzt der Verstand der Spieler-KI. Hier warst du … sehr lange.</p>

Sneak Preview: Gasförderer</h3> </p> Hier ein erster Blick auf den Gas-Extraktor. Nicht alles ist schließlich ein Mineral.</p>

Animation, Bewegung & Terrain v3

Überblick</h1> Mehrere große Ziele wurden erreicht: Das Spiel ist animiert, wir haben erste Ressourcen und das Terrain-System nähert sich dem Status „fertig“. Es war nicht die produktivste Periode überhaupt, aber der Kurs stimmt.</p>

Terrain, Animationen und jede Menge Fortschritt

Steam-Screenshots</h1> </p> Die Screenshots waren der härteste Brocken. Ursprünglich wollte ich unseren Steam-Auftritt viel</em> früher vorbereiten, aber ich bekam die Bilder nicht auf einen Stand, der dem Spiel gerecht wurde.</p>

Art Lead, ESC und der 3D-Umbau

Fazit</h2> Ich bin sehr zufrieden mit dieser Woche. Viele wichtige Arbeiten haben begonnen, und das Spiel hat nun eine klare künstlerische Richtung.</p>

Kunst und Künstler:innen

Offsets, Menüs, Barrierefreiheit und 0.16

Fazit</h2> Ich habe diese Woche nicht ganz die gewünschte Qualität erreicht, bin aber zufrieden mit dem, was entstanden ist. Nachhaltigkeit bleibt mir wichtig – Burn-out gilt es zu vermeiden.</p>

Gebäudemenüs, Gamepads und Kurswechsel

Gebäude-Interface</h2> </p> Zum Schluss kam ein neues Kernfeature hinzu: Ein Gebäude kann nun tatsächlich etwas produzieren!</p>

Fazit</h2> Insgesamt war es eine stressige Woche, und dieses Arbeitstempo soll keine Normalität werden – gerade mit meinen anderen Verpflichtungen. Aber es ist viel passiert, und der Preview-Build sollte Form annehmen.</p>

UI-Grundlagen gelegt

Fazit</h2> Unterm Strich bin ich mit dieser Woche zufrieden. Ich plane, wöchentlich Dev-Blogs und monatliche Video-Blogs zu veröffentlichen – also bleib dran.</p>

Fazit</h1>
Technisch gibt es abseits des coolen Shaders also nicht allzu viel zu sagen, aber im Hintergrund ist gerade eine Menge wichtiger Arbeit angelaufen.</p>

Einen Bug in Bevy rund um KTX2 gefunden</h2>
Beim Umstieg auf KTX2-Dateien ist mir aufgefallen, dass Bevy die `.meta</code>-Dateien für KTX2-Dateien nicht beachtet hat. Eine kleine PR später</a> und es war gefixt. Der Fix wird in Bevy 0.18.1 enthalten sein.</p>`

Fazit</h1>
Es hat sich richtig gut angefühlt, endlich mal wieder ein neues Feature hinzuzufügen nach so vielen Bugfixes. Super happy damit. Jetzt muss ich nur noch das Emotional-Core-/Dialogsystem anpassen, um diese neuen Systeme widerzuspiegeln. Viel Spaß und viel zu tun.</p>

Fazit</h1>
Viele Quality-of-Life-Verbesserungen basierend auf viel Feedback, und es kommt noch mehr. Ich bin ziemlich zufrieden damit und freue mich auf die nächsten Features.</p>

Fazit</h1>
Die Demo ist draußen, und ich freue mich darauf, am vollständigen Spiel weiterzuarbeiten. Ich bin gespannt, was ihr daraus macht.</p>

Demo auf Steam</span> </div> </a> </div>

Neue Gebäude & Ressourcen</h2>
Seit dem letzten Dev-Blog kamen einige neue Gebäude hinzu – alle ziemlich spannend.</p>

Ancient AI Core</h3>
</p>
Hier sitzt der Verstand der Spieler-KI. Hier warst du … sehr lange.</p>

Sneak Preview: Gasförderer</h3>
</p>
Hier ein erster Blick auf den Gas-Extraktor. Nicht alles ist schließlich ein Mineral.</p>

Fazit</h2>
Ich bin sehr zufrieden mit dieser Woche. Viele wichtige Arbeiten haben begonnen, und das Spiel hat nun eine klare künstlerische Richtung.</p>

Fazit</h2>
Ich habe diese Woche nicht ganz die gewünschte Qualität erreicht, bin aber zufrieden mit dem, was entstanden ist. Nachhaltigkeit bleibt mir wichtig – Burn-out gilt es zu vermeiden.</p>

Gebäude-Interface</h2>
</p>
Zum Schluss kam ein neues Kernfeature hinzu: Ein Gebäude kann nun tatsächlich etwas produzieren!</p>

Fazit</h2>
Insgesamt war es eine stressige Woche, und dieses Arbeitstempo soll keine Normalität werden – gerade mit meinen anderen Verpflichtungen. Aber es ist viel passiert, und der Preview-Build sollte Form annehmen.</p>

Fazit</h2>
Unterm Strich bin ich mit dieser Woche zufrieden. Ich plane, wöchentlich Dev-Blogs und monatliche Video-Blogs zu veröffentlichen – also bleib dran.</p>