The developer has posted on Discord. The crash has been found, the fix is in, and the patch is coming. Then nothing happens for days.
It is tempting to assume nobody is working on it. Usually the opposite is true. For a small studio, the slowest part of shipping a patch is often what happens after the code is written, when machines turn a project back into a game your hardware can actually run.
A one-line fix still means a full rebuild
A patch isn’t simply a note slipped into your game’s installation folder. It’s a collection of updated files produced through a development pipeline, and that pipeline involves plenty of heavy, repetitive work. Source code gets compiled, materials become shaders for each platform, and textures, meshes and audio are converted into formats your PC or console can understand.
Unreal Engine has a name for that conversion process: cooking. It transforms game assets into formats that can be read by the platforms they’re intended for. Content needs to be prepared before shipping to players, although modern development tools can reuse previously processed assets rather than starting from scratch every time.
On a large project, building and packaging a game can take hours, even when much of the resulting content is identical to the version already sitting on your drive.
Behind the compiling shaders screen
If you play games on PC, you’ve probably encountered some of this work yourself. Plenty of modern titles pause during their first launch to compile shaders, while others can stutter the first time you enter a new area or trigger a previously unseen effect.
Shaders are small programs that tell your graphics card how to render different elements of a scene, and modern engines need an enormous number of them. Unreal Engine compiles shaders for different combinations of materials, mesh types and rendering features, creating a surprisingly complex process. Its shader documentation acknowledges that these combinations can quickly produce large numbers of shaders, increasing memory requirements and compilation times.
Some of that work also depends on your specific graphics hardware and drivers, which is why certain compilation tasks happen on your PC. When a required pipeline state object (PSO) isn’t ready, the game may have to wait for it to compile. Unreal’s documentation explains that a draw call can block while PSO compilation finishes, creating the familiar hitch or stutter players sometimes experience.
Engine developers and storefronts have been working to reduce these interruptions. Unreal’s PSO precaching system can collect and compile the necessary pipeline states in the background before they’re needed. Steam also introduced shader pre-caching in 2017, allowing supported OpenGL and Vulkan games to download precompiled shader data for compatible hardware, reducing loading times and some of the stuttering experienced during early gameplay sessions.
What happens between the fix and the download
Studios face the same arithmetic at a much larger scale, because they compile and cook for every platform at once. Supermassive Games, the studio behind Until Dawn, once said its shader and code compilation took “over 40 minutes” before it spread the work across more machines.
That is one stage of several. A typical patch moves through something like this:
| Stage | What happens | Why it takes time |
| Fix | A programmer changes the code and checks it locally | Usually the quickest part |
| Compile | Source code becomes the game’s executable | Grows with the size of the project |
| Cook | Art, audio and levels are converted for each platform | Hours on larger projects, repeated per platform |
| Shaders | Materials are compiled into every combination the game needs | Thousands of variations |
| Testing | People play the new build looking for fresh breakage | A broken patch costs more than a late one |
| Release | Console patches go through the platform holder’s certification, while Steam builds are pushed by the developer | Console checks sit outside the studio’s control |
The painful part is the loop. If testing finds a new bug, the fix goes in and the whole pipeline runs again from the top.
Why does the second build cost as much as the first?
In principle, much of this repeated development work should be avoidable. Unreal Engine stores processed asset data in a Derived Data Cache, or DDC, allowing previously generated data to be reused instead of recreated. The engine checks available caches for the information it needs, starting with the fastest. If the required data is already there and remains valid, Unreal can retrieve it rather than spending time generating it again.
A warm cache can save considerable processing time, while incremental build and cooking systems can skip work that hasn’t changed. After a one-line code fix or a small asset adjustment, much of the previous build may still be reusable.
The catch comes down to how some smaller studios manage their build infrastructure. Temporary cloud build machines are attractive because teams can create a fresh environment for each job and shut it down afterward. For many software projects, that’s a convenient approach. For games, however, a freshly created machine without access to persistent or shared caches may need to repeat expensive shader compilation and asset processing tasks. When the job finishes and the machine disappears, its locally stored cache can disappear with it.
Keeping the cache warm
Some studios avoid that problem by using build infrastructure that remembers previous work. A dedicated server rental gives a small team access to a persistent machine in a data centre, with fast NVMe storage that can retain build files and cached data between jobs. It also offers more predictable monthly pricing than paying for temporary computing resources whenever another build is needed.
The first build on new hardware may still take considerable time, but subsequent builds can benefit from previously generated data. Yesterday’s shaders and processed assets don’t necessarily need to be recreated, provided the build system and caches are configured to reuse them. Better still, teams can configure shared caches so multiple developers and build machines benefit from work that has already been completed.
Of course, this isn’t a solution to every delay. A team releasing patches twice a year might gain little from maintaining a dedicated machine that spends most of its time idle, and no amount of additional storage will speed up console certification. Persistent build infrastructure makes the most sense for studios producing builds regularly, whether that’s nightly development builds, on-demand playtest versions or the stream of hotfixes that can follow a difficult launch. Shared cloud caches can also provide many of the same benefits without requiring a permanently running build machine.
So, the next time a developer says a patch is coming soon, the silence rarely means nothing is happening. Somewhere, a machine may be compiling code, preparing assets and assembling another version of a game that looks almost identical to the one you already own. The studios that release patches fastest aren’t necessarily the ones working hardest, but often the ones that have found better ways to avoid repeating yesterday’s work.
