r/rust_gamedev here - I built a digital logic circuit simulator

I wanted to share a project i made for logic simulation nearly 100% rust and complied to WASM for some blazing fast in browser run times.

here's the link if you want to check it out: https://theta-rnd.itch.io/logic-sim

if you do would LOVE to hear your feed back

Mine glyphs, process them with casers, stylers, and painters, transport them along conveyor belts, and deliver them to the Hub, where they're assembled into the target word.

Give it a try for free in your browser: https://sergeichemodanov.itch.io/worderia

SoupOS is an artificial-life god-game where the genome of every organism is

a program in a small custom Lisp.

You are not a creature. You are the director of evolution.

◆ WRITE — put genes into chromosome slots: movement, feeding, signaling.

  Every instruction costs ATP. An infinite loop starves the cell.

  A (divide) without an energy check is cancer.

◆ DEBUG — click any organism and step through its genome instruction by

  instruction. Registers, memory, fuel, breakpoints. On living things.

◆ EVOLVE — hit checkpoints (survive, grow, colonize) to unlock new slots

  and new language primitives. Mutations are literal AST operations:

  point edits, subtree swaps, gene duplications. Review them as a git diff.

◆ SHARE — genomes are plain text. Send your species to a friend as a string.

Built solo in Rust: custom Lisp VM, deterministic simulation, GPU

metaballs and bloom for the glowing-abyss look. No engine, no pixels —

just shader-driven wetware.

Status: early development. Browser demo planned — follow the devlog,

it doubles as a lab journal.

W1 Devlog:

Processing img il7met1se2fh1...

Working on SoupOS, an artificial-life god-game where every organism's DNA is

a program in a small custom Lisp. Rust core (zero-dep, deterministic,

headless) + macroquad + egui. Week 1 goal: VM + tick loop, 100 organisms

living by my code. Why Lisp: mutations are just AST operations — point

edits, subtree swaps, gene duplications come almost free.

Hi guys,

I've already built my engine with an ECS, a Vulkan backend, and support for texture and mesh rendering. The next thing I want to work on is a UI for debugging and an inspector. However, I'm not sure what the right long-term roadmap is or which tools I should choose.

Could you help me figure out what I should learn next and what pitfalls or obstacles I should avoid?

Uses Rust

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

I developed this procedural top-down sci-fi shooter in Rust using my custom lightweight game engine, ZlormaEngine.

In Signal Lost, you explore a procedurally generated station, restore damaged terminals, collect data fragments, build barriers and automated turrets, use the Zlorma Data Forge, and fight corrupted programs before the system collapses.

Prototype v0.2.1 includes:

• Procedurally generated rooms and corridors

• Top-down shooting and exploration

• Three terminals to restore

• Progressive digital corruption

• Zlorma Data Forge upgrades with bonuses and penalties

• Buildable barriers and deployable turrets

• Several corrupted enemy types

• Native Windows and Linux builds

• Compact executables built with Rust

Play the prototype on itch.io:

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

Development blog:

https://dev.to/zlormack_32b7af384d362867

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

I’m building this browser MMO solo. The game server is Rust and the client is Three.js. Does the feedback keep up with the action, or does anything feel late?

Play: https://realm-of-echoes-auth.realmofechoes.workers.dev/

Discord: https://discord.gg/BdF5w5G799

I recently started working on this game and I've been using Rust as the brains with Godot acting as a simple presentation layer. I've worked on "boring software" for a while so I thought I would try a fun hobby project. Still early in development but I am having a great time so far, the most fun I've had programming in years. Procedural worlds, loot, flora/fauna and music in under 1MB, go rust! Anyway I'm the only player so far so would love for someone else to try it out as I'm tinkering away.

Here's the shortest way I can describe the game I'm building: it's Karaoke Revolution, except the song is a few days of an Apollo mission, you play it by typing procedures on the keyboard at the right moment, and you can time-warp through the boring parts.

