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