1
\$\begingroup\$

In the past I've done cooldowns as a specific time in ms, but I was thinking isn't having tick based cooldowns better. This would be more accurate and efficent(not sure).

The bad side I can think about is that if the tick rate is increased, it would affect the game logic. While having a base update rate and a multiplier(that can be applied to everything that is tied to tick rate) would probably fix this, I am not sure if this is a good approach.

\$\endgroup\$
4
  • \$\begingroup\$ If tick based, different frame rates will affect your physics \$\endgroup\$
    – Evorlor
    Jan 25, 2015 at 17:57
  • \$\begingroup\$ Based on the type of game you might not have a choice, games like StarCraft 2 which use a peer-to-peer network architecture I believe must use a tick-based cooldown rate (and a capped frame rate) to avoid desyncing. Do you have a particular kind of game in mind? \$\endgroup\$
    – nwellcome
    Jan 28, 2015 at 17:24
  • \$\begingroup\$ It's an RTS, but client - server also I don't think sc2 is p2p but also client - server \$\endgroup\$
    – luleksde
    Jan 28, 2015 at 17:31
  • \$\begingroup\$ @Ch1pStar You're right, it's routed peer-to-peer where the clients all send player input to the server and the server distributes that information back to the clients. The salient factor is that for performance reasons the server isn't normally communicating game-state information back to the clients, only inputs. That system relies on the clients always doing the same thing given the same input, which gets messy using delta times. I'd love to hear someone with more experience tell me if that's even possible. \$\endgroup\$
    – nwellcome
    Jan 28, 2015 at 19:07

3 Answers 3

1
\$\begingroup\$

If your game logic is going to be tick based you do not change the tick rate.

Fixed tick-based logic update is useful when you need to easily insure game physic & logic is 100% reproducible as delta-time updates will cause different rounding errors depending on the time elapsed.

You can still use delta-times with tick-based updates for calculating the number of ticks for convenience.

And it's possible to mix both even if exact, reproducible game logic is needed: Use delta time for inconsequential things like particles & UI animations so long as they don't affect game logic.

If the need is simply to have a stable replay it's also possible to record the delta times along with the replay data to ensure the physics end up with the same rounding errors.

\$\endgroup\$
1
\$\begingroup\$

It depends on how the rest of your game runs. Either use ticks or time, but choose one and use it everywhere. I prefer using ticks, and setting a max framerate. If the game slows down, so be it. I don't want any quantum tunneling to happen. It's simpler, and i like it. But you could use delta time, and get different framerates with the same game speed. That's up to you to decide. But whatever you do, make the choice once, and use that in your entire game. If you add time based cooldowns in a tick based game and the game runs slow, the cooldowns are suddenly relatively shorter than they're supposed to be, and vice versa.

\$\endgroup\$
0
\$\begingroup\$

Anything that can affect the fundamental outcome of the game in this manner should be based on delta times.

Delta time ensures that the correct amount of actual time is perceived by the game logic, usually delta time is handled in ms.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .