Representing Roguelite Build Effects Without Hard-Coding Every Combination

Build planners for roguelites become fragile when every effect is encoded as a special case. Pass the Fear is a useful example: characters, weapons, relics, tarot cards, battle scars, skill nodes, and weapon parts can all change a run. The combinatorial space grows too quickly for a long chain of if statements.

Describe effects as data

Start with stable IDs and a small vocabulary of operations. A relic effect could be represented as:

{
  "sourceId": "relic-example",
  "trigger": "on_hit",
  "operation": "multiply",
  "stat": "damage",
  "value": 1.15,
  "conditions": ["target_burning"]
}

The public relic directory remains readable for players, while the structured record can be evaluated by tools. The same approach works for the weapon database, where base stats and upgrade effects should be stored separately.

Define an evaluation order

The hard part is not storing a 15% bonus. It is deciding when that bonus applies. A deterministic pipeline might be:

1. load character base stats;
2. apply permanent skill-tree modifiers;
3. apply weapon and part modifiers;
4. apply relic and tarot modifiers;
5. evaluate battle-scar tradeoffs;
6. calculate conditional effects for the selected scenario.

Writing the order down prevents two UI screens from producing different totals. It also makes balance patches easier to test.

Keep provenance with every fact

Every value should include a source version or verification note. When a patch changes a weapon, the system can flag builds that still depend on an older value instead of silently returning a plausible but incorrect result.

A character directory can expose role and starting-kit data, while the skill tree supplies node-level modifiers. The records stay independent but join through stable IDs.

Make the planner explain itself

A useful build planner should show more than a final score. It should list which sources changed damage, cooldown, survivability, or status effects and in what order. Explainable calculations help players notice mutually exclusive choices and assumptions.

Design for discovery

The main Pass the Fear Wiki ties the systems together, but each tool and directory should link back to the underlying entities. That creates a navigable knowledge graph for players and keeps the site maintainable.

The general lesson is to treat game effects as composable data, define evaluation order explicitly, and preserve provenance. Then adding a new relic or weapon becomes a content update instead of another hard-coded branch.