I'm ashamed of myself for getting easily frustrated but this is a seemingly honest question. To answer I could say the code architecture itself, which i guess you could call it the design of the code base in general, it's just unmaintainable to the point adding new features is too painful to actually meet a lot of the design goals. It's one of those things where the more things get piled on the harder it gets to fix and maintain anything.
So far you are just describing the state probably half of all commercial software is in. Where programmers have to waste 80% of their time for getting around old code. It still gets released and then sold for years.
And the thing is, 7D2D is nearly finished and apart from a few armor sets and bandits whose feature set is already in the code due to the zombie cop there is nothing more to come. Even if they would need 3 times as much time to add these features it probably is less at this point in time than to refactor the code because someone on the internet told them to.
I don't see anything here that would prevent 7D2D from releasing. You as software engineer might get nausea looking at the code but the customers, the players don't look at the code. They see the result and while it surely isn't bug-free it already has been a game many people would buy as a finished game outside of EA.
This style of design I totally use for game jams but for projects lasting more than 2 months it gets exceedingly painful and adding more people on doesn't really make pumping out features actually much faster least not over the span of years. It's the game design coupled with the architecture to be more specific. They don't mix. A lot of hyped past wanted features and goals literally can't be done as a result of this.
That may be the case, but as of now those features are just optional stuff on a drawing board. It may be that you think one or more of those features are needed for 7D2D to shine, but TFP seems to have a different opinion there.
The only sure thing we will see in 7D2D at release will be bandits and the new armor, AFAIK.
Now this doesn't need to be acknowledged directly but an extremely powerful first step would be to pull things out of Entity.tick and EntityAlive.tick and gradually move it over to what we'd call a game system or game manager. It's an abstraction where you're doing exactly one piece of logic over a buffer of work (this case Entities with X criteria), this buffer should be maintained and added to and removed before this system is ran to make it easier to do things like batching and threading far as runtime but the real meat of doing this is that it'd actually pull things out of that virtual tick method and actually make it easier to see what's going on.
Or i guess to say this simply though I hate using this expression. It's impossible to maintain spaghetti. And I mean no shame by this but the code is spaghetti and past it's limit. If anyone has understanding of software at all go look at Entity.cs or EntityAlive.cs and actually try to make sense of it. There's too much nested complexity and weird mixes of state checking that make it hard to figure out when something should ever be called or even what it's job is. Code comments would never fix this. I've had a hell of a time trying to wrangle this when helping someone make an optimization mod back in A20. He managed to get the game in an insanely runtime efficient state relatively but the tricks he had to do even if he was on the team wouldn't really be maintainable sadly (without architectural changes). Hundreds of zeds on 40 man servers with 80FPS though yeah it had it's problems. He's more qualified (for the moment at least) to work on the project than whoever's the lead engineer and he's not even a dev but a modder. It's not because he's a genius it's just because he actually put in effort to learn how to do things better and got a gentle push in the right direction.
To reeeeeally sum this up as to why at it's more root cause. There's a guy in the world of software with the handle "uncle bob" whom put out a book called clean code. He's been pushing insanely fanatical OOP is the end all be all kind of concepts on all of the software industry and it's the backbone of why unity uses the CS pattern in the first place, it's why indie devs and devs in mid sized studios have an extremely difficult time making projects like this. It's not exactly their intelligence it's just they don't know any better and are following convention too much.
Yeah, I read about Uncle Bob. He essentially promotes refactoring to death to produce easily readable code snippets. I am not aware that he promotes just one design pattern, but more like using them at all instead of none. So I don't really understand why he would be the cause of indie devs being stuck into only one design pattern or not using them. I also could not find any reference to a CS pattern.
Now one thing I am sure of: if TFPs developers are fans of Uncle bobs design philosophy, it surely won't suffice if a random guy from the internet tells them in a phone call or a forum that that philosophy is borked and they should use option B. And certainly they won't do it when they think (rightly or wrongly) that release of the software is say less than a year away. And even if they know that some part is unmaintainable they won't change it now as long as it works as intended, warts and all.
So, I don't want to stop you, please continue as long as you like, but I think you are too late and too noname, even if you were right. Write a book, get a movement going, maybe that's the way to make yourself heard
A better engineer knows a multitude of patterns and tries to pick the best one based on the task at hand and isn't afraid to refactor.
This sounds to me as if it could have been the "clean code" manifesto. No really, clean code promotes refactoring and using patterns. So what is the difference here?
The code here sadly doesn't have any evidence of that. It just takes one guy whom is interested in walking down this path, that person alone would be more productive than 10+ typical programmers and it's just mostly because of a difference in attitude and exposure to specific topics. A lot of modders over the years seem to perhaps mistakenly think that the engineers themselves aren't interested but i've come to think it's probably that it's not their fault but that they are entirely outside our reach to the point none of us can actually give advice when we see issues. That's a damn shame. At the least the engineers should be hanging around software communities to exchange ideas, and should be reading articles to learn new techniques probably about at least once every two months ish or something akin. The code reflects that they are just too isolated and unexposed. Well that or someone doesn't have the balls to say no to bad direction. One of the two.
Possibly. Though are you sure the software community at large is already past Clean Code? I mean, you might know for yourself that it is wrong, but thousands of developers probably think as fervently that it is right. Hanging around software communities who usually happily argue about which agile method is the best one would not fix that.
