Heya peeps.. after several days of tring things, reading etc. i still don't get it about ticks and synch. I'm new in networked games.. or lets say, Fast Action Network. Server determines Position of clients in a Map. Simple thing. When i think of how things work, its like this Server/Client client sends data to server, Server replies. Now we multiply that by lottsa times, and Very Fast. and with Several clients. I see a big mess, but programs don't see messes.. they know what to do and they do it. Server recv's a pack, it processes, and replies.. doesn't mater if there's a million and from 100 different clients. Server knows who each pack is from and he can work them. and Replies accordingly to each client. Since we got limitations in speed. We have to Make packs as small as we can, we use UDP to make things even faster and losing some data here doesn't matter. Thats basically it.. thats how its supposed to work how i see it. Uey, unfortunately things Are Not working by the way i see it. it all makes sense but on the run, it all crashes, and u get a choppy result, things lock up for secs, etc (what a Mess) What am i missing? i keep reading about ticks and synch.. but i don't understand them. Like DDn said, Server sends a Tick... client doesn't update frame until a tick is recv'd. hmmm ok....why? someone told me, have server send a tick every 20ms, the tick represnts the time since game has begun. ok... why do i need that tick? what is the client supposed to do with knowing when the game started? The 1 thing i heard that made sense is that... ok, we can't have 100 clients spitting out UDP packs all over cause we'l get collisions. only 1 puter can talk at a time on a network, of subnet or whatever... ok i've learned something like that time ago.. so this makes sence go on, and the point of the tick is to Synch the clients so that they all won't be spitting out data and colliding and flooding the server.. Hey, that makes sense. i get it woohoo. But... thats got notin to do with what i read or everyone else says.. i dunno :/ so i added a timer to my app, simple thing, and made it spit out fdata every 10ms(CORRECTION, 10ms, i meant 100ms, Sorry My Big bad ... i have my client move my character constantly... bout it still choppy.. and every now and then like i guess there's a collision and the guy stops... i dunno. this is just 1 client, 1 server... how can it go choppy? i'm useing UDP, sending every 10ms packs, the server has a dedicated thread to recv UDP's... the client is on non-blocking mode, and also has a thread just for recv'n udp's. i've done things by the book.. but still it doesn't work right :/ (BTW, making the UDP socket non-blocking made performance worst) Must it be a TICK thing? its the only thing i can think of... since i hear its soo important on network games and i got no idea of thme anways... i'l BBL to see whats up i'm crackign up... What Is all this about Ticks? and Synch? why do i need it? what does it do? what am i suposed to do with them? hahahaahahah HELP ME!!!!!! i'm going crazyyyyyyy Thank youuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu Edited by - sanced on 10/1/00 6:13:31 PM Edited by - sanced on 10/1/00 7:35:28 PM

Ahh yes networking hell 8^) I''ve seen it before. Getting good scalable network synchronization protocol for an action game is difficult. That is why i suggest going with the simple rcv tick step scheme and then improve upon that. Well if you update at 10ms thats 100 updates per second. At 32 bytes per UDP packet thats 3200 bytes / sec just for the UDP header overhead. On a 56k modem that quicikly saturates the bandwidth, and even on lan you might have problems. Most action games dont update much more than 10 ups, thats 100 ms between each tick. Also dont forget about packet clumping, your rcv thread could read in 1 packet / 100 ms and then suddenly 3 or 4 packet / 100ms. This results in the players position poping to the last packet recived. I''ve had this problem before so you might want to check on it. Or it could be that your main thread consumes the packets at irregualr intervals, this would produce the same results. Its possible you could have a problem in your server or client logic and its unrelated to the communcation code at all (as was the case with one poster). As you can see you have to trace very carefully the path of a packet from its creation to destruction and utilization, as the error could lie anywhere. Plan on implementing comprehensive packet debug code (packet dumps with timmer information, individual streams,client,connection (UDP/TCP_IP) dumps, logic checks to see how the packet is used and it intergrates into your simulation, debug packet info (unique packet id for each pacekt), etc..). All of these will be useful in tracking down bugs in your protocols, and also later when you want to optimize them.

Good Luck

-ddn

hehehehehe i love you ddn

shit icant even see any more i got my eyes all blury...

