Typically it takes more than one milestone for a publisher to decide to intervene. If the publisher believes that a project has gone off the rails there are two major options available. If they think the project is too far gone, they'll cancel the game and reallocate the workers, have a big layoff, or some combination of both.

If they believe the project is still salvageable, the usual process is to replace the team's leadership (or assign them a new boss) and send in their [rescue operators] to take up key team positions and try to save the project. The publisher's rescue team tends to be very experienced and very good at triage. They are there to take a hard look at what is currently going wrong and change the development trajectory to reaching minimum shippable status within the time given. This usually means replacement of the team's existing leadership because the project needs major directional change. The goal is no longer "make the best game you can", because that goal is now unreachable. Instead, the goal becomes "get the game to ship".

At this stage we don't have the resources to get new assets or significant code changes, so most of what we need to do is cobble things together that fit within the existing frameworks and work well enough to be a (mostly) complete and cohesive experience. Features and content that aren't up to snuff get cut or repurposed quite quickly here. Entire levels that are too far behind schedule to reach completion by the deadlines will be cut, set aside for potential DLC repurposing, or scrapped for parts/assets to be used elsewhere in the game.

Not all rescue operations are successful. I would say that one in ten or twenty rescue operations ship something pretty good. A good one third or so of rescue projects fail outright and get cancelled. The rest of the time, the project ships and then either get savaged by critics and/or players or get the 'mid' 7/10 game ratings that are so often quickly forgotten.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ

The most common answer in all of game dev is always "it depends". Most game development falls along a spectrum with one extreme end being "well-oiled machine" (i.e. a project where almost everything is already well-established) and the opposing end being "no idea where they're going and holding on for dear life" (i.e. everything is new and vision/direction is constantly changing). Qualities like clarity of vision, team leadership, and total team experience will determine where on this spectrum each project falls.

If the development process is disciplined and things are proceeding to plan, the demos we show to the executives are not far removed from the final versions we release to the public because things are proceeding as expected. The better-established the game and its feature set, the easier it often is to develop. Franchise games like Madden, COD, or Assassin's Creed, or long-running games like World of Warcraft have a well-established formula, very experienced teams, and a deep tool chest that allow games and game content to be built very quickly and efficiently. They are well-oiled machines that don't often have to reinvent the wheel because they've been using and improving on that process for many years already. They know exactly what they are building and are very good at delivering it. Any demo they build to show off work in progress will be very close to what will be shown in the final version of the game. Very little work will need to be redone.

If development is troubled and the team is having difficulty hitting their goals and milestones on time for whatever various reasons, then the demos will reflect that. Most troubled development executive demos tend to be smoke and mirrors, with a lot of hacks and demo-exclusive assets that are held together by bubblegum and a prayer. These kind of demos can cause the team to enter into a death spiral because cobbling a bunch of hacks together for a demo actually puts the team even further behind schedule because we can't use those kind of hacks in real production. This means that these teams need to build almost everything twice (at least) - a hacky rushed way for the demo and then the "real" way. They constantly need to "catch up", but the hacks they put in place often cause instabilities and [technical debt] that must be addressed later on, which puts them further and further behind. This is commonly known as development hell.

These are, of course, the two extreme ends of a single spectrum. Most game development projects fall somewhere along that spectrum. More experienced and established franchises lean towards the "well-oiled machine" side because they've had all the bad practices beaten out of them over the years. Most new IP and experimental gameplay tends to lean more towards the wild-and-crazy side of the spectrum, because there are too many [unknown unknowns] on projects like that. If you ever find yourself repeatedly behind the 8-ball crunching to put together many demos in a row with lots of hacks, you may wish to consider parlaying the firefighting skills you've learned into a job elsewhere.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