Skip to main content

Forums / Games / Halo: The Master Chief Collection

You know nothing about development.

OP Homicidal Puppy

  1. 1
  2. ...
  3. 2
  4. 3
  5. 4
  6. 5
  7. ...
  8. 7
BUS DR1V3R 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.
At least someone else on here gets it. All valid points.

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.
Were not software developers. We are consumers, and were sold an unfinished broken game. We don't have to have knowledge of 343's inner workings to be upset about that.
This. Stop defending 343i incompetents on making a working a game.
Were not software developers. We are consumers, and were sold an unfinished broken game. We don't have to have knowledge of 343's inner workings to be upset about that.

This. Stop defending 343i incompetents on making a working a game.
Incompetence*

LOL
A lot of people seem to be complaining at the thought of anyone at 343 doing anything that isn't fixing matchmaking, for example, fixing sound bugs, adding new game types, adding Spartan Ops, making improvements to Campaign.
Seriously? You obviously don't know a single thing about what it is like developing a piece of software as a group. They can't just make everyone at 343 work on matchmaking. The sound guys can't do anything about it. Neither can the art guys. They can only work on sound or art, so they will obviously only be able to work on improvements which they have the skill to complete, for example bringing new additions to the offline portion of the game, or fixing less overt bugs in Campaign.
Furthermore, there will only be a select team of people that have familiarity with the matchmaking portion of the software, so even people who are programmers can't necessarily be moved over to matchmaking. You'd end up wasting more time trying to get them to grips with the brand new sections of the code which they have never seen before, so you can't necessarily pull over the guys that are working on porting Spartan Ops, or fixing Campaign glitches, and make them all work on what is essentially networking, and compliance with brand new Xbox One social architecture.
That last part is also important to keep in mind if you're thinking of moaning about how this all worked fine on the original Halo games, "so why are they failing on this now?! HOW BAD ARE THEY?!?!?!!!!111111TROL11"
Xbox Live, and its social functions, are completely different to how they used to be. The social elements of Xbox Live are now managed by a separate OS which runs alongside the component which runs the games. You can't just port the code over, or even use it as a guide to solve the same problems. Its like taking two completely different jigsaw puzzles with completely differently shaped pieces and trying to force them together with a hammer. It just won't work, you need to re-engineer all the ways in which your game communicates with any other machine.
343 have obviously screwed up in a lot of ways, but try to be less ignorant about it?
That feel when I'm actually making an fps right now. Its one of the more simple games to program when its multiplayer only and I can guarantee you its matchmaking system will -Yoinking!- work
Most of you people seriously have no clue what OP is explaining. He is absolutely correct (fact, not opinion). Stay in school, kids.

Yes, all of us, including OP spend $60. Yes, we deserve a product that works and it is BS.

Just re-read his post... if you're not embarrassed by replying with the 'We spent $60 blah blah" then you sure don't have the 'get it' switch.

Hint: Us getting robbed, which we did, is NOT relevant to THIS thread...
OP is a hypocrite who doesn't know what he is talking about

We don't knowhow 343 works and OP doesn't know so take your own advice OP
Were not software developers. We are consumers, and were sold an unfinished broken game. We don't have to have knowledge of 343's inner workings to be upset about that.
boom, headshot. end thread.
Another pointless thread, good attempt tho op.
Hexor wrote:
I've been thrown into situations where I have to learn a new programming language or library in a day.
I call -Yoink-. learn a new version of something in a day? sure. Derivative of something you already know? Ok i buy that.
learning a whole new language that you have no prior/related experience with in a day? -Yoink-.

I understand what the OP is saying. He never said that we don't have a right to complain. He was implying that we shouldn't complain about fixes like lowering volume and adding sound to the countdown timer because they arent big fixes we are all hoping for. The people who fixed that would not be the ones working on the networking for matchmaking so its totally fine that they "fixed" that stuff. It's NOT taking away resources from the other things they need to do. stop -Yoinking!- like "gahh 343 sux! why are they adding a countdown beep when they should be FIXING MATCHMAKINGGGG!!!!"

Thats just stupid.

