The safest design is not a hidden catalog of items, prices, and success rates. Those values can change by patch, server, market, or community methodology. A more durable calculator treats them as user-supplied evidence and performs a small, auditable expected-value calculation.

This article builds that model, derives its break-even condition, implements it in JavaScript, and explains what the result cannot tell us.

Define the scenario before writing code

Suppose one crafting attempt consumes several materials. For material i, let:

• qᵢ be the quantity consumed per attempt;
• vᵢ be the entered value per unit;
• c be any additional cost per attempt;
• a be the number of planned attempts;
• p be the entered probability of success, from 0 to 1;
• u be the number of output units produced by one success;
• V be the entered value of one output unit.

All values must use one consistent unit. It can be a game currency, guide points, or an opportunity-cost scale, but mixing units makes the result meaningless.

The input cost of one attempt is:

C = Σ(qᵢ × vᵢ) + c

Across a attempts, total input value is aC. The expected number of successes is ap, so expected gross output value is:

E[gross output] = a × p × u × V

Expected net value follows directly:

E[net] = a × (p × u × V - C)

This is the ordinary probability-weighted mean. OpenStax's discussion of the mean or expected value of a discrete random variable gives the broader statistical definition.

Derive the break-even probability

Set expected net value to zero:

p × u × V - C = 0

Solving for p gives:

p* = C / (u × V)

p* is the arithmetic break-even success probability. If the entered probability is above p*, the model has positive expected net value; if it is below, the model has negative expected net value.

Notice that the attempt count cancels. Running the same model more times scales expected profit or loss, but it does not change the break-even probability. That distinction is useful in interface design: attempt count describes exposure, while p* describes the decision boundary.

The boundary can also reveal impossible economics. If p* > 1, even a guaranteed success would not recover the entered cost under the current output assumptions. The software should display that result rather than clamp it to 100% and hide the problem.

A small JavaScript implementation

The arithmetic is short enough to review in one sitting. Validation is where most of the defensive work belongs.

function craftingExpectedValue({
  materials,
  otherCostPerAttempt,
  attempts,
  successChancePercent,
  outputsPerSuccess,
  valuePerOutput,
}) {
  if (!Array.isArray(materials) || materials.length === 0) {
    throw new TypeError("At least one material is required");
  }
  if (!Number.isInteger(attempts) || attempts < 1) {
    throw new RangeError("Attempts must be a positive integer");
  }
  if (!Number.isInteger(outputsPerSuccess) || outputsPerSuccess < 1) {
    throw new RangeError("Outputs per success must be a positive integer");
  }
  if (
    !Number.isFinite(successChancePercent) ||
    successChancePercent < 0 ||
    successChancePercent > 100
  ) {
    throw new RangeError("Success chance must be between 0 and 100");
  }
  if (!Number.isFinite(valuePerOutput) || valuePerOutput <= 0) {
    throw new RangeError("Output value must be positive");
  }
  if (!Number.isFinite(otherCostPerAttempt) || otherCostPerAttempt < 0) {
    throw new RangeError("Other cost cannot be negative");
  }

  const materialCostPerAttempt = materials.reduce((sum, material) => {
    if (!Number.isInteger(material.quantity) || material.quantity < 1) {
      throw new RangeError("Material quantities must be positive integers");
    }
    if (!Number.isFinite(material.valueEach) || material.valueEach < 0) {
      throw new RangeError("Material values cannot be negative");
    }
    return sum + material.quantity * material.valueEach;
  }, 0);

  const costPerAttempt = materialCostPerAttempt + otherCostPerAttempt;
  if (costPerAttempt <= 0) {
    throw new RangeError("The entered cost per attempt must be positive");
  }

  const p = successChancePercent / 100;
  const expectedSuccesses = attempts * p;
  const expectedFailures = attempts - expectedSuccesses;
  const expectedOutputs = expectedSuccesses * outputsPerSuccess;
  const totalInputValue = attempts * costPerAttempt;
  const expectedGrossValue = expectedOutputs * valuePerOutput;
  const expectedNetValue = expectedGrossValue - totalInputValue;
  const breakEvenChance = costPerAttempt / (outputsPerSuccess * valuePerOutput);

  return {
    costPerAttempt,
    expectedSuccesses,
    expectedFailures,
    expectedOutputs,
    totalInputValue,
    expectedGrossValue,
    expectedNetValue,
    breakEvenChancePercent: breakEvenChance * 100,
    chanceGapPercentagePoints: successChancePercent - breakEvenChance * 100,
  };
}

Material labels, a source label, an “as of” date, and a scenario note do not change the formula. They still belong in the data model because they preserve provenance. A result without a dated source is difficult to reproduce after a game update.

Work a synthetic example by hand

Consider a deliberately fictional recipe:

• 2 units of material A at 10 value units each;
• 3 units of material B at 20 each;
• 20 additional value units per attempt;
• 10 attempts;
• 40% entered success chance;
• 2 outputs per success;
• 80 value units per output.

The material cost is 2 × 10 + 3 × 20 = 80. Including the additional cost gives C = 100 per attempt and 1,000 across the run.

Expected successes are 10 × 0.4 = 4, producing an expected 8 output units. Expected gross value is 8 × 80 = 640, so expected net value is 640 - 1,000 = -360.

The break-even chance is:

100 / (2 × 80) = 0.625 = 62.5%

The entered chance is therefore 22.5 percentage points below break-even. You can reproduce this scenario in the Crafting Expected Value Calculator, which keeps recipe labels, entered values, chance, source date, and assumptions explicit. It does not supply live materials or derive the probability.

Expected value does not describe the next run

Four expected successes does not predict exactly four successes. Under the additional assumptions that attempts are independent and have a constant success probability, the success count is binomial. The NIST/SEMATECH Binomial Distribution reference gives its probability and variance formulas.

For a attempts with probability p:

Var(successes) = a × p × (1 - p)
SD(successes)  = √(a × p × (1 - p))

If each success has declared value uV, then the standard deviation of gross value is uV times the standard deviation of successes. Two recipes can have equal expected net value but very different variability.

Do not apply this extension automatically. A pity system, changing game state, dependent attempts, multiple outcome tiers, or conditional bonuses violates the simple binomial model. In those cases, record the richer mechanics and choose a model that represents them.

Test identities, not just examples

A few invariant-based tests make the implementation harder to break:

import assert from "node:assert/strict";

const result = craftingExpectedValue({
  materials: [
    { quantity: 2, valueEach: 10 },
    { quantity: 3, valueEach: 20 },
  ],
  otherCostPerAttempt: 20,
  attempts: 10,
  successChancePercent: 40,
  outputsPerSuccess: 2,
  valuePerOutput: 80,
});

assert.equal(result.costPerAttempt, 100);
assert.equal(result.expectedSuccesses + result.expectedFailures, 10);
assert.equal(result.expectedGrossValue, 640);
assert.equal(result.expectedNetValue, -360);
assert.equal(result.breakEvenChancePercent, 62.5);

const atBreakEven = craftingExpectedValue({
  materials: [{ quantity: 5, valueEach: 8 }],
  otherCostPerAttempt: 10,
  attempts: 4,
  successChancePercent: 50,
  outputsPerSuccess: 1,
  valuePerOutput: 100,
});

assert.equal(atBreakEven.expectedNetValue, 0);
assert.equal(atBreakEven.chanceGapPercentagePoints, 0);

Also test 0% and 100% probabilities, one attempt, multiple materials, an exact break-even case, a break-even probability above 100%, and invalid negative or fractional quantities.

Prefer sensitivity analysis to false precision

The calculation is deterministic; the inputs are not necessarily trustworthy. When the success chance or output value is uncertain, run low, central, and high scenarios. Compare whether the entered chance remains above break-even in all three cases.

That workflow communicates more than a long decimal. It shows which assumption changes the decision and keeps arithmetic confidence separate from data confidence.

A good crafting calculator should be boring in the best way: explicit inputs, reviewable formulas, reproducible tests, and visible limits. Expected value is a conditional average—not a forecast, recommendation, or guarantee.

References

• OpenStax, Introductory Statistics: Mean or Expected Value and Standard Deviation
• NIST/SEMATECH e-Handbook of Statistical Methods: Binomial Distribution