anyways, ok.... there we go again start with a simple rcv Tick
What is this Tick about? a rcv tick?
Server or client Receive?

so Server sends ticks every 20ms... (BRB gotta read again what u said)
Ahh damn, yeah i messed up, i said 10ms, i meant 100ms. i have my timer to trigger at 100ms (cause i read thats like a kinda standard, and default) 10 triggers per sec.. sounds fine.

u siad "10 ups, thats 100 ms between each tick"
so i should have this tick every 100ms ok, i understood that part But, whats this tick ? for me Tick = Beep hehehe
is Tick some vital info that tells client or server something important? if it is, who sends it? (Server i suppose) what does it tell the client?

Thanks for bareing with me =)

Well, a good framework would be:

Client keeps track of client movement / action. If client moves forward X steps or fires Y weapon, that is shown on the client, and immediately sent to the server.

On the server, accumulate Client Updates and change the data structures that represent their positions, fire any weapons and calculate trajectory etc...

Then, every 50 - 100 ms (10 - 20 times per second) send out all of the client updates from the last update. This is gonna be a good place for optimization.

Hope that helps.

i hear ya jon

I just made my own input buffer on the client side... so the client buffers up all input and spits it out UDP to the server every... 50ms or 100ms still not sure

and i also increased the size of the steps which u move when u... move

so all that together makes the game seem to work faster. yes, randomly between every 3 to 9 secs.. the game client pauses i dunno why... debugging that now.

thinking if i should buffer output of the server as well and release it every 50ms or 100ms... or since its the server.. let it spit out whenever it needs to or is ready. hmm

Still can anyone explain to me whats this about Ticks ?

yeah yeah me again (i just cant get this right)

been doing some performance check on my code
basicly i got this on a thread to recv udp packs from clients.

While(1)
{
--Counter++ // to measure performance
--do a select() and see if theres Data to be read on socket
--{
----if there is,
----{
--------recvfrom()
--------proces data;
----}
--}
}

there's more code in there but don't mater, i added a Loop counter to see how many times per 500ms the loop goes thru and i get 5000-6000 times the loop cycles poer 500ms.. i guess
1000 cycles per 100ms With 1 Client moving constantly.

That sounds perfect to me... that cycle is recv'n data, and procesing it at 1000 cycles per 100ms

Client still acts choppy


Edited by - sanced on October 2, 2000 8:34:37 AM

I think i finnaly understood Ticks correct me if im wrong of how its supposed to work.

the secuence/lopp would be something like,

- Tick
- Clients Refresh
- All clients send input to svr (Movement, heading, Fire, etc)
- Server recv''s from all, process''s everyone, builds the replys
- replies to all clients the States of the world
- Server sends Tick to clients
- clients Refresh their States of the world, including the screen
....
Cycle starts again

this makes everyone be... what i hear "synch''d"
and controls the flow of the game i guess.

According to the secuence i thaught, its kinda like a FAST turn based thing. Tick actually = End of turn.

Questions:
i''m not sure bout the time of a tick, would it be like...
Server, collect stuff from clients and process...
when 10ms or 20ms the Tick is Activated, Compose a package of current state of the world, send it to all clients, and then send Tick signal.

is that it :D ?????????????????
please tell me that thats exactly the idea... =)

Yes that''s the gist of an in step sychronization routine. This isnt optimal due to its sensentivity to loss and latency, but it''s a good start. Once you have the in step rountine working you can extend it so that the client looks for say every 10th tick from the server, but continues steping until it hits the 20th tick wall (stops if the server doesnt send one, but continues if there is a higher tick value recived, indicating loss). This makes the client less sensentive to loss and results in a smoother simulaition. From a latency standpoint having to wait for a tick confirmation introduces about a step worth of latency or more. Don''t skimp on debug code for the communication routine, it will pay off down the line. I would use blocking sockets on the in packet thread, as its more efficent. Also i would make a seperate out packet thread from the main thread and use blocking sockets on that too. Async sockets have poor performance, they say and undully complicates the main loop.

Good Luck

-ddn

Sanced, you''re getting there, but I wouldn''t suggest a wait on the client side. Send as soon as your player requests movement. Accumulate movement etc... on the server and send out server state at these ''ticks'' like you have it shown.