We SHOULD be pissed that this game was released in such a poor state. Pissed at 343 for not having the balls to tell Microsoft they weren't going to turn over the final build because it wasn't done, and more pissed at Microsoft for forcing the deadline when the product so clearly wasn't finished.
Hexor wrote:
Were not software developers. We are consumers, and were sold an unfinished broken game. We don't have to have knowledge of 343's inner workings to be upset about that.


This. Stop defending 343i incompetents on making a working a game.


Incompetence*

LOL
"Incompetents" is also a word, and considering that he said "343" and not "343's" means that his choice of wording works, while yours wouldn't ;)
A lot of people seem to be complaining at the thought of anyone at 343 doing anything that isn't fixing matchmaking, for example, fixing sound bugs, adding new game types, adding Spartan Ops, making improvements to Campaign.
Seriously? You obviously don't know a single thing about what it is like developing a piece of software as a group. They can't just make everyone at 343 work on matchmaking. The sound guys can't do anything about it. Neither can the art guys. They can only work on sound or art, so they will obviously only be able to work on improvements which they have the skill to complete, for example bringing new additions to the offline portion of the game, or fixing less overt bugs in Campaign.
Furthermore, there will only be a select team of people that have familiarity with the matchmaking portion of the software, so even people who are programmers can't necessarily be moved over to matchmaking. You'd end up wasting more time trying to get them to grips with the brand new sections of the code which they have never seen before, so you can't necessarily pull over the guys that are working on porting Spartan Ops, or fixing Campaign glitches, and make them all work on what is essentially networking, and compliance with brand new Xbox One social architecture.
That last part is also important to keep in mind if you're thinking of moaning about how this all worked fine on the original Halo games, "so why are they failing on this now?! HOW BAD ARE THEY?!?!?!!!!111111TROL11"
Xbox Live, and its social functions, are completely different to how they used to be. The social elements of Xbox Live are now managed by a separate OS which runs alongside the component which runs the games. You can't just port the code over, or even use it as a guide to solve the same problems. Its like taking two completely different jigsaw puzzles with completely differently shaped pieces and trying to force them together with a hammer. It just won't work, you need to re-engineer all the ways in which your game communicates with any other machine.
343 have obviously screwed up in a lot of ways, but try to be less ignorant about it?
I'm glad you posted this. Most people try to use software lingo to try and force their opinions on others as fact. I can tell you now that most people in the vinegar filled forums have no idea.

+1 For OP.
Hexor wrote:
BUS DR1V3R 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.

At least someone else on here gets it. All valid points.

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.
Yet MCC was outsourced to many different companies while H5G beta was in house. What 343 did for MCC could be completely different than what Blur or Certain Affinity did.

Essentially More companies = more hands in the code = more things overlooked. Just looking in my Programming class, each person has their own way of programming. One person could be placing 50 lines of code to get a simple "Hello World" while another might use 10 lines and vice versa.

H5G was in house and could be worked on without any real problems because it could watched from start to finish.
ROBERTO jh wrote:
Want to know what I know about game development. It's a job like any other where there are expectations to be met. They failed and deserve every bit of criticism that they get. If the company was dissolved after this failure I would not be surprised. In fact 343i is lucky that they have Microsoft watching their backs.

Microsoft is the reason this got -Yoinked!- up in the first place. 343i didn't set the deadlines, and they didn't even see a cent of the revenue the game brought in--that's all on MS. 343i got screwed worse than we did because very few people actually understand that they were put in an impossible position for a ludicrously difficult, never-been-done-before project.

Publishers are almost always to blame to a game's failure.
It was 343I who had the idea for the MCC, not Microsoft. But people need to stop the unnecessary hate. I mean seriously, they shipped a broken game, yes, but nobody can do anything about it except support 343I while they fix it (which they are doing). If you don't want to support it and only come to these forums to spout mindless rage in capital letters and threaten foundation-less legal action then I'd think about how you're spending your time.

I'm not talking about you Roberto, just some members of this forum.
Artych wrote:
Hexor wrote:
BUS DR1V3R 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.


At least someone else on here gets it. All valid points.

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.


Yet MCC was outsourced to many different companies while H5G beta was in house. What 343 did for MCC could be completely different than what Blur or Certain Affinity did.

