PROPOSED PROJECT
Game Bug Tracker
Turn game-test recordings, player reports, and error records into a clear bug list. Group duplicate reports, link each issue to the relevant video moment and error, and draft steps for testers to recreate it and assign it to the right team.
The key is there. The gate stays locked.
Draft issue G-018
Windows / build 1.8.0
Turn “it broke”
into a bug someone can reproduce.
The fictional adventure Tidekeeper has four test reports. PT-041 and PT-057 both show a collected harbor key failing to open the gate after a save is loaded in Windows build 1.8.0. PT-060 reports a similar symptom on Android but has no recording or events, so it stays an unconfirmed match. PT-063 concerns missing harbor audio and stays separate. An authored event sequence shows the key in inventory while the restored unlock flag is false. The artwork, records, and timing are illustrative; no actual game or recording was analyzed.
WHAT IS USUALLY DONE
Testers file the same blocked quest in different words, attach long recordings, and paste partial errors into separate tickets. Someone must replay each session, find the failure, and work out whether the reports describe the same issue. A similar symptom on another platform may get merged before anyone checks it.
WHAT SOVRUN CAN DO FOR YOU
Sovrun would build a bug-review workspace that links each report to its recording, game build, platform, and available event or error records. Models locate candidate video moments and suggest related reports; explicit evidence stays beside every suggestion. Testers verify the groups, reproduce the failure, and approve a ticket containing exact steps, expected and observed behavior, source times, and a proposed engineering owner.
Follow the failure
back through the session.
The source recording and event record share a verified session clock in this fictional example. The checkpoint payload omits a field, but the save-system cause remains a hypothesis until an engineer reproduces and investigates it.
Collect the harbor key
Inventory: harbor_key × 1. Unlock flag: true.
Write checkpoint C-03
Inventory includes the key. Saved fields omit the unlock flag.
Load checkpoint C-03
Inventory still has the key. Restored unlock flag: false.
Try the harbor gate
Gate request rejected: unlock flag is false.
Key collected. Gate stays locked after loading the save.
The gate works before saving, then refuses the restored key.
“The harbor gate will not open.” No recording supplied.
Harbor ambience is silent; no gate failure reported.
A ticket with the evidence.
A next step for the right team.
The first build covers a defined test build and the studio’s issue format. These are proposed review outputs; no issue is filed, merged, assigned, or closed automatically.
- Build
- 1.8.0 / Windows
- Moment
- R-041 / 00:37
- Reports
- PT-041 + PT-057
Start from the same save.
- Collect the harbor key in Windows build 1.8.0.
- Save at checkpoint C-03, before opening the gate.
- Return to the title screen and load that checkpoint.
- Approach the harbor gate and try to open it.
Check the saved state.
- Suggested owner
- Save systems
- Hypothesis
- Unlock field not saved
- Verify fix
- Key opens gate after load
- Still unresolved
- PT-060 / Android
How we’d make it happen.
Connect the reports to their sessions
Match each report to its build, platform, recording, and supplied events. Keep original timestamps and flag missing recordings or uncertain clock alignment.
Review the evidence and proposed groups
Locate the reported failure and compare related reports. Separate a supported duplicate from a similar report that still needs testing, then draft exact reproduction steps.
Reproduce and hand off the issue
Testers approve the groups and ticket. Engineers investigate the cause and verify the fix using the same steps before the issue is closed.
Where AI helps
Video and language models help locate reported moments, summarize player descriptions, and compare possible duplicates. The workflow aligns the recording with supplied events using known session references, preserving uncertainty when clocks do not match. Models can suggest a likely area of code but cannot confirm a root cause from a description alone. Rules keep platform, build, and missing-evidence differences visible before grouping reports.
What people approve
Testers decide whether reports are duplicates, reproduce the issue in the named build, and approve the final steps. Engineers investigate the cause, accept ownership, and verify the fix. A similar symptom does not automatically close another ticket, and an AI summary never replaces the original recording or event record.
What we’d need to start
- Permitted test recordings and player reports with session IDs, build numbers, platforms, and reproduction notes
- Available event and error records, source timing information, and the team’s issue categories
- A defined issue-tracker format, access and retention rules, and named testing and engineering reviewers
How we’d test it
Use tester-labeled examples with true duplicates, similar symptoms from different causes, cross-platform reports, and incomplete logs. Check whether video links open the actual failure and whether the proposed steps reproduce it. Count false merges and missed duplicates. Verify that no report is silently closed or assigned as confirmed without the responsible reviewer’s decision.
Prepared for Gaming & esports. We would agree on the work after reviewing your brief, materials, and requirements.
This is a proposed project, not completed client work. The visuals and numbers show example outputs, not measured results.
