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.
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.