Game players do not care about the circumstances of game developers. They buy and play.

Is "spaghetti code" an insult? If it is an insult, I understand that I should not say it.

So is it a fact? If it is a fact, I may use the term "spaghetti code" as before.

The information we are seeing from players is that there are always bugs in the game, and those that have been fixed in the past will reappear within a few months.

All games in this world are great when programming complexity is combined with the game experience. Yes, in fact all games are great. Kudos to the developers.

So if a game has a bug that occurs over and over again, and the fixes recur quickly, should we still say it's great?

That is the player's emotion. You can never know if it is the spaghetti code that is the cause, but players will guess that it is the spaghetti code and say as a complaint that bugs occur. The "spaghetti code."

It is worth remembering that the developer commented that "fixing 99 bugs created 103 bugs". If there is a catchy phrase other than "spaghetti code" that conveys dissatisfaction with a bug without being insulting, use it. However, short, clear, and emotive power words are always effective in the Internet world.

When the game is criticised for spaghetti code, it's because it has a habit of reintroducing bugs that were already fixed, or bugs that don't appear to have anything to do with what they were updating, because it doesn't seem to be clear to anyone how any part of the game is structured in relation to anything else.

Like, the main one that's pointed out is that there's two methods for checking collisions hanging around, which is how you can get visuals and sounds etc. for an ability hitting, but then the ability hasn't actually hit, because both methods are involved in it.

Calling the code base convoluted and messy is pretty much just a description of what's going on. And not every program has to be like this; if it was a clean and orderly code base, a new map wouldn't come with bugged tiles on the new map, and bugged object spawning over everything in the entire game. But code review is expensive and not glamorous in the slightest, so it's never going to be done unless they stumble on something that actually loses money and players.

That’s why competent developers have good comments in their code so they can find things easier. I don’t think it’s fair to defend them for this because they aren’t competent enough to even understand their own code.

On this topic, I have gotten to a lot of fights on the various social media platforms about the use of spaghetti that I just have given up at this point because no one cares and when a bug appears it's just "spaghetti" and roll my eyes and move on. I remember one time aws had a shutdown, which bhvr's servers are on, and people complained about it being the dev's fault, as if my job didn't experience the same downtime cause of some aws issue, lol.

My issue is that literally isn't what spaghetti code is, spaghetti code is literally something ultra specific that happens in procedural languages when people used excessive amounts of goto's to execute specific lines of code that made maintaining and readability hard (see: a huge amount of programs written in the 80s, especially in BASIC). At least use the correct pejorative phrase - which would be lasagna code, which I suspect is what is going on in dbd (which mclean used to describe the codebase as too), but also, can be very hard to avoid. I constantly think about it at my job myself - the codebase at my work is so complex and overarchitected and touched by people around the globe on hundreds of team (I mean this quite literally), that literally a one line change down the line completely broke the product my team works on lol.

If you're going to make a huge game with all sorts of code, you should be labeling it and keeping it organized. That way, you know what each code does and where to find it without any question or concern.

For example:

Line 2,768: It would be smart for a dev to label this as "Pallet Drop Animation".

Then if something happens with dropping a pallet in the future, a dev can search up "Pallet Drop" and find the code associated with said action. You can even label inside labels to make details as easy to understand. This is important for a team working together because each coder needs to be on the same page.

If MandyTalk is working on line 102,345 about hit detection. She should indeed label it as "Hit Detection" and elaborate on everything so that say, dev, Peanits, comes in to make modifications. He can read up on Mandy's labels and notes to understand everything that's happening without having to guess what does what. It saves a lot of time and eliminates messing things up because you thought X does Z.

Just examples before you quote me and tell me I'm wrong. Focus on the point.

Trust me, I made a few games myself and even having 2,000 lines of code is troublesome to manage alone when you find a bug. But having labels and notes DOES help a lot.

However, when the devs have hit times to release content and have to make business related decisions over the health of the game, of course things will not be all handy dandy. All I want is the devs to take one chapter improving code, have a team discussions on how to improve the quality of the game, and build team morale. This would help out on the bugs because the team will be more organized and caught up on their code.

From what I've seen in a dev stream the whole thing is written using visual blueprint scripting.

It will never cease to be amazing and terrifying that COBOL-run stuff is still going on in the background and increasingly few people know how to update it.

