Okay, game budgets are bigger because of massive teams and longer development cycles.
Not sure we got a good explanation for that though. Graphical fidelity is “only part of it”, what’s the rest? Is it really just game scale? Open worlds are not that new at this point. And the bigger ones tend to feature lots of copy-pasted content and boring shopping list designs. Are the new ones really bigger enough that they need ten times the team?
Every times I watch Ubisoft credits for a game (which has been much more rare lately, admittedly), the part of it that was for people actually making the game goes smaller and smaller. Even in the 2010’s you’d already have 30-minutes long credit rolls, with most of it marketing, and a bunch of executives. This was even more obvious on the games that are definitely not larger scale.
The beginning of the article offers analysis as to what the rest of it might be.
Not too long ago, I had coffee with a video-game developer who told me that work was slow and that they’d been spending half of their days watching Netflix.
For a second I was stunned — this person worked for a major corporation worth billions of dollars — until I remembered how many times I’d heard similar stories.
There was the developer who couldn’t work because the game’s tools weren’t ready. There was the team that had to drop everything they were doing because the creative director had played Breath of the Wild over the weekend and came away with some Great Ideas. There were the artists who were blocked from working as they waited for a colleague to finish a design.
In other words, it’s not uncommon for professional video-game makers to find themselves spinning their wheels for prolonged periods, during which they get paid to do very little work.
So their solution to bad team coordination (which I would mostly consider a management problem) is to hire more people into their studios? I am not sure I am getting the link here.
It may explain longer development times, but bigger studios?
My read on it is that they hire enough people to optimistically get everything done when no one is blocked, but you can’t predict the future, like when you have a problem with your middleware that throws a wrench in the works, and a series of problems prevents other teams from getting their work done.
I think it’s an inherent problem with team scale. You can generally work faster when you know everyone that will use your code and you know exactly where and how it will be used. However if three thousand people will work with your code it has to be a lot more generic and water-tight. Adding more people to the team means that the rest of the team will work slower. You can’t add more people to the orchestra and have it played faster.
Okay, game budgets are bigger because of massive teams and longer development cycles.
Not sure we got a good explanation for that though. Graphical fidelity is “only part of it”, what’s the rest? Is it really just game scale? Open worlds are not that new at this point. And the bigger ones tend to feature lots of copy-pasted content and boring shopping list designs. Are the new ones really bigger enough that they need ten times the team?
Every times I watch Ubisoft credits for a game (which has been much more rare lately, admittedly), the part of it that was for people actually making the game goes smaller and smaller. Even in the 2010’s you’d already have 30-minutes long credit rolls, with most of it marketing, and a bunch of executives. This was even more obvious on the games that are definitely not larger scale.
The beginning of the article offers analysis as to what the rest of it might be.
So their solution to bad team coordination (which I would mostly consider a management problem) is to hire more people into their studios? I am not sure I am getting the link here.
It may explain longer development times, but bigger studios?
My read on it is that they hire enough people to optimistically get everything done when no one is blocked, but you can’t predict the future, like when you have a problem with your middleware that throws a wrench in the works, and a series of problems prevents other teams from getting their work done.
I think it’s an inherent problem with team scale. You can generally work faster when you know everyone that will use your code and you know exactly where and how it will be used. However if three thousand people will work with your code it has to be a lot more generic and water-tight. Adding more people to the team means that the rest of the team will work slower. You can’t add more people to the orchestra and have it played faster.
You can’t get nine pregnant women and expect one baby in one month.
Spot on. I’d summarize your comment as “Scope & vision” within the team. An excellent counterpoint to bloated AAA games is Hello Games & No Man’s Sky