Server Actioned Events (Think minigame oriented games) and managing hit detections

Say I have a minigame event which rains down a barrage of arrows upon the map and players, welding to contacted parts. How exactly should I manage the collision detection to ensure as less latency between server and clients as possible.

Using the server exclusively to pickup on touches:
A .Touched event on the server works okay, when the network owner of the arrow is the server. However, on the client is appears to jump from several blocks above to the hit position.

Using .Touched on the client and then informing the server:
Another way I have tried, is having set network owner of arrows to the targeted player and detecting the collision for the player character and arrows owned on the client. This shows well for clients, but server and other clients sees the arrow welded several blocks higher than the client.

I have probably been handling this super poorly but I definitely need some direction in how to handle collisions on my game so that they are seamless, and as fair as possible across all clients and the server.

I want each player to see the rain items (such as the arrow example) smoothly fall and welded whether they may land.

Please direct me on the path to take!

Concurrently simulate the arrow barrage on the server and each client, reconciling each client’s state by periodically sending the server’s frame, since each client state will diverge due to differences in hardware.

An easy approach is to instance each arrow on the server and prevent replication by parenting them to workspace.CurrentCamera. Then, use a RemoteEvent to tell each client to instance an identical simulation on their own client, ideally at a synced time using workspace::GetServerTimeNow. Next, use a RemoteEvent (maybe UnreliableRemoveEvent) to send the server state to each client so they can correct their simulation.

If done just right, each client perceives a smooth simulation at their render tick, with the server maintaining simulation authority. Unfortunately, networking physics is hard, the result will never be perfect, and you must find a tolerable balance between latency and accuracy.

I recommend having each client connect to .Touched on each arrow, attaching it to it’s hit target, then updating the attachment during reconciliation with the server state.

Consider having the server predict each client state, depending on if you want the server to be the single authority for collision, or if a client should have some freedom in if they get hit. That way, if the arrow did not hit the client on the server, but did hit them on their own client, due to the latency between their movement updates, you can balance that.

If you send the CFrame, AssemblyLinearVelocity, and AssemblyAngularVelocity of each arrow, then you can have each client predict where it thinks the server state will be before the next sync occurs.

If the arrows simply fall straight down, then you might find the collision handling can be simpler by determining where an arrow is along a straight line.

1 Like

Thank you so much for the explanation. This makes it really clear about what I need to do. Very much appreceiated. I did not know you could avoid replication of objects to the server using CurrentCamera, very handy. Have good one!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.