DEV Community: Zlormack

ZlormaEngine: Building an Adaptive Game Engine with AI Directors

Zlormack — Wed, 12 Aug 2026 15:30:31 +0000

What if a game engine didn't simply execute a game?

What if it could observe how you play, analyze your run, and coordinate multiple systems to decide what should happen next?

That's the idea behind ZlormaEngine, an experimental game engine I'm building for Linux and Windows.

It started with something much smaller: a prototype called GameFall Arena.

A player. An arena. Geometric enemies. Projectiles. Waves.

Nothing revolutionary.

But while developing the prototype, I started asking a different question:

Instead of scripting every encounter in advance, could the engine dynamically direct the experience around the player?

That question changed the entire project.

It led to the central architecture of ZlormaEngine:

The Director System

A Director is a specialized subsystem responsible for observing, analyzing or controlling one aspect of a run.

The basic loop is:

PLAYER
  ↓
OBSERVE
  ↓
ANALYZE
  ↓
DIRECTORS
  ↓
DECIDE
  ↓
GAMEPLAY
  ↓
PLAYER REACTS
  ↺

But there's an important difference between ZlormaEngine's current direction and simply having several independent systems.

The Directors are designed to communicate with each other.

A Level Director shouldn't generate an arena without considering enemies.

An Enemy Director shouldn't choose a strategy without understanding the arena.

A difficulty system shouldn't increase numbers blindly without understanding the player's performance.

The goal is to create a network of Directors that collectively shape the run.

Level Director: Procedural Arenas with Meaning

The Level Director controls arena generation.

Instead of thinking only about random obstacle placement, it describes each generated arena using what I call Arena DNA.

For example:

SPACE       0.64
COVER       0.42
LANES       0.78
PRESSURE    0.57
ASYMMETRY   0.31
STYLE       ASCENDANT

These values describe the gameplay properties of the arena.

And that's where Arena DNA becomes particularly useful.

It isn't only metadata.

It becomes a language that other Directors can understand.

If an arena has a high LANES value, the AI Enemy Director knows that corridor-based strategies may work.

If COVER is high, another Director can favor enemies or behaviors capable of forcing the player out of defensive positions.

Procedural generation therefore becomes more than:

generate_random_level()

It becomes:

generate_level()
      ↓
understand_level()
      ↓
share_level_properties()
      ↓
adapt_other_systems()

AI Enemy Director

The AI Enemy Director studies how the current run is being played.

It can use information such as:

accuracy;
movement;
damage received;
firing frequency;
combat distance;
combos;
positioning.

The goal isn't:

Player is good → enemies get +200% HP.

That's technically adaptive difficulty, but it isn't particularly interesting.

Instead, I want the engine to ask:

What kind of problem would challenge this player's current strategy?

The demo uses deliberately limited behaviors such as:

CHASE
INTERCEPT
FLANK
PRESSURE_LIGHT

If the player constantly keeps their distance, enemies may gradually become better at interception.

If they remain in predictable areas, another strategy may become more common.

The important rule is that adaptation should remain understandable and fair.

The player should feel challenged, not cheated.

Enemy Shape Director

GameFall Arena originally used simple geometric enemies because it was a prototype.

Instead of hiding that limitation, I decided to turn it into gameplay.

The Enemy Shape Director gives shapes actual meaning.

○ Circle    → Standard
□ Square    → Tank
△ Triangle  → Fast / Aggressive
◇ Diamond   → Tactical / Ranged

This creates immediate visual readability.

A player seeing a triangle doesn't need to inspect a stat panel to understand:

That thing is probably going to rush me.

The full version of ZlormaEngine is planned to expand this system with:

Hexagons
Stars
Elites
Hybrid shapes
Mutations
Different sizes
Rare procedural forms

And because Enemy Shape Director communicates with Level Director and AI Enemy Director, enemy composition can be influenced by the arena itself.

Directors Become More Interesting Together

Imagine this run:

PLAYER
│
├─ fights mostly at long range
├─ has high accuracy
└─ uses predictable movement
        ↓
COMBAT ANALYSIS
        ↓
AI ENEMY DIRECTOR
        ↕
LEVEL DIRECTOR
        ↕
ARENA DNA
        ↕
ENEMY SHAPE DIRECTOR
        ↓
New encounter

The Level Director generates an arena containing several lanes.

Arena DNA exposes that information.

The AI Director knows the player prefers long-range combat.

Enemy Shape Director introduces enemies suited to interception and pressure.

The result isn't necessarily a harder level because enemies have larger health bars.

It becomes harder because:

the situation itself changed.

That distinction is extremely important to what I want ZlormaEngine to become.

Gem Forge: Let the Player Adapt Too

An adaptive engine shouldn't be the only side capable of evolving.

The player needs tools to respond.

That's why GameFall Arena includes Gem Forge.

Enemies can reward gems, which can be spent on upgrades such as damage, movement, projectiles, protection and recovery.

This creates another feedback loop:

COMBAT
   ↓
GEMS
   ↓
GEM FORGE
   ↓
PLAYER BUILD
   ↓
NEW PLAYSTYLE
   ↓
DIRECTORS OBSERVE
   ↓
NEW CHALLENGES

The engine adapts to the player.

The player adapts back.

That's where runs can start becoming genuinely different.

Turning a Bug into a Feature: Projectile Ricochets

One of my favorite parts of development came from a bug.

Projectiles could travel through walls.

The obvious solution was simply to fix collision detection.

But I liked another possibility:

What if hitting a wall caused the projectile to ricochet instead?

The bug became a mechanic.

And the mechanic eventually contributed to another Director.

Malus Director

The Malus Director can introduce temporary constraints based on what's happening during the run.

The demo version is intentionally limited.

The full version could eventually react to things such as excessive ricochets, extremely dominant builds, repetitive strategies or specific combinations of player behavior and Arena DNA.

But there's an important design principle:

A Malus should create an interesting problem, not randomly punish the player.

If a Director changes the rules, the player should have a meaningful way to respond.

Phoenix Director: The Engine Can Help You Too

Not every Director exists to make the game harder.

The Phoenix Director watches for critical moments.

Under specific conditions, it can offer a last chance through recovery, temporary upgrades or another special event.

Imagine surviving a brutal encounter with almost no health left.

The run appears finished.

Then Phoenix activates.

Suddenly, the player has one final opportunity to recover.

That's not just difficulty management.

It's dynamic storytelling through gameplay systems.

Pulse Director: Difficulty Needs Rhythm

Constantly increasing difficulty becomes exhausting.

So another Director manages something less obvious:

rhythm.

Instead of:

HARD
HARDER
HARDER
HARDER
IMPOSSIBLE

the run can breathe:

CALM
  ↓
PRESSURE
  ↓
PEAK
  ↓
RECOVERY
  ↓
PRESSURE
  ↓
MAJOR PEAK

This is the role of the Pulse Director.

It helps transform twenty waves into an experience with pacing rather than twenty increasingly large enemy groups.

ZlormaStyle Director: Giving the Engine an Identity

Early GameFall Arena builds looked exactly like what they were:

a prototype.

Flat backgrounds, basic shapes and functional UI.

The next step became creating a visual identity.

The ZlormaStyle Director is designed around futuristic arenas, metallic structures, luminous circuits, energy surfaces and a cyan / violet / magenta visual language.

Different arena identities can include concepts such as:

REACTOR DECK
CIRCUIT VAULT
VOID GRID
NEON FOUNDRY

But the interesting part is making the visual style react to gameplay.

A run may transition through states such as:

FLOW
PULSE
FRACTURE
ASCENDANT

The arena can therefore visually communicate what the engine is doing.

Wave Music Director

Sound follows the same philosophy.

Instead of looping one background track for an entire run, the Wave Music Director can change the musical atmosphere as the run evolves.

For example:

AWAKENING
MOTION
PRESSURE
PULSE
FRACTURE
HUNTER
ASCENDANT
OVERDRIVE
APEX GATE
ZLORMA FINALE

Gameplay, visual effects and music can therefore work together.

And this leads to another goal:

GameFall Arena should be interesting to watch, not only to play.

That matters for trailers, gameplay videos and streaming.

Run Scars: Giving a Run Memory

Another experimental ZlormaEngine concept is Run Scars.

Important events can leave information behind.

For example:

Phoenix activated
Major damage event
Unusual combat strategy
Special arena event
Director intervention

Other Directors can potentially use those scars later.

The run therefore develops something resembling a short-term memory.

ZLORMA SEED and the Run Signature

Each run can also receive a ZLORMA SEED.

But I want the concept to eventually represent more than procedural generation.

A complete run signature could combine:

ZLORMA SEED
+
ARENA DNA
+
PLAYER BUILD
+
COMBAT STYLE
+
DIRECTOR DECISIONS
+
RUN SCARS
+
SPECIAL EVENTS

The goal is simple:

Every run should have an identity.

The Player's Double

This idea eventually led to one of the strangest systems planned for ZlormaEngine.

Under special conditions, the engine can generate a Double based on the player's run.

Not merely a visual clone.

The enemy is intended to represent an enhanced interpretation of how the player has been playing.

The challenge becomes:

Can you defeat a stronger version of your own playstyle?

Zlorma: When the Engine Becomes the Opponent

And then there is Zlorma.

Zlorma is intended as an exceptional enemy for highly skilled players.

If the Directors determine that someone is consistently dominating the normal systems, Zlorma can become the ultimate challenge.

Conceptually, it's the engine saying:

You've learned my rules. Now fight me.

This system is primarily intended for the complete version.

Demo vs Full Version

The current Zlorma Signature Demo is designed around approximately 20 waves.

That's intentional.

Ten waves proved too short to properly demonstrate adaptation and progression.

But the demo still doesn't expose everything.

System	Demo	Full
Level Director	Limited	Advanced
Arena DNA	✓	✓
Combat Analysis	✓	Advanced
AI Enemy Director	Capped adaptation	Continuous adaptation
Enemy Shapes	Main families	Hybrids + mutations
Gem Forge	Limited	Expanded
Malus Director	Limited	Contextual
Phoenix	✓	Advanced
ZlormaStyle	Selected styles	Full system
Wave Music	✓	Dynamic
Run Scars	Basic	Advanced
Player Double	Teaser / limited	Full
Zlorma	Rare / teaser	Advanced challenge
Generation	~20 waves	Extended / potentially endless

The demo's purpose isn't to expose every feature.

It's to demonstrate the central idea:

The game reacts to your run.

What Makes ZlormaEngine Different?

ZlormaEngine isn't defined by geometric enemies.

It isn't defined by Python.

And it isn't defined by procedural generation alone.

The core idea is the Director Network.

                    PLAYER
                      │
                RUN ANALYSIS
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
     COMBAT          LEVEL         PULSE
    DIRECTOR        DIRECTOR      DIRECTOR
        │             │
        │         ARENA DNA
        │             │
        ▼             ▼
    AI ENEMY ◄────► ENEMY SHAPE
        │             │
        └──────┬──────┘
               ▼
             MALUS
               │
       ┌───────┴────────┐
       ▼                ▼
 ZLORMASTYLE          MUSIC
       │                │
       └───────┬────────┘
               ▼
            GAMEPLAY
               │
               ▼
             PLAYER
               │
               └──────────► NEXT ANALYSIS

Every Director has a specific responsibility.

But their ability to exchange information is where things become interesting.

From Prototype to Adaptive Game Engine

ZlormaEngine started with:

Can I build my own game engine?

Then:

Can it generate arenas and waves?

Then:

Can it react to the player?

And now:

Can multiple Directors collaborate to dynamically direct an entire run?

That's the question I'm exploring today.

My goal isn't to compete feature-for-feature with massive general-purpose engines.

ZlormaEngine is an experiment around a more specific idea:

A game engine that doesn't just run the game — it directs the run.

GameFall Arena is the first playground for that idea.

And this is only the beginning.

🇫🇷 ZlormaEngine : construire un moteur de jeu adaptatif avec des Directors IA

Et si un moteur de jeu ne se contentait plus d'exécuter le jeu ?

Et s'il pouvait observer votre manière de jouer, analyser votre run et coordonner plusieurs systèmes afin de décider de ce qui devrait arriver ensuite ?

