Suppose we are designing a game like *Minecraft* where we have many items $ i_1, i_2, …, i_n in I $ and a lot of recipes $ r_1, r_2, …, r_m in R $. Recipes are functions. $ r: (I times mathbb {N}) ^ n rightarrow I times mathbb {N} $That is, they take some items with nonnegative whole weights and produce a whole quantity of another item.

For example, the cake recipe in *Minecraft* is:

3 milk + 3 wheat + 2 sugar + 1 egg $ rightarrow $ 1 pie

… and the recipe for torches is:

1 bar + 1 charcoal $ rightarrow $ 4 torches

Some recipes might even be reversible, for example:

9 diamonds $ leftrightarrow $ 1 block of diamonds

If there is any combination of recipes that we can apply repeatedly to get more of the elements we started with, then the game is poorly balanced and players can take advantage of it.

It is more desirable that we design the game with recipes that retain elements or possibly lose some elements (thermodynamic entropy in the real world; toast cannot be easily undone).

**Is there an efficient algorithm that can decide whether a set of recipes:**

- keep items?
- lose items due to inefficiency?
- win items?

**Is there an efficient algorithm that can find problematic recipes if a game is out of balance?**

The first thing I think is that there is a graphical structure / peak flow problem here, but it is very complex and looks like a backpack problem. Or maybe it could be formulated as a SAT problem; This is what I'm considering coding at the moment, but there could be something more efficient.

We could encode recipes in an array $ mathbf {R} ^ {m times n} $ where the rows correspond to recipes and the columns correspond to elements. Column entries are negative if an item is consumed by a recipe, positive if it is produced by the recipe, and zero if it is not used. Similar to a well known matrix method for graph cycle detection, we could increase $ mathbf {R} $ at high power and get sums from each row to see if item totals keep going up, stay balanced or turn negative. However, I'm not sure this will always work.

Any discussion, code, or recommended reading is greatly appreciated.