How patches are built & tested

Every GameScrubber patch follows the same repeatable process. The goal is narrow and deliberate: filter the English profanity in a game's text and voice, and change nothing else — not the story, not the performances, not the timing, not the layout. This page walks through how that's done and why the edits stay so contained. It's longer than it needs to be on purpose: if you're trusting a patch with your own game files, you should be able to see exactly what goes into one.

1. Document the game

Each game stores its words differently — some keep dialogue in plain text tables, others pack it into compressed archives or proprietary audio formats. The first step is to map a specific game: which files hold the on-screen text, which hold the voice-over, what tools are needed to read and rewrite them, and which parts must be left strictly alone. Nothing is edited at this stage; it's purely understanding the layout.

2. Find the profanity

Next, every relevant file is scanned against a profanity word list. On-screen text is matched directly. For spoken lines, the audio is transcribed so the words can be located precisely in time — down to where each flagged word starts and stops within a line. This is where automation earns its place: a single game can carry tens of thousands of voice lines, and finding the language by ear isn't realistic at that scale. The scan covers word forms and compounds, not just exact matches, so a word glued into a longer phrase still gets caught.

3. Plan and review the edits

The findings become a concrete plan: exactly which lines change and how. On-screen text is masked in place — each flagged word is replaced with same-length characters, so the surrounding sentence, punctuation, fonts, and layout don't shift. Spoken lines are silenced only across the flagged word, leaving the rest of the performance intact and the clip exactly as long as it was, so nothing drifts out of sync. Before anything touches a file, the plan is reviewed for correctness and safety.

4. Apply — safely, on a backup

Only after review is the patch applied, and never without a backup first. The original files are copied before a single byte is changed; if the backup step fails, the process stops. The edits themselves are deterministic — the same input always produces the same result, with no internet connection and no AI-generated voices. We don't re-record or synthesise dialogue; the original audio is simply quieted in the right spots.

5. Verify in the real game

A patch isn't finished when the files are written — it's finished when it's been checked. The edited game is re-scanned to confirm the flagged language is actually gone, and the game is launched and played to make sure it still runs and that text and audio behave normally. Every count you see on a patch page — the number of voice lines or text entries edited — comes from this real output, measured against the actual build, never estimated. Where a surface can't be cleanly filtered, it's reported as not covered rather than quietly skipped.

6. Document and package

Finally, the patch is packaged for download with a plain-language guide, and its page on this site records what changed, what didn't, the exact game build it was verified against, and the date it was checked. That "what was not changed" note is treated as load-bearing — it's the clearest answer to the question most people actually have before applying a patch.

What stays the same — every time

Want to see it in practice? Browse the patch catalog — each game's page lists exactly what its patch covers and what it leaves alone — or read more about the project on the about page.