2

Ok, so I realize this has been discussed over and over as I have read countless number of Stack Overflow threads, and articles on the web. I currently have a TCP Asynchronous C# .NET Server running on a VPS.

I have gotten this to work well for the multiplayer lobbies such as connecting players to the game and what not. My main problem is when the game starts, as It becomes really blocky. So upon my research

I found some very helpful threads on Interpolation in which they guided me towards a basic (Difference (Serverpos - Localpos) * Deltatime (Time between server updates?) * Interpolation Constant). This worked in the sense that it smoothed out the frame rate, but I still had a momentary lag on the server update times.

However my main problem is that I am using the accelerometer to update the position of each player, however my server cant receive that data and process it as fast as the accelerometer updates which causes it the start messing up.

So today I tried simply sending data to the server, however my max transfer time is around 350MS, that keeps it from combining messages on accident.

I then came across "Dead Reckoning", which would work in theory however since you wouldn't be keeping track of paddle positions up to date in theory. What happens when the ball hits your opponents paddle? Do you automatically jerk the paddle into position and reverse the ball position?

Basically I think I have spun myself in a big circle, by just theorizing different ways of doing this. I am also aware of UDP, but I cant imagine a Pong multiplayer would require me to run a UDP connection, there has to be a way to use TCP.

Anyways, thank you for any help you guys give me. I am new to this and I think have gotten lost in the web of Networking.

Improve this question
2
  • This is pretty vague. Do you have a question about one of these algorithms or techniques that you're talking about? Otherwise, there isn't a question here, and as such, there really isn't an "answer" to it. I sort of see a question in the "dead reckoning" paragraph, maybe you can focus on that question specifically? Commented Dec 11, 2012 at 2:24
  • Sorry, I guess my question would be on how people achieve smooth game play with TCP. Would I send Paddle positions every 350MS while simulating ball at client level. Then just use dead reckoning for the paddles during update periods? Sorry for being vague. Commented Dec 11, 2012 at 2:46

1 Answer 1

Reset to default
3

This isn't a networking problem, it's a filter problem. I would recommend reading up on "Kalman Filtering". The math may be intimidating, but the basic problem you are trying to is "how to I interpolate state based on my knowledge of the physics of my system and (possibly) noisy and irregular measurements of user inputs and previous states".... This happens to be the classic Kalman problem.

1) You have to establish a common "time" that the server and the client agree on. There are some well known algorithms to do this. Timestamp all of your updates with this common time.

2) Using UDP is the way to go - just bear in mind that packets can be lost and they aren't guaranteed to be received in the order they were sent. This means you have to have a way to inspect packets and decide if they are "old" before you use them to update your clients. You also have the problem that if your clients can't process them as fast as they are being sent, then you will start getting large deltas on your clients....better to throw away a packet that is old than spend time processing it.

3) Minimize latency. If you can, cut your server out of the loop altogether and have your clients broadcast updates to each other.

4) This is where filter theory comes in - for each degree of freedom, decide how much error you are willing to tolerate (difference between what a client sees and "truth"). For instance, for an airplane, the position is not very dynamic - you could probably get away with one or even two second updates and have very little position error in the clients. However, attitude (pitch, yaw, roll), is very dynamic, so you might need to update these states every .25 seconds to achieve acceptable position error. Kalman theory will tell you what the update rate needs to be to achieve the error you need. You can also change your update rate based on what you know is happening at the originating client....rapid control inputs => high update rate vs. no control input => low update rate.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Alright, I am not ignoring the Kalman theory, as it is definitely interesting. However I think for the sake of cost/effectiveness it would be better to simply implement a UDP connection and have the server keep the clients in sync? Also thanks for the Kalman tip looks interesting for long term learning just need to get this implemented quickly.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.