0

In simple 'step based' graphical engines object movement is tied directly into frame rate. This was fine in the 1980's when hardware was identical.

For years now engines have been 'time based' with d=s/t. This means that an object will take the same time to get from A to B no matter what the frame rate or power of the computer.

If everything is time based, how can we perform actions like a characters hit points decreasing by x when being hit by an NPC? A 'hit' may be every 5 seconds.

As far as I can tell this 5 second delay is called a 'heartbeat'. Many MMO's use a heartbeat like this that is global for a lot of actions.

Are 'heartbeats' the best method to use for none linear events in a time based engine?

UPDATE:

Thank you for your verbose response. I will try and clarify if possible. I'm trying to decide which options to use for the MMO Server to internally simulate the world that it controls.

As I understand there are 3 main 'stimuli' into the system that cause objects to change: NOTE, these are internal to the Server only.

  1. Linear integrated operations. These are done inside the game loop. For example NPC movement from A to B.

  2. Client events. These occur at seemingly random times as far as the server is concerned. For example the user clicks fire.

  3. Time based. These occur at heartbeat intervals. For example, check for any idle NPCs and give them something to do.

Step 3 is the one I'm wrestling with and looking for clarification as to if this method is correct. I hope this clarifies what my question is.

tshepang
  • 12,111
  • 21
  • 91
  • 136
John Stock
  • 1,104
  • 2
  • 9
  • 11
  • If your game loop has a producer/consumer model for detecting when to execute a render/physics update, then you could conceivably use the same model for game updates, and game timers. See http://gafferongames.com/game-physics/fix-your-timestep/ for some ideas along these lines... – Merlyn Morgan-Graham Aug 14 '11 at 04:13
  • I'm not sure this addresses what I need. Basically I dont want to even check for HP-- on every game loop as it only comes into play every 5 seconds. So things like this are outside the scope of the normal integration techniques for game loops. I was thinking that I have a 'state check' interrupt that checks for things like this every x ms. This will be a heartbeat (or multiples of ). Does that sound good? – John Stock Aug 15 '11 at 18:33
  • Okay, so your question is "is a heartbeat the correct way to do this?" The answer is "yes". But either your definition of a heart beat is totally off, or there are hierarchical granularities of heart beat implemented in some games (quite possible), or you're way off on the scale. Most real time games need to do global game logic updates way more often than every 5 seconds. Think about this: if you had some function that you were sure was called 5 times a second, how would you implement a 10 second heartbeat on top of it? What could/would you use the smaller heartbeat for? – Merlyn Morgan-Graham Aug 16 '11 at 00:18

1 Answers1

1

The question is a bit difficult as it is currently worded because it is ambiguous. Answers could be related to game loops, network server architecture, network client architecture, game logic etc.

But ignoring all this, I'll try to answer the last question:

Are 'heartbeats' the best method to use for none linear events in a time based engine?

Some form of "heartbeat" is the lowest level way you can implement a time-based system. But I can't tell you it is adequate without knowing the requirements of your particular system or game.

Building the heartbeat

As you said, without being able to rely on the real-time nature of the computer system (exact number of clock cycles per second, exact number of clock cycles each instruction, only your program running, no hardware interrupts, etc), the timing to generate this heartbeat can become significantly more complicated. You also can't rely on system or hardware timers, or "thread sleep" commands to implement a stable heartbeat. See this article on Win32 timing if you believe differently :)

You can check out this popular article for some ideas on how to become a bit more flexible, and get your heartbeat more stable. The article talks about building a time "accumulator", and firing off an update/callback function once enough time has accumulated. It is talking about a game loop triggering physics updates, but ultimately a game heartbeat must stem from the game loop, too.

What to do with the heartbeat

Once you have a stable heartbeat, then implementing game logic on top of it can become tedious. It works fine for a game like Quake 1 to have a "think" function for each object called back every 10ms, but in a larger game with more objects (like an MMO), it would become intractable very quickly.

A higher level mechanism you can build on top of this is a "timer" or "stopwatch" that calls a custom per-timer callback function once it has elapsed, or calls it periodically (e.g. every 5 seconds). This way you can do your time check ("is it 5 seconds yet?") in a generic way, and let your game logic only implement the things it cares about.

Network programming

A networked game like an MMO is going to be more complicated than this. You mentioned MMOs, but didn't mention things like network latency, lossy-ness, client/server sync issues etc. So I won't go into detail here. This is convenient, because answer those questions adequately would probably fill a large article, if not a book.

Merlyn Morgan-Graham
  • 58,163
  • 16
  • 128
  • 183
  • @John: I think we've got a big disconnect in what you're asking and what I'm answering. This is the type of question that a white board would be better for :) – Merlyn Morgan-Graham Aug 16 '11 at 00:23