Phantasmal Site > DGD > Writing a Library > Reimplementing From Scratch

Starting Again (and Again, and Again) From Scratch

As for the larger conversation topic, I think the basic problem is that the overwhelming amount of work being done in the LPMud area is endless redundant reimplementations of trivial low level libraries that should have been standardized a decade ago. There is virtually no coordination in the LPMud world; it seems like every single good programmer whose LPC interest is peaking finds a new ancient mudlib to bring from the 1991 era to the 1993 era, and it just STOPS there. I don't understand it. – Par Winzell

From DGD Mailing List  Mon Aug 23 15:11:01 2004
From: DGD Mailing List (Derek Baron)
Date: Mon Aug 23 15:11:01 2004
Subject: [DGD] Quote of the year

>As for the larger conversation topic, I think the basic problem is that the 
>overwhelming amount of work being done in the LPMud area is endless 
>redundant reimplementations of trivial low level libraries that should have 
>been standardized a decade ago. There is virtually no coordination in the 
>LPMud world; it seems like every single good programmer whose LPC interest 
>is peaking finds a new ancient mudlib to bring from the 1991 era to the 
>1993 era, and it just STOPS there. I don't understand it.

That's my candidate for best paragraph of the year in the list. Maybe 
because it hits so close to home; I know I'm guilty of reimplementation. Of 
course I don't think I ever would have *really* understood things like stack 
security, natural language parsing or the intermud3 protocol if I hadn't 
rebuilt them from scratch. Nevertheless, I didn't make other advancements 
that could have moved things forward - a shame I guess but it is what it is.

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement



From DGD Mailing List  Thu Aug 26 16:55:01 2004
From: DGD Mailing List (David Jackson)
Date: Thu Aug 26 16:55:01 2004
Subject: [DGD] GurbaLib

At 02:37 PM 8/26/2004, you wrote:


>Instead, I shelved the project (it's on a CD-R somewhere on my shelf, at 
>least) when I considered that I might like to bring it commercial someday, 
>or at least have the option of licensing it as such.  As much work has 
>been done with LDMUD to cleanup the Lars/Amlyaar stuff, it's still a 
>direct decendent from those driver lines and thereby subject to the same 
>license restrictions.

That's the biggest problem in the MUD development community 
today.  Thousands (dare I say millions?) of man hours have gone towards 
developing libs, but no-one ever wants to release them (some for the reason 
you stated, and thousands of other reasons as well).

We have to keep re-inventing the wheel, over and over again.  How much 
code, I wonder, will never see the light of day again?


>>  You can best serve DGD by appointing yourself to such a role, and
>>releasing your code from the very beginning.  Yes, even when it's
>>basically unusable.
>
>I'm of mixed opinions on this one.
>
>I don't think I really want to release a (mostly-) non-working product, 
>only to have to "hand hold" other people after they unpack the tarball.
>It's bad enough that half the people who would download the thing barely 
>understand how to compile and launch their driver executable.
>
>On the other hand, it's a sure-fire way to get beta testers, without 
>having to even make them THINK of themselves as such.  Hmm.


This falls into "one of the other reasons people don't release code".

I think back on the Linux addage of, "Release early.  Release 
often."  Maybe we should adopt this.


>>Starting from an existing lib would be fine,
>>whatever floats your boat.  Just make sure you understand any
>>appropriate license issues.
>>
>
>There are some pretty-interesting libraries out there (yours included, by 
>the way), but I'd have chosen to be a DIKU-family developer if I wanted to 
>take someone else's work, make a few changes here and there, and release 
>it as a new product line.

I don't think anyone suggested that.


>No, what's really needed is a new creation.  A new species, if you will, 
>of game library for the DGD engine.  Something that can be GPL or BSD or 
>whatever license you want, right from the get-go.

And yet another mudlib is born, when there are several mudlibs that need to 
be completed.

>>  If that's more work than you wish to commit to, help out somebody on
>>an existing project of that type.
>>
>>  Under other circumstances I'd nominate me, but Phantasmal's been
>>pretty stagnant for awhile.  It sounds like shortly, Par Winzell will
>>be the guy to help.
>>
>
>I guess I'll look and see what the Skotos folks release and give it some 
>more thought.
>
>Thanks for your comments, though, as it's always interesting to hear from 
>folks who have done mudlib work that's been released in various stages of 
>completion.
>
>Cheers,
>Jason D. Bourgoin
>aka Katmandu

And perhaps not so interesting to hear from folks who haven't released 
anything at all.

David Jackson

From: DGD Mailing List (Stephen Schmidt)
Date: Thu Aug 26 21:16:01 2004
Subject: [DGD] GurbaLib

On Thu, 26 Aug 2004, Jas wrote:
> If putting together something like that isn't on Dworkin's "to do" list,
> maybe "the rest of us" should take up the initiative.

I concur, and I think that this would be a worthwhile project
(albeit for someone with fewer kids than me ;) even with SkotOS
coming out for public access.

> So, the $64,000 question is two-fold:  is there enough of an interest in
> such a project, and are there other people who would be willing to
> commit either their time, technical expertise, or something else to the
> project?

As someone who's been directly involved in coding two mudlibs
that have been publicly released, and tangentially involved in
a couple more that have and several more than haven't: No project
of this sort succeeds if more than three people are involved.
Either two or three is ideal; you need someone else around to
keep you moving forward. Two is more streamlined and harder for
one person to slack off, but two people can have tie votes and
three can't.

It helps if people are clearly divided by tasks going into
the project. For something like this, one person for low-level
coding, one for game world coding, one for "artsy-fartsy" might
be the right division. Given the needs of DGD, the artsy-fartsy
contribution would probably actually be the most important.

Steve

I'm not going to stop coding; in fact, I've just realized that what the DGD 
community needs more than anything else are finished products.  I know that 
your message here has advocated against the use of "stock" libs...

BUT, from what you've said, and my own observations, it is imperative for 
us, for both the sake of DGD and MUD'ing in general, to produce the following;

1)  We have a great driver already...
2)  We need OLC creation tools, to inspire non-coders to become builders...
3)  We need tools to link the web browser to the MUD, so that getting into 
the MUD can be seamless for the novice...
4)  We need a stock lib with enough playable content so that the average 
guy will be inspired to set up a MUD in the first place...
5)  We need it now.

All of the great MUDs that are out there, after a closer inspection, are 
MUDs that have been around for a while (with only a few exceptions).   They 
have had the hordes of builders pass through them, to create the massive 
amount of content that is necessary to grab and keep players.  The cycle is 
a vicious one; and the only way to break it is to create a massive amount 
of content to draw players in the first place.

But, most libs "die on the vine" because they undertake the massive 
project, only to become dis-interested once the size of the project 
overwhelms them (I suffered from this as well).

I think the original idea for the 2.4.5 lib is a valid model for today; 
players play until they exhaust the content, and once they do, they are 
then in charge of creating new content.

-David Jackson

From: Noah Gibbs
Subject: Re: [DGD] GurbaLib
Date: Thu, 26 Aug 2004 11:39:47 -0700 (PDT)

--- Jas wrote:
> If putting together something like that isn't on Dworkin's "to do"
> list, 
> maybe "the rest of us" should take up the initiative.
> [...]
> So, the $64,000 question is two-fold:  is there enough of an interest
> in 
> such a project, and are there other people who would be willing to 
> commit either their time, technical expertise, or something else to
> the project?

  Historically speaking, the answer is "no" and "no".  Many offers will
be made.  Encouraging emails will occur.  Little work will happen and
less progress will be made.  So far, DGD code is advanced by
individuals and by small groups.  List-based 'net collaborations simply
do not work.

  You need a strong central project lead, who will find he also needs
to do the vast majority of the work.

  You can best serve DGD by appointing yourself to such a role, and
releasing your code from the very beginning.  Yes, even when it's
basically unusable.  Starting from an existing lib would be fine,
whatever floats your boat.  Just make sure you understand any
appropriate license issues.

  If that's more work than you wish to commit to, help out somebody on
an existing project of that type.

  Under other circumstances I'd nominate me, but Phantasmal's been
pretty stagnant for awhile.  It sounds like shortly, Par Winzell will
be the guy to help.

From: Jas
Subject: Re: [DGD] GurbaLib
Date: Thu, 26 Aug 2004 11:37:02 -0800

Noah Gibbs wrote:

>  You need a strong central project lead, who will find he also needs
>to do the vast majority of the work.
>  
>

That's pretty-much what I noticed when I started building a new 
basic/starter mudlib for the LDMUD driver, with plans to release it for 
public distribution.  Lots of people expressed interest in what I had in 
mind, but a "show of hands" produced zero volunteers to assist with the 
project.

I spent many nights pounding away on my keyboard and roughly the same 
number of nights sleeping on the couch instead of with the Mrs., 
coincidentally.  When I was finished, I had something that was probably 
"good enough" to merit a 1.0 release stamp.

Instead, I shelved the project (it's on a CD-R somewhere on my shelf, at 
least) when I considered that I might like to bring it commercial 
someday, or at least have the option of licensing it as such.  As much 
work has been done with LDMUD to cleanup the Lars/Amlyaar stuff, it's 
still a direct decendent from those driver lines and thereby subject to 
the same license restrictions.

>  You can best serve DGD by appointing yourself to such a role, and
>releasing your code from the very beginning.  Yes, even when it's
>basically unusable.
>

I'm of mixed opinions on this one.

I don't think I really want to release a (mostly-) non-working product, 
only to have to "hand hold" other people after they unpack the tarball.  
It's bad enough that half the people who would download the thing barely 
understand how to compile and launch their driver executable.

On the other hand, it's a sure-fire way to get beta testers, without 
having to even make them THINK of themselves as such.  Hmm.

>Starting from an existing lib would be fine,
>whatever floats your boat.  Just make sure you understand any
>appropriate license issues.
>  
>

There are some pretty-interesting libraries out there (yours included, 
by the way), but I'd have chosen to be a DIKU-family developer if I 
wanted to take someone else's work, make a few changes here and there, 
and release it as a new product line.

No, what's really needed is a new creation.  A new species, if you will, 
of game library for the DGD engine.  Something that can be GPL or BSD or 
whatever license you want, right from the get-go.

>  If that's more work than you wish to commit to, help out somebody on
>an existing project of that type.
>
>  Under other circumstances I'd nominate me, but Phantasmal's been
>pretty stagnant for awhile.  It sounds like shortly, Par Winzell will
>be the guy to help.
>  
>

I guess I'll look and see what the Skotos folks release and give it some 
more thought.

Thanks for your comments, though, as it's always interesting to hear 
from folks who have done mudlib work that's been released in various 
stages of completion.

Cheers,
Jason D. Bourgoin
aka Katmandu