Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Multiplayer Movement - TCP

Author
Message
Sph!nx
17
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 28th Sep 2013 21:09
Hey everybody,

I made a thread about multiplayer movement a while ago and eventhough I can do UDP movement, I've changed direction and wish to experiment with TCP movement.

Here's my current idea:
Quote: "
- Clients sends keystrokes and mouse movements to server
- Server performs the actual position/collision/etc. and sends data back
- Clients update their player positions, etc.
"


I haven't really experimented with it much (I'm in the process of setting it up in my code) but I expect much lag. To compensate I could update the client right away and them rectify any mismatches with the server, but that would probably cause effects like players suddenly moving when there is more lag than anticipated.

I know I could compensate for lag, through movement predictions and stuff, but I wouldn't know where to begin with that (not really a match genuis...)

Any kind of input is much appreciated.
Thanks!

Regards Sph!nx
www.mental-image.net
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 29th Sep 2013 00:49
Interesting; you want to use TCP for movement instead of UDP; why so?

I imagine one method of motion prediction is to use Catmull-Rom interpolation using the previous and current vectors; but I have no complete implementation of this in action. You may need to search for an example in the forum.

I know Lee provided one in the Dark Source code library sold on the main TGC website.

Perhaps someone else may have a nifty solution ready to show.

Sergey K
22
Years of Service
User Offline
Joined: 4th Jan 2004
Location:
Posted: 29th Sep 2013 10:55
Quote: "Interesting; you want to use TCP for movement instead of UDP; why so?"

i can answer to that question..
TCP is much more reliable than UDP. i highly recomend using it in large scale games.

also in both cases UDP and TCP there will be kind of lag between the players
in UDP - there is a chance that the other client wont recive the player position
and in TCP - its just long trip between the client to the other client
if you know what i mean (client -> server -> other client) it might lag a little

also i did some experiments on this before
and i suggest to make the correction of the position on the reciving side.
what do i mean?

thats true what you said about the "clients updates the player position etc"
but you will see the player laging and jumping between the frames
the best way is to make a position correction on this side.
so when the other client recives the positions, he will "Curve" them slowly to the main client's position.

i hope you understood
cuz multiplayer stuff are very very hard and annoying sometimes
its very ennoying to talk about "Client" and "other client" if you dont know whats that means, it will make your life harder to read what i said

Stream SnifferTools/Plugins/Models/Games and more!
Sph!nx
17
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 29th Sep 2013 15:10 Edited at: 29th Sep 2013 15:44
Thanks for your quick replies!

I believe you, Sergey, told me in my previous thread that UDP connects players with each other and TCP just the clients with the server, thus allowing for more clients, if the server allows it, than with UDP.

I know UDP also has lag, but that's much lower in my experience and in case of UDP, I have a stream of packets, so a dropped packet is not that much of a problem.

What do you mean by "curve"? Just move them right, but gradually (in steps), instead of directly (one call)?

Edit
Chris, I have that snippets pack and found those snippets but the math is hard for me to understand and I prolly need something simpler than that.

Regards Sph!nx
www.mental-image.net
Sergey K
22
Years of Service
User Offline
Joined: 4th Jan 2004
Location:
Posted: 29th Sep 2013 15:49
Quote: "I know UDP also has lag, but that's much lower in my experience and in case of UDP, I have a stream of packets, so a dropped packet is not that much of a problem."

its all up to your game design. what you play? an a massive online game or just pvp like 1 on 1, or max 10 players or so?
those numbers metters.
lets say you using UDP for up to 10 players.
there is no Server/Client in this, so every client must hold up to 10 players in same time
it might be heavy for low computers.

Quote: "What do you mean by "curve"? Just move them right, but gradually (in steps), instead of directly (one call)?"

