Hi, I'm going through the following documentation: https://docs.metaplay.io/game-logic/how-to-guides/implementing-cheat-proof-randomization.html#overview I have some questions to understand why this is the approach that was chosen. 1. I was thinking the roll could also be ask/response type interaction. The ask handler could execute the random pcg and then invoke and action to grant the item and then return the result in the response. 2. Alternatively if we wanted a queue of unclaimed rolls we could have an entity CastMessage which requests a roll and similar to above that would populate a pending queue or results. I am wondering. What are pros and cons of using the Messaging vs executing an action with a server listener to invoke some server side logic? Thanks Andre

Hi again Andre, and thanks for the great question! That example in the documentation is indeed just one way of implementing server-side randomization (or other server-side logic in general) and for some needs a more direct direct messaging -type of solution might be more suitable. The main benefit of the "initiating action" approach is the interaction with client-driven model timeline. As with any other actions, the client can "predict" with 100% accuracy what the current amount of gold is for the "has enough gold" check so we don't have the error case to handle at all -- and the client logic for UI etc can rely on the current state being up to date. With a request-response implementation, it would be possible for the the player state (say, amount of gold) to change between issuing the request and running the handler. This might not be horrible, the handler just needs to do validation and have the ability to communicate errors. As an example, consider a client doing two of these requests in quick succession: right after the first request the client-visible state would not have changed yet so the client may issue another request which would then fail if the handling of the first request resulted in amount of gold dropping too low. In practice if the client had the notion of these "outstanding" requests for purposes of blocking the UI for duplicate requests this might be not be an issue.

Great. Thanks for the reply. The error handling is something i hadn't thought about. Also with the messaging approach there is also the extra work of proxying the message in the Session Actor.

Yes indeed. Note that individual one-way messages can be tagged with message routing rule

MessageRoutingRuleOwnedPlayer

for conveniently casting messages from client directly to PlayerActor. As it stands, the SDK doesn't provide similar automation for MetaRequest/MetaResponse so you need to relay the request manually in SessionActor. This would be very useful for some use cases and we are definitely planning on adding this functionality, but for many game logic use cases the initiating-action-enqueueing-server-action-for-response is a better choice due to the reason stated above.