Game Programming Theory Question

[Drakkon]

So company wants to delve into multiplayer games and im having trouble figuring out how to beat the stream when it comes to multiplayer games that are not turn based, in other words all players operating at once.

So I started a simple TCP network pong game, and i can get the paddles moving so each player can see the other person moving (albiet somewhat choppy) but when it comes to the ball its really been a mess. I tried letting server control the ball position but the lag on even a normal network makes it really slow. I can let the clients pass off control but still looks choppy on the other persons screen. I've tried passing just direction/angle/velocity but one client gets off in some way. I've tried compression routines and passing as little of data as possible but still is really laggy.

Anyone here have any input as to how games like this are controlled? what role should the server play? observer or controler? what role should client play? any forums where i can look to ask?

 

[kamper]

I have absolutely no experience but here's what I'd try:
-server still dictates exactly where the ball is, but only sends out advertisements at a slow rate
-advertisements include absolute location, direction and velocity
-clients interpolate inbetween advertisements

So basically you have your second scenario, but with periodic syncing with the server.

And you said it's tcp based? Do you just have a huge mass of open tcp connections for the duration of the game or do you set them up and tear them down for every message? I believe that positional games like that are always done with udp. On a lan it should be plenty reliable, on a wan you can just crank up the number of packets and if there's ever a break in service, one of the clients just gets confused for a moment (when you play a multiplayer game online with a high ping other players freeze and then show up far away just a bit later). Multicast is much easier to do with udp than tcp.

 

[Drakkon]

Went with TCP based because I was told it be better when it comes to sending large important packets (which once i can figure out the whole interaction part that will come up next). now im not 100% sure if thats true but just what some guy told me. I just use a single TCP from each client to server both operating on the same port, and limiting it to 2 connections right now so shouldnt be getting too overloaded but as kinda explained above i can see why it might be. UDP might work better for the movement while TCP for the data maybe.

When i watch the packets it looks like the paddle moving and the ball moving is throwing too many packets for the server to interpolate and send something back. Periodic polling may be a good solution, now im wondering if maybe use a standard 10-50ms rate or do soemthing like find the current ping of both clients to the server and whichever is higher that becomes the rate...

 

[Atheus]

I really would use UDP, it's just faster, you are losing valuable miliseconds in the handshake.

Also, you may have to do some interpolation or anticipation of the other player's move (as kamper suggested). Not many people can react in under 100ms so if you keep the timeslice under that you shouldn't have any problems. Say you sync every 50ms, each player will only send 20pps during a game, which is nothing.