But like, the commercial said that making games is just sitting on a couch and pressing a sound board to add that one sound effect in level 3, so like I don’t know why they want money for it.
this post was submitted on 24 May 2025
465 points (97.5% liked)
Games
38773 readers
1716 users here now
Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.
Weekly Threads:
Rules:
-
Submissions have to be related to games
-
No bigotry or harassment, be civil
-
No excessive self-promotion
-
Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts
-
Mark Spoilers and NSFW
-
No linking to piracy
More information about the community rules can be found here and here.
founded 2 years ago
MODERATORS
The PC build is trash
Well in Helldivers 2s case, its not helpful that they picked to use a dead game engine. Autodesk Stingray has been dead for a while.
Also, I might agree except that solo indie devs in their basement can add many basic features in 6 months time, not just one. I get that some features, like new maps, mechanics, or characters take time. But for example, when a game mechanic already exists elsewhere in a game but not in a different part (for example, a flashlight attachment on one gun but not a different gun), there is not a thing in the world that will convince me that would take 6 months to add. And if it would take 6 months to add, that is entirely due to laziness or incompetence.
Sure, larger businesses have more developers to get more work done. But there comes a time when throwing new developers at a problem convolutes the process and actually slows things down more than it helps.
Something that seems simple to you like a flashlight attachment may not be so simple under the hood.
Solo indie devs have an advantage because they're familiar with all of the code. They're the ones that wrote it.
They don't need to learn a new part of the code when making fixes or changes. They don't need to explain to another dev that "you don't change how this information is passed in here because you'll need it to look just like that in some other section that you'll never touch".
Additionally any decisions/changes/etc. are all decided by one person, no need for meetings to get everyone on board and explain exactly what you want to do. No need to try to get everyone to understand your vision for what you want to happen.
A famous comic might explain this process a little better:
Sounds to me like you're not considering that they likely have a massive list of priorities to address and a flashlight attachment is simply not even close to the top of the list.
Nothing exists in a vacuum.
It was only an example. As the asset already exists in the game elsewhere, adding that same asset somewhere else in the game should definitely not take even an intern more than a week to implement.
Again, it is understandable in certain circumstances that major content drops take time. But for something as simple as the flashlight attachment example (which again is only a hypothetical example), there is no excuse for something like that to take 6 months or more to implement. Even if they have other priorities, something like that is so menial to implement that it would not take any significant amount of time away from higher priority development. Particularly because, in the example, other guns already have flashlight attachments, it already exists in the game. Unless they programmed the game in the literal worst way imagineable, they likely have a modular weapon system with slots that accept attachments. Very easy to add a new slot and allow it to accept the flashlight attachment, again as an example.
I think you're misunderstanding the concept of priority.
a big part of the complexity in programming (especially game programming) comes from balancing flexibility with speed (both implementation and performance). At some point, decisions are made weighing out risks, priorities and plans that will solidify a part of the code base in favor of speed (or some other factor) at the cost of flexibility.
this happens all the time
A lot of the reasons a solo dev or modder seems like they can progress so fast changing things is they aren't facing a lot of the same factors and they aren't needing to go through any rigorous testing.
At some point in the process, there's too much risk and and overhead involved to make any change. This is totally normal from triple A down to game jams.
And, you can't ignore that some of these things come down to game design. A change like you're suggesting, just adding a light, can negatively affect the balance of things even if it seems like it wouldn't.
“Our software is a bloated mess” is not the defence they think it is.
It kind of is, unfortunately. Games are often developed with a lot of pressure and the constant dangling of the budget being cut off. I don't think the devs are incompetent and think what they produced (code quality wise) would be the best, but what could they do if they need a result to present to the publisher end of week and then don't get money (aka time) to clean it up but instead they get the next deadline.
On the other hand I am also not sure I can blame publishers. Things can easily spiral out of control if managed badly in the other direction.... see Cloud Imperium Games (i.e. Star Citizen).
load more comments
(1 replies)
load more comments
(4 replies)