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

[Derek Licciardi]

> From: Ola Fosheim Grostad
> Bruce wrote:

>> There's also the whole argument in favor of components and those
>> types of systems which were heavily promoted by John Buehler some
>> months ago, and with good reason.

> I view "components" as something invented for business applications
> which tend to deal with rather stable domains or no hard realtime
> requirements or serious interdependency performance issues AND which
> have to deal with a bunch of existing legacy systems and lots of
> bloat and incompetent programmers...

> But for state-of-the-art MUDs... Why put up a concrete wall between
> your modules?  This is not good for a system that is supposed to
> evolve.  By advocating components one just says that one has given
> up finding a good flexible design AND that you know exactly where
> flexibility will be needed.  In a virtual world however,
> dependencies tend to be related to groupings like geographical areas
> and you seldom can say that there will never exist dependencies
> between different types (classes) in the future! On the contrary, to
> have depth (which most MUDs don't have) you want LOTS of relations
> between those types if you can handle it.

> IMHO layers, modularity, invariants, separation of responsibilities,
> refactoring and all that is good, but components-as-advocated
> (specification based, stable, 3rd party replaceable, no need to
> recompile etc) are not!

> Obviously if you are going to implement a MUD design of the 1990's
> then you can get away with the performance penalty and the
> inflexibility which comes with components... However, you can
> achieve the same thing without the performance issues by being
> disciplined about which classes you depend on (like which header
> files you include, which is easy to verify).

> (This is not to say that you cannot implement certain modules as
> components with no penalty, but the core that constitutes the MUD
> cannot be built with components without penalty...)

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.

In a recent web based game that I built for Fuzzy Zoeller Productions,
I was able to build a component that would model the flight of a golf
ball in 3D space given approximately 15 inputs to the equation.  This
component was accessed over the web through a flash application and
provided a seamless method for gameplay.  In our testing, the
component would easily survive 1 billion iterations in a 48 hour
timeframe on a pentium III 700 desktop computer.  When we finally
placed the component onto the Compaq 4 processor 4GB RAM server it was
going to be housed on, you could not see it register on the
performance monitor given the same volume(it registered about 4% CPU
on the desktop).  In real world applications, properly coded
components can be extremely fast.  As another example, I have yet to
bring down ADO during high stress database access using C++ COM
components.

In my opinion, MUDS are all about databases and components would make
for a great access layer to the database that serves the mud.
Components in this fashion would enable access to the data from the
game and the web without having to write multiple APIs.  Components
would allow you to reuse logic as it appears in game, in a complete
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.  If you code for
Windows, you will inevitably run into COM either through DirectX, ADO,
or some other service of the operating system.  Used properly, these
components can reduce your development time and increase the speed of
your MUD considerably.  On the same note, a badly designed COM
component can be dog slow and incur all of the penalties you speak of.
I would caution you to not dismiss components so quickly as they may
prove to be a better tool than you first thought them to be.

Finally as for the dynamics of code, components(COM or CORBA) allow a
clean and defined method for controlling that change.  Look no further
than DirectX and you will see the benefits of versioning in COM.
Change the way something relates, no problem, the old code remains to
service the old structures until you can migrate them safely to the
new ones.  This translates into more uptime and less customer
complaints.

Sincerely
Derek Licciardi

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