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

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

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!

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

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)

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

> Components in this fashion would enable access to the data from the
> game and the web without having to write multiple APIs.

Uhm?

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

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

Yes probably, but I think there is a major difference between
component-design and component-technology.  Just like there is a big
difference between OOA/OOD and OOP!

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

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

--
Ola  -  http://www.notam.uio.no/~olagr/


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