Bug Tracking for Co-op Campaign Games

Co-op campaign games promise that a group can play through a story together and keep their progress, which sounds simple and is anything but. Underneath sits a host-client model where one machine is usually authoritative, shared state like quest progress and unlocks has to stay consistent for everyone, and players can drop in and out mid-session without breaking the world. The bugs cluster exactly there: progress that saves for the host but not the guest, a player who joins and finds the world in the wrong state, ownership of an object that gets confused when its owner leaves. Tracking these means capturing the session topology and the shared state. This post explains what to log.

Shared progress is the thing that breaks

The defining feature of a co-op campaign is shared progress, and it is the feature most likely to fail. A quest completes on the host's machine but the guest's journal never updates, an unlock that should apply to everyone only sticks for one player, or two players each think they hold the single key item the story expects to exist once. These are state-consistency bugs: the shared world model diverged between clients, and because each player only sees their own copy, the group experiences the same campaign moment differently and cannot agree on what actually happened.

To debug shared progress you need the campaign state from each participant at the moment of the report, not just the host's. Capture the quest flags, unlocks, and key inventory from every connected client so you can diff them and see exactly where they disagree. A report that progress did not save becomes precise when you can see the host advanced a flag the guest never received, pointing at a replication or save-merge bug. Shared progress is bookkeeping across machines, and you cannot reconcile the books without reading every copy.

Host-client authority and who owns what

Most co-op campaigns designate one machine, usually the host, as authoritative over the shared world, with guests sending intentions and receiving results. Bugs creep in around ownership: which client simulates a given enemy, who owns a dropped item, who is allowed to advance a scripted sequence. When authority is ambiguous or duplicated, you get doubled pickups, an enemy that exists on one screen and not another, or a cutscene that triggers for the host while the guest stands in an empty room. The authority model is invisible to players but it is the backbone of every consistency guarantee.

Capture the authority topology in your reports: who was host, which client owned the object or sequence in question, and what each side believed its state was. With that you can see that a duplicated item came from both clients spawning it because ownership was never assigned, or that a stuck cutscene waited on the host while the guest's trigger fired locally and desynced. Ownership bugs are slippery because they depend on the runtime session layout rather than the map, so the session topology is exactly the context a report needs to be reproducible.

Drop-in and drop-out are the hard part

Letting players join and leave mid-session is where co-op campaigns earn their bug reports. A joining player has to be brought up to the current shared state, every relevant flag, the right position in the level, the correct unlocks, and any partial step of a quest, and if the state transfer misses something, they arrive into a subtly broken world. Leaving is just as dangerous: when a player disconnects, everything they owned, units, the host role itself, a quest they were carrying, has to be reassigned cleanly or the session is left with orphaned state.

These join and leave moments are timing-sensitive and order-dependent, which makes them brutal to reproduce from a description. So log the join and leave events with timestamps and the state-sync payload that accompanied a join, plus what was reassigned on a leave. A report that joining mid-mission broke things becomes tractable when you can see the join sync omitted a quest flag, or that a host migration after the host left never transferred ownership of an active objective. Capturing the session timeline turns these ghostly, intermittent bugs into a sequence you can replay deliberately.

Saving and resuming a shared campaign

Co-op campaigns usually persist between sessions, which adds a saving and loading dimension to every consistency problem. The save typically lives on the host, so a guest who played for hours can lose their sense of progress if the host saves a state that never fully merged the guest's contributions, or if the group resumes from the host's file while a guest expected their own. Loading a shared save also has to rebuild the session correctly, restoring quest flags, unlocks, and positions for players who may join in a different order than last time.

So capture the save's shared state and which client it came from when a resume goes wrong, alongside what each player expected the loaded progress to be. Diffing the loaded campaign state against each participant's memory of where they left off exposes whether the save dropped a guest's progress or restored an inconsistent world. Because saves are the authoritative record of a campaign, a save-merge bug quietly compounds across sessions until the group's progress no longer matches anyone's experience, so capturing the saved state on resume reports is what keeps that drift from going unnoticed.

Setting it up with Bugnet

Bugnet's in-game report button can attach the session context that co-op bugs require. Put the player's role, host or guest, into a player attribute, push the shared campaign state and that client's ownership view into custom fields, and include the recent join and leave events with their timestamps. A report then arrives carrying the session topology and the shared state, so when a guest says progress did not save, you can diff their captured campaign state against the host's and see the exact flag that failed to replicate, rather than trading messages about what each friend remembers happening.

Because the same sync or join bug tends to hit many groups, Bugnet's occurrence grouping folds the duplicate reports into one issue with a count, telling you which consistency failure is breaking the most sessions. Filtering by role shows whether a bug only affects guests, which is a strong hint it lives in replication rather than core logic. Crashes during a host migration or a mid-session join arrive with stack traces and platform context, so the fragile connection-time code paths that only break under specific topologies are easy to localize from one shared dashboard.

Testing real session topologies

The co-op teams that ship stable campaigns test the messy session shapes deliberately rather than only the happy path of everyone starting together. Build automated multiplayer tests that start a host, join a guest mid-mission, advance shared progress, drop a player, migrate the host, and assert the shared state stays consistent across every client through all of it. Seed these with the real drop-in and host-migration bugs your players report, so each fragile topology that broke once becomes a permanent regression guard against breaking again in a later build.

Make state consistency something you assert, not something you hope for. Add checks that periodically compare shared progress across clients during a session and flag any divergence the instant it appears, the co-op equivalent of a desync detector, so a replication gap is caught in testing rather than in a player's confused report. With session topology and shared state captured on every report and a test suite that exercises joining, leaving, and migration, the promise that a group can play and keep their progress together stops being fragile and starts being something you can actually stand behind.

Co-op campaign bugs live in shared state and session topology. Capture who was host, each client's state, and the join and leave events, and divergence is easy to spot.