Major games that once took two years now take six or more. The reasons are structural and reasonably well understood within the industry.
Content volume
The dominant factor.
Expectations for world size, asset detail, animation coverage and voiced dialogue have risen continuously.
Each of those scales with human effort rather than with computing power, which means faster hardware does not reduce the work.
A character model that once took days now takes weeks, because the detail expected has increased by orders of magnitude.
Asset fidelity
Higher resolution textures, more polygons, physically based materials and detailed animation all multiply the work per asset.
Photogrammetry and scanning have helped for some categories, capturing real objects rather than modelling them.
Which shifts the work rather than removing it, since scanned assets require cleanup and optimisation.
The team size problem
Larger teams do not produce proportionally more output.
Communication overhead grows with team size, and coordinating hundreds of people across disciplines and time zones is genuinely difficult.
Which is a well-documented effect in software generally and applies here with force.
It is why some studios have deliberately capped team sizes and scoped projects to match.
Iteration
Games are found rather than designed, which is the part outsiders underestimate.
Whether something is fun cannot be determined from a specification, which means building, testing and rebuilding.
Prototyping is comparatively fast. Iterating on a system already integrated with everything else is not.
Which means late changes are enormously expensive, and the pressure to lock decisions early conflicts with the need to discover what works.
Platform complexity
Shipping across several platforms with different architectures, certification requirements and performance targets multiplies testing and optimisation work.
Each platform has its own submission process with technical requirements that must be met exactly.
Which adds months at the end of a project, in a phase where the team is already exhausted.
The live service expectation
A change in what shipping means.
A game expected to receive content for years requires infrastructure, tooling and a content pipeline built before launch.
Which front-loads work that previously did not exist, and it commits the studio to a team that cannot disband after release.
Crunch
The industry's persistent labour problem, and it is a symptom of the scheduling difficulty rather than a separate issue.
Extended mandatory overtime approaching deadlines has been widely documented, and research on software productivity consistently finds sustained overtime reduces output through errors and fatigue.
Unionisation has grown, several studios have made public commitments, and the underlying scheduling problem persists.
What has actually helped
Procedural generation for content where variation matters more than authorship.
Engine reuse and licensing, which removes rebuilding fundamental technology each time.
Outsourcing of asset production, which is now standard and carries its own coordination costs.
And, increasingly, deliberately smaller scope, which is where several of the most commercially successful recent games have landed.
The lesson several studios have drawn is that scope discipline beats production capacity, and it is a harder decision to make than it is to state.
Delays and why they are announced late
Schedules are built from estimates that are systematically optimistic, which is a general property of software estimation rather than a games problem.
Which means the true position becomes clear only when integration begins and problems that were invisible in separate workstreams appear together.
Announcing a delay early is commercially costly, so studios generally hold until certain, which is why announcements arrive close to the previous date.
The alternative — shipping on schedule in poor condition — has produced several high-profile failures with worse commercial outcomes than a delay would have caused.
Post-launch as a phase
The expectation that a game will be substantially improved after release has changed how completion is defined.
Which has genuine benefits — problems found at scale can be fixed — and it has normalised shipping in a state that would previously have been unacceptable.
Where the line sits between reasonable post-launch improvement and shipping unfinished is a judgement, and it has moved.
Preservation of work
Cancelled projects consume years of effort that generally produces nothing publicly visible, and the proportion of started projects that ship is lower than outsiders assume.
Localisation
Translating and adapting for many markets adds substantial time at the end of a project.
Voice recording in multiple languages must wait until dialogue is final, which places it on the critical path.
Which is why some games release with fewer languages and add them later, and why text-heavy games are disproportionately affected.
Certification
Each platform has technical requirements a build must satisfy before release, covering everything from error message wording to controller disconnection behaviour.
Failures require a fix and resubmission, which adds days each time, and the final weeks of a project are frequently consumed by exactly this.
Which is invisible work that produces nothing a player would notice, and skipping it is not an option.