Videogame development times are getting out of control
Death Stranding came out in 2019. Death Stranding 2 will come out in 2025. That's six years for two games. If these were the PS2 days Kojima would have cranked out 3 Death Stranding games by now and we'd be getting Death Stranding 3: Subsistence along with a teaser for Death Stranding 4 next year.
Remember when video game trilogies used be to a huge thing in the sixth and seventh generations? You'd typically get 3 games in about 5-7 years
See: Halo, Gears of War, Resistance, Killzone, etc
Take it with a grain of salt but from what I know of the industry it's mostly a management problem. Sure games are ambitious but we have so many tools at our disposal and game developers are, in fact, extremely fucking skilled. However the suits thought that the SCRUM methodology was cool and now instead of having a general direction for the project, devs have to vomit code and assets until the amount of slop is enough to look like a game
This got me curious so I, too, went and looked it up. Here I thought it would be something like Object-Oriented Design, Functional Programming, or Procedural Programming.
No. It's literally just micromanagement bullshit used by suits to make themselves look useful when they don't know shit about shit. Why the fuck would schools teach that instead of ways to push back against it?
...but unironically. Incompetent middle managers get hung up on ritual over purpose, and think that the whole methodology is a one-size-fits-all approach that will magically solve budget, delivery timeline, and quality control problems.
For my own small projects I use plain old waterfall and shit just gets done. No idea how it works on larger projects but if I'm not mistaken this was how we made games back when Majora's Mask was completed in 1 year (they reused OOC's engine so it was real easy stares at all UE5 projects taking decades to release)
Waterfall was literally presented by its "creator" (Winston W. Royce) back in 1970 as an example of how not to manage a software project due to the lack of testing and validation until all implementation is complete (meaning, no integration or regression testing is performed as features are added during initial construction). This is also kind of the source of the axiom that, "The first 80% of the project takes 80% of the time, and the last 20% of the project also takes 80% of the time," in reference to the prevalence of budget overruns and missed deadlines/estimates once integration testing actually starts.
It's fine for trivial projects, and iterative methodologies (e.g., Agile/Agile variants, XP, etc.) use sort of a mini-waterfall phase on a per-feature basis. You're still performing the same activities, and often in the same sequence; you just toss out the rigidity of only performing each of those activities once for the entire project and thus introducing a fuckton of risk. Unfortunately, Agile became a weird cult religion at some point and a lot of managers are more interested in holding constant meetings than letting developers build software. Honestly, it has been hilarious watching my own IT org try to adopt some semblance of Agile principles while absolutely not changing their mentality or approach to anything; it's like watching a monkey sodomizing a football, but like, with my paycheck. I hate it here. Send help. Or nukes.
That's more or less how our various faux-Agile software projects turned out, between lack of defined requirements, half-assed architecture, and a parade of revolving-door third-party contractors with little to no oversight beyond endless stand-up meetings. No code reviews, no documented QA standards or coding standard, no documented testing requirements, just "git 'er dun" followed by dawning horror when they see the issue backlog get worse with each bugfix since all of the contractors left without leaving behind any real documentation or knowledge transfer. Again, I'd find it hilarious if my own paycheck weren't on the line in the midst of all this. Oh well; toxic management gonna toxically mismanage.
I'm actually certified in a version of SCRUM. I've been on a total of one project which did it in what I would say is the correct way. Where the primary purpose was to gauge work and plan around the developers capabilities and needs, instead of having deadlines imposed arbitrarily from the top. It worked great and we delivered a useful tool in a relatively quick period with pretty inexperienced devs.
Every other time though it's a poor excuse for managers to waste time with useless metrics reporting and whip the devs into coding faster.
I am a victim of agile and we spend probably half the work hours in a week on agile shite alone. But it generates pretty graphs for the useless execs because its not about producing anything but about control.