PotatoPlank
PotatoPlank
About
- Username
- PotatoPlank
- Joined
- Visits
- 8
- Last Active
Comments
-
Adding another +1 to this.
I only kept using Windows because of Dead By Daylight and the .NET Framework. I no longer need to work with the .NET Framework...so it's just DBD keeping me from switching entirely.
-
@Freki said:
https://forum.deadbydaylight.com/en/discussion/comment/1789044#Comment_1789044
Ok so i misspelled fortran in a tired and drugged state (pain killers) but c+ is a language that quickly morphed into C++. I worked in basic, machine, fortran and cobal in the 80's and 90's as I was going through aerospace engineering courses. I am not a software engineer but I have the experience in these languages and how they are programed. I do not dispute you credentials but C+ is a language that was a step from C and then stepped up to C++. I had books that were listing C+ and not c++ originally and they were respected publishers but I will admit that it could be that there was a difference in how one publisher called it and it was truly c++ but we are talking about late 80's and early 90's when I was learning basic programming functionality.
Speaking of Spaghetti Coding I said it was a thing of the past becuase of the block or encapsulation style coding. people here want to say it is the cause of all the errors that they see in the game, you misread what I posted because I talked about how the spaghetti coding really came about in a very simplistic way because 1) most here do not understand what it truly is and 2) I do not have the EXTENSIVE experience in coding programs but I have done so in all the languages I listed. I do not see that just departing from programming standards makes spaghetti coding because the idea of it is that the threads of the program are jumbled and hard to track down. unless they decided to program in stream of consiousness most programs now even if there is a divergence you can follow it from one to the next and find the error if it is obvious.
speaking to the video I did not comment on what blueprints were used for directly other than to agree that the devs have said they used it for parts of the game before, my issue is that he was making statements of "I think" and "I believe" and that made the use of it to prove spaghetti coding impossible because all he was doing was making postulations and moving to proof from there without any of his own. People take it as 100% proof positive because they want it to be and don't care for actual proof. As a programmer and software engineer, can you tell me I am incorrect in that a program does not have to have bad coding to crash? I mean if the video card passes bad information to the computer or the cpu gets distorted information because of mother board noise it is possible that the program could get a bit of data that it can not process and then crash? can that actually happen or is the program 100% protected from the computer hardware? this is where my argument lies that many people can have a program that works just fine and then suddenly someone has an issue, is it the program? or is it something else? could it be both? I think there is room to a say either one of the first two possibilities could be correct. However information must be gathered from those that have the error to examine what is actually going on yes?
I'll give you the benefit of the doubt, but:
- C+ was never a language. You can see a list of languages here (link). You can see the history of C++ here (link). The reason why there was no C+ (it was actually originally called C with Classes from 79-82) is because the naming is purposeful. The ++ symbol is called the increment operator, so C++ is supposed to mean "The next C++".
- I appreciate the aerospace background, but that doesn't provide much cross-knowledge to modern development.
- If you think that debugging code is simple in any way, you're extremely incorrect. The etymology of spaghetti code is irrelevant to modern standards. Spaghetti code has it's own Wikipedia page (link) that explains what it means.
Quote: "Spaghetti code is a pejorative phrase for unstructured and difficult-to-maintain source code. Spaghetti code can be caused by several factors, such as volatile project requirements, lack of programming style rules, and insufficient ability or experience"
If you watch the video though, Scott provides proof of why he states they use Blueprints. Blueprints are way less manageable compared to C++ code. Mclean also has a Twitch VOD that states they use Blueprints, but much less. Of course there's other factors that cause bugs, but historically BHVR has caused the same bugs to reappear in future patches. My educated guess is that they aren't properly utilizing VCS, QA cycles, and a proper UAT environment/system to ensure these bugs don't suddenly reappear.
I entirely sympathize with the devs. It's likely they knew the patch was not ready to go live, but management pushed them to launch on schedule. Debugging is difficult and if the code is not following best practices, it's easy to create new bugs and also extraordinarily difficult to find/fix existing issues.
-
@Freki said:
https://forum.deadbydaylight.com/en/discussion/comment/1782690#Comment_1782690
I didn't say i did not understand him, but his first opening paragraph he speaks he admits he is guessing at all of this and that's why I turned it off. I know programming in basic, cobol, fortrain, c, c+, c++, java and many other languages as I have programed in them. I even have programmed in machine code and assembly and used a command line environment to program routers and other devices. so I understood what he was going to try to say, but when he admitted it's guess work I turned it off because it is not proof to have someone guess at what is happening.
I rarely jump on the forums, but I felt like I needed to respond to you because what you're saying is suspect. I'm a Software Engineer, I don't think you are (or you're very knowledgeable) frankly. You might be super old school, especially since you mentioned languages no one uses from ~30 years ago.
To be entirely transparent, I have ~15 years of experience with modern development (5 professionally) in C++, C#, PHP, Python, JS (node, frontend frameworks), Typescript, Visual Basic 6/.NET, Java, and F#.
Here's what stands out:
- "Fortrain" is Fortran. This is a niche language that was released 60 years ago and since essentially replace by Julia or Python for scripting purposes.It's also not OOP, so it's largely irrelevant in todays engineering.
- Basic and COBOL are also old and are not entirely OOP (COBOL apparently added some support in 2002). Like 40 to 60 years old.
- C+ isn't a language... It literally doesn't exist.
- Assembly and machine code are both great concepts, but have little to do with modern code practices.
- I'm not sure why you even mentioned command line environments. As an engineer, that's probably the last thing I would think of as something "impressive" to explain my credentials. I work in the command line pretty much all day in various Linux distributions and Windows (cmd, powershell)....
I can't quote multiple of your posts, but they all have bad or odd information. Particularly, your rant on spaghetti code was interesting.
"this is what happens here, for anytopic for the most part: disconnect penalty, the fact that killers are getting nerfed all the time or survivors are always nerfed and many other topics like this one and the dreaded "Spaghetti Coding" which is a term coined in the 70's and 80's for a programming style that is no longer even used. originally programs were written with number lines (like 10, 20, 30, 40 etc) and when you needed to add things you had 9 lines you could do it with and thus you end up having to redirect the program to lines far down the line and then make sure it returns to the right point."Spaghetti code absolutely is a thing today?
The modern foundation of software design (OOP) is encapsulation, data abstraction, polymorphism and inheritance. If your objects are properly designed, they should not directly interact with other objects that are logically unrelated. That's why techniques and design patterns such as Dependency Injection are a standard.
But I digress, the point is that not properly following these principles is regularly considered "spaghetti code".
Also, using the Blueprints has other reasons that Scott didn't mention. There isn't a great VCS for Blueprints, which makes working in a team difficult. It's not just Scott that states using Blueprints for large portions of a game isn't viable.
I'd respond even more, but I just wanted to point out some issues from your posts on "page 2" before others took you seriously.