DEV Community: Zlormack

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