[Home] [Groups] - Message: [Prev in Group] [Next in Group]
22762: Re: [MUD-Dev] Ticks?
[Full Header] [Plain Text]
From: shren <shren@io.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Tue, 11 Jun 2002 06:09:53 -0500 (CDT)
References: [1]
Organization: Kanga.Nu
On Fri, 7 Jun 2002, Kwon Ekstrom wrote:
> From: "Anderson, David" <david.anderson@tfp.com>
>> What have other people done for regenning? I'm just doing my
>> best to have it make a bit more sense.
> I'd also recommend not allowing regeneration for mobs/players that
> are currently fighting.
Of course, if you're compulsively going for speed, and are doing
things in C or C++, you can always stick everything that regenerates
on a tick in the same memory block, in two parts - the rate and the
current level. Then the tick thread can live in that memory block
and not even look at the whole player.
struct player
{
...
struct hp *x;
}
struct hp
{
char rate;
int level;
}
So using the above puesdocode, you'd make a big block of hp structs,
and each player or monster would have a pointer pointing to one.
This should optimize the most common hp operation, the tick:
once a second:
struct hp *y = the hp memory block
for i = 1 to numofhpblocks
{
y->level=y->level+y->rate;
y=y+(sizeof(struct hp));
}
Actually checking the amount of hp would probably involve shared
memory, but it is the less common operation. I've thought about
doing random numbers with a similar method - a big block of memory
that's sequentially read to get random numbers, and is randomly
rewritten during idle cycles.
It's probably not the best way, but something about this particular
inelegance I find elegant. I wonder if it would help speed, and by
how much, and how much of a pain in the arse it would be to code.
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev