Mainloop document How should the main loop of the system work? There are many kinds of things we want to happen periodically, including at least the following: letting the player take an action letting nonplayers take an action letting items recharge spawning new monsters natural events? status changes (e.g. hunger increasing, effects running out, status cures, etc) None of these should happen during every single loop. Allowing players and nonplayers different speeds implies this.. Also, not all actions by the player should take the same amount of time. Events need to be able to schedule other events, possibly another instance of themselves (e.g. hunger status checks), possibly something else (e.g. the negation of temporary status changes, poison removal checks/damage, etc). There are many possible ways to handle this, but perl's notion of a stack may be the most efficient, as we can do sequential access as well as pop/push access. We thus have the following structure: $event[140][0] = \&respawn_creatures(); It's an array of arrays of references to functions, the first index being the time offset in the future, the second index being just a method to handle more than one event happening in the same segment, and the reference being what's called at that time. I believe it's safe to parameterize the reference, but will need to check on that. It seems that one obvious way to handle time's passage is to do while(1) { \@now = shift($event); while($#now > -1) { $cur_event = pop(@now); # I hope this preserves the reference do($cur_event); } } We may want to work on this code, however, as we know that: The majority of iterations will be empty iterations In theory, it should be possible to design this so that no empty events are even visited I'm not sure if this code actually handles empty events properly (that is, timeframes where nothing happens) We could do it as a sorted linked list, but that would make insertion uglier. It's not currently clear to me which approach is better. This approach has O(1) insertion time but must traverse at least briefly every granule of time. The linked list idea has O(log N) insertion time (I think), is considerably uglier to code, but never visits empty granules. An alternative and better approach would be to find a way to have perl do a 'sparse-aware' version of shift, which would also make it much easier to store events in a savefile. It may also be possible to do this with &tie(), although it'd be best to avoid things like that if possible. Oh, an additional note -- we need a way to associate events to things that might be removed so that all the related events also disappear. The most obvious reason for this is to allow area-specific effects.