I am not a game dev and do not have a stake in this personally but also dislike the ‘lazy or incompetent dev’ line that gets used sometimes. While ALOT of games seem to be made with really shitty code, with a game that seems as complex as Helldivers 2 adding a new feature can be a lot more complex than expected.
First there are non-technical factors: bosses that might not want to implement the feature and needs to be convinced, the devs might not know how to implement it and need to do research which takes time, artists that need to be added to the pipeline for assets, budget or other financial concerns (management might not think the feature will contribute to revenue), or even something like petty internal politics.
One the side of technical problems there is combinatorial explosion where adding ONE feature means thinking about how it interacts with all the other features. There is the problem of possible technical debt where you might inherit bad code from previous devs that you need to change before you can add anything. There is also the problem that the feature might not be technically feasible; remember that a game has only a fraction of a second to do its calculations and display them to the player while also checking for player input. This does not even begin to consider the problems caused by being a multiplayer game with possible network problems.
On the discontinued engine, the studio founder said that they were already in development of Helldivers 2 when it was discontinued according to the Wikipedia article.
Yeah I agree this seems more like tech debt and possibly a shitty architecture to me, both problems that ultimately come from poor management. The codebase I’m responsible for at work was developed in a mad rush, and the levels of pointless coupling and interdependence sometimes makes it hard to change anything without spending forever tracking down all the stupid little places that piece was touching. That shit comes from management pushing you to just do the thing already and move on, which works for a while until things get so messy you have to slow down or spend some time on a refactor. Someone could easily have made a technical decision for the sake of expedience, which was then built upon and became interconnected with other things in a way that made changing it require a major change, which of course no manager will support, so the work gets broken up into 100 tiny stupid tickets trying to move toward adding the new feature without ever making a breaking change, slowing down the whole thing even more.
I am not a game dev and do not have a stake in this personally but also dislike the ‘lazy or incompetent dev’ line that gets used sometimes. While ALOT of games seem to be made with really shitty code, with a game that seems as complex as Helldivers 2 adding a new feature can be a lot more complex than expected.
First there are non-technical factors: bosses that might not want to implement the feature and needs to be convinced, the devs might not know how to implement it and need to do research which takes time, artists that need to be added to the pipeline for assets, budget or other financial concerns (management might not think the feature will contribute to revenue), or even something like petty internal politics.
One the side of technical problems there is combinatorial explosion where adding ONE feature means thinking about how it interacts with all the other features. There is the problem of possible technical debt where you might inherit bad code from previous devs that you need to change before you can add anything. There is also the problem that the feature might not be technically feasible; remember that a game has only a fraction of a second to do its calculations and display them to the player while also checking for player input. This does not even begin to consider the problems caused by being a multiplayer game with possible network problems.
On the discontinued engine, the studio founder said that they were already in development of Helldivers 2 when it was discontinued according to the Wikipedia article.
Yeah I agree this seems more like tech debt and possibly a shitty architecture to me, both problems that ultimately come from poor management. The codebase I’m responsible for at work was developed in a mad rush, and the levels of pointless coupling and interdependence sometimes makes it hard to change anything without spending forever tracking down all the stupid little places that piece was touching. That shit comes from management pushing you to just do the thing already and move on, which works for a while until things get so messy you have to slow down or spend some time on a refactor. Someone could easily have made a technical decision for the sake of expedience, which was then built upon and became interconnected with other things in a way that made changing it require a major change, which of course no manager will support, so the work gets broken up into 100 tiny stupid tickets trying to move toward adding the new feature without ever making a breaking change, slowing down the whole thing even more.