[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[Kwon Ekstrom]

From: "Ola Fosheim Grøstad" <olag at ifi.uio.no>
> Derek Licciardi wrote:

>> on the desktop).  In real world applications, properly coded
>> components can be extremely fast.  As another example, I have yet to

> Depends on what you compare with.

> purposes than collision detection. And worse, what if you later want
> to do an areaspell that only affect level 40 dwarfs? Unfortunately
> that component does not know what a dwarf is, so it will either have
> to return all objects in a specific area (less efficient) or you
> will have to store race/level information in the component (most
> efficient) or you will have to introduce a new dependency (less
> efficient).

This is a very simple problem, in my code, I've written a Library
component, which acts as a DB, I simply pass it a filter object.  The
library then passes each object that passes it's rather lightweight
testing to the filter, which returns true (the object is filtered) or
false (the object passes all examinations)

Is it less efficient?  I'd say the filter adds a level of complexity
to it, but it really is more efficient than trying to write every
possible value that I want to check directly into the search mechanism
(like I see many mud programmers do)

This is more of an OOP approach, but still relevant.

>> In my opinion, MUDS are all about databases and components would
>> make for a great access layer to the database that serves the mud.

> Well, I think MUDs are all about adapting to the users and the new
> ideas of the designers.

Agreed, muds are about adapting to new ideas, at least a good mud is.
But, you must rely on the database to retrieve the data, so it must be
solid enough to handle it.

>> If you code for Windows, you will inevitably run into COM either
>> through DirectX, ADO, or some other service of the operating
>> system.

> I also tend to think that you cannot get anything faster than
> inlined code and algorithms which are designed in-context.  BTW, not
> being able to avoid COM is not a good reason for applying it to all
> your code :).

Windows programming aside, components are a good
thing... really... Lets take a dikumud for example... I wouldn't
exactly say it's component based, nor would anyone on this list, but
exactly how many times is the act statement called????  Why the act
statement?  Well, it's the easiest way to splice together a string
using appropriate names, etc, as a viewer would see it.  Would you
like to write out the entire contents of the act statement at every
location that it's used?  Or perhaps just the parts that you're using?

lets see... ch_printf(viewer, "%s grins evilly", (can_see(viewer, ch)
?  ch->short_desc : "someone")); For a simple example, you can imagine
all the checks that would get left out in the long run using this
approach.

Components work with this principal.  Sure, poorly designed
components, poorly used components, etc, all cause slowdown and bloat.
Small well defined components can limit your need to rewrite code over
and over again.  If you're designing your own components, you can
write specific objects to predict future changes that may occur.
(Such as my filter for libraries)

As with any programming, good planning is the key to efficient code.

>> clean and defined method for controlling that change.  Look no
>> further than DirectX and you will see the benefits of versioning in
>> COM.

> That could explain the bloat..  How many MB, again?  (I don't see
> how this applies to the MUD core though)

I don't see how it applies to MUD core either, but just as a side
note, imagine how long it would take to write games on windows without
these tools?  Why are most games written for windows?  Why are most
programs written for windows?  I, like most people I've met think
Windows is the biggest, best distributed virus out there, but you have
to admit, there's a reason for it's success.  *nix probably handles
networking and server better, and probably always will, but in the
end, with computer advancement, windows still runs with all of it's
excess layers, well enough for most people.

-- Kwon Ekstrom

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