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

[John Buehler]

Ola Fosheim Grostad writes:
> Derek Licciardi wrote:

>> I have to disagree with this statement.  Components can and do have
>> a use in building MUDS of the future because components bring
>> stability to CHANGING code.  To think components can't work for
>> games undermines the effectiveness of the entire DirectX API.

> Well, some DOS programmers certainly did... ;) I have barely looked
> at DirectX, still I assume that you don't address a single pixel
> through the API, but you work either directly with buffer (thus
> breaking encapsulation) or do things in batch (thus don't really use
> the API and introduce inflexibility, although less apparent in
> rendering).  My perception of DirectX is that it says "This is what
> the hardware looks like, now gimme something close to this in batch
> and I will be reasonably efficient assuming that you don't hit my
> weak spots".  Same thing with OpenGL...

> I don't complain about COM as an interfacing *technology* (although
> I probably would if I wrote Windows programs), I complain about
> component *design* tenants applied to the MUD server core. That is
> to reduce interdependencies to a bare minimum, which is going to
> affect depth and flexibility, I am sure!

Oh, I think I get it now.  There are no component design tenants.  The
size of a component is up to you, and the abstraction distance from
the raw functionality that you are accessing is up to you.  The more
abstract you go, the greater possibility that you have for
substitution by a different component.  The less abstract you go, the
lesser the possibility.  This is a design tradeoff that I'm sure
you're completely familiar with, and components do not hinder you in
any way in continuing to fine-tune design abstraction levels.

> It seems very reasonable to do collision detection as a reusable
> component, and let that component assume responsibility for the
> physical properties of an object.  Still this breakdown might create
> lots of hits on the component interface because there are lots of
> other components that need to look up that information for other
> 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).

> Would I do collision detection in a module, sure, but I probably
> would not wrap it up in an independent facade. I would realize that
> spatial data structures demand in-context design to be efficient and
> flexible.  (I hope)

And you would be creating a component as soon as you construct that
module.  You don't call it a component, but it is.  And you won't be
managing the contracts that relate to it very strictly, and that will
burn you whenever you blink or lose concentration while working with
it.

The first component does general collision detection.  Then when you
only want an area spell that affects level 40 dwarves, you construct a
new contract and a new component.  Fortunately, you have a general
purpose collision detection component that you can use for the lion's
share of the work (through aggregation or delegation, not code reuse).
And you have acknowledged that you created a new contract.  The role
of that contract in your system should have an explicit role in your
system construction - as opposed to just having it be used by other
pieces of software - where they seem to work okay.

>> 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.

How about the part where they are believed to work (with high
confidence) the way the users and the designers intended?

>> array of monitoring and administration tools.  What you may fail to
>> realize is that COM code on windows machines is the closest you
>> will ever get to the kernel, therefore it will more than likely
>> have an advantage with respect to speed over other code.

> I don't know much about COM, and I would not consider writing a MUD
> server under Windows, so if I fail to realize this, it certainly
> does not bother me! ;-))

COM is well worth a look if you ever find some time on your hands.  I
highly recommend "The COM Programmer's Cookbook" by Crispin Goswell,
which can be found at
http://msdn.microsoft.com/library/techart/msdn_com_co.htm

There are a number of books about COM, but they quickly leave the
essentials behind.  Note that COM+ from Microsoft is not really all
that related to COM and should not be considered a resource for
understanding it.

> 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 :).

To obtain an interface requires a call and a simple lookup to retrieve
a pointer.  To make a method call, a pointer dereference and a
procedure call are the overhead.  To the best of my knowledge, it's
the same overhead as C++ (actually COM was required to being
compatible with Microsoft C++).  If you go with fine-grained
components, you can accumulate significant call overhead.  If you go
with coarse-grained components, the call overhead is limited.  Which
is, of course, the same equation as for any pile of code.  Components
technology does not mandate either - although the research team was
focusing on small components for the sake of reliability.  We didn't
know how to build large components in a reasonable amount of time.

>> 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)

A MUD core can be componentized and then upgraded in pieces.  Old
versions of components can be used safely, while newer ones can be
used as desired.  If you want to upgrade to the new version across the
board, you consciously do so.  If the new version implements the old
interface, you're golden.  If it implements new functionality through
a new interface, you have to make code changes at the call sites.  In
any case, it isn't possible to just throw the new version into the
system and have it work until it doesn't.  It won't work or it will.
It either implements the contracts that the rest of the software is
looking for or it doesn't.

Once a component is no longer in use, it can be omitted from the
deliverable.

JB

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