/ Problem
Design thinking applied to a tool
FactoPlanno is a web-based factory planner for factory building game Satisfactory. It's a blueprint-style canvas where you drag machines from a palette, draw belts and pipes between them, and produce a layout you can rebuild in-game nearly 1:1. It isn't a game: no goals, no progression, just a tool meant to sit beside one.
That makes its design problem different from a game's, because it's why I beleive the project belongs here. A tool has nowhere to hide; it has no story or theme to carry it. Its entire design is whether it makes the user's task faster and clearer. FactoPlanno demonstrates two design muscles a game doesn't surface as directly: systems literacy (understanding Satisfactory's rules well enough to encode them) and scope discipline (knowing exactly which problem to solve and sidelining the rest). The tension the whole tool is built on: a plan has to be faithful enough to rebuild in-game exactly while staying fluid enough to actually edit. This is the fidelity that stays editable.
/ Approach
Solving the one underserved problem
Three decisions carry the tool: hold the scope to spatial layout, model the game's real footprints, and resolve the central tension with one abstraction. Presenting: runs.
01 — Scope Discipline
Layout, not math
The sharpest design decision was what not to build. Plenty of current tools handle the mathematical side of factory planning tracking input/output rates, power, water, ratios, and they all handle it well. FactoPlanno deliberately doesn't touch any of it. It targets the one stand-out problem: the actual spatial layout. Where belts and pipes physically run, what footprint a build occupies; which the existing math-focused tools largely ignore. (The one layout-focused tool, SaLT, was a great concept left unfinished and years out of date; that gap is what motivated this project.) The math could be added later, but holding the line on a single well-defined purpose is the design decision, and resisting feature-creep into territory others already own is the discipline behind it.
02 — Fidelity to the Real Build
The game's own units
The tool earns the "rebuild it exactly" promise through grid and footprint accuracy. Machine footprints are modeled as close to 1:1 as possible, and the canvas runs a two-layer grid: a fine ~1m grid, and a bold grid every 8×8 of those squares which is exactly one Satisfactory foundation. Planned for the future is to include .5m snapping granting precise placement for belts, pipes, and walls. The plan isn't a sketch that approximates the game; it's measured in the game's own units, so when you go to follow it in-game, it's nearly a one-to-one match.
03 — THE THORN TO MY MECHANICAL ROSE
Runs
This is one design idea the tool orbits, and it came out of a real tension. In Satisfactory, belts and pipes have a length limit. FactoPlanno auto-breaks a line at that in-game limit, so the visible segments double as a read-out of how much material the path will actually cost to build. But auto-breaking created a new problem: once a line is chopped into segments, editing it is miserable if every piece is independent. The answer I came up with is the run. This is a specialized "group" just for belts and pipes. A run is a whole length of belt or pipe that can be extended from either end and moved as a single unit, segments stay connected, with no redrawing. And it stays flexible: the user can detach a single segment from a run, or split a run in two, and the leftover segments survive as their own runs. That's the design of it becomes clear once I understood the game's rule (length limits), surfaced its real cost (auto-breaking), then invent the abstraction (runs) that keeps the result remains editable. The fidelity-vs-fluidity tension is solved in one simplified concept.
/ Implementation
Current state
The drag-and-drop canvas, palette, belt/pipe drawing, the two-layer foundation grid, and the runs system are the working core of the prototype. The .5m snapping, machine grouping, and much more are planned. Built in JavaScript and React (which I learned both from scratch just for this project), while coming from a C# and Python background; the technical reach is real, but in a tool every line of it is in service of one thing, how cleanly the user can lay out a factory in a way they can efficiently reproduce in-game.
Fig. 1: Canvas — a factory laid out
Fig. 2: Grid detail — 1m + 8×8 foundation
Fig. 3: A run — moved and split
(Media slots to fill — canvas with a factory laid out, the grid detail, a run being moved and split.)
/ Outcome
What the tool produces
A finished FactoPlanno plan is something a player can open beside the game and follow exactly. It should have the same footprints, same grid, real belt counts — while having been quick to lay out and painless to rearrange along the way. The design success isn't a feature list; it's that the tool resolves fidelity against editability instead of forcing the user to pick one.
Differentiator
Where current planners model the throughput of a factory, FactoPlanno models its footprint, the physical layout, in the game's own grid units, faithful enough to rebuild from. It fills the gap SaLT left and that the math-tools never aimed at.
Origin & Authorship
I started this project because I wanted it to exist. I already loved how SaLT worked, but yearned for it to be complete. I also knew other players would find use in it, and chose to make it open source so anyone can pull it, adapt it, suggest features, or help build it. Documented openly on GitHub and YouTube alongside FrostBound and Aqua-Deco.
Status
Prototype, publicly available on GitHub. Subject to change; runs in particular still want testing and tuning, though the concept is solid.
Fidelity that stays editable
Plans rebuild in-game 1:1, yet rearrange without redrawing.
Runs
Encoding the game's belt limits into one movable, splittable abstraction.
Scope discipline
Solves the underserved layout problem; deliberately leaves the math to others.
Real technical reach
JS/React learned from scratch, all of it in service of the user's task.