That's an excellent question. You may remember the term [Decision Paralysis] used before on this blog. It's when a decisionmaker is presented with so many choices that they refuse to make (or put off making) a choice out of fear of making a mistake. Decision Paralysis affects everyone, including game developers like me. We can get so wrapped up in finding the perfect solution that we never commit to any one, for fear of that's solution's drawbacks... even though any solution that we commit to will have drawbacks regardless. This lack of commitment has side effects down the line - because we can't commit to something, we're afraid of our work being wasted or thrown out so we won't commit our best effort to it.

As such, pressure like a deadline naturally pushes us towards what I've taken to calling decision commitment - when we are willing to lock down a choice and accept all the benefits and tradeoffs that choice entails, rather than continuing to circle the options and never commit. It is closely related to what Mark Darrah likes to call completion urgency - the pressure to finish what we're working on. Decision commitment is necessary to make actual progress. Without any pressure to commit to a decision, dev teams can (and do) burn indefinite amounts of dev time and resources going in circles and end up with very little to show for it. When we've got a hard deadline, we know we have to buckle down and commit. That pushes us to give our best because we know it won't be wasted.

Lack of (or late) decision commitment really hurts craftsmanship and quality because we aren't actually committing to what we're building. If we are always keeping the back door open to drop whatever it is we're working on and changing our minds on the direction we're going, it always feels like a potential waste to do our best work. The quickest way to burnout is to feel like your work doesn't matter and your effort was wasted. Why polish, optimize, and improve if we're going to go a different way next week and throw this work out? No one likes to feel that way, so we naturally hedge our efforts with the minimum viable effort if we aren't sure whether it will be used.

This is all a long-winded way of saying "Yes, I absolutely do better quality work when I'm under pressure. Since I am confident we're doing this thing, I can give it my all." Without the pressure to deliver, the back door is always open and it's extremely hard to commit to the decision and give my best. If I know that we're absolutely committing to what I'm working on, I will build the best feature and content that I can. I believe that many other devs share this feeling for similar reasons.

[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

Honestly, I felt completely numb to it in both cases when it happened. That's because the game getting cancelled meant that the team was also getting laid off so I immediately had to go into survival mode. At the time, I shoved all of those feelings about never seeing my work into a tightly-sealed jar to process later once I had secured my own survival. Most of the things I learned from those layoffs (and subsequent layoffs) have been crystallized into my [Gamer's Primer to Practically Dealing with Job Loss]. I didn't have any time to mourn for my lost work because I was too busy trying to secure my own living situation. I did process eventually get around to processing it, but by then it was much later and the scar tissue had already grown.

[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

Over the course of my career, I've worked crunch hours (10+ hours a day) on at least ten separate games, two of which never shipped. I worked weekends on nine of them. Some crunch periods were intermittent (crunching near the end of milestones to make the deadline) and others were ongoing due to overly ambitious schedules and constantly-moving goalposts. Crunch period length was determined primarily by the project - some were short (shortest: two week crunch periods and not more than four weeks total over the entire year) and some were long (longest: eight months of sequential crunch leading up to launch).

I like Mark Darrah's perspective on this - crunch often brings completion urgency, which is the feeling that the team must make final decisions and commit to them, rather than second-guessing and redoing work or just not deciding. Significant amounts of work are gated by committing to large decisions - and crunch is one of those things that tends to force commitment. The longer major decisions go without commitment, the more work piles up on the other side of the decision commitment, thus often necessitating crunch to finish. Looking back on all of the games I've worked on, the projects that committed to the big decisions early were the ones that had the least issues with crunch.

[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

I've actually worked on and shipped more than one annual sports title over my career and I want say for the record that the idea that annual sports titles are "mostly minor tweaks and roster changes" is absolutely and categorically false. Annual sports titles absolutely do not have the same scope as AAA games with multi-year dev cycles, but they do absolutely have significant breadth and depth of scope each year beyond "minor tweaks and roster changes".

The majority changes that occur each year are spread out because they must be - there simply isn't enough development time within the ~11ish calendar months between launches to rebuild everything, so decisions must be made about what gets added/updated this year and what waits for next year. That means that, besides roster updates and minor tweaks, this year we're committing to change our animation system, these eight specific stadiums/arenas, these three game modes, update the commentary system, and rework the stat simulation. Next year, we're committing to these other eight stadiums/arenas, these other four game modes, the physics system, the VFX system, and the AI logic. This sort of round-robin approach is necessary - the dev team often isn't large enough to sustain working on everything each cycle so we need to pick and choose what we can do each year within the time we have. It also means that players who only engage with some of the game likely don't necessarily see (or notice) all of the changes we make each time around. This doesn't mean that we didn't do it or that the changes aren't there, but it can certainly look like not much has changed if the player isn't playing those parts of the game.

To your main question - The primary reason that annual sports games haven't transitioned to a live service model is because of inertia. There is a well-established and financially sustainable annual sales model that works. There would need to be a significant and tangible gain to be had by switching to a live service model other than novelty - all of the current existing tools and systems are built with the expectation of delivering a new retail game each year, and all of the dev experience built up is for delivering a new retail game each year. Switching over to an ongoing service would come at tremendous cost. There must be a gain to outweigh that cost in order for the publishers to do it.

[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