Collision Detection in Multiplayer

Started by
2 comments, last by SpaceDude 19 years, 7 months ago
Hi, I am developing a billiards-like game with DX8. Currently, the rather simple physics / collision detection for it go like this: NOTE: MotionFactor is the last frame's length in a fraction of a second. Multiplying a vector by MotionFactor (from what I gather) allows velocities to be in terms of seconds rather than frames, so that no matter what framerate objects will move at the same speed. ----------------------- LOOP { 1) Move Objects: Update the objects' positions, adding their current velocities. Check each ball's next position (current pos + velocity * MotionFactor) against the others. If the balls will intersect, adjust their positions and velocity so that they rebound / don't hit. Then apply forces like gravity and such to ready the ball's new velocity (velocity += gravityforce * MotionFactor) 2) Render Objects: Renders them in their current position. } ------------------------------------- I apologize for a loose description of that... the code is not exactly perfectly clean now. Ideally, for the networking, I would only have to send the initial ball setup and the direction/velocity of each shot to each client. The clients would then be able to render and calculate the end result of the balls' positions by themselves. --- My question is this: This method works OK for running on a single PC. However when I network the game, the method in which clients receive updates needs to be absolutely accurate so that all clients see the same positions for the balls at the end of each shot. That won't work with the time method used there (MotionFactor). For example, if the host app became stalled for a few seconds for whatever reason, the next MoveObject() would do this: // MyPosition += Velocity * MotionFactor; MyPosition += Velocity * 3.0f; // If the last one took 3 secs That causes the position to be glaringly wrong...and when each client ran the simulation, it would be possible for each client to have an entirely different result of the shot. So somehow I need to be able to make the motion appear smooth regardless of framerate, but at the same time, the physics of it cannot be disturbed by any client-side variable (FPS, processor speed, etc). If you understand what I mean, am I going about this the entirely wrong way? And if not, how can one render the scene with smooth motion while mantaining the accuracy of the original shot? Shutter
Advertisement
For a billiard type game I'd pick one pc as being host and it's calculations are taken as fact.
Then calculate the time of collision of objects (either ball with ball or ball with a wall), take a snapshot of the scene and send it to your clients, which only animate the scene from given frame to frame.
This way you can go sure every client visualizes exactly the same and the table will look same on every pc at the end of movement.
-----The scheduled downtime is omitted cause of technical problems.
Quote:Original post by OmniBrain
For a billiard type game I'd pick one pc as being host and it's calculations are taken as fact.
Then calculate the time of collision of objects (either ball with ball or ball with a wall), take a snapshot of the scene and send it to your clients, which only animate the scene from given frame to frame.
This way you can go sure every client visualizes exactly the same and the table will look same on every pc at the end of movement.


This is the way Worms works. There is a delay of 3 or 4 seconds between client and server in my 2 machines p2p network. Not a problem at all for a turn based game.
[size="2"]I like the Walrus best.
Warning, shameless plug ahead:

I wrote a game of pool with multiplayer, you can check it out here:

http://users.skynet.be/sdsoftware/spacepool.htm

The way i did multiplayer is that the server sends out information of all moving balls once every 1/10th of a second.
And stationary ball information is sent out every 1 second.

The initial cue shot info is also sent out at the start.

The client predicts all the movements and collisions itself, but once it receives data from the server it synchronises itself with the server. And to avoid it looking really choppy, there is some interpolation between the client prediction and the data received from the server (but u can worry about that afterwards).

And when i say ball information is sent out i mean:

Ball ID, Position and Velocity.

for stationary balls the only info thats need to be sent is

Ball ID and Position. (Velocity is assumed to be (0,0,0)).

I'm pretty satisfied with the results, no doubt there are ways to reduce the network traffic but this only generates about 0.014kb/sec per stationary ball and 0.260kb/sec per moving ball. Which should work fine even on a 56 KBps modem.

This topic is closed to new replies.

Advertisement