[MUD-Dev] [DGN] [NEWBIE] Suggestions on (OO) Server Design.

[Kwon Ekstrom]

From: "Sean Middleditch" <elanthis at awesomeplay.com>
> On Tue, 2002-04-09 at 13:53, Kwon Ekstrom wrote:

>> There are also a variety of ways I use my OOP model to shortcut
>> what I'd have to do in a procedural level.  There's probably alot
>> of speed advantages I would get if I used c++ instead of java,
>> but there are several benefits to using java.

> Ah, Java.  I can see some of the Java benefits outweighing the
> cost of speed.  My small mind, I tend to only think of C++ and C,
> sorry.  ^,^

> One issue, with regards to a big OO model in the engine, that is
> going to be a pain, that you w/ Java may not have to worry about,
> is memory management, especially when you integrate a scripting
> language.  I'm writing Scriptix specifically for MUDix (a MUD

Memory manage is still a big deal in java as in C/C++ although in a
different form.  Java's GC handles all your memory for you, but you
need to tell it when an object is ready to be picked up by removing
all references to it.

There are a variety of ways to handle this... Token defines how to
handle references, and abstractToken's default implementation
maintains a single reference of the Token.  This object contains a
single reference and an integer (counting the number of times it has
been referenced).

When you're ready for the object to be garbage collected, you remove
it from the global list, and clear the reference.  The default
disposal handling sets a boolean to true.  Most of my Tokens have a
global "disposed" value which gets incremented, and a finalizer
which will decrement it when the object gets picked up by the GC,
the finalizer can push the object back into a pool if there's room,
otherwise it lets the GC finish with it.  Java allows a finalizer to
add a reference to an object preventing it from being completely
destroyed.

As long as you remember to ONLY reference your tokens from the
reference methods, it works well.  A common java performance issue
is from too many temp objects being generated and picked up by the
GC.  By pooling your objects you save alot of that performance.
Also by reusing temp objects instead of simply creating new ones.
Alot of my objects are designed for reuse instead of disposing them.
In addition, when a Creature is killed in the game, it doesn't get
disposed, it gets reset and attached to a timed event which simply
re-inserts it back into the mud when the time comes.

I don't have "area-wide" resets... each reset is set when the state
changes and waits to come back.  It always annoyed me on diku based
muds where you'd kill a mob and it'd repop instantly so you'd kill
it again and it'd repop 15 or so minutes later... because your first
kills was right before the area reset.  There will likely be some
issues from this, but I think its alot more flexible.

-- Kwon J. Ekstrom

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