How Game Studios Use Custom Fields in Bug Reports

This guide covers how game studios use custom fields in bug reports in detail. A bug report that says “the game crashed” is almost useless. A bug report that says “the game crashed on level 7, during the boss fight, at 15 FPS, on a GTX 1650 with 8 GB RAM, while the player had the fire shield equipped and was on quest step 3 of 5” is actionable. The difference is custom fields. This guide covers why default bug fields fall short for games, which custom fields provide the most value, and how to set them up so they populate automatically.

Why Default Bug Fields Fall Short

Every bug tracker gives you the basics: title, description, severity, priority, assignee, status. These work fine for web applications where a URL and a screenshot capture most of the context. Games are different.

A web app has a predictable state at any given URL. A game has a complex, dynamic state that varies enormously between players. Two players on the same level can have completely different experiences based on their equipment, progression choices, hardware capabilities, and the specific combination of systems active at the time of the bug.

When a developer gets a bug report with only the default fields, their first action is always to ask for more context: “What level were you on? What were you doing? What hardware are you using? Can you send your save file?” This back-and-forth delays the fix by hours or days. Custom fields eliminate this round-trip by capturing the context upfront.

The key insight is that most of this context can be captured automatically by the bug reporting SDK at the moment the report is submitted. The player does not need to know their GPU model or their exact quest state—the game client already has this information.

Essential Custom Fields for Every Game

Based on patterns across hundreds of game studios, these are the custom fields that provide the most value in almost every game project:

Build version (string): The exact game build. Not just “v1.2” but the full build identifier like 1.2.0-build.4523. This tells you immediately whether a bug has already been fixed in a newer build. Auto-capture this from your build system.

Scene or level name (string): The active scene or level when the bug was reported. In Unity, this is SceneManager.GetActiveScene().name. In Godot, get_tree().current_scene.name. In Unreal, GetWorld()->GetMapName().

Player level or progression (number): Where the player is in the game. This can be a literal character level, a story chapter number, a completion percentage, or a combination. Make it a number so you can filter and sort.

Hardware: GPU (string): The graphics card model. Many rendering bugs are GPU-specific. Auto-capture this with SystemInfo.graphicsDeviceName in Unity or OS.get_video_adapter_driver_info() in Godot.

Hardware: RAM (number): Total system memory in MB. Memory-related crashes correlate strongly with available RAM.

FPS at time of report (number): The frame rate when the player hit the report button. Low FPS bugs are a different category from bugs at normal frame rates.

// Unity: Auto-capture custom fields for bug reports
public Dictionary<string, object> GetBugReportContext()
{
    return new Dictionary<string, object>
    {
        ["build_version"] = Application.version,
        ["scene"] = SceneManager.GetActiveScene().name,
        ["player_level"] = PlayerData.Instance.Level,
        ["gpu"] = SystemInfo.graphicsDeviceName,
        ["ram_mb"] = SystemInfo.systemMemorySize,
        ["fps"] = Mathf.RoundToInt(1f / Time.deltaTime),
        ["platform"] = Application.platform.ToString(),
        ["os"] = SystemInfo.operatingSystem,
        ["play_time_minutes"] = Mathf.RoundToInt(Time.realtimeSinceStartup / 60f)
    };
}

Game-Specific Custom Fields

Beyond the universal fields, different game genres benefit from genre-specific context:

RPGs and adventure games: Current quest ID, quest step, equipped items, active buffs/debuffs, party composition, inventory state. Quest bugs are notoriously hard to reproduce without knowing exactly where the player was in the quest chain.

Multiplayer games: Network latency (ping), server region, player count in session, match type, time elapsed in match, player role/class. Networking bugs depend heavily on connection quality.

Open world games: Player world coordinates (x, y, z), current biome or zone, active world events, number of NPCs nearby, loaded chunk count. Knowing the exact position lets developers teleport there instantly.

Mobile games: Battery level, thermal state, device model, screen resolution, available storage. Mobile bugs often correlate with thermal throttling or low storage conditions.

# Godot: Auto-capture RPG-specific context
func get_bug_context() -> Dictionary:
    var player := GameState.get_player()
    return {
        "build": ProjectSettings.get_setting("application/config/version"),
        "scene": get_tree().current_scene.name,
        "player_level": player.level,
        "player_position": "%s, %s" % [player.global_position.x, player.global_position.y],
        "current_quest": QuestManager.active_quest_id,
        "quest_step": QuestManager.current_step,
        "equipped_weapon": player.weapon.resource_name if player.weapon else "none",
        "gold": player.gold,
        "play_time_sec": int(Time.get_ticks_msec() / 1000),
        "fps": Engine.get_frames_per_second()
    }

Structured vs Freeform Data

A common mistake is making custom fields freeform text when they should be structured. Freeform text is useful for the player’s description of what happened, but everything the game captures automatically should be structured.

Use enum fields for values that come from a known set: difficulty level (easy/normal/hard), game mode (campaign/multiplayer/sandbox), platform (windows/mac/linux/android/ios).

Use number fields for anything measurable: player level, FPS, RAM, latency, play time, coordinates. Numbers are filterable, sortable, and can be aggregated into charts.

Use string fields for identifiers: build version, scene name, quest ID, session ID, GPU name. These are searchable and groupable.

Use boolean fields for feature flags: is_fullscreen, has_mods_enabled, is_using_controller, is_in_combat.

Structured data lets you answer questions like “how many crash reports come from players with less than 4 GB RAM?” or “are all reports of quest 7 failing from players who completed quest 3 via the alternate path?” Freeform text cannot answer these questions without manual reading.

Filtering and Querying by Custom Fields

Custom fields become truly powerful when you can filter your bug database by them. Instead of reading through hundreds of reports, you can narrow down to exactly the bugs that match a specific pattern.

Common filter workflows:

After a patch release: Filter by build_version = 1.3.0 to see only bugs reported on the new build. Compare crash rates between 1.2.9 and 1.3.0.

GPU-specific rendering bugs: Filter by gpu CONTAINS "Intel" to find all reports from integrated graphics. These often share the same root cause.

Quest progression bugs: Filter by current_quest = "quest_007" and quest_step = 3 to find all reports of the same quest step failing.

Performance issues: Filter by fps < 30 to find all low-performance reports and look for patterns in hardware or scene names.

Bugnet supports custom fields that you can define per project and filter in the dashboard. The API lets you attach custom fields when submitting bug reports programmatically from your game client.

“The bug reports that get fixed fastest are the ones that give the developer everything they need to reproduce the issue without asking a single follow-up question. Custom fields, captured automatically by the game client, are how you achieve that.”

Related Issues

For reducing the volume of duplicate bug reports that custom fields help you identify, see Reducing Duplicate Bug Reports in Game Development. For setting up automated bug reporting in your game engine, check Bug Reporting SDK Integration Guide. For a broader look at bug triage workflows that leverage custom field data, read Bug Triage Meeting Guide for Game Teams.

Every back-and-forth message asking a player for more context is time wasted. Capture build version, scene, hardware, and game state automatically. Make the fields structured so you can filter, sort, and spot patterns at scale.