But that's completely different from how Unreal typically does it. Movement is client-side predicted and server authoritative out of the box. How does SpacetimeDB even know the collisions of my level?
If I were to cheat and disable all wall collisions on the client. An Unreal server would roll me back, to all other people it would look like I'm walking into the wall. How do you even get SpacetimeDB to run Unreal's runtime (because movement kind of depends on deterministic results for frames). How does SpacetimeDB get hold of the assets (collisions)?
I am always skeptical about these type of projects. Out of the box Unreal Engine supports C++ and Blueprint.
The problem with C++ is the slow compile times, and if you make mistakes the engine crashes. In general you produce stuff slower by using C++.
Blueprint is a visual scripting tool, it compiles fast. But it stores code as a binary blob in source control. And I'm personally not a fan of visual scripting, I would prefer scripting by just writing code.
So generally I prototype in Blueprint and then rewrite in C++ later on. I would love an intermediate language that has fast compile times and saves as a source file instead of a binary blob.
The problem is most of the projects that integrate with another language get abandoned after a while. MonoUE was abandoned, USharp was abandoned, now the newest attempt to integrate UE with C# UnrealCLR looks abandoned. SkookumScript doesn't support UE5. Haxe support for UE was abandoned.
Do I really want to risk writing a ton of code in a language that might not support future engine versions? To be honest, I don't want to take that risk.
If I were to cheat and disable all wall collisions on the client. An Unreal server would roll me back, to all other people it would look like I'm walking into the wall. How do you even get SpacetimeDB to run Unreal's runtime (because movement kind of depends on deterministic results for frames). How does SpacetimeDB get hold of the assets (collisions)?