David B. Held
dheld at codelogicconsulting.com
Tue Jun 11 17:16:20 New Zealand Standard Time 2002
From: "Sasha Hart" <Sasha.Hart at directory.reed.edu>
> Odd idea I tried a long time ago to deal with the CPU use issues
> you're dealing with: each time the player's health needs to be
> determined concretely, record the time. The next time it needs to
> be done, take the difference between the current time and the
> saved time to see how many updates "should have" been done;
> multiply it by some small number and add those just before
> returning the new value.
I like the idea of lazy evaluation via interpolation. If I find
that such updates are a problem, I might steal this idea.
> This probably isn't the best idea unless you need A) really
> fine granularity in health and B) no continuous updating.
I suppose you need B if you have the player health always displayed.
But it seems rather unlikely to me that one would need to update
health on every tick, unless you have very low tick granularity in
the first place.
> also if C) time calls don't take ages
In my event system, there is just a tick timer that gets advanced.
I wouldn't bother checking the system clock, since that gets done
often enough already. I'd just check my tick counter, and infer
time that way. Seems fast enough.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev