Define a build as an engine
A build is not merely a list of spells that share a theme. Start with a core action, identify what triggers from it, show which attributes improve the resulting effects, and state what resource or board condition is required to begin. Then add protection against the situations where that loop cannot start or cannot affect the target. This engine model matches the official promise of new spell and equipment combinations each run better than a fixed class loadout.
Write the build in one sentence before spending heavily: “I use this action to trigger that payoff, and these tags let my bonuses reach both.” If the sentence needs several unrelated “and then” clauses, the plan may be collecting pieces without a reliable loop. Equipment can contribute direct attributes or event-triggered effects, so it belongs in the engine diagram rather than in a separate pile of upgrades; current exact costs, damage, duration, and trigger wording must come from the live tooltip because the August 31 patch changed many systems.
Connect attributes, bonuses, and tags
The developer-recommended teaching video separates build reasoning into attributes, bonuses, and tags. A bonus helps only an attribute to which it applies, while tags describe the scope that can receive the bonus. Adding a tag can therefore open another support path, but only if the current tooltip confirms the interaction. Do not assume two effects synergize because their names sound related or because an older video showed a particular value.
Audit each candidate piece by tracing a complete connection from source to recipient. Name the affected attribute, the bonus that changes it, and the tag or condition that permits the connection. If one link is missing, treat the synergy as 待确认 until the game interface demonstrates it. This prevents expensive purchases that decorate the theme without increasing the engine’s output, uptime, safety, or coverage.
Fill six functional slots
A practical build sheet has six jobs: core action, trigger chain, scaling coverage, startup resources, mobility or defense, and resistance coverage. One spell or item can fill several jobs, and that compression is often more useful than adding another isolated payoff. The sheet also exposes what is absent before a difficult rift makes the absence fatal. It is a planning tool, not a claim that every successful run uses exactly six purchases.
- Core action: the cast, summon, movement, or other repeatable event that begins the loop.
- Trigger chain: the effect that converts the core action into damage, bodies, control, healing, or further casts.
- Scaling coverage: the confirmed attributes, bonuses, and tags that reach the important outputs.
- Startup: the charges, health, components, positioning, or turns needed before the engine becomes useful.
- Mobility and defense: the answer when enemies threaten the wizard before the loop resolves.
- Resistance coverage: an alternate type, debuff, control effect, or summon for a poor matchup.
Review the six jobs before and after every major purchase. If startup is already slow, another long-horizon scaling piece may be worse than a tool that buys one safe turn. If one resistance stops the whole loop, more same-type damage does not repair the problem. No source supports universal thresholds for how much coverage or defense is enough, so those exact breakpoints remain 待确认.
Read player builds as dated cases
The June builds discussion reports several different engines, including Flesh Fiend and Devour, Slime Bounce with Annihilator Staff, Storm Drakes with Dragon Mage, summoned blades, and fire-enchantment ideas. These are pre-main player reports and demonstrate variety, not a ranking or guaranteed recipe. Claims such as “strongest” or “clears the whole run” belong to individual commenters and have no controlled sample behind them. Use the list to learn how players connect triggers, then confirm every component in the current client.
The July Flesh Fiend guided run is also pre-main and shows a more useful analytical pattern. Its author starts with Flesh Fiend and Devour Flesh, connects blood-related casting and recovery, looks for cross-tag support, and openly notes startup demands and turn-efficiency weaknesses. That makes it a case in core loop, startup condition, shortcoming, and patch rather than a current exact recipe. Its historical numbers and precise life or charge cycle are 待确认 after the main merge.
The September 12 report is explicitly post-main and describes a player changing direction after an initial Slime Striders idea. The later engine used Sorcery boots, a step-triggered burst, an Earthquake upgrade, and movement or quickstep support, while the player reports losing once to positioning and succeeding on a second attempt. This supports the lesson that movement, defense, and failure correction belong inside build design. It does not establish that the route is foolproof, best-in-slot, or reproducible across seeds.
Pivot when evidence breaks the plan
Pivot when the run cannot supply the startup piece, the next rifts expose a hard resistance, or a new component creates a cleaner trigger chain. A pivot does not require discarding everything; preserve pieces that still fill a functional slot and replace the disconnected assumption. The official open purchasing and crafting structure makes this incremental adjustment part of normal play. Chasing a named build despite missing drops turns a learning template into a brittle prescription.
Set a pivot checkpoint before spending the next scarce resource. Ask whether the engine works now, what it still needs, and whether the available reward solves that need or starts a separate engine. If a second plan uses the existing tags, defense, or positioning tools, it may be cheaper than waiting for one exact item. Universal pivot timing is 待确认, because the sources provide examples rather than a current probability model for drops.
Diagnose failure by the broken link
When a build fails, locate the first broken link rather than labeling the whole idea weak. A slow start points to resources or setup turns, an immune target points to coverage, repeated exposure points to mobility or defense, and empty charges point to uptime. A component that never appears is a routing constraint, while a component that appears but adds no value may reveal a misunderstood tag. This diagnosis produces a concrete change for the next run.
Keep version labels beside every copied example. The two teaching videos and the June discussion are pre-main, the September 12 report is post-main, and the official August 31 notes define the dividing line used here. There is no current official build database, tier list, same-seed comparison, or reliable win-rate sample in this evidence chapter. The honest goal is a well-explained engine with visible weaknesses, not a claim that one build is optimal for every run.