[MUD-Dev] Collecting ideas for a MUD server... (fwd)

[Rahul Sinha]

On Wed, 22 Dec 1999, Justin Rogers wrote:

> [Rahul Sinha]
> 
> > ActiveX???
> > most muds run on Unix, with good reason, stay FAR away from activeX,
> > unless you think your mud shoudl run on a server with the GUI in
> > kernelspace...
>     Most MUDs is right.   But you are creating a new mud.  So why are you
> worried about what most MUDs do.  You should be worried about what your
> MUD will do.  I've already programmed a MUD using all of the theories
> and items I have described.

granted, using something for history's sake is bad.  BUT, one _should_
stop and consider why other muds do what they do.

Most muds have one monolithic code base. this is bad, the LPC
driver-mudlib split makes more sense.  Why are they that way? the Diku
heritage. (this is an example of history being wrong)

I won't give a counter-example, as (my fault) OS wars do not belong here.
But I shall say this.  I have a Win2k rc2 box sitting next to me in
addition to my linux box.  It is NOT as stable, but the issue is
performance for this sort of stuff.  If you want details on why I believe
this, email me off-list.

>     Its not embedded into a web page.  Your obviously a UNIX guy.  ActiveX
> isn't for web pages.  COM is coming into existence on UNIX now.  And that
> is what ActiveX is all about, COM components.  My mud will run on any COM
> complient operating system or any OS that has COM extensions.  Also, the
> server has multiple output/input plugins.  I can have ten different types of
> clients viewing my world in ten different ways based on the port they connect
> to.  For instance.  Vampires can see at night, so their gamma is higher.  Bug
> based
> creatures see into the infrared and I jack the red level up on the levels as a
> result.  But you can also connect to the mud through the standard text port.  So
> I'm not locked, because I'm modular =-)

okay, why not just implement the entire gamma/color correction thing
client side, and sent simple commands to change them when appropriate?

My point is not that you cannot do foo with activeX/COM, but that there
are faster ways to do this, usually by looking at the problem and working
backwards, instead of choosing a technology and seeing what can be done
with it.

>     Each user has his own thread that he runs in.  Works for up to about 20
> users.  I modified this later though.  Each area runs in its own thread, and
bravo, good choice
> large groups of NPCs have their own threads.  All in all about 50 threads
I split this off into a seperate binary, no need for npcs to be treated
differnetly than pcs, they can operate in the same thread. the
ncp-specific work being done in the other binary, as the main mud does not
need to include this code (not to mention, this allows for different
development cycles for the two, unrelated, projects

> > ummm a peer-to-peer setup is not safe for any centralized game... Justin,
> > have you actually implemented this? If so, you are begging for some player
> > to remember that he can hexedit his character...
> 
>     No not at all.  It isn't quite like that.  I do keep a global player up.
> But
> they are still playing the game.  Users transfer their information around to
> others as they are playing.  So if you log into the system and your user profile
> doesn't match the user profile that everyone else has of you then you get
> kicked.

JCL's man in the middle point is brilliant, I was more thinking that this
is unnecissary.  Why not just have a single server, that keeps all data?

this reduces net traffic, and HD space is cheap.

> 
>     I implemented this because people can create their own worlds offline and
> when
> they start each becomes a shard.  And two players with mutual agreeance can
> create
> links between their worlds and thus users can navigate over player created
> terrains.

so distribute the server binaries, and code in a easy way to link servers.

> 
> > and if you are streaming DirectPLay, how is this peer-to-peer? (iow you
> > NEED a client-server setup)
>     These are multiple instances.  Like I said, I programmed a core that loads
> the
> plugins, and now I have nearly 300 plugins that I've created and as such can at
> any
> time spawn around 80 different games that I've made each with different storage
> locations, commands, input mechanisms, output formats etc...

but dlopen()able .sos (or .dlls for the winfolks) ahve this same property.

Your way may work.  I just feel that for the new project that spawned this
thread, there are faster ways (in programming time) that also leave one
with a faster, lighter, more portable result.

and COM objects are not inherently cross-platform, unless they have been
abstracted to the level of Java byte-code (where performace begins to
matter)  If nothing else, endianness issues exist.

(iow do you interpret COM objects, or execute them... if there is no
interpretaiton layer, even if they are akin to what I know about the older
OLE objects, they are not cross-platform.  If there is an interp layer,
this is another Java, why not go with the already-implemented standard,
instead of a vaporware one?


	Rahul Sinha
Computer Science/ Government,
University Of Maryland College Park
AIM: qui dire	ICQ: 9738191	(301)935-5542





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