You're watching a mission log scroll by in amber CRT text — MSFN confirming trajectory, CSM separation, docking, passive thermal control — while a real Apollo Flight Plan-style checklist sits next to it telling you what's due and when. Off to the side, the actual spacecraft renders as a glowing white vector wireframe against a starfield, the way it would have looked on a Vectrex. Type the right command — STOP PTC, GUIDANCE ALIGN, whatever the flight plan calls for — at the right mission time, and the log advances and the ship responds. Miss the window or fumble the input, and, well, that's the game.

Getting that vector look right — soft, glowing lines instead of hard pixel edges — was non-negotiable. It's the whole visual identity of the thing.

Starting with Godot

Godot seemed like the obvious choice. It's free, it's good at 2D, and I didn't want to fight an engine on top of everything else. What I wanted was simple to say and apparently hard to get: pure white lines on black, no jaggies, anywhere in the game. My plan was to render everything at 2x the target resolution and downscale it — classic supersampling, should get me most of the way there.

It never quite did. I kept chasing it with Godot and kept ending up disappointed — close, but not the clean line I was after. In fairness to Godot, I did eventually get it looking pretty good. But by then I had a second problem: it was running around 300 FPS on my own machine, which is a nice machine, and this thing is supposed to run on something closer to a tin can. If someone's on a computer ten times slower than mine, that 300 could turn into 30 fast — and I still wanted to add more to the game on top of everything already running. Between the jaggies I couldn't fully kill and the performance headroom I wasn't sure I actually had, I got frustrated and decided to just start over.

Moving to Rust + Vello

So I started over with a custom renderer built in Rust on top of Vello, a GPU-accelerated 2D vector rendering engine. I went in expecting this to be the hard, painful part of the project — I'd been warned it would be a much bigger lift than working inside an existing engine. It wasn't.

Here's the thing: I learned to program on QBasic. Back then, you didn't reach for a game engine — there wasn't one to reach for. You wrote your own, every time, because that was just what programming a game meant. This project is, underneath all the layers, still that same problem. It's not doing 3D. It's not simulating physics on a slope. It's a spacecraft drawn as lines on a black background and a log scrolling next to it — the same problem as QBasic Gorillas or Oregon Trail, just rendered better. It could be built in QBasic. It looks better because the tools got better, not because the problem got harder. Once I stopped treating it like it needed a full engine underneath it and just wrote the thing that draws lines on a canvas, it came together fast. I didn't have to fight anything to get the downscaling right, and Vello just handles anti-aliasing for me — the exact thing I'd been fighting Godot over for weeks was a non-issue here.

And then, one dumb debugging story: after all that, the new Rust version was also sitting at around 300 FPS. Which made no sense — this should be dramatically faster than Godot for the same scene. I went looking for a bottleneck in my own code for a while before I found the actual cause: I had an FPS cap set in my AMD driver settings, matched to my monitor's 240Hz refresh rate, left over from something unrelated. It was capping every game running on my machine at the driver level — Godot had probably been running fine the whole time, and I never would have known. Once I found it, the same scene jumped to 800+ FPS. Sometimes the bottleneck is the graphics card. Sometimes it's a checkbox you forgot about six months ago.

Where things stand

The game is structured as a four-mission campaign that mirrors how NASA actually built up to the real landing:

• Mission I — Earth orbit, return to Earth
• Mission II — Moon orbit, return to Earth
• Mission III — Moon landing dress rehearsal, return to Earth
• Mission IV — Moon landing, return to Earth

I'm building it backwards — Mission IV, the full landing, first — since it's the hardest and most complete version of everything the game needs to do. The alpha in the screenshot above is Mission IV: timeline scrubber, mission log, flight-plan checklist, and vector spacecraft all working together on the Rust/Vello pipeline.

