Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Games & XR

Deterministic Replay and Bug Reproduction SDK for Indie Godot Games

An open source Godot plugin that records a player's inputs, random seeds and frame timing so any bug report or crash can be replayed exactly on a developer's machine, with a web portal that collects and triages the recordings. An advanced game tooling final year project for indie studios who cannot reproduce the bugs players send them.

Difficulty

Advanced

Needs a team, real planning, and a supervisor who knows the area.
Effort

2 semesters · 2 to 3 students

Deliverables

7 to ship

3 optional extras

Suggested stack

Godot 4GDScript and C++ (GDExtension)Go or Node.jsPostgreSQLS3-compatible storageReact
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • A Godot plugin that records every input event, the seeds of all random number generators and the frame delta sequence into a compact binary log with a ring buffer of the last N minutes.
  • A replay mode that feeds the log back through the game and reproduces the session frame for frame, with pause, step and seek to any recorded checkpoint.
  • A determinism checker that hashes chosen game state every N frames during recording and replay, and reports the first frame where they diverge and which node changed.
  • An in-game "report a bug" button and an automatic crash hook that upload the log, a screenshot and device info.
  • A web portal where developers see reports grouped by build and by first divergent or crashing frame, and download a log to replay locally.
  • Two sample games (a platformer and a physics-light puzzle game) with the plugin integrated, used as test beds.
  • Documentation listing what breaks determinism in Godot (physics, time-based code, threads, unordered iteration) and how the plugin handles or reports each.

If you have time left

  • Periodic state snapshots so seeking to minute 20 of a long session does not require replaying from the start.
  • Clustering of crash reports by stack trace and replay signature to spot duplicates.
  • A Unity port of the recording format to show it is engine independent.

The problem: "it crashed when I jumped" is not a bug report

Indie studios and solo developers ship to thousands of players on hardware they have never seen. Bug reports arrive as a sentence and a screenshot. The developer tries for an hour, cannot reproduce it, and closes the ticket. Crash reporters give a stack trace, which helps with a null reference but not with the soft bugs: the player clipping through a wall, a quest that will not complete, an enemy stuck in a corner.

Big studios solve this with deterministic replay: record the inputs and randomness, then play the session back exactly. Fighting games do it for rollback netcode, strategy games like Factorio depend on determinism for multiplayer and have written publicly about hunting desyncs. Small teams using Godot have nothing comparable out of the box.

What already exists and the gap

  • Sentry and Backtrace collect crash reports with stack traces and device info, including for game engines, but do not reproduce gameplay.
  • GameAnalytics and similar tools collect events and funnels, which say where players drop off, not why a bug happened.
  • Unity and Unreal replay features (such as Unreal's demo recording) are engine specific and tied to their networking model.

The gap is a small, open source record-and-replay SDK for Godot with a determinism checker that tells you where replay breaks, and a portal to collect recordings from players. It turns an unreproducible report into a file you can step through.

What you build

The plugin hooks into Godot's input handling and wraps random number generation and time. During play it writes a compact log: inputs per frame, delta times, seeds and periodic state hashes. On a crash or when the player presses "report a bug", the last few minutes are uploaded.

The developer opens the portal, sees reports grouped by build, downloads one and opens it in the editor. The game restarts in replay mode, consuming logged inputs instead of real ones, with a small timeline to pause, step frame by frame and jump to the reported moment. If replay diverges, the checker names the frame and the node whose state hash differed.

The technically interesting part

Determinism is the whole project. Anything that depends on wall clock time, thread scheduling, dictionary iteration order, physics engine internals or floating point differences between machines can break replay. You will design what is recorded (inputs only versus inputs plus selected state), force a fixed timestep during replay, route all randomness through seeded generators, and build the divergence detector that makes failures debuggable instead of mysterious.

Be explicit about limits: full physics determinism across different CPUs is not realistic in a student project, so document which game styles are supported and prove it on the sample games.

How to evaluate it

  • Replay fidelity: for 50 recorded sessions on each sample game, the percentage that replay with identical state hashes to the end.
  • Overhead: frame time cost of recording and log size per minute of play; target a small, stated budget.
  • Bug reproduction: plant 10 bugs (including timing and random ones) in the sample games, have testers trigger them, and count how many a developer can reproduce from the report alone, compared with text reports.
  • Developer usability: ask 5 Godot developers to integrate the plugin into their own project and time it.

Suggested plan

  1. Weeks 1 to 4: study Godot's input, process and physics loops; read about determinism in lockstep and rollback games.
  2. Weeks 5 to 9: input and seed recording, binary log format, replay on the platformer.
  3. Weeks 10 to 14: state hashing and the divergence checker; fix determinism leaks found in the sample.
  4. Semester 2, weeks 1 to 5: timeline controls, crash hook, report button, upload API.
  5. Weeks 6 to 9: portal with grouping and downloads; second sample game.
  6. Weeks 10 to 14: evaluation, developer trials, documentation and release on GitHub and the Godot Asset Library.

Path to a product

Release the plugin free and open source to build trust in the Godot community, then sell the hosted portal: free for small projects, paid tiers by number of reports stored per month and team seats. The first customers are indie teams in early access on Steam or itch.io, where bug volume peaks. Studios that need on-premise hosting can buy a licence.

Scope warning

Do not try to support multiplayer, 3D rigid body physics or every Godot feature. Do not build general analytics dashboards; this is a bug tool. A plugin that replays two sample games reliably and explains its failures honestly is a strong result.

Learn what you need on Sefism

Get help with this idea

Determinism is a rabbit hole, so decide early which kinds of game your SDK will support and say so in the report. Bring your proposal and we can agree the scope, pick a stack your team can finish with, and design an evaluation your panel will respect. You build it; we help you make the calls.

New here? Create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.