Thoughts on the social MU* status quo
as6...@atlas.usdu.edu
TinyMUCK, TinyMUD, UnterMUD, etc. etc. would have seemed like total science
fiction to people just twenty years ago, I marvel that we take it so complete-
ly for granted.
Every so often someone crossposts here an advertisement that snuck into one of
the comp. groups advertising a commercial, for-profit server that usually
sounds like a vanilla-flavored TinyMUD -- and the ads makes the product sound
like the thing is totally revolutionary. Hype aside, if you showed the ads to
the average American citizen, said citizen would say "Gosh! How about that!"
And we're about five or six generations beyond the level you see advertised in
those for-profit MU* ads...
We've got virtual reality software set up that allows us to talk with and
interact with people from around the world in (usually) real time, build and
extend a virtual reality setting, program in world rules, simulate any manner
of real life phenomena, and so forth. We've somehow evolved this software
with no central coordination; no professional association of MU* developers
that gets together and shares ideas; no American Journal of MU* Research; and
(usually) no profit motive. All this goes on in a virtual vacuum; as far as
99.999% of the world population is aware, MU*'s don't exist. We've got
incredible capabilities. We got to this point by the seat of our pants, true,
but that just makes me wonder what we could do if we ever sat down and really
had a look at where we're going.
We've got these incredible virtual reality tools called MU*'s that could
potentially allow us to do one hell of a lot of things. MU*'s would have been
the stuff of science fiction twenty years ago... if anyone had actually
thought of them. The potential for further expansion of virtual reality
capability through MU*-like systems is tremendous.
But what do we do with all this wonderful stuff, these MU*'s?
We sit around in chat rooms and give each other backrubs.
We've been given innovations that are to Atari 2600 game cartridges as H-bombs
are to hand grenades and we use them for the computing equivalent of $1.50 per
minute telephone party numbers.
Isn't there more to tinylife than that? Sure, okay, I oversimplified. We do
more than engage in tinysex, chat in IRC-like fashion, and tell each other the
best places to FTP things. We also sit around developing the Next Great
Server, the one that's going to take the MU* world by storm and make
everyone's life Totally Great. Unfortunately everyone's developing their own
server, no one likes to document anything they've coded up, and every time
someone comes up with a useful feep, everyone else falls all over themselves
blasting it as an idiotic and useless trifle to get back for what happened the
time before when *their* feeps were assailed as idiotic. Makes you wonder
that we ever got this far in the first place.
Is anyone out there innovating? Coming up with a new and interesting use to
which social MU* technology can be put? Doing something to lift us to the
next level entirely? Coming up with a social MU* economy that REALLY works?
Developing a weather system for TinyMUCKs? Even doing something interesting
and new with what we've already got?
If we went two years into the future and checked out the Internet, what would
we find? Would people still be flaming each other over server bugs in the
latest version of TinyMUCK 2.2? Still around chatting in one room while 4999
other rooms on the MU* went unexplored? Still idling for hours on sixteen
different MU*'s at once and going from MU* to MU* saying "I'm bored?"
Can't there be more to tinylife than this?
Isn't ANYONE innovating anymore?
Jack Shirazi <js@biu.icnet.uk>
>
>We've got virtual reality software set up that allows us to talk with and
>interact with people from around the world in (usually) real time, build and
>extend a virtual reality setting, program in world rules, simulate any manner
>of real life phenomena, and so forth. We've somehow evolved this software
>with no central coordination; no professional association of MU* developers
>that gets together and shares ideas; no American Journal of MU* Research; and
>(usually) no profit motive. All this goes on in a virtual vacuum; as far as
>99.999% of the world population is aware, MU*'s don't exist. We've got
>incredible capabilities. We got to this point by the seat of our pants, true,
>but that just makes me wonder what we could do if we ever sat down and really
>had a look at where we're going.
>
>We've got these incredible virtual reality tools called MU*'s that could
>potentially allow us to do one hell of a lot of things. MU*'s would have been
>the stuff of science fiction twenty years ago... if anyone had actually
>thought of them. The potential for further expansion of virtual reality
>capability through MU*-like systems is tremendous.
>
>But what do we do with all this wonderful stuff, these MU*'s?
>
>We sit around in chat rooms and give each other backrubs.
>
>Is anyone out there innovating? Coming up with a new and interesting use to
>which social MU* technology can be put? Doing something to lift us to the
>next level entirely? Coming up with a social MU* economy that REALLY works?
>Developing a weather system for TinyMUCKs? Even doing something interesting
>and new with what we've already got?
>
I know nothing of how MU*'s are setup (would like to). But to address
your specific concerns, over in alt.uu.virtual-worlds.misc we are just
at the beginning of creating a course, and we need your experience.
These are exactly the sort of things we need to take further and develop
for progress in virtual-worlds. In fact, it seems to me that the work done
in these MU* groups could probably form the basis for really effective
future development in virtual-worlds. We need experienced and motivated
people like you to help us integrate MU* technology.
Please tell me where I can find stuff about MU* technology - I try to scan all
these groups, but have not noticed a FAQ about the technology used here.
--
Jack j...@bison.lif.icnet.uk
If you only have a hammer, you tend to see every problem as a nail.
-- Maslow
Shag
>Is anyone out there innovating? Coming up with a new and interesting use to
>which social MU* technology can be put? Doing something to lift us to the
>next level entirely? Coming up with a social MU* economy that REALLY works?
>Developing a weather system for TinyMUCKs? Even doing something interesting
>and new with what we've already got?
I know of two systems that are being created for use in RL education (virtual
classrooms / distance education stuff)... one that I'm in on is in the works
at U. Iowa using some hacked-half-to-death version of MUCK ;) and the other
is a MUSH being built at Stockton State College in NJ by a friend of mine.
It's not really a "new and interesting use" but it's a RL application of MUD.
Um... economy... hey, if we could come up with a working economy on a MUD,
we'd probably have something closer to one in RL! ;) Weather... weather
would be neat. 'Course, then you get into an area of VR that's really not
being explored at all, MUD or otherwise - sensory input. If you get weather
involved, you have to tell people whether they're hot, cold, wet, etc.
-Shag
--
Shag | Operator, ShagNET | Editor of "Screaming in Digital"
birc...@pilot.njin.net | Rutgers / NJIN | The Queensryche E-mail Digest
birc...@njin.bitnet | dialup access for | queensry...@pilot.njin.net
sh...@most.other.places | Burlington County | Anything Queensryche, every week
Alan Schwartz
>potentially allow us to do one hell of a lot of things. MU*'s would have been
>the stuff of science fiction twenty years ago... if anyone had actually
>thought of them. The potential for further expansion of virtual reality
>capability through MU*-like systems is tremendous.
>
>But what do we do with all this wonderful stuff, these MU*'s?
>
>We sit around in chat rooms and give each other backrubs.
And what is wrong with that? While there is certainly great untapped
potential in MU* environments, the social aspects of this form of
VR are fascinating and IMHO of great interest to those into the human
aspects of technology.
>Is anyone out there innovating? Coming up with a new and interesting use to
>which social MU* technology can be put? Doing something to lift us to the
>next level entirely? Coming up with a social MU* economy that REALLY works?
>Developing a weather system for TinyMUCKs? Even doing something interesting
>and new with what we've already got?
Check out Mua'kaar (wlu.edu 4201) if you get a chance. They have a working
(though under continual development and improvement) economy and
weather system (It's a role-playing MUSH with an original theme).
Also ecology, food, skills, magic, combat, military battles, etc.
There may be code modifications in the future to support multiple (in-theme)
languages at varying fluency levels, too.
I've written a MUSH flight simulator that I find kinda fun, especially if
you fly it through Talek's Dynamic Spaces (unlimited movement, @whee).
One day, perhaps I'll develop it more fully.
>Isn't ANYONE innovating anymore?
Yep, I think innovations are out there. In the non-game/social domain,
MU* systems could be ideal for conferencing, education (teaching
OO programming is just the beginning), and even running psychological
or economic or ecological experiments.
But let's not overlook the value of a friendly backrub. :)
- Alan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Alan Schwartz
Belkira@Belgariad II | ala...@cogsci.berkeley.edu
Indena@Mua'kaar | UC Berkeley
Javelin@Belgariad, and elsewhere | Cognitive Psychology
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The Eye of Fatima
found is some docs for MUSH, though I seem to recall some statement in
there saying they were significantly different. I don't want to
get too deep into trying to understand MUSH only to find out most
of it is different or contradicted or just left out in MUSE. I've
never coded in any tiny-like muds before, so the whole environment
is rather new to me. I'd appreciate any help you can offer me.
Thanks,
will
Oh, if it matters, the MUSE of use would be BattleTechMUSE.
///////////////////////////////////////////////////////////////////////
|\\\\ /////\\ "The irony of the || _ ___ |
| William A. Day \\ universe has not || ___\ | angerine|
|wil...@ux1.cso.uiuc.edu.\\ escaped me." || \\|_|o __ |
|wad4...@uxa.cso.uiuc.edu.\\ _BattleTech: || /_\ \/ |_)ream |
| ^--@sumter.cso.uiuc.edu.\\ Blood Legacy_ || / |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
David
just scratched the surface of possibility with MU*'s, but
don't put down the social aspects so quickly. You hit the
nail on the head when you said that we all tend to hang around
one room while so many others sit quietly. That does bother me;
however, it's because of that congregating that I have met others
from Canada, Finland, Holland, and the UK. Sure we didn't discuss
political issues ... that's not the purpose of the MUSH. We
talked a little about music (the few minutes we were ooc, anyway).
Our lives are made up of 'small' things, why not share them?
I do understand your comments, however. The trouble is that not
everyone out there is a programmer. Not everyone can dig in and
do the research and coding necessary to bring about these changes
you mention. A working economy would be particularly difficult
because a knowledge of using the MU* code is necessary, and again
not everyone is interested in the effort to learn it. Perhaps a new
approach to the server and interface is the change that is needed.
Dave
Geoff Tuffli
>Is anyone out there innovating? Coming up with a new and interesting use to
>which social MU* technology can be put? Doing something to lift us to the
>next level entirely? Coming up with a social MU* economy that REALLY works?
>Developing a weather system for TinyMUCKs? Even doing something interesting
>and new with what we've already got?
>
Sometime last Fall, this same concern arose in, admittedly, a somewhat
haphazard format in the MUSH dimension of TinyMU*ing. Lydia Leong (better
known as Amberyl) and a number of others (you know who you are :-) ) began
putting together the idea of a MUSH that was much more heavily into role-
playing; the result of this was the Belgariad. Over the next year, a number
of innovations began creeping into it, most notably the beginnings of a
combat and magic system, dynamic spaces, and an attempt (failed) to run an
economy on a MUSH.
The Belgariad was, arguably, the first major MUSH to seriously attempt as
its primary goal to tackle the status quo of TinyBackrubs and the like in
an attempt to inject some vigor back into that particular mode of VR.
About 6 or so months ago, I and a few others decided to try to take the
idea one step forward, and to implement from the start systems such as combat
and economics. That effort, combined with an original theme not based off
a published author's work, resulted in Taeis. Taeis, as some of you probably
know, was put up on an HP-UX, and the resulting code incompatibilities
finally drove it off (these were later fixed).
Recently, within the last month or so, Mua'kaar, another originally themed
MUSH was opened to the public. This, unlike Taeis (which was, admittedly,
horridly organized, a fault I take complete responsibility for) was possessing
of another level entirely of systems. Currently, to name a few, we have in
advanced or rudimentary form systems for weather, economics, combat, magic,
military action, dynamic spaces, ecology, time, and such forth. In the process
of this, I can point out a few interesting side-effects of this movement
towards what I am fond of calling "dynamic MU*es".
The most obvious hurdle that has come up again and again is flat out resistence
to change. Doing extreme and revolutionary shifts in systems on an already
established MU* (as it was on the Belgariad) has proven to be, unsurprisingly,
very difficult to pass by players, most who are very much used to the standard
social MU*, which, while certainly having a place of their own, are not the
whole cake.
This resistence has recently cropped up again in the nature of coded systems
(this occured to some extent, I believe, out of talk of fitting in a very
crude language parser as a system) and role-playing. The legacy left behind
by the first Belgariad was an emphasis on role-playing as opposed to social
MU*ing, and thus the conflict has arisen as to whether coded systems (like
the aforementioned weather and ecology) detract from role-playing.
Some of this arises very naturally out of what people WANT out of a MU*;
some like the socializing, some like the role-playing, some like the coding,
some like the building, and some like the gaining and accumulation of
levels and items and power.
Personally, I don't see these as mutually exclusive in the vast majority of
cases; I believe some people DO, which may be the cause of the current
concern of the apparent "technifying" of MU*es like Mua'kaar and its ilk.
Done properly, I see the various systems as assisting role-playing and making
it richer, fuller. One of the complaints I recently heard had to do with
the profusion of systems that were seen as going unused...whereas my own
impression has been that most people DO use the systems, this may be incorrect
and it certainly bears some want for an objective examination of the uses
for various systems.
In a way, I think that this parallels what happened with the rise of the
role-playing game Amber, which for those who are not familiar with the system,
uses no dice, and is essentially a "pure" role-playing.
Another observation was to the effect that systems making a MUSH environment
more realistic are bad because some players are trying to get AWAY from
reality. My personal belief on this is that what I want out of MU*ing is a way
to further exploit ideas and imagination in the process of creating worlds;
but again, this may simply be a matter of personal preference.
The "dynamic" MUSHes that I know of, for the interested, are the following:
Mua'kaar: wlu.edu 6666, 137.113.10.35 6666 [open]
Belgariad II: csa.bu.edu 4201 [open]
Taeis: << no site >> [down until site is found]
Valdemar: [pre-opening]
Dune: [pre-opening]
There has also been talk of making Dragon's Dawn dynamic in the sense outlined
above, and, from what little I have seen of it, I believe Narnia may also fall
into this category of being a "dynamic MU*".
I hope this has proved interesting, or at least informative as to one line of
attempts to instill dynamicism and novel ideas into TinyMU*. Due to space
considerations, I have completely left out certain other developments in
administration of dynamic MU*es (what has been done, what seems to work well,
what doesn't seem to work as well, etc.,...) as well as details of the
various systems and their implementations.
As a final note, this line of MU*es is, to my knowledge, with the exception
of Dragon's Dawn, all running off the 1.5 PennMUSH code (which with the
parser fixes is, I believe, finally easily as usable as the originaly
TinyMUSH 2.0 code).
Geoff Tuffli
The Green Griffin
Gaerdon@Mua'kaar wlu.edu 6666 137.113.10.35 6666
Colby@Belgariad II csa.bu.edu 4201
Gram@Dune
Celon@Valdemar
Lorm@Taeis
Shaav@Belgariad I
Geoff Tuffli
>>We sit around in chat rooms and give each other backrubs.
>
>And what is wrong with that? While there is certainly great untapped
>potential in MU* environments, the social aspects of this form of
>VR are fascinating and IMHO of great interest to those into the human
>aspects of technology.
>
Yes...this is one point which is frequently overlooked. It is not that
social/combat/role-playing/foo/bar MU*s of whatever type are bad; while
there is nothing wrong, to my way of looking at it, attempting to create
new modes of innovating, condemning the previous forms simply because they
are previous is a bit silly, I think.
Socializing -- and even purely combat-oriented MU*s -- do certainly have
their place, and this should NOT be overlooked. As Alan points out, the
socialization aspects should not be trivialized, as while they are only
one aspect, they are in and of themselves an extremely facinating aspect.
Lydia Leong
on TinyM*s? ]
Interesting developments in the history of TinyM*s:
(the dates below are public openings)
Jan. 91: PernMUSH. This is the first Tiny that strictly enforced a theme,
as far as I know. PernMUSH stresses in-character social interaction.
Any plots are generally short-term and "local" to the characters
involved. Most players have a definite "job" and place in the world.
Aug. 91: Crossroads MUCK. High-quality building and puzzles stressed.
An economy, an LP-mud-style role-playing/comabt system, and many,
many MANY other things were present on this MUCK. Other things,
like a MUD University, were planned. Unfortunately, the game
lagged so much that it was nearly unplayable, and eventually
went down due to site problems.
Feb. 91: The Belgariad (MUSH). The first of the plot-driven MUSHes
(Geoff Tuffli terms these "dynamic"). Role-playing, with a
definite goal in mind, is the focus of this MUSH; plots may be
manipulated by the administrators, who provide a basic storyline.
Had the first widely-used MUSH combat system, and attempted an
economy. Belgariad II (same group of people, new database,
twenty RPG years later) is attempting to improve on the
systems used on Belgariad I.
Jul. 91: AmberMUSH. Role-playing is stressed on this MUSH, but it's
slightly "looser", since the theme allows for multiple worlds
with their own physical/magical laws. Plots (I believe) are
generally run by major characters, without deliberate admin
intervention. There is an RPG system based on the Amber Diceless
paper-and-pencil system. This is the first MUSH to really blend
the plot orientation of a dynamic MUSH with the "ignore things if
you want to" looseness of a social MUSH.
Nov. 91: Mua'Kaar. Strict role-playing MUSH. The world is complex and
original. A large number of systems are MUSHcoded, with plans
to hack things like languages directly into the server. This
is the opposite extreme of a free social MUSH like TinyTIM.
We _have_ come quite a ways in the past two years, actually. We're still
very much at the "game" stage, but people _want_ games, so that's what
we're likely to continue working on.
I believe that one of the reasons that it's taken this long to reach
the level of (perhaps extreme) complexity that Mua'Kaar is aiming for
is the lack of server support for complex systems. Crossroads had to
hack a large number of things directly into MUCK; unfortunately, the
result was severe server lag. MUSH has developed tremendously over
the last year and a half; it is now possible to code things which
would have been totally unthinkable not too long ago.
I'm inclined to think that the flexibility and power of MUCK's MUF
language makes it better suited to large global systems than MUSH is.
"Dynamic" MUSHes presently seem to be favoring 1.50 MUSH over 2.0:
the parsers are identical, but 1.50 has a slightly more flexible
system of handling global and zone (local global) commands, plus
a sub-wizard ("royalty") flag, making it a bit more suitable for
MUSHes with clearly defined areas and a need for lots of admins.
MUCK (at least the Crossroads server) wins out over MUSH again
here, though, since it really has the best support for zones and
local wizards.
Ideally, though, support for combat, a role-playing system, an
economy, etc. should be in the server from the beginning. There's
really nothing out there that fits.
Social interaction remains the primary focus of most Tinys because
the majority of people want to hang out, talk, and relax. The
role-playing MU*s generally take thought and concentration, and
a large number of people don't want to deal with that.
Personally, I'm looking for something beyond what's out there now;
I don't know what it is, but if I come up with an idea, you'll
see a new MU* on the mudlist...
-- Amberyl (PernMUSH) / Polgara (Belgariad) / etc.
-------------------------+----------------------------------------------------
Lydia Leong, CSE '94 | C code. C code run. Run code run... please!
l...@eniac.seas.upenn.edu | Backup not found: (A)bort (R)etry (P)anic
l...@imsasun.imsa.edu | "man reboot" (-n option): Avoids the sync(1). It
l...@csa.bu.edu | can be used if a disk or the processor is on fire.
-------------------------+----------------------------------------------------
Geoff Tuffli
systems. I've heard that "MAGE" combines MUSH and MUF into a single system.
Has anyone looked at this variant as a possibility for use in dynamic MU*ing
(which, actually, I define not simply as plot-driven but as a combination
of plot-driven and system-driven, usually by necessity)? And, as an extension
off of this question, if MAGE is not suitable, why? And, more specifically,
is it salvageable if it is not suitable?
JKF
Hmm. Dave, I agree: not everyone is a programmer. I'm no comp sci major
and I barely know how to use UNIX at all. My talents, if any, lie in
other areas, but this doesn't stop me from wanting to contribute. If I
can't go code a weather system, that doesn't stop me from saying "yo, I'd
really like a weather system." If enough people say "yo, I want a weather
system," people might sit down and start coding.
I can also sit here at my computer and muse speculatingly about what a
weather system might entail. For example, I presume that you'd need to go
through an entire TinyMUCK dbase and set all rooms to either inside,
outside, or exposed (such as a porch). Then you'd need to set an altitude
property on each room so that higher elevations got colder weather. You
might also have to set a longitude-latitude prop and delegate someone to
map the world so that areas would receive the appropriate longitude-
latitude prop. Once you had each area set in terms of whether it was
indoor, outdoor, or exposed, had an elevation, longitude, and latitude,
you'd be ready to start your program running. The program could also be
set up to read properties off each room in order to have climactic
zones... you could take a desert and set a property reducing the
probability of rain by 90%. Your program would be set up to interact with
each of these properties and provide corresponding weather spoofs once
every ten minutes, perhaps.
These are just my surface thoughts on weather on a TinyMUCK... I don't
doubt that a further discussion could revamp my thoughts into something
workable. Then perhaps all it would take is getting a few people to sit
down and code. People who can't code can help out the people who do by
working out exactly what it is they want and suggesting algorithms for
doing it. Don't sell the people who don't hack code short. They can have
an effect also.
Lydia Leong
>Lydia Leong mentions that MUCK's MUF might be better suited for large global
>systems. I've heard that "MAGE" combines MUSH and MUF into a single system.
MAGE isn't used, because, IMHO (and the opinions of a fair number of other
MUSH people - I don't know about MUCKers), MAGE sucks. I believe Moira's
FAQ says, "Interesting idea, really busted code."
MAGE is basically MUCK with MUSH bludgeoned and/or stapled in. Very little
of the ichor spilled in the process has been mopped up, and the server
apparently continues to shriek in pain from the indignity of the entire
operation.
I'm being rather generous when I say that MUSH has been bludgeoned into
the server. The level of MUSH available in the MAGE server is approximately
equivalent to TinyTIM two years ago (i.e. almost all the features you know
and love aren't there); in fact, the docs that come with MAGE include the
ancient Croaker MUSH manual. The "MUSH" in MAGE bears about as much
resemblance to a modern PennMUSH 1.50 or TinyMUSH 2.0 version as the
Wright brothers' airplane does a 727.
The code is also incredibly ugly and undoubtedly buggy; glancing through
it earlier, I saw a couple documented MUSH coredump bugs which were
happily carried over into MAGE.
MAGE doesn't give you enough MUSH functionality to actually make it
*useful* for anything that you'd normally try to program in MUSH. Most
of the things you can do with MAGE's "MUSH" are easier done using MUF.
In the context of MAGE, MUSH is most useful for getting quick 'n dirty
results: it's quicker to type :[strlen(my test string)] than to write
a MUF program to do it. The MUCK functionality in MAGE is considerably
better than the MUSH functionality, since the server is based off
TinyMUCK 2.2.
The present version of MAGE is better than the earlier ones, both in
terms of stability and features, but it's still a long, long ways off
from having any really useful MUSH features. For the coding of complex
systems, straight MUCK or MUSH is still better, by far. I doubt that
MAGE will *ever* have anything approaching the full functionality of
current MUSH servers, since server size considerations come into play.
MAGE for dynamic MU*s? Forget it. I could see - *maybe* - MUCKers
trying MAGE instead, but I can't see MUSHers who aren't familiar
with MUCK and don't want to deal with MUF being able to program
anything worthwhile in the current version of MAGE.
Hsu I-wei
>systems. I've heard that "MAGE" combines MUSH and MUF into a single system.
MAGE combines _some_ of MUSH with MUCK. I believe it was released over 1.5
years ago, so it was basically alot of the stuff of a pre-MUSE version of
MUSH(0.8?) kludged ontop of MUCK 2.2. So it doesn't have nearly all the
features of MUSH 2.0 (ie. no semaphores, zones, object inheritance) nor do
I think it should encompass every MUSH feature (or else you're talking one
bloated server). You can do much more with the MUF programming language than
with the MUSH verbs/functions, but there are some important areas where MUSH
wins, and MAGE covers most of them(I hope).
>Has anyone looked at this variant as a possibility for use in dynamic MU*ing
>(which, actually, I define not simply as plot-driven but as a combination
>of plot-driven and system-driven, usually by necessity)? And, as an extension
>off of this question, if MAGE is not suitable, why? And, more specifically,
>is it salvageable if it is not suitable?
As for suitability I don't know.. MUCK has advanced a fair amount, during the
period when development of MAGE code was non-existant. If the current versions
of MUCK (fb and daemon) are not suitable, then chances are that MAGE isn't
either. As for salvageable, I hope so because I'm trying to salvage it! The
next version of MAGE(1.2) will be a rekludge of MUSH on top of MUCK 2.3 (don't
release it until after finals or else I'm screwed! ;). I will be taking a
look at MUSH 2.0 to see what newer features/changes, if any, I should add this
time around.
>
> Geoff Tuffli
> The Green Griffin
Francis
Hsu I-wei
>In article <1992Dec2.0...@midway.uchicago.edu>
> tu...@midway.uchicago.edu writes:
>>Lydia Leong mentions that MUCK's MUF might be better suited for large global
>>systems. I've heard that "MAGE" combines MUSH and MUF into a single system.
>>[ Question summarized: is this good for "dynamic" MU*s, and why/why not? ]
>
>MAGE isn't used, because, IMHO (and the opinions of a fair number of other
>MUSH people - I don't know about MUCKers), MAGE sucks. I believe Moira's
Now if the MUSH people would elaborate on exactly why MAGE (1.1 please) sucks,
I'd like to know so that I can take care those deficiencies in the next
version.
>FAQ says, "Interesting idea, really busted code."
Yup, and the busted code (ie. version 1.0) has been fixed and made stable (more
stable than MUCK 2.2 at least).
>
>MAGE is basically MUCK with MUSH bludgeoned and/or stapled in. Very little
True.
>of the ichor spilled in the process has been mopped up, and the server
If you mean that there have been no improvements/big fixes, this is completely
false. I spent many, many hours cleaning up 1.0. The big problem was that
for a year after 1.0 came out, nobody worked on improving MAGE code. So it
got filed away and mostly forgotten except for a reputation of crappy code and
being unstable. The unstable part has been taken care of for the most part.
>apparently continues to shriek in pain from the indignity of the entire
>operation.
>
>I'm being rather generous when I say that MUSH has been bludgeoned into
>the server. The level of MUSH available in the MAGE server is approximately
>equivalent to TinyTIM two years ago (i.e. almost all the features you know
>and love aren't there); in fact, the docs that come with MAGE include the
True, only a small part of MUSH is in MAGE. To put all of MUSH 2.0 ontop of
MUCK would be overkill. I really would like to know what features of the
more recent MUSH that are important/powerful would be nice to have in the
next version of MAGE.
>ancient Croaker MUSH manual. The "MUSH" in MAGE bears about as much
>resemblance to a modern PennMUSH 1.50 or TinyMUSH 2.0 version as the
>Wright brothers' airplane does a 727.
>
>The code is also incredibly ugly and undoubtedly buggy; glancing through
Aye, I'll concede the ugliness. Unfortunately, no one would salvage it so
there's only me.
>it earlier, I saw a couple documented MUSH coredump bugs which were
>happily carried over into MAGE.
Hmm.. now these bugs I definitely would like to get taken care of. (assuming
you are talking about the current version...)
>MAGE doesn't give you enough MUSH functionality to actually make it
>*useful* for anything that you'd normally try to program in MUSH. Most
>of the things you can do with MAGE's "MUSH" are easier done using MUF.
>In the context of MAGE, MUSH is most useful for getting quick 'n dirty
>results: it's quicker to type :[strlen(my test string)] than to write
>a MUF program to do it. The MUCK functionality in MAGE is considerably
>better than the MUSH functionality, since the server is based off
>TinyMUCK 2.2.
Yup, MAGE will continue to be MUCK foremost, with some of MUSH added in.
>The present version of MAGE is better than the earlier ones, both in
Thank you. (Though now that I realize you have been flaming the current
version all along, I actually feel worse :)
>terms of stability and features, but it's still a long, long ways off
>from having any really useful MUSH features. For the coding of complex
Hmm.. I have little experience with MUSH, but when I explore one, the things
that have I have found important in MUSH and lacking in MUCK are things like
objects being able to interact somewhat like players. This is probably the
most important part of MUSH I want in MAGE. As for a flag for every letter
in the alphabet, the spiffy @doing WHO list, commands such as @axyzsucc (an
exagerration).. those aren't going to be added for sure (I think). (Btw,
the spiffy @doing WHO list can be done in MUF in the current version + recent
patches ;)
>systems, straight MUCK or MUSH is still better, by far. I doubt that
I will disagree of course. There are alot of things you can do with MUF that
can't be done in MUSH. And there are a fair amount of things which can be done
much
>MAGE will *ever* have anything approaching the full functionality of
>current MUSH servers, since server size considerations come into play.
You're right.. it's not going to have all of MUSH in it, for the reason that
you give (and also because it would be creating unecessary redundancies)
>MAGE for dynamic MU*s? Forget it. I could see - *maybe* - MUCKers
>trying MAGE instead, but I can't see MUSHers who aren't familiar
>with MUCK and don't want to deal with MUF being able to program
Yes, I agree with your advice with qualifications. For beginning MUSHers
who CAN deal with MUF, I think that MAGE has its usefulness. Along with
MUCKers who have visited MUSHes and seen the ease at which certain things
are accomplished on a MUSH.
>anything worthwhile in the current version of MAGE.
:( I can only hope I will get a better review with the next version.
>
>-------------------------+----------------------------------------------------
>Lydia Leong, CSE '94 | C code. C code run. Run code run... please!
>l...@eniac.seas.upenn.edu | Backup not found: (A)bort (R)etry (P)anic
>l...@imsasun.imsa.edu | "man reboot" (-n option): Avoids the sync(1). It
>l...@csa.bu.edu | can be used if a disk or the processor is on fire.
>-------------------------+----------------------------------------------------
>
Francis
Geoff Tuffli
The reason I originally asked about MAGE (having heard only a very
little about it) came from the two problems I see about MUCK that an integrated
usage of MUSH might be able to solve. The first, as I understand it from
speaking with one of the gods of HoloMUCK, was that what you get with MUF
is increased flexibility at the cost of security, and thus one has to be
careful about giving out MUCKer bits. The second, and to my mind, possibly
more important (as the security issue seems to have been dealt with reasonably
well by most current successful MUCKs) involves the level of the language
of MUF. MUF, from what I have seen, is a considerably lower-level language
than is MUSH, and thus while certainly more flexible, for non-master coders
it can be much more difficult to learn to implement.
Now...second question, since MAGE is considered to be "good idea,
bad execution"...has anyone thought of trying something along that line
since MAGE? :-)
Lydia Leong
>The reason I originally asked about MAGE (having heard only a very little
>about it) came from the two problems I see about MUCK that an integrated
>lower-level language than is MUSH, and thus while certainly more flexible,
>for non-master coders it can be much more difficult to learn to implement.
I wouldn't necessarily call MUF a lower-level language than MUSH.
MUF is definitely a language, though - it's Multi-User Forth. MUSH is
really a primitive scripting language whose power has been increased
through brute-force additions - hardcoded new commands and functions.
From what I've seen, in most cases, it takes less MUSH than MUF to
write the same thing, with a couple of exceptions (the really big
MUF programs, like Foxen's MUFpage, which are heavily property-dependent).
MUF is *not* a difficult language, as far as I can tell. (I'm a
neophyte MUF programmer, with a knowledge of the basics; I've never
needed to know more.) It does take a bit more time to understand,
and you can't jump in and start fooling around right away, like you
can with MUSH. This probably discourages some people, especially since
there's a lack of good on-line MUCK help, and there's no manual/tutorial
which teaches more than the absolutely basics of MUF. On the other hand,
it's very easy to be a bad MUSH programmer.
I don't think it's any harder to learn MUF's stack-based mode of thinking
than it is to learn to _efficiently_ use MUSH's various functions and
commands (especially the list-processing ones).
> Now...second question, since MAGE is considered to be "good idea,
>bad execution"...has anyone thought of trying something along that line
>since MAGE? :-)
Combining MUCK and MUSH? Nobody's seen a point to doing it, I think.
(Nobody wants a server that gigantic.) As for other servers:
Well, there's Unter... I've really liked what I've seen of it so far,
although I'm a tad disappointed that there's no manual for the U
programming language, which is C-like in syntax. It's not big on
feeps, though, and isn't really designed to build hulking big systems.
There's also MOO, which, like MUCK, is fully programmable; it's very
powerful, and combines most of the standard Tiny syntax with other
stuff designed to facilitate object-oriented programming. This is
probably the single best thing out there for building really complicated
systems. It's more difficult to learn than MUSH, though.
I still think that if you want to build a MUD with complicated systems,
you're better off writing a server from scratch, with all your favorite
feeps built in from the start. (Do you want weather? Make sure your server
has support for 'cron'-type jobs. Do you want combat? Make sure the database
layer supports that efficiently. Etc.)
-- Amberyl@PernMUSH / Polgara@Belgariad / etc.
Foxen
>Aug. 91: Crossroads MUCK. High-quality building and puzzles stressed.
> An economy, an LP-mud-style role-playing/comabt system, and many,
> many MANY other things were present on this MUCK. Other things,
> like a MUD University, were planned. Unfortunately, the game
> lagged so much that it was nearly unplayable, and eventually
> went down due to site problems.
*sigh* Nine months in the building, and it lasted 5 after it opened.
Well, at least it is remembered in nice terms here. Thanks.
>I believe that one of the reasons that it's taken this long to reach
>the level of (perhaps extreme) complexity that Mua'Kaar is aiming for
>is the lack of server support for complex systems. Crossroads had to
>hack a large number of things directly into MUCK; unfortunately, the
>result was severe server lag.
Actually the server hacks sped the server up. The reason it lagged so
much was that it was running on a Sun 3/60 (underpowered) at a university
with a bad net connection.
>MUCK (at least the Crossroads server) ...
The current version of the server derived from the CrossRoads MUCK code
is TinyMUCK 2.2fb4.2. It's available for anony ftp at ftp.apple.com in
pub/fb.
- Foxen
--
___ __ ___ _ . _^^ ____ fo...@netcom.netcom.com
\ / | | \ | | | -> '-" \______/___/ Yet Another Furry Fan (YAFF!)
`v' |-- |--< |--- `v' ' ,| _____ | "Support the Church of the
| |___ | \ | o //|| ||| Holy Fur of Ilura!"
Ken Arromdee
>>Aug. 91: Crossroads MUCK. High-quality building and puzzles stressed.
>> An economy, an LP-mud-style role-playing/comabt system, and many,
>> many MANY other things were present on this MUCK. Other things,
>> like a MUD University, were planned. Unfortunately, the game
>> lagged so much that it was nearly unplayable, and eventually
>> went down due to site problems.
>*sigh* Nine months in the building, and it lasted 5 after it opened.
>Well, at least it is remembered in nice terms here. Thanks.
You don't want to start arguments over this again. Trust me.
--
"the bogosity in a field equals the bogosity imported from related areas, plus
the bogosity generated internally, minus the bogosity expelled or otherwise
disposed of." -- K. Eric Drexler
Ken Arromdee (arro...@jyusenkyou.cs.jhu.edu, arro...@jhunix.hcf.jhu.edu)
JKF
>>Aug. 91: Crossroads MUCK. High-quality building and puzzles stressed.
>> An economy, an LP-mud-style role-playing/comabt system, and many,
>> many MANY other things were present on this MUCK. Other things,
>> like a MUD University, were planned. Unfortunately, the game
>> lagged so much that it was nearly unplayable, and eventually
>> went down due to site problems.
>
>*sigh* Nine months in the building, and it lasted 5 after it opened.
>Well, at least it is remembered in nice terms here. Thanks.
>
>>I believe that one of the reasons that it's taken this long to reach
>>the level of (perhaps extreme) complexity that Mua'Kaar is aiming for
>>is the lack of server support for complex systems. Crossroads had to
>>hack a large number of things directly into MUCK; unfortunately, the
>>result was severe server lag.
>
>Actually the server hacks sped the server up. The reason it lagged so
>much was that it was running on a Sun 3/60 (underpowered) at a university
>with a bad net connection.
Well, Foxenbabe, why not bring Crossroads back? Find a better site, put
it up, pare down the sloppy building that was showing up toward the end,
and let it go? Given that Tom, Dick, and Harry keep putting up their own
revolutionary TinyMUCKs with absolutely atrocious building (Hi, Chronos!),
we could always use a TinyMUCK with *decent* building to show off to
people. It could even become a tutorial MUCK.
jim miller
arro...@jyusenkyou.cs.jhu.edu (Ken Arromdee) writes:
>In article <1992Dec3.1...@netcom.com> fo...@netcom.com (Foxen) writes:
>>>[...] Crossroads MUCK [...]
>You don't want to start arguments over this again. Trust me.
Joel? Joel??
--
>Are not Tom Bombadil and Beorn the same guy?
Nope. Reasons:
...
(c) Tom does not periodically turn into a bear.
Jennifer Smith
>[ Following up on the "is anyone doing anything other than socializing
> on TinyM*s? ]
>Interesting developments in the history of TinyM*s:
>(the dates below are public openings)
>Jan. 91: PernMUSH. This is the first Tiny that strictly enforced a theme,
> as far as I know. PernMUSH stresses in-character social interaction.
> Any plots are generally short-term and "local" to the characters
> involved. Most players have a definite "job" and place in the world.
Actually, wrong. :) It was the *third* Tiny that strictly enforced a theme -
the first two died horrible unlamented quiet deaths. TwinPeaksMUSH and
SanctuaryMUSH (based on the Thieve's World series) ran sometime between
late 90 (August, Sept-ish) and Jan 91. They both were built on (Sanctuary
mostly; some really rather neat things on there, actually), but both got
many complaints about having only one theme! Too restrictive, boring, not
fun - those were the general complaints. And so, people quit playing them,
and they were shut down. PernMUSH was the third strict-theme Tiny, and it's
survived so far. :)
--
Jennifer Smith
j...@math.okstate.edu
On MUDs: Moira, RosaLil, Jasra, etc. | It's the terror of knowing
Here, have a clue. Take two, they're small. | What this world is about
Bryant Durrell
>In <100...@netnews.upenn.edu> l...@disco.seas.upenn.edu (Lydia Leong) writes:
>>[ Following up on the "is anyone doing anything other than socializing
>many complaints about having only one theme! Too restrictive, boring, not
>fun - those were the general complaints. And so, people quit playing them,
>and they were shut down.
Maybe for Sanctuary. PeaksMUSH got closed down because the head
wizard and other wizards were too busy with other things to pay
attention to details like giving out links, and when it started
crashing the head wizard didn't really wanna bother dealing with
code problems. Whatta doof.
(So it was me. Nobody's perfect.)
--
Bryant Durrell dur...@chop.isca.uiowa.edu
------------------------------------------------------------------------------
I feed on the flesh of the living, and I vote.
Foxen
>
>Well, Foxenbabe, why not bring Crossroads back? Find a better site, put
>it up, pare down the sloppy building that was showing up toward the end,
>and let it go? Given that Tom, Dick, and Harry keep putting up their own
>revolutionary TinyMUCKs with absolutely atrocious building (Hi, Chronos!),
>we could always use a TinyMUCK with *decent* building to show off to
>people. It could even become a tutorial MUCK.
>
Firstoff, it isn't my MUCK to bring back. I was just a wizard and
programmer there.
Other than that, though, on the technical end, the MUF code used to build
most of XR is now rather dated or obsolete. I don't think anyone who was
on the project wants to redo everything to upgrade it.
On the administrative end, we don't have a site for it, though that could
probably be fixed.
On the social end, I don't think most of the people who were on the
project want to deal with the various headaches, nightmares and problems
that were rampant. There are a lot of bad feelings tied up in there.
And that is all that I am willing to say about that, so don't ask for
clarification.
Personally, I have no intentions of being a wizard on a major MUCK again,
as it is an absolute royal pain in the ass. I had more than enough on
FurryMUCK.
These reasons and more are why I doubt that CrossRoads MUCK will ever
see light of day again, except perhaps on Brigadoon Day. 'Nuff said.
jason downs
>These reasons and more are why I doubt that CrossRoads MUCK will ever
>see light of day again, except perhaps on Brigadoon Day. 'Nuff said.
awe, come on! just give it to Hurin to run.
--
\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-/
\ - jason downs - /\ - dow...@atlantis.CS.ORST.EDU - /
/ zeppelin/amiga release 2/insane guy \/ led/vasudeva/lord of fear of death \
/-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\
Ken Arromdee
>>These reasons and more are why I doubt that CrossRoads MUCK will ever
>>see light of day again, except perhaps on Brigadoon Day. 'Nuff said.
>awe, come on! just give it to Hurin to run.
Sure, why not. He has, after all, shown interest in acting there as a wizard
in the past.
--
"The writer wrestling with an uneasy soul. Turbulent in its uncovering,
cathartic in its expression. Huang is a sensitive this age of the world has
not seen."
-- auzzie about dirque
Ken Arromdee (arro...@jyusenkyou.cs.jhu.edu, arro...@jhunix.hcf.jhu.edu)
Snooze
In article <Byp31...@math.okstate.edu> j...@math.okstate.edu (Jennifer Smith) writes:
>In <100...@netnews.upenn.edu> l...@disco.seas.upenn.edu (Lydia Leong) writes:
>>[ Following up on the "is anyone doing anything other than socializing
>[...] but both [Sanctuary and PeaksMUSH] got
>many complaints about having only one theme! Too restrictive, boring, not
>fun - those were the general complaints. And so, people quit playing them,
>and they were shut down.
Maybe for Sanctuary. PeaksMUSH got closed down because the head
wizard and other wizards were too busy with other things to pay
attention to details like giving out links, and when it started
crashing the head wizard didn't really wanna bother dealing with
code problems. Whatta doof.
(So it was me. Nobody's perfect.)
ahh...peaksMUSH...those were the days...
Looking for some coffee...
Agent_Cooper
JKF
>
>arro...@jyusenkyou.cs.jhu.edu (Ken Arromdee) writes:
>
>>In article <1992Dec3.1...@netcom.com> fo...@netcom.com (Foxen) writes:
>>>>[...] Crossroads MUCK [...]
>
>>You don't want to start arguments over this again. Trust me.
>
>
>Joel? Joel??
>
Who? Me?
Naw, auzzie, I don't really feel like flaming the people from Crossroads.
Sure, their hype about the system outweighed the actual worth of the
system (with unbelievable lag times and frequent downage) by about ten to
one... it was amazing, reading the ads that popped up here and there and
then going to Crossroads and finding it down or so unbelievably lagged
that commands took fifteen minutes to go through. This is the biggest
reason why I feel you shouldn't start advertising things until you have a
product ready to go... I feel sorry for the people who spent months
getting it ready and had their work rendered valueless by a bad site.
Mark Crother
What about virtual classrooms? I see MU*s as a great way to teach. If
fact I will be try out this idea soon on my machine.
--Mark
Scott Howard
IMHO Mage was a very quick hack. Byte has gone quite a ways in making
MAGE more stable. I took most of the MUSH functions and incorporated
them into the latest public version of DaemonMUCK. I then wrote
MUF versions of @listen, @ahear, etc, etc, etc. I belive that you'll
find that this type of server has ENORMOUS potential. Unfntly, I havn't
seen ANYONE using it. Oh well.
--
The opinions expressed are not necessarily those of the University of
North Carolina at Chapel Hill, the Campus Office for Information
Technology, or the Experimental Bulletin Board Service.
internet: laUNChpad.unc.edu or 152.2.22.80
Edward L. Wallace
tu...@ellis.uchicago.edu (Geoff Tuffli) writes:
> Now...second question, since MAGE is considered to be "good idea,
> bad execution"...has anyone thought of trying something along that line
> since MAGE? :-)
I've seen a couple ideas come down the road in my short tenure (I
started in August of '91) on the net.
* MOOSE - this was an attempt by koosh to write MOO and MUSE together.
He got pretty far, as I understand it -- even having written a
MUSE-like queue. This is second or fourth or tenth hand tho', so I
dunno how accurate the information is. It was eventually discarded as
inefficient. I guess if you want something that does what MUSE does..
use MUSE. If you want something that does what MOO does.. use MOO; was
the reasoning (wow! Watch him murder punctuation!)
* MUF w/MUSH hacks. I don't know squat about MUF. I don't have the
time to learn a new language even if I could find a place to give me a
bit to learn with. Perhaps sometime in the future I'll learn it.
Apparently this system has met with limited success - I guess the
people who use the MUCK with the additions are mostly MUCK users and
therefore don't really get thrilled by the MUSH additions. Not sure on
this one's status, it was posted awhile back.
* MOO w/MUSE interpreter. This is a project I'd love to see actually
work. Being able to have a nice strong server like MOO which could
have a simple (or not so simple, given MUSE's parser) scripting
language for those who weren't interested in doing more than: @va
Toy=$spin top:@emit @whee.. fun fun fun. -- would provide me personally
with the best options. I could spend my time taking advantage of MOO's
power, and other people could spend their time not learning MOO and
yet, still maintaining some of the 'fun' they can have on MUSH and
MUSE. This is an ongoing project and has a very dedicated person
working on it. Far as I know, he's getting functions to evaluate. In
other words: progress has been made. The end isn't anywhere in sight,
however.
I long to see a server which provides two levels of 'code', if you
will. One, a scripting language like MUSH or MUSE which could be
available as a stepping stone to nonprogrammers, or simply something
for people who want nothing more. And two, a more powerful language on
par with MUF or MOO which would afford people some more flexibility.
If anyone finds something which can do this, and do it *well*, let me
know.
Falryx @ most places
--
Ted Wallace '93 - Dept. o' Fizix and Astrolo..er.. astronomy
Marcus J. Ranum
>I long to see a server which provides two levels of 'code', if you
>will. One, a scripting language like MUSH or MUSE which could be
>available as a stepping stone to nonprogrammers, or simply something
>for people who want nothing more. And two, a more powerful language on
>par with MUF or MOO which would afford people some more flexibility.
UnterMUD does this in several ways. There is support for
easily extending the environment or writing local commands and nifty
objects using 3 different languages:
C - obviously. But the MUD server is designed to make
it really easy to add new system-wide commmands into
the server code, for complex stuff where speed is needed.
U - This is a derivative of the U programming language
from UberMUD. There are a few quirks in the implementation
(such as that everything has to go on one line, which I
find unaesthetic in the extreme) but it's quite useable.
You can either write U code attached to objects or rooms
(or locks - a lock can be a program) or "system wide"
U routines. U is a "real" programming language in the
sense that it's compiled and then interpreted, not
interpreted as text. It's also somewhat more verbose
and structured that something like MUSH-speak.
Macros - UnterMUD also supports the ability to have "macros"
which act much like shell aliases or shell scripts. An
UnterMUD macro is basically a sequence of user-level
commands that is fed to the command interpreter as
if you, or the room, or the object, typed them in by
hand.
The U and Macro interfaces are closely linked. U-code can call
macros and vice versa. A Macro, called from U looks like a function call.
U-code called from a Macro looks like an ordinary command, and so forth.
It was difficult to get the integration right - I'm not sure it was a
100% success, but it's a pretty fair attempt.
mjr.
jason 'Think!' steiner
> Edward.L...@dartmouth.edu (Edward L. Wallace) writes:
>
> >I long to see a server which provides two levels of 'code', if you
> >will. One, a scripting language like MUSH or MUSE which could be
> >available as a stepping stone to nonprogrammers, or simply
> >something for people who want nothing more. And two, a more
> >powerful language on par with MUF or MOO which would afford people
> >some more flexibility.
>
> UnterMUD does this in several ways. There is support for
> easily extending the environment or writing local commands and nifty
> objects using 3 different languages:
>
> from UberMUD.
>
> which act much like shell aliases or shell scripts.
have the macros been improved at all in the last 6 months or so?
i tried logging onto an Unter once 'cause it sounded interesting.
the macro language gave me some -real- troubles. when i asked for
help on it, even the guy running the mud couldn't do what i wanted.
if anything, the macros are -more- difficult to use than U. U is
great, BTW, but with a hopelessly complex macro system and a full
fledged programming language Unter doesn't really have anything for
intermediate players.
jason
--
`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`
`,` "Stark raving sane." -- Rosencrantz & Guildenstern Are Dead `,`
`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,`,` jste...@anwsun.phya.utoledo.edu ,`,`,`
Snooze
it's fast, disk based...and distributed
yay!
snooze
Hsu I-wei
Does anyone have a list of CoolMUDs in existence? Are there even any
implementations with the functionality of a generic TinyMUD? (ie. any builder
can @lock, provide a way for others to take over ownership of an object
they created, etc.) Are there any implementations with the functionality
of a MUSH? MOO? MUCK?
The only CoolMUD I've visited appears to barely be approaching the
functionality of a generic TinyMUD.
Francis
Marcus J. Ranum
>have the macros been improved at all in the last 6 months or so?
>if anything, the macros are -more- difficult to use than U. U is
>great, BTW, but with a hopelessly complex macro system and a full
>fledged programming language Unter doesn't really have anything for
>intermediate players.
I haven't touched a line of code in Unter in ages. Formal
development of the MUD has basically stopped, though for all I know
people are out there somewhere hacking away at it.
The macros wound up becoming overcomplex because initially
Unter wasn't *going* to have a programming language. What happened,
of course, was that everyone insisted that this bit of functionality
be added, or that bit, in order to make it more "usable", and pretty
soon the macros got unwieldy. If I was going to do it all over again,
I'd have left the whole macro capability out. It'd actually not be
too hard to remove from the server, but I just didn't feel like it.
There's a lesson in all this (*) I think. When you're writing
a MUD it's never enough to include just what you think it needs. Once
it comes into use all kinds of stuff will get added, whether it makes
sense or not. Therefore, eliminate design constraints that would
prevent your MUD from being used in ways you didn't design it to,
and make sure that there's as much modularity as possible so that
it takes a minimum of hammering to add new stuff. Adding the U code
interpreter to Unter meant adding 20 lines to the existing code
base, and linking in the interpreter and related modules.
mjr.
(*) I am, by now, one of the foremost experts in writing MUDs that
nobody likes to use. I'm still trying to figure this out.
Ken Arromdee
>I long to see a server which provides two levels of 'code', if you
>will. One, a scripting language like MUSH or MUSE which could be
>available as a stepping stone to nonprogrammers, or simply something
>for people who want nothing more. And two, a more powerful language on
>par with MUF or MOO which would afford people some more flexibility.
>If anyone finds something which can do this, and do it *well*, let me
>know.
One problem with this is that it encourages policies of not actually allowing
people to use the powerful language, on the grounds that they already have a
language which is good enough (and who cares if it's unwieldy....)
NM156
all this talk about coding and servers exposed my gross ignorance ... i've
got two questions: where is an ftp site that has a manual for the current
MUSH command/coding system?
and...
is there anything (from a user's-view perspective) that can be implemented
in U or Moo or MUSH that cannot be implemented by a determined MUF hacker with
very minor server modifications if neccessary? i would include with this:
anything that is so computationally ridiculous when implemented in MUF that
it just shouldn't exist.
i'm just curious ... if someone were to have enough time and dedication to
actually sit down and implement the MU* of their dreams, with all the super-
keen features they can dream up, is there anything (other than convenience
and style) that would keep her/him from just slugging it out in the MUF pits?
deep down traumahound
--
Ingredients: chopped pork shoulder with ham, salt, water, sugar, sodium
nitrate, snar...@leland.stanford.edu
T. Lesher
>
>all this talk about coding and servers exposed my gross ignorance ... i've
>got two questions: where is an ftp site that has a manual for the current
>MUSH command/coding system?
Sure. caisr2.caisr.cwru.edu has it, under /pub/mush. I think you
want mushman.2.005.shar.Z, cuz as far as I know, it's the latest
version (right, Amberyl?) It's a good language, even if it _does_
look, as one has suggested, like "line noise". :)
>is there anything (from a user's-view perspective) that can be implemented
>in U or Moo or MUSH that cannot be implemented by a determined MUF hacker with
>very minor server modifications if neccessary? i would include with this:
>anything that is so computationally ridiculous when implemented in MUF that
>it just shouldn't exist.
>i'm just curious ... if someone were to have enough time and dedication to
>actually sit down and implement the MU* of their dreams, with all the super-
>keen features they can dream up, is there anything (other than convenience
>and style) that would keep her/him from just slugging it out in the MUF pits?
Maybe speed. I've been tossing around the idea of a Mu* server that
would compile stuff instead of interpreting raw text, but since I have
my hands full with real (? can I say that?) MUSH plotlines right now,
in addition or RL finals, I haven't the time. Maybe something on the
order of LPC, but with a more MUSH-like server and game system.
Also, I doubt that admins of a site are particularly willing to tweak
Mu* server code just so a player's Sooper kOOl Item will work. I
think, in these cases, that the opposite question is relevant: is
there anything that a clever MUSH programmer can't do that you could
do in hardcoding? Intuitively, I'd say, "Yes", but I've shot
down every non-trivial example I can think of that a normal (non-wizardly)
player might want to do... any takers? (BTW, I'm talking about things
that are patently impossible, not just difficult, kludgy, or ssllooww,
in MUSH code).
--
Tim Lesher <les...@bucknell.edu>
Hsu I-wei
>In article <1992Dec7.0...@dartvax.dartmouth.edu> Edward.L...@dartmouth.edu (Edward L. Wallace) writes:
>>I long to see a server which provides two levels of 'code', if you
>>will. One, a scripting language like MUSH or MUSE which could be
>>available as a stepping stone to nonprogrammers, or simply something
>>for people who want nothing more. And two, a more powerful language on
>>par with MUF or MOO which would afford people some more flexibility.
>>If anyone finds something which can do this, and do it *well*, let me
>>know.
You might want to consider looking at TinyMAGE 1.1. The thing is, if you find
it inadequate in certain areas, you email me and I'll try to be helpful in
getting those features added. If I don't get feedback, then I have to guess
which features of MUSH are the most important and powerful. And I'm very
inexperienced with MUSH...
The next version of MAGE (1.2) will be TinyMUCK 2.3 (which will hopefully
come out before winter break!?) with parts of MUSH 1.50 and 2.0 (as per
recommendations from a couple of MUSH coders, thanks again) added in. The
current programmability of MAGE is that of MUSH at about 1.5 years ago, in
combination of MUF. In my opinion, what you can do with both in cooperation
is much greater than the sum of the parts.
>
>One problem with this is that it encourages policies of not actually allowing
>people to use the powerful language, on the grounds that they already have a
>language which is good enough (and who cares if it's unwieldy....)
Such a policy ultimately depends on the wizards who run the mud. I'd rather
have a simpler easy-to-use language along with the more powerful and have
faith that wizards won't all of the sudden turn fascist, than not have it
at all.
And in some cases, having different "levels" of programming power can actually
encourage wizards to open up access to more players. I would venture to guess
that FurryMUCK is more generous about giving out M bits now that they have
several levels of Muckers. Sure alot of people are going to be denied access
to the higher levels at first, but once they really become proficient (and
show a desire to write something besides a teleport program) I doubt they'd be
denied it.
>--
>"the bogosity in a field equals the bogosity imported from related areas, plus
>the bogosity generated internally, minus the bogosity expelled or otherwise
>disposed of." -- K. Eric Drexler
>
>Ken Arromdee (arro...@jyusenkyou.cs.jhu.edu, arro...@jhunix.hcf.jhu.edu)
Francis
Marcus J. Ranum
>in U or Moo or MUSH that cannot be implemented by a determined MUF hacker with
>very minor server modifications if neccessary? i would include with this:
>anything that is so computationally ridiculous when implemented in MUF that
>it just shouldn't exist.
That's a meaningless question. Any programming language with a
reasonable set of necessary operations can be used to write just about
anything, if you're willing to suffer the pain of doing it. Especially
if that means "very minor server modifications".
The questions, in my mind, are:
a) will the result be readable
b) will the result be efficient
c) will the result be so ugly that vogons get sick when they
look at it?
The way I always looked at MUDs is basically that they're a symbol
table with a network interface. There are some meta-rules ("universe rules"
in UberMUD-speak) that control what players think they can do. Some MUDs
have the ability to dynamically alter the universe rules. Others code them
in C. Basically, if you give programmatic access to the internals of the
symbol table, then you can do anything you like. For example, Unter and
Uber both let the wizard manipulate the contents of any arbitrary value in
the system, thus permitting any kind of weirdness imaginable. Most of the
programmable MUDs seem to permit some kind of internal server access.
mjr.
Marcus J. Ranum
Matthew J Brown
This highlights, really, the problem with the MOO and CoolMUD way of
doing things. The servers, out of the box, are more-or-less unusable.
Such servers are really little more than a programming language with a
kind of 'operating system' for it to run on, handling tasks,
player connections etc. Because of their very flexibility, writing a
useable MUD from scratch (ie. starting with the server and a
bare-bones database) is very difficult. The minimal.db included with
MOO, for example, requires you to enter the code for an expression
evaluator, and build the rest from that.
A related problem, of course, is that because such things as @lock are
not part of the server, but instead are database-defined mechanisms;
however, the programmers who are writing the database will not
generally use such a high-level construct themselves, but will instead
write special-case code each time. Only non-programmers will really
*need* an implementation of @lock. Programmers would, in general,
rather spend their time writing nifty things for themselves.
It is for this reason that you'd probably never find a Tiny-emulator
system in such a MUD that is all that advanced; certainly you'll
probably never find an implementation of MUSH scripting and macros.
Anyone who wants to become a power-user on such a MUD has to become a
programmer.
There is also the point, of course, that CoolMUD is still (I believe)
in an experimental stage, and it hasn't been around very long.
-Matt
--
| Matthew J. Brown | Dept. of Computing | If God intended for us to go to |
| m...@doc.ic.ac.uk | Imperial College, | lectures He wouldn't have created |
| mj...@cc.ic.ac.uk | 180 Queen's Gate | double-sided photocopiers. |
| Morven on Lambda | LONDON SW7 2AZ | -IC RagMag 1991/92 |
Marcus J. Ranum
>Maybe speed. I've been tossing around the idea of a Mu* server that
>would compile stuff instead of interpreting raw text
It's been done. In fact, you can get a considerable space savings
if you do something like UnterMUD used to do, and compile the source code
for a user program down to bytecodes that you then write on disk. A multi
kilobyte player program generally compiled down to ~250 bytes or so, plus
the string space. Uber even packed string space, doing substring compression
where possible. I have no measurements for how much that may have saved,
but it imposed no overhead so what the hell...
Speed is a *big* advantage of something that compiles. Especially
if you use the Uber approach, and only compile stuff *once*, ever, and
then just execute from the precompiled bytecodes. This made loading a
function both efficient and fast - "subroutine" calls involved something
like setting 4 ints and 2 pointers. Unter uses a yacc-based parser to
build disposable parse-trees. Slower by far, but it means you don't
throw away the player's source code (which used to really irritate them).
>is
>there anything that a clever MUSH programmer can't do that you could
>do in hardcoding? Intuitively, I'd say, "Yes"
Is there any reason why an intelligent person should jump through
all the hoops to write anything nontrivial in an abominable language like
MUSH?
I'm sure that it's probably impossible to write a MUD running
*inside* the MUD. Andrew Molitor actually had a kind of weird MUD-in-a-MUD
a couple of years back in Uber. It had infinity-spaces represented as
point co-ordinates, movement, and a whole mess of other weird stuff,
and actually ran just as fast to the eye as the MUD itself (though since
he did a lot of recursive stuff, I could actually see the load meter
move a little when he was playing around in it).
mjr.
Hsu I-wei
>
>This highlights, really, the problem with the MOO and CoolMUD way of
>doing things. The servers, out of the box, are more-or-less unusable.
>Such servers are really little more than a programming language with a
>kind of 'operating system' for it to run on, handling tasks,
>player connections etc. Because of their very flexibility, writing a
>useable MUD from scratch (ie. starting with the server and a
>bare-bones database) is very difficult. The minimal.db included with
>MOO, for example, requires you to enter the code for an expression
>evaluator, and build the rest from that.
Well, the LambdaMOO implementation of MOO quickly surpassed the functionality
of TinyMUD. When I first created a character there (#595.. a while back),
it already had all TinyMUD did from a user's perspective plus more. Thus,
when someone advertises a MOO and compares it with other mud implementations
I don't question it. Snooze, on the other hand, seems to be comparing CoolMUD
on par with MOO and other advanced variants of TinyMUDs. Sure it's disk-based,
and distributed, but what can an average user accomplish on a CoolMUD? If
the only CoolMUD I've visited is the implementation which has progressed the
furthest, then I really can't see how you can, at this time, put it on the
same level as other types of Tinys. (Generic TinyMUD, maybe, at most.) If
someone else has a more advanced implementation of CoolMUD up and running
(and public), I'd like to know so that I can see that CoolMUD _users_ really
have something brag about.
>
>It is for this reason that you'd probably never find a Tiny-emulator
>system in such a MUD that is all that advanced; certainly you'll
>probably never find an implementation of MUSH scripting and macros.
>Anyone who wants to become a power-user on such a MUD has to become a
>programmer.
>
>There is also the point, of course, that CoolMUD is still (I believe)
>in an experimental stage, and it hasn't been around very long.
Good points. Although do you not consider MOO to be such a "Tiny-emulator"
system? (I don't know exactly how much is built-in to the core server.) Or
is it that you don't consider MOO to be all that advanced.
>
>-Matt
>
>
>
>--
>| Matthew J. Brown | Dept. of Computing | If God intended for us to go to |
>| m...@doc.ic.ac.uk | Imperial College, | lectures He wouldn't have created |
>| mj...@cc.ic.ac.uk | 180 Queen's Gate | double-sided photocopiers. |
>| Morven on Lambda | LONDON SW7 2AZ | -IC RagMag 1991/92 |
Francis
Snooze
Bingo...also...I am trying to put a bit of TinyMUD like stuff in, like
locks...but it's not something that one does over night (well...if I didn't
have to work for a living maybe... ;)) Crystallium should have locks within
bout 2 weeks...I've got half of it done on paper...just need to pound it
into the mud.
/ There is also the point, of course, that CoolMUD is still (I believe)
in an experimental stage, and it hasn't been around very long.
CoolMUD is still being written...but so far it works fairly well with almost
no bugs. That' we've found...
come try crystallium: 132.241.1.43 8888
-Matt
snooze
Judy Anderson
>doing things. The servers, out of the box, are more-or-less unusable.
>Such servers are really little more than a programming language with a
>kind of 'operating system' for it to run on, handling tasks,
>player connections etc. Because of their very flexibility, writing a
>useable MUD from scratch (ie. starting with the server and a
>bare-bones database) is very difficult. The minimal.db included with
>MOO, for example, requires you to enter the code for an expression
>evaluator, and build the rest from that.
>
Actually, LambdaMOO comes with the LambdaCore, a rather complex set of
existing objects and verbs from which it is reasonable to build a
world without an enormous amount of substrate coding. Sure, you'll
have to write code to support your world, but by no means are you
starting "from scratch". And if what you want to do is really
different from the LambdaCore, then indeed you might be better off
starting from scratch. But if you want to do something really
different, probably you didn't want *any* of the existing servers such
as MUSE, so you can't really complain that LambdaCore isn't serving
your needs.
Pavel Curtis has done quite a lot of work making sure that the MOO
server *will* work out-of-the-box on a variety of systems.
Judy Anderson yclept yduJ 'yduJ' rhymes with 'fudge'
yd...@symbolics.com yduJ on LambdaMOO
LambdaMOO is lambda.parc.xerox.com [13.2.116.36] 8888
Join the League for Programming Freedom, l...@uunet.uu.net
JKF
Just curious, snooze, but what *is* CoolMUD? It sounds like no CoolMUD
would seem much at all like any other CoolMUD because the 'universe rules'
and things that you have to build on top are going to be different each
time... as far as I can tell, CoolMUD is analogous to TinyMUCK 2.2 with
no commands of any sort but *with* MUF.
If this is the case, what's the big deal about CoolMUD? Sounds like a
Radio Shack Build-Your-Own-Server kit but missing the instructions.