A Tiny Colony Simulation in Rust (Part 1)
Scope, Constraints, and Why Bevy
I’ve tried starting this game before.
More than once, actually. A small, fantasy-flavored colony simulation: a few people, a piece of land, some basic production, and the feeling that things slowly start to work on their own. Every time I approached it with decent intentions and familiar tools (Unity, C#, things I use professionally), and every time it quietly died.
The reasons were always the same: lack of time, increasing scope, and no clear stopping point.
This time, I’m trying something different. I want to keep the project small, treat it as a learning exercise, and, most importantly, actually finish something. I’ve also been wanting to learn Rust for a while, mostly out of curiosity. This project is a way to combine both goals.
This is not a commercial game, and it’s not meant to be a polished tutorial series. Think of it more as a public lab notebook: documenting decisions, constraints, and small steps taken along the way.
The “game”
At its core, the game is a very small, RimWorld-inspired colony simulation.
There is a fixed grid world. A handful of pawns live in it. Some tiles contain trees, which can be chopped for wood. There is a stockpile. Pawns autonomously go to trees, chop them, and haul the wood back to the stockpile.
That’s the entire gameplay loop.
There are no grand narratives, no diplomacy systems, no deep needs simulation. Just a simple loop that is easy to reason about and, crucially, easy to finish.
In scope
For the first version, the scope is deliberately constrained to:
a fixed-size grid map
around 10 pawns
trees with a finite amount of wood
hauling wood to a stockpile
a fixed tick-based simulation loop
minimal UI for debug information (wood count, tick rate, pause/speed controls)
Explicitly out of scope
Equally important is what this version will not include:
hunger, mood, relationships, or social systems
building placement or construction
diplomacy, factions, combat, or military mechanics
advanced pathfinding or optimization
editor tooling or polished UI
Why Rust
I don’t have a professional reason to use Rust here. This is not about picking the “best” language.
I’ve wanted to learn Rust for a while because it sits at an interesting intersection of systems programming, safety, and performance. Simulation-heavy problems are a natural fit for its strengths, and the language forces a level of clarity that I find appealing.
Using Rust here is mostly about curiosity and learning, trying something new outside my usual stack, in a context where correctness and explicit data flow matter.
Why Bevy
For the engine, I chose Bevy.
Bevy is a Rust-native game engine built around an ECS (Entity-Component-System) architecture. That model maps very naturally to simulation-heavy games, where behavior emerges from many small rules applied over large sets of entities.
I also like Bevy’s code-first workflow. There’s no heavy editor dependency, and most of the logic lives directly in Rust code. That makes it easier to reason about what’s actually happening, and easier to keep the project lightweight.
Bevy isn’t the simplest option, and it’s certainly not the most mature engine available. But it strikes a good balance between control and productivity, and it’s a solid excuse to explore ECS-driven design in practice.
High-level architecture
At a high level, the project follows a few simple principles:
the game is built using ECS concepts: entities are data, behavior lives in systems
the simulation runs on a fixed tick rate
rendering is decoupled from simulation logic
most game behavior is data-driven rather than object-oriented
There’s no attempt here to design a reusable framework or an extensible engine. This is a small, purpose-built simulation.
Constraints and rules
To avoid repeating past mistakes, I’m imposing a few rules on myself:
no expanding scope mid-iteration
one small feature per milestone
refactor only when something actively hurts
once a milestone works, stop and write about it
