Wo wir heute stehen
Pixel.Axiom.Engine hat einen wichtigen Punkt erreicht: PAE ist längst mehr als ein technischer Prototyp, aber noch nicht die fertige Spielefabrik, die wir langfristig bauen wollen. Dazwischen liegt der vielleicht spannendste Abschnitt eines Projekts — jener Moment, in dem aus einer funktionierenden Engine eine belastbare Produktionsgrundlage wird.
Der aktuelle Entwicklungsstand trägt die Versionsnummer PAE 0.113.1. Das erste Referenzspiel Death Pays Overtime liegt als eigenständiger Development-Build vor, sein erster grosser Produktloop ist durchgängig spielbar, und die automatisierte Prüfung umfasst inzwischen 1539 fehlerfrei bestandene Checks.
Das ist noch kein Release. Es ist jedoch ein belastbarer Zwischenstand, auf dem wir weiterbauen können.
Die Kurzfassung
- Death Pays Overtime 0.1.0-dev wird aus seinem eigenen Projektmanifest gebaut.
- Der aktuelle technische Stand ist Pixel.Axiom.Engine 0.113.1.
- Der erste vollständige Kampagnenbogen ist vom Einstieg bis zum Folgelevel-Platzhalter spielbar.
- Linux und Steam Deck bilden den gegenwärtigen Entwicklungs- und Releasepfad.
- Der aktuelle Build besteht 1539 automatisierte Prüfungen ohne Fehler.
- Ein physisches Steam Deck wurde mit demselben Build und identischem Binary-Hash verifiziert.
- Ein zweites Gerät bleibt bewusst auf einem älteren, ebenfalls geprüften Stand und dient damit zusätzlich als Vergleichspunkt.
- Die längere physische Balanceprüfung ist noch offen.
- Windows, Steamworks, Store-Veröffentlichung und ein öffentlicher Release sind vorgesehen, aber noch keine bestandenen Releasegates.
Was Pixel.Axiom.Engine eigentlich ist
PAE soll keine weitere universelle Engine sein, die alles für alle verspricht. Das Ziel ist bewusst konkreter: eine modulare Factory für kompakte, kommerziell veröffentlichbare 2D-Pixel-Art-Spiele.
Ein Spiel entsteht dabei nicht als untrennbarer Block aus Code, Assets und Sonderfällen. Stattdessen verbindet die Factory mehrere klar getrennte Ebenen:
1. einen schlanken, genreunabhängigen Runtime-Core in C11;
2. deterministische Generatoren für Pixel-Art und Content;
3. optionale Gameplay-Module;
4. erprobte Genre-Templates;
5. eigenständige Spielprojekte mit eigenen Daten, Locales, Assets und Marken.
Langfristig soll ein Projektmanifest festlegen, welches Template, welche Module und welche Inhalte zu einem konkreten Spiel gehören. Die Factory validiert diese Angaben, erzeugt benötigte Artefakte, kompiliert das Spiel, führt seine Prüfungen aus und erstellt ein nachvollziehbares Releasepaket.
Der entscheidende Grundsatz lautet: Mechanismus vor Spielregel. Der Core soll Zeit, Zustände, Kollision, Daten, Zufall, Szenenwechsel und andere allgemeine Fähigkeiten bereitstellen. Er soll aber weder Kevin noch Happy Valley, Seelenpunkte oder eine bestimmte Todesmaschine kennen.
Determinismus statt undurchsichtiger Magie
Ein zentrales Merkmal von PAE ist das Zusammenspiel von DNA, Brain, Seeds und versionierten Generatoren.
DNA beschreibt die Eigenschaften einer Figur oder eines Gegenstandes. Brain-Daten beschreiben Verhalten. Generatoren übersetzen diese Angaben zusammen mit einem Stilprofil und einem Seed in reproduzierbare Ergebnisse. Gleiche Eingaben sollen dasselbe Resultat hervorbringen — nicht nur ungefähr, sondern technisch überprüfbar.
Dieses Prinzip reicht weit über Grafik hinaus. Gameplay-Zufall läuft über getrennte, injizierte Zufallsströme. Neue visuelle Varianten dürfen dadurch beispielsweise nicht unbemerkt die Gegnerfolge, Beuteverteilung oder Balance eines Laufs verändern. Die Simulation arbeitet mit einem festen 60-Hz-Zeitschritt und bleibt in ihren entscheidenden Teilen ohne Grafiktreiber testbar.
PAE verwendet dabei keineswegs ausschliesslich automatisch erzeugte Inhalte. Handgeführte und externe Assets sind ausdrücklich möglich. Entscheidend ist, dass ihre Herkunft, ihre Lizenz und ihre Rolle im Projekt nachvollziehbar bleiben.
Death Pays Overtime: das erste echte Produkt
Death Pays Overtime ist nicht bloss eine Technikdemo für die Engine. Es ist das erste eigenständige Spielprodukt, an dem PAE seine Architektur beweisen muss.
Im Mittelpunkt steht Kevin, Reaper #4077: ein überarbeiteter Sensenmann in einer absurden Jenseitsfirma. Sein Management schickt ihn nach Happy Valley und verlangt entweder 3333 verfügbare Seelenpunkte oder 3 Minuten und 33 Sekunden erfolgreich überstandene Arbeitszeit.
Happy Valley ist dabei kein abstrakter Testplatz mehr. Der warme Freizeitpark besitzt eigene Wege, Attraktionen, Parkpersonal, Passanten, Händlerzugang und eine erkennbare räumliche Identität. Die freundlich wirkende Umgebung steht im bewussten Kontrast zu Kevins dunklem Violett, der kalten cyanfarbenen Seelenenergie und dem bürokratischen Druck seines Arbeitgebers.
Ein ungewöhnlich umfangreicher erster Spielbogen
Der gegenwärtige Build beginnt mit sieben lokalisierten Pixel-Comicseiten und einem Corporate-Mail-Auftrag. Danach führt er durch mehrere miteinander verbundene Systeme:
- Kevin arbeitet sich durch Happy Valley und sammelt Seelenpunkte, Crypto und Run-XP.
- Passanten bilden die Hauptziele, während die Protectors of Life immer entschlossener eingreifen.
- Jeder tatsächliche Levelaufstieg erzeugt einen mobilen, spektralen Seelenzeit-Auditauftrag.
- Während Kevin einen Auditknoten synchronisiert, verlangsamt sich die übrige Welt auf 30 Prozent ihrer normalen Geschwindigkeit.
- Ein versäumtes Audit ruft Corporate-Compliance-Auditoren auf den Plan — Angestellte derselben Firma, die ihre Personalführung ausgesprochen wörtlich nehmen.
- Beim Dealer lassen sich Seelenpunkte zu einem wechselnden Kurs gegen Crypto tauschen.
- Aus Rahmen, Auslöser, Mechanik und Nutzlast entstehen prozedural zusammengesetzte Todesmaschinen.
- Gekaufte Maschinen können in einem Möbelhausbetrieb frei montiert und während einer verriegelten Nachtschicht eingesetzt werden.
- Die Schicht wird über CCTV-Feeds beobachtet und endet mit einem schwarzen, bürokratisch kalten Ergebnisprotokoll.
Erreicht Kevin sein Managementziel, öffnet sich der nächste Teil des Kampagnenbogens. Mehr verraten wir an dieser Stelle bewusst nicht: Die tatsächliche Destination der versprochenen Erholungsreise und der spätere Boss gehören zu den Überraschungen des Spiels.
Der Wohnmarkt: ein Spiel im Spiel
Einer der grössten Fortschritte der vergangenen Entwicklungsphase ist der Fallenbetrieb. Was ursprünglich als einfache Test-Lane begann, ist inzwischen ein eigener kleiner Business-Sandbox-Loop.
Der aktuelle Wohnmarkt führt 24 Besucher in deterministischen Gruppen durch verschiedene Abteilungen. Kevin kauft zuvor Maschinen, stellt sie im Laden auf und beobachtet die laufende Schicht über vier CCTV-Feeds. Besucher können in Panik geraten, Fluchtwege wechseln und der tödlichen Planung entkommen. Ein automatisch aufgebautes Maschinenpaket soll nützlich sein, darf aber keinen perfekten Lauf garantieren.
Die Maschinen selbst werden aus 32 gewichteten Projektteilen zusammengesetzt. Ihre Bauteile beeinflussen Aussehen, Preis, Schaden, Abklingzeit und Einsatzart. Ein gekaufter Blueprint bleibt anhand seiner gespeicherten Teile und Generatorversion reproduzierbar — auch dann, wenn der Teilepool später erweitert wird.
1539 Prüfungen — und was diese Zahl wirklich bedeutet
Die aktuelle Testsuite prüft weit mehr als den blossen Programmstart. Sie deckt unter anderem Datenvalidierung, deterministische Zufallsfolgen, Szenenübergänge, Profil- und Walletoperationen, Shopkäufe, Maschineninventar, Fallenplatzierung, Bosszustände, Lokalisierung und zahlreiche visuelle Integrationspfade ab.
Wichtig ist dabei die Trennung der Ebenen:
- Core-Mechanismen werden ohne konkrete Spielinhalte geprüft.
- Gameplay-Systeme laufen soweit möglich headless und ohne raylib.
- Projektgates sichern die Regeln von Death Pays Overtime.
- visuelle Xvfb-Prüfungen kontrollieren definierte Ansichten in 1200 × 800 Pixeln;
- Release- und Dist-Ziele erzeugen ein eigenständiges Binary und ein versioniertes Archiv.
1539 grüne Checks bedeuten nicht, dass das Spiel bereits fertig ausbalanciert ist. Sie bedeuten, dass der geprüfte technische Vertrag reproduzierbar eingehalten wird. Das ist die Grundlage, auf der menschliches Spielen und ehrliches Balancing überhaupt sinnvoll werden.
Auf echter Hardware geprüft
Der aktuelle PAE-0.113.1-Build wurde nicht nur lokal erzeugt. Er wurde atomar auf ein physisches Steam Deck übertragen und dort anhand von Version, Startziel und vollständigem Binary-Hash verifiziert.
Ein zweites Steam Deck trägt bewusst noch PAE 0.112.0. Auch dieser Stand wurde separat geprüft. Diese Differenz ist kein versehentliches Versionschaos, sondern ein klar dokumentierter Gerätestand: Das aktuelle Gerät dient als Hauptziel, während das zweite einen bekannten Vergleichsstand behält.
Die eigene Hardwareprüfung ist allerdings nicht mit Valves offizieller Steam-Deck-Einstufung gleichzusetzen. Eine solche Bewertung erfolgt erst im Rahmen des späteren Steamworks- und Store-Prozesses.
Grafik als System — nicht als beliebige Bildmenge
Auch visuell wächst das Projekt inzwischen über einzelne Sprites hinaus. Death Pays Overtime besitzt eine verbindliche Art Direction mit klaren Silhouetten, kontrollierter Perspektive und einer festen Farblogik:
- Reaper-Stoff bleibt dunkelviolett;
- Seelenenergie leuchtet cyan bis türkis;
- Protectors verwenden helle und warme Uniformfarben;
- Amber markiert Rang, Gefahr und bürokratische Aufmerksamkeit;
- Heilung bleibt grün;
- Happy Valley wirkt warm, lebendig und beinahe einladend.
Jede neue Bildquelle und jede technische Ableitung wird mit Ursprung, Prompt, Tool, Datum, Status und SHA-256 dokumentiert. Das gilt für Runtime-Sprites ebenso wie für kommerzielle Illustrationen. Generierung ersetzt bei uns nicht die Art Direction — sie muss ihr folgen und nachvollziehbar bleiben.
Was bereits geschafft ist
Der heutige Stand beweist mehrere wesentliche Dinge:
- Ein eigenständiges Spiel kann aus einem versionierten PAE-Projektmanifest gebaut werden.
- Death Pays Overtime besitzt einen durchgängigen, lokalisierten Produktloop.
- Der gleiche Simulationsstand bleibt durch Seeds und getrennte Zufallsdomänen reproduzierbar.
- Shop, Profil, Inventar, freie Fallenplatzierung und Betriebssimulation funktionieren als getrennte, testbare Verträge.
- Der Releasepfad für Linux und Steam Deck erzeugt ein prüfbares Paket.
- Umfangreiche Runtime-Grafik, Audio und Marketingquellen besitzen dokumentierte Provenienz.
Was ausdrücklich noch offen ist
PAE ist noch nicht am langfristigen Factory-Ziel angekommen. Insbesondere stehen noch aus:
- die vollständige Extraktion des ersten `arena_survivor`-Templates;
- eine Factory-CLI für den gesamten Validate–Generate–Build–Test–Package-Ablauf;
- ein zweiter Titel, der die Wiederverwendbarkeit ohne Core-Sonderfall beweist;
- ein zweites Genre-Template;
- der vollständige Windows-Releasepfad;
- Steamworks, Achievements, Cloud-Saves und Store-Publishing;
- die abschliessende kommerzielle Artwork- und Store-Produktion;
- eine längere physische Balanceprüfung des aktuellen Builds.
Gerade der letzte Punkt ist wichtig. Automatische Tests können belegen, dass Regeln korrekt funktionieren. Sie können jedoch nicht entscheiden, ob sich der Druck über einen vollständigen Lauf hinweg gut anfühlt, ob ein Audit im falschen Moment frustriert oder ob eine Todesmaschine zwar rechnerisch fair, aber praktisch zu dominant ist.
Die nächsten Schritte
Kurzfristig konzentriert sich die Arbeit auf drei Bereiche:
1. Physische Balanceprüfung: PAE 0.113.1 wird über längere Läufe auf echter Hardware gespielt und hinsichtlich Happy Valley, Compliance, Wohnmarkt und später Kampagnenabschnitte bewertet.
2. Kommerzielles Bildsystem: Website-, Presse- und später Steam-Artwork werden zu einer zusammenhängenden visuellen Kampagne ausgebaut.
3. Factory-Meilenstein F1: Die Projektgrenze wird weiter vervollständigt, bis Death Pays Overtime vollständig aus seinem Manifest und der vorgesehenen Template-Struktur gebaut wird.
Danach folgen die weitere Heat-Gegenreaktion, die Härtung der Factory-Pipeline und schliesslich der Nachweis, dass PAE mehr als ein einziges Spiel tragen kann.
Kein fertiges Versprechen — aber ein funktionierendes Fundament
Der vielleicht wichtigste Fortschritt ist nicht eine einzelne Figur, Maschine oder Bildschirmansicht. Es ist die Tatsache, dass die vielen Teile inzwischen einen zusammenhängenden Produktionsweg bilden.
Death Pays Overtime ist spielbar genug, um echte Produktfragen zu stellen. Pixel.Axiom.Engine ist stabil genug, um diese Fragen reproduzierbar zu bearbeiten. Und die noch offenen Punkte sind konkret genug, um nicht hinter einer vagen Vision zu verschwinden.
Genau dort wollen wir sein: noch mitten in der Entwicklung, aber längst nicht mehr am Anfang.
Feedback und Fragen sind über die Support-Seite willkommen.
