Pixel.Axiom.Engine

A modular factory for reproducible pixel-art games.

What is Pixel.Axiom.Engine?

Pixel.Axiom.Engine (PAE) is being developed as a modular factory for commercially releasable 2D pixel-art games. It brings together a high-performance C11/raylib runtime core, data-driven game content, deterministic generators, reusable gameplay modules and thoroughly tested genre templates.

PAE is therefore more than a graphics engine or a conventional game engine. Its long-term purpose is to provide an integrated production environment capable of validating a game, generating its content, compiling its code, running automated tests and packaging the result as a traceable release.

Death Pays Overtime is the first standalone game being created with PAE. It serves both as a genuine commercial product and as a demanding proving ground for the engine’s reusable foundations. The game retains an identity entirely of its own; PAE appears only as a discreet mark of provenance: Powered by Pixel.Axiom.Engine.

PAE Logo

Games that grow from rules

At its heart, PAE is data-driven. Characters, objects, behaviours, balancing and visual variations are not embedded within the engine core as one-off exceptions. Instead, they are described through project and module data.

Some of this data behaves like a form of digital “DNA”: a compact collection of properties from which versioned generators can derive reproducible content. The associated “Brain” interprets those rules and governs behaviour and changes of state.

Similar DNA profiles can therefore produce a recognisable visual or functional kinship, whilst changes to the underlying data create new variations — without requiring a bespoke runtime exception for every character or object.

Why determinism matters

PAE uses controlled seeds, fixed simulation steps and clearly separated random-number domains. Given the same input data, generator version and seed, the same process should produce the same result.

This is far more than a technical curiosity. Determinism makes it possible to:

  • reproduce defects reliably;
  • run automated gameplay and content tests;
  • compare game states and leaderboard results fairly;
  • regenerate procedural content in a traceable manner;
  • assess changes to rules and balancing with precision.

A reproducible game is considerably easier to test, maintain and release with confidence.

A factory, not a single game

PAE is intended to unite several clearly separated layers:

  • a genre-independent runtime core;
  • optional gameplay and platform modules;
  • reusable genre templates;
  • standalone game projects with their own identities and content;
  • deterministic content and pixel-art generators;
  • a reproducible validation, build, test and packaging pipeline.

Specific game rules belong within the relevant project or template — never within the general-purpose engine core. The true test of that separation is not an architectural diagram, but a second game built without requiring project-specific exceptions in the core.

How PAE approaches generative AI

PAE does not reject AI tools as a matter of principle. What matters is where and how they are used.

Runtime content is intended to be produced through controlled, versioned and reproducible algorithms. This is procedural generation in the traditional sense: rules, data and seeds determine the outcome.

Marketing material, such as website illustrations, key art or store graphics, may be created with AI assistance. These assets are treated separately and documented with their source, prompt, tool, date, production status and SHA-256 checksum. Where a platform requires disclosure, those requirements must be reviewed and satisfied before publication.

This keeps technical reproducibility, creative production and commercial transparency properly distinct.

Current development status

PAE is being extracted methodically from its first reference product and developed into a reusable game factory. The present technical focus is Linux and Steam Deck, with Windows planned as a subsequent target.

New abstractions are not invented speculatively. They are introduced when a real game has a demonstrable need for them, then verified through automated testing and practical use within an actual product.