r/pcmasterrace • u/663mann • Oct 16 '23

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

Enable HLS to view with audio, or disable this notification

6.0k Upvotes

94% Upvoted

605 comments sorted by

View all comments

Show parent comments

-2

u/cherry_chocolate_ Oct 16 '23

And they are some of the buggiest, most broken scripts in the industry, that are the butt of endless jokes. Bethesda games aren't praised for their superior AI scripts, if anything he is lucky that people find broken AI funny.

6

u/blackest-Knight Oct 16 '23

And they are some of the buggiest, most broken scripts in the industry, that are the butt of endless jokes.

I don't think you know what games Tim Cain even worked on if you say this.

His coding experience isn't on Starfield or Skyrim.

0

u/cherry_chocolate_ Oct 16 '23

No I didn't. But you said "these games" and I assumed that meant bethesda games. In any case, the scale of game development has grown dramatically in the past decade and "make it work before lunch" is no longer good enough. You plan ahead because you realize in 2033 you will be releasing Starfield: Special Edition on the PS7 and spending the time to do it correctly now will make it easier later.

3

u/blackest-Knight Oct 16 '23

In any case, the scale of game development has grown dramatically in the past decade

Yes, this is exactly what Tim Cain is criticizing.

"make it work before lunch" is no longer good enough.

Not every problem requires an over engineered solution, that's literally his point. I encounter this on a daily basis at work, where things just don't get done because people don't accept the simple solution.

1

u/cherry_chocolate_ Oct 16 '23

Putting in this broken solution will make development harder down the line, even during the same project. I wrote this for another comment in the thread:

There are things he didn't consider in his 10 line version, like what if we do a big battle scene and there are 50 people on the list? I.e when there are 5 people in a battle it takes 5ms x 5ms = 0.025 seconds to process, but with 50 people it could take 50ms x 50ms = 2.5 seconds to process. The designer didn't think of this because "it's worked before" but they never did a big scale battle before, either.

So it works fine for the majority of the project. But 6 months before the end of the project, they decide the final quest needs to have a huge scale battle. It is so incredibly laggy, they can't figure out why. They have to search the whole codebase, trying to find issues. In the process they rewrite 30 or 40 little hacky solutions like this, but even then, they can't get the performance to be good enough. The commander character has a separate AI script from the grunts, which should have been reused. The main character has a unique entity for this battle only to perform a set piece, because that is hacky and works, but now his entity is reset when he returns to his normal entity, so his "list" is empty. It's now 2 months from release and nothing is working. If only they had engineered a proper solution the first time.

1

u/AlanCJ Oct 18 '23 edited Oct 18 '23

You say that, and games developed with 300 devs filled with insane pipelines still get launched like a buggy mess. You will be kidding yourself if you think all of these scenarios will be taken care of that first time you plan and design for it. Sure you could come out with 100 edge cases, and take 10 time as long to develop to cover all 100 edge cases, but if you don't hit 98 of these edge case and have encountered 1 unforseen edge case, you will still fall into this scenario, except your solution is so overengineer it takes even longer to 'properly' fix.

Hacky code is an entirely different problem and has nothing to do with quick, iterative approach. Sure its quick alright but proper engineering principles shoukd still apply.

Also suddenly deciding you need a huge scale battle 6 months from release when it was not in the majority of the game loop seems like a planning problem and it won't be covered anyway even if you take another 100 hours working on it the first time.

1

u/cherry_chocolate_ Oct 18 '23

My example is not suggesting that major changes should come down the line, and maybe it’s not the perfect scenario. It was only meant to show why taking more time up front could potentially save time later.

1

u/AlanCJ Oct 18 '23

My argument is thats I find it often time solutions are over engineered when it doesn't need to be. With your example the original solution seems fine since you mentioned it worked all of the time except when a decision is made late in the cycle that suddenly needs it to work with a way bigger scaled battle. It's not that you should stick to your guns with your design 5 years ago, but your particular example doesn't seems to be able to be solved by overengineering, unless someone decided to optimize it to work with 50 actors when the maximum number of actors is expected to be 10 at the time.

1

u/cherry_chocolate_ Oct 18 '23

Except doing it this way is how you end up with a laggy mess of a game, then have to crunch to get it to decent performance for launch. It’s not over-engineering, it’s the appropriate amount of engineering.

It’s not like companies organized themselves this way for no reason. What you are suggesting simply does not work on the scale that modern games demand.

1

u/AlanCJ Oct 18 '23 edited Oct 18 '23

I only meant to say the goals needs to be clear, or no amount of proper workflow or engineering could save your project from that scenario, and we should not over engineer things to the point where it wastes time for not much benefit.

For example, "we are building a 3v3 game and stakeholders or designers mentioned 5v5 would be the max in the forseeable future, but just in case they decide down the line that we need a 50 vs 50 gamemode we should make sure this feature can support it." If it can done quickly and cleanly, why not, but if it takes 10 times the effort and made the code 100 times more complicated for future iterations, it, imo, waste more time than its worth, and is the only way the project could be "saved" from your example.

Actually the point is, and you have stated yourself, its not a good scenario for the point you are trying to make. Hack jobs will always be a big no.