I wanted the pleasure of routing a production line without prescribing one efficient answer. Crushline began with a factory-game question: if two machines can get to the same material by different routes, what makes the choice interesting beyond a larger number on one recipe? Waste, byproducts, timing, bottlenecks, and the freedom to leave a messy line in place became part of the design.
The technical path was uneven. I worked through C++ and SDL experiments, graph structures, and several interface directions while the game rules kept evolving. A three-route iron example made the tradeoffs concrete enough to discuss, and ports and rates made a graph legible. At the same time, I was separating the reusable graph and platform work into projects of their own. This page follows the game-specific decisions through those splits and the reported UI successes and failures; it does not turn the exploratory production designs into a released game.
Production needs a reason
I asked for a base of twelve solids, twelve liquids, and twelve gases, classifying them by their initial state at ambient room temperature. That was a content-planning direction, not a final chemistry simulation or a locked list of thirty-six implemented resources.
The follow-up question was “why?” Producing materials should support incremental challenges and a final objective, with several possible paths to victory. I also wanted basic machines to need upgrades, and intermediate parts and components to connect the raw materials to those upgrades.
One idea was to craft modifiers for machines or individual ports. Ingots could become parts, then assemblies that improved throughput or efficiency. That gives a production line a reason to feed another line and gives the player reasons to revisit an older layout.
A concrete slice: three ways to make iron
The assistant’s Slice 1 specification made those ideas tangible. Its ordinary objective was at least 50 iron ingots per minute, handled slurry, sufficient power, and a graph without hard structural errors. Any one valid route could satisfy the basic production goal.
The rates below were proposed content-authoring values, not already approved balance or measured game output:
| Route | Process | Proposed output and cost |
|---|---|---|
| Washed ore | Ore → crusher → washer with water → smelter | 50 ingots/min, 10 slurry/min, 60 kW |
| Slurry recovery | Ore → crusher → slurry-producing wash → filter → dust smelter | 50 ingots/min, 20 dirty water/min, 10 waste/min, 78 kW |
| Dirty shortcut | Ore → crusher → direct dirty smelting | 50 ingots/min, 25 waste/min, 69 kW with two crushers |
The baseline washer consumed 60 crushed ore and 30 water per minute to produce 50 washed ore and 10 slurry. The recovery variant used 40 water and sent 50 slurry to a filter. The filter produced iron dust and dirty water, making the unwanted stream something that could become part of another route.
The dirty smelter took 100 crushed ore per minute. Two proposed crushers could nominally supply 120, leaving a surplus to expose rather than automatically hide. The numerical draft still needed a balance and flow-consistency pass; it should not be mistaken for a validated simulator result.
Ports make the tradeoffs readable
The proposed node layout put primary inputs on the left, main outputs on the right, and byproducts on the bottom where appropriate. A washer therefore needed both ore and water inputs, plus a way to route slurry or waste. A filter needed an iron-dust output and a dirty-water outlet.
The failure cases were part of the specification. Missing water could stop a washer. Insufficient power could scale machines down. An unhandled byproduct could prevent the objective from passing. Sending raw ore to a washed-ore recipe could produce no useful output. Surplus material could be a diagnostic without automatically making the graph invalid.
An optional showcase would run all three routes together for 150 ingots per minute. Its purpose was to demonstrate different costs, waste streams, power needs, and graph complexity around one target item.
The implementation route also changed
The broader history includes C++ simulation work, custom platform and graph layers, a React Flow prototype, and Godot exploration. In the stack discussion I said React had demonstrated that the graph interface could be playable, while proposing Godot as a development direction I already knew somewhat. A later message preferred the optimized React Flow interface to Canvas2D.
I was still changing both the factory rules and the path to an interface. The steady part was the game question: can a player see why a line produces what it does, reroute it, and learn from an inefficient build without being forced into a single recipe?