Eine modulare Factory für reproduzierbare Pixel-Art-Spiele.
Was ist Pixel.Axiom.Engine?
Pixel.Axiom.Engine (PAE) wird als modulare Factory für kommerziell veröffentlichbare 2D-Pixel-Art-Spiele entwickelt. Sie verbindet einen schnellen C11-/raylib-Runtime-Core mit datengetriebenen Spielinhalten, deterministischen Generatoren, wiederverwendbaren Gameplay-Modulen und geprüften Genre-Templates.
PAE ist damit mehr als eine Grafik- oder Spiele-Engine. Das langfristige Ziel ist eine durchgängige Produktionsumgebung, die ein Spiel validieren, Inhalte erzeugen, den Programmcode bauen, automatisiert testen und als nachvollziehbares Release-Paket ausgeben kann.
Death Pays Overtime ist das erste eigenständige Spiel, das mit PAE entsteht. Es dient gleichzeitig als reales Produkt und als Belastungstest für die wiederverwendbaren Teile der Engine. Das Spiel behält seine eigene Identität; PAE erscheint lediglich als Herkunftshinweis: Powered by Pixel.Axiom.Engine.
Spiele, die aus Regeln wachsen
Im Kern arbeitet PAE datengetrieben. Spielfiguren, Objekte, Verhalten, Balancing und visuelle Varianten werden nicht als Sonderfälle fest in den Engine-Core eingebaut, sondern über Projekt- und Moduldaten beschrieben.
Ein Teil dieser Daten funktioniert wie eine digitale «DNA»: Sie enthält kompakte Eigenschaften, aus denen versionierte Generatoren reproduzierbare Inhalte ableiten können. Das «Brain» interpretiert die zugehörigen Regeln und steuert Verhalten und Zustandswechsel.
Dadurch können ähnliche DNA-Profile eine erkennbare visuelle oder funktionale Verwandtschaft besitzen, während Änderungen an den Daten neue Varianten erzeugen – ohne für jede Figur oder jedes Objekt einen neuen Sonderfall in den Runtime-Core einzubauen.
Warum Determinismus wichtig ist
PAE verwendet kontrollierte Seeds, feste Simulationsschritte und klar getrennte Zufallsdomänen. Gleiche Eingabedaten, dieselbe Generatorversion und derselbe Seed sollen deshalb wieder zum gleichen Ergebnis führen.
Das ist keine blosse technische Spielerei. Determinismus macht es möglich,
- Fehler zuverlässig zu reproduzieren;
- automatisierte Gameplay- und Contenttests auszuführen;
- Spielstände und Bestenlisten fair zu vergleichen;
- generierte Inhalte später nachvollziehbar neu zu erstellen;
- Änderungen an Regeln und Balancing gezielt zu überprüfen.
Ein reproduzierbares Spiel lässt sich besser testen, pflegen und veröffentlichen.
Eine Factory statt eines einzelnen Spiels
PAE soll mehrere klar getrennte Ebenen miteinander verbinden:
- einen genreunabhängigen Runtime-Core;
- optionale Gameplay- und Plattformmodule;
- wiederverwendbare Genre-Templates;
- eigenständige Spielprojekte mit eigener Marke und eigenen Inhalten;
- deterministische Content- und Pixel-Art-Generatoren;
- eine reproduzierbare Validate-, Build-, Test- und Packaging-Pipeline.
Konkrete Spielregeln gehören dabei zum jeweiligen Projekt oder Template – nicht in den allgemeinen Engine-Core. Ob diese Trennung wirklich funktioniert, beweist nicht eine Architekturzeichnung, sondern erst ein zweites Spiel, das ohne projektspezifischen Core-Sonderfall gebaut werden kann.
Wie PAE mit generativer KI umgeht
PAE lehnt KI-Werkzeuge nicht grundsätzlich ab. Entscheidend ist, wofür sie eingesetzt werden.
Runtime-Inhalte sollen über kontrollierte, versionierte und reproduzierbare Algorithmen entstehen. Das ist klassische prozedurale Generierung: Regeln, Daten und Seeds bestimmen das Ergebnis.
Marketingmaterial wie Website-Illustrationen, Key-Art oder Store-Grafiken kann dagegen KI-unterstützt entstehen. Solche Assets werden getrennt behandelt und mit Quelle, Prompt, Werkzeug, Datum, Bearbeitungsstatus und SHA-256 dokumentiert. Wo Plattformen eine Offenlegung verlangen, muss diese vor der Veröffentlichung geprüft und vorgenommen werden.
So bleiben technische Reproduzierbarkeit, kreative Produktion und kommerzielle Transparenz sauber voneinander getrennt.
Aktueller Entwicklungsstand
PAE wird schrittweise aus dem ersten Referenzprodukt herausgelöst und als wiederverwendbare Factory aufgebaut. Der aktuelle technische Schwerpunkt liegt auf Linux und Steam Deck; Windows ist als späteres Ziel vorgesehen.
Neue Abstraktionen werden nicht auf Vorrat erfunden. Sie entstehen dort, wo ein konkretes Spiel sie tatsächlich benötigt, und werden durch automatisierte Tests sowie reale Produktnutzung abgesichert.
