first of all, great project you have here! For a future project I am evaluating server-side solutions with might work well with Unity.
So I understood that, if I wanted to have server-side validation of entity positions and collisions I have two options:
Reimplement deterministic physics in e.g. GO and manually replicate the game world in Nakama
Use unity headless server and communicate back and forth between Nakama and unity, where Nakarma acts like a proxy/gatekeeper and account manager
The game I am talking about is a mixture of physic mini games like e.g. Mario Party, sometimes realtime and sometimes semi realtime. Any suggestions what path to follow?
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.
Any idea what kind of lib would work well in GO or really physics from scratch?
@matthiasbruns We usually write the small amount of logic needed for the game simulation directly for each project but there’s a few off the shelf physics libraries that may cover parts of what you want to achieve for the multiplayer logic:
Most of these cover the 2D physics requirements but could be extended or modified to fit the requirements of the 3D game.
Also consider closely how much of the physics needs to be calculated server-side. Some of the most successful multiplayer games (like Vainglory) use the game client engine to do most of the physics calculations and arbitrate only over the critical anti-cheat requirements in the gameplay.
Thank you very much for those useful guidelines. I think that I will try out a few of your hints to see what feels best for us
That’s really great help. I bet everything will become clearer when actually starting to implement things (first standalone server side project for me).
