Game Server - Timers

1

What the rational behind using timers on the game server (for timing mob behaviors, players temporary buffs and ect’), when you can simply use the game loop tick and call some version of update() method? (like monogame does on the client side)

*Assuming the game simulation is single-threaded.

Thanks.

2

Probably to prevent cheating. If the Server controls everything, it’s a lot more challenging for someone to cheat. If I have access to the timer, it might be easier to cheat.

3

Yes, I would say cheating and synchronization.

  • If timers, health, money, or anything is done on the client side, then the player could go into the game’s memory and change the values. There’s actually some impressive software to make this quite easy, like Cheat Engine.
  • If you have a multiplayer game, it would be more difficult to synchronize the game for different players if things are stored in the game client. Spawn timers need to complete at the same time so all players see the enemy appear at the same time. Temporary buffs need to have a central source of truth so they expire at the same time. You don’t want one player thinking the invincibility buff expired when another is upset because he thought he would still be invincible for another half second. And that’s easier to control when there’s a central system controlling when the timers complete rather than waiting for your computer to ask mine if I’m invincible, where the information you receive is now ~100ms old.
4

I think I wasn’t clear, so I will try clarify my question:

When I said using the “game loop”, I meant the “game loop” inside the server.
I asked this question, because I understood some people prefer to use Timer objects in async way to time game actors events, instead of simply use the “game loop” clock and update the world events accordingly.

Sorry if I wasn’t clear :slight_smile:

5

Ah I see. I was confused by the wording “like monogame does on the client side.”

Timers can be more convenient because you have an encapsulated object that’s counting on its own, with the ability to easily start and stop them. Usage is nice because when the timer completes, it will call your event function that has been preconfigured, so you don’t constantly need to check if it’s done.

If you need complex timers that don’t work with that standard behavior, then you can run your own in the game loop. But any standard timer (e.g. saving a completion time, comparing the current time to see if it’s done, calling a function) is basically recreating that small amount of logic that’s already done for you. Of course if you use a ton of timers, this might be preferable for garbage reasons.

Another cool thing to try if you need some customization is Task.Delay. It uses a timer internally (see the source), but instead of configuring the event function at the start, you can pass around your task and let different services check IsCompleted within their update loops.

6

@jnoyola
Thank you very much for your answer!
The Task.Delay sounds cool, I will check if it allocates memory internally that I can’t pool - I try to avoid memory allocations that aren’t reusable.

7

I worked for a company that wrote software for highspeed real time systems (C# services interacting with PLC’s) for both aironautiical systems and the nuclear powre industry, and they moved to using the new Task.Delay mechanism, they found (and I have no evidence to support this) it resluted in bottle necks when compared to old school threading and returned to the older threading model.

Not saying don’t use it, just that it came up on a job I was on and that’s what I was told. I imagine for 99.9% of applications it’s fine, just not in the case of that company.