Visit the Kill Switch Master List for more information on these and other current known issues: https://forums.bhvr.com/dead-by-daylight/kb/articles/299-kill-switch-master-list
We encourage you to be as honest as possible in letting us know how you feel about the game. The information and answers provided are anonymous, not shared with any third-party, and will not be used for purposes other than survey analysis.
Access the survey HERE!
Stop saying "Spaghetti Code" as an insult to game developers, please.
The very nature of programming is that it's complicated. VERY complicated. When you make a change on line 12,456,774,778,999 it can have an effect on line 22,565,335,666 which have nothing to do with each other and why did this change affect... doesn't matter it did. So then you have to scour the code and figure out that the reason is because it had an effect on line 2,884 which had an effect on line 2,566,335,555,665 which affected line 33,556,444 and that is how 12,456,774,778,999 affected 22,565,335,666. But then the fix for that affects line 3,455,377 and here we go again...
A lot of gamers love to insult developers with the term "spaghetti code" but, you might as well order angel hair pasta at Olive Garden then send it back because it's 'spaghetti pasta."
So please, understand that ALL code is like that, and so using it as insult just shows that you have no idea what you are talking about.
Comments
-
When you make a change on line 12,456,774,778,999 it can have an effect on line 22,565,335,666 which have nothing to do with each other and why did this change affect.That is spaghetti code, yes. The name itself comes from the fact that dependencies are twisted together in a very unorganized fashion, and the more you build on them without cleaning them up, the worse the entanglement becomes. I agree that most people who use the term don't really understand what they're conveying with it, but it is something that is generally best to be avoided by streamlining and maintaining code, especially if you are going to be building on it further.
Also, not "all" code is like that, its the entire point of concepts like handlers. Instead of chaining together a series of dependancies, you can use flow control to create appropriate checks to call information from other sources, especially in a language like C++ which does not require serialization first.
39 -
I must admit that it was very hard to understand your spaghetti text
10 -
Yes, but not every program is built upon C++ and the bigger a program is, the more complicated it becomes even with C++. My point overall is that most gamers that throw out that insult have no idea what they are talking about. The fact that you obviously do, then I think you of all people should understand where I am coming from. I mean, we don't even really know that BHVR doesn't have flow control and checks. Maybe they do, but even those aren't always perfect. Which, makes throwing the "spaghetti code" term at them even more of an issue IMO.
0 -
This one was built in blueprints, and converted to C++. It supports variables without requiring serialization, therefore it is able to streamline its code natively if the appropriate time and effort is allocated. I understand that spaghetti code doesn't mean that code is inherently bad, just that it is inefficient and prone to dependency related issues the more it is built upon before being cleaned up. Also they definitely use flow control because thats the foundation of everything down to if/than statements, my point was that when problems cause dependancy spirals like many of the ones in this game can, code being unorganized is often the reason for both said issues cause as well as the time and effort required to fix said issue. Its still a negative thing, but like I agreed, it doesn't mean the game is coded in crayon or something.
16 -
Oh, absolutely. Also, thanks so much for that insight into DBD's code. I will admit, that while I DO know computer programming, my knowledge is all almost 30 years old. I wanted to be a game designer and went to college for it, but... life got in the way. Thing is, when I see the insults hurled at game developers (even worse for other games) sometimes I think I dodged a bullet.
0 -
We will stop saying spaghetti code when it stops making sense. Look at the new update. Reintroduction of old, already fixed bugs (goomba) and a lot of inconsistent fat-shaming spots.
If this isn't a spaghetti code issue, I really can't imagine something that could be more!
8 -
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.
2 -
it's not an insult it's just fact. The devs have so many issues with tangled code every patch it's actually insane. It's pretty clear that dbd simply wasn't made with the intention of it surviving for anywhere close to this long, so first devs probably didn't spend that much effort into making the the "basement" of the code that stable to build off of.
3 -
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.
4 -
Yes, exactly. There’s a reason that a ton of things break with every patch, and it seems to be getting worse with each new update. Even the devs have stated that they never expected the game to last this long and get this big, so it’s pretty clear that this is a monster that has become difficult to tame. The devs really should start from scratch at some point, but obviously that takes time and lots of money. I don’t blame them for just milking the old code at this point. Plenty of people are still playing the game and they are still spending $ despite the constant bugs.
1 -
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.
4 -
I don't think we are going to get rid of those calling names cause I don't think most people respect the developers who work this every day.
That is despite them making the game that these people end up playing anyway.
1 -
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.
1 -
I don't claim to know what the dbd codebase looks like but this is a half truth at best, and disingenuous at worse. Commenting is obviously very important on specific things, like when it's not clear what specific code does, but in the long run even well documented code has the issues where changing one thing can have an unintended effect somewhere else.
1 -
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.
2 -
I think the notion of spaghetti code only referring to goto being used to make random jumps in code execution is a pretty outdated one, though? The same general idea, that you can't trace the program execution with any reliability, seems to be predominant. Which does at least cover DBD (because why are there multiple collision detection methods still in usage? How did that not get refactored properly?), although it probably doesn't explain a lot of the weirder things going on (I'd hazard a guess that the eternal tendency for map spawns to go haywire is pretty bad hygiene over what's global to all maps and shouldn't be changed, or needs to be turned into a method variable or something).
0 -
From what I've seen in a dev stream the whole thing is written using visual blueprint scripting.
0 -
Spaghetti code itself is a really outdated concept, you really really really really don't see it almost ever unless you are working on legacy stuff - I'm talking about stuff still in use from waaay back. My first job still was using software that was written in ~1989 that had these issues, that has been somehow maintained and added to. But it was unreadable but mostly worked. It was really never re-done modernized because the higher ups didn't want to spend x amount of time to re-do something that worked. You also sort of see that in the financial sector as well with cobol stuff written ages ago that handles transacations and stuff, but that has higher stakes than what I was doing, and cobol has it's own set of issues.
So a big thing in modern development is DRY - don't repeat yourself. So let's say I have code A that does some business logic, but now I added functionality to a new part of my application that needs to run that same exact logic, You don't want to copy/paste - that leads to maintainability nightmares. Especially if you have multiple teams working on the two areas. If we are talking about jumps like that, that is mostly a good thing - you almost never want to repeat code. But that has it's own issues, things breaking can be one of them.
That's sort of what I'm referring to with lasagna code - it's structured and layered and one thing goes wrong when changing something it can lead to. It's also not just a traceability thing - you can usually see what references something else, ide dependent of course.
Ok look, I don't mean to overly defend the devs, there HAVE been breaking issues since I started playing regularly and even back when I played a few matches on my ex's account to test it out in ~2017, but I can take things personally because I'm a developer and I know how things go, and I know we are always the first to blame, and I think being a dev on this game is probably the most miserable thing in the world, if not just for the community lol. Granted I'm not a game developer, but I am a senior engineer and have seen a lot of things go wrong in several different sorts of applications. But I also don't think it's just an issue with the devs, right? I've said this before:
a) the executives set too strict of deadlines - I really think if they slowed down to 3, or even 2 dlc releases a year we wouldn't see this kind of things. If you are in a huge crunch to get things out, things ship broken - I don't think I need to remind anyone of the twin's launch. Granted, things aren't done in 3 months - being, all the planning, programming, art, sound, etc, but the deadlines are really tight and set before things are even worked on. It's not really a decision that the devs make, that comes from product/project managers, which in turn get that stuff from the big wigs.
b) I think the QA on dbd has such a complicated job - we have so many killers at this point, with so many perks, so many maps, that I feel like things can easily slip by (re: collision). Also, on top of that - these aren't live matches, some things just, come out during live matches to do things qa or devs didn't account for. I don't know the answer to this, I've seen it at every one of my jobs. In non-gaming development things can be caught at integration or unit tests before things even ship - it's not perfect and things can still slip by. But I don't really know what that could look like with game development to cover every aspect of the game and how things interact, you know?
Sorry for the long ramble, lol.
From my understanding it was originally done done in blueprints first but now they use just normal c++ for the most part now and re-wrote a lot of blueprints stuff (I think that is why nurse was re-done and disabled for the month or two earlier this year? I think?)
2 -
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.
1 -
Could be. No idea personally. I just saw it once when they were talking about billy. I mean we're seeing the exact same bugs that happened when they changed to those exact pallet models previously. Plus some new interesting ones.
0 -
That's an absolutely great point. Even the use of the term "spaghetti code" is outdated, yet so many still use it to explain modern code that isn't even spaghetti at this point.
0 -
What makes it not spaghetti code?
0 -
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
0 -
Read any number of other replies from those who have done programming in the last 30 years in this very thread. Heck, even the quote you replied to was in response to a great explanation.
0 -
It's nice having a different topic every now and then.
1 -
Remember that time when crouching as Pig caused your game to display the flavor text for a version of Calm Spirit that wasn't even in the game yet?
0 -
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?
Post edited by Reinami on4 -
Yeah, but I wanted your explanation.
0 -
I'll stop calling it spaghetti code once they stop releasing more bugs than content every patch.
3 -
The programmer who wrote Wiretap commented on Twitter that the change to Blast Mine was intentional. So what I think happened is that they indeed made BM and Wiretap share some code, and then the programmer went to the designer and asked if it was worth it to make a special case for Blast Mine and the designer said they should behave the same so changed the BM design.
1 -
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.
0 -
What are they doing with their time? They’re messing with (and breaking) maps and making all kinds of other changes that nobody asked for, like changing the textures for pallets and breakable walls to make them harder to see
0 -
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?
0 -
Yeah, which is kind of the joke. Like, every other game developer seems to be able to handle "spawn 3+ enemies who move towards you" just fine. Not sure why it's so impossible for BHVR. It's not like the zombies even have special powers or unique behavior scripts, like the Left 4 Dead zombies.
0
