🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Player-Car Collision in Unity

Started by
14 comments, last by Butabee 9 years, 5 months ago

I wonder if it would be feasable to simulate on the clients and server and send occasional absolute positions and correct the cars over time.


Yes, this can work. If the cars are "scenery" and seldom actually collide, and/or don't matter much for the gameplay, then users might not care about the occasional inconsistencies. If the cars are an essential part of gameplay, users may feel that it's "too glitchy," though.

If you were gonna make a multiplayer game with collidable cars in Unity, how would you handle it? The physics don't have to be 100% accurate but should be mostly beleivable.

Advertisement

I wonder if it would be feasable to simulate on the clients and server and send occasional absolute positions and correct the cars over time.


Yes, this can work. If the cars are "scenery" and seldom actually collide, and/or don't matter much for the gameplay, then users might not care about the occasional inconsistencies. If the cars are an essential part of gameplay, users may feel that it's "too glitchy," though.

This is how we've handled games in the past, but always the exact position has been non-critical.

Each person transmits their location as game data rather than as Unity-managed object positions. The other players are treated as any other NPC. When an event comes in that a remote player has moved, their avatar is given a command that is basically avatar.MoveTo(location, direction). It may cause weird situations where the remote player's avatar needs to do pathfinding and run around the map, and very rarely it hits a critically-bad situation and the simulator will simply force the avatar to the location without concern for correctness and mapping.

Works well in games where players are not seeing the same screen and don't care too much about collisions. I imagine that same method would fail horribly for any kind of driving and crashing situation.

If you were gonna make a multiplayer game with collidable cars in Unity


Here's where I would start:
Is this mobile or desktop? On desktop, run physics at a much higher rate (120 Hz is good for cars!)
Then up the transmit rate to something like 40 Hz (again, assuming not mobile.) Send position/velocity/orientation/spin in each checkpoint -- hope you don't have too many cars!
Then locally simulate collisions on each client, but also send collision events as detected on the server, and play the same sound effects/camera shake when getting a server-side message.

On mobile? Try the last thing, but expect that it won't be very good. Perhaps try another kind of game :-/
enum Bool { True, False, FileNotFound };
Isn't that what physics simulation is for though? To calculate physics properties like the ones you listed? Or did you mean send those not so frequently for correction? I don't see why I'd need to send the position and all that outside collision events. I think you're right with the physics simulation rate though if I don't want cars warping through things. Currently I just send input state over the network and simulate those locally and remotely which is working well, but that's just for avatars. I was thinking I could do the same for cars.

I don't see why I'd need to send the position and all that outside collision events.


For two reasons:

1) The input and other object locations won't be available on the local machine for all the other players. Thus, your local car will be simulating in a world that is different than on every other player's machine (as well as different from the server.) You want to move the player car towards consistency pretty much continuously, a little bit every step.

2) Simulation isn't actually deterministic in Unity (or Unreal, or any other engine that isn't written to specifically be deterministic.) Thus, small errors will creep in -- just something simple like putting the same constraint in different rows on different machines will make the solver arrive at slightly different solutions, which will diverge over time.
enum Bool { True, False, FileNotFound };

I think I'll just leave the cars out for now. I think it will take too much time to get working right with acceptable bandwidth. Maybe I'll add it later, after the game is complete sans cars, in a patch, or DLC or something.

This topic is closed to new replies.

Advertisement