Last week in our community, members engaged in some insightful discussions around testing phases and the tools that make our lives easier. The conversation about the role of soak tests before a release candidate brought out some diverse opinions on how best to ensure stability in the final stages of development. Meanwhile, a thread on underappreciated tools sparked a sharing of hidden gems that many found invaluable. On a lighter note, there was a humorous yet surprisingly insightful thread about those pesky doorframes in games that sometimes become unexpected hurdles.
This Week’s Hot Topics
Soak test window before RC
There’s been a lively debate on the best timing and duration for soak tests before a release candidate. This discussion is crucial for anyone involved in game development, especially if you’re aiming for a smooth launch. Read more here
Your unsung MVP tool this year
Members have been sharing their go-to tools that haven’t gotten the spotlight they deserve. It’s a treasure trove of tips for anyone looking to streamline their workflow or discover new efficiencies. Read more here
When the doorframe becomes the villain
This light-hearted thread explores the unintended challenges of game design, focusing on how something as simple as doorframes can become complex obstacles. It’s a fun read with some practical takeaways. Read more here
Thank you for staying engaged and contributing to the community. Your input makes the discussions richer and more valuable for everyone. Looking forward to another week of thoughtful conversations.
On our last RC, we finally nailed stability by running a 6-hour soak on a true release build with autosave on and a bot looping a 10-minute input trace; using Perfetto (https://perfetto.dev) and auto-restarting the map every 30 minutes exposed a sneaky allocator stall. If you can’t wire up restarts, at least reload a heavy scene on a timer to force asset churn — anyone else see leaks that only appear after map reloads?
Quick tip: alongside pre-RC soak tests, we script suspend/resume + brief network drops every 5 minutes with autosave on, because , frametime creep and file locks only surfaced then; PresentMon’s CSV (GitHub - GameTechDev/PresentMon: Capture and analyze the high-level performance characteristics of graphics applications on Windows.) makes the multi-hour drift obvious… If that feels heavy, a lighter alt is forcing low disk space and slight clock skew once per hour to catch save/telemetry races — saved us from a late RC deadlock. Anyone else seen clock skew bite achievements?
One thing that saved us: soak on the release build with storage at 95–98% full and forced slow I/O, then deliberately kill the process mid-autosave to verify recovery. Our rule is “assume writes fail,” and for network chaos we’ve had good luck with clumsy (clumsy, an utility for simulating broken network for Windows Vista / Windows 7 and above), just don’t let artificial throttles mask real pacing issues. It’s like pulling the plug on a toaster — scary, but it proves the kitchen wiring is safe.
We caught a nasty freeze by scripting a GPU driver reset mid-session — a forced TDR during a camera cut — like yanking the HDMI cable at the worst moment (docs: WDDM Support for Timeout Detection and Recovery (TDR) - Windows drivers | Microsoft Learn). My rule is “assume the GPU disappears once per session” and verify lost-device recovery, but I keep this in nightly runs only since it’s noisy and can hide other perf signals.
Let overlays update mid-session and toggle them on/off (Discord, NVIDIA Share, Xbox Game Bar) while alt-tabbing and switching display modes — we only reproduced a mouse-lock loss when the Discord overlay injected on resume (https://support.discord.com/hc/en-us/articles/115000145731-Game-Overlay-101). It’s like a bouncer changing shifts during a boss fight — caveat: this can get noisy and look like a false positive if your retail build blocks overlays.
Quick example: we loop Windows sleep/wake 20–30 times while the game streams textures and autosaves; it exposed a D3D device-lost path and an audio init race we never hit otherwise. It’s great late in RC, but noisy on some OEM laptops due to Modern Standby quirks — cross-check with classic S3 if you can (docs: System power states - Win32 apps | Microsoft Learn). Anyone else testing controller hot-unplug during resume?
During RC soak I script a locale flip at runtime (en-US → “de-DE”) and reload settings; it flushed out a subtle JSON number parse where 1–23 vs 1.23 broke cooldown math. @amelie_tan87 it’s in the same spirit as your clock bump, but expect messy logs and consider culture-invariant parsing as a safety net.
I stress saves by flipping the save folder to read-only and filling the disk to 99% during RC; it revealed a hot retry loop and a missing “out of space” dialog. Gate it behind a debug flag and watch with ProcMon (Process Monitor - Sysinternals | Microsoft Learn) or it’s like yanking the tablecloth mid-dinner, @amelia_88 — worth adding to your soak?
I like to force a system clock jump mid-session (push it forward/back about 60 min) to catch code that uses wall-clock for timers; it once turned daily resets into negatives and broke cooldowns, so we swapped to a monotonic source. Minor caveat: this can confuse telemetry/SDK events, @amelia_88 — do you simulate DST or NTP resyncs too?
And before we cut the release candidate, I script switching the default audio device mid-session (disable/re-enable via SoundVolumeView: View / change sound volume on Windows from command line or GUI); it’s exposed hangs and missing device-change handling more than once… If your audio path isn’t dynamic, hot‑swap controllers with USBDeview instead, but either way “assume outputs can disappear” and watch for UI locks.
I always test putting the machine to sleep and waking it while the game’s running; it reliably exposes lost device, input re-init, and reconnect bugs that soak tests miss. On Windows I trigger it with rundll32 powrprof.dll,SetSuspendState or just close the lid, then make sure we have a clean “resume-from-sleep” path back to gameplay. Caveat: overlays and some GPU drivers can muddy the signal, so I verify on a vanilla OS image first.