C'est l'idée derrière ZlormaEngine, le moteur de jeu expérimental que je développe pour Linux et Windows.

Tout a commencé beaucoup plus simplement avec GameFall Arena.

Un joueur.

Une arène.

Des ennemis géométriques.

Des projectiles.

Des vagues.

Puis une question a changé la direction du projet :

Au lieu de programmer chaque rencontre à l'avance, est-ce que le moteur pourrait diriger dynamiquement l'expérience autour du joueur ?

C'est ainsi qu'est née l'architecture des Directors de ZlormaEngine.

Qu'est-ce qu'un Director ?

Un Director est un système spécialisé chargé d'observer, d'analyser ou de contrôler une partie particulière de la run.

JOUEUR
  ↓
OBSERVATION
  ↓
ANALYSE
  ↓
DIRECTORS
  ↓
DÉCISION
  ↓
GAMEPLAY
  ↓
RÉACTION DU JOUEUR
  ↺

La particularité de ZlormaEngine est que ces Directors sont destinés à communiquer entre eux.

Le Level Director peut comprendre l'organisation d'une arène.

L'AI Enemy Director peut analyser le comportement du joueur.

Enemy Shape Director peut sélectionner les familles d'adversaires.

Pulse Director peut contrôler le rythme.

ZlormaStyle et Wave Music Director peuvent accompagner visuellement et musicalement cette évolution.

Le moteur devient progressivement un réseau de systèmes coopératifs.

Level Director et Arena DNA

Le Level Director s'occupe de la génération des arènes.

Mais générer aléatoirement des obstacles ne suffisait pas.

J'ai donc commencé à développer Arena DNA.

SPACE       0.64
COVER       0.42
LANES       0.78
PRESSURE    0.57
ASYMMETRY   0.31
STYLE       ASCENDANT

Arena DNA décrit les propriétés d'une arène.

Les autres Directors peuvent ensuite les utiliser.

Une valeur LANES importante peut favoriser certaines stratégies ennemies.

Une forte quantité de COVER peut influencer le choix des adversaires.

Arena DNA devient donc un langage commun entre les Directors.

AI Enemy Director : analyser la manière de jouer

L'AI Enemy Director peut observer la précision, les déplacements, les dégâts reçus, les combos, la cadence de tir, la distance de combat et le positionnement.

Mais son objectif n'est pas simplement :

Bon joueur = ennemis avec beaucoup plus de vie.

Je veux plutôt qu'il se demande :

Quel problème pourrait remettre en question la stratégie actuelle de ce joueur ?

Dans la démo, plusieurs comportements restent volontairement limités :

CHASE
INTERCEPT
FLANK
PRESSURE_LIGHT

La version complète pourra aller beaucoup plus loin.

L'objectif reste cependant le même :

adapter le défi sans donner l'impression que le moteur triche.

Enemy Shape Director : quand la géométrie devient du gameplay

Les formes simples de GameFall Arena étaient initialement celles d'un prototype.

Elles sont progressivement devenues une mécanique.

○ Cercle   → Standard
□ Carré    → Tank
△ Triangle → Rapide / agressif
◇ Losange  → Tactique / distance

La silhouette permet immédiatement au joueur d'identifier le danger.

À terme, hexagones, étoiles, élites, hybrides, mutations et formes procédurales rares pourront enrichir le système.

Et Enemy Shape Director peut communiquer avec Level Director et AI Enemy Director.

Ainsi, l'arène et ses ennemis peuvent être conçus ensemble autour de la run actuelle.

Gem Forge : le joueur doit pouvoir répondre

Le moteur s'adapte.

Le joueur doit pouvoir faire la même chose.

Les combats permettent donc d'obtenir des gemmes utilisées dans la Gem Forge.

COMBAT
 ↓
GEMMES
 ↓
GEM FORGE
 ↓
BUILD
 ↓
NOUVELLE STRATÉGIE
 ↓
ANALYSE DES DIRECTORS

Chaque amélioration peut modifier la manière de jouer.

Le moteur doit ensuite comprendre cette évolution.

Transformer un bug en mécanique

À un moment du développement, les projectiles traversaient les murs.

Il fallait évidemment corriger le problème.

Mais plutôt que de simplement supprimer ce comportement, une idée est apparue :

faire ricocher les projectiles.

Cette correction est ainsi devenue une mécanique.

Elle a également participé à la réflexion autour du Malus Director.

Malus Director

Le Malus Director peut introduire certaines contraintes en fonction de la run.

L'idée n'est pas de punir arbitrairement.

Un malus doit créer une décision supplémentaire.

Dans la version complète, ce Director pourra devenir beaucoup plus contextuel et communiquer avec Arena DNA, Combat Director et les autres systèmes.

Phoenix Director : une dernière chance

Tous les Directors ne sont pas contre le joueur.

Le Phoenix Director peut détecter certaines situations critiques et offrir une dernière chance.

Une run pratiquement perdue peut alors devenir un moment mémorable.

ZlormaEngine commence ici à se comporter moins comme un simple générateur et davantage comme un metteur en scène du gameplay.

Pulse Director : créer un rythme

Une difficulté constamment ascendante devient rapidement fatigante.

Pulse Director permet plutôt :

CALME
 ↓
PRESSION
 ↓
PIC
 ↓
RÉCUPÉRATION
 ↓
PRESSION
 ↓
PIC MAJEUR

Les 20 vagues de la démo peuvent ainsi former une progression plutôt qu'une simple succession d'ennemis toujours plus nombreux.

ZlormaStyle et Wave Music Director

L'identité graphique de ZlormaEngine repose progressivement sur des environnements technologiques sombres, structures métalliques, circuits lumineux et énergies cyan, violet et magenta.

ZlormaStyle peut utiliser différents états :

FLOW
PULSE
FRACTURE
ASCENDANT

Le Wave Music Director applique une philosophie similaire au son.

La musique peut changer avec la progression de la run et renforcer les événements importants.

Le but est que GameFall Arena soit intéressant à jouer et à regarder.

Run Scars et ZLORMA SEED

Certains événements peuvent devenir des Run Scars.

