Games are perceived to be date-driven hits. So there is a "magic date" you need to meet -- a major holiday, for instance, or a big industry event like E3 -- or your project is "toast". So you wind up with crunch time, and a lot of quality problems, and ship a bad, buggy product that gets bad reviews (but hey, you shipped by the magic date, so that made it all better, right?)
Crunch time generally happens with consumer products; I've worked on these products practically my whole career, and it will burn you out unless you can find projects with enlightened management. I've also found that getting your own piece done solid, ahead of schedule, only means that you get dragged into the swamps and help out other teams with their issues -- you get to work on the really nasty bugs, the integrations with APIs designed by people too clever for their own damned good, you get to see the real sausage being made.
I argue that shipping a good product late, with a smaller team [the tendency is to add a bunch of staffing to meet deadlines, and we all know how that story ends] will result in better reviews and sales, a team that has better ownership of the product, and much better retention. But try telling that to a Suit whose only skill is to order people around.
[When I wrote my first game cartridge, I gave a detailed schedule of 150 days. It was October and marketing wanted the project to ship by Christmas, which left about two weeks for development. Even a clueless management stack knows that you can't compress work by that much, but it did take some effort to convince the marketroids that they couldn't just have 20 or 30 engineers sit down for a week and write the code. I did burnout hours for several months and finished up within a week of what I'd planned].
I regularly counsel "kids" not to get into the game industry early, and to concentrate on getting wide experience to a bunch of technologies, because game studios need more than just graphics and pretty lights. You can be a hero for doing a provisioning system, or a secure real-time networking layer, or a great storage system, and this stuff is just as necessary and as valuable as those flashy effects on the screen, just not as sexy or visible.
It’s not just holidays and E3 (and dodging releasing at th same time as the largest flagship titles). The main schedule constraint is that marketing spend must be paid months in advance for the purpose of reserving specific time windows. That spend is often equal or greater than the development budget. And, if you miss your time window, too fucking bad. You will have no marketing, no more money to buy in again and your game is now a flaming money hole.
I once worked on a sequel to a semi-popular Xbox game that was tremendously better than the original in every way -except that it lacked marketing. It sold 10% of what the original did because no one noticed that it shipped.
Shipping late is often not an option. Either ship on time or cancel the project near the end of development after 90% of the budget is spent. Layoffs and possible studio closure will certainly follow.
> The main schedule constraint is that marketing spend must be paid months in advance for the purpose of reserving specific time windows. That spend is often equal or greater than the development budget. And, if you miss your time window, too fucking bad. You will have no marketing, no more money to buy in again and your game is now a flaming money hole.
That's a good argument for being date-driven. However it strikes me that the best way to deal with that is to have a disciplined project management process so that you have a good estimate for when product development will actually be done.
That's the theory. And, everybody claims that's what they do. But, in practice it is exceedingly difficult to estimate not just software, but software that is premised on delivering novelty, creativity and a volume of original and highly-technical art greatly exceeding the budget of the engineering team.
On top of that, there is pretty much no defined path for learning how to be a game production manager. People come in, in myriad ways, pretty much completely unskilled as junior producers and mostly learn by following their seniors. As a result, project management skills in the industry are generally quite... poor.
> That's the theory. And, everybody claims that's what they do. But, in practice it is exceedingly difficult to estimate not just software, but software that is premised on delivering novelty, creativity and a volume of original and highly-technical art greatly exceeding the budget of the engineering team.
I hear ya. I don't have a background in game-dev, but I have done some tech R&D, and worked with others who have a lot more such experience, and so I understand the challenges of setting a delivery date when the problem is so open-ended. It's helped when you can spend some time upfront trying to eliminate the biggest sources of risk via prototyping, etc. Would that be called something like "pre-production" in game-dev?
However, and I don't mean to be glib here, but it seems to me that most creative software development isn't so revolutionary that it can't be estimated (or, at least isn't so radical that the feasibility of given due date cannot be determined) by a team with deep domain experience. I suspect, though cannot prove, that the fact the industry tends to burn people out after only 3 years is largely what causes the burnout. If they did a better job at retaining experienced engineers the need for crunch mode might diminish greatly.
> On top of that, there is pretty much no defined path for learning how to be a game production manager. People come in, in myriad ways, pretty much completely unskilled as junior producers and mostly learn by following their seniors. As a result, project management skills in the industry are generally quite... poor.
I think that's probably true for the software industry more generally. It's no knock against the people who are project managers, I just don't think there's often clear guidance for what the project manager is really supposed to do.
Crunch time generally happens with consumer products; I've worked on these products practically my whole career, and it will burn you out unless you can find projects with enlightened management. I've also found that getting your own piece done solid, ahead of schedule, only means that you get dragged into the swamps and help out other teams with their issues -- you get to work on the really nasty bugs, the integrations with APIs designed by people too clever for their own damned good, you get to see the real sausage being made.
I argue that shipping a good product late, with a smaller team [the tendency is to add a bunch of staffing to meet deadlines, and we all know how that story ends] will result in better reviews and sales, a team that has better ownership of the product, and much better retention. But try telling that to a Suit whose only skill is to order people around.
[When I wrote my first game cartridge, I gave a detailed schedule of 150 days. It was October and marketing wanted the project to ship by Christmas, which left about two weeks for development. Even a clueless management stack knows that you can't compress work by that much, but it did take some effort to convince the marketroids that they couldn't just have 20 or 30 engineers sit down for a week and write the code. I did burnout hours for several months and finished up within a week of what I'd planned].
I regularly counsel "kids" not to get into the game industry early, and to concentrate on getting wide experience to a bunch of technologies, because game studios need more than just graphics and pretty lights. You can be a hero for doing a provisioning system, or a secure real-time networking layer, or a great storage system, and this stuff is just as necessary and as valuable as those flashy effects on the screen, just not as sexy or visible.