Hi, we’re currently trying to make gifting on group mechanics via group chats like this
We’re unsure on how to handle multiple people updating the same chat content with UpdateChatAsync. Problem is from design wise, gifting would decrease some coin on the gifter.
So in the case of more than 5 people gift to a particular user simultaneously, how do we know if an update chat call fails from IChannelMessageAck? We don’t want to make gifter coin reduced if the person requesting the gift already have his request full.
We’re using Nakama 3 with Unity SDK
Thanks for the help!
Hey @cloudAle, I’d recommend using Nakama storage collections (Collections - Heroic Labs Documentation) alongside the chat feature to ensure that the max chat messages won’t be surpassed prior to sending a gift.
So each time Client A receives or claims gift message, you could increment or decrement a storage object variable by one, respectively.
Prior to some Client B sending a message to client A, it could read the storage object for Client A and if Client A’s variable is already at the max, it can prevent client B from sending the message (or even hide the prompt to gift.)
Thanks for the answer @lugehorsam
To clarify, if using storage and not using UpdateChatAsync the flow would be something like this
A send Gift Request to group channel, A also write storage with public read
B got the message
B try to send help
RPC would check if storage valid
RPC update A storage
RPC send gift to A
B deduct coin
Which means the actual message in the cannel is actually not updated, the values displayed in the chat window is on client responsibilty, am I right for this?
Also is there anything I need to worry if we’re going to use storage? since the nature of chat tends to be chatty, there will be a lot of storage of GiftRequest Collection with Key MessageID tied to a particular user.
Storage would be as small as
type GiftRequest struct {
val int `json:"val"`
// To check if a particular user already send a gift
nakamaIds []string `json:"nakamaIds"`
expiredTime int64 `json:"expiredTime"`
}
or this is something that nakama can easily handle at ease and nothing for us to worry about
Thanks!
the flow would be something like this…
Yep that flow looks right to me. You don’t necessarily need custom RPC calls to write this, I think you can pull it off by cross-referencing the chat message IDs with the storage object using the APIs shipped with the client SDK.
the values displayed in the chat window is on client responsibility, am I right for this?
I’m not sure which values you mean and what you mean by “client responsibility” in this case.
Also is there anything I need to worry if we’re going to use storage?
The storage calls use heavily optimized SQL queries and were built to handle these types of frequent updates.
1 Like
Wouldn’t it be safer to do rewarding items on nakama server though? CMIIW isn’t it best practice to do economy related things on server?
The 1/5 values on the chat window to display, since the message is basically just “Player A request a gift”, so it’s client responsibility to cross check with A storage and display it correctly on the chat window
Wouldn’t it be safer to do rewarding items on nakama server though? CMIIW isn’t it best practice to do economy related things on server?
It depends on whether and how you validate the economy transaction that is being sent by the client. You’re right that it’s a good idea to do so. It is valid to use custom RPC’s to do this but you can also “before” and “after” hooks that run on the server in the pipeline from your storage calls: https://heroiclabs.com/docs/runtime-code-function-reference/#register-hooks
So some validation can run on the server to ensure that the gifter actually has the currency he is gifting, and that the recipient hasn’t exceeded the max number of gifts, etc.
since the message is basically just “Player A request a gift”, so it’s client responsibility to cross check with A storage and display it correctly on the chat window
So there’s two issues here: (1) Your original question about validating the max number of gift requests received by a client. (2) Validating that the requester’s health state hasn’t changed since the time of the request. (3) Updating the UI of the potential gifter when the health state of the gift requester has changed.
We’ve discussed (1). For (2), you could still use a storage hook or RPC to validate that if you didn’t want to on the client. For (3) I’d use the chat message updated event so you can render it in real time.
1 Like
One last thing, AFAIK there’s no API for the server to update a particular message on a chat channel right? It can only be done from game client
Other than that, thanks for the detailed explanations, we’ll probably going with the custom rpc’s route
@cloudAle You’re right we lack a server framework function to update a chat message inside an RPC call. Can you open a feature request for it?
1 Like
@cloudAle We’ll work on it as part of our next server release. 
1 Like