Phoenix, événement majeur, stratégie inhabituelle ou intervention spéciale peuvent laisser une trace exploitable plus tard.

Chaque partie possède également une ZLORMA SEED.

À terme, une signature de run pourrait combiner :

ZLORMA SEED
+
ARENA DNA
+
BUILD
+
STYLE DE COMBAT
+
DÉCISIONS DES DIRECTORS
+
RUN SCARS
+
ÉVÉNEMENTS

Chaque run pourrait ainsi posséder sa propre identité.

Le Double et Zlorma

Parmi les systèmes les plus expérimentaux se trouve le Double du joueur.

Le moteur pourrait utiliser les informations accumulées pendant la run pour générer un adversaire inspiré du style du joueur, mais volontairement plus puissant.

Le défi devient :

Pouvez-vous battre une version améliorée de votre propre manière de jouer ?

Puis vient Zlorma.

Zlorma représente un adversaire exceptionnel destiné aux joueurs capables de dominer les systèmes classiques.

Le moteur semble alors dire :

« Tu connais mes règles. Maintenant, affronte-moi. »

Une démo volontairement limitée

La Zlorma Signature Demo vise environ 20 vagues.

C'est suffisamment long pour commencer à percevoir les interactions entre Directors, tout en gardant certains systèmes volontairement bridés.

La version complète pourra libérer l'adaptation de l'IA, davantage de formes, les mutations, des interactions plus profondes entre Directors, le Double, Zlorma et une génération beaucoup plus étendue.

La démo doit avant tout faire comprendre une chose :

Votre manière de jouer influence la run.

Ce qui définit vraiment ZlormaEngine

Ce ne sont ni Python, ni les formes géométriques, ni les vagues qui définissent réellement le moteur.

C'est son Director Network.

Plus les Directors apprennent à communiquer, plus le moteur peut construire des situations cohérentes autour de la partie en cours.

ZlormaEngine est parti d'une question :

Puis-je créer mon propre moteur de jeu ?

Elle est devenue :

Puis-je créer un moteur qui réagit au joueur ?

Aujourd'hui, la question est devenue :

Plusieurs Directors peuvent-ils collaborer pour diriger dynamiquement une run entière ?

C'est désormais le cœur du projet.

ZlormaEngine ne cherche pas seulement à exécuter le jeu. Il cherche à diriger la run.

GameFall Arena n'est que le commencement.

Publishing My Procedural Rust Game on Game Jolt

Zlormack — Sat, 18 Jul 2026 15:45:25 +0000

I brought Zlorma Core: Signal Lost to Game Jolt, published a new gameplay trailer and applied for Creator access for ZlormaStudio.

title: "Bringing Zlorma Core: Signal Lost to Game Jolt"
published: false
description: "I published the new Signal Lost gameplay trailer on Game Jolt and applied for Creator access for ZlormaStudio."

tags: gamedev, rust, indiegame, devlog

Bringing Zlorma Core: Signal Lost to Game Jolt

Today marks another step forward for Zlorma Core: Signal Lost and ZlormaStudio.

After publishing the prototype on itch.io and sharing its development through this blog, I have now started bringing the project to Game Jolt.

I uploaded the new gameplay trailer, prepared the game presentation and submitted an application for Game Jolt Creator access.

The application is currently waiting for review.

What is Signal Lost?

Zlorma Core: Signal Lost is a procedural science-fiction top-down shooter developed in Rust with my custom lightweight 2D game engine, ZlormaEngine.

The player wakes up inside a damaged digital station being consumed by corruption.

The main objectives are to:

explore procedurally generated rooms and corridors;
repair three damaged terminals;
collect data fragments;
fight corrupted programs;
build barriers and automated turrets;
use the Zlorma Data Forge;
escape before the system collapses.

The current release is Prototype v0.2.1 — Demo Polish Update.

A More Polished Gameplay Trailer

For this release, I created several versions of the gameplay trailer.

The main trailer includes:

an animated introduction;
faster gameplay cuts;
cinematic titles;
visual impact flashes;
dynamic zoom and camera movement;
a custom synthwave and chiptune soundtrack;
a final screen linking to the playable prototype.

I also created shorter versions for social networks such as Mastodon, Bluesky, Discord, Facebook and Game Jolt.

Preparing several trailer formats helped me understand how differently a game needs to be presented depending on the platform.

A full trailer can explain the mechanics, while a shorter version must immediately show action, visual effects and the main gameplay loop.

The Zlorma Data Forge

One of the most important additions in Signal Lost v0.2 is the Zlorma Data Forge.

After repairing a terminal, the player receives three randomly selected upgrades.

Each upgrade provides an advantage, but most of them also introduce a disadvantage.

For example:

faster shooting can reduce weapon damage;
additional maximum health can reduce movement speed;
stronger turrets can become more expensive to build;
additional data rewards can accelerate corruption.

The goal is to make each run different and force the player to balance power, survival and risk.

Demo Polish Update

Version 0.2.1 improves the presentation of the prototype with:

screen shake during impacts;
projectile trails;
procedural shockwaves;
glowing enemies and terminals;
floating score and data indicators;
clearer objective messages;
corruption warnings;
animated system banners;
improved victory and defeat screens;
a more animated Data Forge interface.

All visual effects are generated directly through code.

Signal Lost does not depend on external level files or large graphical asset packs.

Built with ZlormaEngine

Signal Lost is powered by ZlormaEngine, my custom 2D game engine written in Rust.

The engine currently provides:

software-rendered 2D graphics;
procedural environments;
procedural effects and sprites;
a custom bitmap font;
native Linux and Windows builds;
very small executable sizes.

The current approximate executable sizes are:

Linux: 476 KB;
Windows: 312 KB.

Keeping the engine and games lightweight remains one of the main technical goals of the project.

Why Game Jolt?

Game Jolt gives independent developers another place to present their work, publish trailers, share development updates and interact with players.

My goal is not to replace the itch.io version.

Instead, I want to use both platforms:

itch.io for distributing the prototype;
Game Jolt for sharing videos, updates and building a community around ZlormaStudio.

I have configured the Game Jolt marketplace account and submitted a request for Creator access.

I am now waiting for the Game Jolt team to review the application.

