Jump to content

  • Log In with Google      Sign In   
  • Create Account


How to synchronize the ball in a network pong game?

  • You cannot reply to this topic
10 replies to this topic

#1 Thaars   Members   -  Reputation: 100

Like
1Likes
Like

Posted 22 June 2014 - 06:20 AM

Hi guys,

 

I'm new to this forum. I've already asked my question at stackoverflow but got no answer yet. I hope it is not a problem to ask here again.

 

I’m developing a multiplayer network pong game, my first game ever. The current state is, I’ve running the physic engine with the same configurations on the server and the clients. The own paddle movement is predicted and get just confirmed by the authoritative server. Is a difference detected between them, I correct the position at the client by interpolation. The opponent paddle is also interpolated 200ms to 100ms in the past, because the server is broadcasting snapshots every 100ms to each client.

 

So far it works very well, but now I have to simulate the ball and have a problem to understanding the procedure.

 

I’ve read Valve’s (and many other) articles about fast-paced multiplayer several times understood their approach. Maybe I can compare my ball with their bullets, but their advantage is, the bullets are not visible. When I have to display the ball, and see my paddle in the present, the opponent in the past and the server is somewhere between it, how can I synchronize the ball over all instances and ensure, that it got ever hit by the paddle even if the paddle is fast moving? Currently my ball’s position is simply set by a server update, so it can happen, that the ball bounces back, even if the paddle is some pixel away (because of a delayed server position).

 

Until now I’ve got no synced clock over all instances. I’m sending a client step index with each update to the server. If the server did his job, he sends the snapshot with the last step index of each client back to the clients. Now I’m looking for the stored position at the returned step index and compare them. Do I need a common clock to sync the ball?

 

Update:
I've tried to sync a common clock for the server and all clients with a timestamp. But I think it's better to use an own stepping instead of a timestamp (so I don't need to calculate with the ping and so on - and the timestamp will never be exact). The physics are running 60 times per second and now I use this for keeping them synchronized. Is that a good way?

 

When the ball gets calculated by each client, the angle after bouncing can differ because of the different position of the paddles (the opponent is 200ms in the past). When the server is sending his ball position, velocity and angle (because he knows the position of each paddle and is authoritative), the ball could be in a very different position because of the different angles after bouncing (because the clients receive the server data after 100ms). How is it possible to interpolate such a huge difference?

 

Thanks in advance for any help!

 



Sponsor:

#2 hplus0603   Moderators   -  Reputation: 4960

Like
3Likes
Like

Posted 22 June 2014 - 10:24 AM

There's a patent from 2000 that writes up one way of doing this, by adjusting the time frame used for an object based on how interesting (close) the object is to the viewer/interactor. Thus, far away, non-controlled objects are displayed using the "as seen from the server" clock. Close, locally controlled objects are displayed using the "locally simulated-ahead" clock.

https://www.google.com/patents/US6628287

Implementations of these ideas may exist from before this time, but I haven't found a good write-up of them.
enum Bool { True, False, FileNotFound };

#3 Thaars   Members   -  Reputation: 100

Like
0Likes
Like

Posted 22 June 2014 - 11:42 AM

Thanks for your answer. I'll take a look and try to understand ;-)



#4 Thaars   Members   -  Reputation: 100

Like
0Likes
Like

Posted 23 June 2014 - 01:03 AM

This is a lot of text and hard to understand for me... Unfortunately I'm more confused than before. Why should I send a user input from a client with a future timestamp to the server?

It would be very nice, if someone could answer in easy words and figuratively spoken my first post. I've read a lot of articles for the last 2 weeks about this whole stuff and I still don't understand how it works in detail.

 

Thanks!



#5 hplus0603   Moderators   -  Reputation: 4960

Like
2Likes
Like

Posted 23 June 2014 - 10:27 AM

It turns out that distributed simulation is complex, and time management is one of the complex parts of that.
You need a certain vocabulary to be able to talk about these things.
I recommend a good textbook or dedicated study into that subject. Singh, et al: Networked Virtual Environments, is a decent textbook.
enum Bool { True, False, FileNotFound };

#6 Thaars   Members   -  Reputation: 100

Like
-3Likes
Like

Posted 24 June 2014 - 12:52 AM

Hey man, I expected such an answer... It's every time the same in forums: "Here is a link and if you don't understand it, you are too stupid for that stuff."

Even if its complex, it is possible to explain it in easier words than to link to a patent. It's a shame, that nobody in a game dev forum is able or interested to do that.



#7 samoth   Crossbones+   -  Reputation: 4496

Like
0Likes
Like

Posted 24 June 2014 - 03:51 AM

In the particular case of "pong", I believe that you are very lucky since you do not need any (or at least not much) synchronization at all.

 

The ball moves in a straight line, at a constant speed. It only changes direction when it bounces off something (the wall or a paddle) and it only changes speed if the server decides that the game is getting too boring (presumably because you've been playing for 3-4 mins without losing the ball).

It is exactly predictable where the ball will go, as well as where and when it will bounce off a wall. All of this can be done without interaction with the server.

 

All the server needs to do is receive paddle positions from the clients regularly (and forward those to the respective other player so they can see it on their screen) and decide if a player had his paddle in the right position whenever the ball crosses the line. Then it either sends an "out" message or a "bounce" message to everybody. Everything else can run on the clients only without further synchronization, and nobody will ever know.


Edited by samoth, 24 June 2014 - 03:51 AM.


#8 hplus0603   Moderators   -  Reputation: 4960

Like
0Likes
Like

Posted 24 June 2014 - 10:02 AM

you do not need any (or at least not much) synchronization at all


I suggest you code it up and try it. It turns out that for one player to see what the other player is doing, when latency is high, is an interesting and non-trivial problem. The naive solution will show the other player missing the ball on the locally playing client's screen.
enum Bool { True, False, FileNotFound };

#9 hplus0603   Moderators   -  Reputation: 4960

Like
2Likes
Like

Posted 24 June 2014 - 10:06 AM

"Here is a link and if you don't understand it, you are too stupid for that stuff."


What part of "here's a textbook that actually explains everything you need to know, which is WAY TOO MUCH to write in a single forum post" is not helpful or suggests you're stupid?
In fact, you have to be pretty non-stupid to actually learn what's in that book!

If you expect to be able to learn this stuff without any effort on your own, then, for the field of distributed simulation, that's unlikely to work out for you. Until now, I had no reason to believe this was the case, but your post makes me wonder.
enum Bool { True, False, FileNotFound };

#10 Thaars   Members   -  Reputation: 100

Like
0Likes
Like

Posted 25 June 2014 - 12:44 AM

I had just a question and I thought, we can discuss it here. I read a lot of posts and articles, a book (in my first language) and your linked patent and I'm still not sure how to solve this problem. From my point of view are there a lot of books I could also read but I don't know, which one is the right one. Unfortunately I'm not a native english speaker, so reading some books could be difficult and taking a long time. Thats why I'm here.

 

I’m writing the whole stuff in javascript and using node.js as the server and chipmunk.js physics engine. In different browsers the simulation will get different speeds over time (with the same configuration). Chipmunk should be deterministic, but it doesn’t look it. Because of this and to prevent cheating, I cannot calculate everything on the clients.

 

Maybe displaying the ball in the past could be a solution. I'll think about it.



#11 hplus0603   Moderators   -  Reputation: 4960

Like
0Likes
Like

Posted 25 June 2014 - 11:08 AM

In different browsers the simulation will get different speeds over time


Are you doing fixed time step physics?
What time management strategy are you using?
enum Bool { True, False, FileNotFound };





PARTNERS