• Announcements

GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Followers 0

What do you mean "don't measure time with secs/milisecs, instead use ticks" for state synchronization?

5 posts in this topic

Hmm from what I read here in this forum section, it is highly discouraged to measure time using seconds/miliseconds, instead use ticks for synchronization. I wonder what does it really mean, since synchronization involves ping time, and it is measured with miliseconds. I recently read the valve network synchronization technique, however I cannot seem to fully grasp it as a whole.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

From what I can swallow of those huge wall of texts, I think this is how it was implemented.

1. When the game start, the server sends me the "Tick number" (assume it's 0). The server increase this number every time it do simulation update.

2. I receive it. I, too will increase this number every local simulation update.

3. Assume the server and client update rate is 10 fps, which is 100 ms between each tick. Between those tick I collect user input, and of course I include the current tick number. Of course I do read packets from server, but let's not focus on that. The server is doing almost the same thing on his side (read, simulate, send) every 100 ms.

4. Assume it's 100 ms since last tick. Now it's time to update. Me (client), simulate locally using those buffered input. Then directly I send those buffered input to server.

5. Server receives it, perhaps 200 ms later. It reads the client input. However, it must be too late. The server's tick number will almost always be bigger than the client. In server, the tick number currently could be 12, while the tick number included in client packet was 10.

Now, I got several questions :

1. Well, now that there's unmatching tick number, what should the server do? I got the notion that there should be some kind of "rewind and replay" stuffs. But who does it? the server or the client?

2. Assume that at the client's step no. 3, the client press forward and quickly press left. Since this is UDP, I'm sure the packets could be received by the server not in order. Should the client be using reliable/ordered send for input?

Thanks before, I'm trying to make a multiplayer pong, so it's quite relevant. Pong is kinda twitch based, don't you agree ;)

0

Share on other sites

synchronization involves ping time, and it is measured with miliseconds

The *simulation time* should be measured in ticks. That way, everybody runs the same simulation, ticking at the same rate, so that time-variant behavior (like acceleration) is the same across all players.
*real time* of course is measured in seconds, so at some level, there is code that "looks at the clock" and decides what the current simulation tick "should be" and ticks the simulation forward, one tick at a time, until it is.

You can calculate the current target tick as such:

targetTick = (systemTime() - timeOfCalibration) * speedOfSimulation + tickAtCalibration;
None of your simulation code should use "real time," because doing so makes it impossible to unit test, makes it impossible to rewind time if needed, and generally causes bugs.

Well, now that there's unmatching tick number, what should the server do?

In Source, the server may rewind time and re-play the particular entity that provided late input data, as long as the rewind is "not too far." If the rewind is too far, the server must discard the input. The client will somehow detect/be told that it is out of sync and "snap" if that happens.

Should the client be using reliable/ordered send for input?

If your simulation absolutely requires determinism (such as for an RTS or other lockstep game where state is never sent, only inputs,) then yes, you will need reliable, ordered, delivery of commands/inputs. This means the game may stall if one player is having connection issues.
If the simulation can recover from de-sync ("correct" a client) then it's more likely that the rare case of input loss is dealt with by correcting the client whose packet didn't make it.
Typically, each input message will have a timestamp for the simulation tick it was intended for. As long as the server sorts the messages by tick, and/or rewinds time the right amount for each, then things will work out.
1

Share on other sites

Hmm I don't think I get it here. I feel so stupid. I understand what a tick rate is, and that is used for fixed time-step which helps ensuring predictability also to stabilize physics. I know it means to decouple physics and rendering. Also, now I get that pingtime is used for that rewind and replay stuff, also for client side prediction. Now to clear another confusion.

1. Based on the approach above, of course the tick number in the server and the client will differ (because of lag).

(the server is simulating tick 12, client was sending tick 10) --> (server rewinds and replay, he simulates that client move since tick 10(past) until tick 12(now)) --> (server sends update, telling this is your position at tick 12) CMIIW --> (???)

-should the server informs that it is currently tick 12? I guess so, the server tells the client "this is your state at (current )tick 12". please CMIIW

-should the client update its tick number so it's 12? or continually update his local tick, but use the informed server tick for interpolation?  anyway, what should the client do now that it knows the server is at tick 12? of course by this time the client tick time would have changed, perhaps below, equal, or above 12.

-what does it mean that player is ahead of server, behind server? I used to hear this a lot in conversations and forums. I don't get it. But I think here's what it means. Please correct me if I am wrong:

-1. client is ahead of server, if he receives update from server telling "this is your state at tick 12", while locally he is at tick 13 (anything > 12)

-2. client is behind server, if he receives update from server telling "this is your state at tick 12", while locally he is at tick 11 (anything < 12)

-3. client is equal to server, if he receives update from server telling "this is yout state at tick 12", while locally he is at tick 12 too.

0

Share on other sites

The ahead/behind server description you talk about would not surprise me. Note that there is no well-defined, single, language used for these things. For example, a client can be said to be "behind server" even when in the case of 2 in your list, and case 3 could "never happen" because the client would jump forward to the received time stamp in that case.

However, one thing that confuses me is your use of the words "is at tick." You cannot know exactly what tick someone "is at." You can only know what their tick number was when they sent a message. For the client and server to keep their tick rates (rate of tick advancement) in sync, it may be useful for the client to attach its current tick number to packets sent to server, and for the server to return two pieces of data: "When I received a packet that you sent when you were at tick A, I was at tick B. When I sent this return packet, I was at tick C." The client can then look at what its tick is when it receives that packet, and calculate (D-A,) subtract (C-B,) and divide by two; that's the estimated one-way transmission latency. You can also use this information to predict what the tick number will be on the server when the packet you send at tick E actually arrives.

How you then put together these pieces, depends on your specific game model. Source is different from Quake is different from Starcraft is different from World of Warcraft is different from ...

1

Share on other sites

It might be better in future to use some other term that 'ticks' which is the same term used for that crude time system used on various operating systems.   Ive never used them ('ticks') except on Sleep() commands and only for very loose code).  I may have even changed the tick rate in one usage.

When I saw the last mention in some post with someone being told to use 'ticks' I automatically though of that, and NOT of the method of using an artificial/arbitrary time system  (Ive used the high performance/precision timers in my networking many times including for in-line profiling performance)

Edited by wodinoneeye
0

Share on other sites

When we say "ticks" on the networking forum, we mean "simulation steps." If you instead think of of ticks as "jiffies," then I can see how that would be confusing :-)

0

Create an account

Register a new account