Play Signal Lost

The prototype is currently available for Windows and Linux:

Feedback about the controls, procedural generation, visual effects, difficulty and Data Forge system is welcome.

What Comes Next?

The next steps for Signal Lost include:

improving combat feedback;
expanding procedural room generation;
adding more enemy behaviors;
improving the Kernel Error boss encounter;
balancing the Data Forge upgrades;
adding more sound effects;
preparing the next public release.

I also plan to continue improving ZlormaEngine through the development of Signal Lost and Gemfall Arena.

Every new game helps test a different part of the engine.

Repair the system.

Contain the corruption.

Find the exit.

Building a Procedural Top-Down Shooter in Rust with My Custom Game Engine

Zlormack — Thu, 16 Jul 2026 18:31:57 +0000

# Building a Procedural Top-Down Shooter in Rust with My Custom Game Engine

After developing Gemfall Arena, I wanted to answer a new question:

Could my custom Rust game engine support something more complex than a wave-based arena shooter?

That experiment became Zlorma Core: Signal Lost — Prototype v0.1.

Signal Lost is a procedural top-down sci-fi shooter featuring exploration, damaged terminals, collectible resources, defensive structures, corrupted enemies, and a final escape objective.

It is also the second playable game built with my custom engine, ZlormaEngine.

The prototype is available for Windows and #Linux:

https://zlorma-studio.itch.io/zlorma-core-signal-lost-prototype-v01

Moving beyond an arena shooter

Gemfall Arena helped me build and test the first important parts of ZlormaEngine:

Software rendering
Keyboard and mouse input
Player movement
Projectiles
Enemy spawning
Collisions
Particle effects
Bitmap text
Wave progression
#Linux and Windows builds

However, its gameplay takes place inside a combat arena.

For my second project, I wanted the engine to support:

Exploration
Multiple connected rooms
Procedural level generation
Interactive objectives
Collectible resources
Player-built defenses
Different enemy behaviours
A final exit condition

Signal Lost became the project used to implement and test those systems.

The game concept

A digital corruption is spreading through an abandoned station.

The player controls the last maintenance program still online.

Three critical terminals have stopped responding. The station cannot activate its emergency exit until the terminals are restored.

The main gameplay loop is:

Explore the generated station
Locate a damaged terminal
Restore and defend it
Collect data fragments
Build barriers or deploy turrets
Restore all three terminals
Defeat Kernel Error
Reach the emergency exit

The objective was to combine fast top-down combat with light exploration and construction mechanics.

Procedural station generation

The biggest new system is the procedural map generator.

Each run creates a station containing connected rooms and corridors.

The generator must produce a layout that is:

Navigable
Large enough for combat
Small enough to avoid empty exploration
Suitable for terminal-defense encounters
Compatible with enemy movement
Different on each new run

The generated station contains:

Floor tiles
Solid walls
Connected rooms
Corridors
Three damaged terminals
Data fragments
Enemy spawn locations
Construction areas
A boss encounter
An emergency exit

This system can later be reused for dungeon crawlers, roguelikes, survival games, and other ZlormaEngine projects.

Terminal restoration

The three terminals provide the main objectives.

The player must explore the map, locate each terminal, and move close enough to begin restoring it.

While the system is being repaired, corrupted programs continue attacking.

This changes the rhythm of the game.

The player is not simply eliminating enemies. They must also decide:

Which terminal to restore first
Where to stand during a defense
Which passage should be blocked
When to spend collected fragments
Where a turret will be most effective

After all three terminals are restored, the final phase of the run begins.

Data fragments and construction

Signal Lost introduces a simple resource system.

The player collects data fragments while exploring and fighting corrupted programs.

These fragments can be spent on two defensive structures.

Barriers

Barriers can block passages and slow enemy movement.

They are useful for protecting terminals and controlling the direction from which enemies can approach.

Automated turrets

Turrets automatically fire at nearby enemies.

They cost more fragments than barriers but provide additional damage during terminal defense and the final battle.

The construction system is intentionally small in Prototype v0.1.

The goal is to test:

Resource costs
Object placement
Collision updates
Automated targeting
Structure health
Interaction with enemies

More structures can be added after the foundation has been tested.

Corrupted enemy programs

The prototype currently includes several enemy behaviours.

Glitch

Glitch is a small and fast enemy that directly pursues the player.

Its purpose is to apply constant movement pressure.

Corruptor

Corruptor is slower but more dangerous around objectives and defensive structures.

It forces the player to protect more than their own health.

Sentinel

Sentinel attacks from a distance using corrupted projectiles.

This prevents the player from remaining safely behind a single barrier.

Kernel Error

Kernel Error is the final enemy of Prototype v0.1.

It appears during the final stage after the terminal network has been restored.

Defeating Kernel Error unlocks the emergency exit and allows the player to complete the run.

Reorganizing ZlormaEngine

While creating Signal Lost, I also reorganized the engine into a cleaner Rust workspace.

The current structure looks like this:

``text
ZlormaEngine/
├── Cargo.toml
├── crates/
│   └── zlorma_engine/
│       ├── Cargo.toml
│       └── src/
├── games/
│   ├── gemfall_arena/
│   │   ├── Cargo.toml
│   │   └── src/
│   └── signal_lost/
│       ├── Cargo.toml
│       └── src/
├── scripts/
├── docs/
└── dist/
``

The shared zlorma_engine crate contains reusable systems.

Each game remains an independent executable while sharing the same engine foundation.

This organization makes it easier to:

Reuse rendering and input code
Maintain several games
Build the entire workspace
Target Linux and Windows
Produce release archives
Track executable sizes
Add future ZlormaStudio projects

Cross-compiling from Linux to Windows

The Linux builds worked correctly, but the first Windows cross-build failed while compiling minifb.

The error was:

``text
At least one of the x11 or wayland features must be enabled
``

The problem came from the dependency features defined in the engine crate.

After correcting the minifb configuration, Cargo correctly detected the required feature:

text
minifb feature "x11"
└── zlorma_engine
├── gemfall_arena
└── signal_lost

plaintext

The complete workspace now compiles successfully for:

text
x86_64 Linux
x86_64 Windows GNU

toml

