[MUD-Dev] Ticks?

[John Buehler]

David B. Held writes:
> 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.

Displays are performed by the client, which can have the same rules
of interpolation that the server is using.  All you're trying to do
here is leave the value of the character's health on the server in a
calculable form, but not calculated, and only for the purpose of
saving CPU cycles.  As a result, the client can update as much as it
likes, using the same interpolation rules that the server will use
when the time comes.  This means that the client doesn't even use
ticks.  And in truth, neither does the server.  It's all uniform.
So the client displays a smooth updating to the display every frame
and the server infers a smooth update which will accurately reflect
the client's interpolation.  When the server actually performs an
update, the client could be notified in order to make sure that they
are lockstep.  But that's probably another area that you want to
defer, aggregate or somehow optimize for the problems inherent in
it.

>> 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.

Try a system service that works at a very low level, such as elapsed
clock cycles.  That avoids the formatting and conversion that the
time of day calls and such perform.  You only need to know that some
thousands of clocks have passed (letting you infer elapsed real
time), not that it's Wednesday, or Eastern Standard Time.  Make
those calls once per loop, or once per 100 loops, with math to
determine the current time between actual system calls.  It all
depends on the characteristics (e.g. uniformity) of your processing
loops as to what types of mathematical games you can play.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev