question

It doesn't matter how smart we are - what you're asking is, how to use an occasional call to Cloud Script to prevent cheating in a realtime game. With no hosting server, your clients will be authoritative. That means, as you say, any modifications made to the local client code would result in cheating behavior. Trying to detect that would require (again, as you say) frequent checks of player position, as well as validation of the player's equipment and damage values every time they shoot at the other player (at a minimum). And calling Cloud Script that frequently not only is not what that service is designed for, it would be more expensive than running hosted servers (https://docs.microsoft.com/en-us/gaming/playfab/features/pricing/meters/meters#cloudscript).

You could have the clients report their player inventories at the start of a match, and then send a report of player actions at the end of the match, and check all the values in each to see if you can spot any bad behavior, but since the client is authoritative, again, that can be falsified.

Another layer past that would be to have each client send up a report at the start and end of the match containing all the details. You'd have to coordinate on when both reports are available to check, and determine a consistent way to make any changes you want to at the end of the match only once. Like choosing a client to "drive" the processing of the report analysis and having the other client only check to see if it's done, taking over the "driver" responsibility if the reports haven't been analyzed for some long period of time. Since a hacked client could lie on each report, the start report is just so that there's a record that the two clients initiated a match (so that a rage quit won't prevent the final analysis). The end report analysis would be checking both that the clients agree on the details and that there aren't any obvious signs of cheating (weapons used, damage done, etc.). And if one client doesn't send a report at all (they exited the app), you need to decide how to handle that. Do you trust the one remaining client? The problems with this are numerous, not the least of which is the fact that since this is a realtime game, it sounds like you're going to be connecting the players peer-to-peer. In which case, since player A has player B's IP Address, it's trivial to pay a few $ online to kick off a DDoS attack on player B's IP. So player B winds up dropping, and player A's report is the only thing you have to go by. A cheated client could then send any report it wants to.

So, the next step past that is to use something like Lockstep (https://en.wikipedia.org/wiki/Lockstep_protocol) to coordinate between the clients, so that the cheat prevention becomes a process where the two clients have to continuously agree on what's happening in the game. The issue with that is that it has significant performance penalties, which generally won't work with fast-paced realtime games (where you're already going to have to do everything you can to reduce latencies). Again, in this model you'd need to do some kind of coordinated report check at the end, but it would be an improvement over the report-only method above, if you can afford the performance hit.

Basically, to effectively prevent cheating in the type of game you describe, we would recommend using a custom game server to host the session, so that it can be authoritative. Anything less than that is going to require fairly extensive work that will still be vulnerable to cheating without continual re-evaluation and improvement. For any non-trivial player population, you'd have hackers experimenting to find ways around your current implementation - which becomes the classic situation with this type of cheat protection, in that you build a higher wall, and they just build a taller ladder.