[stcredzero]

Most games don't make these mistakes...it seems they weren't aware of some other best practices.

I see this time and time again. Game developer runs into one of the difficult subjects in computer science/programming. Dismisses the difficulty. Gets themselves into trouble. Blames the library/product/platform.

The last time I was at a game jam, I found myself explaining generational garbage collection to a game dev. He then proceeded to "solve" all of his problems by writing a 5 minute hack to ensure all of his objects would be collected as quickly as possible. Which didn't work, because the lifespan of his objects is dependent on gameplay, so he can't ensure all of his objects will die in Eden. I kept trying to explain that he should actually hold onto his objects (especially bullets in his bullet hell game) and recycle them as much as possible, so that he would reduce memory pressure and have those objects promoted to old space, so they are looked at less often.

I see this sort of thing time and time again.

[ThrowawayR2]

> I see this time and time again. Game developer runs into one of the difficult subjects in computer science/programming. Dismisses the difficulty. Gets themselves into trouble. Blames the library/product/platform.

Members of this particular team worked on the highly acclaimed Total Annihilation (1997) and Supreme Commander (2007) so inexperience or lack of technical expertise seems unlikely to be the cause here.

[politician]

Parts of PA are brilliant, absolutely brilliant. The team pulled off some incredible feats:

- In a 16-player game, each player can operate thousands of units across multiple planets orbiting a star, and afterwards, you can replay the match exactly within your own copy of the game.

- The planets themselves were mobile battlefields which could be destroyed, moved, and weaponized.

- The path-finding for those thousands of units crashing into an opposing army of thousands of units is smooth and there isn't total chaos on the field.

But the team also made some really questionable bets that ultimately doomed the title.

- Then, for some reason, they used an out-of-proc UI compositor to draw the 2D elements that would fork one process per layer IIRC and drop interaction events, and broke the tool that the players use to interact with the wonderful simulation.

- Then, for some worse reason, they launched it like this, and reaped the terrible early reviews that doomed the title. Even after patches resolved the issues, the long-term damage was done.

[stcredzero]

So they have no excuse for missing out on those other best practices.

[reitzensteinm]

What on earth has a generational gc and can't handle a little bullet spam?

[jungler]

Nearly any per-frame instancing tends to hit generational boundary cases due to ambiguity over lifetimes that the VM can't account for. They usually don't result in GC pauses that are large enough or frequent enough to make the game unplayable, but they do prevent the desired "solid 60hz". It's actually a huge thorn in the side of fast gameplay code. Recommendations always turn towards engineering a static allocation(value types if you can do them, object pools if not). However it takes enough effort to build the latter that quite a few games running on GCs ship without doing it in all cases, and some runtimes make it borderline impossible(string processing).

[reitzensteinm]

OP was at a game jam, though. They were building a prototype. If they were going for a smooth 60hz, they were doing it wrong.

If there were pauses causing significant gameplay issues, it's doubtful GC was the specific cause. There was probably something very wrong being done - my guess would be instantiation of a managed resource like a texture or 3d model.

I doubt generational GC came in to it, and feel like the OP is prematurely celebrating his own insight in to what was causing the issue.

(Then again, maybe it was a VR game and pauseless 120hz was the goal.)