SpaceProjectSim: A self‑running space‑economy simulator in Rust and Bevy

Overview

SpaceProjectSim is a self‑running space‑economy simulator written in Rust with Bevy 0.18 that executes as a single native binary with no runtime dependencies. The project simulates hundreds of autonomous agents—ships, facilities, populations, factions—trading, mining, hauling cargo, taking contracts, and reacting to market prices that emerge from an order‑book model.

Simulation Mechanics

The simulation models autonomous ships using a GOAP planner that scores goals such as trade, delivery, refuel, retrofit, rest, and explore, then builds a behavior tree to execute the cheapest plan and replans mid‑flight when a better option appears. Facilities run production recipes (smelting, refining, manufacturing, farming, mining), degrade over time, self‑repair with tools, level up 1–10, restock from local markets, and are abandoned when chronically broke. Populations consume food and fuel, produce labor, post food and passenger contracts under stress, and physically migrate to happier systems when sentiment collapses. Factions collect taxes on member facilities, post subsidy contracts for chronic shortages, fund construction of new facilities where demand is unmet, and hold pairwise relations. Contracts come in six kinds—Delivery, Courier, Passenger, Subsidy, Supply, CrewMission—with a full posted → accepted → paid lifecycle, reputation gating, auto‑renewal, and age‑escalating payments. Markets price 13 commodities per station via a coverage model with shortage‑urgency multipliers; ships move real supply between markets as they trade. Construction sites appear during chronic shortages, accrete delivered cargo from 0 → 1.0, then materialize into a persistent facility. Everything persists to SQLite; a sim resumes from the exact tick it left off, and a per‑universe world_seed keeps the nebula backdrop stable across restarts. Spatial LOD causes distant ships to tick less often with rate‑scaled state changes so the frame budget focuses on the viewer’s vicinity. The simulation currently runs about 485 live agents (282 ships, 93 facilities, 27 populations, 8 factions, 60 celestial bodies) with a median tick time of p50 ≈ 10–20 ms inside a 125 ms budget.

Architecture

The codebase is organized into five crates in a Cargo workspace: sim_core (pure simulation logic with hecs ECS and GOAP planner, no async or IO), sim_db (SQLite persistence via sqlx), sim_server (library crate providing HTTP/WebSocket handlers for headless mode), sim_protocol (WebSocket wire types), and client_bevy (the binary that uses Bevy 0.18 + egui, embeds sim_core as a Bevy resource, and queries the hecs world directly). Three rules keep the design honest: sim_core never imports tokio, sqlx, or axum; hecs is the sole source of truth during a tick with exclusive mutable access; and cross‑entity effects go through a command buffer (SimCommand) where a phase reads world state and writes commands, and the next phase applies them, ensuring determinism. The tick phase ordering, ownership model, and feedback loops are documented in docs/ARCHITECTURE.md with mermaid diagrams. The original Godot client remains as a parity reference but is no longer the front end; the pivot to an embedded Bevy client removed the socket boundary entirely.

Building and Running

A single Makefile wraps cargo, rustup, codesign, and packaging to produce release binaries for macOS, Windows, and Linux. Running make run (equivalent to cargo run -p client_bevy) launches the Bevy client; make build creates a release binary at target/release/client_bevy. Headless mode, useful for CI or smoke tests, is invoked with cargo run -p client_bevy -- --headless, which starts the HTTP/WebSocket server from sim_server. The command make verify performs a build, runs ~250 tests, and executes clippy with strict settings. A smoke test script (scripts/smoke.sh [secs]) boots headless, runs for a given number of seconds, and prints database counts. All packaged builds read the version from the root Cargo.toml via env!("CARGO_PKG_VERSION") and the Makefile greps the same field for Info.plist and archive names, preventing version drift.

Community Reaction

Commenters highlighted the role of large language model assistance in the project’s development.

"I have also been using LLMs (mostly claude code) to develop a game with Rust and Bevy, and it seems to work very well. The strictness of rust seems to really help them get the code right, and the ECS architecture seems to make it easy for them to reason about how things work (because they only need to hold a few systems and components in context at a time)." — @lantry "It’s fun to see projects like this that seem largely unlocked by LLM assistance, and probably wouldn’t even get started if it weren’t for them. I know the hype cycle for LLMs seems to have hit its peak already, but I am fully convinced we are still in the early days of what we’ll be doing with them in software development." — @sulam Some expressed interest in extending the simulation for online use. "Neat idea! I think it would be cool if you can host a simulation and enable online viewers. Have the simulation accessible from a website (god-mode disabled of course), and have an agent generate some sort of newspaper or news bulletin of interesting things that happen." — @hersko Others compared the project to existing space games or asked about design choices. "Reminds me of SpaceTraders" — @thomascountz "What is it about the space industry life that makes us developers adore it so much? :p X4 Foundations just got a big update if you’re looking for a game built around this industry sandbox idea." — @qwertyastronaut "You might also like my AI written zero player game/sim: https://github.com/derekburgess/simcraft" — @spacecadet Questions about information flow and faction organization were raised. "I’m curious how you’ve thought about the faction organization structures as well as information flows in the sim? Are agents omniscient about prices and postings? I ended up making in-sim information a commodity that agents could choose to sell to each other, but I didn’t follow through fully baking that dynamic." — @awhitty A few commenters noted their personal reservations about studying LLM‑generated code. "I was kind of excited but then the "made with Claude" ruined it. I wanted to study your code but there’s little point in studying LLM code for me. Same as looking at LLM art." — @greenleafone7

Outlook

The author released the project under the MIT license to encourage forking, experimentation, and reuse of its systems, emphasizing that there is no official roadmap.

"Nowhere, on its own — and that's kind of the point.

This started as a fun idea: a from-scratch space economy that actually simulates itself instead of faking it. It grew way past what I expected, mostly in late-night sessions pairing with Claude. But I'm not pretending it's a game with a roadmap, and I'm not actively pushing it toward "shippable."" — from the project’s "A note on where this is going" The author invites others to gut, rename, bolt a game on top, or extract the economy engine for other uses, and welcomes pull requests and issues while noting that a fixed cadence cannot be promised.