David Vallner wrote:

> Paul Lutus wrote:
>> 
>> The question is not whether it can be done, the question is why would one
>> want to do it this way. In modern times a program like this is
>> event-driven, not clock-driven, for excellent reasons.
>> 
> 
> If it's a turn-based game, why not?

Responsivity? The fact that the processor would not bother with the process
unless there was a need, and the more need, the more attention. The usual
reasons for event-driven design.

> Besides, the architecture would be 
> similar anyway, you'd just evaluate the player actions in discrete
> ticks, not immediately.

Yep, true. I've always though event-driven made more sense in a case where
there might not be any processing required at a particular time, or
conversely, when there were a lot of players and a lot of attention needed.

In detail, when there are no players, the timer gets the processor's
attention for no reason, but when there are a lot of players, the timer
cycles might begin to overlap, a contingency that must be handled in the
game routine.

Neither of these issues comes up with an event-driven design.

-- 
Paul Lutus
http://www.arachnoid.com