3 ms·

In games it happens quite a bit. The great debate is always "will I want to change this tiny thing here without impacting everything else?" vs DRY. Studio cult

In games it happens quite a bit. The great debate is always "will I want to change this tiny thing here without impacting everything else?" vs DRY. Studio cultures differ, but I would say at least half resort to hard coding things like positions of every item manually given the excuse they might want to shift something by a bit later (in a hurry, crunching etc.) without side effects. Thankfully the emergence of more standard tooling and engines has pushed this to being more of an art resource concern, but it does lead to things like being told that taking a game that assumes a 16:9 1080P display and making it more flexible will take multiple years of person time. Personally I cannot stand this tendency, but do get why they do it.

hinkley 3y ago
You can get pretty close to the end of a project before you really understand what it was you were trying to do. Especially if management is allowed to keep moving things on you. I think this is substantially the instinct that leads to Waterfall. I just want to know what I'm supposed to be building for a while before you 'ruin' it.
- tomcam 3y ago
  > You can get pretty close to the end of a project before you really understand what it was you were trying to do. Truer words were never spoken.
  - fidotron 3y ago
    In my case the insight happens about 3 weeks after the project was delivered.
    - hinkley 3y ago
      "You were serious about that?"
    - tomcam 3y ago
      Holy shit that knocked the wind right out of me!
- ClimaxGravely 3y ago
  Definitely. I've worked on my fair share of projects where the game is essentially completely changed midway or late in development. Stuff like "this single player game we've been working on for 2 years now has to be a multiplayer game". That was a fun one. In other industries I've been able to reasonably strategize for various changes but in games the change can be so profound and out of left field it's pretty much impossible to anticipate the change and plan for it.
  - hinkley 3y ago
    “We are never going to internationalize this software.” “We just discovered a thing called a globe.”
    - fidotron 3y ago
      Oh damn, one of the worst was the game was practically finished and “we just did a publishing deal, it is great, you just need to support 13 languages” “which?” “Arabic” . . .
maccard 3y ago
I think the days of that happening are mostly gone. In the days where games were one-and-done, gameplay code was like this, but in the age of sequels & live service games, game code is as good (or bad) as any other code.
lunaticlabs 3y ago
To frame this, I actually worked at Sony as a software engineer on the Playstation when Wipeout came out, so I have some firsthand insight into developing games around this time. When it comes to older games like this, there were a bunch of compromises that we had to make that introduced additionally complexity, that are entirely overlooked here. You're looking at this from the perspective of how a computer/processor works now, and what it is like to develop software without having to take into actual account the limitations of the hardware and processor itself, as a part of your code design. For example, the Playstation 1 had a MIPS R3000 CPU, and a single instruction pipeline, so it's basically doing only doing 1 thing at a time. Multithreading doesn't exist. Our only parallel processing was that we could do all the game logic + all the math to transform all the triangles into screen space, and simultaneously the GPU would be drawing the last frame we drew. We had 4MB of memory total, so when we were were working on games then, we would have actual discussions about whether it was worth the overhead of including a malloc/free, or just hard-coding all your memory addresses because of the space you'd save. We would compile out our abstracted, "nice" versions of functions, count the instructions, and compare sizes to see where we could optimize the code to reduce the compiled output size. In return, we might be able to draw an extra triangle or two. The instruction and datacache were tiny, and loaded based on address, so sometimes we would add code or instructions that didn't do anything just to make a loop not cross a cache boundary. So we were working on under strict time pressure, with unknown hardware and badly translated japanese print manuals (and sometimes not even translated), in small teams without any real ability to communicate with anyone else in the industry about it (since we are all under NDA). I'm not saying that we didn't write bad code, we did write plenty of it, but a number of the decisions on HOW to write the code itself that we were considering then aren't even visible to people reading the code now and making judgements on it. I knew I was writing spaghetti code some of the time, because I didn't have the memory budget to load it as data. Is there a cleaner way to do their UX and in a data-driven fashion? Sure. But for me to get that data, I would have to write a function to load a/multiple blocks of data from a 1x CD that a super low transfer rate, and an appallingly long seek times. Making a data-driven UI is possible, but not practical when someone hits the start button, they want the menu to come up immediately. In many cases, we knew that we were writing bad code, but didn't have the capacity to write anything better. It literally didn't fit our budget for memory or CPU. Then you have to make decisions about where you CAN afford an abstraction, and those decisions can be quite painful. I haven't violently disagreed with anyone in any of these threads, but did want to offer a bit of my first hand perspective on things that are often overlooked.

hinkley 3y ago

You can get pretty close to the end of a project before you really understand what it was you were trying to do. Especially if management is allowed to keep moving things on you. I think this is substantially the instinct that leads to Waterfall. I just want to know what I'm supposed to be building for a while before you 'ruin' it.

tomcam 3y ago
> You can get pretty close to the end of a project before you really understand what it was you were trying to do. Truer words were never spoken.
- fidotron 3y ago
  In my case the insight happens about 3 weeks after the project was delivered.
  - hinkley 3y ago
    "You were serious about that?"
  - tomcam 3y ago
    Holy shit that knocked the wind right out of me!
ClimaxGravely 3y ago
Definitely. I've worked on my fair share of projects where the game is essentially completely changed midway or late in development. Stuff like "this single player game we've been working on for 2 years now has to be a multiplayer game". That was a fun one. In other industries I've been able to reasonably strategize for various changes but in games the change can be so profound and out of left field it's pretty much impossible to anticipate the change and plan for it.
- hinkley 3y ago
  “We are never going to internationalize this software.” “We just discovered a thing called a globe.”
  - fidotron 3y ago
    Oh damn, one of the worst was the game was practically finished and “we just did a publishing deal, it is great, you just need to support 13 languages” “which?” “Arabic” . . .

maccard 3y ago

I think the days of that happening are mostly gone. In the days where games were one-and-done, gameplay code was like this, but in the age of sequels & live service games, game code is as good (or bad) as any other code.

lunaticlabs 3y ago

To frame this, I actually worked at Sony as a software engineer on the Playstation when Wipeout came out, so I have some firsthand insight into developing games around this time. When it comes to older games like this, there were a bunch of compromises that we had to make that introduced additionally complexity, that are entirely overlooked here. You're looking at this from the perspective of how a computer/processor works now, and what it is like to develop software without having to take into actual account the limitations of the hardware and processor itself, as a part of your code design. For example, the Playstation 1 had a MIPS R3000 CPU, and a single instruction pipeline, so it's basically doing only doing 1 thing at a time. Multithreading doesn't exist. Our only parallel processing was that we could do all the game logic + all the math to transform all the triangles into screen space, and simultaneously the GPU would be drawing the last frame we drew. We had 4MB of memory total, so when we were were working on games then, we would have actual discussions about whether it was worth the overhead of including a malloc/free, or just hard-coding all your memory addresses because of the space you'd save. We would compile out our abstracted, "nice" versions of functions, count the instructions, and compare sizes to see where we could optimize the code to reduce the compiled output size. In return, we might be able to draw an extra triangle or two. The instruction and datacache were tiny, and loaded based on address, so sometimes we would add code or instructions that didn't do anything just to make a loop not cross a cache boundary. So we were working on under strict time pressure, with unknown hardware and badly translated japanese print manuals (and sometimes not even translated), in small teams without any real ability to communicate with anyone else in the industry about it (since we are all under NDA). I'm not saying that we didn't write bad code, we did write plenty of it, but a number of the decisions on HOW to write the code itself that we were considering then aren't even visible to people reading the code now and making judgements on it. I knew I was writing spaghetti code some of the time, because I didn't have the memory budget to load it as data. Is there a cleaner way to do their UX and in a data-driven fashion? Sure. But for me to get that data, I would have to write a function to load a/multiple blocks of data from a 1x CD that a super low transfer rate, and an appallingly long seek times. Making a data-driven UI is possible, but not practical when someone hits the start button, they want the menu to come up immediately. In many cases, we knew that we were writing bad code, but didn't have the capacity to write anything better. It literally didn't fit our budget for memory or CPU. Then you have to make decisions about where you CAN afford an abstraction, and those decisions can be quite painful. I haven't violently disagreed with anyone in any of these threads, but did want to offer a bit of my first hand perspective on things that are often overlooked.