Great article,
I am baffled nobody at R* cared to investigate a 6min load time that was there for years. Doesn't sound very AAA-gamedev to me.
I am baffled nobody at R* cared to investigate a 6min load time that was there for years. Doesn't sound very AAA-gamedev to me.
1. It's a boiling frog problem which developed over several years. It started fast when the JSON file was small but then got a little bit slower each time new content is added.
2. It's also not exactly an "interesting" part of the code base. IIRC it's a JSON file which configures the ingame shop(?). This was probably delegated to a summer intern to implement in a couple of days, maybe in an entirely different department from the people who develop the actual core game.
3. New shop items are probably added by a content team without programmers in the loop who would know by instinct that something must be wrong. People on that content team also most likely don't stay on that team for very long, which together with the boiling frog problem above means that everybody thinks "it's always been like that".
4. Any specific feedback from the outside probably gets lost in the noise of other requests.
5. ...plus a general 'not my problem' attitude common in big organizations and an always-full kanban board ;)
My theory is the fix existed internally but was never merged for weird political reasons. Some have guessed it was due to advertising being done on the loading screen. Or it could have been pure dysfunction, like how fixes for all the notepad.exe problems apparently existed at Microsoft for decades, but it took a full rewrite to have working undo.
The 'large-organization-dynamics' are all the same though across all industries. I bet enough people down in the trenches noticed, but nobody pushed enough to get the problem investigated and fixed. There's probably several dozen bug duplicates about that problem buried somewhere in GTA5's JIRA (and indeed probably also with exact instructions how to fix, and maybe even somebody did that work but then didn't push enough to get it integrated).
I work in a larger business but am dealing with a similar problem. Trivial implementation/fix; nearing two years into the effort.
What am I doing? Changing 'proxy.remoteURL' for our Docker registries from a painfully slow upstream to a faster one.
You can have people in pain with a solution in hand and still find it difficult to sell.
> You can have people in pain with a solution in hand and still find it difficult to sell.
"Well, we don't know what side effects that might have"
Actually, my understanding is that most devs don't really play the games they build, at least not in the way that people do. (Anecdotal evidence is that quality-of-life features tend not to come from developers very often). And even when they do play the games, internally, it's likely on an internal branch, with internal mocking of things like servers and the like, so a loading time bug that scales quadratically with content is unlikely to be something that would surface in internal playtesting. I also doubt they're playing their games on their own time; if you're already working 40 hours or so each week on the game, it's probably not a feeling of unwinding to put in another 5 or 6 hours on your own time after you come home from work.
My guess is that people noticed but nobody was in the right position to debug - their internal tooling may have been that this code path was usually skipped or behaved differently on internal builds. And debugging a full production build was something many devs didn't do because it was painful.
They're absolutely jacked workstations that probably loaded it in a blazing 2.7 minutes!
If there's a million fires and half of those crash the game, fixing something like a load time might easily stay under the radar.
And that's even before we consider internal political issues. The code could have been owned by a group that was refusing any PRs that would have fixed the issue. Or maybe the code was written by the big boss' nephew and fixing it would have removed his contribution.
Don't underestimate the power of complacency
If you extend the logic, what's the point of keeping any commits from years ago? What's a good cut off date to just start discarding history? Rewriting it?
But in the same breath, what's the point of cloning commits from years ago? It's not as if you'd cherry pick anything from back then. And that's my point, the former requires an org decision and active action, and the other is a blobless clone. The nice thing about the blobless clone is you can always change your mind, you can get old blobs if you find you need it. But if you threw out old commits, and you need them later... that's the brakes.
6 Minutes?!?!
Are we using Commodore 1541 FDDs again?
Per the article, most of that wait is garbage coding and that's apparently just fine, because....clowns will continue to buy it.
They won't be. They will push out worse and worse code and it's fine, because it's still being purchased.
Have you heard of a game called Fallout 76? or maybe Red Dead Redemption 2?
Both released as hot garbage and apparently, that was fine.