Bug Reporting for Games With Summoning Mechanics

Summoning mechanics spawn autonomous entities that live, act, and die under rules players only half understand. A summon belongs to someone, follows an AI, obeys a cap on how many can coexist, and despawns on a timer or trigger. The bugs are about that lifecycle: a summon that will not appear because the cap was hit, one that lingers after it should die, or one whose AI freezes. A player reporting a misbehaving minion is describing a particular lifecycle and AI state. This post covers capturing the summon, AI, and limit state that makes those bugs reproducible.

A summon is a lifecycle with an owner

Every summon has a beginning, a life, and an end, and bugs cluster at each boundary. At spawn it must pass the summon cap, find a valid position, and bind to an owner. During life it runs an AI, follows or guards, and obeys commands. At the end it despawns on a timer, on the owner's death, or on dismissal. Each transition is a place where state can go wrong: a spawn that silently fails the cap, an owner reference that breaks, a despawn that fires twice or not at all.

Players experience these as a summon that did not appear, vanished early, or stuck around. They cannot see that the cap was full because a previous summon never cleaned up, or that the owner link dangled after a reload. The lifecycle state, how many summons exist, who owns each, and where in its life each is, is invisible from the outside. Without it you are guessing which boundary the bug crossed, and summon lifecycles have a lot of boundaries to guess among.

Capturing summoned entity and ownership state

When a summon report comes in, capture the entity itself: its type, current health and status, position, remaining lifetime, and the owner it is bound to. Then capture the owner side: how many summons the owner currently has, against the cap, and the list of their ids. A failed summon often resolves instantly once you see the owner was already at the cap because a dead summon was never removed from the count, a classic leak that compounds over a session.

Ownership is a frequent failure point, especially across reloads, deaths, and scene transitions. A summon whose owner reference broke may stop responding to commands, attack the wrong faction, or refuse to despawn because the despawn trigger keyed off an owner that no longer exists. Capturing the owner binding and the summon's faction lets you see these dangling-reference bugs directly. A minion attacking its master is incomprehensible until you see the faction or owner field was wrong, and then it is obvious.

AI state of the summon

A summon is only useful if its AI works, and frozen or confused summon AI is among the most reported issues. Capture the AI's current state: its behavior or state-machine node, its current target, its path or destination, and any command queued by the owner. A summon standing still is usually stuck in a state with no valid transition, or pathfinding to an unreachable point, or holding a command it cannot fulfill. The AI state names which of these it is.

Targeting and following are the common AI bugs. A summon that will not attack may have a target it cannot reach, a target filter excluding everything nearby, or a follow state overriding combat. A summon that wanders off lost its owner anchor or its leash radius. Capturing the target, the leash anchor, and the active behavior lets you reproduce the AI's decision context. You set up the same state in a test and watch the AI make the same wrong call, which is far better than poking at behavior trees hoping to provoke the freeze.

Limits, caps, and cleanup

Summon caps and cleanup deserve their own attention because their bugs are cumulative and session-long. If a despawn path ever fails to decrement the count or remove the entity, the cap fills with ghosts and future summons silently fail. This looks intermittent to the player, working early in a session and breaking later, which is the signature of a leak. Capturing the live summon list with each entity's state exposes the ghosts directly: entities that should be gone but still count.

Capture the cleanup triggers too: what was supposed to despawn the summon and whether it fired. Timers, owner death, dismissal, and zone transitions each have their own path, and a bug in one leaves orphans the others do not catch. With the cap count, the live list, and the cleanup triggers recorded, you can tell a genuine despawn bug from a player who simply hit the cap legitimately. The data separates the leak from the limit, which from the outside look identical.

Setting it up with Bugnet

Bugnet captures game state automatically through its in-game report button, which is exactly what summon lifecycles need. When a player reports a summon that misbehaved, you attach the summoned entity's type, health, position, lifetime, and owner binding, the owner's current count against the cap, the live summon list, and the AI state as custom fields. The player describes the misbehavior in a sentence while Bugnet records the lifecycle and limit state that explains it, so a session-long leak does not stay an unreproducible mystery.

Occurrence grouping collapses a recurring leak or AI-freeze bug into one issue with a count, so a problem that quietly degrades many sessions surfaces with real weight. Filter by custom fields like summon type, whether the cap was full, or AI state to find the pattern quickly, and crashes from a runaway summon count arrive with stack traces and device context. The entity states, the caps, the duplicates, and the crashes all sit in one dashboard you can prioritize by how many players a leak actually reached.

Designing summons to be debuggable

The durable practice is to make the summon registry and each summon's AI state queryable at any moment. Keep the live list, the per-owner counts, and each summon's lifecycle and AI node available to the reporter so any summon report carries its full context. Log spawns and despawns with reasons so you can audit cleanup. None of this affects how summoning plays, but all of it turns leaks and freezes from session-long mysteries into traceable events.

Summon systems accumulate complexity as you add types, commands, and interactions, and their bugs accumulate across a session in a way most systems do not. Capture lifecycle and limit state early, and you can add new summon types confident that leaks and dangling owners will show up as data rather than as a slow degradation players quit over. Build the registry snapshot now, and your summons will stay reliable companions instead of becoming the thing that fills every late-game session with ghosts.

Summon bugs are lifecycle bugs. Capture the entity state, owner binding, AI node, and live cap list and a session-long leak becomes a traceable event.