The shortest amount of downtime between projects I had was two weeks. We shipped the game, I took my comp time, and I came back and started on a new project. We weren't going at full speed yet - it was mostly just exploratory preproduction work for the new game - but it was still work. The longest amount of downtime was indefinite. The project finished, didn't sell well, and almost everybody got laid off as a result.Normally what happens is that we get off-the-books comp time, usually some facto
The shortest amount of downtime between projects I had was two weeks. We shipped the game, I took my comp time, and I came back and started on a new project. We weren't going at full speed yet - it was mostly just exploratory preproduction work for the new game - but it was still work. The longest amount of downtime was indefinite. The project finished, didn't sell well, and almost everybody got laid off as a result.
Normally what happens is that we get off-the-books comp time, usually some factor of how much time we crunched before launch, and then we come back for a few weeks/months of taking it easy, doing retrospectives, and brainstorming new ideas for what we want to do next, and then ramping back to a normal work week after that.
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 wi
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.
Voice acting has a lot of associated costs. Specifically, getting the voice acting requires us to pay for:The voice actor's timeThe recording studio timeThe voice director's timeThe developer timeThese can add up - we pay union voice actors about $2000 per day each according to the current [SAG-AFTRA interactive media contract rates], and we spend at least that much for studio time. We also need to factor in the time the developers are away from the development studio and are at the recording st
Voice acting has a lot of associated costs. Specifically, getting the voice acting requires us to pay for:
The voice actor's time
The recording studio time
The voice director's time
The developer time
These can add up - we pay union voice actors about $2000 per day each according to the current [SAG-AFTRA interactive media contract rates], and we spend at least that much for studio time. We also need to factor in the time the developers are away from the development studio and are at the recording studio because they aren't doing their normal tasks while taking care of this. It isn't uncommon for voice recording to cost over $10,000 per day, all things considered.
In addition to this, voice actors are often quite busy. They often have many roles already scheduled that they have committed to. This means that they might have only one or two days they can commit to recording, then be unavailable for months after that. In such cases, it means that we can't make any modifications or changes to the script after the recording is done because the voice actor isn't available to do those lines anymore. For example, take a look at [Aleks Le's IMDB page]. He did a lot of voicework for games like Persona 3 Reload, Street Fighter 6, Octopath Traveler 2, etc. I count 18 separate projects he recorded for in 2023 alone. If he's one of my voices, I probably wouldn't be able to get him back in the recording studio for several months since his schedule is so packed.
SWTOR is especially difficult to record for because player voice lines need to be recorded once for each character class. That means aligning eight different actors schedules before a hard deadline, and that can be extraordinarily difficult. Anyone who's tried to schedule events knows this - things happen, people change, agreements fall through, things get pushed back. As such, it's a small miracle they're able to keep putting out fresh voiced content like they do.
Of course a studio can delay the launch, but a launch delay will have its own set of consequences. Remember, no game launches in a vacuum. Timing is the key factor.The most obvious consequence goes back to the adage "Time is money". The developers working on the game need to pay rent and buy food. The studio needs to pay those developers during that time to keep them employed. Those costs don't go away when the game's launch is delayed - they will still accumulate. If the studio doesn't have the
Of course a studio can delay the launch, but a launch delay will have its own set of consequences. Remember, no game launches in a vacuum. Timing is the key factor.
The most obvious consequence goes back to the adage "Time is money". The developers working on the game need to pay rent and buy food. The studio needs to pay those developers during that time to keep them employed. Those costs don't go away when the game's launch is delayed - they will still accumulate. If the studio doesn't have the money they need to keep the lights on during that delay, it won't be able to make payroll for its employees or pay its bills/debt. In such a situation, a delay is impossible - the company will die without money from the game sales.
The second consequence is about the state of the gaming world over time. Imagine that we delay our game to dodge Hades 2. What happens after Hades 2? Will we need to dodge another big release? Will we need to dodge another competitor in our specific game genre? Will the market still be good for our game? Will the platform still be good? Remember, Facebook was a major gaming platform for years and then it wasn't. Imagine spending two years and millions of dollars to develop a major Facebook game only to have the platform die out from under you before launch. Things always change over time.
These two consequences feed into each other - every day we delay, more things change and new problems arise. Every day we delay, costs build up that we need to pay for somehow. Every day we delay release, our income on the game remains zero. At some point, the game will need to launch or the company will assuredly die.
It has certainly happened in the past, though not necessarily specifically the narrative part of the game. Many games are pushed to launch without development being as far as they want it to be due to reasons like hitting their budgetary limit and needing to recoup some of the investment. Our estimates are only estimates after all, sometimes we run into unforeseen problems and things take longer than expected. We can't stop paying the developers when we hit snags like that, so certain features e
It has certainly happened in the past, though not necessarily specifically the narrative part of the game. Many games are pushed to launch without development being as far as they want it to be due to reasons like hitting their budgetary limit and needing to recoup some of the investment. Our estimates are only estimates after all, sometimes we run into unforeseen problems and things take longer than expected. We can't stop paying the developers when we hit snags like that, so certain features end up more costly than others, which eats into the budget that was earmarked for other stuff instead. Most games in this situation have a lot of other launch issues too for the same reason - when you're pushed out the door to make the deadline due to running out of budget, things that should have been fixed are often not.
When World of Warcraft launched in 2004, there were several entire world zones that were incomplete and (mostly) locked off from players. Some players were able to sneak in through various exploits and take screenshots of those areas. Most notable were that the zones were primarily unpopulated by anything - no mobs, no quests, empty towns and buildings, just environment geometry that had been built out. This accompanied other incomplete bits of the game like quests that still had XML code in them. It would take years before players would finally see the incomplete-at-launch zones in some form or other.
Cyberpunk 2077 famously launched after multiple delays with numerous bugs and weird issues. Notably, the dev team also completely cut the multiplayer mode of the game that they had been building in order to consolidate resources to ship the single player game. The game came in super hot and had a huge number of launch issues that were eventually (mostly) ironed out, but the multiplayer mode was never resurrected.
The most famous example of this is probably Knights of the Old Republic 2. The publisher famously moved the deadline up and Obsidian scrapped the in-development ending since they didn't have the time to finish it. Instead, the story was wrapped up super quickly to ship the game. Notably, the partially-finished original ending was left on the disc and modders eventually discovered (and later restored) it.
The cost of making changes entirely depends on how expensive the individual changes are to make. That is generally dependent on how many people are needed to do the work to make those changes. Once upon a time, back when all cutscenes were pre-rendered FMV, it was tremendously expensive to make changes because making any small change required re-rendering the entire video which was enormously expensive. Today, for an in-game cinematic, a lot of the things are done in real time so we can swap thi
The cost of making changes entirely depends on how expensive the individual changes are to make. That is generally dependent on how many people are needed to do the work to make those changes. Once upon a time, back when all cutscenes were pre-rendered FMV, it was tremendously expensive to make changes because making any small change required re-rendering the entire video which was enormously expensive. Today, for an in-game cinematic, a lot of the things are done in real time so we can swap things out as needed.
For the specific assets used in the cinematic, it depends on what it costs to make those new assets. If we already have the assets built for other reasons (e.g. a different outfit for this character), it's a lot cheaper than having to build a new asset from scratch for the cinematic. If we already have a voice line recorded, it's a lot cheaper and easier than having to arrange for the voice actor to come back in and record new lines. If we want to change the background music for the scene, it's a lot cheaper to use an existing piece we already have than to get a composer to make a new piece.
We usually try to minimize massive changes after the fact because of the cost involved. It's far more efficient to make sure that we've gotten our narrative and story locked down and finished before we begin constructing the cinematics than doing it as we go. Sometimes changes must be made (e.g. the voice of a major character has to pull out for whatever reason and we need to re-record all of the character's lines, we might be able to make some changes since we need to re-record anyway. But generally speaking, the early planning is much cheaper than the later implementation. We can't get refunds on development time or effort spent and we only have so much to spend on the total game.