-2

I tried to make a PONG game which works , and then change it to a multiplayer game.

You can choose the "Game Speed" which is basically how much cycles it takes until the ball can move and send location data.

So every tick (default is 200) the server sends this to 

pos:{0}:{1}&ballpos:{2}:{3}&gametick:{4}

(of course its in a String.Format)

and every tick the client sends this to the server :

pos:{0}:{1}

in order to sync the clients location with the hosting player.

it sends the messages with this function :

public static void sendMessage( String message , UdpClient client)
{
Byte[] toSend = new byte[55];
toSend = Encoding.ASCII.GetBytes(message);
client.Send(toSend, toSend.Length);
}

Now when we play , and we are on skype for example , the skype connection quality is really low , and extremely laggy. then the game becomes laggy.

Is there a more efficient way to send data to sync locations?

Paz Haviv
  • 137
  • 1
  • 1
  • 10
  • How often are you sending the update? Is that every 200 milliseconds? – Gusdor Oct 09 '15 at 09:33
  • 1
    I wouldn't do it every 'tick', I'd do it every few milliseconds. 200 cycles is nothing in modern computers - it's no wonder you're DoSing each other. – Callum Bradbury Oct 09 '15 at 09:33
  • @Gusdor , im sending the update every 'tick' , which is by default 200 cycles of a while loop – Paz Haviv Oct 09 '15 at 09:34
  • @CallumBradbury But if I do it every few ms , wouldnt it cause the ball to teleport instead of smoothly moving? – Paz Haviv Oct 09 '15 at 09:35
  • 2
    @PazHaviv Have you tried to find out? Seems that would be more conclusive rather than asking a random stranger on the internet. – Daniel Kelley Oct 09 '15 at 09:37
  • The netcode used in games can get quite complex, especially when you take into account you can't "trust" the clients - if all you're using to determine where a paddle is is what a client _says_ it is, a client could "teleport" their paddle to where it needs to be, and cheat. Entire teams can spend time working on such details... One way to look at it is that the clients each do the full simulation so things run smoothly, and resync with the server every x ms - in theory things _shouldn't_ jump in such a situation, but if packets are missed etc, they might end up jumping. – James Thorpe Oct 09 '15 at 09:38
  • Consider that the human eye can only really make out ~30 FPS. That means you could teleport the ball every 33ms and there'd be no noticable visual difference. You'd potentially have to add some logic on the client side to check if the ball had passed through a paddle when it teleports, but that shouldn't be too hard. – Callum Bradbury Oct 09 '15 at 09:38
  • 1
    @JamesThorpe I currently dont want to mess with cheating and anti-cheating. because its just a game between friends. – Paz Haviv Oct 09 '15 at 09:39
  • @CallumBradbury ok , ill try that , ill do every 10000 cycles which I think is about 10 milisecond. – Paz Haviv Oct 09 '15 at 09:40
  • @Gusdor every 200 cycles of a while loop , I think its 200microsecond. – Paz Haviv Oct 09 '15 at 09:40
  • @CallumBradbury , well , I tried every 1000 while cycles , what I can say from that is that the ball and the host player is teleporting. not smooth – Paz Haviv Oct 09 '15 at 09:51
  • Do it based on time not clock cycles, then you can be sure how often it is triggering and it won't be tied to how fast your CPU is. Tweak the ms delay until it appears smooth, or alternatively add some sort of client side smoothing between updates. – Callum Bradbury Oct 09 '15 at 09:55
  • @CallumBradbury well thanks for your help :) I currently did every 3 milisecond clock time ,everything but the ball movement is good Edit : everything is good now , it works almost smoothly. Im going to need to wait until I can test it over WAN , but I think that will solve it. Thanks everyone for helping :) – Paz Haviv Oct 09 '15 at 10:03

1 Answers1

1

Here are a few tips:

  1. Send packets based on time, not loop cycles. Loop cycles are heavily influenced by what else is going on on the PC. This gives you more control over how often the updates will be made and it will not vary based on system performance. 200 microseconds is crazy fast. You don't need that.
  2. You are flooding your local network with packets and causing a bottleneck.
  3. Send packets less frequently. 5 times per second is a good number to start with
  4. If that update rate is not quick enough, do what the professionals do. Interpolate where the ball is going to go based upon past updates. For example, you have an idea of direction and speed, so make an educated guess!

Updates should be regular, deterministic (you know when they will happen) and non-volatile (missing one isnt a problem). Experiment with slowing the update rate right down and see what happens.

Gusdor
  • 14,001
  • 2
  • 52
  • 64
  • Yes thats what I did now , I made it currently every 3 milisecond (from 200 microsecond , thats quite a difference) , and well its smooth , if it causes a choke again , ill try to interpolate. I will get back with an answer in few hours. Thanks :) – Paz Haviv Oct 09 '15 at 10:08