My point, however, wasn't calling it spaghetti code in the true, Go To Statement Considered Harmful sense, just in the more colloquial (at least, in my experience) 'program flow is a mess and nobody is entirely sure how we've arrived at this particular method but we have and so we can't remove it' one. Doing goto-level spaghetti in a game so heavily event-driven would be an achievement in how impractical it is.

There's clearly both something wrong with the QA and code structure--again, we have the current release as an example. I'm not talking the edge cases like 'if you do this specific thing at the wrong time the Knight goes bizarre', I'm talking 'the entire map spawn is comically bugged' and 'every single map in the game is now spawning everything including in places it shouldn't'... which either suggests nobody is actually checking the maps before this goes to live, or global spawn parameters weren't recognised as such and someone accidentally changed the things.

It's just a funny way to refer to all those instances where they update a texture on Dwight Fairfield's elf costume

And that somehow breaks Wake up

Or something as equally absurd

It's nice having a different topic every now and then.

I am a software engineer professionally and have been for nearly 10 years.

It's not that hard. They have spaghetti code.

But seriously. Programming does not work like that. Things don't have impact on other things unless they are directly tied to it. For example, this is my speculation as to why they "nerfed" blast mine by making it so it doesn't return to you if it wasn't broken by the killer, when they released wiretap.

it is obviously because wiretap and blast mine used the same logic and code to "put something" on the generator. Blast mine worked entirely by being "kicked" by the killer whereas wiretap was cancelled by a killer kicking it, but had an additionally effect. The reality is though, they basically refactored blast mine to be generic so they could make other perks like wiretap work, but then realized that wiretap would be OP if they gave it back to the survivor if the killer didn't kick the gen, so took it away. Then didn't realize they "nerfed" blast mine in the process. And because they take forever to do anything, here we are with a nerfed blast mine, even though it was already underpowered to begin with.

When, in reality, it would be really simple to add logic to the "generic" version to add a flag that is like "returnsOnCooldown" to check if the thing is still on the gen when the cooldown is up, and if it is, it returns it to the survivor. Then just have wiretap set that flag to false, and blastmine set it to true. Or, if they speculate that they wouldn't want that behavior on any other perk, they add the check specifically into blast mine's code. This should be a simple task, that should literally take an engineer maybe 20 minutes to implement and write tests for it. But they don't. Why? The only reason that they wouldn't is because either:

A) They think it isn't that important for blast mine (which shows they know very little about their own game)

B) It is actually extremely difficult to do this (spaghetti code)

C) They literally don't know that this problem exists (which shows a massive problem with the company as a whole)

I would suspect it is A or B.

This is just this one problem though. The reality is there are tons of problems with this game that could easily be fixed with simple number tweaks, yet they take ages to do them. Months if not years. For example, the solo queue system for survivors to get icons that show what they are doing. Such a system is extremely simple to implement. And shouldn't take more than a few weeks for a single engineer. The logic for it is extremely simple. Check what action the survivor is doing, then set a flag, then based on that flag, an icon appears for other survivors. Why is that so hard to do and taking a year at this point? They say because they are doing other things. But like, WHAT are they doing? Rarely anything changes from patch to patch outside of a handful of perk changes every few months along with a new killer and survivor. Every 2-3 years they do a big sweeping change, and that's about it.

The only explanation for this is that it is far more difficult for them to do these things than it should be.

If i were them, i would be tweaking things constantly, either switch their patches from being every what, 2 months? to every 2 weeks, and change a few things every time, or during these 2 month patches, they should be making changes to dozens of perks at time. I mean, really think about it, how many VIABLE perks are there for both sides? Maybe a dozen? Out of what, hundreds?

My point is, what on earth are they doing with all of this time they have?

I'll stop calling it spaghetti code once they stop releasing more bugs than content every patch.

Video game programming IS very complicated. That is true.

That being said, there are very many zombie-based multiplayer computer/console games on the market today and they've been around for decades. Most fps games get a zombie-mode at some point. I'm not 100% sure why putting 2 zombies into their game was such a monumental hurtle to overcome. That kind of seems like the video games 101.

The story goes like this:

Back while they were developing the first RE chapter they messed around with an iri add-on that indeed spawned in a third Zom Zom. It tanked game performance so badly they scrapped the idea and changed the add-on.

Now I assume they develop & test on badass PC's. So if those couldn't handle a third zombie, what hope is there for my Xbox1? Or our poor Switch cousins? What else could it be but the game's coding?