Hey everyone, I have a simple and (hopefully) easy to answer question:
I’m currently storing all connected presences in a TypeScript List inside of my custom match state interface, and I was wondering if it’s possible to access that match state inside of an RPC function.
(For this case specifically, I want to make an RPC function that sens the presence list of the server to the client)
In case anyone knows if and how thats possible, please let me know!
Also, here’s how my function currently looks:
let getMatchPresencesRpc: nkruntime.RpcFunction = function(ctx: nkruntime.Context, logger: nkruntime.Logger, nk: nkruntime.Nakama, payload: string) {
logger.info('Get match presences Rpc recieved.');
//This is where I would like to access the match state and then return the presence list
return JSON.stringify({});
}
I noticed that what I was doing propably wasn’t the right way (I originally wanted to use that rpc to let the client fetch the presence list and then instance other players according to that list, but it seems like there is already such functionality on the Godot SDK, so that seems unnecessary).
However, I have another example that I struggle to find the correct way dealing with. Say for example I wanted the player to let the client send its position to the server and let the server save that information and then relay it to other clients in the matchLoop() function, after ensuring the position provided by the client is valid. To me it would make sense to save that information in a player list inside of the game state, but since it isn’t exposed to rpc functions, I wouldn’t know how to go about saving these player positions. Any ideas how this could be done instead?
Apologies but I’m not sure I follow why an rpc is needed. The clients would send their positions via the realtime connection to the match, within the match loop you inspect the messages, do the necessary checks to validate the positional changes, and if valid, then you can store the positions within an object in the match state that maps, for example, the player IDs to their current position.
I see now. To be honest, I am quite new to Nakama and didn’t really know that the realtime connection existed and how to use it, but after reading your answer and taking a look at the official TypeScript match handler template, I think I now have a better understanding of how to use it. And you’re absolutely correct, an rpc is unnecessary for what I was trying to do.
Just to follow up with some additional information that may be of use to you as you develop your game.
Typically your players would communicate via the realtime socket connection when part of a match using the SDK specific send and receive match state functionality. For examples of this, specifically for Godot as this appears to be the engine you are using, please see the Sending match state section of the Godot SDK client guide. In contrast, RPCs tend to be used for more on-demand and non-realtime client-to-server or server-to-server communication.
Further to this, we have just revamped our server runtime match handler API documentation which you may find useful. Please see the updated TypeScript match handler API documentation.
So sorry to revive an old topic, but going back to @Coxcopi 's original question, I can see a use case where one would like to display a list on a clan website (for example) of ongoing matches and who’s participating.
Or another use case where you’d want to display the progress of a match (how many players are left, health, etc) on an esports portal where people can track it live.
Would the state of the match have to be POSTed to a custom endpoint periodically during the Match Loop? Or is there a better “Nakama way” of getting it via S2S RPCs (for example)?
@Antviss you could have the match loops store this information into a storage object and set up a custom RPC to fetch it.
Otherwise you can use the match listing API and the match labels by adding some metadata to them, although we advise against adding extensive unneeded (for querying) metadata to the labels as this data would get needlessly indexed by the matchmaker engine.