humm.. its kinda hard to explain, but try to imagine
lets say in pressing W to move forward, it sends to other player that i moving forward untill i droped the W key. right?
now, if the ping between the players is stable, it will have no problems doing that. and the positions of the same player on 2 different clients will be the same.
but lets assume your ping jumped from 200ms to 210ms.
what happening now?
when you pressed W and moved forward in distance of 500 units (X/Y/Z)
but what other client will see is 490 units of movement.
so not so precise after all. right?

thats why i suggesting to overthink about how you gonna do the movement and add a "curving" to the final position of the player. so those 10 units can be fixed.


note;
i said units, its X/Y/Z scale, but you can also think of it as meters.

Stream SnifferTools/Plugins/Models/Games and more!
Sph!nx
17
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 29th Sep 2013 15:59 Edited at: 29th Sep 2013 16:00
Sergey, I appreciate your input!

I know, not the most original idea, but I'm working on a minecraft-like game (but set in space with generated planets, in sectors, instead of a large never ending worlds).

Before I start with the 'voxel'/cube engine part (I did my research and understand most of the mechanics!) I wish to get the networking just right.

I also use the term 'units'. I understand that the "curve" is some kind of function/calculation (client side) that would do the required actions, but with the amount of lag taken into consideration, correct?

I have those snippets Chris talked about, but I'm not sure if I'm allowed to post it here, cause it's part of a commercial product sold by TGC.

Regards Sph!nx
www.mental-image.net
thenerd
17
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 29th Sep 2013 16:11 Edited at: 29th Sep 2013 16:13
Quote: "I believe you, Sergey, told me in my previous thread that UDP connects players with each other and TCP just the clients with the server, thus allowing for more clients, if the server allows it, than with UDP.
"


This is completely untrue. with a UDP system all you have to do is specify a target to send a data packet to. It's perfectly valid to have a server that receives UDP input packets from a client, processes them, and sends out the results through UDP back to all the clients. That's how most professional games work. TCP is much too slow for any realtime game movement.

Quote: "I know UDP also has lag, but that's much lower in my experience and in case of UDP, I have a stream of packets, so a dropped packet is not that much of a problem."


You're correct in saying this. With UDP a dropped packet is completely unimportant because the send time is very fast. with TCP, each packet is delayed so they are received in the correct order. If you're sending movement or position data, this would become a problem as a game got longer because if the user's internet can't handle the amount of data being received or sent, the TCP packets will pile up and the latency will get higher and higher as the TCP system always reads the oldest packet first. With UDP, if the connection cannot handle the amount of data being received, Some packets will be deleted which is unimportant.

Quote: "I know, not the most original idea, but I'm working on a minecraft-like game (but set in space with generated planets, in sectors, instead of a large never ending worlds).

Before I start with the 'voxel'/cube engine part (I did my research and understand most of the mechanics!) I wish to get the networking just right.
"


If you're working on a game similar to minecraft, you might want to create a sort of "Reliable UDP" system that checks if a packet has been received to ensure that important data such as block placing or breaking reaches the server. But I would still advice against using TCP for that style of game.

Sph!nx
17
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 29th Sep 2013 16:22
Hey thenerd,

My first idea was, to have things like stats,blocks data, and stuff be send through TCP.

UDP was for movement, angles and everything else that would be send in a 'constant stream of packets', where lost packets are dealt with. I already have this working in a previous prototype, so I can always implement that.

The idea is to be able to have as much clients as the server would allow for/can handle. Either way, I would need still to have a system that compensated for lag...

Regards Sph!nx
www.mental-image.net
thenerd
17
Years of Service
User Offline
Joined: 9th Mar 2009
Location: Boston, USA
Posted: 29th Sep 2013 16:36
You could try that. TCP might even be too slow for block data but I'm not sure, it might work. You could try TCP first and if it's too slow, use a reliable UDP system. The movement should definitely be UDP which you already have working.

Sph!nx
17
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 30th Sep 2013 19:44 Edited at: 30th Sep 2013 19:45
Al right, Gonna do it like this:

A simple method to counter lag/stuttering in motion/movement:
Quote: "Client sends "states" of keys and mouse movement to server, which sends them to other clients (this will work for all kind of motion).

