[MUD-Dev] Re: MUD Development Digest

[Justin McKinnerney]

> -----Original Message-----
> From: Petidomo List Agent,,,, [mailto:petidomo at kanga.nu]On Behalf Of Dr.
> Cat
> Sent: Friday, April 24, 1998 6:31 PM
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] Re: MUD Development Digest
>
> [stuff deleted]
>
>> As a rule of thumb, on pretty much ANY O/S, you really don't want to have
>> more than 1/3 your memory be in swap.
>
> We are in agreement here, but I'd go farther and say zero percent is what
> I really want.  As J. C. pointed out, I may have to look around for a
> Unix that doesn't assume things should be swapped out even when there's a
> surplus of RAM - or at least one that can be tweaked to act that way.

You could always run without swap under Linux and (I believe) Solaris.

While this raises a lot of red flags - if you are the only person running on
the system, and you are pretty sure that the only real process on the system
is your game server (no sendmail, no ftp, etc), then go for it.

Swap was always meant to prevent the system from going down due to physical
memory running out and meant as a convineance to agument the price of memory
(which isn't so much an issue as it used to be). It was obviously never
intended as a source pool for physical memory as this is not what the
hardware was intended for. :)

> If I had any interest in setting up a game with thousands of simultaneous
> users that generated no revenue, I'm sure I'd rush right out and study up
> on all the latest data structures and memory management techniques.  For
> now I'll stay mostly with my old friend the array.  Kinda like I used in
> BASIC in 1978, only with more datatypes available.  :X)  They're not
> elegant and beautiful and graceful like triple-sideways-linked-lists of
> handles to structures...  But like an old reliable car, or an old
> reliable horse, they get the job done.  We've got about 400,000 player
> hours logged on our server now so far, and it's rolling along pretty
> smoothly most of the time.

Everything is relative to scope.

It is very easy to start a project with your mentality, and then deal with
issues as you run into them. This approach is not uncommon when it comes to
multi-user games in general.

However, to start a project and say "I want >this< to be possible" is to set
your limits. If you plan on supporting up to 100,000 players, do the math,
figure out what your game would be like if that happened, figure out every
worst case scenario. Then ask yourself if your code is truly up to it.

Yes, you can rely on technology advancing to a certain extent - but the game
that handles 100,000 players on current technology elegantly will most
certainly do so in the future. No one ever got bitten for having a game that
ran smoothly on a LOWER platform than one would expect.

----

As I progress my own (extremely slow-going) game, I find myself following a
similar development path as Java. Though my goals are disctinctively
diffrent (My bytecode is not intended to be portable), several concepts
inherit to modular coding seem to be popping up as cominalities between Java
and my own bytecode.

Bytecode could easily be dubbed a "fancy" proceedure. Why do it? Simply
put - Extendability. I want to be able to change fundamental game concepts
in areas as I wish, on the fly, and without rebooting the game.

Many MU*s currently do this. But most of them do it via realtime
interpreters. While this isn't a major CPU load, per-se, it does take up
data space in the processor cache, so you're pretty much guarenteed more
cache misses than if using bytecode for the same proceedure. (And, of
course, the natural cycle savings on not having to parse every time
something is executed).

So, in the end, my point would be that all "fancy" coding is directly
related to your goals. And if you intended to be a comertial server, once
you are out of beta you are not allowed the luxury of making so many major
code changes. So the best solution would be adaptable code.

> P.S.  The real trick is figuring out what parts would contribute the most
> towards "making the game fun", and then *only* implementing those parts.
> If you take any other approach, odds are good you'll never get your game
> done - indeed, most people that try to make a game never do get one done.

I totally agree.

Game design is very, very important. Far more important than implementation.

However, you can take for granted certain hurtles in implmentation.

Case: I want a server that is capable of running under Linux.

Problem: Linux inheritly has a hard limit of 256 file handles per-process,
and I do not want to hack the kernel (even though it's just chaning one
#define it's still bad idea in general) on every machine I have a server
running on.

Granted: I need code to get around the 256 limit.

That case is a physical limit problem. There are other effency problems that
are generally a good idea to work around at first and would not hurt you in
the end to have worked around.

In a few cases, this includes having the ability to adjust a server to
whatever technology it uses (such as the memory/swap issue - having an
adjustable memory cache with a "fancy" caching algorithm).

These problems can be mutually exclusive of the game design itself (256
limit), or while they can be mutually exclusive (dbase solution to
memory/swap), it may actualy be better for such things to revolve around
game specific information which can only be supplied by the design (specific
caching implmentation will always be FAR more efficent than a general DBM or
ODBMS).

If you possess the ability/time/resources to, it never hurts to shoot for a
goal that is beoynd what you think will actually happen. Because if it does
happen, everyone involved will be happy you did, and guarenteed, someone
will be unhappy that you didn't make your goals *higher*! :)

	- Justin -


--
MUD-Dev: Advancing an unrealised future.