Back to Blog
craftingitemssystems designbalancing

Crafting Without Busywork: Designing Recipe Trees Players Can Reason About

A practical method for crafting systems: build a small ingredient vocabulary, pick the right chain depth, price recipes in player-minutes, and test with the empty-inventory walk.

GameDesignerX TeamOctober 14, 20268 min read

A player opens your crafting menu for the first time and sees 48 recipes. Thirty-one of them are greyed out. Four of them are "Wooden Spear", "Reinforced Wooden Spear", "Iron-Tipped Spear" and "Iron Spear". They close the menu and go back to hitting things with the first weapon you gave them, and they never open it again.

That is the usual failure mode of crafting. Not that the system is too shallow or too complex, but that the player cannot reason about it — cannot look at a shelf of junk in their inventory and form a plan. This post is a method for building a recipe tree that holds up: how to choose your ingredient vocabulary, how deep to go, how to price recipes so upgrades feel earned, and how to tell busywork from depth before you ship it.

Start with the fantasy, not the items

Before any spreadsheet, write one sentence describing what crafting is in your game. Three different sentences produce three completely different systems:

  • "Crafting is how I survive the next night." Short recipes, consumables, high turnover. Don't Starve and the early hours of Valheim live here.
  • "Crafting is how I express a build." Few recipes, each with meaningful trade-offs, usually modifiers or components rather than flat upgrades.
  • "Crafting is the game." Deep chains, intermediate goods, automation pressure. Factorio is the extreme end of this.

Write that sentence into your mechanics doc and treat it as a veto. Every recipe you later consider has to serve it. If your sentence is "crafting is how I survive the next night" then a 6-ingredient legendary sword recipe is off-theme no matter how cool it is.

Build an ingredient vocabulary, not an ingredient list

Players reason about crafting using categories, not individual items. Give them a small vocabulary with clear roles, then reuse it hard.

A workable default for a mid-sized game is four ingredient classes:

Class Role Rough count Example
Base materials Gathered directly from the world 8–12 wood, fibre, copper ore, hide
Refined materials One processing step, used everywhere 5–8 plank, rope, copper ingot, leather
Components Recognisable sub-parts, shared across recipes 4–6 hilt, gear, circuit, binding
Catalysts Rare, gate progression, consumed 2–4 core fragment, strange alloy

That is roughly 20–30 ingredient names total. It sounds small. It is not: with four classes and shared components you can support 60+ recipes where each one still reads clearly, because the player has only learned ~25 nouns.

The failure case is the opposite shape: 80 ingredients, each used in two recipes, so nothing the player picks up is predictably useful. A material that appears in only one recipe is a quest item wearing a costume. Either promote it to a component used in four places, or cut it and make the recipe use something existing.

The three-use rule

Before adding a new material, ask: can I name three different recipes that will use it, in at least two different categories (weapon, tool, structure, consumable)? If not, don't add it. This rule kills most crafting bloat at the source, and it is cheap to enforce: keep the material list in your items module, sort by "used in" count, and put everything with a count of 1 on the chopping block at every review.

Depth: how many steps before a payoff

Depth is the number of transformations between "thing I picked up" and "thing I use". Each step adds strategic planning and subtracts immediacy.

  • Depth 1 (ore → sword): instant gratification, no planning, no economy. Fine for action games where crafting is a side system.
  • Depth 2 (ore → ingot → sword): the sweet spot for most survival and RPG games. One processing station, one decision point.
  • Depth 3 (ore → ingot → component → sword): justified only when components are shared across many outputs, so making a batch of hilts is itself a meaningful decision.
  • Depth 4+: you are making a factory game. Commit to it, build the logistics tools, or back off.

A practical rule: the deeper the chain, the more outputs each intermediate must serve. If your depth-3 component feeds exactly one final item, delete the middle step. You added two clicks and a menu, not a decision.

Mixing depths is fine and usually correct: consumables at depth 1, gear at depth 2, endgame structures at depth 3.

Price recipes against time, not vibes

Every recipe has a real cost in player minutes: gather time + travel + processing. Estimate it crudely and write it down. You do not need precision — you need the ordering to be right.

Say your measured gather rates from a playtest are:

  • Wood: 20/minute
  • Copper ore: 8/minute
  • Hide: 3/minute (requires hunting)

An iron sword costing 10 wood + 20 copper + 5 hide is therefore 0.5 + 2.5 + 1.7 ≈ 4.7 minutes of player time. Now ask: is this sword worth five minutes? If it is a 10% damage bump over the starting weapon, no. If it unlocks a new biome, yes.

Put these numbers in a sheet with columns for ingredients, derived minutes, what it unlocks and tier, then sort by minutes. The order should match your intended progression exactly. Every inversion — a tier-3 item cheaper than a tier-2 item — is either a bug or a deliberate secret, and you should know which. A balance and economy sheet next to your item list makes those inversions obvious at a glance, instead of three months later in a thread about the "best early weapon".

Make upgrades consume, not duplicate

If a tier-3 sword's recipe is "20 iron + tier-2 sword", the player's old gear has an exit path and your numbers stay small. If it is "60 iron" from scratch, you get inventory hoarding and runaway material costs. Consuming the previous tier also means the player keeps exactly one sword, which quietly solves inventory pressure you would otherwise design around.

Discovery: how players learn recipes

Pick one model and stick to it. Hybrids confuse players more than any individual system does.

  1. Full visibility, greyed out. Shows the player the road ahead; risks the 48-recipe wall. Works if you filter by station and tier.
  2. Unlock by material. Picking up copper reveals every copper recipe. Strong teaching, strong "ooh" moment, easy to implement.
  3. Unlock by blueprint. Recipes are findable rewards. Good for exploration games, bad if players can miss a critical path item.
  4. Experimental combination. Players mix ingredients to discover results. Delightful when it works, but it needs a serious pass on failure feedback.

Model 2 is the safest default. Whatever you pick, always show a recipe's full ingredient list once it is visible, including the ingredients of its intermediates. "You need 3 rope" is useless if the player doesn't know rope is 5 fibre.

Test it with the empty-inventory walk

Here is a playtest protocol that finds crafting problems fast. Give a tester a fresh save and a single goal — "make yourself a shelter" — then say nothing for 15 minutes and record:

  • Time to first successful craft (target: under 3 minutes)
  • Number of menu opens before the first craft (target: under 4)
  • Whether they ever say out loud what they are going to make next
  • How many materials are in their inventory that they cannot name a use for

That last metric is the one that matters. If a tester is carrying nine materials and can explain four of them, your ingredient vocabulary is too big. Log the session in your playtesting module with those four numbers and re-run it after every material cull; the trend line will tell you more than any opinion in the room.

A pre-ship checklist

  • One sentence defining what crafting is in this game, agreed by the team
  • Every material used in 3+ recipes across 2+ categories
  • No intermediate step that feeds exactly one output
  • Recipe costs estimated in player-minutes and sorted without inversions
  • Upgrade recipes consume the previous tier
  • One discovery model, applied consistently
  • Recipes filtered by station and tier in the UI, never one flat list
  • Empty-inventory walk run with at least three testers who have never played

Crafting earns its place when a player can stand in a field, look at what they are carrying, and say "I need two more copper and then I can build the thing". Every rule above exists to protect that sentence. If a recipe you are about to add makes that sentence harder to say, it is busywork — cut it, and spend the time on the four recipes players actually use.