Periodically, I’ll hear from people that wish a game would implement one little thing to make all the difference in the experience. Maybe there isn’t enough save points. Or the control profiles aren’t flexible enough. Somebody hard of hearing wants subtitles. Seemingly small tasks, right?
As developers, we run into these situations all the time. The initial design document is just that: a document. A plan. It’s full of educated guesses, studio review, and more than a little hope, because chances are nobody there has made brand new feature ‘X’ before. With usually more than 12 months from beginning to end to determine how a game turns out, we want the design to be fun. We pray for the design to be fun. But we have no choice but to plan for the worst, because game development is anything but a sure thing. And the moment the schedule starts slipping, the studio starts losing one of two things: time or money.
There is a saying in game development that roughly goes, “the longer your project takes, the more expensive every decision becomes.” What it means is that at first – when your game is strictly on paper – decisions (basically features) are as cheap as what you write it on. Nobody has done anything with your idea yet, so cutting it loose inevitably costs little to nothing. But at the end of a project, when the game is a hair away from being bug-free and ready to ship? That same breezy idea could push your ship date from Christmas to Easter and force the company to cut your best friend’s job to make the payroll. (ugh!)
For argument’s sake, let’s say the little change you want is subtitling for cutscenes. Seems like a fair thing to ask for, right? Heck, a lot of engines out there support it out of the box. But let’s say it’s not there. Either programming had to make the cutscene engine from scratch, or the software in the budget can’t do it. What sort of cost is there to implement this a month before the game ships?
Programming: Even though the schedule may be backed, the team needs to find a programmer who can spare the time to code in overlay support for cutscenes. The overlay needs to take into account size and positioning (the TV could be SD or HD) as well as having support for multiple languages (since rarely does a product only ship in North America.)
Localization: I just mentioned multiple languages. Well, now not only does design need to come up with a current script, but now localization has to find a few more weeks to write that script out in different languages. This is not the same thing as a literal voiceover script, as anyone who has experience in subtitles might tell you. The average game these days probably ships in no less than 5 languages.
User Interface: Just adding the feature isn’t enough; the player needs to be able to turn it on or off. Maybe even switch between languages if you want that. But either way you look at it, it means the UI team needs to either revise the current interface or come up with something new to support it, and then the UI programmer needs to have time to implement it…without stepping over already touchy in-game memory limits.
Testing: The one you’re likely to hear the loudest shouting about. Think of your nearly finished game as something similar to a Jenga puzzle. Add too many blocks or push too many existing ones, and the whole thing topples over. Every change requires a new build and a new full-on assault from the testing department. It’s not only possible, but likely that those subtitles have caused some part of the game to either lock up, slow down, or break TRC. All of them are bad, because they can prevent the game from shipping on time and possibly prevent the team from playing their own game.
What happens to all of the tutorials when (A) no longer jumps? What happens if the framerate drops just enough to double the difficulty of that boss fight?
Okay, so all in all…maybe a month of work combined? Depending on the project, there’s a chance it could be doable. Certainly if there is the staff to spare. But the project just about to ship will likely cut it without a second thought. Game designs are built with two things in mind: the things we want, and the things we need in order to successfully build a game.
No matter what we do, sometimes the wants need to wait for next time.