Node-based progression editor. Cycle detection, multi-stage talents, effect config.
Created a visual editor that eliminated data-entry errors in character progression and let designers iterate on skill trees on their own.
Role: Tools programmer. Team: solo. Duration: 1 month. Platform: Unreal Engine 5. Tools: C++ · Slate · Blueprints.
Problem: Skill trees were spreadsheet data entry. A designer wiring a prerequisite chain could create a cycle, and nothing complained until a player hit it at runtime and the tree deadlocked.
Approach: A node editor that refuses to author an invalid tree, backed by a runtime that is built for lookups rather than for walking the graph the designer drew.
Result: Constant-time talent state lookups during gameplay. Designers balance cost curves and prerequisites without engineering time.
Invalid trees are unauthorable. The validator is the whole point of the plugin. Connection rules are enforced by the graph schema, so a prerequisite that would close a cycle simply cannot be wired, and an impossible chain is caught while the designer is looking at it rather than in a bug report. Everything else here is convenience; this is the part that removed a class of bug entirely.
Author a graph, ship flat arrays. What the designer draws is not what the game walks. The graph compiles to flat runtime structures, and a local player subsystem caches both dependency validation results and a hash of every talent. Checking whether a talent is unlocked during combat is a map lookup, not a traversal, which matters because the UI asks that question for every node on screen every time anything changes.
Talents that upgrade instead of unlock. Most talent systems are binary: locked or unlocked. That forces designers to fake progression by placing three near-identical nodes in a row. Here one talent carries a primary stage plus any number of extra stages, each with its own cost, effect and requirements, so a talent can start cheap and get expensive, or the reverse, without a code change or three duplicated nodes.
Connections that carry meaning. Connection colour and style are driven by unlock state rather than being decoration, so a player reading the tree can see which paths are already paid for and which are still gated. It is a small thing that removed a recurring piece of UI feedback nobody wanted to hand-maintain per tree.