Modeling Crafting Dependencies for a Scrap Mechanic Planner

Crafting-heavy games look simple until a player asks a practical question: “What do I need to build this machine, including every intermediate part?” At that point a recipe list becomes a dependency-graph problem. Scrap Mechanic is a useful case study because its parts, Craftbot recipes, upgrade chains, crops, and survival raids all affect planning.

Model recipes as directed edges

Each craftable output should point to its ingredient requirements, while every ingredient should have a stable item ID. A compact representation might look like this:

{
  "outputId": "controller-level-3",
  "quantity": 1,
  "station": "craftbot",
  "ingredients": [
    {"itemId": "component-kit", "quantity": 4},
    {"itemId": "circuit-board", "quantity": 6}
  ]
}

A public parts database can render the readable item pages, but the same records should power a crafting reference and any planning tools.

Expand dependencies recursively

A crafting planner can walk the graph until it reaches raw resources. The important details are:

• multiply ingredient quantities by the requested output count;
• merge repeated materials after expansion;
• detect cycles or invalid recipes;
• preserve station requirements;
• let players mark inventory they already own.

Memoizing each expanded recipe keeps large plans responsive. It also makes the calculation deterministic enough to test with fixtures whenever a game update changes recipe data.

Keep blueprint analysis separate

A blueprint analyzer has a different input grain. It starts with a serialized creation, counts parts by UUID, and joins those IDs back to the item database. Keeping this parser separate from the recipe graph makes both systems easier to validate.

The useful output is not only total block count. Mass, component categories, controller usage, bearings, pistons, and missing or modded UUIDs help a builder understand why a creation behaves the way it does.

Treat raids as another calculator

Survival planning also depends on farm value and timing. A raid calculator can translate planted crops into an expected raid level, then explain the thresholds instead of presenting a mystery number.

One source, several interfaces

The main Scrap Mechanic Wiki connects these views, but the architecture works because the tools do not maintain competing copies of the same facts. Normalize item IDs, version the source data, validate every relationship, and generate player-facing tools from that shared model.

That pattern applies well beyond one game: dependency graphs are the right abstraction whenever crafting, upgrades, and inventories overlap.