this post was submitted on 02 Oct 2024
68 points (94.7% liked)
games
20524 readers
311 users here now
Tabletop, DnD, board games, and minecraft. Also Animal Crossing.
-
3rd International Volunteer Brigade (Hexbear gaming discord)
Rules
- No racism, sexism, ableism, homophobia, or transphobia. Don't care if it's ironic don't post comments or content like that here.
- Mark spoilers
- No bad mouthing sonic games here :no-copyright:
- No gamers allowed :soviet-huff:
- No squabbling or petty arguments here. Remember to disengage and respect others choice to do so when an argument gets too much
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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
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?
That's the neat part. It doesn't, not without lots of wasted hours of labor and squandered resources
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.
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.