[DGD] Re: Kernel library

[Frank Schmidt]

I have too low system response to answer more briefly.

But let me explain: I see the world from an LP-programmers view. When
creating LP muds (or any text mud), the programming techniques does not
have to be perfect. In fact, forcing wizards to type "inherit class A" and
"inherit class B", each time they have need for a little function, will
make them very frustrated. As a wizard myself, I have many times over seen
the big advantage (in productivity and simplicity) of not having to
#include and inherit a dozen files just to make an object. That's one of
the things that have attracted me to code more in LPC rather than C++.
Simplicity with regards for the actual users (you know, that dude you just
taught LPC ;). It is an advantage for a beginner, and for
high-productivity experts. (Damn, response time of 10 seconds for each
keystroke!) 

Also, the inherit system with class libraries is confusing: Let's say you
have a StringClass library inherited by A. Then A is inherited by B. And
then B gets the StringClass library for "free". In other words: The
StringClass library _should_ have been inherited privately to A, since it
is only meant to be used internally in A. And if you implement
private/protected inheritance, explain _that_ to the newbie wizard. ;)

Think of the REAL users of the system (not just the admins with advanced
programming skills, but little productivity). There are the players; who
just doesn't care _how_ the game is programmed as long as it's fun to
play. Then there are the creators; who just want to see their fantasies
come true and the players to play through them. 

You can make as much advanced programming environment as you like, but is
it elegant to program in? Or does it require "HUGE" know-how and lots of
extra code to specify this-and-that, programming language specific things
that really has no impact on the end result, just takes longer time and
more frustration to code. "And the OO design is beautiful." Who cares; in
the MUD community?

Okay, let's say you gather together a bunch of high-tech programmers who
wants to create a MUD. They _want_ OO design, they want private,
protected, encapsulation, inheritance, polymorphism, public, virtual,
members, classes and friends. At the year 2030 they'll still be making the
library modules. Maybe, of course, they could be finished by then, but
would the mud-game be directed towards gameplay or fancy programcode?
How big would the mud be?

I know I'm being maybe a bit too realistic. I know there are better ways
to program. I know how fun it is to program something that is
elegant. However, concerning games, I believe the computer
should be doing most of the work, instead of the programmer. Or at least,
as much work from the creators' sides put into the _realisation_ of their
goals.

(This is my point of view with a tea-spoon, sorry for lengthy note. You
are entitled to have quite a different point of view. I'll respect yours 
as long as you respect mine.)


Felix:
The kernel library is fine, you have spent alot of good work into it. It
is the general usefulness (in practice) I am questioning. The main point
go like this: If I am to make a mudlib, I'd want the full control of
access, users, driver object, auto object etc, etc. If a kernel library
can give me this, fine, but I haven't seen such a lib yet. There are so
many ways to build things, and the kernel only supports one way. So
a mudlib that "want" its own system/dialect would need to create its own
kernel (or core) lib on top of DGD. I'm afraid this is the way things are,
no matter how good kernel one can come up with.

You say UO fits on top of the kernel lib, I bet it does. Probably because
the UO kernel is designed very much alike the kernel. But this is in big
terms, then _everything_ multiuser can fit ontop of the kernel. The
problems arise when someone wants something specific- or detailed, the
kernel doesn't support it, and you end up writing alot of redundant code
around the kernel lib. And if you want to toy around with different
configurations of users, access handling? I'd say the best place for such
things are within the mudlib.

Let me just say in finishing words, that the kernel lib is probably
excellent for someone who wants its features- and doesn't care how it is
done, as long as it is done and done correctly. They'll save immense lot
of work thanks to you. I'd in fact, be very interested to hear from people
using the kernel, and dgd.


Something that just popped into my head when reading:
--------------------------------------------------------------------------
Just because my solution sounds simpler, doesn't mean I don't
understand and respect your point of view, or have less reason
to do so.
-------------------------------------------------------- FS 1998 ---------

;)

Take it easy folks,

Frank




List config page:  http://list.imaginary.com/mailman/listinfo/dgd