How to sync movement in authoritative multiplayer?

Development
#1

Hi everyone, I kind of get stuck at syncing the movement of the player in authorized multiplayer.

Here is my case:
I am using Unity as the client. I know the basic theory of client prediction and server compensation. But I don’t know how to do it when working with physics. Like I can send the command to server when the player presses Move Command. Then the server will send back the new location it should be. But how does the server has the awareness of whether there is an obstruct there? If it is a platform game, how does the server know if the character should fall if the new location has no platform?

To sum up, how does the server have the awareness all the environment? How does Unity and Nakama server work to solve this?

Any help will be appreciated!

1 Like
#2

I have a similar question. Say you implement your game logic in some language that isn’t Lua, JavaScript, or Go. Maybe you test it in a local setting without authentication or social features, and have entities syncing and interacting well. Then you hook that game to Nakama, and maybe you want to use server-authoritative multiplayer. How do you do that without reimplementing your game logic in another language? This seems especially problematic for some of the projects I’d eventually like to work on, where the client and server are essentially the same game and use the same spaceflight and other systems. The difference is that the client single-player mode is a demo for flying around, learning piloting, etc. while the server/multiplayer mode is an MMO (or maybe not Massive, but a world where several players can fly around and chat.) Single-player mode lets one player fly around and interact with NPCs and such, but multiplayer mode connects with a headless server running the same systems, and syncs changes across the network.

I think maybe the way you do this is by figuring out what you need to sync, then writing JavaScript/Lua/Go code to interact with your server process. So maybe the server exposes a GRPC API, and the various commands use a GRPC library to call it. By the time a request hits the API, Nakama has already authenticated it and can guarantee that the player is issuing commands to the correct entity. Then the chat and other features are layered on top of that.

Is that accurate? Or is the expectation that I implement all my server-side logic in a supported language and the client is just a dumb renderer/controller? If it is accurate, is GRPC the recommended technology for the Nakama->game server control plain, or would something else be a better choice? Guessing GRPC’s being TCP doesn’t matter nearly as much if Nakama and the game servers are likely on the same network segment.

Thanks.

#3

I think you would be interested to watch this awesome talk on “networking and physics”. This talk is an “old but gold” case. I think “snapshot interpolation” and “state synchronization” algorithms that lecturer talks about are good cases for your authoritative scenario.

2 Likes
#4

Option 1:

Game with simple physics that doesn’t require a physics engine to predict movements (grid game …): can do in Nakama in Go / Lua / JS.

Option 2:

Complex physics: use both Nakama & a headless instance of the game engine you’re using that compute physics.
In my case I have Nakama running in Kubernetes, when a Match is created it spawns a headless Unity node that compute physics, when the match is terminated, delete the node.

Option 3

Complex physics: Implement a physics engine (good luck), use a physics engine in Nakama and rely only on Nakama physics (but you can’t do client-side prediction then because you have different physics implementations on server & client)

3 Likes
#5

@louis030195 That’s an excellent summation of the options for movement sync logic in the multiplayer abstractions available in Nakama. Thanks :pray:

I’d say option 3 is a little more nuanced than you’ve described but it really depends on the type of multiplayer game on what level of physics simulation needs to be executed server-side.