A lot of it, I think, depends on the language you're using.  For
example, a lot of the infrastructure I wrote would be superflous
in one of the higher-level languages that has, eg, garbage collection
and serialization support.  But I'm doing the roguelike in plain C
just because I like the sheer low-level hardcore-ness of it, and in
a low-level language, you have to plan ahead for even things as
"simple" as memory management and serialization.

So as I've learned to write C (as opposed to Lisp or Scheme,
which I use at work) I've learned some disciplines for not getting
into memory-management trouble.  The most important is: Never
have more than one persistent copy (that is, one that crosses
routine boundaries, whether as an argument or a function return,
or one that gets stored in a dynamically allocated structure)
of a pointer at a dynamically allocated object. If you think
you need another pointer at something, or if you think you need
to pass a pointer at something more than once, then what you
need to do is wrap that type of thing in a managing structure
keyed by integer and then store or pass around the integers
that you can provide as keys to the managing structure. C has
lots of syntax for using pointers directly, and lots of
infrastructure for, say, string handling, that assumes you're
not doing this.  Use it with restraint if at all.  Duplicate
what you need, ignore what you don't, and don't pass pointers
around if you can help it.

This solves most of the memory management problem: it prevents
things from being leaked, gives you a chance to do things like
bounds checking and null checking away from the "pointer" use
site, and if you can tell when something in the structure is
stale or useless, it allows you to periodically traverse the
structure reaping them (and of course, implementing such
structures reminds me OFTEN of Greenspun's Tenth Law).

It also solves most of the serialization problems:  You can
serialize your manager structures in a straightforward way
giving just keys and data, and then use the key integers
anywhere else in serialization where you need to refer to
dynamically allocated objects.  No naked pointers means no need
to figure out how to store them at save-game time or reconstruct
them at read-saved-game time.

Realizing the importance of this one technique is enough to
prompt a rewrite - or at least it was for me.  The reason I
didn't know enough to do it in the first place is I was used
to writing in Lispy languages and I had to beat my head
against these "simple" problems for a while before I figured
out the shape of them and how to handle them.

I can flush my memory manager to disk and back and have full state...
its very nice. the hardest part is making EVERYTHING play with it.
ie: linked list code libraries etc...

makes life so much easier. 180 odd lines of code. niiice.

Let's start by defining some vocabulary.

"Wall" time or "Player" time - this is time as seen from the player's
POV, and determines, for example, whether your game is a lunch break
game (half-hour) or a weekend game (20 hours) or an obsession-level
quest (80 hours and up).  Wall time is important in balancing the game,
in that if you realize the players are spending half their time dealing
with something that's supposed to be one-tenth of the game you need to
rebalance a little.

"Game" time - this is absolute time as seen from the character's
perspective.  Seconds, minutes, and hours pass in the dungeon and
game time keeps their count.  Lots of people call these "turns" but
I'm going to try not to because that confuses them with Beat time.

"Character" time or "Beat" time is time as measured in your
character's opportunities to act.  Fast characters may get ten
beats in a minute of game time while slow ones get six.  Lots of
people call these "turns," but I'm going to try not to because that
confuses them with game time.

If your game's time flow is uncompromising, the game clock, the
character speeds, the amounts of "beats" different actions take,
etc, are not integers. They are the outcome of equations that may
have near-arbitrary real results, and counted-move strategies are
nearly useless and would probably require guru meditations on the
source code to develop and execute.  Characters can be sped up or
slowed down arbitrarily, and their actions will be rescheduled
according to their new speed from the moment they were sped or
slowed, not from their next turn or their last.

What I have is an "uncompromising" time flow.  Here's how it's
implemented.

Anything that changes anything in the modeled world is an 'event':
a serializable structure that can be executed.  (Yes, function
pointers are involved.  One of the fields of an event is an index
into a big array of function pointers).  Events can be "chained,"
and some events modify the ones chained behind them.  For example,
a "fireball" spell is  implemented as, spell-cast event, linked
to ball-effect event, linked to fire damage on a square event.
The spellcast event takes time and mana and does not execute the
chained following effect if it fails. The "ball effect" applies
the chained following effect to a wide area.  The "fire damage on
a square" event applies fire damage to all actors in a square.

There's a classic-computer-science structure called a Priority Queue
(search on "Priority Queue" if you want the implementation details).
It's for keeping things ordered (or partially-ordered) by their
priority, while minimizing the CPU required to add something, get
the first thing, reschedule something, or delete something.

My Game time is implemented as 'events' kept in a priority queue,
and the "priorities" of the events are the game times at which
the events are supposed to happen.  I take the first event off
the priority queue, execute it, and delete it. Usually executing
it results in putting another event a lot like it back on the
queue, simulating "recurring" or "duration" effects, and in that
case I reuse the space to store the new event. Some of these
events are effects with duration or delay that are attached to
Game Time, (like the time for smoke to clear or wooden doors to
burn or water to drain) and others represent actors. These "actor
effects" are indexed by the game time of the current first event
in the actors' own 'beat time' priority queues.

Each actor also has a priority queue of 'events' (in fact the code
is reused).  But these events are stored according to 'beat time'
rather than 'game time.'  This includes the 'event' which is the
character's opportunity to take an action, as well as events with
duration or delay measured in the beat time of the actor, such as
taking poison damage, healing, recovering mana, skill timeouts,
etc. When an actor's event comes up in the gametime queue, I
use the interval between his current and next actions in beat time,
plus the actor's speed, to calculate the game time of the next
actor event for that actor.  So the gametime queue never contains
more than one actor event per actor, but the actor keeps getting
new actor events scheduled as long as his 'beat time' queue isn't
empty (it gets empty when he dies, basically).

Executing an actor event means, go to the actor, get the first
event off his beat-time queue, execute that action remembering
its beat-time, put its recurrence if any back into the beat-time
queue, then subtract the just-executed beat-time from the new
'next' beat-time.  Divide by the actor's speed, add the current
game-time (ie, the game time of the current actor-event) to
find the game-time of the next actor event for this actor, take
the current actor event off the gametime queue, and put a new
actor event back into the gametime queue.

Because the Gametime priority queue contains events that have
reference to the actors, and the actors know their own events'
locations in the Gametime priority queue, I can slow or speed
a particular actor at any moment.  I change his speed. His
"beat time" priority queue remains unaffected.  The game time
for his 'actor' event is adjusted so that the interval between
the current moment (the event which is slowing or speeding him)
and the moment of his next movement is halved or doubled. And
then I use the actor's knowledge of its own event's location in
the gametime queue to "fix" the gametime queue after rescheduling
the event.

This means there's a multitude of crap that I don't have to
worry about slowing down or speeding up when an actor slows
down or speeds up; it happens automatically. When his speed
changes, the rate at which his beat time passes relative to
game time changes.  This means nothing measured in that beat
time has to be adjusted at all; it slows down or speeds up
with him.

Oh... there's also some special code to handle petrifaction
without dividing by zero.  But that's in the column of minor
details.

--
Radomir `The Sheep' Dopieralski

You can record this whenever the actor chooses such an action,
and clear it whenever an interruptible action is executed or
aborted.

It also requires two new event types:  An 'interrupt' event, and
an 'abort?' event.

If you have that, you can just chain 'interrupt' events to
events like attacks that interrupt interruptible actions.  And
an 'interrupt' event, when executed off the game queue, would
look at the actor record being interrupted, see if there's an
interruptible action going on for that actor, and if there is,
drop an 'abort?' event into the actor's beat-time queue with
the actor's current beat time.  (which you'll probably have
to calculate from gametime since it's someone else's action).
This immediate event will cause the 'actor' event to be
rescheduled, moving it to the head of the gametime queue.

When you execute the 'abort' action, you give the actor the
opportunity to abort the current interruptible action and start
some different action instead. If the actor chooses to abort,
you delete the interruptible action from the beat-time queue
(this is what requires the actor record to know the index of
of the interruptible action) and put whatever action the actor
chooses into his beat-time queue.

If I do this, I'll probably create a 'hard-interrupt' action
too - this would be similar except that instead of an 'abort?'
event it would drop a 'your-action-has-been-aborted' (or
'action-failed') event into the beat-time record of the
affected actor.