Sébastien Vercammen / root-cause engineering
Open to new engagements

For game studios · shipped titles · no source access

Something in your shipped build is broken, and you want it fixed.

I find out why, working from the public build your players downloaded. You don't have to hand over source code, repo access or an engineer's time to get started. Pick the problem that's costing you most. You get a cause and a number inside two weeks, whichever way it goes.

What it costs and what you get See the work first

Does one of these sound like your build?

  • Players keep hitting a crash.
  • The game runs fine, then drops hard in one particular place.
  • Loading times have crept up over the last few updates.
  • The longer someone plays, the worse it gets.
  • An update fixed one thing and something unrelated got worse at the same time.
  • It falls apart on one particular graphics card or driver.
  • Sound cuts out or the game hitches under load.
  • The slow part is inside an engine, plugin or middleware you don't have the source for.
  • The person who wrote the failing system isn't available.

Past work on closed-source builds

Each of these was diagnosed from outside the studio, on a retail build, with no source access. The full technical write-up behind each one is available on request.

Windrose · Kraken Express · Unreal Engine 5 · D3D12
Shipped

Hard crashes on startup for some

A slice of players hard-crashed on startup. Root-cause diagnosis surfaced the fault in a bundled graphics shader component (outside of game code), and pinned down which version update fixed it, plus which engine configuration avoids the bug.

What it cost to find out
Nothing but the build
No source, no seats, no onboarding.
What they did with it
Shipped + FAQ
I want to give credit: they responded very fast, and published an FAQ for their users nearly immediately after the report.
D3D12Core.dll update … huge kudos to our friend @Seb for figuring this one out! ❤️Windrose team, announcing the official FAQ entry
Windrose staff announcement crediting Seb by name for the D3D12Core.dll startup-crash fix
Kraken Express announcing the fix.
Similar problem?

Crash reports arriving from players? €2,500, report in two weeks. You get the cause and what it takes to fix it, whichever way it goes.

Start a diagnosis →
Over the Top: WW1 · Flying Squirrel Entertainment · Unity IL2CPP · 200-player
Shipped in a hotfix

Worst-frame stutter in a 200-player session, now fixed

before<20fps→after>60fps· the worst frames in a 200-player session
What it cost to find out
Nothing but the build
No source access, no onboarding.
What they did with it
Hotfix 1.0117
Shipped the following day, carrying the performance findings. Easily one of the nicest teams to work with, open-minded and talented people.

The average frame looked healthy, around 108 fps, but a persistent stutter caused the worst frames to drop below 20 fps without clear cause.

With custom native profiling and an extremely responsive dev team, we attributed every millisecond of the 200-player frame dips, and lifted the worst-case dips from <20 fps to >60 fps.

Ten worst frames · whole-frame ms
← 20 ms frame budget ~9 ms average · 108 fps 672 ms 196 ms
The average frame was fine. The worst frames ran 10–34× over expected budget, causing noticeable stuttering.
Similar problem?

Frame drops or stutter in one place? €2,500, report in two weeks. Get an audit report: the cause and what it takes to fix it, whichever way it goes.

Start a diagnosis →
theHunter: Call of the Wild · Expansive Worlds / Avalanche · Apex · D3D11
Fixed and shipped

A mythical reward species that wasn't showing up

What it cost to find out
Nothing but the build
No source access, no onboarding.
What they did with it
Fixed in patch 9.1
before0→after100%spawn rate for affected players · root cause, repro steps and save-file forensics

The Wild Haggis was the game's first mythical creature, added with the Scotland reserve. Finish the Scotland mission and it should start appearing on the map. Players reported that it never did, some of them after hundreds of hours of searching. It was meant to be very hard to find, not impossible, and the community had documented the pattern for a long time without ever finding the cause.

So I went hunting for a potential bug instead. Working from the closed-source retail binary, with the community's reports as the only lead, the cause turned out to be two of the game's own subsystems competing, which left the haggis unable to spawn.

Official studio announcement confirming the haggis spawn bug and a committed fix
Expansive Worlds announcing the incoming fix.

On the same title, a separate investigation into Vurhonga Savanna's frame rate traced ~42% of unexpected frame cost to two level-of-detail tiers of a single grass mesh, and recovered up to +79%, 143 fps to 256 fps.

Similar problem?

Are your players encountering a bug? €2,500, report in two weeks. Get an audit report chasing the root cause, the evidence behind it, and what it takes to fix.

Start a diagnosis →
Rust · Facepunch Studios · Unity + native
Rebuilt + accelerated

4.6 min of world generation, down to 20 s

Rust's world is generated by a closed-source native library with no public specification. I reimplemented it from the outside as a bit-exact port at 2× the performance, and then built a performance-first port that does the same work in 20 seconds.

before~4.6 min→after20.6 s13.4× · same map size (4500), same seed, same machine · two other seeds land at 18.6 s and 18.9 s

Rust servers wipe on a weekly to monthly cycle, and wipe day is the busiest moment in the game. Picking and publishing a map in that window means waiting on the generator, so the question was how short that wait could get. Measured against my own multithreaded port instead of the game's, the same campaign ran 140.6 s → 20.6 s, 6.8×.

The two largest wins were defects in the original rather than tuning. Beyond those: multi-core parallelisation, SIMD, a new pathfinding routine, and sub-phases made independently parallelisable, so even the stages that have to stay serial can be run across several maps at once.

Bit-exact port
0
Largest difference from the game's own output. Height, biome, topology, splat.

And bit-exactness is optional. The fastest version drops it in favour of maximum performance. It doesn't reproduce the game's output bit for bit from the same seed, but it generates the same gameplay-level features, so there is no noticeable difference for players. CUDA takes out the last few seconds on top of that. When the output does have to match the game exactly, that path exists and is proven: the bit-exact port is byte-for-byte identical to the game's own output, every noise primitive and every terrain layer, and the accelerated version that keeps that guarantee runs ~116 s, 2.4× faster than the game, with 1.90× throughput on top.

Similar problem?

A system taking minutes when it should take seconds? €2,500, report in two weeks. Get an audit report: where the time actually goes, measured on the shipped build, and what it takes to fix.

Start a diagnosis →
Stormworks: Build and Rescue · Geometa · native · embedded Bullet physics
Physics performance

One save dragged the tick rate from 64 to 15

before10–17→after~61ticks per second · ~99% recovered
The symptom
64 → 10–17 TPS
The same in singleplayer as on a server. Healthy on every other save.
After
~61 TPS restored
~99% recovered, and a no-op on saves that were never affected.

A single stale physics record was costing roughly 50 ms of every tick. Found in the shipped binary, without source, and fixed three independent ways so the studio could pick whichever one fit their release process. Each one a no-op on saves that didn't have the problem.

Separately, on the same title, I rebound the game's physics through my own native layer: the constraint solver went from 9.5 ms to 6.1 ms, and shadow rendering from 12–13 ms to about 3 ms, taking the whole frame from 42 to 55 fps. On top of the engine work I also built a few server-side mods for the same title, adding automatic recovery and similar operational benefits.

64 nominal save loads fix applied ~61 TPS ~15 TPS · a crawl ~61 restored
Similar problem?

Tickrate collapsing? €2,500, report in two weeks. Get an audit report chasing the root cause, the measurements behind it, and what it takes to fix.

Start a diagnosis →

The offer

For the first engagement: One problem, you pick which one. Two weeks on it, and you get everything I find.

What you get
A root-cause report
What is actually causing the defect, the evidence for it, and what it takes to fix it. Delivered inside two weeks.
What the first engagement costs
€2,500 fixed
One number, not a range. Agreed before I start, and it does not move.

The report is written so that your own team can act on it: the cause, the evidence, what it takes to fix it, and roughly what that fix costs. If the symptom turns out to have more than one cause, you get all of them. The two-week deadline is what bounds this, not the number of causes.

We agree which problem it is on a free scoping call, before anything is paid. You pick by pain, whichever one is costing you most, and we work out together what that actually covers. Everything after this first engagement is scoped the same way and quoted as a fixed fee before it starts. No day rates, no open-ended engagements.

Is this a fit?

A good fit when

  • The obvious fixes already failedThe problem is real and reproducible, and the first plausible explanations didn't hold. You want the actual root cause found, not another guess.
  • You want it proven, not assertedA before/after in numbers anyone can check, measured on the real build, matters more to you than a confident opinion.
  • Understanding has to come firstA shipped binary, an engine you don't have the source for, or a system nobody still on the team wrote, has to be understood before anything gets built on top of it.
  • Defined scope suits youA defined problem and a defined deliverable, handled async and written-first, fits how you want to work.

Probably not a fit when

  • You need ongoing staffingA pair of hands by the hour, to work through a backlog, is a different kind of hire. I take on one defined problem and see it through to a proven result.
  • It has to run on meetingsStandups, live availability, managed time. I work async and written-first, which is what the deep focus depends on.
  • The conclusion is already locked inBeing brought in as a reference expert or a second opinion is welcome. What doesn't work is a conclusion fixed on untested assumptions, with no room for an investigation that might disprove it.
