Networking Help

[Luke Pierson]

Hey there! I’m working on an online multiplayer rts and have some experience with networking in gml. I have it so there’s a server that clients can connect to, they can enter a match with each other, they can message each other, and even move units around with the other player being able to see the same movements play out on their computer.

I have no plans to release the game or use a dedicated server, just my computer running the server when I decide to get the game going. I’m just working on this as a personal project for me and my friends to play.

What I’m worried about though and need advice on is synchronization. I’ve done pretty extensive research and I think I’m going to try to go with a lockstep approach.

My main question I think is how to ensure the players are synchronized at the start of the game? I’m imagining if the server pairs players together and then updates the clients that they’ve found a match and load into the game, how can I ensure that the players load in at the same exact time and start their first ticks (for the lockstep) at the same time?

Oh also I’m using TCP. I know it’s slower than UDP, but I think I can hopefully make it work, especially with an rts where input delay is kind of expected, since its indirect control and I can play animations to smooth it out. Alternatively, it is an rts which means lots of units moving around. So idk if you think I really should switch, please tell me! Thanks for taking the time!

 

[woods]

how can I ensure that the players load in at the same exact time and start their first ticks (for the lockstep) at the same time?

players hit the ready button..
when all players have ready up, 3,2,1 .... game starts

 

[Luke Pierson]

how can I ensure that the players load in at the same exact time and start their first ticks (for the lockstep) at the same time?

players hit the ready button..
when all players have ready up, 3,2,1 .... game starts

i think I might have figured it out. But my concern was that the server would confirm that all players are ready and send the confirmation to the clients to begin the countdown but because latency can affect the time it arrives, the games would begin their countdown at different times which means they would not be synchronized.

BUT if I do lockstep, I think I don’t really need to worry about it because I’m only progressing the game forward when both computers have sent their actions. It’s like rapid turn based game play in a way. Idk if I’m on the right track, but I don’t see why it won’t work

 

[woods]

im definitely not the expert here ;o)
but here's my thoughts

some things are out of our hands.. latency boils down to how fast the clients and server talk to eachother.
with the server handling all the action and just asking clients for input.. (server is always right) you are gonna have a bit of delay of course. we cant help hardware and connection speed ;o)

It’s like rapid turn based game play in a way.

maybe if you have some sort of a confirmation from the clients to the server, and then server spits out new data all the clients.. might be able to reduce the de-sync effect.
but this would slow the overall flow of the game down to the speed of the weakest connection?

just a thought

 

[Pelican Police]

Here's a method to make sure everything runs perfectly in sync:

1. Client -> Server [my current_time is 4000]
We send our current_time to the server every second.

2. Server -> Client [Your current_time was 4000]
The server will reply as fast as it can.
When we receive this reply, time has passed and so the current_time is now 5000.
We can determine that the roundtrip was 1000 (i.e. 1 second).

3. Server - > Client [my current_time is 8000]
The server will be doing the same to us.

4. Client -> Server [Your current time was 8000]
So we reply as soon as we can.

The current_time of the server when it sent that message was 8000.
Based on the roundtrip time, that was 500 (0.5 seconds) ago.
The 500 comes from half the round trip: 1000 * 0.5 (we only need the time taken from server-> client, the roundtrip time is client->server->client).
So in this exact moment, the current_time of the server will be 8000+500.

If our current_time right now is 4500, then the relative offset between us is (8500-4500) so 4000 (4 seconds).
This just means that they opened their game 4 seconds before us.

As the network is unpredictable, we need to keep an average their current_time relative to ours. The more this data is exchanged, the more accurate it will be.
Remember that current_time is linear, it is not affected by fps. You don't need to 'reset' the average unless the server restarts.
Keep track of how different the incoming values are to the average, this will give you a "confidence" score of how sure we are that these values are correct.

Once we've gathered this information, the server can say "I want you to do X when my current_time is 10000", and we know exactly when to do it.
At any given moment we can calculate the server's current time with: our current_time + relative offset (4000)
If our current_time is 4500, the server's current_time is 8500, so they want us to perform X in exactly 1500 (1.5 seconds).