Sync Probs Networking An RTS

yo im currently working on a Real TIme Strategy game simular to Populous 3 ( go here to see a screen shot (pictures section) http://www.strategyplanet.com/populous/popiso ) (if any of u have played it ul know what ive got ahead) ive used sockets before in other languages but only recently found out how to do it in c++, thats not the problem tho, at the moment each command is sent in a 10 byte packet using TCP for example unit selection would send [PACKETTYPE][TEAM][X][Y][WIDTH][HEIGHT] which normaly looks summin like "C£$%[];{Lk" now in this respect it works great and commanding like a thousand units to a place requires only about 20bytes of data to be sent, but the problem is the time delay it takes for the other player's exe to recieve the command and in which time the unit on thr pc will move say 10 milliseconds after the one on mine which causes a variance in position and thus the game is out of sync, i tried doing a frame by frame "PING" where unless all player's return the PING it will not continue with the game but this means that say the game is running at 40fps each ping is 10bytes which is sent and recieved, thus 1 ping = 20 bytes * frames = 800bytes per second per player (not including all the TCP header info) do u know of a better more 56k friendly method of sync? if so please mail back or any suggestions or ideas would be great.. and im sorry for posting in one great big lump of text but it probly reflects the way i code lol, thanx for ur time

I've been thinking about the same thing. Perhaps you could implement a latency feature; keep a frame counter on each side, and when you send a command you (a) queue the command on your local machine for execution after a delay of (x) frames, and (b) send the command to the other machine with an extra little bit of data saying which frame to execute the command on; if the other machine doesn't reply with an 'I got it!' packet before the target frame arrives, you pause.. or something. And those status pings probably wouldn't hurt either.

But no matter what you do, don't do what I did: Sending a packet containing the state of all game keys pressed on the keyboard (a struct with a bunch of 1-bit boolean bitfields, to minimize packet size) at each frame, and blocking for it. It works, and you get perfect sync (theoretically), but it shoots performance to hell unless you're on a LAN - and even then it sometimes still does :D

lol i have implemented a few ultra lag methods with perfect sync hehe, the first thing u mentioned about queing and logging ticks is interesting, ive thought of something simular i will set max frames to around 20 frames and then have a global long value to store the current total frame count which is sent along with the command, then when the packet is recieved it counts the difference in the frames of when the command was excecuted and when it was recieved, then i thought of a reverse procedure of some sort, like a log of the past events that is time logged so it reverts back to the frame when the command is excecuted and then excecutes the command, so now i just gotta code a function to log commands, but knowing my luck il find another major flaw with the multiplayer code :D thnx for ur reply

>>so it reverts back to the frame when the command is excecuted and then excecutes the command
Hmm, that's an interesting idea - logging the previous states. Then you'd have to take into account if you execute a command then receive a packet that says "do something else 3 frames ago", and then you'd have to backtrack, execute the first command, then fast forward and execute the second command again. But what happens when you exceed the 20 frames?.. Unless you send back a packet that says "Ran out of backtracking frames, here's where I'm at" and send the current status or something.

good point but ive already thought of a fix for it, i send a PING to each player every 20 frames (Ping per second) which holds the game in a recv loop until the ping is recieved this way command history in theory should never exceed 20 frames

Quote:

---

i send a PING to each player every 20 frames (Ping per second) which holds the game in a recv loop until the ping is recieved this way command history in theory should never exceed 20 frames

---

Good idea, except that this might cause a pause every 20 frames. Still, I bet it's a lot better than ping every frame :D

lol ya my initial idea kinda sucked lol.. actualy it did cause a small noticable pause over 56k but i have made it barely niticable by sending the ping request on frame 18 so by the time its at 20 it should be ready to continue.. im sure thrs still errors in my theory and in my ideas for implementation.. lol its my first attempt at making an rts and a networked game of this magnitude so i think i kinda dived into the deep end abit hehe

>>its my first attempt at making an rts and a networked game of this magnitude so i think i kinda dived into the deep end abit hehe
I've been wanting to try making an RTS for some time now... how complicated is it?

well im sure u prbly can easily, the only kinda stuff i did before this game was small rpg style games like zelda spoofs, but the engine itself is exactly the same, im coding virtualy all of it in gdi and im still getting a great frame rate (300fps on p4 computers... a humble 50fps on mine :S ), basicly i started off making a general GDI class.. u know for stuff like buffers layering and alpha blending bitmaps, then i decided heck il add on a sprite class that uses the gdi class, then i thought il build an rpg.. then after loads of mods i ended up with my current game... the coding ive used in most places i could far improve on but it was a working progress thing (learn as i go), so gradualy over a few months ive added to it and my old coding seems kinda scruffy now lol... i gotta say the hardest part so far has gotta be pathfinding but its quite an easy concept to grasp but irritating to code, erm heres a pic of my game in its glory:
http://www.strategyplanet.com/populo...so/screen9.jpg
if ur interested i could send u the source and res for it so u can see my methods i implemented for urself, aslong as u excused the odd unexplainable variable, code thats more untidy than my room and about as efficient as the uk rail service... hehe

>>u know for stuff like buffers layering and alpha blending bitmaps
Cool, didn't realize you could alpha blend with GDI.

Looks really cool, I like the lightning :) Well, I have to get my sockets wrapper in order before I can do any RTS making, which may take some time... and then I want to learn to use OpenGL or Direct3D. But good luck with your sync'ing :)

