February 2000
- datagram protocol design theory? (Question about multithreaded servers) Ola Fosheim Grøstad
- Library error J C Lawrence
- Semi-OT: Linux support in commercial MUDs? Ola Fosheim Grøstad
- From the Apache Referrer logs J C Lawrence
- From the Apache Referrer logs Kris Van Hees
- good muds for ai programming? Robert Zubek
- good muds for ai programming? J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling cg@ami-cg.GraySage.Edmonton.AB.CA
- Event Scheduling J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Miroslav Silovic
- Event Scheduling Jp Calderone
- Event Scheduling Ola Fosheim Grøstad
- Event Scheduling Miroslav Silovic
- Event Scheduling J C Lawrence
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- IO Speed Suggestions Christopher Kohnert
- IO Speed Suggestions J C Lawrence
- Couple of articles Koster, Raph
- Couple of articles Dr Richard A. Bartle
- OT: Soliciting advice from Canadians Alex Oren
- MUD Specific Building pages MichelleThompson
- MUD Specific Building pages J C Lawrence
- Embedding Python icecube@ihug.co.nz
- Embedding Python icecube@ihug.co.nz
- Embedding Python J C Lawrence
- Embedding Python Todd McKimmey
- Embedding Python Oliver Jowett
- Embedding Python Todd McKimmey
- ADMIN: List post rejections J C Lawrence
- distributed objects Kevin Littlejohn
- distributed objects Vijay Weasel Prabhakar
- distributed objects Brandon J. Rickman
- distributed objects J C Lawrence
- distributed objects Koster, Raph
- distributed objects Vijay Weasel Prabhakar
- distributed objects David Bennett
- distributed objects Phillip Lenhardt
- distributed objects cjones@one.net
- distributed objects F. Randall Farmer
- distributed objects Ola Fosheim Grøstad
- distributed objects Kevin Littlejohn
- distributed objects J C Lawrence
- distributed objects Gary Whitten
- distributed objects Balthazaar
- distributed objects J C Lawrence
- distributed objects Ola Fosheim Grøstad
- distributed objects Eli Stevens {Grey}
- distributed objects Jon A. Lambert
- distributed objects Charles Hughes
- distributed objects Caliban Tiresias Darklock
- distributed objects Charles Hughes
- distributed objects J C Lawrence
- distributed objects J C Lawrence
- distributed objects Charles Hughes
- distributed objects Charles Hughes
- distributed objects Laurent Bossavit
- distributed objects Kevin Littlejohn
- distributed objects markm@caplet.com
- distributed objects KevinL
- Distributed Objects Justin Rogers
- Security J C Lawrence
- commercial muds and cable TV (was code base inquiry ) Sellers, Michael
- commercial muds and cable TV (was code base inquiry ) Matthew Mihaly
- commercial muds and cable TV (was code base inq uiry ) Sellers, Michael
- commercial muds and cable TV (was code base inq uiry ) Matthew Mihaly
- business models Matthew Mihaly
- business models Daniel.Harman@barclayscapital.com
- business models Vincent Archer
- business models Dave Rickey
- a shrinking pool of players? Johan J Ingles-le Nobel
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Bryce Harrington
- a shrinking pool of players? Travis S. Casey
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? Ryan P.
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Draymoor
- a shrinking pool of players? Koster, Raph
- The Endeavour Map and MUD Applications Michael Hohensee
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications David Bennett
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Eli Stevens {Grey}
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Koster, Raph
- The Endeavour Map and MUD Applications Lo, Kam
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Joel Dillon
- The Endeavour Map and MUD Applications Justin Rogers
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist J C Lawrence
- Next gen MUD wishlist Chris Jones
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Sellers, Michael
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Codebase Ideas punitac@prodigy.net
- Codebase Ideas Bryce Harrington
- Codebase Ideas Aaron Mitchell
- OT: Money as motivator (was code base inquiry ) J C Lawrence
- OT: Money as motivator (was code base inquiry ) Matthew Mihaly
- Guide Applicant : Player Ratio Geoffrey A. MacDougall
- Guide Applicant : Player Ratio Matthew Mihaly
- MUD-Dev digest, Vol 1 #286 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #286 - 13 msgs Caliban Tiresias Darklock
- MUD-Dev digest, Vol 1 #286 - 13 msgs Koster, Raph
- voice vs. text Matthew Mihaly
- voice vs. text Justin Rogers
- voice vs. text John Bertoglio
- voice vs. text Lovecraft
- voice vs. text Lo, Kam
- voice vs. text Hans-Henrik Staerfeldt
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Justin Rogers
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Dynamic help files, was code base inquiry Richard Woolcock
- OpenSource licenses for game rules? J C Lawrence
- To all the devoted! (fwd) J C Lawrence
- Newbies Johan J Ingles-le Nobel
- MUD-Dev digest, Vol 1 #288 - 9 msgs Dr. Cat
- (fwd) Commercial-use Restrictions on Code Bases (was: help me find 100% free graphical mud) J C Lawrence
Date: 12/02/1999
Subject: Re: Commercial-use Restrictions on Code Bases
(was: help me find 100% free graphical mud)
Newsgroup: rec.games.mud.admin
Author: Martin Keegan <mk270@cam.ac.uk>
Thread Message
In article <383EC091.F94E9912@spam.free.gamecommandos.com>, Ilya wrote:
>>I think that a mud will take care of itself. If a mud is
>>run correctly, there will be people that play there. If the
>>mud is a piece of crap, people might visit, but won't stay
>>long.
>
>True enough. But I'm not worried about the player base or
Just for the record I must dispute the "but won't stay there long"
line and its blind acceptance, but that's not why I'm posting.
> Too many of our most creative and productive minds in the mudding
> world are finally forced by economic concerns to abandon it in
> search of activities which can provide at least a minimal reward.
> If more code bases were out there and were promoted which allowed
> for commercial use, then
Now the Linux "counterexample" raised against you actually comes
back to help; since the Linux kernel, OS and operating environment
are all largely under free licences, it is possible, paradoxicly,
for the system to be exploited commercially. I'm sure we couldn't do
this with Minix.
So too mud server codebases. Geneticly we have various groupings of
server codebases which are related to one another by derivation or
inspiration. More important, however, is the typological distinction
along a sort of hack'n'slash <-----> RPG <-----> MOO <-----> talker
continuum. What we find is that there are almost two separate
communities, the Diku/AberMUD crowd of D&D-style games (and I stress
the word "games"), and most of the other types of mud on the other
side of the divide. The Diku mob doesn't know or care about the
existence of MOO/MUSH/LP, etc, and the MOO/MUSH mob look down
scornfully on the Diku people (to whom they should be grateful for
attracting losers and troublemakers away from their own systems).
None of these communities (however you count them) is significantly
communally aware of the issues familiar to the Free Software/Open
Source movement, and it shows. One interesting cultural artefact
demonstrating this is the way mud adverts will use the word 'code'
as a count-noun "We use a SMAUG code" (which to an OpenSourcer is
not a valid sentence, "We use SMAUG code" being the only option),
implying that there is little communication between these groups. If
there were greater overlap, there'd be more opposition to the use of
non-free mud servers, not only for the ideological bigotry
satisfaction reasons of the Free Software juggernaut, but also
because these people would be able to put forward strong practical
arguments against things like the Diku licence.
Elsewhere in this thread which I have been watching with interest,
Matt Chatterly identified three different types of reason someone
might start a not-so-new mud: coolness / powertrip, etc ; breakaway
/ disaffection ; actual desire for originality. He said that the
first two of these three ought to be taken out and shot. A while ago
I should certainly have agreed. However, I have recently read a post
[*] by Travis Casey on the MUD-Dev mailing list in which it was
argued that most of these StockMUDs about there should be considered
analogous to people running their own RPGs on pencil and paper and
someone wanting to be DM. Should the DM have to invent his/her OWN
regular polygon to get original dice? Of course not.
The analysis of the StockMUD phenomenon has fallen victim to a
category error. When I was compiling The Mud Tree, I counted as a
single mud variety all muds which derived from the same source
(e.g., Diku, Circle, SMAUG, MOO, Dirt, Mordor), but, not having the
benefit of the insights of Mr Casey or of Eric Raymond's Cathedral
and Bazaar essay (which I largely disagree with, but which would
have proven useful), failed to see that a lot of these people just
wanted to run their own game, rather than create their own unique
virtual world (partially because of the assumed orthodoxy (namely
that all mud administrators should want to be mud creators and
innovators)).
The first and second groups (the harmless DM wannabes and the
splitters) ought to be considered separately from the innovators,
even though they are doing roughly the same thing in the same
environment. The conditions of this environment are that players
don't communicate with a significant proportion of the mudding
community and there is a strongly defined notion of acceptable
variation. Players will tolerate changes in races, classes, etc, but
will strongly reject muds which have a different set of basic
commands or fundamentally different combat system. The "norming"
effect whereby GPLed code in free software projects ensures that
forks and splits don't occur too damagingly by all the useful
changes being merged into a central tree has its counterpart in the
mudding world: popular innovations within the permitted scope will
propagate from mud to mud slowly through the word of mouth
transmission mechanism of a fragmented community. There's certainly
no central Diku clearing house for ideas, but there might as well
be.
So, why do all three groups choose the same old code? The first two
groups obviously want to attract players, and familiarity sells mud
time. The third group may (separately from the familiarity to the
players issue) also select a familiar codebase because it will be
easier to modify to their tastes, or because there is a particular
set of desired features offered by the codebase. I submit that the
most desired feature is mud socket code: it's the thing which
constitutes a real barrier to entry for aspiring mud designers. The
easy way out is to use someone else's code ...
What this has led to is using not only stock socket code but a whole
stock mud, probably due to the difficulty of separating the two. For
the want of some socket code, the game mechanics and interface of an
entire mud are copied.
I think it would be quite beneficial (irrespective of the accuracy
or otherwise of my ever-haughty and possibly self-serving analysis)
to have a framework of LGPLed components (socket code, parser, game
mechanics, "database" (Ok, so the middle two are interdependent))
making up a mud system, allowing coders to take only the bits they
want, forcing them only to conform to a particular set of interfaces
between these components, rather than forcing them to accept all the
components just to get the single one they want. By no coincidence
whatsoever I have been writing a component of just such a system
... :) and shall probably be releasing it (the networking code) this
weekend.
>perhaps we would have saved more of these creative/productive
>minds for the hobby/art and this would have been a good thing.
Perhaps as the maintainer of such a high profile site as
gamecommandos you are in a good position to promote things like this...
Mk
[*] http://www.kanga.nu/archives/MUD-Dev-L/1999Q4/msg00467.html - (fwd) ADMIN: "A Classification Of Muds" [was 'In defence of stock muds...'] J C Lawrence
- Distribution Geir Harald Hansen
- player persistence Matthew Mihaly
- [Off-topic] GDC-2000 Derek Snider
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 Justin Lockshaw
- [Off-topic] GDC-2000 Christopher Allen
- [Off-topic] GDC-2000 Matthew Mihaly
- [Off-topic] GDC-2000 Joe Andrieu
- [Off-topic] GDC-2000 Kristen L. Koster
- [Off-topic] GDC-2000 Richard A. Bartle
- [Off-topic] GDC-2000 Bruce
- [Off-topic] GDC-2000 David Bennett
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] AAAI symposium (was: GDC-2000) Robert Zubek
- MSP Richard Ross
- Privateer-style mu*? Bobby Bailey
- Minimum community sizes Dan Root
- Minimum community sizes Koster, Raph
- Minimum community sizes Dan Root
- Minimum community sizes adam@treyarch.com
- Minimum community sizes Matthew Mihaly
- Minimum community sizes David Bennett
- Minimum community sizes Matthew Mihaly
- Pike codebase Daniel Podlejski
- chil@gate.net Joel Kelso