SIMN. Like Simon, but cooler.

Our open simulation and networking engine: a deterministic core in Rust does the thinking and handles networking transactions, while Godot does the rendering and handles player input and actions.

Source on GitHub

The split

SIMN as the source of truth, Godot as the client.

Built with Rust, utilizing Bevy's ECS implementation. (We use the standalone bevy_ecs crate) World state, AI, combat, networking, and anything where a crash or a subtle type error would wreck a session lives in a set of crates that build and test without Godot at all. That core is portable, fast, and harder to break by accident.

Godot handles what it's good at: rendering, scenes, audio, input. A single bridge crate is the only place the two worlds touch, built on gdext, the Rust bindings for Godot 4. Everything below that line stays engine-agnostic on purpose.

Content authorship (maps, UI, scenes, dialogue, scripted moments) is GDScript, which is fast to iterate on. The split means a buggy script can misbehave, but it can't corrupt world state or take the server down.

The stack

What's in the Box?!

Deterministic sim

In progress

The world runs using bevy_ecs at a fixed tick, with deterministic ordering. This pattern makes co-op replication and reproducible bug reports possible instead of a nightmare.

One bridge to Godot

In progress

gdext is the only seam between Rust and the engine. Keeping it to a single crate means the simulation never grows a hidden dependency on Godot, and the core APIs stay portable and flexible.

Steam networking, two ways

Planned

P2P over Steam for local saves, and a dedicated server build for persistent, hosted instances. The server is the source of truth; clients render what it tells them, client inputs feed the deterministic outputs.

TOML config, end to end

In progress

Every weapon, item, faction, region, and behavior is data, authored in TOML. This lays the groundwork for a robust modding toolset that allows for sim tweaks and new content without breaking core system integrity.

A world that keeps running

In progress

Near the players, the simulation runs in full fidelity. Outside that radius, regions update on a lighter abstract model. Both stay coherent, so the place you left behaves like a place, not a frozen set piece.

Open source, forever

In progress

Public under the MIT and Apache 2.0 licenses. Read it, fork it, learn from it, send pull requests, use it for your own game. Accepted engine contributions earn a share of revenue, terms pending.

Why bother

Determinism above all

Co-op means several machines need to agree on what just happened. If the simulation is deterministic, you can send inputs instead of constantly syncing state, and everyone sees the same response states. Without this, you spend the whole project chasing desync.

The discipline is annoying up front, but it (hopefully) saves the project later.

If you want the specifics, the code is public and open. Start with the simulation crates, then familiarize yourself with our Godot bridge.

Go deeper

Read the code.

Everything above is in the open. Clone it, build it, break it, use it, send a fix. The contribution and revenue-share terms are a work in progress, and will live on our website when they're ready.

Source on GitHub See Noosphere See the ledger