Essentially More companies = more hands in the code = more things overlooked. Just looking in my Programming class, each person has their own way of programming. One person could be placing 50 lines of code to get a simple "Hello World" while another might use 10 lines and vice versa.

H5G was in house and could be worked on without any real problems because it could watched from start to finish.
Well said guys. And a lot of people forget that Halo 4 worked just fine at launch, it's not like 343I are the incapable developers that many would have you believe.
Artych wrote:
Hexor wrote:
BUS DR1V3R 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.


At least someone else on here gets it. All valid points.

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.

Yet MCC was outsourced to many different companies while H5G beta was in house. What 343 did for MCC could be completely different than what Blur or Certain Affinity did.

Essentially More companies = more hands in the code = more things overlooked. Just looking in my Programming class, each person has their own way of programming. One person could be placing 50 lines of code to get a simple "Hello World" while another might use 10 lines and vice versa.

H5G was in house and could be worked on without any real problems because it could watched from start to finish.
I'm referring to matchmaking and networking here which was done by 343. It was done in house. Doesn't matter how many companies were outsourced for other tasks.
Erik L wrote:
Hexor wrote:
Were not software developers. We are consumers, and were sold an unfinished broken game. We don't have to have knowledge of 343's inner workings to be upset about that.


This. Stop defending 343i incompetents on making a working a game.


Incompetence*

LOL

"Incompetents" is also a word, and considering that he said "343" and not "343's" means that his choice of wording works, while yours wouldn't ;)
Yes, I took a gamble that it's more likely that he didn't include the 's and misused "incompetents". (Have you ever seen someone write "past tents"? I've seen it a lot more than I should). Using the sentence as is is very awkward English. If it is "incompetents", why would the be incompetents if they made a working game? If it was "incompetence", it means that they are unable to make a working game.
I'm actually a software developer and was very disappointed to see how MCC was released in its broken state. It's been almost 3 months since launch and the game is still buggy. Solo queuing works fine (except for times when it doesn't with uneven teams), but party queuing has been awful. Not to mention a lot of random overlooked insights, such as taking 4-5+ button presses just to change teams in the lobby when past Halos it was 1-2.
Hexor wrote:
Artych wrote:
Hexor wrote:
BUS DR1V3R 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.


At least someone else on here gets it. All valid points.

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.


Yet MCC was outsourced to many different companies while H5G beta was in house. What 343 did for MCC could be completely different than what Blur or Certain Affinity did.

Essentially More companies = more hands in the code = more things overlooked. Just looking in my Programming class, each person has their own way of programming. One person could be placing 50 lines of code to get a simple "Hello World" while another might use 10 lines and vice versa.

H5G was in house and could be worked on without any real problems because it could watched from start to finish.

I'm referring to matchmaking and networking here which was done by 343. It was done in house. Doesn't matter how many companies were outsourced for other tasks.
Of course it matters... The more variables the more opportunities for errors, networking or otherwise. There were too many cooks in the kitchen.
Erik L wrote:
The 'you couldn't do it better' argument is fundamentally flawed, and becoming tiresome.


That's not the argument at all. The argument is that even if 343i took all of their engineers and put them in matchmaking, not only is it possible that they are not skilled enough in network programming to do the job well, but it would also slow the original engineers down while they get the new engineers up-to-speed. See Brook's law:
Quote:
Brooks's law is a claim about software project management according to which "adding manpower to a late software project makes it later." It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. According to Brooks, there is an incremental person who, when added to a project, makes it take more, not less time.
Note that this does not excuse MCC from being broken or say that we shouldn't complain. Yes, all of this should've been taken care of prior to the game's launch. The point is that now that we are in this situation, simply assigning more people to the project won't necessarily fix it faster, and could actually end up fixing it slower.
I agree with the concept that 343 shouldn't be focused on fixing matchmaking exclusively. There are gamebreaking crashes in campaign co-op that are reproducable. There are no audio settings to adjust the volume mix. Splitscreen is unplayable due to framerate. Yes matchmaking needs to be fixed, but there are other concerns that should also be addressed.
  1. 1
  2. ...
  3. 2
  4. 3
  5. 4
  6. 5
  7. ...
  8. 7