Field note · Games
Crafting calculators are dependency graphs disguised as shopping lists
Published: September 9, 2026 · Maintained by: Jisung Kim · AI assistance and release-check practices are disclosed in the editorial policy. This note documents WEBBE-B tool behavior, design choices and verification practice.
PalStack turns Palworld crafting goals into remaining-material totals. The visible output looks like a shopping list, but the underlying problem is a dependency graph: one desired item can require components that themselves require other components.
Direct ingredients are only the first layer
If Item A requires two of B and three of C, and each B requires four of D, then one A indirectly requires eight D. A planner must recursively expand the recipe tree until it reaches base materials or another stopping rule.
Quantities multiply through the tree
Multiple goals share dependencies. Two different crafted items may both require ingots, polymer or another intermediate. Summing each branch separately and then merging identical base materials prevents the user from manually adding the same ingredient across several recipes.
Owned inventory changes what remains, not what the recipe means
The complete recipe requirement and the remaining shopping list are different quantities. If a goal requires 40 units and the player already owns 15, the remaining need is 25. Keeping those concepts separate makes the calculation explainable and lets inventory be updated without rewriting recipe data.
Intermediates create a modelling choice
A player may already own intermediate components. The planner can either subtract those components before expanding their ingredients or expand everything to raw resources first. The useful behaviour depends on whether the goal is “what raw materials would be needed from zero?” or “what do I still need given my current inventory?” A transparent interface should make that distinction visible.
Shared dependencies make a single combined plan valuable
Suppose three goals each need electronic components. Calculating them independently can make the player gather materials three times. A combined dependency expansion reveals the total once and can reduce repeated trips.
Versioning is part of correctness
Game updates can change recipes, quantities or item names. A perfectly implemented calculator with outdated recipe data can produce a wrong result. That is why the tool identifies the game version its data targets and tells users to verify unexpected totals after updates.
Cycles should not exist in a valid crafting tree
If recipe data accidentally says A requires B while B requires A, naive recursion never terminates. Data validation should detect that cycle instead of hanging the browser. Similar checks can catch missing recipe references and negative or zero quantities where they are not meaningful.
A simple worked example
Goal X needs 3 Y and 2 Z. Each Y needs 5 Ore. The player owns 1 Y and 4 Ore. If owned intermediates are credited first, only 2 Y need to be crafted, which consumes 10 Ore; after subtracting the 4 Ore already owned, 6 Ore remain, plus the ingredients for Z. Writing this chain explicitly makes it easy to test the calculator.
Why the browser is a good fit
The dependency data is finite and the arithmetic is deterministic. Once the recipe table is loaded, expansion and inventory subtraction can happen instantly in client-side code without an account or server-side player profile. The user controls the inventory values.
The broader lesson is that a crafting calculator should expose both the recipe assumptions and the remaining-material logic. A single total is useful only when the path to it can be understood and updated.
Choose whether intermediates are inventory or demand
A dependency calculator needs an explicit rule for craftable intermediates. Suppose one final item needs two plates, and each plate needs three ore. If the player already owns one plate, the remaining demand is one plate plus three ore only if existing inventory is consumed before expansion. If the calculator expands every recipe blindly, it will ask for six ore and overstate the shopping list. PalStack therefore separates recipe structure from inventory subtraction so the user can see which assumption produced the total.
Cycles must fail loudly
Most crafting trees are acyclic, but bad data can create A → B → C → A. A recursive totalizer without cycle detection can loop forever or overflow the call stack. A safe implementation marks the current dependency path and stops with an error if a material appears again before that branch closes. That behavior is preferable to returning a plausible-looking partial total from corrupted recipe data.