Bug Reporting for Games With Karma and Reputation

Reputation and karma systems make the world remember what players do. Help a town and merchants offer discounts; raid a caravan and guards attack on sight. The promise is consequence, and when it breaks, players lose trust in the whole world: a faction turns hostile for no reason they can recall, a quest that should be available stays locked, or a single kill tanks standing with an unrelated group. Each faction tracks a value moved by tagged events, with thresholds that gate hostility, prices, and content. The bugs live in those value changes, the threshold checks, and how factions influence one another. This post is about capturing reputation state so a standing report names the event or threshold that misfired.

Reputation is a ledger, and ledgers get bad entries

A reputation system is essentially a ledger: each faction has a running balance, and events post credits and debits to it. Helping a quest adds standing, attacking a member subtracts it, and the current value is the sum of all those entries. Bugs are bad ledger entries: a debit posted to the wrong faction, a value applied twice, a change with the wrong sign, or an event that should have been neutral posting a large penalty. The player only sees the resulting balance and the consequence, so they report a faction is hostile, while the cause is one bad entry somewhere in the history.

Because the value accumulates over a long playthrough, these bugs are hard to trace after the fact. A player who is suddenly hated by a faction cannot tell you which of hundreds of actions caused it, and you cannot know without the change history. Capturing not just the current value but a log of recent reputation changes with the event that caused each one turns the ledger transparent. You can scroll the history and find the entry that does not belong, which is the only practical way to debug an accumulated value that took an entire session to go wrong.

The reputation state to capture

Capture the current standing for each relevant faction, the thresholds that define hostile, neutral, and friendly bands, and a log of recent reputation changes with the amount, the sign, the faction affected, and the event or action that triggered each change. With the change log you can audit the balance: do the recent changes sum to a movement consistent with the current value, and is each change attributed to a sensible cause? A large negative change tagged to an event that should be harmless is the bad entry, and it is visible the instant you read the log.

Capture the faction relationship map too, because many reputation systems propagate changes across allied and opposed factions. Helping one group should lower standing with their enemies, and a bug in that propagation can swing an unrelated faction. Recording which factions a change propagated to, and by how much, exposes propagation bugs that would otherwise look like a value changing on its own. Without the relationship context, a faction turning hostile because you helped its rival looks like a phantom change, when in fact it is a propagation rule firing more strongly than intended.

Value change bugs and double counting

The most common reputation bug is a value change applied incorrectly. A quest reward granted twice because two code paths both award it, a penalty with a flipped sign that raises standing for a hostile act, or a change scaled by the wrong multiplier. These produce standing that does not match player expectation, and they are invisible without the change log because the final value looks plausible even when it was reached by a wrong path. Capturing each change as a discrete entry lets you spot a duplicate by seeing two identical entries from the same event.

Sign errors deserve special attention because they are easy to make and confusing to experience. A debit written as a credit means betraying a faction improves your standing with them, which players will happily exploit and rarely report as a bug. Capturing the sign and amount of each change alongside a description of the action makes these obvious during review, even when no player flags them, because helping action paired with a negative change or a hostile action paired with a positive change jumps out of the log. The ledger view makes the system auditable in a way a single number never can.

Threshold gates and locked content

Reputation gates content: a merchant unlocks better stock at friendly, a faction turns hostile below a threshold, a quest requires a minimum standing. These gates are threshold comparisons, and they break the same way all threshold checks do, by reading a stale value or comparing against the wrong band boundary. A player who has clearly earned friendly standing but cannot access the gated content is hitting a check that read an outdated value or used the wrong threshold constant. Capturing the value the gate evaluated next to the threshold it required confirms the mismatch directly.

Hostility thresholds cause the most dramatic reports because crossing one flips every faction member to attack. If the threshold check uses a value that has not refreshed after a recent positive change, a player who just made amends still gets attacked, which feels deeply unfair. Capturing whether the hostility evaluation ran against the current value, and what band it concluded, separates a genuine low standing from a stale read. A faction marked hostile in the report while the captured standing sits in the neutral band means the band classification did not update, which is a refresh bug, not the player earning the hostility.

Setting it up with Bugnet

Bugnet's in-game report button captures game state automatically, so a reputation report arrives with the standing values and change history attached rather than a player guessing why a faction hates them. Serialize reputation into custom fields: per faction current standing, the threshold bands, the recent change log with amount, sign, faction, and triggering event, and the faction relationship map with propagation amounts. When a report says guards attacked me for no reason, you open it and the change log shows a large negative entry tagged to an event that should have been neutral, naming the bad ledger entry.

Occurrence grouping folds matching reputation reports into one issue with a count, so a mis tagged event tanking standing for many players surfaces as a single prioritized entry rather than scattered confusion. You can filter by the faction custom field to find every report touching one group, and scan the change logs across reports to find a recurring bad entry from the same event. With the standings, the change history, and the relationship map in one dashboard, an accumulated value bug that would otherwise be untraceable becomes a quick audit of the ledger the player could never see.

Testing reputation as a ledger

The durable defense is testing reputation as the ledger it is. Write tests that apply a sequence of tagged events and assert the resulting standing matches the expected sum, with each change posted once, with the correct sign, to the correct faction. Test propagation by applying a change to one faction and asserting allied and opposed factions move by the configured amounts and no more. Because your reports serialize the change log, any suspicious history replays into a test that asserts the same sequence produces the intended standing, locking the fix in as a regression.

Test the gates explicitly: set standing just inside and just outside each band boundary and assert hostility, dialogue, and content gate correctly, with the value read fresh so stale reads cannot pass. The teams that ship reputation systems players trust are the ones who can audit the full change history and the relationship map at any moment, rather than inferring intent from a single standing number. When the ledger is observable and tested, the faction that turns hostile for no reason becomes a single bad entry you can point to, and the world keeps its memory consistent.

Reputation is a ledger. Capture the change history, not just the balance, and the faction that hates you for no reason reveals the one bad entry.