A game that requires a large download before it can be played properly on release day is not necessarily a rushed game. The gap between the shipped version and the finished version is built into the release calendar.
The disc is finished before the game is
Physical media has to be manufactured, packed and distributed to shops around the world before the release date.
That process takes weeks, and it starts from a fixed build of the game that cannot change once pressing begins.
The date at which that build is locked is well before the date the team stops working.
Everything the team does after the lock has to reach players some other way.
That other way is the patch downloaded on the first day.
Certification is a queue with a schedule
Console platforms require submitted builds to pass a technical certification process before they can be published.
Certification checks conformance with platform requirements, including how the game handles storage, accounts, controllers and error states.
It takes time, and a failure means resubmission and another wait, so studios build buffer into their plans.
The build submitted for certification is therefore older still than the one used for manufacturing in some pipelines.
A studio finishing work right up to release has no route to players except a patch that clears certification separately.
Manufacturing lead times are inflexible
Pressing plants schedule capacity in advance, and a slot missed is a slot given to someone else.
Distribution to retailers in many countries adds further weeks, and shipping cannot be compressed by paying more beyond a point.
Retailers also require stock in warehouses well before the announced date so that shelves are full on the morning.
Marketing campaigns are booked against that date months earlier and cannot be moved cheaply.
The release date, in practice, is set by logistics rather than by readiness.
What the patch usually contains
Day one patches are commonly a mix of bug fixes found in the final weeks, balance adjustments and performance improvements.
They also frequently include content that was complete but not integrated in time for the lock.
Localisation updates appear often, because translated text arrives late and needs checking in context.
Online functionality is another frequent component, since server behaviour cannot be finalised until the servers are configured.
The size of the patch is a poor guide to the state of the game, because a single changed asset file can force a large download.
Digital release did not remove the deadline
A digital-only game avoids manufacturing, but it does not avoid certification, and it does not avoid preloading.
Preloading, where players download the game in advance so it is playable at midnight, requires the files to exist days beforehand.
That reintroduces a lock date, though a later one than physical media allows.
Storefronts also need lead time to prepare listings, regional pricing and age ratings.
The gap narrows with digital distribution but does not close.
Why the patch is sometimes larger than the game
Games are packaged in compressed archives arranged for fast loading rather than for efficient updating.
Changing a small amount of data inside such an archive can require replacing the whole archive.
Some patching systems also rebuild files locally, which requires temporary space on top of the download.
Studios can design for smaller patches, but doing so involves trade-offs in load times and memory use.
A large first patch usually indicates a packaging decision rather than an unusual number of fixes.
Reviews and the version reviewers played
Review copies are distributed before release, and reviewers may or may not have the day one patch available.
A reviewer playing an unpatched build can encounter problems that no player will see.
Publishers sometimes delay review access until the patch is ready, which compresses the review window and is read as suspicious.
Where a game changes substantially between review and release, the published assessment describes a version that briefly existed.
This is why some outlets now note explicitly which build they played and whether servers were live.
What this means for playing offline
A player who buys a disc and never connects to a network has the manufactured build and nothing else.
For a single-player game that build is usually functional, but it will contain the problems the patch was written to fix.
For games designed around online components, the unpatched build may not be usable in any meaningful sense.
Preservation is the longer-term concern, because a disc that requires a patch to work is not self-contained.
Once patch servers are eventually retired, the version that survives on the shelf is the one that was never intended to be final.