Skip to content
This repository has been archived by the owner on Nov 23, 2024. It is now read-only.

How to change networking to server-authoritative #5

Open
infcodey opened this issue May 27, 2021 · 6 comments
Open

How to change networking to server-authoritative #5

infcodey opened this issue May 27, 2021 · 6 comments
Assignees

Comments

@infcodey
Copy link

Hello,

I would like to change the networking from master-client-authoritative to server-authoritative.

I would appreciate any advice on how to go about this, thank you.

@docsncode
Copy link

Hi @infcodey I'd recommend looking at the authoritative multiplayer docs. Your server side logic will need to be written in Lua, TypeScript or Go. There are also some great video tutorials on authoritative multiplayer for a Godot and JavaScript game. Let me know if you need anything else 😄

@infcodey
Copy link
Author

Thanks for the response @seanpackham.

Is there a way to leverage the existing master-client code when writing the server side logic?

Is the Lua/TypScript/Go requirement because of Nakama?

@docsncode
Copy link

@infcodey glad I could help 😄 some of the logic will be similar and can be ported. You can also watch the Godot video series which has code you could copy and use.

Yes, Lua/TypScript/Go is a Nakama requirement for writing server runtime code.

@dsnopek
Copy link
Contributor

dsnopek commented May 28, 2021

There's actually another model where you pick one of the clients to be "the server", treat it as authoritative, and just use Nakama to relay the messages. Or, if you didn't want a client to have that authority (because of potential cheating), you could even launch another instance of the game somewhere in the cloud, connect it to the match, and make that act as the authoritative server, again, just relaying the messages through Nakama.

That's not necessarily a better model, it really depends on the game. But if your game depends on the physics engine, or complex interconnected systems, it might be prohibitively difficult to re-create the physics engine or those systems in Lua/TypeScript/Go, making it easier to have an instance of the game do that work.

@infcodey
Copy link
Author

Many thanks @seanpackham and @dsnopek

@dsnopek I was thinking along the same lines. Even for a simple game it could be difficult to perfectly re-create the systems in Lua/TypeScript/Go.

I'm looking for full server authority, would you recommend the model you mentioned (using an "invisible" instance to act as the authoritative server) for this game?

If so, do you have any advice for going down this path? I can't seem to find any code examples of this model.

P.S. If you know anyone who would be interested to take this task on as a contract job, please let me know!

@dsnopek
Copy link
Contributor

dsnopek commented Jun 1, 2021

I'm looking for full server authority, would you recommend the model you mentioned (using an "invisible" instance to act as the authoritative server) for this game?

I can recommend it generally, but it really depends on the specifics of your game, and, of course, other constraints, such as the composition of your team (ie. do you have someone who can maintain this infrastructure long-term?) and budget (depending on the resources needed by your game, the average length of a session, expected number of players, etc it can get quite expensive to pay for all those resources in the cloud).

If so, do you have any advice for going down this path? I can't seem to find any code examples of this model.

There's really a lot of options.

So, first of all, I don't know if this is true for your game, but for the sake of making an example, let's assume your game is session-based (ie. a bunch of players are matched up in a session that starts, runs for a bit, and then ends -- as opposed to having long-running servers where players pop in and out).

You could, for example, setup a Kubernetes cluster on AWS, and then have a Nakama module (written in Lua/Go/TypeScript) with a custom RPC that will launch a "pod" with a server instance of your game on this cluster, and then get all the players and the server connected in a match together in Nakama. When the match is over, the server pod would shutdown, and Kubernetes would free up whatever resources it was using. There's dedicated software for doing this sort of implementation, like Agones, for example.

Anyway, not necessarily recommending that for you (because I don't know the details), but just one possible example!

P.S. If you know anyone who would be interested to take this task on as a contract job, please let me know!

Feel free to contact me at https://www.snopekgames.com/contact :-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants