How to Set Up Bug Reporting for Game Demos

A game demo is a job interview. Players spend five to fifteen minutes deciding whether your game is worth their wishlist, their money, and their time. A crash during those minutes is not just a bug — it is a lost customer. Yet most indie developers ship demos without any crash reporting, relying on Discord messages and Steam forum posts to learn about problems. By the time you hear about a critical crash through manual channels, hundreds of potential players have already bounced.

Why Demos Need Bug Reporting More Than Full Releases

The stakes in a demo are higher than in a full release. A player who bought your game will tolerate some bugs because they are already invested. A demo player owes you nothing. One crash and they close the game, never wishlist, and forget about it. You will never know they existed.

Demos also run on hardware you have never tested. Your development machines and your QA team’s machines are a tiny, non-representative sample of the hardware diversity in the wild. Steam Next Fest alone can bring tens of thousands of players across every GPU generation, CPU architecture, and driver version imaginable. Without crash reporting, you are blind to compatibility issues that may affect a large portion of your potential audience.

The third reason is timing. Demo events are time-limited. Steam Next Fest runs for one week. If a critical crash affects 20% of players on AMD GPUs and you do not discover it until day five, you have wasted four days of your most important marketing window. Real-time crash reporting lets you discover, diagnose, and hotfix critical issues within hours.

Choosing and Integrating an SDK

For demo builds, the SDK needs to be lightweight, easy to integrate, and low-friction for the player. The player should never have to fill out a form or create an account to submit a bug report. Crash reports should be sent automatically and silently. Manual bug reports should be one click or one keyboard shortcut.

Bugnet’s SDK is designed for this use case. It adds under 500KB to your build size and sends reports asynchronously on a background thread. Integration takes under ten minutes for most engines.

# GDScript (Godot) - Minimal demo integration
# 1. Add the Bugnet SDK to your project
# 2. Initialize in your autoload

func _ready():
    Bugnet.init("your-project-key")
    Bugnet.set_metadata("build_type", "demo")
    Bugnet.set_metadata("build_version", "demo-2026.04")
    Bugnet.set_metadata("event", "steam-next-fest-apr-2026")

# 3. Add a bug report hotkey (optional but recommended)
func _input(event):
    if event.is_action_pressed("report_bug"):
        Bugnet.show_report_dialog()  # In-game overlay

// C# (Unity) - Minimal demo integration
void Start()
{
    Bugnet.Init("your-project-key");
    Bugnet.SetMetadata("build_type", "demo");
    Bugnet.SetMetadata("build_version", "demo-2026.04");
    Bugnet.SetMetadata("event", "steam-next-fest-apr-2026");
}

void Update()
{
    if (Input.GetKeyDown(KeyCode.F8))
        Bugnet.ShowReportDialog();
}

Tag every report with build_type: demo so you can filter demo bugs separately from development builds. If you participate in multiple events, add an event tag to distinguish Steam Next Fest crashes from PAX demo crashes from press preview crashes. This metadata is free to add and invaluable for filtering.

Demo-Specific Telemetry

Beyond crashes and bugs, demos benefit from lightweight session telemetry. You want to know how far players get, where they drop off, and whether your demo delivers the experience you intend. This data complements bug reports by showing you the context around problems.

Track these events at minimum:

• Session start and end — How long did the player engage? A median session under two minutes suggests a critical early-game problem.
• Demo completion — What percentage of players reached the end of the demo content? Low completion rates may indicate bugs, difficulty spikes, or confusion.
• Checkpoint progression — Define three to five milestones in your demo (finished tutorial, beat first boss, reached area 2). Track how many players reach each one. A sharp drop-off between two checkpoints points to a problem in that section.
• Wishlist button clicks — If your demo has a “Wishlist on Steam” button, log when players click it. This is your conversion event.

Cross-reference telemetry with bug data. If players who encounter a specific bug have a 60% lower wishlist rate than players who do not, that bug is directly costing you conversions and should be prioritized above all non-crashing issues.

Setting Up Alerts for Demo Events

During a demo event, you need to know about critical issues in real time. Set up alerts that notify you via Discord, Slack, or email when crash rates spike. Define thresholds before the event starts so you are not scrambling to configure alerts while players are crashing.

Recommended alert thresholds for demo events:

• Crash rate above 5% — More than 1 in 20 sessions crashing. This is an emergency. Investigate immediately and consider pushing a hotfix.
• New crash signature — A crash that has not been seen before in testing. It may be hardware-specific. Check the device metadata for patterns (all AMD, all Linux, all integrated GPUs).
• Crash count above absolute threshold — If more than 50 total crashes occur in an hour, something is wrong regardless of the rate. This catches issues even when session volume is high enough to keep the rate low.

During the event, assign someone on the team to monitor the bug dashboard. This does not have to be a full-time role — checking once every two hours is sufficient if alerts are configured properly. The goal is to catch critical issues within a few hours, not a few days.

Post-Demo Analysis

After the demo event ends, the data you collected becomes a goldmine for pre-launch planning. Export all crash reports, bug submissions, and telemetry events. Group crashes by hardware configuration to identify platform-specific issues you need to fix before launch. Analyze session drop-off patterns to find where the player experience breaks down.

Pay special attention to the bugs that were reported multiple times by different players. If twenty players independently report the same issue, it is something prominent in the experience, not an edge case. These are your highest-priority launch fixes.

Finally, compare bug encounter rates with wishlist conversion. If you can demonstrate that fixing the top three demo bugs would have increased your wishlist rate by a measurable percentage, you have a data-driven argument for prioritizing those fixes over new feature work in the lead-up to launch. That kind of evidence is hard to argue with, even when the team is eager to move forward.

Every demo crash is a lost wishlist. Instrument before you ship.