I had some questions more related to the architecture and security i did not find answers in the doc,
so if anyone could direct me to possible resources that would be great.
For example i see here:
From what i understand a user can upate his own data from the client. So for example, regarding the scoring of a player, with the example given, we have to trust the client for the submission of the score? I am not sure what would be the recommended pattern to follow to avoid that and have the server side handle the logic.
I guess the server to server should be an option to leverage,
But if someone has some example of what would be the different responsabilities of each server in this case or some feedback experience, that would help.
From what i understand a user can upate his own data from the client.
Yes the client can update their account and user profile properties like: display_name, username, etc, etc.
So for example, regarding the scoring of a player, with the example given, we have to trust the client for the submission of the score?
No you don’t need to trust the score submitted by the player. In fact there’s no field called score anywhere on a user account in Nakama. There is a field called metadata which can contain a nested JSON object that stores fields and values that are specific to the game. This information is returned when the player fetches their account but it cannot be updated by the client.
To update it you must write an RPC function and register it with the server runtime. These functions can be written in Lua or Go and called by game clients. Within the function you can implement whatever logic you like. This could involve velocity checks on input values, bounds checks, etc, etc. The logic to prevent the client from cheating can be completely controlled from your RPC functions. This is covered in the docs here and here.
A server to server (S2S) function in Nakama is expected to be called from another game server you’ve already got (for example to migrate from) or when you need to interact with Ad networks, or rewarded video services which can signal back to the game server over a webhook HTTP request.
Hope this helps. Let me know what kind of multiplayer game you want to build and I’ll try to give more detailed answers.
Hi thank you for your quick answer, it helps me understanding how RPC should be used.
The multiplayer game we plan won’t have heavy graphics on the client, the interactions of the game would be through tchat mostly. (so no heavy calculation of ui state interactions). From what i understand we can implement the whole logic we need through RPC function. So what would be the best pattern so the server hold a complete state of a game session (For example: let’s say several players by room, each room having their own game state, each game state would need to access some kind of a common ledger at the beginning and at the end of a game session)