Time/duration handling in strategic game

Question

I'm considering developing a space opera game, having already done some game design. Technically, though, I'm coming from a business applications background. Hence I don't really know how I should handle time and duration.

Let's state the matter clearly: what if something is bound to happen in 5 hours and on which other events depend.

For example the arrival of some space ship in some system where some defense systems are present, hence a fight would start.

Should I use some kind of scheduler (like Quartz in my java land) to trigger the corresponding event when due (I plan to use events for communication)? Something else?

Edit: important side note: the aim is to do some web application, so with multiple nodes for better scalability and the like. Hence a single loop on one node wouldn't do it. Should there be a master node or are they some better known solution ?

Furthermore, the loop in itself doesn't resolve this duration issue: between firing of the event on its ends, many loops happen. Does it mean every loop should check such "waiting" actions?

Answer 1

Most games centre around a 'game step' loop. Things happen in discrete pacels of time.

It is straightforward to have a queue of future events and to consume those events for each game step.

More about game time-steps on the gafferongames blog.

Answer 2

Just record your game time, add it to a variable, once the variable gets to a certain amount, fire your event.

Answer 3

What kind of web application is it?

Is it one that runs all the time, as a continuous process? If so, simply do this with a standard game loop:

while app_still_running:
    check queue of pending events
    while the next pending event is due now:
        execute event
    sleep(some reasonable duration)

You may need to run this in a background thread if the rest of your app is event-driven: if so, be sure to put a lock around the whole event so that everything stays consistent.

Or, is the web app one that only runs when you visit a page? (eg. like a PHP app?) If so, you can have an entry at the top of each page which checks if events are due, and if so, process them at that point before rendering the rest of the page. It's basically the same thing, except done just-in-time instead of periodically.

Either way, the idea is to push events onto a queue and read them off in order. If you just have one process, this can be a queue data structure. If you have multiple processes, it's probably best to have them in a database and use a sorted query to collect them. (Though be careful to ensure multiple processes can't both read the same events.)

There is probably no reason why a single loop on one node isn't good enough for your purposes. You can designate one node as the master for performing all this. Or you can store pending events in the database and just have the various nodes grabbing a handful of events via a transaction. On the whole though your scalability problems will not be at the business logic end.

As far as consistency across nodes is concerned, where one node is processing an event but another is displaying or editing data relevant to that event, that's an issue for database transactions and the like. If you cache anything, you are pretty much throwing away consistency, so you have to make decisions over what can be cached, and what cannot. That starts to get outside the scope of this particular problem however.