WARDOGS Bug Reports: Describe the Expected Action and the Result You Observed

Choose the correct kind of feedback

The WARDOGS developer description invites community feedback during Early Access. That does not mean every frustrating outcome is a bug. First decide whether you are describing an interaction that failed, a design preference, a performance problem or another player's behavior.

For a suspected bug, write the action and the result. "Selected the visible option, but the displayed state did not change" is an observation. "The developers intentionally removed my progress" adds a motive that the observation cannot establish. Keep the report anchored to what the interface and gameplay actually showed.

If the issue concerns harassment or suspected cheating, use the game's reporting process rather than presenting it as a general design request. If it concerns a community server's own rule, identify that context. Correct categorization helps the report reach the people who can investigate it and prevents a technical ticket from becoming a mixture of unrelated complaints.

Reduce the example to a usable sequence

List the minimum ordinary steps leading to the problem, including the relevant mode, server or equipment where needed. Include the version and approximate time. Another person should understand where the sequence begins without having to reconstruct your entire session.

For example, a construction interaction report might identify the available option, location and visible response. Do not provide speculative hidden code explanations. The developer can investigate implementation; your stronger evidence is the action and its outcome.

Try a supported reproduction only if it can be done without exploiting the problem, disrupting others or risking additional losses. If a suspected issue gives an unfair advantage, stop using it and report what was observed. BULKHEAD's policy prohibits deliberate exploitation. A good report does not require repeatedly demonstrating a harmful result in live matches or advertising instructions that encourage other players to abuse it.

Record evidence and uncertainty together

A short clip or clear screenshot may show more than a long emotional description, but explain what the viewer should notice. Identify the relevant moment, the expected behavior and the actual result. Avoid sending an unedited recording with no context and assuming support will infer the question.

Include whether the issue happened once or repeatedly. Note conditions you have not tested. "Occurred twice on the same server; other servers not checked" is honest and actionable. Calling the bug universal without those comparisons can send investigation in the wrong direction.

Keep account credentials, private conversations and unrelated personal information out of public reports. Use the official process for any files containing private identifiers. Do not alter evidence to make the result appear more severe. Cropping for clarity is different from removing context that changes what happened; retain the original if support asks for a fuller view through an appropriate private channel.

Make the consequence specific

Explain what the suspected problem prevented: completing an interaction, joining a match, understanding a prompt or continuing a planned team action. Distinguish that consequence from the solution you would prefer. A developer may be able to fix the underlying issue differently from your first suggestion.

For balance feedback, use a concrete scenario and describe the decision that felt unproductive. A request for a broader change is stronger when it explains the gameplay problem instead of listing arbitrary desired values. Avoid presenting a single difficult encounter as proof that an entire equipment category is unusable.

After submitting, keep the case or post reference and add new evidence only when it changes the report. Read later official updates before saying the issue remains current. A useful feedback habit preserves the difference between observation, interpretation and preference. That makes your reports easier to assess and helps you learn from an evolving game without treating every changed result as a newly discovered defect.

Questions that come up