Client receive the states and start/end the movement of the desired players/objects, based on the state."


Position Syncing:
Server sends position data to clients and they update their objects. Perhaps some stuttering might occur, but it would be reduced, right?

It has been suggested before and I think that it would be the simplest method... predictions and dead reckoning is very difficult to understand for me.

Regards Sph!nx
www.mental-image.net
Michael P
20
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Oct 2013 00:54 Edited at: 1st Oct 2013 00:57
@thenerd agree with most of what you are saying.

However, I don't like the idea of creating a reliable UDP protocol. What is the point in reinventing the wheel? TCP is more or less UDP with an additional reliable layer and some connection protocol. It is unlikely that you will manage to create a reliable UDP protocol which is as effective and efficient as TCP.

My advice is to use TCP for sending reliable data like stats, and UDP for low latency unreliable data like player movements.

On the issue of how TCP handles large data streams (sending all your block data in one big go); it handles this very well because it has congestion control mechanisms to send large data streams in multiple smaller packets. UDP has no such mechanisms.

@ Sph!nx
I experimented with your idea of sending key strokes a while back. Doing it really simply without any prediction algorithms is generally too slow; you really do notice the lag. However there are alot of algorithms around which can reduce this lag by predicting movement; I think games like counter strike use said algorithms.

Sph!nx
17
Years of Service
User Offline
Joined: 3rd Dec 2008
Location: The Netherlands
Posted: 1st Oct 2013 14:42 Edited at: 1st Oct 2013 14:50
Hey Michael,

Yep, been searching around the web and the information is quite sparse. There is some stuff, also on the Valve Wiki but maths is not my strong point. **

I have those snippets, written by TGC and would like to share those with someone who could explain them to me... but I'm afraid that would not be allowed, since those snippets are part of an official TGC product. Perhaps I should send a mail to TGC and ask them if it is ok to do so.

**
And that's an understatement. I love programming and I constantly impress myself on how well it goes and how many complicated things I can do (and fully understand!), but I still have a problem with Dyscalculia (It's a fear/panic thing that prevents me from grasping even simple calculations. It's not that I could never understand, cause logic is very high within me, but with numbers, it can take ages until I 'get it'... but I'm determined

Regards Sph!nx
www.mental-image.net
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 2nd Oct 2013 22:32 Edited at: 2nd Oct 2013 22:38
There have been some professional solutions suggested; but just to clarify why I asked about TCP usage for movement; UDP - being the fastest solution of the two which is also used in most AAA games I have played, sending positions a number of times per second would compensate for lost packets; and is doing so on millions of game sessions across hundreds of countries on X-Boxes, PS3s and PCs as I type this message. Again, TCP has professional applications in video games, such as Michael mentioned.

To my point regarding interpolation, because Sph!nx wasn't very sure.

Let us exaggerate for a moment and imagine that the new position of each player is synchronized once every 2 seconds; which in a real world live game would be catastrophic.

Let us think of vectors as XYZ positions.

In the following example, a new position is given to a set of cones once every 2 seconds; I have used linear interpolation on a blue cone, curved on a green cone, and no interpolation on the red cone. If you can grasp the sense of linear interpolation; then Catmull-Rom is something that can help you guess the path of motion, not just in a straight line.

This will show you how interpolation helps reduce lag; although there is no cure for poor network performance; at least it looks like the players are walking forward every two seconds, instead of teleporting! In a real game your movement would be updater numerous times per second.



But that is just a starting point; in a serious application of this technique; you would also transmit the angle and speed of the moving players. Using the last 2 positions, a Catmull-Rom curve would help your video game guess where the player will be in the next second or two.

Do not put too much emphasis on optimization and interpolation until you get the game working; first get it working, then refine it; you might end up optimizing and interpolating something that does not and cannot work

Login to post a reply

Server time is: 2026-07-07 00:08:18
Your offset time is: 2026-07-07 00:08:18