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
deleted by creator
Yeah it sucks
Back when I dreamed of being a game dev I went back to college for it and they taught this bullshit in the class
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?
One look at the fucking incestuous flow chart made me feel nausea. How the hell does anything get fucking done?
deleted by creator
Our project uses waterfall disguised as agile.
Real Agile has never been tried™️
...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.
Leave your job, start a construction firm doing agile housing builds
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.
Okay thanks for clarifying that, iterating is definitely necessary, I didn't think "waterfall" actually meant literally no iteration whatsoever
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.