[MUD-Dev] Libs for 3D Client/Servers

[Travis Casey]

On Tuesday July 03, 2001 17:10, Dave Rickey wrote:
> From: Brian Hook <bwh at wksoftware.com>

>> I'm curious what the list membership would think of a product
>> that was basically a "graphical MUD in a box".  Something with a
>> set of libs for a server, client, database, etc. and that lets
>> MUD operators create and manage their own 3D graphics MUDs for
>> smaller scale operations (I'm thinking along the lines of
>> hundreds of simultaneous users on a server).

>> I believe MonoLith has something like this in their
>> LithTech/LithWorlds stuff...is this interesting to many people?

>> The big problem I can think of is that, even with sufficient
>> tools, there is a lot of complex art that needs to be created, so
>> the step from text MUD to graphical MUD is a pretty steep one.

> I think it would have potential, especially if it was not GPL'd
> (some other version of the copy-left scheme, that allowed the
> operators to collect money and even make a profit would be fine).

The GPL does not prevent either of these things -- if it did, Red
Hat and other for-profit Linux companies would not be able to exist.
You may be thinking of the Diku license, which didn't allow running
a for-profit mud without permission from the copyright holders.

In fact, the GPL only requires you to release source code you create
if you distribute the resulting binaries in some way -- if, for
example, you took a GPLed server, altered it, and ran it as your
server, you would not have to distribute your alterations, as long
as you didn't give away binaries of your server.

> The key point would be graphical assets, I'd suggest hard-coding
> that format and make it unchangeable by the users.

I'm not sure what you mean here -- do you mean that the format is
unchangeable, or that the graphics are formatted in a way to try to
make them unchangeable?  I doubt you can do the latter (after all,
the client has to be able to decode the format), and I'm not really
sure what the point of the former is.

> If any new capabilities were needed, then you could incorporate
> them in a backwards-compatible way.  The biggest barriers to entry
> for such a product would be the problems it poses for someone who
> makes a popular variant, can't afford to serve everyone who would
> like to connect but doesn't want to throw his work into the public
> domain, and conversely, building up a large enough "Open Source"
> community of critical assets like art and models.

If the art is not truly needed for the game (i.e., if it's easily
replaceable by drop-in other art), you could make a case for it
being "merely aggregrated" with the client, and keep it under
separate copyright.

> So I'd "copy-left" liscense all of the graphical assets and
> scripts, so that the dragon model created by Joe Artist can be
> picked up by Sam Scripter and given a skin made by his art student
> friend without a lot of fuss, but under a liscense (perhaps based
> on the FreeBSD or LGPL liscense?) that allowed the operator to
> make a profit.  And I'd keep the engine itself under a traditional
> liscense, so I could make money selling copies of the base client
> and maintain control of the core codebase, keep it from forking
> into incompatible versions.

This is the only part that wouldn't work under the GPL.  You could
sell copies of the base client, but you wouldn't be able to prevent
forks.  (And there wouldn't be much reason for people to buy your
base client... once someone out there had a copy, they could give it
away to others.)

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_) 

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