A single build script creates:

Linux executables
Windows executables
Linux .tar.gz archives
Windows .zip archives
SHA-256 checksums

Keeping the executables small

One of the original goals of ZlormaEngine was to keep each game executable below 3 MiB.

The release profile uses size-focused settings:

toml
[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
panic = "abort"
strip = "symbols"

plaintext

Current optimized executable sizes are:

| Game | Linux | Windows |
|---|---:|---:|
| Signal Lost Prototype v0.1 | 460 KiB | 296 KiB |
| Gemfall Arena Demo v0.2 | 464 KiB | 312 KiB |

Both games remain comfortably below the original target.

The small size is especially satisfying because the same workspace now supports two different game structures.

What Signal Lost adds to the engine

Signal Lost expands ZlormaEngine with several reusable systems:

Procedural map generation
Tile-based rooms and corridors
Interactive terminals
Objective progression
Resource collection
Construction placement
Automated turrets
Destructible barriers
Multiple enemy behaviours
Boss progression
Exit activation

Gemfall Arena demonstrates arcade wave combat.

Signal Lost demonstrates exploration, objectives, resource management, and construction inside a generated environment.

Together, the two games provide a much better test of the engine than a single project could.

What I learned

The most important lesson was that a second game quickly reveals which systems are truly reusable.

Code that appears generic inside one project may still contain assumptions about:

Map dimensions
Enemy spawning
Camera behaviour
Game states
Interface layout
Objective progression

Building Signal Lost forced me to separate engine systems from game-specific logic more carefully.

It also showed the value of maintaining a shared workspace early, before creating too many separate projects.

What comes next?

Prototype v0.1 is a technical and playable foundation.

Future versions may include:

More station layouts
Larger sectors
Better enemy navigation
Additional corrupted programs
New bosses
More defensive structures
Player upgrades
Environmental hazards
Difficulty settings
Improved visual effects
Music and sound effects
Saved settings and progression
A clearer tutorial

My next priority is to test the core gameplay loop and improve it based on player feedback.

Play Signal Lost

Zlorma Core: Signal Lost — Prototype v0.1 is available for Windows and Linux.

Download it on itch.io:

Feedback about the controls, procedural generation, difficulty, enemy behaviour, and construction mechanics is welcome.

Repair the system. Contain the corruption. Escape.

Developed by ZlormaStudio

Powered by ZlormaEngine

Built with Rust

Pourquoi j’ai créé ZlormaEngine au lieu d’utiliser un moteur existant

Zlormack — Thu, 16 Jul 2026 18:19:48 +0000

Pourquoi j’ai créé ZlormaEngine au lieu d’utiliser un moteur existant

Développement d’un moteur de jeu léger en Rust pour créer Gemfall Arena

Je travaille actuellement sur ZlormaEngine, un petit moteur de jeu développé en Rust pour faire fonctionner mon premier jeu vitrine : Gemfall Arena.

Je ne cherche pas à créer un concurrent de Unity, Unreal Engine ou Godot. Ces moteurs sont beaucoup plus complets et sont développés par des équipes expérimentées.

Mon objectif est différent : je veux construire un moteur simple, léger et spécialisé dans les jeux de tir en vue du dessus. Cela me permet de comprendre ce qui se passe réellement derrière une fenêtre de jeu, un déplacement, un tir ou une collision.

ZlormaEngine est donc à la fois un projet de moteur et un projet d’apprentissage.
Pourquoi créer mon propre moteur ?

J’aurais pu utiliser un moteur déjà existant pour développer Gemfall Arena plus rapidement.

Cependant, je voulais répondre à plusieurs objectifs personnels :

apprendre Rust avec un projet concret ;

comprendre la boucle principale d’un jeu ;

contrôler directement le rendu et le gameplay ;

limiter le nombre de dépendances ;

produire un exécutable très compact ;

générer une grande partie du contenu sans assets externes ;

créer une technologie adaptée précisément à Gemfall Arena.

Utiliser mon propre moteur demande plus de travail. Par exemple, une fonctionnalité simple dans un moteur existant peut demander plusieurs fichiers et de nombreux tests dans ZlormaEngine.

Mais chaque problème résolu m’aide à mieux comprendre la programmation d’un jeu.
Une architecture Rust volontairement simple

L’architecture de ZlormaEngine reste volontairement légère.

Le projet peut être séparé en plusieurs parties principales :
Plain Text
Copy

ZlormaEngine
├── platform
│ ├── linux_x11
│ └── windows_win32
├── renderer
├── input
├── game
├── entities
├── procedural
├── waves
├── difficulty
└── shop

La partie platform gère les différences entre Linux et Windows.

Le renderer dessine les formes, les projectiles, les ennemis, les gems et les effets.

La partie game contient la boucle principale et les règles de Gemfall Arena.

Les autres modules s’occupent des systèmes plus précis comme les vagues, la boutique ou la génération procédurale.

Je préfère pour le moment une architecture claire et compréhensible plutôt qu’un système très abstrait. Mon niveau évolue en même temps que le projet, donc je garde du code que je peux relire et modifier facilement.
La boucle principale du moteur

Comme beaucoup de jeux, Gemfall Arena utilise une boucle principale.

De manière simplifiée, elle fonctionne comme ceci :
Plain Text
Copy

while game.is_running() {
platform.process_events();
game.update();
renderer.clear();
game.render(&mut renderer);
platform.present(renderer.framebuffer());
}

À chaque image, le moteur :

récupère les actions du clavier et de la souris ;

met à jour le joueur et les ennemis ;

vérifie les collisions ;

met à jour les projectiles et les particules ;

dessine la nouvelle image ;

affiche le framebuffer dans la fenêtre.

Cette boucle paraît simple, mais beaucoup de systèmes sont exécutés à l’intérieur.
L’objectif des 3 Mio

L’un des objectifs de ZlormaEngine est de garder le moteur et le jeu final sous une limite d’environ 3 Mio.

Cette limite est surtout un défi technique personnel. Elle m’oblige à réfléchir à ce qui est réellement nécessaire.

Pour réduire la taille, j’utilise notamment un profil Rust orienté vers la taille :
Plain Text
Copy

[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
panic = "abort"
strip = true

Ces options permettent de demander au compilateur de privilégier un exécutable plus petit.

J’essaie également de :

limiter les dépendances externes ;

éviter d’intégrer des textures volumineuses ;

générer les éléments graphiques directement ;

utiliser des structures de données simples ;

ne compiler que les fonctions réellement nécessaires ;

séparer le code Linux et Windows avec la compilation conditionnelle.

La limite de 3 Mio reste un objectif. Elle doit encore être vérifiée après chaque nouvelle version, car chaque fonctionnalité peut augmenter la taille du programme.
Un rendu logiciel

ZlormaEngine utilise un rendu logiciel.

Cela signifie que le moteur dessine directement les pixels dans une zone mémoire appelée framebuffer.

Par exemple, pour dessiner un pixel :
Plain Text
Copy

fn put_pixel(buffer: &mut [u32], x: i32, y: i32, color: u32) {
if x < 0 || y < 0 {
return;
}

let x = x as usize;
let y = y as usize;

if x >= WIDTH || y >= HEIGHT {
    return;
}

buffer[y * WIDTH + x] = color;

}

À partir de cette fonction, il est possible de construire :

des rectangles ;

des cercles ;

des lignes ;

des projectiles ;

des particules ;

des barres de vie ;

des ennemis ;

des gems.

Ce système reste moins puissant qu’un rendu moderne utilisant directement le GPU, mais il est suffisant pour mon jeu actuel.

Il me permet aussi de comprendre précisément comment l’image est créée.
Windows avec Win32

La première architecture était uniquement compatible avec X11. Elle pouvait fonctionner sous Linux, mais elle ne pouvait pas produire directement une version Windows fonctionnelle.

J’ai donc prévu un second backend basé sur Win32 et GDI.

Le gameplay reste identique. Seule la couche liée au système change.

Rust permet de séparer les plateformes avec des conditions de compilation :
Plain Text
Copy

[cfg(target_os = "linux")]

mod linux_x11;

[cfg(target_os = "windows")]

mod windows_win32;

Cela permet d’utiliser X11 uniquement sous Linux et Win32 uniquement sous Windows.

C’est une étape importante pour ZlormaEngine, car je souhaite proposer Gemfall Arena sur les deux systèmes.
La génération procédurale

La génération procédurale est une partie importante de l’identité du moteur.

Au lieu de charger de nombreux fichiers externes, ZlormaEngine peut générer directement certains éléments à partir de nombres et de règles.

Cela concerne notamment :

les positions des obstacles ;

les variations de couleurs ;

les formes des ennemis ;

les particules ;

les explosions ;

les trajectoires ;

les vagues ;

certaines variations de difficulté.

Un générateur pseudo-aléatoire simple peut être utilisé pour obtenir des résultats différents :
Plain Text
Copy

struct Random {
state: u32,
}

impl Random {
fn next(&mut self) -> u32 {
self.state ^= self.state << 13;
self.state ^= self.state >> 17;
self.state ^= self.state << 5;
self.state
}
}

L’utilisation d’une graine permet également de recréer une même génération.

Ce système est pratique pour produire du contenu sans augmenter fortement la taille du jeu.

Le système de vagues

La démo de Gemfall Arena contient actuellement 10 vagues.

Chaque vague détermine :

le nombre d’ennemis ; leurs points de vie ; leur vitesse ; les types d’ennemis disponibles ; la quantité potentielle de gems ; la pression exercée sur le joueur.

Une formule simple peut servir de base :

let enemy_count = 4 + wave * 2; let enemy_health = 1.0 + wave as f32 * 0.15; let enemy_speed = 0.8 + wave as f32 * 0.04;

Je dois toutefois faire attention à ne pas augmenter uniquement les nombres.

Ajouter trop de points de vie peut rendre les ennemis longs à éliminer sans rendre le combat réellement plus intéressant.

Je préfère donc mélanger plusieurs changements : vitesse, quantité, position et types d’ennemis.
Une difficulté adaptative

Le numéro de la vague ne suffit pas toujours à déterminer une bonne difficulté.

Deux joueurs peuvent atteindre la même vague avec des performances très différentes.

ZlormaEngine peut donc analyser plusieurs éléments :

le temps nécessaire pour terminer une vague ;

les dégâts reçus ;

la précision des tirs ;

la quantité de vie restante ;

le score ;

les améliorations déjà achetées.

Le moteur produit ensuite une valeur de difficulté.
Plain Text
Copy

let mut difficulty = wave as f32;

if accuracy > 0.70 {
difficulty += 0.4;
}

if damage_received == 0 {
difficulty += 0.3;
}

if clear_time > expected_time {
difficulty -= 0.2;
}

Ce système est encore en cours d’équilibrage.

Le but n’est pas de punir un bon joueur, mais de conserver une tension intéressante pendant toute la partie.
La Zlorma Gem Forge

La Zlorma Gem Forge est la boutique de Gemfall Arena et l’une des signatures que je souhaite conserver dans les jeux créés avec ZlormaEngine.

Les ennemis peuvent laisser tomber des gems lorsqu’ils sont éliminés.

Le joueur les récupère dans l’arène, puis peut les dépenser entre les vagues.

La particularité est que chaque amélioration possède un avantage et un inconvénient.

Par exemple :

Amélioration

Bonus

Malus

Rapid Core

cadence de tir augmentée

ennemis plus rapides

Power Shard

dégâts augmentés

santé maximale réduite

Vital Shell

santé maximale augmentée

déplacement plus lent

Phase Boots

vitesse augmentée

prix plus élevés

Gem Magnet

attraction des gems améliorée

ennemis plus résistants

Je trouve ce système plus intéressant qu’une boutique où chaque achat rend simplement le joueur plus puissant.

Le joueur doit réfléchir aux conséquences de son build.

Des prix liés au score

Le prix des améliorations peut évoluer selon la vague et le score.

Une formule simple peut ressembler à ceci :

fn calculate_price(base_price: u32, wave: u32, score: u32) -> u32 { base_price + wave * 3 + score / 500 }

Un joueur performant gagne davantage de gems, mais les améliorations peuvent également devenir plus coûteuses.

Ce système doit rester lisible. Si la formule est trop complexe ou trop punitive, le joueur ne comprend plus pourquoi les prix changent.

L’équilibrage de la boutique sera donc amélioré progressivement grâce aux retours des joueurs.
Les erreurs rencontrées

Créer un moteur apporte forcément des erreurs.
Le projet ne trouvait pas le script Bash

Lors des premières versions, le script de génération se trouvait dans le dossier de téléchargement, mais il était lancé depuis un autre dossier.

Linux indiquait alors :
Plain Text
Copy

Aucun fichier ou dossier de ce nom

La solution était simplement de se placer dans le bon dossier ou d’utiliser le chemin complet.

Cette erreur m’a rappelé qu’un script destiné aux utilisateurs doit afficher clairement où il se trouve et où il crée les fichiers.
Le moteur était uniquement compatible #Linux

La première version utilisait directement X11.

Le code ne pouvait donc pas être compilé tel quel pour Windows.

La solution a été de séparer le moteur en une partie commune et plusieurs backends de plateforme.
L’image du jeu était trop petite

La résolution interne était affichée directement sans agrandissement adapté.

Le jeu apparaissait dans un coin avec beaucoup d’espace noir.

La solution a été de conserver la petite résolution pour les calculs, mais de l’agrandir proprement lors de l’affichage.
Les ennemis se superposaient

Lorsque plusieurs ennemis poursuivaient le joueur, ils pouvaient se placer exactement au même endroit.

J’ai ajouté une petite force de séparation entre les ennemis proches.

Cela donne des déplacements plus naturels et rend les groupes plus lisibles.
Les fonctionnalités augmentent la complexité

Chaque nouvelle fonction peut créer des effets secondaires.

Une amélioration de vitesse peut modifier l’équilibrage. Une nouvelle particule peut affecter les performances. Une nouvelle plateforme peut ajouter des erreurs de compilation.

Je dois donc avancer étape par étape et tester régulièrement.
Ce que j’ai appris jusqu’à présent

Le développement de ZlormaEngine m’a déjà appris plusieurs choses importantes.

Un moteur n’est pas seulement un système de rendu. Il doit relier la plateforme, les entrées, les règles de jeu, les collisions, l’affichage et la gestion des ressources.

J’ai également compris que l’optimisation ne consiste pas uniquement à rendre le code plus rapide.

Elle concerne aussi :

la taille de l’exécutable ;

la consommation de mémoire ;

la lisibilité du code ;

la facilité de compilation ;

la compatibilité entre systèmes ;

l’expérience du joueur.

Je suis encore en apprentissage, mais Gemfall Arena me donne un projet concret pour progresser.
Les prochaines étapes

Mes prochains objectifs pour ZlormaEngine sont :

stabiliser les versions Linux et Windows ;

améliorer les effets sonores procéduraux ;

mieux équilibrer les 10 vagues ;

rendre la difficulté adaptative plus naturelle ;

améliorer la Zlorma Gem Forge ;

ajouter de nouveaux comportements ennemis ;

vérifier régulièrement la limite de 3 Mio ;

publier davantage de DevLogs techniques ;

recueillir les retours des joueurs et développeurs.

ZlormaEngine reste un moteur jeune, mais il fait déjà fonctionner une démonstration complète.

Je souhaite continuer à l’améliorer progressivement, sans perdre son objectif principal : rester petit, compréhensible et spécialisé.
Conclusion

J’ai créé ZlormaEngine parce que je voulais apprendre en construisant réellement les différentes parties d’un jeu.

Cette méthode est plus longue que l’utilisation d’un moteur existant, mais elle me permet de comprendre mes erreurs, de tester mes idées et de développer une technologie adaptée à Gemfall Arena.

Je ne cherche pas à prétendre que mon moteur est meilleur que les solutions existantes.

Je veux simplement créer un moteur qui correspond à mon projet, à mon niveau actuel et à ma manière d’apprendre.

Chaque nouvelle version de Gemfall Arena représente aussi une nouvelle étape dans le développement de #ZlormaEngine.

Zlormack
Développeur indépendant de ZlormaEngine et Gemfall Arena

Construire petit, comprendre mieux, progresser à chaque build.

🎮 Gemfall Arena :
🎬 Trailer :

VectHorde: Surviving the Swarm (Custom Rust Engine) 🦀

Zlormack — Thu, 04 Jun 2026 11:38:02 +0000

This is a submission for the June Solstice Game Jam

What I Built

Video Demo

Code

How I Built It

Prize Category

Building a Custom 2D Game Engine in Rust: Lessons from VectHorde

Zlormack — Tue, 02 Jun 2026 11:05:55 +0000

Building a game engine from scratch is a massive undertaking, but it’s one of the most rewarding challenges a developer can face. I’ve recently decided to take on this journey by building the #ZlormaEngine, a 2D engine written entirely in #Rust.

My goal was to create a lightweight, high-performance engine capable of handling hundreds of entities on screen without frame drops. To test its capabilities, I developed a Twin-Stick Shooter called VectHorde: Swarm Survival.

Why Rust for a Game Engine?

**Memory Safety**: Rust’s borrow checker helps prevent common memory-related bugs, which is crucial when managing large numbers of game entities.

**Performance**: The control over memory layout and zero-cost abstractions allows for the kind of arcade fluidity I wanted to achieve.

Challenges & Takeaways

**Entity Management**: Handling the swarm survival mechanic required efficient data structures to ensure the game remains stable even when the screen is crowded.

**The "Game Feel"**: Beyond the technical performance, fine-tuning the inputs and the "Terminal Nexus" upgrade system was key to making the game fun to play.

**
Check out the project**

I’ve just released the demo for VectHorde on itch.io. If you're interested in game dev, Rust, or just want to challenge your reflexes, feel free to give it a try!

👉 https://zlormack-studio.itch.io/vecthorde-swarm-survival

I’m currently gathering feedback to decide how to approach the full version of the game. If you have any insights on engine architecture or game design, I'd love to discuss them in the comments!

rust, #gamedev, #programming #showdev

Happy coding!
Zlormack
Building the ZlormaEngine in Rust.
Follow my journey on Itch.io