Authoring Errors
Everything on this page is fixable before Play Mode: validation findings, assets missing from databases, broken references, and graphs that are structurally unable to run.
For content authors whose Workbench shows a validation badge, or whose new card exists but refuses to show up anywhere.Authoring errors are the cheap kind: the Workbench can point at most of them before a battle ever runs. The validation badge in the window header is the entry point. Click it, jump to each finding, fix, and repeat until it disappears or only intentional warnings remain.
When you fix by hand, work from the owning asset outward. The diagnosis order rarely changes:
Severity: error vs warning
| Severity | Meaning |
|---|---|
| Error | The content is broken or unsafe to run. Fix it before testing. |
| Warning | Possibly intentional, but worth a decision before testing. |
Treat warnings as intentional only when the design calls for them. A missing reward deck is fine on a rewardless test encounter and wrong on a normal victory flow. The per-mode rules behind each finding are listed in Validation and Where Used.
The asset exists but never shows up
The most common authoring error has no error message at all: a card, status, enemy, or encounter that exists as an asset but appears in no picker and no battle. Content becomes visible to the runtime only through database membership, so check:
- The item is inside the database you think it is in.
- That database is the one assigned to the scene's
GameCardManager. - Demo databases and your project databases are not mixed. Editing a card in one while the scene loads the other produces exactly this ghost.
Broken references
The usual suspects: card artwork or template, status icon, unit prefab, an encounter's player unit or enemy list, a reward deck, or a graph node pointing at content that was deleted.
Repair references through the Workbench pickers rather than by typing names. The pickers only offer content from the active databases, which removes the typo class of bugs entirely. Before renaming or deleting anything shared, check the Used By panel first; it lists every asset that will feel the change.
Incomplete assets
Each content type has a minimum viable shape. The card shell needs a name, an energy cost, a type, and a target mode; a card that should do something also needs a Behavior graph, because a playable card with an empty graph plays fine and does nothing. That "plays but nothing happens" case is almost always graph, not shell.
Statuses need a display name, a Stack Rule, a Decay Rule, and an icon the player can recognize. A status that applies but never changes usually has Decay Rule Never where you meant PerTurn, which is an asset field, not a graph problem.
Enemies need an HP range, a prefab, a Behavior graph with an enemy-turn entry, and intent configuration. An enemy that stands still all battle usually has a graph whose entry never matches the enemy turn.
Encounters need a player unit and at least one enemy; a reward deck if rewards are on. When a scene starts the wrong battle entirely, the encounter is fine and the scene bootstrap points elsewhere.
Graphs that cannot run
Structural graph problems the validation pass and a careful look catch:
- No entry node, or an entry that never fires for this asset kind.
- A control path that dead-ends because a connection was deleted.
- A required target that cannot resolve at run time.
- A result output read by a node that executes before the producer.
- A custom node whose declared output name does not match the name passed to
StoreResult, which makes the port silently produce nothing.
Fix structure before balancing numbers. A perfectly tuned card on a graph that cannot execute is still a dead card.