Average FPS Looks Fine, but the Game Still Hitches. Why?

Two different complaints arrived together, and that matters, because they turned out to have different causes. A freeze on the loading screen is a single bad moment before play starts. A slowdown during the run is a drag that lasts the whole session. Treating them as one vague problem called lag would have pointed the developer at one fix for two jobs. The devlog keeps them apart, and the fixes are apart too. The loading freeze got a loading change. The run slowdown got a shadow change and a character-animation change. That split also keeps the reporting honest: the loading fix claims nothing about run speed, and the shadow fix claims nothing about loading. If your own players report both a bad load and a sluggish run, split the complaints before you start fixing, or you will tune the wrong system for half the reports.

The headline number is the average frame time, about 21 milliseconds before the update and 13.5 after it, on the developer's own test PC. But the more useful number is the stutter share: frames taking over 25 milliseconds fell from up to 19 percent to under 2 percent. That is the difference between a game that is merely faster on paper and a game that stops hitching in practice. An average can improve while one frame in five still stutters, and players feel the stutters, not the average. A frame that takes 25 milliseconds is already running at only 40 frames per second, so a game can report a respectable average while a fifth of its frames sit at or below that line. The devlog's pair of numbers is a good reporting habit to copy: give the average for the overall picture, and give the share of bad frames for what the player actually feels. Both numbers here carry the same label, and it must stay attached to them: they are one developer's reported results on one test PC, with no hardware named, and no claim that every player's machine will see the same change.

Here is the core of the case, in the developer's own words: the sun's shadow was drawing the whole street twice every frame, and it now uses a single, shorter cascade. To see why that hurts so much, think about what a shadow pass does. Drawing a shadow means drawing the scene again from the light's point of view, so that the game knows what blocks the light. If that pass covers the whole street, and it runs twice per frame, the game pays the cost of drawing the street three times in total every frame: once for the picture you see, and twice for the shadow. Cutting the shadow work to a single, shorter cascade removes one whole street-drawing pass and shrinks the one that remains. That is a large saving from a small change, and it explains why the frame time fell so far without any change to the street itself, the characters, or the gameplay. The general explanation of shadow passes in this paragraph is background, not a quote from the devlog; the double-draw fact and the single shorter cascade are the developer's own statements.

The other two fixes in the same update handle the two remaining symptoms, and each one follows a different idea. The loading screen now stays until the game has finished preparing its graphics, so the heavy first frame no longer happens in front of the player. Nothing about that first frame got cheaper; it just moved to a place where the player expects to wait, behind a loading screen, instead of landing as a visible freeze. The character fix is about size: character animations are compressed to about 3x smaller files, so rescuing a survivor in the middle of a run no longer causes a hiccup. The pattern here is worth noticing. Loading something in the middle of play, even something as small as one survivor's animations, can stall the frame that needs it, and making the files smaller removes that stall. The same update also gave all eight survivors 3D models, but that is content, not the performance case, and this article does not go into it. Zombies, items and props still use placeholder shapes in the public builds, per the same devlog, which is a useful reminder that this is a prototype in active development, not a finished release.

Nothing below is presented as what the Red Shelter developer did beyond the three fixes already described; the checklist generalizes those fixes for your own project, and it stays inside it. The reusable habit is counting bad frames, not just averaging all frames. A game can get faster on average while still hitching one frame in five, and only the stutter share tells you whether the hitches are gone. The second habit is auditing hidden double work. A shadow pass, a reflection pass, or any effect that redraws the scene can quietly double your heaviest cost, and it will not show up in a list of visible objects, because the extra draw is not something the player sees. The third habit is moving costs to where waiting is expected. A loading screen, a menu transition, or a quiet moment before action starts can absorb work that would otherwise land as a freeze in the middle of play.