When Eurogamer reported that Marvel Rivals Season 9. 5 will "drastically" reduce the install size on PC and console, most players cheered at the extra free gigabytes. Engineers should read the headline differently. It signals that NetEase has re-architected part of its build pipeline, delivery mechanism, or on-disk layout-not simply flipped a "compress harder" switch.
A dramatic shrink in a live-service install is rarely a marketing slider; it's the visible output of a long asset audit, a manifest refactor. And a data-delivery discipline that many teams defer until storage pressure forces the issue.
Season 9, and 5 gives us a useful case studyIn this post I will walk through the systems-level decisions that typically drive a multi-gigabyte footprint reduction: how assets are cooked. Which compression codecs are selected, how patches are chunked and signed. And why install size is now a first-class SRE metric rather than a packaging afterthought. Read our guide to game patch delta encoding
Why Install Size Is a Platform Engineering Problem
Install size is one of the most under-measured platform metrics in live-service game development. It directly affects acquisition: a 150 GB footprint on a 500 GB console leaves the user with only a handful of other games before they have to delete something. It also affects patch completion rates, CDN egress bills, support ticket volume. And even the reliability of crash-dump collection. In production environments, we found that patch abandonment on slower connections started climbing sharply once a delta crossed the 8 GB threshold.
Beyond the player experience, bloat is usually a symptom of deeper pipeline debt. Orphaned textures, duplicated language packs, unreferenced shader permutations. And stale seasonal assets all inflate the build without adding gameplay value. When a team commits to shrinking the install, it is really committing to tracing every cooked byte from source asset to delivered artifact. That is expensive work, but it pays dividends in faster iteration, cheaper hosting, and fewer "storage full" refunds. See our CDN observability checklist for live games
The Season 9. 5 Patch as a Delivery Refactor
We don't yet have the exact byte counts behind Marvel Rivals Season 9. 5, but a "drastic" reduction almost always implies a refactor rather than a single-file cleanup. Live-service games grow organically: each season adds heroes, maps, costumes, voice-over packs. And event modes. If the build system does not aggressively retire old data, the install grows monotonically even when much of that content is no longer reachable from the current game loop.
One common trigger for a footprint refactor is the transition to a new manifest format. A manifest v2, for example, can track optional language packs, split PAK files by game mode. And mark streaming-only assets so they aren't duplicated on disk. NetEase may also have split "foundational" assets from rotating seasonal content, allowing future seasons to add and remove content without leaving dead weight behind. That kind of change requires coordination across build engineering, QA - platform certification, and anti-cheat teams.
Asset Cooking and the Hidden Cost of Redundancy
Most AAA cross-platform titles are built in Unreal Engine. And Marvel Rivals fits that pattern. During the cook phase, editor-facing source assets are transformed into platform-specific cooked files. The process is supposed to strip editor metadata, but in practice it often leaves behind unused materials, prototype meshes, duplicate texture mips. And localization tables for regions the build doesn't ship. I once worked on a live-service UE5 title where a spring-cleaning pass recovered nearly 20 percent of the install footprint simply by deleting orphaned . uasset references and consolidating duplicate textures.
The real fix isn't a one-time cleanup; it's instrumentation. Content-addressable storage, deterministic cook pipelines. And per-build size reports let teams spot drift before it ships. If two maps import the same rock texture at different import settings, the cooker produces two separate cooked objects. A content-addressable pipeline would deduplicate them automatically. Treating the cooked build as a dependency graph rather than a folder tree is the difference between controlled growth and bloat. Learn how we measure build artifact bloat in production
Texture and Geometry Streaming Reduce Duplication
Modern engines can also shrink the install by no longer pre-storing the highest-resolution version of every asset. Unreal Engine 5's Nanite virtualized geometry and Virtual Texture streaming allow the client to fetch only the detail levels that are actually visible. Instead of shipping a unique LOD0 mesh and full mip chain for every prop in every map, the build contains a single authoritative representation and streams subsets on demand. That removes one of the largest sources of redundant data in traditional game builds
Implementing streaming isn't freeIt requires the lighting, shadow, and audio systems to understand partial data availability. And it pushes pressure onto the I/O scheduler and memory budget. On consoles, it also interacts with the operating system's suspend-and-resume model. Done well, though, it can simultaneously reduce install size, shorten load times, and improve texture pop-in because the client no longer wastes disk space on mips it never displays. For more background on how this works in Unreal, see the Unreal Engine Virtual Texture documentation
Compression Algorithms Powering Modern Game Clients
Codec selection is another lever. General-purpose compression like zlib or gzip is easy to integrate but rarely optimal for game assets. Most high-end titles today use Oodle Kraken for its excellent ratio-to-decompression-speed trade-off, especially on the CPU-constrained decompression paths of consoles. Oodle Texture goes further by exploiting the fact that GPU texture formats are already block-encoded; it can squeeze additional bytes out of normal maps and albedo textures without changing the runtime format.
On PC, Zstandard has become popular for patch data because it offers tunable compression levels and fast decompression. The format is documented in RFC 8478, the Zstandard Media Type. And it integrates cleanly with manifest-based patchers. The key engineering decision isn't "which codec is best? " but "which codec is best for each asset class? " Audio, video, textures, and executable code all have different entropy profiles and different latency requirements. A mature pipeline profiles each category separately.
Delta Patching and Chunked Manifest Strategies
Reducing the installed footprint is only half the problem. The other half is making sure updates remain small. Naive patchers replace an entire file whenever a single byte changes. Which is why some games ship multi-gigabyte patches for a balance tweak. Modern systems split files into content-defined chunks, hash each chunk. And transmit only the chunks that changed. Tools like bsdiff, HDiffPatch, and Oodle Network SDK implement binary delta encoding, while content-defined chunking libraries such as FastCDC produce stable boundaries even when bytes shift inside a file.
A chunked manifest also improves CDN efficiency. Immutable chunks can be cached at the edge indefinitely. And rollout telemetry can show exactly which chunks fail integrity checks. In production environments, we found that moving from per-file deltas to chunked, content-addressable deltas cut our patch size by roughly 35 percent and our CDN egress by a similar margin. The biggest challenge wasn't the algorithm but the tooling: artists and designers needed clear dashboards explaining why a tiny content change produced a large chunk diff. How we instrument CDN cache-hit ratios for live games
Console Hardware Decompression and I/O Architecture
Consoles add hardware constraints that PC ports often ignore. PlayStation 5 uses the Kraken decompressor as part of its I/O complex. While Xbox Series X|S relies on DirectStorage and custom BCPack texture decompression. A build that's optimized for PC SSDs may waste space on console because it stores data in layouts that the hardware decompressor can't stream efficiently, forcing the team to pad or duplicate data to meet seek-time budgets.
Shrinking the install on console therefore requires co-design with the platform SDK. Files must be aligned to the hardware block size, packed in the order they are loaded, and tagged so the decompressor can operate without tying up CPU cores. The Xbox Velocity Architecture overview explains how Microsoft treats storage as a first-class part of the rendering pipeline. When NetEase claims a smaller console install, it likely means they have reworked these platform-specific layouts rather than just recompressing PC assets and calling it a day.
CDN Edge Behavior and Patch Rollout Observability
Smaller installs and smaller deltas change the shape of traffic on patch day. Fewer bytes per user means lower origin load, higher edge-cache hit ratios. And fewer timeouts on congested last-mile links. From an SRE perspective, the patch becomes easier to reason about: the blast radius of a bad rollout is smaller because re-downloads are cheaper, and telemetry shows completion curves that flatten faster. We used to track "patch started" and "patch completed" as separate events; the gap between them was one of our most reliable predictors of churn.
Rollout engineering also benefits. With chunked, signed manifests, teams can push updates through deployment rings: first to internal hardware, then to a geo-limited canary, then to one platform, then globally. If a chunk fails verification, the manifest can be pinned back to the previous version for that platform without forcing a full reinstall. Observability should include not just HTTP status codes but chunk-level hash mismatches, decompression failures. And disk-space exhaustion events.
Verification, Integrity, and Rollback Engineering
Any time you move or remove files, you risk breaking anti-cheat, save-data migration, or platform certification tests. Anti-cheat systems maintain whitelists of expected file hashes; if a refactor changes the on-disk layout, those hashes must be updated before the patch ships or legitimate clients will be flagged. Save data often stores references to content paths; renaming or removing a referenced asset can corrupt a player's loadout. Rollback engineering requires that the previous build's manifest, signatures,, and and delta paths remain reproducible
The safest pattern is to treat the build as an immutable artifact identified by a content hash. The patcher fetches a signed manifest for the target version, verifies every chunk against that manifest, and only then swaps the running game directory. If the verification fails, the client can resume from the last good chunk rather than starting over. This is the same discipline used in container image distribution. And it scales surprisingly well to multi-gigabyte game clients.
What Other Live Service Teams Should Borrow
If you're shipping a live-service game, treat install size as a CI/CD metric just like frame time or crash rate. Add per-build reports that list the largest cooked assets, duplicate textures. And unused content references. Schedule quarterly "asset amnesty" sprints where designers and artists delete prototypes that leaked into shipping builds. Use engine-native tools such as Unreal's Size Map, Asset Audit. And PakSizeVisualizer to make bloat visible. The goal is to Prevent the next 30 GB of growth before it happens.
Second, decouple foundational content from seasonal content in your manifest. Players shouldn't carry around Halloween event audio in March. Optional language packs should be downloadable on demand, not bundled by default. Finally, invest in delta encoding and chunked delivery early. The cost is front-loaded, but it compounds every patch day. For mobile and cross-platform teams, the same principles apply even more strongly because device storage and cellular bandwidth are tighter constraints than console SSDs. Contact our Denver mobile app development team for a build pipeline review
Frequently Asked Questions
How can a patch reduce install size without removing playable content?
It usually does this through better compression, texture and geometry streaming, deduplication of assets. And removal of unused or redundant files. The same content can occupy far less space when it's stored efficiently and streamed on demand rather than duplicated across multiple maps or packaged at the highest resolution everywhere.
Does a smaller install mean worse graphics or longer load times?
Not necessarily. Modern streaming systems can actually improve load times because the client fetches only what it needs. The visual quality is preserved as long as the source assets and runtime formats remain unchanged. The engineering trade-off is usually between disk space and I/O complexity, not between disk space and fidelity.
Which tools and engines make install-size optimization easier?
Unreal Engine 5 provides Nanite - Virtual Textures - Size Map. And Asset Audit tools. Compression libraries include Oodle Kraken and Texture, Zstandard, and platform-specific codecs like BCPack. Patch tooling includes bsdiff, HDiffPatch, Oodle Network SDK, and custom content-defined chunking systems.
Why do console updates sometimes require double the install size temporarily?
Console file systems often use copy-on-write or update-package staging. The new files are written to a temporary location, verified. And then swapped in. Until the swap completes, both the old and new data exist on disk. Better delta patching and manifest design can reduce this staging overhead, but it rarely disappears entirely.
How do developers verify that a smaller install still works on every platform?
They run automated smoke tests, platform-certification suites, anti-cheat integrity checks,, and and canary rollouts on each target deviceSigned manifests and per-chunk hash verification catch corruption before the game launches. Save-data compatibility tests ensure that player progress and loadouts survive the layout changes,
Conclusion
Marvel Rivals Season 95 isn't just a headline about free disk space it's a reminder that live-service games are long-running distributed systems, and their health depends on disciplined build, delivery, and storage engineering. A smaller install is the user-visible outcome of months of work on asset cooking, compression - delta patching, console I/O layouts. And rollback safety.
If your team has been treating install size as a packaging afterthought, let Season 9. 5 be the nudge to instrument your pipeline. Start measuring the largest cooked assets, compare compression codecs per asset class. And move toward chunked, content-addressable delivery. The storage you save is also the storage your players don't have to manage-and that's a better player experience than any patch note can describe.
What do you think?
Should install size be a first-class CI/CD gate,? Or is it acceptable to improve only when players start complaining about storage limits?
Which is the bigger engineering challenge: shrinking the initial install footprint,? Or keeping patch deltas small across years of seasonal content updates?
How much of this storage optimization work should be handled by the engine vendor versus custom tooling built by each live-service team?
