None linear events in a time based engine

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 objec开发者_StackOverflow社区ts 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.

---

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.