Hi @matthiasbruns welcome
This is a great question. In essence I think your assessment of the options are right though its a bit more nuanced so happy to discuss in detail here.
Though before we do that I’m unclear about this part “Reimplement deterministic physics” as far as I’m aware (though my knowledge is probably outdated) Unity engine does not have a deterministic physics implementation. If the game client runs on different CPU/architectures the simulations will differ in small ways. Has this changed?
- Reimplement deterministic physics in e.g. GO and manually replicate the game world in Nakama
You could reimplement the minimal necessary logic to do collision detection, ray tracing, projections, etc. to implement the logic for the entities in the game world. Some game teams have done this with a small amount of Go code and it works well especially when combined with netcode modelled in Protobuf or FlatBuffers.
Use unity headless server and communicate back and forth between Nakama and unity
For physics intensive 3D games and especially where you’d want to leverage the GPU for calculations you would use Unity headless instances on AWS GameLift or similar. Use Nakama for all the rest of the game services: user accounts, chat, in-app notifications, leaderboards, custom RPCs for metagame systems, etc, etc. This also works really well and many game teams also take this approach.
The approach you take depends on the level of sophistication you need with the server-side reconciliation, entities, and state management.
mixture of physic mini games like e.g. Mario Party, sometimes realtime and sometimes semi realtime
These kinds of games would work really well with minimal server-side physics logic. You’d usually just need to track positions and resolve vectors against the client-side positions to reconcile movement.
Would a game like Bitmoji Party be a good example of what you want to achieve? It’s built on Nakama with the authoritative multiplayer engine.