DEV Community: Rowan Vale

Representing Roguelite Build Effects Without Hard-Coding Every Combination

Rowan Vale — Wed, 29 Jul 2026 10:58:19 +0000

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:

load character base stats;
apply permanent skill-tree modifiers;
apply weapon and part modifiers;
apply relic and tarot modifiers;
evaluate battle-scar tradeoffs;
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.

Modeling Crafting Dependencies for a Scrap Mechanic Planner

Rowan Vale — Wed, 29 Jul 2026 10:55:31 +0000

Crafting-heavy games look simple until a player asks a practical question: “What do I need to build this machine, including every intermediate part?” At that point a recipe list becomes a dependency-graph problem. Scrap Mechanic is a useful case study because its parts, Craftbot recipes, upgrade chains, crops, and survival raids all affect planning.

Model recipes as directed edges

Each craftable output should point to its ingredient requirements, while every ingredient should have a stable item ID. A compact representation might look like this:

{
  "outputId": "controller-level-3",
  "quantity": 1,
  "station": "craftbot",
  "ingredients": [
    {"itemId": "component-kit", "quantity": 4},
    {"itemId": "circuit-board", "quantity": 6}
  ]
}

A public parts database can render the readable item pages, but the same records should power a crafting reference and any planning tools.

Expand dependencies recursively

A crafting planner can walk the graph until it reaches raw resources. The important details are:

multiply ingredient quantities by the requested output count;
merge repeated materials after expansion;
detect cycles or invalid recipes;
preserve station requirements;
let players mark inventory they already own.

Memoizing each expanded recipe keeps large plans responsive. It also makes the calculation deterministic enough to test with fixtures whenever a game update changes recipe data.

Keep blueprint analysis separate

A blueprint analyzer has a different input grain. It starts with a serialized creation, counts parts by UUID, and joins those IDs back to the item database. Keeping this parser separate from the recipe graph makes both systems easier to validate.

The useful output is not only total block count. Mass, component categories, controller usage, bearings, pistons, and missing or modded UUIDs help a builder understand why a creation behaves the way it does.

Treat raids as another calculator

Survival planning also depends on farm value and timing. A raid calculator can translate planted crops into an expected raid level, then explain the thresholds instead of presenting a mystery number.

One source, several interfaces

The main Scrap Mechanic Wiki connects these views, but the architecture works because the tools do not maintain competing copies of the same facts. Normalize item IDs, version the source data, validate every relationship, and generate player-facing tools from that shared model.

That pattern applies well beyond one game: dependency graphs are the right abstraction whenever crafting, upgrades, and inventories overlap.

Designing a Data-First Companion Wiki for DragonSword: Awakening

Rowan Vale — Wed, 29 Jul 2026 10:46:36 +0000

A game wiki becomes much more useful when it is treated as a small data product instead of a stack of prose pages. DragonSword: Awakening is a good example because its 19 playable heroes, Tag-team interactions, upgrade materials, and exploration data all overlap.

Start with a normalized content model

I would keep heroes, roles, elements, skills, materials, recipes, and map locations as separate entities, then connect them through stable IDs. That avoids copying the same material or skill data into multiple pages and makes later balance updates less error-prone.

A hero record can stay small:

{
  "id": "hero-slug",
  "role": "breaker",
  "element": "fire",
  "tagTriggers": ["launch", "stun"],
  "materialIds": ["mat-a", "mat-b"]
}

The public hero directory is the human-readable view, while the same relationships can drive filters and comparison tools.

Build tools from the same source

Once the content is normalized, a team builder should not need a second hand-maintained dataset. It can derive role coverage, Tag-chain compatibility, and missing support functions from the hero records.

The same principle applies to a material planner: let users select upgrade goals, aggregate required items by ID, and show which requirements are shared across heroes. This is more useful than forcing people to maintain a spreadsheet beside the wiki.

Treat maps as structured data

An interactive map works best when each marker stores a type, region, coordinates, prerequisites, and source notes. That makes filtering and later validation much easier than embedding coordinates directly in presentation code.

Design for discovery

The main DragonSword: Awakening Wiki links the datasets and tools together, but every entity page should also provide contextual links back to related heroes, items, bosses, or locations. This helps both players and crawlers discover the graph naturally.

The broader lesson is simple: store facts once, derive tools from the same model, and make every useful record reachable from navigation and search. A companion site built this way can survive patches without turning each update into a manual rewrite.