[MUD-Dev] Text Parsing

[Adam Wiggins]

On Wed, 9 Jun 1999, Matthew Mihaly wrote:
> Machine has k6 400 processor, w/128 megs RAM. The server is written in C,
> I believe, but I didn't write the server (I may not have an exact
> understanding of what constitutes the server, but what I mean by it is the
> thing that handles the low-level connection stuff). 

You need more RAM.

> Yeah, I profiled it all. Mob ai is taking up about 20% of processor time,
> and player movement is quite slow, taking up to .07 seconds when malloc is
> low (our server has an irritating little memory leak, which we're working
> to fix). 

Well, obviously you need to fix that, but in the meantime, give yourself
some breathing room with more memory.  I've got 300 megs in my home machine
now just because it's so damn cheap.  128m DIMMs are selling for about $100
at the store near my house; at that price, get two or three.

Don't have the cash?  Arctic was having serious memory problems, and they ran
a T-Shirt drive to raise money.  I think they charged $20 for the shirts, which
they acknowledge as "well more than they were worth", but the idea was that
you were contributing to the improvement of the game.

They made so much money from it that they bought an entire new machine with
(I believe) 512 or 1024 megs of RAM.  The MUD runs *much* nicer now, no delays
at all, even at its peak of ~250 players online at once.

> Currently, mob AI is broken up into three main tasks. One handles mobiles
> that randomly wander about (quite a few of those. Butterflies to net and
> the like). One handles mobiles that are involved in a fight. The final one
> handles everything else (healing, gathering items, etc). 
> So really, at most, that accounts for, on the high end, say, 35% of
> processor time. The other 65% seems to be reasonably well-distributed
> among everything else.

One thing I found, given the task of optimizing a diku clone years ago to run
more smoothly on a Sparc 10 (not real speedy and only 128M of RAM) was that
there were a lot of simple assumptions that were never accounted for.

For example, the first thing I did was add a room field num_pcs_in_room.
This number started at 0, was incremented when a player entered the room,
and decremented when they left.

Then at the top of act(), which is the routine which get called to turn the
markup language into text that everyone in the room can see, I simply checked
to see if num_pcs_in_room was greater than zero.  If not, I just returned without
doing any processing.  This made quite a difference; up until then it had been
constructing the "You leave north" and "A hobbit arrives from the south" strings
every time a mobile moved, whether a PC was present or not.

I also staggered the way that things happened; at the time, most all of the game
updating happened on the "tick" mark (every 60 seconds), which caused a slowdown
right then.  I made an "object tick", a "character tick", and so forth.
By the same token, mobiles, which previous updated every 3 seconds (all of them),
I changed to update every second.  However, not *all* of them would update, only
about 1/3rd.  I'd just save the linked list pointer until the next second, and
pick up where I left off.  When it got to the end it would loop around again.

Finally, I took the mobile code and made it so that they stored a lot more information
about their current state, rather than recomputing it every pulse.  As a result,
their update was often reduced to just looking at their current task and deciding
that they wanted to keep doing it, rather than, say, recomputing a path to their
target every update.

Finally, hardware is cheap.  If you'd rather spend your time improving the gameplay
rather than optimizing (I know I would), and you have the cash, I'd shell out for
something more powerful, probably SMP.  Go for dual Celerons, or dual PII/PIII's
if you can afford it.  (Personally, I'm waiting for my dual K7-800's, although
I guess I shouldn't hold my breath on that one.)

Adam W.




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev