[MUD-Dev] RE: Request to mailing list MUD-Dev rejected

[David Loeser]

<EdNote: Accidentally rejected by Moderator.  Now posted, sadly
minus References: and In-Reply-To: headers>

> Ola Fosheim Grøstad wrote:
>> Derek Licciardi wrote:

<SNIP>

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

Wrong. Look on the shelves of any retail store that sells computer
entertainment titles for Windows and you'll discover that all of
these titles require DirectX. No serious developer of entertainment
titles for the PC/Windows can afford not to utilize this technology,
for several obvious reasons. Even amateur game developers use
DirectX (Ask me if this is a good thing or a bad thing, or read
further).

> 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

This is true but what is the point that your trying to make? As for
breaking encapsulation, most developers have wrapped their own code
around all (or some) of the DirectX components.  For example I have
encapsulated the buffer manipulation pixel plotting functionality in
several overloaded functions. I also have HLines, VLines and
ClippedLine code included. My GUI code inherits from this DirectDraw
class and makes use of most of these functions. Very nice if I do
say so myself. That is part of the beauty of C++ (or any OOP
language) if something isn't encapsulated you can change it to be
so.

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

What are both of you saying? Muds aren't all about databases and I
don't think MUDS are about adapting to the users. The technology
behind the mud should allow for flexibility. Flexibility to drop
components in and replace them as needed.  On the front end a MUD
should be entertaining and fun. Fun above all else. I don't care if
the MUD was written in Fortran and uses flat files for storage... it
just needs to be fun. Derek, we can discuss this over lunch :)

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

I agree that COM should not be used in all of your code - but, COM
does have several advantages over dynamic link libraries. Derek
mentions versioning below.  Some benefits of COM are it's ease of
replacement (Hence Component). On MUDS being able to replace a
component without recompiling the entire application is a plus. COM
also makes reusability possible... write a component to handle user
logins and you can use it on every MUD that you ever write. Or if
you have two muds using the login component and you discover a bug
in the code - recompile the component and update it... the two MUDs
are none the wiser.

Of course there are drawbacks to COM. The biggest is the simple fact
that old interfaces can never be eliminated, they must remain in
subsequent versions. That leads to versioning. Versioning in COM was
suppose to fix DLL hell... it did not. Lastly COM interfaces need to
be planned. The two reasons listed above make it evident that COM
should not be a shoot from the hip effort. Careful considerations
need to be made to prevent too many versions of the components
interfaces from "living"

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

OK, finally a point that I will agree with you on, Ola :) I dream of
the days when I wrote 6502 assembly and squeezed every bit out of
64K.  Unfortunately, the folks at Microsoft have forced Windows
programmers to follow them down every dead end and narrow alley (can
you say Hungarian Notation) just when you were beginning to like
COM, DCOM or COM+ .... they have a new newer paradigm for us to
accept. I'm an old Amigan... and sometimes I cry when I think what
could have been :(

As for using the Component Object Model for components within MUDs,
I think that the benefits far outweigh the drawbacks as long as you
design the interfaces up front. The nice thing about COM is that it
is a binary compatible software component which many languages can
communicate with.  Write your components in C++ and link up to them
with Perl or VB or hmmmm Python?


David "Dak Lozar" Loeser

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