AS/
← Games

GearTopia

A Factorio-like factory sim with Dwarf-Fortress depth levels and no electricity — everything runs on gears and shafts.

Role
Solo — design & engineering
Year
2026
Stack
Godot · C# · GDScript · Simulation · Data-driven architecture
TL;DR

A factory-building game in Godot (C# + GDScript): dig down through Dwarf-Fortress-style depth levels and power your factory entirely through mechanical energy — shafts, gears, and gear ratios instead of electricity. A custom simulation of RPM/torque networks, data-driven buildings, conveyors, and cross-level item transfer, with the heavy systems written in C# for performance. My most technically ambitious game; currently paused.

What it is

A Factorio-style factory builder with two deliberate twists. First, the world has depth levels in the spirit of Dwarf Fortress — you dig downward and build across multiple Z-layers. Second, there’s no electricity: the whole factory runs on mechanical power — shafts and gears — so power routing is a physical, spatial puzzle rather than a wire you drop anywhere.

It’s the most technically ambitious of my games, and it’s on pause — I may return to it. What’s below is what actually runs.

The core system: mechanical power

Power is simulated as networks of connected shafts, gears, and machines:

  • Energy sources produce an RPM and a torque.
  • Gears change RPM by their tooth ratio — rpm_out = rpm_in × (teeth_in / teeth_out) — so gearing up for speed costs you torque, and vice-versa.
  • Machines only run when the network delivers their required RPM (within a tolerance) and enough torque.
  • Shafts cap how much power they can carry, so overbuilt lines break or stall.
  • Networks resolve to states like RUNNING, OVERLOADED, or CONFLICTED — the last when two sources fight over the same network at different RPMs.
No electricity — everything runs on mechanical power

  source ──shaft──▶ gear ──shaft──▶ machine
   rpm, torque    teeth ratio    needs target rpm ± tol + torque
                rpm_out = rpm_in × (teeth_in / teeth_out)

  networks solved with BFS, rebuilt lazily only on change:
    RUNNING · OVERLOADED · CONFLICTED · IDLE · SHAFT-BROKEN

  60 Hz deterministic tick ▸ Mechanical ▸ Machines ▸ Conveyors

The network solver runs a BFS over the grid and rebuilds lazily — only the dirty parts, only when something changes — rather than recomputing every tick.

The rest of the factory

  • Depth & cross-level transfer. A multi-Z-level world you dig through; ports carry both power and items vertically between levels, and the camera can peek the layer below.
  • Data-driven content. A building is just a .tres config (footprint, ports, gear/machine/shaft/conveyor stats, optional behavior script) auto-loaded from a folder; items work the same way. Adding or tweaking content is a data change, not code.
  • Conveyors & crafting. Conveyors move items between machines and storage on a deterministic 60 Hz tick; machines craft from mechanisms, with cascading manual crafting on top. Item queues are struct-based and zero-GC.
  • World & interaction. A chunk-based spatial grid with per-layer O(1) lookups, four build layers (ground / mechanical / transport / structure), digging, a player inventory and hotbar with drag-and-drop, and a machine interface.

Performance, and the C# decision

Performance was a first-class goal, and it drove a real architecture call. Profiling pushed me to move the heavy simulation into C# — the spatial grid, the mechanical and machine and conveyor systems, runtime building state, and the zero-GC conveyor queues — while keeping the lighter, iteration-heavy systems in GDScript (UI, player, rendering, building behaviors). In practice that meant porting core systems across languages mid-project — a deliberate trade of short-term rework for the frame budget a factory sim needs when the map fills up.

What’s laid in, and what stayed on paper

The groundwork is in for a fluids/water system and for tower-defense-style combat — enemy waves that attack the factory, with buildings already carrying HP and damage. The wider design — settlement contracts (ship resources out to settlements for rewards) and goblin raids you defend with traps and turrets — is designed but not yet built.

Why it’s here

It’s my clearest example of systems engineering at scale: a custom simulation (mechanical power across a multi-level grid), a data-driven content pipeline that makes new machines trivial to add, and pragmatic performance work — including a cross-language port — done because the game genuinely needed it.

Gameplay video ↗