The English is good enough, so don't worry!

The case of "tie breaking" requires game design more than it requires network packet design. The case of two players hitting the same rock sounds similar to the case of two players trying to collect the same health pack in a first-person shooter.

The way that case is solved is by structuring the player interaction in two phases; one phase is the "preview" phase, visible only to the acting player, and the other is the "result" phase, visible to everyone. So, for example, the "preview" phase of picking up a health pack might be playing a short sound of an injection gun or something. As soon as the player gets to the health pack, play this sound, and send a "I got to the health pack" request to the server. Then, when the server determines that the request succeeded, it sends back "so-and-so picked up the health pack" which causes a particle glow to play around the winning player and causes the sound effect to trigger if it hasn't already played. Also, when receiving this message, each game client knows to update the health of player so-and-so.

So, if you and I are both racing for the health pack, both of us will play the capture sound, and then one of us will be "winner" (normal result) whereas the other will be "loser" (and will see the effect of the other player picking up the health pack.) Each viewer will hear the pickup sound, and will see the player that won actually get the particle effect. For the "losing" player, the way to rationalize this is that the sound effect was actually played by the other player picking up the pack.

There are some important design considerations here:

- the preview effect is somewhat small and not too noticeable, and works well in all three cases of "winning," "losing," and "seeing someone else do it."

- the state on the client doesn't actually change (other than noting that the health pack sound effect already triggered) as part of the request

- the server chooses to only act on requests that are correct, and doesn't need to send any updated about "negative" requests (it's great when you can design it like this, but some cases may require a negative message.)

- the state on the client (and on all clients) are updated as part of the server update

Together, they make for a robust system that solves tie-breaking on the server with minimal player confusion.