A release date moving is one of the most ordinary events in this industry and one of the most consistently misread. Players tend to treat a delay as evidence that a project is in trouble, and press coverage tends to treat it as news. Both reactions assume that the original date was a serious commitment. Often it was not.
Dates come in categories, and the category a date belongs to predicts how likely it is to hold. Understanding those categories is more useful than tracking any individual announcement.
The four kinds of date
Not every date means the same thing, and publishers use the same words for very different commitments.
- Internal milestone dates. A studio targets these for planning but never announces them. They slip constantly and are invisible until the next public date replaces them.
- Provisional targeting. Usually a window like a season or a half-year. The studio has a rough plan but not a finished one.
- Announced dates backed by a production schedule. The date is public, marketing is booked around it, and the publisher is aware of the cost of missing it. These hold most of the time.
- Completion dates. Rare, and they hold essentially always.
What actually causes delays
Scope growth is the most common cause by a wide margin. A game that is 20% longer is not 20% more work. Every new system needs content to demonstrate it, every new area needs testing, every new mechanic interacts with every existing one, and the testing matrix grows faster than the game does.
The second most common cause is a first-party platform certification delay. A game that is content-complete can still fail certification and need a resubmission. These delays are rarely announced at all, because the publisher sees them as an internal process issue rather than a project event.
Third is dependency on content that does not exist yet. Licensed music, voice work, and cinematics frequently have their own schedules and their own vendors, and a slipped audio milestone can hold up an otherwise finished build.
Fourth is simple attrition: key people leave, or illness hits, and a team that was running a tight schedule loses its margin for error.
What to trust when you read an announcement
The useful signal is not the date itself but what surrounds it. When a publisher announces a date, they usually publish a trailer and a pre-order at the same time. That is a costly commitment and it makes a delay expensive too, which is why announced-and-pre-orderable dates hold far better than announced alone.
The other signal is the precision of the window. A specific day implies a production schedule behind it. A season implies intention. A year implies a placeholder that the publisher may not expect anyone to read as firm.
Finally: watch whether the developer repeats the date in their own communications. When a publisher announces a date and the studio stays silent, that disagreement is usually where the delay comes from.
How we use this
Our verification process labels dates by how confident we are in them rather than presenting every date as equally solid. If a date is a placeholder with no month and day, we show no countdown at all. If we cannot confirm a date against a second source, we mark it as announced rather than verified. The goal is that you can see our uncertainty rather than having to infer it.