Hello,

scenario: Player has 50 of 50 energy. Player does something ( -5 energy ). Player regains 1 energy every 5 minutes. 

Thoughts: I was thinking that it would be a good idea to add a property like

DateTime TimeToUpdateEnergy {get;set;}

when a player does something. So that I can have a background service running an update which does essentialy

update tbl set energy = energy + 1, TimeToUpdateEnergy = dateadd(mi,5,getdate()),getdate() where TimeToUpdateEnergy = GETDATE()

Now thinking about it I might run into multiple problems. If my service fails to update right at that exact second, my client and my server will run out of sync.
Querying the current energy from the client seems kinda hacky, so I am unsure how to handle that situation.

Are there any best practices I should follow?

Thanks!

Standard answer 1: run all game logic on just the server.  The server notifies the client when the game state changes.  Do not trust the client with any game state, ever.

Standard answer 2: run your game logic at a fixed frame rate.  Do all timing in terms of frames.  The server send a "tick" to each client once per frame, and the clients only update the game state when they receive a tick.  It is therefore relatively easy to keep the server and the clients perfectly synchronized.

Either one of these would fix your immediate problem.  Both of them are good ideas.

(And don't ever use datetime objects for game logic.  What if the game is paused?  What if the game state is saved and later restored?  What happens when the time zone changes, such as at the start or end of daylight saving time?  What happens when you get a leap second?)

24 minutes ago, a light breeze said:

Standard answer 1: run all game logic on just the server.  The server notifies the client when the game state changes.  Do not trust the client with any game state, ever.

Standard answer 2: run your game logic at a fixed frame rate.  Do all timing in terms of frames.  The server send a "tick" to each client once per frame, and the clients only update the game state when they receive a tick.  It is therefore relatively easy to keep the server and the clients perfectly synchronized.

 

Obviously I am running the logic on the server. The question kinda gives it away.. The problem is the syncing of the visual part. Let's say the players screen says 160s left until he receives 1 energy. I am unsure how to handle the situation if the server fails to do so in that exact second. A tick would mean once per second? If so every client would have to query the server every second, that sounds kinda bad.. 

24 minutes ago, a light breeze said:

(And don't ever use datetime objects for game logic.  What if the game is paused?  What if the game state is saved and later restored?  What happens when the time zone changes, such as at the start or end of daylight saving time?  What happens when you get a leap second?)

 

There is no pause, there is no saving. Server does not observe DST. Idk what a leap second is.
Either way, what would be an alternative?

1 hour ago, SinnedB said:

Obviously I am running the logic on the server. The question kinda gives it away.. The problem is the syncing of the visual part. Let's say the players screen says 160s left until he receives 1 energy. I am unsure how to handle the situation if the server fails to do so in that exact second.

If the server lags, then the game lags, obviously.  Not much you can do about it, but at least all aspects of the game lag at the same time, so the game stays in sync.

1 hour ago, SinnedB said:

A tick would mean once per second? If so every client would have to query the server every second, that sounds kinda bad..

One tick per frame, so if the server runs 60 fps, then 60 ticks per frame.  You might be able to get away with less than 60 fps, but probably not as low as 1 fps.

Also, the client doesn't query.  The client passes input on to the server and passively waits for the server to tell it what it needs to know.  No need for round-trip communication when a unidirectional stream will do.

1 hour ago, SinnedB said:

Either way, what would be an alternative?

Count frames.  If the server runs at 60 fps, then one second of game time is exactly 60 frames.  If the server lags because it cannot keep you, one second of game time is longer than a second of clock time.  If you're running a stress-test on your server, a second of game time may be shorter than a second of clock time.

The only part of your server that should look at actual physical time is the part that runs the game simulation at a steady fixed fps, and even that part of the server would be better served with a timer that isn't affected by leap seconds.  And any part of the server that runs seasonal events based on real-world dates, I guess.

1 hour ago, a light breeze said:

-snip

I am sorry if I left out an important detail. I am working on an app that isn't running on a game engine with animated sprites and stuff. I guess it's more like a browser game.

Maybe I just can't make much sense of what you are explaining but I still do not know how I would solve my problem..