I’m working on a server-authoritative, competitive, fast-paced multiplayer game and I’m new to Nakama. I’m trying to understand the best way to integrate headless Nakama with GameLift (headless Unity) in this scenario.
From my research, it seems that Nakama handles matchmaking and fleet management and provides the client with the IP address of the game instance when it creates or finds an instance on GameLift.
For high-frequency updates like player positions, what’s the best approach to send these updates to the game server (the game instance on GameLift)?
I noticed that Nakama provides the SendMatchStateAsync method. My questions are:
Does this method send the message directly to the game server (game instance on GameLift)?
Or does it send the message to the Nakama server, which then relays it to the game server?
If the latter is true, it doesn’t seem ideal for fast-paced games due to potential latency. In that case, should I use a different networking solution, such as Netcode for GameObjects, alongside Nakama for these updates?
Finally, what are some other common use cases for Nakama in this scenario? For example, handling persistent player state, game session metadata, etc.?
Any guidance or best practices would be greatly appreciated!
If you’re looking to use Amazon GameLift, you can think of Nakama as the orchestrator of your GameLift instances - you can use it create your headless instances as needed, keep track of ongoing matches to list them (e.g.: backfill matches), use the matchmaker to match players together, create lobbies, etc.
As you point out, Nakama would also handle player accounts, authentication, persistent player state and many other social features you’d like to include in your game (such as leaderboards, friends, notifications, status, etc)
The typical flow is for the game client to connect to Nakama via one of our provided SDKs to handle player authentication, list available game sessions to hot join or create a new lobby. Then, the client connects and interacts with the GameLift instance directly to drive the game logic. If the game has authoritative side-effects that need to happen (e.g.: update a score on a leaderboard or update the player inventory) then your headless instance should communicate with Nakama directly with what we call a Server-To-Server RPC call, so that these updates happen authoritatively.
SendMatchStateAsync is used to send match state updates to Nakama’s own authoritative engine (not the headless instance) which you could use to, for example, set up the Lobby System. As part of your lobby code, you’d use the Fleet Manager to create the new headless GameLift instance once players are ready, and communicate them the instance details so they can connect.