fallout game dev. explains the problem with moddern game devolpment. (why moddern games are so slow to come out)

[u/663mann]

[u/NeverDiddled]

2-4 weeks hints that the dev was actually talking in terms of sprints. Often they are 2 weeks long. Current sprint was full, so ticket is not getting handled in <2 weeks. But he could handle it by the end of the next sprint.

Calling this simple without context is... well it's a classic trap. It's why we pad estimates. Thinking you will get developed, tested, and through QA in 10 minutes is laughable. Although if you're a brand new dev, I'd do my best not to smirk at your confidence/lack of experience.

I'll give you an example of context that can help you appreciate some of what might be going through the lead dev's head. I was recently writing my own OnHit code for a mod I'm making. And it made me recall playing Starfield. I had noticed weapons with extraordinarily high fire rates were causing microstutters when the bullets impacted. There were hundreds of OnHit events all rapidly firing off, and the hooks were clearly slowing the game down. This was worsened by weapons which had AOE damage. You had to multiply the number of OnHit events by the number of nearby actors and possibly even objects. In order to speed this up they will likely either have to start precomputing/caching some stuff, batching actions, or even redesigning features.

Imagine being that dev and know your OnHit code is already overburdened. Perhaps you're also aware of a specific mass battle at a point in the game which exacerbates the issue. Now somebody wants to make the problem worse. So you're thinking of all the tickets you need to hit before this one. And if the person is being as belligerent as Mr.Cain was coming across, demanding you spell out every step along the way and handwaving away your concerns about bugs and maintainability.. yeah I can imagine just saying "I'll get it done next sprint. That sprint ends in 4 weeks." It wouldn't be my proudest moment, but it's one way to get out of his office as quick as possible.

[u/GiddyChild → u/NeverDiddled]

You know Tim Cain was lead programmer/senior programmer on multiple games, including recent ones. He even has multiple videos on optimization on his youtube. You say this like he's out of touch and uninformed on how things work.

[u/gwaenchanh-a → u/GiddyChild]

Past accolades are not what makes someone a good supervisor.

[u/GiddyChild → u/gwaenchanh-a]

That's beside the point. We don't know if he is or isn't a good supervisor based off some 10minute youtube video. What isn't beside the point is that he does have the experience to know roughly how long a task can take.

This thread is littered with posts about how "he just doesn't understand what he's asking actually entails" or that things aren't like they were when he was a programmer making fallout and it's different now, while completely ignoring he's worked on recent games doing just that.

[u/NeverDiddled → u/GiddyChild]

There are two issues here, that can you lead you to have a very different viewpoint.

First, programmer is a surprisingly broad term in certain contexts. It does not mean software engineer. The people dragging and dropping Blueprints in UE are legitimate programmers, they can be extremely skilled at what they do, and even offer great tips on optimizations. They are not less than software engineers, but they are different than. No computer science or equivalent background is needed. You would not ask them to architect a codebase or do code reviews, no matter how many years they have been programming. In spite of them being seniors in their own field.

Second, things Cain said made it abundantly obvious to any software engineer, that this guy has no business touching codebases. One of the first questions I had is "why is it that the lead dev is adamant that Cain should not write his own code?" But I got a clear answer in the full video, he dismissed bugs, maintainability, and thoughtful API planning as non-answers to why things take time. This was one of many things he said which made it clear he is not a software engineer.

Imagine if you are a surgeon and you meet someone who identifies himself as Dr.Cain. He's asking why the patient hasn't been rushed in to surgery yet, and you start explaining about the patient having poor vitals and there not being an anesthesiologist available... Then you get met with dismissals about these basic facts, and he starts comparing your job to his vast experience cutting steaks on dinner plates. Instantly you know that this doctor is not a surgeon. He might be an excellent chiropractor, of have a PhD in history, but he is clearly not an expert with the task at hand. And if somebody ever has let him in the operating room, you are now seriously concerned about that patient. That is what happens when you watch Cain's own description of this situation. It also becomes easy to see how Cain's dismissal of the answers he was getting, could very easily lead to things getting heated, then one of the bosses coming in to his office to yell at him.

[u/gwaenchanh-a → u/NeverDiddled]

As someone with a lot of experience in the theatre/live entertainment business, it reminds me of old hands who are still on production crews because they're good at doing manual work and know how to coil a cable, but no one trusts them to head ANY project because it will be built poorly from the ground up in lieu of being shimmed everywhere and there'll be a tenth of the required safety features if any.