I do face a problem where I perform various operations between the client and the server though the socket, but it would be way better to do it through rpc call. The problem is, I cannot because RPC can’t access match state.
Scenario:
Creating an MMO (one server, one match only). Each player in the game has an inventory attached to them. A player can perform various things dependent on state of inventory. The inventory is saved on the entity in memory on server for quick and fast access - instead of reading and writing to database each action made by player.
When the player goes the an NPC-shop and buy an item from the shop it sends a message through the socket instead of RPC. This is because the inventory needs to be updated in the match. THIS is an acton that would be way more suitable to use an RPC function instead of the socket. But I cannot access the match state. So the server won’t know what has changed in the players inventory.
How can I approach this differently? This is just one scenario of many that I’ve faced where I would like to use an npc instead of socket. Sometimes it works (when an action don’t have to be notified in the match state), but most of the time I would really need to access the match state.
Hi @gruset, can you first clarify on the reasons you’d prefer to use an rpc instead of the socket?
And as you are using authoritative multiplayer, you can already send real time data from your client and handle it inside the match loop. Is there a reason you can’t modify match state by sending data via Nakama socket on the client?
At this moment i am sending it through the socket and modifying everything - and it works. The main reason i would like to use rpc function instead of the the socket is: operations like this i would like to make the user wait for the result from the server. While waiting, the “Buy button” from an npc shop is disabled. This is just one example. A socket is sent and there is no built in way to know what response corresponds to what action being sent.
My other solution to this was to match the actions being sent between the client and the palyer with an id - so the client can know when a specific response for a specific actions is being received.
This problem arised when i was testing out the game with higher pingrate, like 1000ms. The i relised that this might be a problem. ppl might spam the buy button.
I think this is more a conceptional problem. You should think about how you handle synchronous actions (click buy and show result) in an asynchronous way (i.a. click buy, send message via socket and not wait but anytime receive a result)
Yes you could work with an id: While not received a result, you can block the UI. That is a more or less client-side-only thing. Since you are talking “MMO”, you should always keep in mind that your server should not perform so much actions, but rely on the client to do the complex stuff.
A different approach would be to use the storage engine. As the inventory may not change that rapidly, the performance would be ok. You can access the storage engine from any rpc or socket. In fact, depending on how large your inventory may be, it is not suitable to be put in the matchState (since that size is limited by configuration and available memory)
A note on performance: I noticed that the storageEngine is incredibly fast. It can definitely handle hundreds of requests within milliseconds.