They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work.

My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it.

In my experience, RAII is my preferred pattern for certain things (std::lock_guard), and you can almost certainly express the majority of these "uber game dev patterns" using RAII/smart pointers/etc, but the c++ implementation of these "uber game dev patterns" tends to be more complicated (and imo esthetically ugly) compared to really well written C.

These new languages (zig, odin, jai) appear to be attempts to improve C to allow an alternative to C++ that doesn't have the ugly baggage that C++ has.

I hacked together world cloning in box 2d and am confident I could do it in box 3d as well. Especially with the record/replay/validate system to help guide the implementation.

I'll find a way to send you and Erin my project when I get it working (or when I fail)

Thank you for your time. I respect you deeply and have valued your work.

For box2d, in the past I added a function to delete the entire contact cache and then I experimented with either calling that every single frame on both client and server, or only during a rollback.

In one game, I did the former and in most others, I did that latter.

In those box2d games, the entire world was predicted/resimulated, including remote players. A smart smoothing technique was used on remote players to dampen network artifacts. It worked well, even sniper rifles worked well. (The player movement had a certain flavor)

I am currently building something custom on top of Jolt, but will experiment with box3d.

The smart detection of what needs to be resimulated is something I'm just about to start on.

My mind is turning on how partial resimulation could be done on top of box3d's 'keyframe' recording system....

My reading of Box3D's docs is that it has 'cross platform determinism', and 'recording/replay'? Isn't that sufficient?

Synchronize inputs, determine if inputs were 'mispredicted', if so, rollback the physics world, apply the changed inputs and resimulate?

Just for context: I implemented state-sync netcode into box2d in 2018 and shipped multiple real games using it - and I work on netcode professionally.

I'm planning on adding full netcode support for box3d and releasing it as part of a larger framework.

https://box2d.org/documentation3d/md_simulation.html#autotoc...

I might try to implement this paper, great find! I love this 2000-2010 stuff

Learning "the old ways" is certainly valuable, because the AIs and the resources available are bad at these old ways.

I'm offering real practical advice from experience of having worked on real projects.

I'll make it real clear:

GDScript & c++ > C#

The purpose of recommending c++ here is:

If GDScript is too slow, reach directly for C++.

I'm specifically recommending GDScript over C# for ease of use and c++ over C# for performance.

I've been going the other way, learning the old tools, the old algorithms. Specifically teaching myself graphics and mastering the C language. Tons of new grads know how to use Unity, how many know how to throw triangles directly onto the GPU at the theoretical limit of performance? Not many!

If performance is a concern, skip C# and go straight to c++. Now your ripping at max speed with the smallest binary! That's my whole point. GDScript + c++ is my point. Ditch C# it's not worth the squeeze.

You only dabble in the c++ for the sliver of the project that needs it. 90% of game development is animating stuff and user interface development. GDScript is great for that.

I won't even get into how big of projects I've written in GDScript successfully.