Original MUD Association?
H. McDaniel
> I propose that a few of us working on *original* games get
> together and form an association to promote our games, to
> share resources (knowledge and money or other supplies
> to fuel projects beneficial to the members.)
>
> If all members agreed to promote each other's games, you
> have a situation (I think) where it is possible to pool a lot
> of resources, including management personnel, public
> relations, play testers and so on. Way, way, way back when
> I first got into mudding I worked on a group of about 3 games.
> Each game had original areas and lots of original code being
> worked on. All of the admin were friends and gave accounts
> to the builders of every other game in the group. I'm not
> saying we need to go that far, but that atmosphere of
> cooperation allowed for the implementor of any of the games
> to get a lot of useful feedback from the admin and builders of
> the other games.
>
> Anyhow, if you can pool management resources, and by
> management here I mean anybody in a position to manage
> game or game play (this may include "wizards" or whatever
> you call them on your game.) then having 24 hour, 7 days
> a week online support for players isn't a problem even for
> the smallest game. You simply ask for management from
> some other games to help watch your game during the times
> when you aren't available. In fact it might be desirable to
> have a meta mud command center. Ha. A single location
> where users can manage several games simultaneously.
> Not that I feel like coding it, I'm just saying ;)
>
> Perhaps such an association will be most appealing to original
> muds that are still in development, but I thought I'd put it on the
> table and see what admin think.
>
> -McDaniel
cl...@kanga.nu
> I propose that a few of us working on *original* games get
> together and form an association to promote our games, to
> share resources (knowledge and money or other supplies
> to fuel projects beneficial to the members.)
I'm more than willing to host such a project as an off-shoot of
MUD-Dev at Kanga.nu.
> Anyhow, if you can pool management resources, and by
> management here I mean anybody in a position to manage
> game or game play (this may include "wizards" or whatever
> you call them on your game.) then having 24 hour, 7 days
> a week online support for players isn't a problem even for
> the smallest game. You simply ask for management from
> some other games to help watch your game during the times
> when you aren't available. In fact it might be desirable to
> have a meta mud command center. Ha. A single location
> where users can manage several games simultaneously.
> Not that I feel like coding it, I'm just saying ;)
Sounds a lot like what the Pan project was supposed to be (and never
will be due to over-reaching scope), and Bunyip might yet be (if I
can finish setting up the box).
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
cl...@kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Acius
>>I propose that a few of us working on *original* games get
>>together and form an association to promote our games, to
>>share resources (knowledge and money or other supplies
>>to fuel projects beneficial to the members.)
>
> I'm more than willing to host such a project as an off-shoot of
> MUD-Dev at Kanga.nu.
I'm willing to help. Just poke me.
>>Anyhow, if you can pool management resources, and by
>>management here I mean anybody in a position to manage
>>game or game play (this may include "wizards" or whatever
>>you call them on your game.) then having 24 hour, 7 days
>>a week online support for players isn't a problem even for
>>the smallest game. You simply ask for management from
>>some other games to help watch your game during the times
>>when you aren't available. In fact it might be desirable to
>>have a meta mud command center. Ha. A single location
>>where users can manage several games simultaneously.
>>Not that I feel like coding it, I'm just saying ;)
Nooo ... must ... not get ... distracted ... from ... mud coding ...
Actually, this sounds enormously fun. Of course, being an LP nut, I'd
probably implement the whole thing in LPC, given the chance. A single
meta-MUD with intermud links to the other muds would be cool. Being able
to project yourself into any MUD would be cooler, but is probably biting
off a bit much...
> Sounds a lot like what the Pan project was supposed to be (and never
> will be due to over-reaching scope), and Bunyip might yet be (if I
> can finish setting up the box).
Tried searching the web ... although I discovered that "Bertie the
Bunyip is a devastatingly handsome Australian mud monster," I didn't
find the projects you're referring to. Can anyone drop a link? Thanks.
-- Acius
acius _at_ simud _dot_ org
P.S. I tried getting InterMUD working once, and though I managed to get
some sort of signal, I have no working code nor intelligible spec that I
could find, and ended up being unable to do anything useful with my
flaky connection. Would we use InterMUD for something like this, and if
so, can someone point me in the direction of some decent docs?
H. McDaniel
> P.S. I tried getting InterMUD working once, and though I managed to get
> some sort of signal, I have no working code nor intelligible spec that I
> could find, and ended up being unable to do anything useful with my
> flaky connection. Would we use InterMUD for something like this, and if
> so, can someone point me in the direction of some decent docs?
I am not inclined to use intermud for this project. You can bet that
a lot of original games don't use LPC. Not everybody will want to implement
intermud support in their custom mud base. It certainly isn't on my list of
things to do (I have a very long list right now.) As far as game play goes
I have ZERO interest in providing mud-to-mud mail, finger, whois or
wiz chat services either. Same for transporting game objects to some other
guy's mud. I don't see the point given that by virtue of the fact my game
is
original such objects would be a "little" out of context on the other guy's
game.
OTOH I wouldn't have anything against setting up a mud gateway to all
associated muds. A player would need only a single password and user
account on the gateway server. There they get a menu of games to connect
to and can connect to any of those games without ever needing to supply
more password(s) or player name/user id. Or at least such a gateway would
make sense with my mud server because we have a user account layer
that allows you to access all of your characters without needing a password
for each character.
Anyhow, this is getting far ahead of things ;) First we need to have some
specific goals for the association. But that can't be settled until some
number of prospective members are identified and discuss 'it'.
-McDaniel
cl...@kanga.nu
> cl...@kanga.nu wrote:
>> Sounds a lot like what the Pan project was supposed to be (and never
>> will be due to over-reaching scope), and Bunyip might yet be (if I
>> can finish setting up the box).
> Tried searching the web ... although I discovered that "Bertie the
> Bunyip is a devastatingly handsome Australian mud monster," I didn't
> find the projects you're referring to. Can anyone drop a link?
Bunyip has not been publicised, well, not outside DevMUD.
Essentially at this point its just a dual P3-400 sitting on my DMZ
waiting to be deployed. Not much left to do: setup process
ccounting limits, disk quotas, and a well defined capability system.
I've just been missing the time to do that.
The general intent for Bunyip is to be the successor to Pan as
discussed on the Pan and Meta lists at Kanga.nu. Initial intent to
cut back Pan's scope to something actually accomplishable in
reasonable time: dev-oriented MUD hosting and support for those
projects which are either interesting or which show some promise of
advancing the state of the art (server space, bandwidth, AFTP,
BitKeeper, web, lists, list archives, etc).
KaVir
>
> I propose that a few of us working on *original* games get
> together and form an association to promote our games, to
> share resources (knowledge and money or other supplies
> to fuel projects beneficial to the members.)
[snip]
I like this idea - a lot. I've recently formed an "alliance" of sorts
between the mud I'm currently developing (HnS/GoP/PK oriented) and a
mud developed by an online friend (pure RP) - the idea being that our
muds are so different, they're not going to attract the same audience,
so we might as well send our "player rejects" to each other! Equally,
it gives us the chance to give "outside opinions" of each others
concepts and provide useful feedback.
However there's no reason why it couldn't go a step further and become
a fully-fledged group. It would take the whole "promotion" thing
another step, and also help counter one of the biggest problems with
having so many stock muds - the fact that a newbie logs onto half a
dozen muds, finds that they're all the same, and decides not to bother
looking any more. If we can direct the people "who want something
different" to a site dedicated to completely original muds, it would
be a big benefit to everyone IMO.
What I'm particularly interested in:
* Promoting original muds.
* Providing places for people to discuss original muds.
* Providing resources to help people create original muds.
* Bouncing ideas and concepts off other developers.
* Exchanging design ideas with other developers.
* Sharing management tips with other admin.
* Sharing the knowledge and insight that comes with experience.
What I'm not interested in:
* Maintaining any sort of "player blacklist".
* Exchanging significant code with other developers.
* Letting other people manage my mud.
* Exchanging personal (my team are welcome to do what they wish, but I
don't want strangers involved in the running of my project)
What I'm specifically against:
* Promoting self-acclaimed "original" obvious diku/whatever ripoffs.
* Being coerced into helping other people create original muds.
* Being coerced into financing other peoples original muds.
* Being coerced by those outside my project to run my mud in a certain
way.
I know of a couple of other projects in the design/early
implementation phase which have great promise, as well as a handful of
scratch-written muds which are showing potential. I am hoping to
speak to some of them at the Meet and Greet III on Saturday 18th May,
as one of the discussion rooms will focus on custom mud development.
You can read more about it here:
http://mudworld.inetsolve.com/awards/2002/
--
KaVir
God Wars II
www.GodWarsII.com
Jon A. Lambert
How do you define "original"?
Which of the following muds would qualify as "original"?
1) Realms of Despair
2) Aardwolf
3) Rivers of Mud
4) Abandoned Reality
5) Carrion Fields
6) PernMush
7) Cajun Nights
Which of the following mud server bases in development are "original"?
1) CoffeeMud
2) Mud++
3) ScryMud
4) DentinMud
5) Circle
6) LambdaMoo
7) LDMud
8) Godwars
--
J. Lambert
H. McDaniel
I touched on this question in email to KaVir. I actually think that
it's a mistake to try and identify an "original mud" and to grant
memberships (in effect) to a mud. Instead I lean towards using a
point system that says this particular aspect of a game is "original".
If an individual gets enough points then they are eligible for
membership. Individual meaning all levels of game builders and
not simply the game implementor. At its root the question of
originality is of course subjective and not only that but it is time
sensitive. This isn't a fatal flaw, we just have to understand that
because something is original today doesn't mean it will be
original 2 years from now. And that because *I* find something
original doesn't mean you do. I think we can define original to
include:
Innovative - Does the thing present a novel approach to an old
problem or is it applying an old idea to a newly identified
problem in a way that wasn't immediately obvious to others
working on the problem?
Original - Is the thing the first of it's kind?
Unique - Is the thing one of a kind?
Now, the route to membership might follow this path:
1. An individual who believes they have created something
innovative, original or unique applies for membership. The
application includes specific claims that can be investigated.
2. At some point a group of current members get together to
discuss the application and vote on whether to grant basic
membership or not. The discussion would center around
whether the applicant has something innovative, original
or unique to offer.
Mind you, not all memberships would be equal. Somebody
with 50 points is not going to have the same voting
privileges or access to member services as somebody
with 2000 points. Access to something like an association
run mud list would be especially restricted to games that
have members working on them with good scores in multiple
categories.
I see no point in having a group like this open up
membership to all comers. If you want that there are
places on the net where this exists already ;) Whenever
the question of a mud association is brought up on this
NG there is going to be the obligatory cry of, " it isn't fair"
of course... But I'm listening.
-McDaniel
Blane Bramble
> "Jon A. Lambert" wrote:
>
> I touched on this question in email to KaVir. I actually think that
> it's a mistake to try and identify an "original mud" and to grant
> memberships (in effect) to a mud. Instead I lean towards using a
> point system that says this particular aspect of a game is "original".
> If an individual gets enough points then they are eligible for
> membership. Individual meaning all levels of game builders and
> not simply the game implementor. At its root the question of
> originality is of course subjective and not only that but it is time
> sensitive. This isn't a fatal flaw, we just have to understand that
> because something is original today doesn't mean it will be
> original 2 years from now.
Does said MUD and staff lose membership in this circumstance?
> And that because *I* find something
> original doesn't mean you do. I think we can define original to
> include:
>
> Innovative - Does the thing present a novel approach to an old
> problem or is it applying an old idea to a newly identified
> problem in a way that wasn't immediately obvious to others
> working on the problem?
>
> Original - Is the thing the first of it's kind?
>
> Unique - Is the thing one of a kind?
>
> Now, the route to membership might follow this path:
> 1. An individual who believes they have created something
> innovative, original or unique applies for membership. The
> application includes specific claims that can be investigated.
> 2. At some point a group of current members get together to
> discuss the application and vote on whether to grant basic
> membership or not. The discussion would center around
> whether the applicant has something innovative, original
> or unique to offer.
What about facets of my game which has been around since 1989 (but not
available since 1993) that were original back then - do they get judged on
their value at the time I wrote them, or only now when much is no longer
unique or original? What about a game that is in development now but may
only apply to join in a few years (when the author finds out about the
group) - will he be barred because what was original when he started is no
longer because he didn't have the resources to make the game available for a
couple of years?
>
> Mind you, not all memberships would be equal. Somebody
> with 50 points is not going to have the same voting
> privileges or access to member services as somebody
> with 2000 points. Access to something like an association
> run mud list would be especially restricted to games that
> have members working on them with good scores in multiple
> categories.
Now I think you've argued yourself out of the "good idea" box. So, voting
privs are doled out based upon a subjective "originality" value. This (IMHO)
makes the entire idea worthless, either members should be roughly equal, or
there is no value in this, it's just an elitist clique (and this is from
someone who only ever writes original games from scratch).
>
> I see no point in having a group like this open up
> membership to all comers. If you want that there are
> places on the net where this exists already ;) Whenever
> the question of a mud association is brought up on this
> NG there is going to be the obligatory cry of, " it isn't fair"
> of course... But I'm listening.
I do think there is a place for an organisation like this, I'm not sure I
agree with the scoring of membership. If I am working on an original game
(original code base, major new development of existing code base, original
idea for setting and mechanics) then I should be entitled to join - either I
am doing something original or I am not.
Blane.
H. McDaniel
> "H. McDaniel" <cut_Xs_off_to_...@stellargenesis.com> wrote in
> message news:3CD2CB3F...@stellargenesis.com...
> > "Jon A. Lambert" wrote:
> >
> > I touched on this question in email to KaVir. I actually think that
> > it's a mistake to try and identify an "original mud" and to grant
> > memberships (in effect) to a mud. Instead I lean towards using a
> > point system that says this particular aspect of a game is "original".
> > If an individual gets enough points then they are eligible for
> > membership. Individual meaning all levels of game builders and
> > not simply the game implementor. At its root the question of
> > originality is of course subjective and not only that but it is time
> > sensitive. This isn't a fatal flaw, we just have to understand that
> > because something is original today doesn't mean it will be
> > original 2 years from now.
>
> Does said MUD and staff lose membership in this circumstance?
Points would be historical. You get points and those points stay on
your record. Losing membership would be relatively difficult outside
of choosing to drop off (or violating some sacred membership rule.)
Mind you, only individuals (in my plan) would be members and not
a MUD. Of course if the implementor of a MUD notices that lots of
his staff are members with impressive ratings then he/she can
use that in advertising.
> > And that because *I* find something
> > original doesn't mean you do. I think we can define original to
> > include:
> >
> > Innovative - Does the thing present a novel approach to an old
> > problem or is it applying an old idea to a newly identified
> > problem in a way that wasn't immediately obvious to others
> > working on the problem?
> >
> > Original - Is the thing the first of it's kind?
> >
> > Unique - Is the thing one of a kind?
> >
> > Now, the route to membership might follow this path:
> > 1. An individual who believes they have created something
> > innovative, original or unique applies for membership. The
> > application includes specific claims that can be investigated.
> > 2. At some point a group of current members get together to
> > discuss the application and vote on whether to grant basic
> > membership or not. The discussion would center around
> > whether the applicant has something innovative, original
> > or unique to offer.
>
> What about facets of my game which has been around since 1989 (but not
> available since 1993) that were original back then - do they get judged on
> their value at the time I wrote them, or only now when much is no longer
> unique or original?
I'd say that they don't get judged at all. It sucks but I wrote a lot of
original
stuff back in 1992-1994 myself that is no longer relevant because it isn't
available for play.
> What about a game that is in development now but may
> only apply to join in a few years (when the author finds out about the
> group) - will he be barred because what was original when he started is no
> longer because he didn't have the resources to make the game available for a
> couple of years?
All that should count, IMO are things currently available to the public or at
the
very least available for inspection by the judges. If you wrote something
TWENTY years ago it might count if you could somehow make it available for
play right now. It would have to be judged in a contemporary context and not
simply be compared to the state of the art twenty years ago however.
This is similar to the academy of motion pictures. If you produce a film that
you said you made 10 years ago and that film looks better than any other
film that was out 10 years ago are you going to get nominated for an Oscar
for best film of 1992? Uh........ no.
> >
> > Mind you, not all memberships would be equal. Somebody
> > with 50 points is not going to have the same voting
> > privileges or access to member services as somebody
> > with 2000 points. Access to something like an association
> > run mud list would be especially restricted to games that
> > have members working on them with good scores in multiple
> > categories.
>
> Now I think you've argued yourself out of the "good idea" box. So, voting
> privs are doled out based upon a subjective "originality" value. This (IMHO)
> makes the entire idea worthless, either members should be roughly equal, or
> there is no value in this, it's just an elitist clique (and this is from
> someone who only ever writes original games from scratch).
Hey, when you come up with an objective and practical way to measure
originality in muds, you let me know. I know an original game when I
see it.
> > I see no point in having a group like this open up
> > membership to all comers. If you want that there are
> > places on the net where this exists already ;) Whenever
> > the question of a mud association is brought up on this
> > NG there is going to be the obligatory cry of, " it isn't fair"
> > of course... But I'm listening.
>
> I do think there is a place for an organisation like this, I'm not sure I
> agree with the scoring of membership. If I am working on an original game
> (original code base, major new development of existing code base, original
> idea for setting and mechanics) then I should be entitled to join - either I
> am doing something original or I am not.
No, either you're doing something that others can recognize as original or
you aren't. People make judgments about things they can perceive
not about what is in your head, heart or stashed on a hard drive somewhere.
For instance the game I'm working on is 100% original, all from scratch.
I don't intend to share the code so I know that the only way I can demonstrate
it's originality is in the player interface, the world presented and so on.
Maybe
it isn't fair that probably 90% of the hard work (IMO) is on the server side
and I'll never get all the laurels for that I may feel are warranted, but
that's
life.
-McDaniel
cl...@kanga.nu
> I touched on this question in email to KaVir. I actually think
> that it's a mistake to try and identify an "original mud" and to
> grant memberships (in effect) to a mud. Instead I lean towards
> using a point system that says this particular aspect of a game is
> "original".
Its an odd thing to start forming a group by first defining who
can't belong. You'd do better by being inclusive as as a group, and
allow (they're going to do it anyways) individuals to be exclusive
as to their associations.
Remember High School?
> Innovative
> Original
> Unique
Which are all value judgements, all subject to debate, and
guaranteed to be clique enforced once the group matures at all. Not
a good recipe for success.
> Now, the route to membership might follow this path:
> 1. An individual who believes they have created something
> innovative, original or unique applies for membership. The
> application includes specific claims that can be investigated.
> 2. At some point a group of current members get together to
> discuss the application and vote on whether to grant basic
> membership or not. The discussion would center around
> whether the applicant has something innovative, original
> or unique to offer.
> Mind you, not all memberships would be equal. Somebody
> with 50 points is not going to have the same voting
> privileges or access to member services as somebody
> with 2000 points. Access to something like an association
> run mud list would be especially restricted to games that
> have members working on them with good scores in multiple
> categories.
Which tends to set you up for hostage games with donated services
and their threatened withdrawal being used as counters.
Simpler:
Here's the group. Here are the services the group offers.
Anybody can see the services. Access to the individual services
requires social networking with the operators of those services.
The group is then primarily defined a set of communication media and
access thru them to various support services..
> I see no point in having a group like this open up membership to
> all comers. If you want that there are places on the net where
> this exists already ;) Whenever the question of a mud association
> is brought up on this NG there is going to be the obligatory cry
> of, " it isn't fair" of course... But I'm listening.
Why assume fairness on the part of members to the group given that
there are precious few feedback loops?
Richard Woolcock
news:f5a3bd39.02050...@posting.google.com...
> "H. McDaniel" <cut_Xs_off_to_...@stellargenesis.com> wrote
in message news:<3CD16F90...@stellargenesis.com>...
> > Oops. Meant to cross-post this to rec.games.mud.admin. So here
goes:
> >
> > > I propose that a few of us working on *original* games get
> > > together and form an association to promote our games, to
> > > share resources (knowledge and money or other supplies
> > > to fuel projects beneficial to the members.)
> > >
[snip]
> How do you define "original"?
[snip]
To be honest I was thinking along the lines of simply "written
from scratch". It might be a bit muddist, but my main interest
(at least at the moment) lies in discussing design issues - if
someone has started with an existing codebase, then they've
already got their game. They've skipped completely what I
consider to be one of the most important phases in creating a
good mud.
However you've made me think now (I hate it when that happens!).
What if someone creates a mud from scratch - by hacking it all
together? Or what if they write a mud from scratch which is
designed to work in the same way as an existing mud (eg a Diku)?
My proposal would be that each mud should be "original" (as in
code), and that existing members should get to vote on whether
it was sufficiently "original" in theme/concept (I doubt there
is any such thing as a "truely" original concept, after all,
but the mud shouldn't aim to immitate - it should have its own
vision).
The product wouldn't have to be finished, but there should be
enough in the way of design (and some proof of implementation)
to show that the mud is more than just a pipe dream.
After all, it's in the early stages of development when the
bouncing of ideas and concepts is most critical - as with any
software project.
KaVir.
H. McDaniel
> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
> > "Jon A. Lambert" wrote:
>
> > I touched on this question in email to KaVir. I actually think
> > that it's a mistake to try and identify an "original mud" and to
> > grant memberships (in effect) to a mud. Instead I lean towards
> > using a point system that says this particular aspect of a game is
> > "original".
>
> Its an odd thing to start forming a group by first defining who
> can't belong. You'd do better by being inclusive as as a group, and
> allow (they're going to do it anyways) individuals to be exclusive
> as to their associations.
The point system is used by the Writer's Guild. You can't belong if
you haven't produced something like a play, book or had something
published. Does that sound odd? It's a hell of a lot better than the
standard that determines who can start a mud (ie: no standard at all.)
> Remember High School?
You'll have to be more specific.
[...]
>
> > I see no point in having a group like this open up membership to
> > all comers. If you want that there are places on the net where
> > this exists already ;) Whenever the question of a mud association
> > is brought up on this NG there is going to be the obligatory cry
> > of, " it isn't fair" of course... But I'm listening.
>
> Why assume fairness on the part of members to the group given that
> there are precious few feedback loops?
I don't know that fairness to the degree you have in mind is necessary.
It is simply necessary that the members are satisfied with the level
of service.
-McDaniel
cl...@kanga.nu
> cl...@kanga.nu wrote:
>> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
>>> "Jon A. Lambert" wrote:
>> Its an odd thing to start forming a group by first defining who
>> can't belong. You'd do better by being inclusive as as a group,
>> and allow (they're going to do it anyways) individuals to be
>> exclusive as to their associations.
> The point system is used by the Writer's Guild. You can't belong
> if you haven't produced something like a play, book or had
> something published. Does that sound odd? It's a hell of a lot
> better than the standard that determines who can start a mud (ie:
> no standard at all.)
A critical difference is that that is an external and objective
criteria. None of the proposed critera have had those qualities.
>>> I see no point in having a group like this open up membership to
>>> all comers. If you want that there are places on the net where
>>> this exists already ;) Whenever the question of a mud
>>> association is brought up on this NG there is going to be the
>>> obligatory cry of, " it isn't fair" of course... But I'm
>>> listening.
>> Why assume fairness on the part of members to the group given
>> that there are precious few feedback loops?
> I don't know that fairness to the degree you have in mind is
> necessary. It is simply necessary that the members are satisfied
> with the level of service.
A base problem is that you have nothing in place structurally to
prevent a Tagedy of the Commons.
Acius
Would "written from scratch" exclude LP's? I have written some
fifty-thousand odd lines of LPC code in my current project. I started by
writing the LPC boot-up sequence, and wrote everything from there ...
all the player, monster, room, grammar, etc. code is mine. Even boring
things like the file permissions and security are cut from whole cloth.
Arguably, this MUD is "stock", because it uses existing code (the LDMud
driver), and is indeed an apalling two-thirds stock (because the LDMud
driver has over 100,000 lines of code). However, the "stock" portion
consists entirely of sockets, a compiler, data-typing, database
interfacing, etc., and has hardly a shred of gameplay logic inherent in it.
There is not a significant danger of a group like this being invaded and
overtaken by "stock" MUD creators, since the huge majority of said
creators are not willing to put significant time or effort into
developing MUDs -- that's why they're working on stock codebases, and
not obsessively pouring entire weekends into redesigning game logic
(have you noticed how many people defending their use of stock code
mention time as a factor?).
It's probably still a good idea to have a minimal barrier to entry. I
suggest something like this:
You must write a clear, interesting post about a feature you have
implemented or are implementing in a MUD. This needs to be more than
three or four sentences -- a page or two will do. Discuss the usefulness
and implementation of this feature. It will be posted on the group
message boards, and people will vote it as "interesting," "stupid," or
"whatever." Get more "interesting" votes than "stupid" ones, and you're in!
This has the pleasant side effect of creating a database of essays on
current topics in MUD development, which would suit a group like this.
Proof of implementation will probably be largely inherent in the essay
-- one is able to write a lot more cogently about that which one has
attempted to implement.
Jon A. Lambert
> "Jon A. Lambert" wrote:
>
> > > > muds that are still in development, but I thought I'd put it on the
> > > > table and see what admin think.
> > > >
> membership to all comers. If you want that there are
> places on the net where this exists already ;) Whenever
> the question of a mud association is brought up on this
> NG there is going to be the obligatory cry of, " it isn't fair"
> of course... But I'm listening.
Speaking of Admins....
I'm sure you remember my MCA or Mud Community Association (or
maybe better termed mud administrators assoc. or perhaps the
association of good muds). At the time, my interest was creating
a forum of persons who actually ran games. The criteria wasn't
"originality", but simply honest, trustworthy and ethical. Yeah
simple eh. I know I spent more time on defining a members' code
of ethics than on anything else. Much of it was modeled after
the ICCA (computer consulting) codes. The basic thrust was
providing services to those who ran muds on a day to day basis,
that is admins. It wasn't a developers nor a coders association.
And likely it was and is not what you have in mind at all.
One of the services you mentioned, the pool of admins helping to
run muds... I can certainly see how it would appeal to a developer
or coder who's interest is usually NOT in running a game, but in
creating it. Tell me though, how does a group of people primarily
interested in coding and creating muds come up with a pool of
substitute admins. They certainly won't be drawing from their
own membership ranks.
I think my criteria was far broader, as all or most of the muds
I listed in my last post would have likely qualified for membership.
We still wanted to preclude the 16-year old kid who compiled Merc,
vomited it up on a server, and had 3 players, from petitioning for
membership. Either as a way to legitimize their own laziness and
lack of creativity, or as a potential siphon of talent, players,
sniPPetz and 1337 codz.
Well that was a year and a half ago. I lost interest for a number
of reasons. Time was one. I was coding on two running muds. I
was also helping out on 2 different mud server projects. I won't
even bother to mention my own server project. As if that wasn't
enough, it did attract a little too much of the anti-med and
anti-shade "crusade". Probably timing and my fault for being
identified with both.
That was NOT it's purpose though. It's purpose was to promote good
muds and foster ethics and trust between admins. Something I think
is still lacking today. If there is any interest I could probably
post the MCA stuff here. Btw, I still have your mud awards proposal
and procedures around here someplace which I thought was pretty good.
It was meant only to be elite in the sense that you were an established
mud admin and other members could reasonably be assured and could
assume by virtue of interest, declaration, reputation and by other
members staking their own judgment and word on referral that you
were a stand-up good fellow or a fine gentlewoman.
--
--* Jon A. Lambert - TychoMUD Email:jlsy...@NOSPAM.ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--
H. McDaniel
> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
> > cl...@kanga.nu wrote:
> >> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
> >>> "Jon A. Lambert" wrote:
>
> >> Its an odd thing to start forming a group by first defining who
> >> can't belong. You'd do better by being inclusive as as a group,
> >> and allow (they're going to do it anyways) individuals to be
> >> exclusive as to their associations.
>
> > The point system is used by the Writer's Guild. You can't belong
> > if you haven't produced something like a play, book or had
> > something published. Does that sound odd? It's a hell of a lot
> > better than the standard that determines who can start a mud (ie:
> > no standard at all.)
>
> A critical difference is that that is an external and objective
> criteria. None of the proposed critera have had those qualities.
Nice try, but you're wrong. You can write the best book ever but who decides
that you get published? Not an objective panel of experts, it's some reader
at a publishing house and then if you're lucky some executive who gives it
a green light based on subjective stuff. There have been cases where an
author, frustrated that his/her work was not being accepted for publication,
simply copied a famous work that had been published, put their name on
it and submitted it to see what would happen. Those get turned down to.
If objectivity ever enters into the picture it's the kind that has nothing to do
with quality (like gee this book sold 2 million copies maybe a similar one will
too.)
Maybe you consider what you do in muds to be pure science. Me, I'm
creating art. You don't prove it's correct with a ruler.
> > I don't know that fairness to the degree you have in mind is
> > necessary. It is simply necessary that the members are satisfied
> > with the level of service.
>
> A base problem is that you have nothing in place structurally to
> prevent a Tagedy of the Commons.
What would you suggest?
-McDaniel
H. McDaniel
In my own case I have and will recruit people to manage the day
to day operation of the game. Back in the old days I did manage
day to day myself but I really don't have time to do it anymore
between working insane hours for the job that puts food on the
table and trying to live life. I barely have time to code mud stuff ;)
> I think my criteria was far broader, as all or most of the muds
> I listed in my last post would have likely qualified for membership.
So that is your litmus test. In my mind I don't have a requirement that
mud X. make the cut so I don't have to think in terms of where the
muds you named might fall.
> That was NOT it's purpose though. It's purpose was to promote good
> muds and foster ethics and trust between admins. Something I think
> is still lacking today. If there is any interest I could probably
> post the MCA stuff here.
Sure, post it.
-McDaniel
cl...@kanga.nu
> cl...@kanga.nu wrote:
>> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
>>> cl...@kanga.nu wrote:
>>>> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
>>>>> "Jon A. Lambert" wrote:
>>>> Its an odd thing to start forming a group by first defining who
>>>> can't belong. You'd do better by being inclusive as as a group,
>>>> and allow (they're going to do it anyways) individuals to be
>>>> exclusive as to their associations.
>>> The point system is used by the Writer's Guild. You can't belong
>>> if you haven't produced something like a play, book or had
>>> something published. Does that sound odd? It's a hell of a lot
>>> better than the standard that determines who can start a mud (ie:
>>> no standard at all.)
>> A critical difference is that that is an external and objective
>> criteria. None of the proposed critera have had those qualities.
> Nice try, but you're wrong. You can write the best book ever but who decides
> that you get published?
Which doesn't matter. Its a discreete fact: You were published, you
were not published. Comparitive discrete facts outside of, "I have
a server listening on a port" generally don't exist in the MUD
field.
> Not an objective panel of experts, it's some reader at a
> publishing house and then if you're lucky some executive who gives
> it a green light based on subjective stuff. There have been cases
> where an author, frustrated that his/her work was not being
> accepted for publication, simply copied a famous work that had
> been published, put their name on it and submitted it to see what
> would happen. Those get turned down to. If objectivity ever
> enters into the picture it's the kind that has nothing to do with
> quality (like gee this book sold 2 million copies maybe a similar
> one will too.)
Quite, but those are not the criteria used for the Writer's Guild.
> Maybe you consider what you do in muds to be pure science. Me, I'm
> creating art. You don't prove it's correct with a ruler.
My history in the field supports itself..
>>> I don't know that fairness to the degree you have in mind is
>>> necessary. It is simply necessary that the members are satisfied
>>> with the level of service.
>> A base problem is that you have nothing in place structurally to
>> prevent a Tragedy of the Commons.
> What would you suggest?
Don't build in systemic obligations, but instead make the system a
set of communications media which allow and encourage members to
proffer services without group-obligation.
Richard Woolcock
"Acius" <redso...@hotmail.com> wrote in message
news:3CD33984...@hotmail.com...
> Richard Woolcock wrote:
>
[snip]
> > To be honest I was thinking along the lines of simply "written
> > from scratch". It might be a bit muddist, but my main interest
> > (at least at the moment) lies in discussing design issues - if
> > someone has started with an existing codebase, then they've
> > already got their game. They've skipped completely what I
> > consider to be one of the most important phases in creating a
> > good mud.
[snip]
> Would "written from scratch" exclude LP's?
Not (I imagine) if the mudlib was written from scratch - although
such a mud would skip several of the aspects of the engine design
which I'm interested in discussing with other developers.
> I have written some fifty-thousand odd lines of LPC code in my
> current project.
And I wrote slightly over 140 thousand lines of code in my old
Diku mud, but I wouldn't consider it sufficient to qualify. It's
not about how advanced the mud is, it's about following the
development lifecycle at the beginning. It's not about some sort
of "elite society" - it's about a group of people who have the
knowledge and experience of developing every aspect of their muds,
and are willing to exchange and share that knowledge with each
other.
[snip rest]
KaVir.
H. McDaniel
What percentage of mud developers would you say have the knowledge
and experience "of developing every aspect of their muds and are
willing to exchange and share knowledge with [other similar individuals]" ?
-McDaniel
cl...@kanga.nu
> "Acius" <redso...@hotmail.com> wrote in message
> news:3CD33984...@hotmail.com...
> It's not about how advanced the mud is, it's about following the
> development lifecycle at the beginning. It's not about some sort
> of "elite society" - it's about a group of people who have the
> knowledge and experience of developing every aspect of their muds,
> and are willing to exchange and share that knowledge with each
> other.
The skills and interests needed for efffective server design and
implementation tend to be different than those needed for effective
world design which are different than those needed for fine grained
social and cultural engineering which are different than those
needed for economic system design (outside of simple facuet/drain),
which are different than those needed needed for effective scripting
language design (eg used by unwashed user-programmers) and so forth.
Do you really want to restrict the group to only members of the
first set?
John Robert Arras
Richard Woolcock <Ka...@kavir.org> wrote:
>
>it's about a group of people who have the
>knowledge and experience of developing every aspect of their muds,
>and are willing to exchange and share that knowledge with each
>other.
>
I see that J.C. Lawrence is posting in this thread, and I don't mean to
step on his toes, but...
Isn't this basically what MUD-Dev does?
Could this idea be implemented as a revisiting of old threads on there,
or something along those lines? I think topics should be revisited every
few years as technology and knowledge changes to incorporate "best
practices" learned by trying things. Maybe several people could decide
to go over old topics in detail again?
Or, is the idea more of a working group for more incomplete, but
interesting ideas?
Or both or something else?
Also, how would the archives and discussions be handled? If they are
public, would someone who hasn't started from the beginning be able to
contribute if they have an amazing way to do something new and
interesting?
John
cl...@kanga.nu
> In article <ab0u2g$ghh$03$1...@news.t-online.com>,
> Richard Woolcock <Ka...@kavir.org> wrote:
>> it's about a group of people who have the
>> knowledge and experience of developing every aspect of their muds,
>> and are willing to exchange and share that knowledge with each
>> other.
> I see that J.C. Lawrence is posting in this thread, and I don't
> mean to step on his toes, but...
<bow>
> Isn't this basically what MUD-Dev does?
Partially. At one time, yes. I would like it to again but don't
believe I'm either in the position to force the issue, or that it
would be wise or in the best interests of the list to force the
issue. In many ways I now ride herd without steering.
MUD-Dev was initially founded by a gorup who were all developing and
designing their own MUD servers, and thus actively and very
pragmatically discussing their designs and considerations as they
went along. It was very much a pragmatic working list that got work
done, and that shows in the archives. Currently MUD-Dev is more
amorphous and softer edged, especially in regard to design topics.
Remember: programming MUDs has little that is unique to MUDs.
Most of the basic problem sets are well known to other fields, are
well examined and well documented. Further, the bits that are not
so well travelled technically, are generally better approached in
non-MUD area (eg scripting language design).
> Could this idea be implemented as a revisiting of old threads on
> there, or something along those lines?
Sure.
> I think topics should be revisited every few years as technology
> and knowledge changes to incorporate "best practices" learned by
> trying things. Maybe several people could decide to go over old
> topics in detail again?
One of the things I'd like to do, after I win the lottery of course,
is to go back thru the archives from the beginning and wortk
forward, replying anew to interesting messages.
> Or, is the idea more of a working group for more incomplete, but
> interesting ideas?
> Or both or something else?
> Also, how would the archives and discussions be handled? If they are
> public, would someone who hasn't started from the beginning be able to
> contribute if they have an amazing way to do something new and
> interesting?
I don't know what will happen with the current initiative. I have a
few things I'm working on for the new Kanga.Nu, MUD-Dev, and Bunyip
projects which I've spoken on briefly but don't really want to
discuss at length, if only for the facts of ease of distraction into
talking about rather than doing as well as distraction from a
current positive effort into something that's not ready to happen
yet.
On my end I'm a fan of transparency and permanent history. As such
the intent is to archive and index everything. I have my own ideas
of membership criteria for my projects, something I haven't
implemented with MUD-Dev, but they mostly center on meritocratic
ideals and tangible contributions toward the project purposes (as
verus the field or art). More simply:
Anybody can look.
Anybody can talk, elsewhere.
You have no right to speak.
You have no right to be listened to if you do speak.
You can earn the ability to speak.
You can earn the ability to grant others the same.
You can earn other abilities.
All abilities will be lost if they are not maintained.
The more you do, the more I'll support you to do further.
The problem isn't content, its intelligence, and specifically
applied intelligence. I'm still in hope of building a system which
self-selects toward that.
Jon A. Lambert
> "Jon A. Lambert" wrote:
>
> > I think my criteria was far broader, as all or most of the muds
> > I listed in my last post would have likely qualified for membership.
>
> So that is your litmus test. In my mind I don't have a requirement that
> mud X. make the cut so I don't have to think in terms of where the
> muds you named might fall.
>
Nods. I did want to point out something which may or may not be obvious
to the casual reader. The Original Mud association and this MCA thing
do indeed have different goals and purposes, and very likely appeal to
different mix of potential members. I think generally positive purposes
in their own way. I would say that JC Lawrence's Bunyip has even a
ternary purpose that of simply "supporting research and exploration".
While it's true that a few of his goals do come into alignment with
what you and Kavir have stated, where they don't he has certainly stated
so. I believe he's providing an enviroment and support for advancement
of muds, not building a formal organization. He can correct me and
will if I'm wrong there. :-P
Anyways I don't have a problem with any of them (as if it that matters
at all :-> ) as I don't view any of them as necessarily competitive nor
grossly overlapping in function.
Things of this nature are begun like mud projects I suppose. You
don't necessarily debate and come up with something perfect that
pleases everyone or anyone. Someone simply does it, runs with it,
and if anything interesting comes of it then so be it.
cl...@kanga.nu
> I would say that JC Lawrence's Bunyip has even a ternary purpose
> that of simply "supporting research and exploration". While it's
> true that a few of his goals do come into alignment with what you
> and Kavir have stated, where they don't he has certainly stated
> so. I believe he's providing an enviroment and support for
> advancement of muds, not building a formal organization. He can
> correct me and will if I'm wrong there. :-P
You are correct.
Minor addendum: I have hopes that Bunyip (which is actually the
hostname of the machine I've gotten for the purpose rather than a
project name) will extend beyond the initial development-centric
base toward a more generic set of communications media. I hope.
Its something I can plan for and want. Its also something that
will only happen if smart people step up and use it, build with it
and add the extra human values that make such a thing live. It
could happen.
Effectively its MUD-Dev all over again with a very different focus,
tho a rather shared base charter and similar baseline purpose.
> Anyways I don't have a problem with any of them (as if it that matters
> at all :-> ) as I don't view any of them as necessarily competitive nor
> grossly overlapping in function.
Quite.
I wish Bruce saw that as well with Agora.
> Things of this nature are begun like mud projects I suppose. You
> don't necessarily debate and come up with something perfect that
> pleases everyone or anyone. Someone simply does it, runs with it,
> and if anything interesting comes of it then so be it.
My father had a saying I'm fond of:
If something is worth doing it is worth doing right. If it is not
worth doing right its not worth doing.
That's actually the main lesson I've forced myself to learn in the
last few months -- especially in regard to where it both gains and
ceases applicability. I've written at least 5 replacements for the
Kanga.Nu site and list operations that have all done various new and
interesting things and have thrown every one of them out as not
satisfying some subsequently derived internal standard. Sad. Also
silly. There's a significant value to just doing something, even if
it is not perfect.
Iteration is not a Bad Thing.
In a great many ways MUD-Dev succeeded to the extent it has because
of and to the limits of its failings and imperfection. I can only
hope I do as badly this time around.
H. McDaniel
You can't get in the fricking Writer's Guild without passing somebody's
subjective test on your writing. What part of this has you confused?
> > Maybe you consider what you do in muds to be pure science. Me, I'm
> > creating art. You don't prove it's correct with a ruler.
>
> My history in the field supports itself..
I think most of us here have some history in the field. Yet, here we are
discussing something.
-McDaniel
Richard Woolcock
> Richard Woolcock wrote:
>
[snip]
> > And I wrote slightly over 140 thousand lines of code in my old
> > Diku mud, but I wouldn't consider it sufficient to qualify. It's
> > not about how advanced the mud is, it's about following the
> > development lifecycle at the beginning. It's not about some sort
> > of "elite society" - it's about a group of people who have the
> > knowledge and experience of developing every aspect of their muds,
> > and are willing to exchange and share that knowledge with each
> > other.
>
> What percentage of mud developers would you say have the knowledge
> and experience "of developing every aspect of their muds and are
> willing to exchange and share knowledge with [other similar
> individuals]" ?
My poor use of grammar implied past-tense. Allow my to rephrase,
and answer.
I would estimate that a very small percentage, probably less than 1%,
have the knowledge and experience necessary TO develop a mud from
scratch. A smaller fraction have already done so, but I doubt that
they would have so much interest in sharing that knowledge.
However for those who have the ability, but are still in the creation
process, it's been my experience that they are usually quite keen to
discuss what they've done with other developers. I've logged on to
the occasional scratch-written mud and chatted to the owner, and they
are usually happy to find someone to show off to, who can appreciate
what they've done - and also more than happy to listen to my feedback
and opinions.
However the occasional mud-coder wandering onto your mud for a chat
isn't very organised. I think that many such people would enjoy a
location where they could gather together to "show off" what they've
done, and gain feedback from each other.
KaVir.
cl...@kanga.nu
> cl...@kanga.nu wrote:
>> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
>>> cl...@kanga.nu wrote:
>>>> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
>>>>> cl...@kanga.nu wrote:
>>>>>> In alt.mud.programming H. McDaniel <cut_Xs_off_to_...@stellargenesis.com> wrote:
>>>>>>> "Jon A. Lambert" wrote:
>>>>> The point system is used by the Writer's Guild. You can't
>>>>> belong if you haven't produced something like a play, book or
>>>>> had something published. Does that sound odd? It's a hell of
>>>>> a lot better than the standard that determines who can start a
>>>>> mud (ie: no standard at all.)
>> Which doesn't matter. Its a discreete fact: You were published,
>> you were not published. Comparitive discrete facts outside of,
>> "I have a server listening on a port" generally don't exist in
>> the MUD field.
>>> Not an objective panel of experts, it's some reader at a
>>> publishing house and then if you're lucky some executive who
>>> gives it a green light based on subjective stuff. There have
>>> been cases where an author, frustrated that his/her work was not
>>> being accepted for publication, simply copied a famous work that
>>> had been published, put their name on it and submitted it to see
>>> what would happen. Those get turned down to. If objectivity
>>> ever enters into the picture it's the kind that has nothing to
>>> do with quality (like gee this book sold 2 million copies maybe
>>> a similar one will too.)
>> Quite, but those are not the criteria used for the Writer's Guild.
> You can't get in the fricking Writer's Guild without passing
> somebody's subjective test on your writing. What part of this has
> you confused?
You're making two mistakes, first you're looking for absolute
objectivism (which is a fallacy in its own statement), and second
you're ignoring the simplicity of the fact that publication is a
discrete fact which exists outside of the control and decision
framework what forms the Writer's Guild. Think about it in
relativistic terms. It really is quite simple. The fact that the
decision to publish or not was subjective has no relevance -- it
wasn't a decision made by the Writer's Guild, made with Writer's
Guild resources, or within the Writer's Guild semantics.
Effectively, in a relativistic sense, the Writer's Guild and
publication are discrete and disjoint systems and thus are not
mutually relevant.
Of course people don't generally view the two systems that way, but
that's a different and human foible. It doesn't change the fact
that the systems are discrete and thus puublication is objective to
the Writer's Guild -- no matter how much interest the Writer's Guild
may take in it.
>>> Maybe you consider what you do in muds to be pure science. Me, I'm
>>> creating art. You don't prove it's correct with a ruler.
>> My history in the field supports itself.
> I think most of us here have some history in the field. Yet, here
> we are discussing something.
<shrug> Then it matters not, no?
Richard Woolcock
> In alt.mud.programming Richard Woolcock <Ka...@kavir.org> wrote:
> > "Acius" <redso...@hotmail.com> wrote in message
> > news:3CD33984...@hotmail.com...
>
> > It's not about how advanced the mud is, it's about following the
> > development lifecycle at the beginning. It's not about some sort
> > of "elite society" - it's about a group of people who have the
> > knowledge and experience of developing every aspect of their muds,
> > and are willing to exchange and share that knowledge with each
> > other.
>
> The skills and interests needed for efffective server design and
> implementation tend to be different than those needed for effective
> world design which are different than those needed for fine grained
> social and cultural engineering which are different than those
> needed for economic system design (outside of simple facuet/drain),
> which are different than those needed needed for effective scripting
> language design (eg used by unwashed user-programmers) and so forth.
>
> Do you really want to restrict the group to only members of the
> first set?
I'm not attempting to define the rules for this Association, I'm just
defining what *I personally* am interested in. However I would say
that the other aspects you mention are already covered by MUD-DEV -
that's the place I go for general high signal/low noise discussions
of general advanced mud concepts. What I'm interested in here is
something more specialised and more personal.
KaVir.
cl...@kanga.nu
> <cl...@kanga.nu> wrote in message news:el61ba...@kanga.nu...
>> The skills and interests needed for effective server design and
>> implementation tend to be different than those needed for
>> effective world design which are different than those needed for
>> fine grained social and cultural engineering which are different
>> than those needed for economic system design (outside of simple
>> faucet/drain), which are different than those needed needed for
>> effective scripting language design (eg used by unwashed
>> user-programmers) and so forth.
>> Do you really want to restrict the group to only members of the
>> first set?
> I'm not attempting to define the rules for this Association, I'm
> just defining what *I personally* am interested in.
<nod> There's an apparent problem with equating individual
preferences with group mandate.
> However I would say that the other aspects you mention are already
> covered by MUD-DEV - that's the place I go for general high
> signal/low noise discussions of general advanced mud concepts.
<bow>
> What I'm interested in here is something more specialised and more
> personal.
Likewise, especially WRT the latter.
H. McDaniel
Nowhere in this thread have I been "looking for absolute
objectivism".
> (which is a fallacy in its own statement), and second
> you're ignoring the simplicity of the fact that publication is a
> discrete fact which exists outside of the control and decision
> framework what forms the Writer's Guild.
\
I'm trying to ignore everything that isn't relevant to the subject
at hand.
-McDaniel
cl...@kanga.nu
> Nowhere in this thread have I been "looking for absolute
> objectivism".
It was the only reasonable explanation I arrived at to explain your
insistance that publication was not an externally discrete fact but
was subjective.
>> (which is a fallacy in its own statement), and second
>> you're ignoring the simplicity of the fact that publication is a
>> discrete fact which exists outside of the control and decision
>> framework what forms the Writer's Guild.
> I'm trying to ignore everything that isn't relevant to the subject
> at hand.
Yet you are drawing structural parallels to the Writer's Guild while
ignoring the basic structures that form the Writer's Guild?
Dennis Towne
>
> "H. McDaniel" <cut_Xs_off_to_...@stellargenesis.com> wrote in
> message news:3CD4177F...@stellargenesis.com...
> > Richard Woolcock wrote:
> >
>
> [snip]
>
> > > And I wrote slightly over 140 thousand lines of code in my old
> > > Diku mud, but I wouldn't consider it sufficient to qualify. It's
> > > not about how advanced the mud is, it's about following the
> > > development lifecycle at the beginning. It's not about some sort
> > > of "elite society" - it's about a group of people who have the
> > > knowledge and experience of developing every aspect of their muds,
> > > and are willing to exchange and share that knowledge with each
> > > other.
> >
> > What percentage of mud developers would you say have the knowledge
> > and experience "of developing every aspect of their muds and are
> > willing to exchange and share knowledge with [other similar
> > individuals]" ?
*raises hand*
> My poor use of grammar implied past-tense. Allow my to rephrase,
> and answer.
>
> I would estimate that a very small percentage, probably less than 1%,
> have the knowledge and experience necessary TO develop a mud from
> scratch. A smaller fraction have already done so, but I doubt that
> they would have so much interest in sharing that knowledge.
Having gone through it myself, I'd say that the percentage is a -lot-
higher; there are a lot of people with the knowledge and experience to
write a mud from scratch. The barriers to creation really just don't
look that tall to me. What's the real killer is the huge amount of time
involved, and I think that's what ends most scratch development efforts.
[snip]
> However the occasional mud-coder wandering onto your mud for a chat
> isn't very organised. I think that many such people would enjoy a
> location where they could gather together to "show off" what they've
> done, and gain feedback from each other.
rec.games.mud.*. We already have our discussion forum, and we're
discussing on it right now.
As for showing off and gaining feedback, it turns out I have so much
shit to implement right now anyway that I'm actively not looking for
ideas - perhaps why I'm not real active on this list. I'd be more than
happy to describe how I've done certain things, and have even done so in
the past, but it seems that the things I have to talk about are less
interesting than usual :)
(I think most of the innovations in AA have been player administration
based - things to remove the overhead of dealing with trivial shit from
the admins. Not many people are interested in this, even though it does
help to take load off of the admin staff and leave them more time to
build.)
-dennis T
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alter Aeon Multiclass Mud - Beware The Hill Giants!
http://dentinmud.org/alter, telnet://xirr.com:3000
Dennis Towne
[snip]
> > How do you define "original"?
>
> [snip]
>
> To be honest I was thinking along the lines of simply "written
> from scratch". It might be a bit muddist, but my main interest
> (at least at the moment) lies in discussing design issues - if
> someone has started with an existing codebase, then they've
> already got their game. They've skipped completely what I
> consider to be one of the most important phases in creating a
> good mud.
>
> However you've made me think now (I hate it when that happens!).
> What if someone creates a mud from scratch - by hacking it all
> together? Or what if they write a mud from scratch which is
> designed to work in the same way as an existing mud (eg a Diku)?
Very good question, and one that would be very important for me. I've
been told many times that 'this looks just like a Diku' or 'why don't
you credit the diku team'. I even post the occasional ad listing my mud
as 'Diku like'. Mind you the internals are all completely different,
but the only real obvious sign that it's not a Diku is the way fighting
works.
Even now, when I think about it, there's only one thing that I have done
that would be difficult to do on a Diku code base.
I guess my point is that perhaps its best to toss out the 'original'
requirement, and simply say you want to talk to competent mud coders.
Personally, I think you get true competence from writing from scratch -
not so much because you're putting together the fundamental data
structures, but because your mistakes force you to think about all the
'what ifs' along the way. Others will have their definitions of course,
but saying 'you must have written a mud from scratch' might be a good
first level filter.
Lars Duening
> I guess my point is that perhaps its best to toss out the 'original'
> requirement, and simply say you want to talk to competent mud coders.
> Personally, I think you get true competence from writing from scratch -
Of course, to make it truly 'from scratch' you'd have to start with
re-inventing the universe.
--
Lars Duening; la...@bearnip.com
PGP Key: http://www.bearnip.com/lars/pgp-lars.asc
Lars Duening
> > To be honest I was thinking along the lines of simply "written
> > from scratch". It might be a bit muddist, but my main interest
> > (at least at the moment) lies in discussing design issues - if
> > someone has started with an existing codebase, then they've
> > already got their game. They've skipped completely what I
> > consider to be one of the most important phases in creating a
> > good mud.
> [...]
> I guess my point is that perhaps its best to toss out the 'original'
> requirement, and simply say you want to talk to competent mud coders.
> Personally, I think you get true competence from writing from scratch -
> not so much because you're putting together the fundamental data
> structures, but because your mistakes force you to think about all the
> 'what ifs' along the way.
What a load of crap. Designing a mud well has nothing to do with whether the
implementation starts from scratch or from an existing codebase. Writing a mud
from scratch only guarantees that the creator will spend a lot of time
re-solving long-solved problems instead of working on their new, original
stuff.
Blane Bramble
news:slrnadfsh...@needa.bearnip.com...
> > requirement, and simply say you want to talk to competent mud coders.
> > Personally, I think you get true competence from writing from scratch -
> > not so much because you're putting together the fundamental data
> > structures, but because your mistakes force you to think about all the
> > 'what ifs' along the way.
>
> What a load of crap. Designing a mud well has nothing to do with whether
the
> implementation starts from scratch or from an existing codebase. Writing a
mud
> from scratch only guarantees that the creator will spend a lot of time
> re-solving long-solved problems instead of working on their new, original
> stuff.
Although your first point is valid, in your own words, your second is a load
of crap :-)
Blane.
Jonathan L. Potter
/snip
> You can't get in the fricking Writer's Guild without passing somebody's
> subjective test on your writing. What part of this has you confused?
/snip
Out of curiousity, you have to be published to get in, right? So, if you
publish something yourself, you can still get in?
--
Snafu Life.
Shoddy-Hack Artists for Life.
01000101 -- Go ahead take a byte ;)
Richard Woolcock
Writing a mud from scratch ensures that the implementation fits the
design, and not the other way around. I can stick wings on a car and
eventually turn it into an aeroplane, and save reintenting several parts
of it (such as the engine and wheels), or I could start from scratch.
There are numerous advantages to be gained from starting from scratch,
but if you're ONLY going to reinvent the wheel then I'd agree there
isn't much point in doing so. Having previously written both a ~170K
line Diku/Merc derived mud as well a ~7K line scratch-written mud, I've
had a taste for both, and I know that for what I'm doing now it's much
easier to start from scratch.
KaVir.
H. McDaniel
>
> "H. McDaniel" <cut_Xs_off_to_...@stellargenesis.com> wrote in
> message news:3CD462C3...@stellargenesis.com...
>
> /snip
> > You can't get in the fricking Writer's Guild without passing somebody's
> > subjective test on your writing. What part of this has you confused?
> /snip
>
> Out of curiousity, you have to be published to get in, right? So, if you
> publish something yourself, you can still get in?
It isn't that simple. There are various conditions. Basically if
somebody really wants to get in, they will find a way. But the
points will somewhat relate to how big of a contribution the
author is making to the *commerical publishing* world.
-McDaniel
Dennis Towne
Lars, I totally agree with you regarding implementation, but that was
not the point. I will also personally attest to the fact that the
creator will resolve long-solved problems instead of working on new,
original stuff. But again, that is not the point.
The fact is that in the course of writing a code base from scratch, an
implementor is going be forced to deal with many pitfalls and problems
that he or she probably wouldn't have been aware of otherwise. This
translates directly into a broad competence and depth of experience that
not all implementors will have. If you are looking for a filter to
detect people with comprehensive knowledge, having implemented a scratch
mud seems like a good one.
-dennis T
(As a side note, I don't really believe your assertion. My experience
was that yes, I did have to reinvent the wheel several times, but in the
grand scheme of things I did much more solving of new problems than
resolving old ones. And for the most part, now that I know the
internals and capabilities of stock bases, I'd go so far as to say that
all the difficult problems aren't addressed in them anyway. In short,
the only things you have to reinvent when starting from scratch are the
trivial things: lists, file load/save, area loading, etc.
The really difficult things are the ones where solutions are built up
over time, and for that the stock bases simply aren't of any help. Take
for example the ever present issue of annoyance characters. How many
different ways are there to automatically deal with channel spammers and
annoyance characters? How many code bases have support for this by
default? In how many of those code bases is that support actually
effective?
Then there are other things that would have had to be reimplemented
anyway - take for example spellcasting. The system on AA looks very
similar to that in a stock diku - but for a diku to duplicate everything
my spellcasting system does, you might as well start over. It wouldn't
be worth the effort.)
H. McDaniel
Yes, OTOH I don't think anybody in this thread suggested that they wanted an
association just for people with comprehensive mud [coding] knowledge.
Correct me if I'm wrong -- I could be.
-McDaniel
Joshua Uyehara
If the implementation of the codebase itself imposes limitations on the
creative design of the MUD, the codebase, IMHO, is either broken due to bad
design, or deliberately sacrificing flexibility for one reason or another.
A codebase that imposes limitations on the creative design of the game is
analogous to an OS that limits the types of programs that will run on it.
Sometimes (as in the case of Diku & derivatives) this is done as a
deliberate design decision to facilitate ease-of-administration or enhanced
performance under hardware resource limitations at the expense of
flexibility. True, trying to start a new and original MUD from a cookie
cutter codebase is harder than writing one from scratch, but there are a
handful of powerful and flexible codebases that will more than meet any
needs you may have.
Josh
Joshua Uyehara
online.com:
IMHO, if the implementation limits the creative design, then the codebase
is either A) broken by bad design, or B) deliberately sacrificing
flexibility for some other gains. type A inflexible codebases have mostly
been weeded out and are self-regulating (at least to my knowledge, as very
few MUDs that I know of use a codebase that I would consider type A). Type
B, what I like to call "cookie cutter" codebases (due to their tendency to
spawn countless clone MUDs) such as Diku and derivatives, sacrifice
flexibility and design freedom in return for ease-of-administration,
performance under hardware resource limitations, or something similar. A
good codebase doesn't attempt to dictate any of the design decisions to
you, but, rather, provides you with a useful and powerful set of tools that
will enable you to implement your design quickly and elegantly in a manner
that is easy to maintain and extend. There are a handful of codebases out
there that will allow you to implement whatever it is that you're hoping to
do. Writing a scratch MUD for any OS for which a port of a codebase that
implements a turing complete stackmachine (ie afaik ldmud, MUDOS, lpmud,
Genesis) is a big waste of time.
--
======================================
Joshua Uyehara
uye...@NOSPAM.fas.harvard.edu
jiles@dartmud
======================================
Dennis Towne
[snip]
> There are a handful of codebases out
> there that will allow you to implement whatever it is that you're hoping to
> do. Writing a scratch MUD for any OS for which a port of a codebase that
> implements a turing complete stackmachine (ie afaik ldmud, MUDOS, lpmud,
> Genesis) is a big waste of time.
Completely false. What you are saying is roughly equivalent to 'since C
is turing complete, anyone who writes a compiler for a different
language on a platform that already has a C compiler is wasting their
time'. Or how about 'since vi is a complete editor, no-one should ever
need to write a different one'?
The fact of the matter is that different code bases have different
characteristics, and it's entirely possible that there is no existing
codebase that has the characteristics wanted regardless of how turing
complete it is. Take for example a code base that is turing complete,
but only has interfaces to use the equivalent of assembly language -
sure, you can write anything you want in it, but that doesn't mean it's
going to be fun and/or easily maintainable. And by the time you write a
better interface layer on top of it, you could have done some real
design work from the ground up and perhaps come up with something better
and more original.
In other words, a code base simply may not suit what I think my purposes
are, and that alone can be enough to make it worth my time to design and
construct a new one. It's not real hard to do anyway.
-dennis T
Marc Bowden
Duening) wrote:
>
> Of course, to make it truly 'from scratch' you'd have to start with
> re-inventing the universe.
Shhh! You're going to make Kavir mad again if you keep talking about his
secret projects!
--
Marc Bowden - Soulsinger Dreamshadow:The Legacy of the Three
ry...@merit.edu 209.48.36.2 3333
Richard Woolcock
news:3CE15898...@xirr.com...
> Joshua Uyehara wrote:
>
> [snip]
>
> > There are a handful of codebases out
> > there that will allow you to implement whatever it is that you're
> > hoping to do. Writing a scratch MUD for any OS for which a port
> > of a codebase that implements a turing complete stackmachine (ie
> > afaik ldmud, MUDOS, lpmud, Genesis) is a big waste of time.
>
> Completely false.
Indeed it is, but I often hear it spouted at me by the LP advocates,
and when I point out the numerous reasons why I don't WANT to use
LPC they get really pouty at me, so I'd really rather not go there
again (despite being all warm and fuzzy from having won a flamewar
earlier today, after my opponent invoked Godwin's Law on me).
Suffice to say that, having carefully considered the various options
available, my team and I are creating our mud from scratch in C++ -
and we certainly don't consider it a "big waste of time".
KaVir.
Blane Bramble
news:abrufj$nr8$05$1...@news.t-online.com...
> "Dennis Towne" <soda....@xirr.com> wrote in message
> news:3CE15898...@xirr.com...
> > Joshua Uyehara wrote:
> >
> > [snip]
> >
> > > There are a handful of codebases out
> > > there that will allow you to implement whatever it is that you're
> > > hoping to do. Writing a scratch MUD for any OS for which a port
> > > of a codebase that implements a turing complete stackmachine (ie
> > > afaik ldmud, MUDOS, lpmud, Genesis) is a big waste of time.
> >
> > Completely false.
>
> Indeed it is, but I often hear it spouted at me by the LP advocates,
> and when I point out the numerous reasons why I don't WANT to use
> LPC they get really pouty at me, so I'd really rather not go there
> again (despite being all warm and fuzzy from having won a flamewar
> earlier today, after my opponent invoked Godwin's Law on me).
>
You *will* use LPC or you *will* be shot. Please choose your own favourite
accent for this.
> Suffice to say that, having carefully considered the various options
> available, my team and I are creating our mud from scratch in C++ -
> and we certainly don't consider it a "big waste of time".
>
Pah! I consider almost everything I write a big waste of time. But it's my
time I'm wasting, and I enjoy wasting it in this fashion, so why not?
Blane.
Blane Bramble
news:Xns920ED3C41334uy...@209.249.90.101...
Yes, I'm sure this is true of some codebases - the first time you do
something it's often not the best design.
> or B) deliberately sacrificing
> flexibility for some other gains.
If you are writing a codebase for a specific game, then this too tends to
happen.
>type A inflexible codebases have mostly
> been weeded out and are self-regulating (at least to my knowledge, as very
> few MUDs that I know of use a codebase that I would consider type A).
Type
> B, what I like to call "cookie cutter" codebases (due to their tendency to
> spawn countless clone MUDs) such as Diku and derivatives, sacrifice
> flexibility and design freedom in return for ease-of-administration,
> performance under hardware resource limitations, or something similar.
I would say that any codebase probably falls into case B - there are
trade-offs with any software design, and it is very difficult to know which
ones are important for someone elses purposes. A design trade-off that makes
sense for your game, might cripple mine.
> A
> good codebase doesn't attempt to dictate any of the design decisions to
> you, but, rather, provides you with a useful and powerful set of tools
that
> will enable you to implement your design quickly and elegantly in a manner
> that is easy to maintain and extend. There are a handful of codebases out
> there that will allow you to implement whatever it is that you're hoping
to
> do.
Are there? Can you truly state that some of the codebases are capable of
implementing, efficiently, any possible ideas a MUD creator might have. I
wouldn't like to bet on it - yes they might be capable of implementing any
idea, but efficiently is another matter.
> Writing a scratch MUD for any OS for which a port of a codebase that
> implements a turing complete stackmachine (ie afaik ldmud, MUDOS, lpmud,
> Genesis) is a big waste of time.
>
Freedom of choice? Challenging project? Custom design for better efficiency
for your own game? New ideas that are difficult to implement given the
assumptions in an existing system?
Are these all a waste of time too? Why do we need more than one codebase
given this statement? And, if everyone thought this way, there would be very
little progress in computing in general - revolution tends to make larger
bounds than evolution in this case.
Blane.
Blane Bramble
news:Xns920E75A9EAADuy...@209.249.90.101...> >
>
> True, trying to start a new and original MUD from a cookie
> cutter codebase is harder than writing one from scratch, but there are a
> handful of powerful and flexible codebases that will more than meet any
> needs you may have.
>
I disagree - it is easier to create a non original MUD from a cookie cutter
codebase, not harder to create an original one. With so many players having
an end goal of "I want to run a MUD" rather than "I want to create a world
like so" they take the easy option to a functioning game, and achieve their
goal. Sadly, that goal is not to create a unique world, and so having not
set out to do this, it is not suprising that they don't achieve it.
Blane.
Mystran the Dark-Elf
>
> [snip]
>
> > There are a handful of codebases out
> > there that will allow you to implement whatever it is that you're hoping
to
> > do. Writing a scratch MUD for any OS for which a port of a codebase
that
> > implements a turing complete stackmachine (ie afaik ldmud, MUDOS, lpmud,
> > Genesis) is a big waste of time.
>
> Completely false. What you are saying is roughly equivalent to 'since C
> is turing complete, anyone who writes a compiler for a different
> language on a platform that already has a C compiler is wasting their
> time'. Or how about 'since vi is a complete editor, no-one should ever
> need to write a different one'?
I agree.. if every thought like that we wouldn't have C++ and vim.
I could still do what I do, I could do the same with C I do in C++, and I
could use vi to do what I do in vim, but I would have to implement all the
C++ features I need over C (like all STL stuff) myself, and if would be much
more waste of time than invention of C++ was.
To reduce the waste of time however, it should be noticed, that the
resulting product should solve some problem in the other alternatives.
Writing a diku clone that works internally almost exactly like diku sure is
waste of time when you could just modify diku, but if you can gain something
from starting from the OS level (inventing the universe probably isn't
useful) might be a good idea. There is no ultimate answer however, as some
projects would benefit from existing codebases, and some won't. You can code
a mud on DOS after all, but somebody still created Windows, BSD and Linux
(and other OS's) so we wouldn't have to. Still, there are lots of OS
projects after all, that try to overcome the limitations in the current
implementations.
> The fact of the matter is that different code bases have different
> characteristics, and it's entirely possible that there is no existing
> codebase that has the characteristics wanted regardless of how turing
> complete it is. Take for example a code base that is turing complete,
> but only has interfaces to use the equivalent of assembly language -
> sure, you can write anything you want in it, but that doesn't mean it's
> going to be fun and/or easily maintainable. And by the time you write a
> better interface layer on top of it, you could have done some real
> design work from the ground up and perhaps come up with something better
> and more original.
Exactly.
> In other words, a code base simply may not suit what I think my purposes
> are, and that alone can be enough to make it worth my time to design and
> construct a new one. It's not real hard to do anyway.
There are few things that are ugly actually.. checking who are those people
that need to receive a message can be a pain, if you don't want to check
everything for the whole list of players forexample.. another thing is
making a decent parser, which IMO is also pretty hard with any existing
codebase i've seen. (and yes I've seen lp and mudos)
Also most current MUD codebases are so strictly room based that making
forexample a tilebased map (where there can be one player per tile) is
pretty hard.. if you don't want to make the whole map into one room that is
:)
- Mystran
Richard Woolcock
news:ac0sba.p8e.ln@backup...
> "Joshua Uyehara" <uye...@fas.harvard.edu> wrote in message
> news:Xns920E75A9EAADuy...@209.249.90.101...> >
> >
> > True, trying to start a new and original MUD from a cookie
> > cutter codebase is harder than writing one from scratch, but
> > there are a handful of powerful and flexible codebases that
> > will more than meet any needs you may have.
> >
>
> I disagree - it is easier to create a non original MUD from a
> cookie cutter codebase, not harder to create an original one.
[snip]
It depends what you're trying to do. If your "original features"
require the removal of the majority of the codebase, then you'll
almost definitely find it easier to start from scratch. In my Diku,
for example, I rewrote more and more of the combat system, then
eventually just scrapped the lot and rewrote it (it follows the White
Wolf combat system, not the D&D one). Equally it doesn't use areas -
it has a single huge world with automated dynamic descriptions. The
skill and magic systems are no longer used (although there are still
unused chunks floating around). I could go on - but in short, it
would have been easier if I had just started from scratch (although I
learned a lot, so I don't consider it a loss - but creating a new mud
now, I wouldn't start with a Diku unless it was already designed in
exactly the way I wanted).
KaVir.
H. McDaniel
> There are a handful of codebases out
> there that will allow you to implement whatever it is that you're hoping to
> do. Writing a scratch MUD for any OS for which a port of a codebase that
> implements a turing complete stackmachine (ie afaik ldmud, MUDOS, lpmud,
> Genesis) is a big waste of time.
Your time must be more valuable than mine. And believe me, I stopped working
fast food a LONG time ago.
-McDaniel
Jon A. Lambert
> "Joshua Uyehara" <uye...@NOSPAM.fas.harvard.edu> wrote in message
> news:Xns920ED3C41334uy...@209.249.90.101...
> > been weeded out and are self-regulating (at least to my knowledge, as very
> > few MUDs that I know of use a codebase that I would consider type A).
> Type
> > B, what I like to call "cookie cutter" codebases (due to their tendency to
> > spawn countless clone MUDs) such as Diku and derivatives, sacrifice
> > flexibility and design freedom in return for ease-of-administration,
> > performance under hardware resource limitations, or something similar.
>
> I would say that any codebase probably falls into case B - there are
> trade-offs with any software design, and it is very difficult to know which
> ones are important for someone elses purposes. A design trade-off that makes
> sense for your game, might cripple mine.
Actually I think that's a good general categorization that Joshua came
up with. MOO, Cold and LP are type C's. From a game designers standpoint
they are simply programmable network servers that happen to have a lot
of builtin functions that are useful for those designing muds. They
are environments that encapsulate a language compiler/interpreter, networking
and database (althought I'm not sure persistence is standard on all LPs).
There are other things that are very similar and would classify as generic
programmable network platforms. The whole Java environment or the #Net
framework for instance. Someone designing a mud for an LP, MOO, or Cold
has almost as much flexibility with content, game system, and game type as
the guy opening a vi console and starting at the beginning with main().
I would suggest that they are many many months or years ahead because they
don't have to worry about low level routines that have little or nothing
to do with the "game". In other words a mud author doesn't need to
jack about network programming, database programming, compiler and vm
construction and various other odd skillsets in order to design an
original mud. The problem with your type A and B servers is in order
to muck with the game you need to know a lot more than just game design
or game programming. On the other hand a lot of these type C servers
are running type B or stock mud libs. So the cookie cutter template
thing works both ways. There are indeed TMI or Lima clones.
Anyways the coding from scratch thing has always struck me as silly.
It's sort of similar to those pissing contests between programmers
who use a low level language vs. those who use a high level language
over who is the real programmer. And there's also this "not invented
here" syndrome too. I could advance the notion that perhaps they
aren't writing muds from scratch anyways since they are in fact
being lazy and using stock operating systems and stock C language
libraries. Real men with hairy chests (and real women with heaving
bosums) would of course write their from scratch mud starting with
writing an operating system that is customized to run muds.
In any case writing from scratch isn't any guarantee of originality.
Sure from a legal or IP view it's original. But from a game players
view is it? I mean I've logged into LPs, Dikus and from scratch
servers and seen the same old D&D style hack-n-slash game being
played. Now from a pendantic view nothing is original. On the
other hand original is more often a synthesis of old in a new way.
For example, since Kavir is on this thread consider GodWars.
He doesn't think it was original. I do. Perhaps it's in our
definitions. Sure it was based on Merc, not original. Sure it
was based on a White Wolf game, not original. On the other hand
it sure was one hell of a perversion of the WOD style being
played in the Mush world at the time and at people's kitchen
tables. ;-) So the synthesis of PK, WOD, and Merc together
made it a rather original game. And that's without mentioning
specific features, just conceptually an original synthesis.
Is it still original? Well there's maybe a dozen or so of them
running so yes originality is a temporal thing as well. Diku
is original all 1000 of running are pretty much original copies.
:-P
The bottom line from a players view is that they are having fun
playing it. And I have the feeling that has less to do with the
game being original in any sense of the word but more to do with
the other people they are playing with. I mean thats why MUDS
are more fun than SUDS. And even an unoriginal DUD MUD can be a
hell of a lot more fun than an original SUD.
The bottom line from a programmers, designers or artists view is
that they are having fun doing their thing.
I don't think those two views are necessarily convergent nor
do I think there is any reason in the world they ought to be.
--
--* Jon A. Lambert - TychoMUD Email:jlsy...@NOSPAM.ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--
Miroslav Silovic
> Anyways the coding from scratch thing has always struck me as silly.
> It's sort of similar to those pissing contests between programmers
> who use a low level language vs. those who use a high level language
> over who is the real programmer. And there's also this "not invented
> here" syndrome too. I could advance the notion that perhaps they
> aren't writing muds from scratch anyways since they are in fact
> being lazy and using stock operating systems and stock C language
> libraries. Real men with hairy chests (and real women with heaving
> bosums) would of course write their from scratch mud starting with
> writing an operating system that is customized to run muds.
May I also suggest Type D MUDs: Written from scratch without using
a general purpose network server, but using general purpose libraries
whenever necessary? If done right, they won't sacrifice flexibility
(mind you, I don't consider online coding to be a must for a flexible
MUD project - central CVS with automatic build/reinstall/reboot sequence
and a test site on each developer's local machine is even nicer in
some ways - like availability of real debugging tools).
In particular, a C++ scratch MUD project practically begs using
things like ACE, Boost, CommonC++, libXML, libXSLT etc. And Java
scratch MUD with Java standard libraries would be another example
(I just wouldn't consider it Cold/LP/MOO-like system). Once you
include these in your project, you're not much worse off than
starting off from, say, Cold.
As for the 'why' side of things: None of the codebases mentioned
in this thread support kernel-level multithreading. This means
that throwing more than one CPU on your server buys no real gain.
None support true optimising compilation (although dgd has some
right ideas in that direction). And fallback to C to gain performance
tends to be unwieldy with Cold and MOO (I don't know about LP).
So none of the C-type MUDs will do well for computationally intensive
MUD (either because of the large number of users, or bots, or
demanding AI).
Miro
Joshua Uyehara
[snip]
> Completely false. What you are saying is roughly equivalent to 'since
> C is turing complete, anyone who writes a compiler for a different
> language on a platform that already has a C compiler is wasting their
> time'.
Wrong, and your examples merely reinforce my point. Programming languages
are developed either as enhancements to existing languages a la BCPL->B->C,
specialized to take advantage of a different software development
paradigm/problem set (lisp, fortran, perl), or a combination of both (Ruby,
Python, objective C, C++, Java, C# and all that .net crap). No languages
are written merely to duplicate the functionality of an existing language,
but neither do they try to reinvent the wheel.
>Or how about 'since vi is a complete editor, no-one should ever need to
>write a different one'?
If your needs differ sufficiently from what vi offers, then by all means,
write a new editor. Vi is modal, has no multiple buffer capabilities, and
it was designed from the ground up for use over pre-X11 terminal
conections. If you need similar capabilities, or want to take advantage of
new technology, you start with vi, and tweak it to your liking (VIM, gVim).
Starting from scratch is wasting your time. If and only if your needs
differ so much that vi shares no non-trivial functionality that could be
easily ported, you start from scratch.
> The fact of the matter is that different code bases have different
> characteristics, and it's entirely possible that there is no existing
> codebase that has the characteristics wanted regardless of how turing
> complete it is. Take for example a code base that is turing complete,
> but only has interfaces to use the equivalent of assembly language -
> sure, you can write anything you want in it, but that doesn't mean
> it's going to be fun and/or easily maintainable. And by the time you
> write a better interface layer on top of it, you could have done some
> real design work from the ground up and perhaps come up with something
> better and more original.
That example is complete bull. Only an idiot would design a toolset that
makes it harder to complete the target problem. Take a look at a codebase
that implements a turing complete stackmachine and then tell me again how
it would be easier/better to write 100k+ lines of code from scratch when
you could spend a few hours at most studying the bison grammar spec,
letting you add whatever it is you thought was missing.
> In other words, a code base simply may not suit what I think my
> purposes are, and that alone can be enough to make it worth my time to
> design and construct a new one. It's not real hard to do anyway.
>
> -dennis T
Then you've never actually taken the time to look at the codebases that are
out there.
Joshua Uyehara
> "Joshua Uyehara" <uye...@NOSPAM.fas.harvard.edu> wrote in message
> news:Xns920ED3C41334uy...@209.249.90.101...
>> "Richard Woolcock" <Ka...@kavir.org> wrote in
>> news:ab9e8r$2ul$07$1@news.t- online.com:
[snip]
>> Writing a scratch MUD for any OS for which a port of a codebase that
>> implements a turing complete stackmachine (ie afaik ldmud, MUDOS,
>> lpmud, Genesis) is a big waste of time.
>>
>
> Freedom of choice? Challenging project? Custom design for better
> efficiency for your own game? New ideas that are difficult to
> implement given the assumptions in an existing system?
>
> Are these all a waste of time too? Why do we need more than one
> codebase given this statement? And, if everyone thought this way,
> there would be very little progress in computing in general -
> revolution tends to make larger bounds than evolution in this case.
>
> Blane.
>
>
I agree wholeheartedly that writing a codebase from scratch is a good
project for learning some basic network protocol (or at least how to use
the existing libs), and some of the fundamental problems involved with
creating a MUD. I disagree, however, that advances are not made in the
manner I've stated. Almost all major advances tend to be improvements on
existing ideas, such as programming languages and computer interfaces. If
people did not make use of existing works, and opted to start from scratch,
we wouldn't have vim, emacs, linux, X11, gnome, cvs, or, ms windows, ms
office etc. I have yet to see a MUD that is fundamentally revolutionary in
its implementation, or one that couldn't have been easily implemented in
LPC, with the sole exception of graphical MUDs.
Dennis Towne
[snip]
> > In other words, a code base simply may not suit what I think my
> > purposes are, and that alone can be enough to make it worth my time to
> > design and construct a new one. It's not real hard to do anyway.
> >
> > -dennis T
>
> Then you've never actually taken the time to look at the codebases that are
> out there.
Fine, you win the argument through brute force. Have fun in your little
LP mud world.
-dennis T
Blane Bramble
> > characteristics, and it's entirely possible that there is no existing
> > codebase that has the characteristics wanted regardless of how turing
> > complete it is. Take for example a code base that is turing complete,
> > but only has interfaces to use the equivalent of assembly language -
> > sure, you can write anything you want in it, but that doesn't mean
> > it's going to be fun and/or easily maintainable. And by the time you
> > write a better interface layer on top of it, you could have done some
> > real design work from the ground up and perhaps come up with something
> > better and more original.
>
> That example is complete bull. Only an idiot would design a toolset that
> makes it harder to complete the target problem. Take a look at a codebase
> that implements a turing complete stackmachine and then tell me again how
> it would be easier/better to write 100k+ lines of code from scratch when
> you could spend a few hours at most studying the bison grammar spec,
> letting you add whatever it is you thought was missing.
>
I was writing a game to run under DOS (this was in 1988 or thereabouts). I
had to use LIM/EMS memory to allow me to address > 640kb. This meant I had
to use a memory paging scheme. It was easier to write a codebase and
language from scratch that took this into consideration than to try and
shoe-horn an existing grammer into the limitations I had to live with. By
controlling the language, I could make the limitations of the OS have as
little impact as possible.
> > In other words, a code base simply may not suit what I think my
> > purposes are, and that alone can be enough to make it worth my time to
> > design and construct a new one. It's not real hard to do anyway.
> >
>
> Then you've never actually taken the time to look at the codebases that
are
> out there.
>
Why would you say that? Because your favourite codebase does what you need,
doesn't mean that it's true for everyone. Let me ask this, it is possible to
write any program in C. So why does LISP exist?
Blane.
H. McDaniel
> That example is complete bull. Only an idiot would design a toolset that
> makes it harder to complete the target problem. Take a look at a codebase
> that implements a turing complete stackmachine and then tell me again how
> it would be easier/better to write 100k+ lines of code from scratch when
> you could spend a few hours at most studying the bison grammar spec,
> letting you add whatever it is you thought was missing.
It depends on what you're trying to do precisely and how good of a coder you
are. And other little details like who is going to maintain the code.
-McDaniel
H. McDaniel
> I have yet to see a MUD that is fundamentally revolutionary in
> its implementation, or one that couldn't have been easily implemented in
> LPC, with the sole exception of graphical MUDs.
When I code my own scratch mud I don't have the problem of
patching OTHER PEOPLE'S BUGS in my server or having
somebody else decide to eliminate functionality there that
requires me to REWRITE HALF OF MY GAME if I want to
keep up with new versions. I also get better speed. For instance
my sci-fi game under development crunches a lot of numbers.
I coded similar stuff in LPC and while the times were okay they
weren't ideal. I like the timing now.
For instance:
The minimum controllable clock resolution available to LPC
objects in MudOS when I was working on it was 1 second. If
you wanted to perform a wait or "call out" the resolution was
1 second. The amount of work an object could do was
limited to prevent This 1 second had nothing to do with
system resources it was just fixed that way for historical
LP reasons and (I guess) on the assumption that people only
needed to do contolled timing of messages visible to players
or on actions that will be delayed longer than one second.
Well, for somebody who knows how to code and is looking
to juggle time at a finer resolution this absolutely sucks.
Or how about the network communications stuff. My scratch
server has better network virtual terminal support than MudOS,
allows me to handle connections the way *I want to* which
is very different than how any stock games that I know of
do.
I don't trust the security in somebody else's driver, BTW. To
get to trust it (if that's possible) I'd have to read every line
of their code. I don't want to waste time (to use one of your
phrases) study some other guy's driver in the level of
detail required to detect all the security gotchas.
-McDaniel
Richard Woolcock
>
> I agree wholeheartedly that writing a codebase from scratch is a
> good project for learning some basic network protocol (or at least
> how to use the existing libs), and some of the fundamental problems
> involved with creating a MUD. I disagree, however, that advances
> are not made in the manner I've stated. Almost all major advances
> tend to be improvements on existing ideas, such as programming
> languages and computer interfaces.
I'm more than happy to incorporate (and improve upon) existing ideas,
but that doesn't mean I have to use the code as well. As it is, I've
considered the various options available and decided that C++ is the
language for the job, because:
* There is, for me, a great personal satisfaction in creating a mud
completely from scratch. Just as players draw their "fun" from
different aspects of playing a mud (such as exploring, roleplaying
or PKing), so mud owners are no different. For some people, the
fun lies in "playing god", and for that they need to get the game
up and running as soon as possible. For others, like me, the fun
lies in the creation process - in turning my vision into a tangible
mud - starting from the ground up (and no, the operating system is
not part of the mud). Telling me that my "fun" is worthless is no
different from the RP fanatics who go around saying that HnS, GoP
or PK are worthless style of play. Not only is it very rude, but
it's also very closed minded - not to mention being wrong. I don't
go around telling other people how they should enjoy mudding, so
kindly extend me the same courtesy.
* My team and I am writing a specific game, not a generic programming
environment. We don't care how extensible our game is for other
people, because it's not designed to be a public codebase, or a
platform for other mud developers. It should do what WE want it to
do, and it should do it well.
* I've been using C++ professionally for around 3 years and C for 2.5
years before that. I've also been programming muds in C for over 7
years, including writing one from scratch. My team members have a
variable amount of experience, but each of the other 5 developers
have either written a mud from scratch on their own in C, work as a
software engineer professionally (using C or C++), or both. In
terms of overall team knowledge, we'd have been better off using C,
but several of our design requirements were far easier to meet with
the features provided by C++. I've never used LPC, and as far as I
know, neither have any of my team members.
* LPC is slower than a mud written in C or C++, and consumes much more
memory. Resources might be cheap these days, but why should I pay
more for a higher spec mud server when I don't have to?
* Experience gained from LPC has little value outside of muds, other
than as general programming practice. However any experience I
gain from mud development in C or C++ improves my knowledge of (and
keeps me in practice with) the language, and thus strengthens my
professional skill set. Much of my knowledge of C comes (often
indirectly) from developing muds - and I'm hoping to improve my C++
in the same way. Equally, any knowledge I gain at work can also be
applied to my mud development.
* There is a huge range of books available on both C and C++, and I
have built up a small collection over the years. I always like to
keep a copy of K&R or Stroustrup nearby for reference purposes, but
I also have a selection of other books (such as "Effective C++" by
Scott Meyers, which is a particular favourite of mine) which I keep
handy in case I'm not sure of something. I've never seen any books
on LPC.
* There is a vast amount of information online about both C and C++,
but (comparatively) far less about LPC. A quick websearch (or a
search through the usenet archives) will bring up several answers
to just about any C/C++ question you can think of - but information
about LPC is much harder to find.
* There is a huge range of tools and utilities available for both C
and C++, both free and commercial, as well as numerous design tools
which provide support for both languages. I've never seen any such
tools for LPC - and even if there are some, there can only be a
tiny fraction of the number available for C or C++.
* There are no license restrictions on a scratch-written C/C++ mud,
while a mud developed in LPC is limited by the license for the
driver (unless you create your own, which suddenly becomes a LOT
more work).
* I much prefer to develop locally and then upload my changes, rather
than work online. This is partly due to my internet connection
(which is rather unstable) but it's also a matter of convenience -
I like to have the most recent versions of my code on my home
computer, I don't like uploading something until I feel that it's
in a reasonable state, and I like having access to my own set of
development tools.
* I don't like the idea of people changing the mud from within the
mud, other than as a player manipulating their environment. If my
mud server gets hacked, the worst that can happen is that they can
steal some binaries, shut down the mud, and destroy anything the
players have done since the last pfile backup. On an LPmud, they
could change the source code (causing all sorts of problems),
steal a copy for themselves - and destroy anything the players OR
staff have done since the last backup.
* I don't want non-coders writing code for the mud. In fact, I don't
want them going anywhere NEAR the code. If I want someone to
develop something within the game, then I will supply them with the
tools they need - tools which are easy to use, and which restrict
them to doing no more than I WANT them to be able to do.
* I don't want area-writers to have to learn how to program. In my
experience, the majority of people are good at either coding, or
building (as in creating descriptive zones), but very rarely both.
Many smart and highly talented builders have neither aptitude nor
interest in coding - requiring them to be able to code is (to me)
about as pointless as interviewing graphical artists for a MMORPG
and only hiring those who know how to code. The two skills are
unrelated, and I want to keep them that way.
* I want all code to be independantly scrutinised and tested before
going into the mud. The idea of writing code and adding it to the
running game strikes me as being downright dangerous, as well as a
waste of resources (each developer already has their own computer
as a development platform).
Now if you want to use LPC, then you should go for it - but don't try
to tell me it's some sort of "silver bullet", because it's not. It
has advantages and disadvantages like any other language, and for what
I'm doing the disadvantages outweigh the advantages.
KaVir.
Craig S. Dohmen
> the features provided by C++. I've never used LPC, and as far as I
> know, neither have any of my team members.
If you can code in C, you can code in LPC. Probably better, since string manipulation is easier and you don't have to muck around with memory allocation.
> * LPC is slower than a mud written in C or C++, and consumes much more
> memory. Resources might be cheap these days, but why should I pay
> more for a higher spec mud server when I don't have to?
At peak usage (over 200 players) Discworld uses about 65% CPU of a lowly Athlon 700, and about 250MB of memory.
> * Experience gained from LPC has little value outside of muds, other
> than as general programming practice. However any experience I
Like I said, LPC is close enough to C/C++ that it certainly can help outside the MUD. It certainly helped me get a grasp on OOP.
> handy in case I'm not sure of something. I've never seen any books
> on LPC.
Less need for 'em, because you don't have all the excess baggage that comes with C++.
> to just about any C/C++ question you can think of - but information
> about LPC is much harder to find.
See above.
> * I much prefer to develop locally and then upload my changes, rather
> than work online. This is partly due to my internet connection
> (which is rather unstable) but it's also a matter of convenience -
Er, what? There's nothing stopping you from writing your code on your machine and FTPing it up to an LP MUD. Most of the coders on Discworld work that way.
> * I don't like the idea of people changing the mud from within the
> mud, other than as a player manipulating their environment.
*blink* You don't like the idea of being able to test code on the fly without recompiling and without shutting down the MUD? I can't even conceive of any other way, especially when you have maybe 50 to 70 people who are all working on different things in 20 different time zones. And there are plenty of bugs you won't find by testing on your local machine that you will find when your code's being hammered on by 100 players.
There are plenty of protections against disaster. Coders can't change code they don't have permission to. Functions can be made "protected" or "private" to stop people from calling stuff they shouldn't. It's no less secure than straight-C++ code.
> * I don't want non-coders writing code for the mud. In fact, I don't
> want them going anywhere NEAR the code.
If you're talking about the deep-down internals, then I'd agree with you. However, as I said, there are plenty of protections against people accidentally destroying stuff.
If you're talking about writing room descriptions, then you are insane. I'd almost RATHER have non-coders writing that stuff because they'd probably do a better job of it than I would.
> * I don't want area-writers to have to learn how to program. In my
> experience, the majority of people are good at either coding, or
> building (as in creating descriptive zones), but very rarely both.
Building locations or monsters doesn't require much knowledge of how to code. Take a standard template, modify it, you're done. Besides that, there are plenty of room builders for LP MUDs out there.
> * I want all code to be independantly scrutinised and tested before
> going into the mud. The idea of writing code and adding it to the
> running game strikes me as being downright dangerous,
It's not.
> as well as a waste of resources
It isn't.
> has advantages and disadvantages like any other language, and for what
> I'm doing the disadvantages outweigh the advantages.
Except most of the disadvantages you talk about are perceived rather than real. :)
--Craig
Craig S. Dohmen
"Blane Bramble" <bl...@spamguard.lyzard.net> wrote in message news:b2k0ca.tpk.ln@backup...
> doesn't mean that it's true for everyone. Let me ask this, it is possible to
> write any program in C. So why does LISP exist?
Because LISP came first. :)
--Craig
H. McDaniel
> "Richard Woolcock" <Ka...@kavir.org> wrote in message news:ac1htc$19b$07$1...@news.t-online.com...
> > the features provided by C++. I've never used LPC, and as far as I
> > know, neither have any of my team members.
>
> If you can code in C, you can code in LPC. Probably better, since string manipulation is easier and you don't have to muck around with memory allocation.
Hell, I can code in BASIC. String manipulation is easier and you don't have to muck
around with memory allocation.
-McDaniel
Joshua Uyehara
news:3CE3DCA4...@yahoo.com:
> Joshua Uyehara wrote:
>
>> I have yet to see a MUD that is fundamentally revolutionary in
>> its implementation, or one that couldn't have been easily implemented in
>> LPC, with the sole exception of graphical MUDs.
>
> When I code my own scratch mud I don't have the problem of
> patching OTHER PEOPLE'S BUGS in my server or having
> somebody else decide to eliminate functionality there that
> requires me to REWRITE HALF OF MY GAME if I want to
> keep up with new versions. I also get better speed. For instance
> my sci-fi game under development crunches a lot of numbers.
> I coded similar stuff in LPC and while the times were okay they
> weren't ideal. I like the timing now.
If you're skilled enough to write a scratch base even a quarter as good as
ldmud, none of the above would be a problem. Need fast number crunching
capabilities? Make some efuns.. heck.. throw in a C->Fortran API for
writing your efuns so you can make use of a real maths language. Also,
you'd be an idiot if you installed an upgrade that made you rewrite half
your game. If you can write a scratch base, I'm sure you're capable of
maintaining a server on your own.
> For instance:
>
> The minimum controllable clock resolution available to LPC
> objects in MudOS when I was working on it was 1 second. If
> you wanted to perform a wait or "call out" the resolution was
> 1 second. The amount of work an object could do was
> limited to prevent This 1 second had nothing to do with
> system resources it was just fixed that way for historical
> LP reasons and (I guess) on the assumption that people only
> needed to do contolled timing of messages visible to players
> or on actions that will be delayed longer than one second.
> Well, for somebody who knows how to code and is looking
> to juggle time at a finer resolution this absolutely sucks.
IIRC, the resolution for ticks is set by a single #define.
> Or how about the network communications stuff. My scratch
> server has better network virtual terminal support than MudOS,
> allows me to handle connections the way *I want to* which
> is very different than how any stock games that I know of
> do.
Then rewrite/replace the appropriate libs. "I didn't like the socket
handling code" is a poor reason for re-writing an entire network
server+stackmachine.
> I don't trust the security in somebody else's driver, BTW. To
> get to trust it (if that's possible) I'd have to read every line
> of their code. I don't want to waste time (to use one of your
> phrases) study some other guy's driver in the level of
> detail required to detect all the security gotchas.
>
> -McDaniel
>
Now this single point is the only good non hardware-resource-limitation or
education-related argument for writing a scratch codebase that I've seen
yet. I for one, however, trust the LPMUD line's 14-year-long trial by fire
more than I'd trust an untested codebase that I've written from scratch.
H. McDaniel
> "H. McDaniel" <cut_Xs_off_to_re...@yahoo.com> wrote in
> news:3CE3DCA4...@yahoo.com:
>
> > Joshua Uyehara wrote:
> >
> >> I have yet to see a MUD that is fundamentally revolutionary in
> >> its implementation, or one that couldn't have been easily implemented in
> >> LPC, with the sole exception of graphical MUDs.
> >
> > When I code my own scratch mud I don't have the problem of
> > patching OTHER PEOPLE'S BUGS in my server or having
> > somebody else decide to eliminate functionality there that
> > requires me to REWRITE HALF OF MY GAME if I want to
> > keep up with new versions. I also get better speed. For instance
> > my sci-fi game under development crunches a lot of numbers.
> > I coded similar stuff in LPC and while the times were okay they
> > weren't ideal. I like the timing now.
>
> If you're skilled enough to write a scratch base even a quarter as good as
> ldmud, none of the above would be a problem. Need fast number crunching
> capabilities? Make some efuns..
What? You mean I can't do it in LPC as you claimed previously? What you
fail to understand is that I have no interest in coding a mudlib or equivalent
in two languages. If I'm required to code in C and LPC I find it a hassle.
I'd
rather do one or the other. Guess which ones wins if I need to code C to
get the mudlib to behave the way i want it to? When I started using MudOS,
I was fully capable of "hacking" the driver. I had come from a Diku
background where all I did was server coding in C. I knew very little LPC
at first, in fact. But I didn't want to have to develop in two languages.
That
is a waste of time (as you are fond of saying) if the whole game can be
implemented in just one of those languages. And guess which language
that is.
> heck.. throw in a C->Fortran API for
> writing your efuns so you can make use of a real maths language. Also,
> you'd be an idiot if you installed an upgrade that made you rewrite half
> your game. If you can write a scratch base, I'm sure you're capable of
> maintaining a server on your own.
The catch is that I have zero interest in maintaining somebody else's
unsupported, poorly documented server code.
> > For instance:
> >
> > The minimum controllable clock resolution available to LPC
> > objects in MudOS when I was working on it was 1 second. If
> > you wanted to perform a wait or "call out" the resolution was
> > 1 second. The amount of work an object could do was
> > limited to prevent This 1 second had nothing to do with
> > system resources it was just fixed that way for historical
> > LP reasons and (I guess) on the assumption that people only
> > needed to do contolled timing of messages visible to players
> > or on actions that will be delayed longer than one second.
> > Well, for somebody who knows how to code and is looking
> > to juggle time at a finer resolution this absolutely sucks.
>
> IIRC, the resolution for ticks is set by a single #define.
Inside the driver. You mean I can't do it in LPC as you claimed
previously? Of course you know that simply changing the
tick will require rewriting any existing LPC code that relies
on 1 second ticks for sending messages to player. Now
given that you just said, "you'd be an idiot if you installed
an upgrade that made you rewrite half your game", are
you being idiotic now or was your earlier statement false?
Actually *IF* I were going to go the route of touching the driver
with a 10 foot pole I'd have simply of written a new efunction that
had a sub second clock resolution. But that's missing the point
about my not wanting to have to write in two languages, just
covered in the previous section.
> > Or how about the network communications stuff. My scratch
> > server has better network virtual terminal support than MudOS,
> > allows me to handle connections the way *I want to* which
> > is very different than how any stock games that I know of
> > do.
>
> Then rewrite/replace the appropriate libs. "I didn't like the socket
> handling code" is a poor reason for re-writing an entire network
> server+stackmachine.
I own my code. I am not donating it to be under the same license
as MudOS and I'm not interested in (nor have I been invited to)
work on the MudOS driver. You can replace "MudOS" with any
other driver out there now and my position stands. And I did
not "re-write an entire network server+stack machine" I am
writing my own server from scratch. This isn't the same thing
as rewriting. It is originating.
> > I don't trust the security in somebody else's driver, BTW. To
> > get to trust it (if that's possible) I'd have to read every line
> > of their code. I don't want to waste time (to use one of your
> > phrases) study some other guy's driver in the level of
> > detail required to detect all the security gotchas.
>
> Now this single point is the only good non hardware-resource-limitation
> or
> education-related argument for writing a scratch codebase that I've seen
> yet. I for one, however, trust the LPMUD line's 14-year-long trial by fire
> more than I'd trust an untested codebase that I've written from scratch.
That sounds reasonable if:
* You want to implement your game in LPC.
* You don't mind not having pretty good network virtual terminal support.
* You believe that there are no known exploits to LPMUD.
* You have limited to no experience coding software that is in a hostile
environment as part of your 9-5 job.
* That you wouldn't test your scratch codebase before exposing it to the
world.
Speaking to the last point: You believe (unless I have you confused with
another poster in this thread) that the best way to test mud code is to
have any Tom, Dick or Harriet log onto the game and play around with
things. If that's your idea of testing then you are absolutely right to never
code anything outside of a sandbox.
-McDaniel
John Robert Arras
Craig S. Dohmen <doh...@erols.com> wrote:
>At peak usage (over 200 players) Discworld uses about 65% CPU of a lowly =
>Athlon 700, and about 250MB of memory.
>
How many objects are generally in the game during times like this?
That seems like a huge amount of memory. And also, is there more data
cached to disk, or is it all in memory?
John
Richard Woolcock
news:ac1m67$9el$1...@bob.news.rcn.net...
> > more memory. Resources might be cheap these days, but why
> > should I pay more for a higher spec mud server when I don't
> > have to?
>
> At peak usage (over 200 players) Discworld uses about 65% CPU of a
> lowly Athlon 700, and about 250MB of memory.
Good lord, is that supposed to be some sort of joke? I think you've
more than proved my point.
> > handy in case I'm not sure of something. I've never seen any
> > books on LPC.
>
> Less need for 'em, because you don't have all the excess baggage
> that comes with C++.
So the various LPC features, which are no use to me, are "a useful
and powerful set of tools" while the C++ features which I am using
within my mud are "excess baggage"?
> > * I don't like the idea of people changing the mud from within the
> > mud, other than as a player manipulating their environment.
>
> *blink* You don't like the idea of being able to test code on the
> fly without recompiling and without shutting down the MUD? I can't
> even conceive of any other way, especially when you have maybe 50
> to 70 people who are all working on different things in 20 different
> time zones. And there are plenty of bugs you won't find by testing
> on your local machine that you will find when your code's being
> hammered on by 100 players.
So you just throw out unscrutinised and untested implementations and
let your players find the problems?!
> > has advantages and disadvantages like any other language, and for
> > what I'm doing the disadvantages outweigh the advantages.
>
> Except most of the disadvantages you talk about are perceived
> rather than real. :)
No, all of them are real. I could overcome some of them, but if I
did that I would lose all the advantages of LPC. However I would
still have many of the disadvantages.
KaVir.
Mystran the Dark-Elf
> "Craig S. Dohmen" <doh...@erols.com> wrote in message
> news:ac1m67$9el$1...@bob.news.rcn.net...
> "Richard Woolcock" <Ka...@kavir.org> wrote in message
> news:ac1htc$19b$07$1...@news.t-online.com...
> >
> > > * LPC is slower than a mud written in C or C++, and consumes much
> > > more memory. Resources might be cheap these days, but why
> > > should I pay more for a higher spec mud server when I don't
> > > have to?
> >
> > At peak usage (over 200 players) Discworld uses about 65% CPU of a
> > lowly Athlon 700, and about 250MB of memory.
>
> Good lord, is that supposed to be some sort of joke? I think you've
> more than proved my point.
Not necessarily.. another option is that the LPC code is VERY bad :)
> > > * I don't like the idea of people changing the mud from within the
> > > mud, other than as a player manipulating their environment.
> >
> > *blink* You don't like the idea of being able to test code on the
> > fly without recompiling and without shutting down the MUD? I can't
> > even conceive of any other way, especially when you have maybe 50
> > to 70 people who are all working on different things in 20 different
> > time zones. And there are plenty of bugs you won't find by testing
> > on your local machine that you will find when your code's being
> > hammered on by 100 players.
>
> So you just throw out unscrutinised and untested implementations and
> let your players find the problems?!
You can still allow the feature to be used just by a limited set of people
and test it there, but much worse I find the problem of profiling code like
that. But then again the performance of the system seems to be no concern
given what is said above ;)
- Mystran
Craig S. Dohmen
> Speaking to the last point: You believe (unless I have you confused
> with another poster in this thread) that the best way to test mud
> code is to have any Tom, Dick or Harriet log onto the game and play
> around with things. If that's your idea of testing then you are
> absolutely right to never code anything outside of a sandbox.
Butting in, but here's how I see it. If you want to stick to a l33t team of crack coders working on your from-the-ground-up code base you've got loads of problems. Everyone needs a copy of the code, so they have to download it from somewhere. Plus they have to keep it in sync with everyone else. Plus in order to test their stuff they have to have a C/C++ compiler. Plus they probably all have to be running the same OS.
If people can just log onto the game and code (as in a typical LP), all these problems vanish. This may be a shock, but not everyone out there has a broadband connection and Linux and gcc or Windows and Visual C++. With an LP MUD it doesn't much matter if you're running DOS 3.3 on a 486 with a 28.8 modem; you can still be productive. It's also a (IMO) much less intimidating environment for people who aren't born coders. They can try things out and get immediate feedback, with the knowledge that even if you screw up royally, the worst that's likely to happen is just a runtime error or a "too long evaluation; execution aborted". In short, it opens up the door to a lot more people to write code. This is a strength, not a weakness.
--Craig
Craig S. Dohmen
> Good lord, is that supposed to be some sort of joke? I think you've
> more than proved my point.
*blink* Good luck then.
> So the various LPC features, which are no use to me, are "a useful
> and powerful set of tools" while the C++ features which I am using
> within my mud are "excess baggage"?
Which features are of no use? And if you don't think C++ is full of excess garbage...
> So you just throw out unscrutinised and untested implementations and
> let your players find the problems?!
No. All I said was that you'll find more problems when a lot of people are using your code that if you are testing it alone. Maybe you're just a perfect coder and I'm not. Oh well!
> No, all of them are real.
Nah, you're just on crack.
--Craig
H. McDaniel
> H. McDaniel <cut_Xs_off_to_re...@yahoo.com> wrote:
> > Speaking to the last point: You believe (unless I have you confused
> > with another poster in this thread) that the best way to test mud
> > code is to have any Tom, Dick or Harriet log onto the game and play
> > around with things. If that's your idea of testing then you are
> > absolutely right to never code anything outside of a sandbox.
>
> Butting in, but here's how I see it. If you want to stick to a l33t team of crack coders working on your from-the-ground-up code base you've got loads of problems. Everyone needs a copy of the code, so they have to download it from somewhere. Plus they have to keep it in sync with everyone else. Plus in order to test their stuff they have to have a C/C++ compiler. Plus they probably all have to be running the same OS.
If I were interested in having others code on my server (I'm not at
present) I would simply give those coders SSH access to my build machine
and we would use some form of source control (there are several choices
out there) or if each coder was working on well isolated portions of code
we would simply do manual merging at the appropriate times.
> If people can just log onto the game and code (as in a typical LP), all these problems vanish. This may be a shock, but not everyone out there has a broadband connection and Linux and gcc
You haven't identified any real problems. You don't need a broadband
connection to SSH into my build machine. You don't need Linux or gcc either.
> or Windows and Visual C++. With an LP MUD it doesn't much matter if you're running DOS 3.3 on a 486 with a 28.8 modem; you can still be productive. It's also a (IMO) much less intimidating environment for people who aren't born coders.
In my experience, having a lot of volunteer, inexperienced coders is not that
valuable. Most of them make very little contributions in the way of reusable code
and I am obligated to remove their contributions whenever they either
decide to leave the game or are asked to leave. As I may have said in
another posting, when I was running an LPMUD, despite having something
like 20-30 active builders on average, I was doing 97% or more of the
coding of inheritable objects, daemons, and other essential or high priority
stuff.
>They can try things out and get immediate feedback, with the knowledge that even if you screw up royally, the >worst that's likely to happen is just a runtime error or a "too long evaluation; execution aborted". In short, it >opens up the door to a lot more people to write code. This is a strength, not a weakness.
But I don't need "a lot more people to write code". How many people
you want depends on a lot of factors and I know that I don't need
more than 1 person coding right now. I'm not saying LPMUD isn't useful.
It just isn't what I am interested in, despite having done a lot with it
in the past.
-McDaniel
Alan Schwartz
>Richard Woolcock <Ka...@kavir.org> wrote:
>> Good lord, is that supposed to be some sort of joke? I think you've
>> more than proved my point.
>
>*blink* Good luck then.
His point being, I think, that 65% CPU use on an Athlon is much too high
for any mud, even with 200 players (I dunno about the 250Mb of memory -
I don't know how large discworld is).
When a PennMUSH server with 200 players goes above 4-6% CPU, we start
to worry. On one hand, PennMUSH doesn't have a slew of mobs
acting autonomously as many LPmuds do, so most of our CPU is player-bound,
not server-bound. (On the other, every player is a potential coder,
so there can be a lot of code running).
Anyway, I think that's what Richard meant. Personally, I'm a fan of
LPmuds and the LPC language, but that may be because MUSH's internal
programming language is so much ickier. :)
- Javelin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Javelin@M*U*S*H (mush.pennmush.org 4201) | Alan Schwartz
Owl@Rio: Manha de Carnaval | dune...@pennmush.org
Paul@DuneMUSH, and Javelin elsewhere | PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
PennMUSH Source: ftp://ftp.pennmush.org/pub/PennMUSH/Source
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Matt Knecht
>
>Butting in, but here's how I see it. If you want to stick to a l33t team
>of crack coders working on your from-the-ground-up code base you've got
>loads of problems.
Many of us don't want a l33t team of coders. We enjoy working on the
code itself, and designing a game. Having a fun MUD to play on is
just a nice side-benefit.
> Everyone needs a copy of the code, so they have to
>download it from somewhere. Plus they have to keep it in sync with
>everyone else.
There are many ways to make this process not only painless, but
productive. I use CVS for my small team. There are many other source
control systems out there, most of which are easy to use.
> Plus in order to test their stuff they have to have a C/
>++ compiler. Plus they probably all have to be running the same OS.
My code works on Linux, Solaris, and FreeBSD. It probably works on
others, but I really haven't tried compiling on more platforms that
that. =)
It's also simple to give coders access to the server with a development
account. I routinely modify my local code repository on the server,
and from the repositories I have at home and work. CVS takes care of
all the nitty gritty details of keeping everything in sync. All a
developer needs is an ssh client.
>If people can just log onto the game and code (as in a typical LP), all
>these problems vanish. This may be a shock, but not everyone out there
>has a broadband connection and Linux and gcc or Windows and Visual C++.
I'm not sure why you'd need a broadband connection to code. Perhaps
I'm missing something. But the problems you cited aren't really
problems at all, so I guess the point is moot.
>With an LP MUD it doesn't much matter if you're running DOS 3.3 on a 486
>with a 28.8 modem; you can still be productive.
A few years ago I used to use telnet from a VAX to get development
access. I imagine CVS works on VMS, but I didn't have the disk quota
to find out.
> It's also a (IMO) much
>less intimidating environment for people who aren't born coders. They
>can try things out and get immediate feedback, with the knowledge that
>even if you screw up royally, the worst that's likely to happen is just
>a runtime error or a "too long evaluation; execution aborted". In shor
>, it opens up the door to a lot more people to write code. This is a
>strength, not a weakness.
It's a strength if what you want is many people expannding the code
and game in all sort of different directions. Personally, I like to
build the game myself with just a few other people. I guess we have
different goals, though.
--
Matt Knecht <h...@voicenet.com>
exile.lurker.net 4000
Myles L Skinner
Mystran the Dark-Elf <mys...@joutomaa.net> wrote:
>
> Also most current MUD codebases are so strictly room based that making
> forexample a tilebased map (where there can be one player per tile) is
> pretty hard.. if you don't want to make the whole map into one room that is
> :)
No kidding...and try doing it with hexagonal tiles, too.
Map tiles and rooms still share a rather uneasy coexistence in our SMAUG.
Probably not the ideal solution to graft something that different on to a
stock codebase, but it certainly can be done.
We were originally were going to write "from scratch", but at one point I
decided I was wasting my time when I had a doctorate to complete. So instead
I make SMAUG jump through hoops and my builders can continue to use the
tools they've always used, so they're happy too.
ms
--
Covenant MUD: "Under Development for Fewer than One Hundred Years!"
hei...@gmail.com
> In article <slrnadfqe...@needa.bearnip.com>, la...@bearnip.com (Lars
> Duening) wrote:
>
> >
> > Of course, to make it truly 'from scratch' you'd have to start with
> > re-inventing the universe.
>
> Shhh! You're going to make Kavir mad again if you keep talking about his
> secret projects!
>
> --
> Marc Bowden - Soulsinger Dreamshadow:The Legacy of the Three
> ry...@merit.edu 209.48.36.2 3333
Are you still around Soulsinger?