Email me your symptoms Or keep reading to see what to expect

Before you decide

All you hand over is the public build.

The same download your players have. Nothing else is needed to start.

What stays on your side

  • Your source codeNo repo, no branch, no build server seat, no symbols. I don't need them to do my work.
  • Your engineers' timeNobody needs to come off a sprint to onboard me, answer questions, or walk an outsider through the codebase. If someone wants to, that's welcome, it just isn't required.
  • Your legal timelineNothing here needs an NDA negotiated before it starts, because I only ever see the build your players already have. If your legal team wants one in place anyway, I'm glad to sign a reasonable one.

What helps, if you happen to have it

  • A repro, or the closest thing to oneSteps, a save file, a specific map, a hardware configuration it happens on. Useful, not required. Plenty of these arrive with no repro at all, and building one is part of the work.
  • Crash dumps or telemetry you've already collectedIf you have them, send them. If you don't have them, that works for me too.

What happens during the two weeks

Laying the groundwork
Days 1–3

I reproduce it, or tell you I can't

The first thing I do is turn your problem into something that happens on demand, on my machine, on the retail build. If it won't reproduce, you hear that in the first days.

Days 3–12

Measure, then narrow

Instrument the shipped binary, measure where the time or the memory or the fault actually goes, and eliminate candidate causes until we arrive at the root.

What lands on your desk
Day 7

A halfway update

What's been ruled out, what's still standing, and whether my estimate of the answer has changed.

Day 14

The audit report

The cause, the evidence chain that proves it, what it would take to fix, and roughly what that fix costs. Written for an engineer on your team who can start the implementation without me.

The work is done independently, communication is async and written-first throughout. No daily standup, and no requirement that anyone on your side is available on a given day.

What "no" looks like

Sometimes the symptoms don't turn out to be what we expected: the issue is caused by user error, the bug sits in the code of a third-party vendor, or the thing everybody blamed turns out to be innocent.

If there is a cause to find
€2,500 fixed
Inside two weeks: the cause, the evidence, and what it takes to fix it.
If there is no cause to find
€2,500 fixed
Inside two weeks: a report documenting what was done, what was ruled out, how it was measured, and next steps to take.
The deliverable is the same either way

The report has the same shape whichever way it goes: every cause considered, how each one was tested, what the evidence did to it, and what the next steps are to resolve it. Same price, same deadline, and if it's beyond my abilities to diagnose it I'll say so plainly and explain why.

A published example: on Windrose, the answer was that the studio's own code wasn't at fault. The crash sat below the game, in a bundled runtime component. They published it in their FAQ the same week.

And if you want me to implement the fix

The audit report already tells you what the fix involves and roughly what it costs. That's part of the deliverable whether I do the work or your team does. If you want me to implement the fix, the audit report will scope the work that needs to be done, and these things are settled before that work starts:

  • A written success criterion, agreed in advanceSMART success criteria: Specific, Measurable, Achievable, Relevant, and Time-bound. Examples: "Crash X no longer reproduces across 100 runs of scenario Y" and "Frames per second in scene Z stays above N on the reference machine".
  • You choose the benchmark scenesYour build, your maps, your hardware. Concretely defined measurements so you don't have to take my word for it.
  • Optionally, with milestone bonusesIf you want to go the extra mile, part of the fee can be tied to hitting additional goals beyond the baseline. E.g. +30% avg fps baseline, with every extra +5% avg fps being a separate milestone, up to +60% avg fps, with fees fixed upfront to eliminate surprises.
  • Handing it to your own team is a normal outcomeThe report is written to be actionable by an engineer who has the source. The audit report by itself will be sufficient to do the work, even if someone else does it.

Confidentiality

Results are shared · Methods stay private

In the audit report, I publish what was found and what to do next. In case studies, I never publish how it was found: no approaches, no tooling, no route into game binaries. Every write-up withholds the method on purpose, to prevent wrongful use.

I don't discuss one studio's build with another, and nothing about your engagement appears anywhere without your written approval, including the fact that it happened. I'll work under NDA if you want one in place.

One problem, €2,500, and a cause inside two weeks, whichever way it goes.

Send me a short description of the symptoms and what you've already tried. If it's a fit I'll confirm the scope and the start date. If it isn't, I'll tell you that instead, before you've spent anything.

[email protected]