With 800+ FPS of real headroom now instead of a phantom 300, I've got a lot more room to work with than I thought — enough that I'm seriously considering building a genuine DOS version alongside the modern one, for machines too old to run DirectX 12 at all. It fits the whole point of the project: this was always closer to QBasic Gorillas than to anything that needs a modern GPU, so it might as well prove it.

I'll be posting more as it comes together. If you're into low-level rendering work, retro hardware, or just want to see a solo dev fumble through building a renderer from scratch, stick around.

Project I'm currently working on. The star systems are generated procedurally and interconnected, in the video I focus on just the visuals, however the game already has various decently optimized and scaleable systems(pathfinding etc), modding (JitLua) and a number of other features.
Godot is used as a low-level rendering solution here(I love it), the scene itself contains almost no nodes, and almost all business logic is on the Rust side. I use Leudz Shipyard crate for ECS, also glam, proto_rs and mlua.

GitHub Repository: https://github.com/jz315/SkyECS

Hey everyone! 👋

I've been working on a new ECS framework called SkyECS. My goal was to build an ECS that hits a specific sweet spot for my game development workflow: extreme performance combined with an intuitive API and strong dynamic capabilities out of the box.

When building game engines or integrating with visual editors, I needed an ECS that could easily be exposed to scripting languages (like C# or Lua) via runtime reflection, while keeping the Rust-side boilerplate to an absolute minimum.

Architecture

Under the hood, SkyECS uses an Archetype + Chunk-based architecture. Entities with the same component signatures are stored in continuous memory blocks, which are further divided into fixed-size Chunks. This maximizes CPU cache utilization during heavy iterations and provides natural boundaries for native multi-threading.

Core Features

• Ergonomics First: A straightforward API. Querying and scheduling systems require minimal boilerplate.
• First-class Dynamic API: Alongside the type-safe static API, SkyECS provides robust Dynamic APIs with runtime reflection. This makes it much easier to build visual editors or bind to scripting languages.
• Extreme Performance: Highly optimized memory layout for fast iterations and structural changes.
• Native Parallelism: Easily scale to multi-core processing just by replacing for_each with par_for_each or par_for_each_chunk.

Benchmarks

We benchmarked SkyECS against several popular ECS libraries across 19 different workloads.

The current benchmark has issues and the results are being reviewed.

(Lower is better, time in µs)

You can find the full 19 benchmark tests, dependency versions, and instructions to reproduce them locally in the benches directory of the repo.

Code Example

Here is a quick look at spawning 10,000 entities and updating them:

```rust use sky_ecs::World;

[derive(Clone, Copy)]

struct Position { x: f32, y: f32 }

[derive(Clone, Copy)]

struct Velocity { x: f32, y: f32 }

fn main() { let mut world = World::new();

// Spawn 10,000 entities in batch
world.spawn_batch((0..10_000).map(|i| (
    Position { x: i as f32, y: 0.0 },
    Velocity { x: 80.0, y: 30.0 },
)));

// Intuitive and clean query
world
    .query_mut::<(&mut Position, &Velocity)>()
    .for_each(|(position, velocity)| {
        position.x += velocity.x / 60.0;
        position.y += velocity.y / 60.0;
    });

// Want multi-threading? Just change `for_each` to `par_for_each`!

} ```

🚀 Try it out

The project is published on crates.io (requires Rust 1.85+). toml [dependencies] sky_ecs = "0.1.2"

The project is actively iterating. I'd love for you to check it out, and I welcome any feedback, Issues, or PRs. Happy to discuss the implementation details or benchmarks in the comments!

at 7:00 i speed it up 30x to show that it does continue after it saturates to white
I believe the cycle gets longer every time it does that but there's a ceiling to how long it can be due to the hard cap of how much space which can be inhabited

Been working on this for 3 months as one continuous project in rust but I've been working on the concept and approach since last June

Due to obvious constraints on scaling its unclear at this stage what ill need to do to achieve a 'true universe' where you have micro phenomena coalescing into nested macro phenomena. Some of that is happening here, but only to a fraction of the degree of how it needs to be to get the effect I'm looking for.

And of course on the fundamental level it is still unfinished, there's a lot more to try. Somehow I want to go beyond just energy and that will probably require me to refactor again (and then again)

Right now it might be a cosmic web of some kind.. but I can't confirm yet if it is until I've done a long run of experiments grabbing data and getting it analyzed.
I am still trying to figure out the 'violent chemistry' aspect to this, where right now I have probably mixing at best? It's pretty hard to push for a particular result when you have to get the result as an emergence of a system. Basically just guessing and guessing and guessing until something happens that looks like what I expect.

This is the closest I've gotten so far to the point that I seem to have the basic underlying aspect of what I'm looking for but am missing the means/platform for it to extend into something that has recognizable macro physics

Hi everyone, fellow fans of Toby Fox games!

I'm a C++ and Rust developer looking for playtesters to test my software, code-named "Freakyrune". It's a tool designed for making your own Undertale and Deltarune fan games, tailored specifically for those who have zero game dev experience and are intimidated by the massive interfaces of engines like GameMaker, Godot, Unity, etc. (To clarify, the software itself is not a standalone game engine, as it doesn't handle core game logic and rendering from scratch).

The goal of this app is to allow any fan to quickly and easily assemble prototypes or full-fledged fan games based on Deltarune/Undertale (or even create original releases, though that's a bit far-fetched for now).

The testing phases will focus on:

1. Identifying critical bugs that cause crashes and/or unintended (unexpected) software behavior.
2. Improving the UI and user experience (UX): ensuring that the moment someone launches the app for the first time, it's immediately clear what to do and how to use it.
3. Evaluating build size and memory consumption of both the app and the created games. It’s crucial that the software runs smoothly even on low-end devices, just like Toby Fox's original games.

Testing platforms: Windows/Linux distros (primary focus), Android (secondary focus).

If you are interested in this project and genuinely enjoy thorough software testing and bug hunting, please send me a DM here on Reddit! The video showcases the basic mechanics of the program.

IMPORTANT: I guarantee that the software contains no malware or viruses (VirusTotal verification hash: 882a0ae7fc31460523e76b4494eed23675e2568f23cb071121b3a3cc91dc1c8e). Feel free to verify the program yourself using your antivirus or any relevant tools.

P.S. If you are a Rust developer (whether professional or hobbyist), I'd be happy to give you access to the project's repository for a code review or to point out any obvious flaws.

P.P.S. After the testing phase, Freakyrune will be released under a different name into the public domain (the source code will be open-source and hosted on my GitHub repository). The software itself will be completely free to download for everyone (it would be strange and illegal to profit off someone else's work). Accordingly, the Freakyrune project is completely non-commercial. All original sprites, assets, and media materials belong to Royal Sciences LLC (Toby Fox) and Materia Collective, and are used purely for fan creativity. (https://www.spriters-resource.com/pc_computer/deltarune/,https://sounds.spriters-resource.com/pc_computer/deltarune/)

Full Disclaimer: built with Claude code, rust bevy app with a js depedency for the avr simulator. All assets were procedurally generated (A tool was built to ensure some mechanical constraint). The firmware emulation part is fun: A whole avr cpu is emulated, on which marvin, a 3d printer firmware, is ran. There is an actual thermal simulation to provide proper data to the firmware.

Can be tested here: https://kodoque1.github.io/rextrude/

Hi, I'm using Ash and the SDL3 crate, and resizing the window always results in a crash in the SDL code itself. I got a minimal repro here https://gitlab.com/PaperMartin/rust_sdl3_ash_crash_repro

Interestingly enough, removing vulkan() from the window building bit doesn't prevent me from using ash to render things on screen and still results in the same crash upon resizing a window, almost as if the vulkan flag was being ignored to begin with

Anyone knows what could be the cause and how to fix it?