At least someone else on here gets it. All valid points.BUS DR1V3R wrote:Jesus of all wrote:BUS DR1V3R wrote:
Game code is not inherently more unreadable, or harder to understand, than any other code. That's what commenting, coding standards, and documentation is for. If you can't read and understand that stuff, then you have bigger problems. Millions of lines of code, maybe. Out of those millions of lines of code, I'm willing to be less than a tenth of it is networking related.
At the end of the day, game engines are made out of modular systems. Each system can be broken down into a diagram of moving pieces. Once you understand that, you understand the system. It's engineering, and it's nothing new.
Also, I have no insight into the codebase, but I'm not sure why writing a thin wrapper layer for networking would be that difficult. It's not like they haven't totally ignored about half of the functionality of all of the games anyways.
As for the Xbox One APIs, no other games seem to be having issues with them. APIs are literally built with ease of use in mind, and NO ONE ELSE IS HAVING ISSUES.
Bureaucracy has nothing to do with an engineer's ability to perform their job.
Game code is not "inherently" more unreadable but the reality is that it is, because you have to constantly optimize, hack, and change stuff. If you've ever been dropped into a complicated modern game that's already in progress then you will know what I mean.
The fact that you call yourself an engineer is pretty indicative of the problem. It is a lot easier to apply sound development practices, design patterns, etc., when you don't need to worry about performance or memory. If you look at actual game code (no, not Doom), a lot of it is manual bit shifting, gross hacks, weird global functions and macros, comments that aren't kept up to date, global state management, and 10000 lines of code in a single file that's commented out and you have no idea what it's for or if it might be useful.
I always love it when I get to work on some business technology or web application. I love thinking of myself as a software "architect", or "engineer", or "designer". I love to believe I'm writing Clean Code™. But in games there is a lot of pressure to get stuff done and to have the game take full advantage of the hardware.
I've heard the MCC is using an experimental networking API, but that could be a rumor. If not, then yes, whoever was responsible for the networking code and server infrastructure should probably be fired. That stuff is generally fairly easy these days. In any case, it could just be me, but XBL on the X1 seems like absolute -Yoink-.
Bureaucracy has quite a bit to do with an engineer's ability to perform their job, my friend. Oh god, does it ever...
You seem to be speaking more to the side of gameplay programming, which is the "hackier" side of game development. I have worked on modern games, and come in mid-alpha. Most systems outside of gameplay are very well architected and solid.
Sound development practices and design patterns have nothing to do with poor performance, or inefficient memory usage. Let's try to provide more context to the game code issues you've listed.
Bit shifts - Usually math hacks(fast divide/multiply) or endian shifts, have nothing to do with design patterns or memory usage but can boost performance.
Gross hacks - This is what code reviews are for.
Global functions - These are gross, I'll give you that, but are usually caused by legacy code. They should be refactored when necessary.
Macros - These are common in all code bases, not just games, and are usually just small inline functions. Meant to force inline functionality and reduce cost of change.
Global state management - This is used in literally all software that has states. The Android OS even has global state management.
Everything else you've mentioned is indicative of poor code health. Probably legacy code that was written before code reviews were standard practice. This is not a product of game code, all legacy code bases suffer from these issues.
You seem to take issue with me referring to myself as a software engineer, and the fact that I don't make excuses for writing poorly documented and readable code. What about that leads you to believe that my code is not performant and memory efficient?
If they are using an experimental API, they picked a hell of a title to test things out on. I'm willing to bet they won't roll the dice like that anymore.
The one thing I might add is if the new API is causing the issues why have they not rolled back to an older version or different API? My theory is this is what they are doing in the next CU that they are releasing the beta for. If this is true, kudos for them for doing something right but it shouldn't have taken them 2 months to figure this type of thing out.
Secondly, they had it working in the Halo 5 beta... Why not update MCC to use whatever system/APIs that Halo 5 did? This could be what the CU is doing.