thnx u 2

I have been doing a rts myself. I havent done much towards the networking yet but I have thought a bit about how I would do it.

My game keeps a program counter that loops constantly. I was thinking that when an action occurs certain information for that action is sent, ie: action, unit, parameters, time.

Time will be the value of the program counter when that action is to begin.

Example: Player 1 moves a unit
Action is MOVE.
Unit is the unit number of the moving unit.
Parameter is its destination, x and y.
Time is a point on the program counter far enough ahead of its current position that Player 2's machine will receive and process the instruction before it occurs but not so far that the user will notice a delay.

So if player 1 is moving unit 3, to position 45,3 and the current program counter is 245 it would send.. M:3:45:3:255

Unit three would then start its move operation on both machines at program counter 255.

Because the program counter is part of a processing thread and graphics are drawn independantly frame rate doesn't affect the game speed.

Periodically, the machines communicate making sure their program counters aren't to far apart, if they are the faster machine will slow its game speed.

All very good, except:

Quote:

---

a point on the program counter far enough ahead of its current position that Player 2's machine will receive and process the instruction before it occurs but not so far that the user will notice a delay.

---

The problem is, if the instruction ISN'T received before the 'time' arrives, how can you tell and how will you fix it? That is what we have been discussing ;)

Quote:

---

I've been thinking about the same thing. Perhaps you could implement a latency feature; keep a frame counter on each side, and when you send a command you (a) queue the command on your local machine for execution after a delay of (x) frames, and (b) send the command to the other machine with an extra little bit of data saying which frame to execute the command on; if the other machine doesn't reply with an 'I got it!' packet before the target frame arrives, you pause.. or something. And those status pings probably wouldn't hurt either.

---

Ahh, that is essentially what i was suggesting. My bad .;)

thrs still loads of flaws in any implementation i can think of, i guess if i was to use ur suggested method it wld require handshaking between all the clients and then thrs no way of ensuring that all machines will conform to the protocal,i suppose u cld do summin real awkward like::

PLAYER1> send movement suggestion and que the movement
PLAYER2> recv suggestion (& que) send time suggestion
PLAYER3> recv suggestion (& que) send time suggestion
PLAYER1> recv all time suggestion calculate real time suggestion
PLAYER1> send real time suggestion mark time in que
PLAYER2> send ready (mark in que as ready)
PLAYER3> send ready (mark in que as ready)
PLAYER1> recv both confirmations (mark in que as ready)

PLAYER1> PLAYER2> PLAYER3> PROCESS QUE

and that takes up 90bytes per movement requiring loads of handshaking resulting in even more noticable lag and still has major flaws :P soo much irritation.. it makes me wanna stop coding the RTS and starting a simple offline RPG (like zelda what a cool game and no networking involved) hehe

Well, I don't know about all the time negotiation, that might be annoying for the user (command delay is unconstant). I do know that in starcraft there's a latency setting feature, so that the user manually sets the latency to low, high or extra high - meaning the command delay is small, medium, or large. Then the user just sets the latency higher until there are no pauses in the game due to sync... not sure how it does the pauses though.

You could have one system pause, wait for the late client to catch up, then unpause it for the other client when both are at the same packet number. If need be you could have a latency screen show up with something such as: "Player X is lagging....attempting to catch up".

Sorry if this has been brought up before, but I think this is similar to how they did it in Starcraft.

do u meen like send cmd, pause-> recv cmd, then send back frame when it was processed then recv frame and catchup, this might work but ud see random fluctuations of the game speed, kinda like when u sit on the tv remote and u wonder why it keeps going from normal play to fast forward