So what *SHOULD* future MUDs do?
amol...@eagle.wesleyan.edu
>
>>What do you think MUDs should be able to do 2 years from now?
>
> They should be able to provide an Infocom-like textual reality
> in which the users can fool themselves into believing they're really
> there. This implies that the MUD will have to have a very powerful
> programming language which can simulate reality as closely as possible;
> putting a pen on paper should cause the paper to get written on,
> dropping your lunch on the floor might cause your fine fish sandwich
> to smudge the carpet, etc. The MUD should be easy enough to use
> and understand that Joe Art History can walk on and be generating
> reality without giving up on the process first. Tidbits like
> distributivity are not, in my opinion, as important as low cpu
> footprint, power, and especially ease-of-use.
This sounds interesting. I gather one or more of the UK servers
can do this sort of thing, the derivative(s) of MUD. This kind of
descriptive power seems incompatible with easy extensibility by Joe Art
History, though. Did I misread?
>>What would your ultimate MUD server be able to do? And why?
>
> It would contain enough artificial intelligence to be able to fill in
> minute details; for instance, every object in every desc would be
> recognized whether or not the object 'existed' as an instantiated
> data item in the server, and it would provide well-written accounts
> of what happened whenever I performed an action. The accounts would,
> of course, be different most every time.
I think this would be hard to do 'right', but it might well be possible
to work up something in some sense 'quick and dirty' that would provide almost
the same. _vide_ Julia. She converses almost convincingly, but is just a
great pile of templates to match against (I think -- my apologies to mlm
if I am misrepresting her). I'd be interested in hearing about ideas for
prototypes.
>>What is the single most important thing that makes a MUD good? And why?
>
> currently, its ability to act as a chat program. Ideally, its
> easy extensibility.
Extensibility in aid of what? Escapism, I presume?
> * fills in details using some form of AI (currently doable)
Tell us more. I think you know more about this than anyone else
currently, uh, contributing. Does that whatsit you worked on do something
like this?
> * database-editing server separate from database-exploring server
> (currently doable)
This is an interesting idea. You're saying 'build it under one server,
play it under another'? That's very innovative, at least for those of us
raised on the Tiny* line.
> * fast (doable, for the exploring server)
Err, this depends on the AI jazz above, surely?
> Felix
It's interesting to note your emphasis on building and exploring.
Do you believe that Tiny* derived (literally and spiritually) servers
suffer from a lack of both because people don't want to, or because the
tools for doing it well enough don't exist? If the former is true, then
your notions constitute wasted effort.
One space after periods.Conserve bandwidth.
Andrew
Marcus J. will do TCP/IP for food Ranum
Ok, now that we've worked ourselves into a real frenzy over
what does or does not constitute a good MUD server, let's talk about
the future. Now that we've all agreed that current servers are just
re-inventing the wheel, let's talk about what the next few great
steps to take in MUDs are.
Obviously, this isn't a discussion just for server hackers -
what *IS* the next step? What problems need to be solved? *DO* any?
Are MUDs going to just be glorified chat programs until they get
shut down, or is the chat stage a temporary mark on the way to something
else?
Comments? Let's try to at least stick with things that are
currently do-able (though maybe hard) and that within the next 2 years.
(EG: yeah, 3d video and sensory feedback'd make things interesting but
that's a little future still) Where I use the word "MUD" below, I am
talking specifically about servers and server functionality - it's
impossible to factor in the creativity of the folks who build things.
--------
What do you think MUDs should be able to do 2 years from now?
What are the biggest problems with the current generation of MUDs?
What would your ultimate MUD server be able to do? And why?
(to put comments in perspective) What purpose do you see in MUDs?
What is the single most important thing that makes a MUD good? And why?
If you could put together a server with a wave of a magic wand,
describe it.
mjr.
Felix Ortony
> Obviously, this isn't a discussion just for server hackers -
woo.
>--------
>What do you think MUDs should be able to do 2 years from now?
They should be able to provide an Infocom-like textual reality
in which the users can fool themselves into believing they're really
there. This implies that the MUD will have to have a very powerful
programming language which can simulate reality as closely as possible;
putting a pen on paper should cause the paper to get written on,
dropping your lunch on the floor might cause your fine fish sandwich
to smudge the carpet, etc. The MUD should be easy enough to use
and understand that Joe Art History can walk on and be generating
reality without giving up on the process first. Tidbits like
distributivity are not, in my opinion, as important as low cpu
footprint, power, and especially ease-of-use.
>What are the biggest problems with the current generation of MUDs?
They've been written, in the main, by people who don't have much
imagination or skill. TinyMUD is limited; MUCK is bloated and
not disk-based; MUSH is a heap; LP is a slow bad idea; Aber is
limited; Uber is a bit too heavy; Diku is LP wearing a leather mask,
and Unter is great, but has painful quirks. The main problem with
MUDs in general is that they no longer encourage towards their
purpose; TinyMUD got away with lots of building and fun and interesting
data because it was so fresh, new and vibrant. Current MUDs, lacking
that freshness, need to actively encourage building in a non-hard,
non-tacked-on way.
>What would your ultimate MUD server be able to do? And why?
It would contain enough artificial intelligence to be able to fill in
minute details; for instance, every object in every desc would be
recognized whether or not the object 'existed' as an instantiated
data item in the server, and it would provide well-written accounts
of what happened whenever I performed an action. The accounts would,
of course, be different most every time.
>(to put comments in perspective) What purpose do you see in MUDs?
escapism.
>What is the single most important thing that makes a MUD good? And why?
currently, its ability to act as a chat program. Ideally, its
easy extensibility.
>If you could put together a server with a wave of a magic wand,
>describe it.
* accepts english language building commands (currently doable)
* fills in details using some form of AI (currently doable)
* database-editing server separate from database-exploring server
(currently doable)
* self-generating database (the outlook is hazy, ask again later)
* fast (doable, for the exploring server)
Note that when I say 'doable', I don't mean to imply that a mud could
open TODAY in which you could type "if a player walks in carrying the
red fish, open up a pit which drops him into the dragon's lair." I
mean that the state of the art has made parsing that possible, and
that there exist machines which could handle that level of detail.
>mjr.
Felix
--
a b c d e f g h i j k l m n o p q r s t u v w x y z
Felix Sebastian Ortony for...@murphy.gis.uiuc.edu
jason downs
amol...@eagle.wesleyan.edu writes:
>In article <fortony.706768594@murphy>,
> for...@murphy.cs.uiuc.edu (Felix Ortony) writes:
>> * database-editing server separate from database-exploring server
>> (currently doable)
>
> This is an interesting idea. You're saying 'build it under one server,
>play it under another'? That's very innovative, at least for those of us
>raised on the Tiny* line.
sounds a hell of a lot like how building is implemented under AberMUD V.
obplug: Glory (AberMUD 5.16) -> cs.pdx.edu 5000
--
\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-/
\ - jason downs - /\ - dow...@cs.pdx.edu - /
/ zeppelin/amiga release 2/insane guy \/ led/vasudeva/lord of fear of death \
/-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\
Marcus J. will do TCP/IP for food Ranum
>>What do you think MUDs should be able to do 2 years from now?
>
>They should be able to provide an Infocom-like textual reality
>in which the users can fool themselves into believing they're really
>there. This implies that the MUD will have to have a very powerful
>programming language which can simulate reality as closely as possible;
>putting a pen on paper should cause the paper to get written on,
>dropping your lunch on the floor might cause your fine fish sandwich
>to smudge the carpet, etc.
Yeah, this'd be really cool. The biggest problem is that
as far as I can tell, this level of functionality almost exists
today - the real bottleneck is creating those worlds and doing
the simulation stuff right. Infocom games are just very large
state machines (sort of) - the're limited but can appear to be
really detailed. Future MUDs need to be able to contain the same
kind of detail without requiring the huge amount of bookkeeping
writing an Infocom game must require.
I recall reading someplace that when Infocom (actually,
this was the bunch that did the adventure game for Suns - the
something-or-other condor) designed their games, they'd make
what amounted to a massive state map of the whole game. I just
can't imagine putting that kind of effort into a MUD adventure,
where I think MUDs of the future need to grow is in allowing
rapid prototyping.
Definitely, closer natural-language-like parsers will
need to be developed, IE: "write 'foo' on paper with pen" should
change the paper's description as appropriate.
On the other hand, how much realism is necessary? The
team cthulhu MUD had pretty impressive functionality in this
regard but I found that I really wasn't that interested in
using it socially. It'd definitely be more appealing for a
hard-core adventurer's MUD.
If the observation that "LP and Diku seem to be the most
popular MUDs around" is correct, then it's worth figuring out
why and what can be done to help it. Would a MUD server that
had tools to basically act as a D&D-style gamemaster be best?
That'd be interesting..
>>What would your ultimate MUD server be able to do? And why?
>
>It would contain enough artificial intelligence to be able to fill in
>minute details; for instance, every object in every desc would be
>recognized whether or not the object 'existed' as an instantiated
>data item in the server, and it would provide well-written accounts
>of what happened whenever I performed an action. The accounts would,
>of course, be different most every time.
This would be neat, but I haven't even a clue of how to
begin developing such a thing. You'd maybe be able to make some
progress by somehow parameterizing objects, but I suspect you'd
get some pretty laughable algorithmic slips of the tongue.
"You're in a a large open room, with a huge bed and french windows.
There are exits to the west"
>look out window
"The window looks out to the west, and you can see The Garden"
It'd be interesting to be able to do stuff like that (the
example assumes there was no description for the window, so it
took the name of the destination) - a lot of this would require
that the "topology" (to abuse the term) be regular.
>* self-generating database (the outlook is hazy, ask again later)
I always thought a hack'n'slash MUD that build dungeon-levels
a-la nethack would be kind of amusing.
mjr.
Johan Andersson
>
> Ok, now that we've worked ourselves into a real frenzy over
> what does or does not constitute a good MUD server, let's talk about
> the future. Now that we've all agreed that current servers are just
> re-inventing the wheel, let's talk about what the next few great
> steps to take in MUDs are.
>
Ok, I'll bite. For me a MUD is a simple text interfaced virtual world. The
next generation of MUDs should be better virtual worlds.
There is three essential parts that I think need to be considered:
- The interface to the players
- The interface to the creators
- The simulation model used in virtual world.
As what we are describing is a MUD, lets assume that the interface is based
on text. Furthermore lets assume that player and creator is two roles,
possible assumed by the same user.
For the players, the keyword must be 'believability'. The world model must
be able to make itself believable through the interface to the user, this
means that the range of actions the interface allows the user must result
in responses from the world model through the interface that are in some
sense realistic and complete.
For the creator, the keyword must be 'freedom'. A creator must not be
limited by the design of the world model. Anything conceivable should be
possible to implement.
To fulfill the 'believability' demand the simulation model must probably
be based on something other than 'responses to commands'. A simplified
simulation of newtonian mechanics should probably be an essential part
of the model, including of course a Euclidean geometry.
So, how to achieve this?
First, let me disagree a bit with Felix. I think the three basic ideals
of LPmud is a correct first step. (That it doesn't exactly work this way
is another matter) These are:
- Everything is objects.
- It is object interaction that contitutes the game.
- There is nothing else, all information reside within objects.
The server should have no concept of the game. It should merely execute
code within objects. There are compromises to this in LPmud.
Concordingly, the 'room' concept must be generalised. The server should
have no knowledge of containment or any other relation among objects. The
HITLab people have a nice 'space' concept, that it would take some time
to explain, offering a solution to this problem.
Secondly, for players, the fixation around commands and parsing must be
lift out from the world model into the interface. We must diffrentiate
between intentions and actions. This is were Felix AI code fits in nicely.
Intentions are what the player sends in text form to the interface.
Actions are transformations to the world model, described in a formal
language, perhaps pure mathematics.
Can this be simplified?
The above describes a general virtual world. It could when technology
allows it be interfaced with all sorts of fancy VR equipment. The limits
of a text interface can be allowed to cause simplifications in the
model. The more limited an interface, the less complexity needed in the
model to achieve believability.
I won't digress more than this right now. I'm intrested in participating
in further discussions on this subject.
/Johan
--
Johan Andersson | "You don`t have conversations with microprocessors
Chalmers, Sweden | you tell them what to do, and then you helplessly
Email: | watch the disaster when they take you literally."
d8a...@dtek.chalmers.se | Sah`ot in David Brins "Startide Rising"
Peter Lucas
be as one of the first crude steps toward cyberspace, construed as an
alternate realm of reality--built of data and visited by people who go there
to work, play, and otherwise interact with each other and with the data.
What MUDs bring to the net that other database servers or chat programs
don't is a sense of PLACE. You don't just USE a MUD, you GO to one, and
can BE in it.
In terms of this vision, extreme realism is of little value. Stained
carpets and elaborate "limb-based" combat systems that can record
a superficial flesh wound 5cm above the left elbow are cute, but mostly
a waste of effort--beyond a certain point (which has probably already
been reached) such features simply add complexity without really adding
functionality or contributing all that much to the sense of place. A fairly
abstract physics (as long as it is consistent) is good enough for now.
On the other hand, capabilities like inter-MUD travel and network-wide
objects are on the critical path toward turning the net into a place.
I want to be able to develop a single character as my network alter-ego--
a persona with a stable set of "physical" and personality characteristics;
with posessions (tools, toys, data objects) which I can carry around the net
and share with others. I want to be able to create agents who can roam the
net on my behalf and do useful work for me in my absence.
A lot of this stuff is potentially not that far off. If 1/10 of the effort
currently being expended on producing new code that is no more interesting
than the old (or spent flaming on this list) were direced toward simple
goals along these lines, we could get there pretty quickly. As for the
next two years, here are some suggestions:
1) Work on network-wide object persistence. Unter seems to be on the right
track here; but it will be just an interesting experiment until standards
get hammered out that can reasonably be implimented across game
architectures. A simple object description language with a set of standard
object attributes plus "private" server-specific data would be a start.
Lots of issues here, but it's time to work on them.
2) MUDs need to become more self-regulating; i.e., they need real economies.
Almost all current MUDs are run like the Soviet Union (central planning,
values of goods assigned arbitrarily, etc). We've seen where that leads.
A simple market in which the values of objects within a game is determined
by supply and demand would permit prices to contain information about
players' judgments of the intrinsic value of objects. Interesting and useful
things would retain their value, junk wouldn't. In such an environment,
change would be much more likely to be for the better, rather than just
random.
3) MUDs need to become more useful. I have nothing against escapist role-
playing as a a reason for using MUDs, but if they are to earn their keep
on the net in the long run, we should aspire to more. Be creative.
For example, how about a NetNews MUD? It could have rooms for each newsgroup,
with a bulletin board in each one. Related groups could be geographically
close to each other. Players with similiar interests would tend to meet
each other in the rooms of interest to them, thus combining the archival
quality of NetNews with the interactivity of chat programs. KnowBots
could watch the boards on behalf of players, reporting back interesting
findings. Combined with network-wide objects, I could tear off interesting
messages and take them back to my home MUD with me, or give them to
my friends.
Keith C. Estanol
one, I'm concerned mostly about the social impact that MUDs
will have, and how their social and group interaction will
change. MUDs are still an evolving society, with primitive
controls on behavior, that can be changed in the future.
At the moment, MUDs are ruled with a primitive type of
government, namely that of totalitarianism, and not one of
the more complex and higher evolved government.
Will MUDs develop along the lines of human history? They
seem to be changing more and more each day. Will we have to
deal with virtual red tape?
Maybe what we'll see is something new and different
happening on MUDs. But then again, people don't change very
much, and it takes a long time for them to change, if at
all. I for one, would like to hear more discussion on this.
That's it for now.
Keith C. Estanol | st...@ucsd.edu
UCSD, Cognitive Science | st...@ucsd.bitnet
Time Traveller Wizard's Council,
Wanted: An office with a window, and a SPARCstation
------------------------------------------------------------
"You can choose from phantom fears or kindness that can kill.
I will choose a path that's clear, I will choose free will!"
- Rush -
Marcus J. will do TCP/IP for food Ranum
>1) Work on network-wide object persistence. Unter seems to be on the right
>track here; but it will be just an interesting experiment until standards
>get hammered out that can reasonably be implimented across game
>architectures. A simple object description language with a set of standard
>object attributes plus "private" server-specific data would be a start.
>Lots of issues here, but it's time to work on them.
There are a HUGE number of issues and we looked at a lot of them
back when Unter was first on the drawing board, scratched our heads, and
decided to punt. Off the top of my head, the biggest problem with inter-MUD
object exchange is conceptual -
On some MUDs, attributes of objects have no relation or direct
mapping to attributes on other MUDs. Most objects will have some kind
of name and description attribute, but what about locks? Contents lists?
Just figuring out how to portably represent a list is a very very hard
problem, since some MUDs might do lists completely differently from
others. There's also the problem of inheritance in the object-oriented
MUDs...
We looked at the data representations of the various MUDs
out there, and most of the Tiny*-like ones were similar (though
some, like all the ones written by that Ranum guy, have slightly
odd decisions) but a lot of the LP and other MUDs are really very
different beasts inside. Even among the Tiny-like MUDs, just to
give an example, some MUDs incorporate the room's player list and
objcet contents list in the same list - others like Unter separate
them out. To do portability, you'd need a suite of conversion
filters on each side of a MUD-to-MUD link... Owch. ...And then
there's all the extension languages...
mjr.
Ron A. 5150 Echeverri
Prevent cracking to a minimum. Reduce lag (ie machine lag, not net lag).
Still be fun. Have "Qualified" gods (not teenagers with attitudes)
>What are the biggest problems with the current generation of MUDs?
Easy to crack. Laggy (they seem to be mounted on TRS-80's for chrissakes).
After a while they can get REAL dull. Some gods have terrible attitudes about
helping mortals.
>What would your ultimate MUD server be able to do? And why?
Run @50MHz or even 100. Have incredible amounts of memory. Back itself up every
day or every half day (depending on traffic). Great security. A responsible
Admin who actually spends time on the MUD (this is a BIG thing i've seen...
the actual 'owner' of the server is almost NEVER on)
>(to put comments in perspective) What purpose do you see in MUDs?
What purpose do you see in living?
Who gives a @!#$!@#? just play the game if you want to.
>What is the single most important thing that makes a MUD good? And why?
Good players. A good playing space. A good environment (includes mud features,
gods, etc)
>If you could put together a server with a wave of a magic wand, describe it.
My magical server. *wave wand* Ta-da! Sell it to ya for 10mil coins, a set
of banded mail and an orb of annhilation.
--
"All this machinery making modern music \ Ron Echeverri-BSCS 1995
Can still be open-hearted. \ Univ. of So. Cal.
Not so coldly charted, it's really just a question \______________________
Of your honesty, yeah, your honesty." - Rush, 'The Spirit of Radio'
Ron A. 5150 Echeverri
>They've been written, in the main, by people who don't have much
>imagination or skill. TinyMUD is limited; MUCK is bloated and
>not disk-based; MUSH is a heap; LP is a slow bad idea; Aber is
>limited; Uber is a bit too heavy; Diku is LP wearing a leather mask,
Heh. GUess what. This is an opinion.
Calling Diku an "LP wearing a leather mask" is like calling a BMW a "Yugo
wearing a leather mask"
Marcus J. will do TCP/IP for food Ranum
The other day I came up with this idea for what I've been calling
a futureMUD - I believe it's technically feasible to write it, but I also
doubt very much that I'm going to try. On the other hand, I'll stick my
neck out by just tossing the idea out to see how it sounds. If anyone
tells me to "get a keyboard" I will ask them to have their seconds
email mine with choice of weapons and location.
Rationale and motivation:
-------------------------
MUDs that interoperate seem to be a kind of a holy grail - lots
of people will nod and say "yeah, that's what I want" but nobody seems
to have a good idea what one should look like, and what the tradeoffs
in implementation should be. On one hand, everyone thinks that a net-wide
distributed MUD should look like a local one for all intents and purposes,
completely ignoring the fact that such a beast will perforce be completely
different from the current run-of-the-MUD. A whole new set of tradeoffs
comes into play.
Clearly nothing's going to satisfy everyone, but a lot of MUDs
have a "must have" criterion for programmability, action at a distance,
and some kind of permissions. In order to implement such a thing across
a net-wide MUD, a completely different approach will be needed, and it
will have to:
a) scale well
b) be efficient [though we admit and accept that it will be less
efficient than a purely local case]
c) be reliable
d) support action-at-a-distance (remote who, remote paging,
remote action, remote object action)
Is this even possible?
----------------------
Probably not. That shouldn't stop anyone.
Tradeoffs:
----------
A net-wide MUD is clearly going to have to be meta-programmable
and at least to some degree written in itself. It will need a fairly
rich basic language, to deter localizations from breaking interoperability.
This is a foolish hope, since it's inherently impossible to have everyone
running at the same release level, so the MUD must be capable of at least
theoretically interoperating with a variety of releases and even other
MUDs (to some slight degree).
In order to do this, it stands to reason that very strong data
hiding protocols will need to be in effect, and (unfortunately) it's
likely that nonlocal action will be expensive, requiring multiple
network transmissions in order to work.
Ideally the server's internals will be completely hidden from
the user or even the wizard - wizards should be able to deal with the
server just at its meta-programmed level. To make up for this, the
server will need some pretty darn nice "mudlib" - and possibly the
ability to share one base "mudlib" over the entire network. (note
this makes bootstrapping "a trick")
First cut at a design:
----------------------
UnterMUD's design is inherently backwards. Rather than sending
the data from server to server, future MUDs need to support what
amounts to inter-server procedure call. If done properly, the end
result will LOOK THE SAME.
Object-Oriented systems like Smalltalk use a "message" model of
programming. IE: no function calls, a given object sends another a little
bundle of data and expects it to do something interesting with it. That
object may in turn do something else with the bundle but at that point
it's no longer your problem, unless you ask it to reply, of course.
The entire MUD server, then is a support system for messaging
and message-routing between objects residing either on the local server
or somplace on another (possibly running, possibly not) server. Basically,
the design of the MUD is very much like a small message-passing operating
system. Each player "thread" has a running context of some sort that
is scheduled by a thread scheduler, being woken up and put to sleep as
various event occur. Some actions a thread may take would cause it to
be put to sleep pending an event. Clearly events such as timers and
interrupts (and interrupt handlers) would be needed, and, of course,
user input from the monkey at the keyboard would be a type of event.
A thread is associated with an object, and its "virtual address
space" is the attributes of that object. [typical OOP stuff]
Threads would have a variety of primitives that they could
perform (basically analogous to system calls) - which would either
block the thread, leave it runnable, or kill the thread off. Some
kind of fork semantics would be nice [address the locking issue with
hand-waving, though since calls are in kernel mode and we aren't a
real operating system we don't have to worry about hardware level
interrupts].
All operations that required action on another object are
done smalltalk-like, by sending a message to another object.
There are several kinds of message operations:
-> send a message and don't necessarily expect a response
-> send a message and put the thread to sleep until it gets a
response from the object the message was sent to
-> send a message and put the thread to sleep until it gets a
response from the object the message was sent to
and do not disable other incoming message processing
-> send a message to multiple targets (multicast)
-> send a message to multiple targets (multicast) and wait
for a response from *one* of the targets
Unlike every single existing MUD, message passing is not necessarily
synchronous. (EG: send a message and wait for a response versus send a message
and keep processing) The server is expected to deal with and dispatch messages
as it gets them in whatever order it wants. Thus the MUD is inherently a
threaded server - a player could (if they wanted to) do something and let
it wait 10 minutes to take effect (by sending a message to an object that
will sleep 10 minutes and then forward the message)
The MUD makes distinctions between objects that are in its local
database, versus objects that are in remote databases, using a naming
scheme like Unter's. Thus, action at a distance is supported. Picture
3 people talking in a room. Player 'A' is on MUD 'Amud'. Players 'B' and
'C' are on 'Bmud'. They're all in a room on 'Cmud'
Player 'A' sends a message to the room (444@Cmud): "say 'foo'"
this message need not block Player A's thread so he can
leave the room if he wants, or whatever.
Room eventually gets message and (basic speech) multicasts it to
all the players in the room. This means sending one
message to A@Amud, and another message to B@Bmud,C@Bmud
Amud gets the message for A@Amud and queues it into A's thread
as some kind of a basic echo-text message, which shows
up eventually on A's tty, hopefully a few hundred
milliseconds later.
Bmud gets the message for B@Bmud and C@Bmud and queues it to
them, if they're live.
This example deliberately glosses over several important
problems, such as that you don't really want to multicast messages
to players that aren't logged in - but that's an issue in the design
of the "universe rules" not the MUD server. Presumably when a
player connected they might send their local room a message
saying that they wanted to receive speech. There are lots of
options for handling these kinds of cases.
Remote whisper/page and whatnot will work. It would be quite
trivial to build an object that you operate on in one MUD that then
changes things someplace else. A simple example of a radio controlled
tank would have the controller send a message with timeout to a tank
requesting it to do something, and the *controller* (not the player)
thread would be blocked waiting for a response from the tank or until
a timeout expired.
This messaging MUD would be built on top of UDP datagrams
(obviously) instead of connected sockets. No more connected player limits.
Some kind of protocol for authentication would be nice - this is an
open design issue.
The matter of what happens when the network is down has some
real problems, I realize - presumably the people who write the internals
for the universe rules will need to address what operations are important
to get an ack back from, and what are not. Speech is disposable, but
walking from room to room is not. (walking consists of:
Player 'A' sends a message to room: "go east"
Room replies "no exit east"
-or-
Room replies "you are now in <##> through exit <##>"
Player sends a (no ack needed) message to exit "east" that it has been
used
Player sends a (ack needed) message to destination "I have arrived"
etc...)
Conclusions:
------------
The design presented here is a blue-sky concept for how a future
MUD might be implemented. Note that by using a message-passing approach,
local operations will still be very quick and reliable, though remote
operations and action-at-a-distance will still work.
Multiple transmits per operation is not particularly elegant for
remote operation, but still would be feasible. There would be a definite
cost (400ms or so) for complex actions requiring multiple messages. Room
to room movement between MUDs would *STILL* be faster than in the Unter
case and is more reliable, since no objects actually move. Ever.
Debugging universe rules would be a project right from hell.
Universe rules would need to carefully handle race and deadlocks
by making very few operations require a synchronous response. On the
other hand, if "mudlib" calls ran in the *player* object context, and
attempt for a player to do something involving a MUD that was down
would simply block the player's thread - everyone else keeps running
and in fact the player would be able to still hear and whatnot while
their thread was blocked.
@find would still not be reasonable to implement. ;) Local @find
would be.
mjr.
Marcus J. will do TCP/IP for food Ranum
>Will MUDs develop along the lines of human history? They
>seem to be changing more and more each day. Will we have to
>deal with virtual red tape?
You were never on Islandia, were you?
mjr.
Keith C. Estanol
Actually, I was, but I suppose I wasn't very observant of
Islandia politicking. I just thought it was very silly at
the time. Ahh..
eri...@mit.edu
[good ideas deleted]
> 3) MUDs need to become more useful. I have nothing against escapist
role-
> playing as a a reason for using MUDs, but if they are to earn their keep
> on the net in the long run, we should aspire to more. Be creative.
> For example, how about a NetNews MUD? It could have rooms for each
newsgroup,
> with a bulletin board in each one. Related groups could be
geographically
> close to each other. Players with similiar interests would tend to meet
> each other in the rooms of interest to them, thus combining the archival
> quality of NetNews with the interactivity of chat programs. KnowBots
> could watch the boards on behalf of players, reporting back interesting
> findings. Combined with network-wide objects, I could tear off
interesting
> messages and take them back to my home MUD with me, or give them to
> my friends.
>
> -plu...@andrew.cmu.edu
I just wanted to say that I agree with you 100% here. This issue to me is
more important than how the underlying server is written. How MUDs are
used has and will continue to shape how MUD drivers are designed.
Currently, most people think of them as a game and nothing more. Until
this changes to some degree, we won't see significant leaps in server
designs.
I see MUDs as the ultimate interface to computers. What they are, is a
natural way to represent practically any activity you would want to do on
a computer, whether it is a news forum, a place for world wide
conferencing, group software development, home shopping, whatever. Think
about what computer software companies are promising out of their
software: easy to use interface which is still powerful, transparent
network connectivity, etc. You name it, MUDs have it now. It's really
kind of funny when you think about it.
Anyway, I'll keep this short because I could ramble on for hours on this
subject. I just finished writing my thesis on just this topic (I
developed a MUD where users could get personailzed news, and could read
different kinds of news based on the room that they were in, etc.). The
thrust of thesis talks about MUDs as an alternative interface to most
things that you might want to do with a computer. So rather than just
spew about it here, if you're interested in hearing more, drop me a line.
(I might take a little while to get back to you, sorry)
Erik
Wayfarer @ {Portals, MIRE, TMI, Overdrive}
Chris Siebenmann
| popular MUDs around" is correct, then it's worth figuring out
| why and what can be done to help it.
It strikes me that one core difference between the average Diku/LP
and the average TinyM* is that the former is a game, while the latter
is a society. I find it unsurprising that more people play a game than
participate in a new society. I also suspect that a game MUD will be
noticably differently constructed than a society MUD (for example,
world consistency is probably a much bigger thing in a game).
--
"I generally sing second tenor. When I try for counter
tenor, it always ends up being of the bargain variety."
- lyd...@sol1.gps.caltech.edu (Speaker to Minerals)
c...@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
Chris Siebenmann
| To fulfill the 'believability' demand the simulation model must probably
| be based on something other than 'responses to commands'. A simplified
| simulation of newtonian mechanics should probably be an essential part
| of the model, including of course a Euclidean geometry.
Why are people so intent on (re)creating only the real world? Think
big. A simulation of cyberspace probably has highly non-Euclidean
geometry, and the notion of rooms placed in a 'space' that people can
understand seems rather suspect for a sorceror's home (or a high-tech
dwelling; cf., say, Dan Simmon's HYPERION).
Walker Aumann
> I always thought a hack'n'slash MUD that build dungeon-levels
>a-la nethack would be kind of amusing.
That's funny, so did I. So did a couple of my friends. However, due to
current workload and impending graduation, check back with us in about
9 months.
ObReligionAboutMUDs: Step one in making a *good* mud, with many of the
features described above (like making the pencil write on the paper),
is that after one assembles a *small* group of people to code this thing
(two or three being about optimal), one goes to the mudlib directory
(speaking in LP terms), and types 'rm -rf *'. Death to D&D combat systems!
>mjr.
Walker Aumann "Beep beep beep Oh no, heavy. The coins keep
wal...@delilah.ccsf.caltech.edu coming out. Beep beep beep Even the
telephone hates me. Beep beep beep I wish
there were no machines and everyone lived a
pastoral existence. Trees and flowers don't
deliberately cool you out and go beep in
your ear." - Neil, "The Young Ones"
Chris Siebenmann
| Prevent cracking to a minimum.
Suggestions are welcome; anyone want to write up a compendium of
useful anticracking/antispam techniques? (beyond 'make sure your
server is bugfree')
As an observation, I've been through one cracking episode and one
spamming episode, and it's remarkable how few of the security measures
that were hastily proposed in their aftermath would actually have
helped. I'd be especially interested in the opinions of MUD admins
who've been through such things as to valuable security measures.
| Have "Qualified" gods (not teenagers with attitudes)
Donations and offers to pay people salaries are certainly welcome.
Unpaid volunteers are subject to quality-control problems, as it were.
Pros typically cost real money; it's why they're pros and not
amateurs.
| >What are the biggest problems with the current generation of MUDs?
| After a while they can get REAL dull.
Are there ingenious ways of beating this (if only to noticably
increase the time it takes to get bored) that don't involve continual
expansion of the MUD?
Jason Harvey Titus
wider range of goals then simply exp from hack and slash. I
personally prefer the user-friendly aspects of diku's, and see
that format as open to great modifications. Perhaps having
people fill roles in a huge city when they log on, and then
playing out the scenario of building up that city. IE - Your
choose to be city manager, or police chief, or gang lord,
whatever.
Or people could start out as average Joe, and just have
to finagle their way up. It just seems that the amazing thing
about muds is the ability to create another reality, with its
own set of rules and such. I would like to see a greater
diversity in the scenarios, as opposed to a greater freedom for
players to warp that reality. Thats great and all, but a
different thing from a role playing game.
Jason Titus - UVa
Johan Andersson
I wrote:
| To fulfill the 'believability' demand the simulation model must probably
| be based on something other than 'responses to commands'. A simplified
| simulation of newtonian mechanics should probably be an essential part
| of the model, including of course a Euclidean geometry.
In article <1992May26.0...@jarvis.csri.toronto.edu> c...@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes:
> Why are people so intent on (re)creating only the real world? Think
> big.
>
You got to learn to walk before you can learn to run.
If we are to model reality, lets start with something comparatively simple,
that everyone knows how it works. I assure you, it will be difficult enough
anyway.
> A simulation of cyberspace probably has highly non-Euclidean
> geometry, and the notion of rooms placed in a 'space' that people can
> understand seems rather suspect for a sorceror's home (or a high-tech
> dwelling; cf., say, Dan Simmon's HYPERION).
>
Using virtual reality, we are talking inclusive interface, no simple text,
but more or less vapor hardware, to let someone experience strange worlds
and geometries is a very neat idea, but face it, it won't happen in two years.
Frankly Chris, get off your high clouds of visionary imaginations. VR
suffers enough from excessive amounts of hype without yours adding to it.
To qoute an unknown source:
'Some people dream of accomplishing great things,
others stay awake and make them happen.'
Sorry if I sound harsh, but I've heard so much VR hype that I tend to choke
on it.
Simon Raboczi
>d8a...@hacker.dtek.chalmers.se (Johan Andersson) writes:
>| To fulfill the 'believability' demand the simulation model must probably
>| be based on something other than 'responses to commands'. A simplified
>| simulation of newtonian mechanics should probably be an essential part
>| of the model, including of course a Euclidean geometry.
> Why are people so intent on (re)creating only the real world? Think
>big. A simulation of cyberspace probably has highly non-Euclidean
>geometry, and the notion of rooms placed in a 'space' that people can
>understand seems rather suspect for a sorceror's home (or a high-tech
>dwelling; cf., say, Dan Simmon's HYPERION).
According to my understanding, the strength of a VR is supposed to be
that it translates a hard-to-understand data-space into something that
the user can relate to meaningfully. Having your VR accurately mirror
RL means that users can navigate intuitively, using familiar assumptions
about what will happen. It's not reality that's important as much as
familiarity...fantasy worlds with consistent internal physics probably
work even better. The notion of rooms placed in a 'space' that people
can understand may seem suspect, but it IS easier for people to
understand. :) Getting disoriented a lot kills the sense of "being
there".
--
,-_|\ Simon Raboczi (rab...@s1.elec.uq.oz.au)
/ * Department of Electrical Engineering
\_.--_/ University of Queensland, St Lucia
v Brisbane, Australia
CNB...@tamvm1.tamu.edu
(IMHO) aren't so good. These are the impressions of a player who
has never written a single line of code (perspective which should
be counted IHMO).
>carpets and elaborate "limb-based" combat systems that can record
I agree. The player's imagination must be allowed to create some of
the realism in the game.
>On the other hand, capabilities like inter-MUD travel and network-wide
>objects are on the critical path toward turning the net into a place.
perspective, part of the fun is being able to play different muds.
A happy medium in this area is probably the 'right' way to go.
>2) MUDs need to become more self-regulating; i.e., they need real economies.
>Almost all current MUDs are run like the Soviet Union (central planning,
>values of goods assigned arbitrarily, etc). We've seen where that leads.
>A simple market in which the values of objects within a game is determined
>by supply and demand would permit prices to contain information about
>players' judgments of the intrinsic value of objects. Interesting and useful
Excellant suggestion!
>3) MUDs need to become more useful. I have nothing against escapist role-
>playing as a a reason for using MUDs, but if they are to earn their keep
>on the net in the long run, we should aspire to more. Be creative.
suggestion goes along the same lines as muds that are nothing more
than chat machines. Those are not muds by defintion (after all,
what does MUD stand for?). I say keep it a game.
Now for a suggestion of my own. I really like muds like Vincent's
Hollow which have a class of levels instead of a single line of
levels a player advances in. More of these would be good.
----------------------------------------------
Chris Barnes |
cnb...@tamvm1.tamu.edu | "If guns are outlawed, only the
(409) 846-3273 (home) | government will have guns"
(409) 845-8454 (work) | (stolen quote)
Jeff Bone
>1) Work on network-wide object persistence. Unter seems to be on the right
>track here; but it will be just an interesting experiment until standards
>get hammered out that can reasonably be implimented across game
>architectures. A simple object description language with a set of standard
>object attributes plus "private" server-specific data would be a start.
>Lots of issues here, but it's time to work on them.
I fail to see where the Unter object protocol, OIF, fails in these respects.
OIF is MUD independant, and specifies exactly what you have described
above. If there's any criticism one can make of OIF, it might be that
the object model is relatively simplistic and "flat" (i.e., one level
of attributes, no support for "propdirs" or "attribute trees" or whatever)
but it's an excellent start. In fact, the doc in the U distribution
describes OIF independently of Unter itself; it was designed with
precisely the things mentioned in mind.
SUPPORT THE ANSI OIF STANDARDIZATION EFFORT! ;)
jb
--
-- Jeff Bone ------------------------------------------------------------
"Imagination is more important than knowledge." - A. Einstein
------------------------------------------------------- jb...@dell.com --
--
Russ Random Smith
->In article <fortony.706768594@murphy> for...@murphy.cs.uiuc.edu (Felix Ortony) writes:
->>They've been written, in the main, by people who don't have much
->>imagination or skill. TinyMUD is limited; MUCK is bloated and
->>not disk-based; MUSH is a heap; LP is a slow bad idea; Aber is
->>limited; Uber is a bit too heavy; Diku is LP wearing a leather mask,
->Heh. GUess what. This is an opinion.
->Calling Diku an "LP wearing a leather mask" is like calling a BMW a "Yugo
->wearing a leather mask"
Bear in mind this comes from the individual who one message back couldn't
distinguish between a MUD server program, and the machine it runs on.
--
=======================[Comedy! Sudden, violent comedy!]======================
+-------------Russ "Random" Smith----------...@okstate.edu--------+
| Godfather of the Random Gang; Diplomat of the Brotherhood of Evil MUDders |
+-----------------------------------------------------------------------------+
William Henry Timmins
I've thought about this... the only problem with this is that you either
need alot of people doing really dull jobs (ok... I go cut wheat. I go
to market. The miller mills it, and I sell the flour to ... etc), or you
have a HUGE list of autonomous beings doing it, with players being
nobles, or something.
This is an interesting idea I've yet to see implemented. You could have
areas which are 'fertile'. Autonomous 'npc's can wander, find somewhere
new to plant, plant, harvest, etc.
That would make such a mud a robot-domain, in which pcs could wander,
fight, and interact with the 'peasants.'
Sound interesting?
-Me
Daniel Crow
This sounds very interesting. We looked into implementing this kind of closed
economice model on our Mud recently and abandoned it for the moment as too
hard. We are running an LP, and one of the problems (which I believe is also
common to AberMUDs and probably other types too) is that there is in effect
an unrestricted source of objects of value: because items in LP are
regenerated every (usually 15-45) RL minutes, in order to get wealth under
a closed system you just wait for the item to reappear then sell it on. You
would risk getting into a cycle of hyperinflation. Without changing some of
the fundamental assumptions that underly LP you are going to have a fun time
sorting this out.
I am sure you are right that to get this sort of model running, you would
need (in effect) lots of automata which performed the menial (and essential)
tasks of the economy. The computational implications of this are non-trivial.
I also believe that a proper economic model would significantly enhance any
Mud which could successfully implement it.
Has anyone tried to do this, or thought through the implications more
thoroughly?
--
Dan Crow
dan...@scs.leeds.ac.uk
Scott D Anderson
> What I would like to see in the future muds would be a
>wider range of goals then simply exp from hack and slash. I
>personally prefer the user-friendly aspects of diku's, and see
>that format as open to great modifications. Perhaps having
>people fill roles in a huge city when they log on, and then
>playing out the scenario of building up that city. IE - Your
>choose to be city manager, or police chief, or gang lord,
>whatever.
Already exists, now, not future tense. The GodNet. Part role-playing,
part combat, part social mud. The combat and RPG system exists to
support and direct the social aspects. You can work your way into
any portion of the society there, performing whatever actions you
need to take to get to your own goals. Work with the CyberPriests,
or oppose them through the Underground True Church. Cast aside your
humanity and give in to the evil temptings of the Denizens of Hell.
Or just try to stay alive. Your choice.
Godnet is at morticia.cnns.unt.edu 7777
Baalzebub @ GodNet
--
CHOOSE CHEAP Scott Anderson
TWO: / \ san...@engin.umich.edu
/ \ Entropy at its finest:
FAST---------EASY "Spam, spam, spam! Wonderful SPAM!"
Scott Goehring
>ro...@skat.usc.edu (Ron A. "5150" Echeverri) writes:
[drivel deleted]
>Bear in mind this comes from the individual who one message back
>couldn't distinguish between a MUD server program, and the machine it
>runs on.
Not to mention the fact that he engages in USENET vandalism (I've seen
Ron cascading at least twice now).
--
Republicans understand the importance of bondage between a mother and child.
-- Vice President Dan Quayle
Magnus Holmberg
>m...@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>| If the observation that "LP and Diku seem to be the most
>| popular MUDs around" is correct, then it's worth figuring out
>| why and what can be done to help it.
> It strikes me that one core difference between the average Diku/LP
>and the average TinyM* is that the former is a game, while the latter
>is a society. I find it unsurprising that more people play a game than
>participate in a new society. I also suspect that a game MUD will be
>noticably differently constructed than a society MUD (for example,
>world consistency is probably a much bigger thing in a game).
I don't agree Dikus are only game and no society. At least
on the ones I inhabit, there is a lot of social interaction,
though perhaps a bit stratified. Players come and go, but
the immortal society is a quite complex one.
- MH a.k.a. Gimli
Felix Ortony
>In article <fortony.706768594@murphy>, for...@murphy.cs.uiuc.edu (Felix Ortony) writes:
>>
>>>What do you think MUDs should be able to do 2 years from now?
>>
>> They should be able to provide an Infocom-like textual reality
>> in which the users can fool themselves into believing they're really
>> there. This implies that the MUD will have to have a very powerful
>> programming language which can simulate reality as closely as possible;
>> putting a pen on paper should cause the paper to get written on,
>> dropping your lunch on the floor might cause your fine fish sandwich
>> to smudge the carpet, etc. The MUD should be easy enough to use
>> and understand that Joe Art History can walk on and be generating
>> reality without giving up on the process first. Tidbits like
>> distributivity are not, in my opinion, as important as low cpu
>> footprint, power, and especially ease-of-use.
> This sounds interesting. I gather one or more of the UK servers
>can do this sort of thing, the derivative(s) of MUD. This kind of
>descriptive power seems incompatible with easy extensibility by Joe Art
>History, though. Did I misread?
>
We've already got an arbitrarily powerful language which joe art history
can understand and use; it's called 'English.' The real problem is getting
regular little computers to understand English or some useful subset of
it. Currently, there are perfectly usable algorithms and indeed whole
engines which can translate english into predicate logic. I think MUDs
in the future will use these or something like these.
>>>What would your ultimate MUD server be able to do? And why?
>>
>> It would contain enough artificial intelligence to be able to fill in
>> minute details; for instance, every object in every desc would be
>> recognized whether or not the object 'existed' as an instantiated
>> data item in the server, and it would provide well-written accounts
>> of what happened whenever I performed an action. The accounts would,
>> of course, be different most every time.
> I think this would be hard to do 'right', but it might well be possible
>to work up something in some sense 'quick and dirty' that would provide almost
>the same. _vide_ Julia. She converses almost convincingly, but is just a
>great pile of templates to match against (I think -- my apologies to mlm
>if I am misrepresting her). I'd be interested in hearing about ideas for
>prototypes.
There are a lot of ways to do this. Backward and forward chaining are
ways of moving some of the pointers off disk and into memory, at the
cost of a little speed; object-orientation (the good bits) could also
help here with something like multiple inheritance. I understand there
are LPmuds out there which have something they call multiple inheritance
in that which they call LPC. This might be a good place to start looking.
>>>What is the single most important thing that makes a MUD good? And why?
>>
>> currently, its ability to act as a chat program. Ideally, its
>> easy extensibility.
> Extensibility in aid of what? Escapism, I presume?
Yes. I want to be able to lose myself and cause other people to be lost.
>> * fills in details using some form of AI (currently doable)
> Tell us more. I think you know more about this than anyone else
>currently, uh, contributing. Does that whatsit you worked on do something
>like this?
which whatsit? Anyway, there are algorithms out there, the names of
which are not currently important, which make deriving logical conclusions
and implications a breeze in well-formed universes like the blocks world.
For those of you who don't know what the blocks world is, it's a postulated
universe in which there are only eight or so objects -- a table, blocks
of various size, shape and color, and a hand which accepts instructions.
If you tell the hand to 'put the red cube on the blue cone,' it says,
"I am sorry, the cube would fall off the cone," even though it doesn't
have explicit rules about red cubes not being able to handle balancing on
blue cones. The hand uses 'backwards chaining,' which allows it to take
a bunch of rules (cones are NOTFLAT, cubes require FLAT to be ON,
FLAT has nothing to do with COLOR, etc) and derive an answer. The problem
with this is that the mud universe is not 'well formed' -- nobody has yet
come up with a completely satisfactory list of classes and qualities which
could instantiate an interesting mud reality.
The cool thing about backwards chaining and all those other fuzzy logic
style algorithms is that they're extensible; if you insert the rule
"BLUE things cannot be FLAT", then bingo, the hand refuses blue cones,
blue cylinders, blue tables, as balancing places. If you insert the
rule "PURPLE things cannot OWN CARS," then even if you don't have any idea
what a car is, or what it is to be purple, you can still do stuff. And
of course, if you say "can purple things own chevies?" and you've implemented
the program right, the program will say, "uh, are chevies cars?" to which
you say, "well, yes," and the program says, "then no."
And the REALLY cool thing is that you can say "objects may not rest on
tables if the table is tipped over." "tables which are tipped over cause
objects upon them to impact upon the floor." "objects which impact upon
the floor may break." "fish do not break." "vases break." "there is
a fish and a vase on the table at time 1." "kicking objects cause them
to tip over." "fish may not tip over." "At time 2, I kick the table."
OUTPUT: the table tips over. The fish and the vase fall to the floor.
The vase breaks.
"At time 3, I kick the fish."
OUTPUT: the fish does not tip over.
(well, you gotta account for default rules, but you get the idea).
>> * database-editing server separate from database-exploring server
>> (currently doable)
> This is an interesting idea. You're saying 'build it under one server,
>play it under another'? That's very innovative, at least for those of us
>raised on the Tiny* line.
I think it's just a whole lot cleaner. Opens the possibility for 'compiled'
code and other neat ideas.
>> * fast (doable, for the exploring server)
> Err, this depends on the AI jazz above, surely?
Yep. Even machines like 4/110s, though, are perfectly adequate for
fifteen, twenty concurrent backwards chaining database mungers. And in
two years, the average mud machine is gonna probably be more equivalent to
a RS/6000, which kicks the 4/110 around.
>> Felix
> It's interesting to note your emphasis on building and exploring.
>Do you believe that Tiny* derived (literally and spiritually) servers
>suffer from a lack of both because people don't want to, or because the
>tools for doing it well enough don't exist? If the former is true, then
>your notions constitute wasted effort.
> One space after periods.Conserve bandwidth.
You're the dork who uses tabs.
> Andrew
Felix
--
a b c d e f g h i j k l m n o p q r s t u v w x y z
Felix Sebastian Ortony for...@murphy.gis.uiuc.edu
Ken Arromdee
>> Why are people so intent on (re)creating only the real world? Think
>>big. A simulation of cyberspace probably has highly non-Euclidean
>>geometry, and the notion of rooms placed in a 'space' that people can
>>understand seems rather suspect for a sorceror's home (or a high-tech
>>dwelling; cf., say, Dan Simmon's HYPERION).
>According to my understanding, the strength of a VR is supposed to be
>that it translates a hard-to-understand data-space into something that
>the user can relate to meaningfully. Having your VR accurately mirror
>RL means that users can navigate intuitively, using familiar assumptions
>about what will happen. It's not reality that's important as much as
>familiarity...fantasy worlds with consistent internal physics probably
>work even better. The notion of rooms placed in a 'space' that people
>can understand may seem suspect, but it IS easier for people to
>understand. :) Getting disoriented a lot kills the sense of "being
>there".
But people are different. Different users have different intuitions.
This gets back to the old question about teleporters, and about topology. It
might be "natural" for a person with a reasonable amount of computer experience
to be able to change directory from anywhere, to any other accessible
directory. This person, on a mud, might wish to use a teleporter to go to any
room he can access, without passing through the intervening rooms. Or even
consider the paradigm of a scene change in a book or movie; you don't always
see someone go through all the intervening places to get somewhere--it happens
off screen.
Forcing such a person to use "rooms" which one must pass "through" to get
somewhere may be counterproductive....
--
Hi! Ani mutacia shel virus .signature. Ha`atek oti letoch .signature shelcha!
Ken Arromdee (UUCP: ....!jhunix!arromdee; BITNET: arromdee@jhuvm;
INTERNET: arro...@jyusenkyou.cs.jhu.edu)
Marcus J. will do TCP/IP for food Ranum
Another fun possibility is to merge future MUDs with artificial
life. It'd be pretty cool to have food chains of monsters. ;)
mjr.
The WOZ
>
> @find would still not be reasonable to implement. ;) Local @find
> would be.
>
>mjr.
Player A sends a '@find' message to the system object on his home mud and
waits for a response.
Sysobj on Amud sends '@find' message to all known muds, and waits for at
least one response while processing other messages and looking for matches
locally.
Sysobj on Amud sends the result to player A.
Doran ducks quickly to avoid flying flames.
--
: main me @ trigger @ desc setdesc me @ swap notify ;
( a viral description muf program. make everyone look )
( just like you! /// awoz...@morpheus.calpoly.edu )
( Lord Knight Errant Grammer Checker of the B.E.M. )
Marcus J. will do TCP/IP for food Ranum
>Player A sends a '@find' message to the system object on his home mud and
>waits for a response.
>
>Sysobj on Amud sends '@find' message to all known muds, and waits for at
>least one response while processing other messages and looking for matches
>locally.
>
>Sysobj on Amud sends the result to player A.
Actually, with the asynchronous messaging approach, it'd work,
since you wouldn't lock the whole MUD up. If someone did an @find on
the whole network, they'd spin spindles all over the place, and over
a prolonged period of time would be bombarded with messages to the
effect of:
"I found 'cat' over here!"
"I found 'cat over there too!"
etc. You could "punish" the @finder by making the @find command
do all its messaging synchronously, so they would be locked up until
every single MUD in the world was done running its @find. ;) Serve the
bleeders right if you ask me! Of course everything else would keep
crunching along. Be a real pity if some wandering alien chewed you up
for lunch while you were locked in the bowels of an @find...
Multicastable messages would be a real problem spammability-wise.
Of course MUD-spamming is a social problem, not a software problem.
mjr.
Marcus J. will do TCP/IP for food Ranum
> etc. You could "punish" the @finder by making the @find command
>do all its messaging synchronously [...]
I just thought of a much simpler solution. Have the create
command always create all objects on the player's home MUD. That way
they're all local to the player, always. Not only that, you continue
to own them, and can manage and manipulate their on-disk images, etc.
[Need to consider the effect on performance if there were
rooms belonging to 6 different MUDs on the same server. I expect it
might still be tolerable if done right]
mjr. [still no plans to implement yet another "crap" MUD, so don't
expect to see anything out of this idea from me]
jason steiner
: In-reply-to: c...@hawkwind.utcs.toronto.edu's message of 26 May 92 07:56:46 GMT
:
: > A simulation of cyberspace probably has highly non-Euclidean
: > geometry, and the notion of rooms placed in a 'space' that people can
: > understand seems rather suspect for a sorceror's home (or a high-tech
: > dwelling; cf., say, Dan Simmon's HYPERION).
: >
: Using virtual reality, we are talking inclusive interface, no simple text,
: but more or less vapor hardware, to let someone experience strange worlds
: and geometries is a very neat idea, but face it, it won't happen in two years.
huh? it's happening now. you actually have to work rather hard to
keep a MU* within topological boundaries. strange geometries we have
aplenty. strange worlds are just as easy.
: Frankly Chris, get off your high clouds of visionary imaginations. VR
: suffers enough from excessive amounts of hype without yours adding to it.
i happen to -like- my imagination thank you. MU*s are a good way of
bringing what i imagine to life. VR suffers enough from excessive amounts
of restrictions without yours adding to it. :) seriously, having a
good set of virtual physics is a good idea, but a MU* that won't let
me teleport, put a big thing in a smaller object, make one way exits
or do other "impossible" things is not one i want to use, much less
play in.
: To qoute an unknown source:
: 'Some people dream of accomplishing great things,
: others stay awake and make them happen.'
in MU* you can have your cake & eat it too. nyeah. :P
: Sorry if I sound harsh, but I've heard so much VR hype that I tend to choke
: on it.
too bad. most of us -like- cake.
: /Johan
--
would you could you should you cross thru if i could wipe my eyes a blinding
compromise another pinky shave enlightens the brow now cow to die another day
if you prefer outside be blessed sir ostracize better bastard now forgotten
well instead of favored son of hell in hopes to open eyes - scaterd few, U
`,`,`,`,`,`,`,`,`,`,` ste...@jupiter.cse.utoledo.edu `,`,`,`,`,`,`,`,`,`,`
jason steiner
: This is an interesting idea I've yet to see implemented. You could have
: areas which are 'fertile'. Autonomous 'npc's can wander, find somewhere
: new to plant, plant, harvest, etc.
:
: That would make such a mud a robot-domain, in which pcs could wander,
: fight, and interact with the 'peasants.'
:
: Sound interesting?
yup. sounds like Populous from a first person POV.
: -Me
Chris Siebenmann
| government, namely that of totalitarianism, and not one of
| the more complex and higher evolved government.
It's hard to argue with the person who's giving you free disk space, or
a free living spot. If you can pack up and move, and you own or rent
your own MUD 'house', then we can have democracy. Until then, any
democracy introduced will be fake democracy, always at the mercy of the
tyrant's tolerance.
James Roraback
>
Job? You want me to work to play? Have you never had a real job?
The problem adding a myriad details to MUDs is that details can remove
playability, just llike those cumbersome board wargames with hundreds
of carboard playing pieces, an 200 page rule book, and 3 hours real
time to complete 1 round. Yes, they were fun when they were all we had,
but now we have our computers to roll the dice and track details.
Theoritically these computers should releive us of the monotonous details
and give us more time to role-play and plan, theorize and philosphize
the consequences of our actions.
Wider goals? certainly an excellent suggestion. Many muds do have
quests that award experience and reward for solving puzzles with brain
and not brawn. Physical and mental challenges should both become
standard features in future MUDs. But not necesarilly monotonous
challenges, there still needs to be some sense of adventure. I'm not saying
that role-playing he police chief is boring, it can have its exciting
moments, but those moments end when the cheif and his officers have to fill out
a couple hundred ppages of reports explaining why it was necessary to
exterminate the vermin adventurers who had formed a Mayor bashing party. Not
to mention justifying the expenditures of ammuntion, the hiring of extra
policemen for the battle, survivor benifits for the widows of all those
policemen who died tryning to save the mayor......etc.etc.etc
So, do muds need to be more realistic, certainly, but not in the sense
of adding minute details to scan an already unreadle scroll rate. We, need
instead to add more believability to our senses. Jumping from mud to mud,
server to server is more believable than killing the same three golems
over and over. Graphics add the sense of sight to enhance believability.
And, what about some basic audio? terminals with only a bell do have a speaker,
and software could be written to send different frequencies and wave patterns to that speaker
Well, I think I've made my point, coding new server methods isn't the only
goal we can think about. lets think about better ways to fool our senses
into enjoying the Artificial Realities we create.
There are thos who know me as ........ Knightwind
--
-------------------------------------------------------------------------------
James Roraback Only from darkness
rora...@rodan.acs.syr.edu Can there come light
-------------------------------------------------------------------------------
Chris Siebenmann
| I see MUDs as the ultimate interface to computers.
Can you elaborate on how a MUD would have a better interface to,
say, netnews or electronic mail than we currently have? People are
always saying this, and I am always disbelieving them; MUDS today
are natural interfaces for very few things, and most of what I do
with computers is not included.
Chris Siebenmann
| According to my understanding, the strength of a VR is supposed to be
| that it translates a hard-to-understand data-space into something that
| the user can relate to meaningfully.
Unless the conversation has taken a left at Aldebaran, we are talking
about future MUDs, not future VR. The two are not quite synonymous,
especially in *this* context.
Chris Siebenmann
| > Why are people so intent on (re)creating only the real world? Think
| > big.
| You got to learn to walk before you can learn to run.
Log onto a decent MUD and look around; people are *already* running
with the primitive tools they have available. Forcing them to walk,
albeit at a much higher level of detail than before, may not be very
popular.
| Frankly Chris, get off your high clouds of visionary imaginations. VR
| suffers enough from excessive amounts of hype without yours adding to it.
Congratulations on failing your 'read clearly' roll. I am not proposing
VR; I said 'a simulation of cyberspace', not 'cyberspace'. Such a
simulation has been done already several times on various different
MUDs. Similarly I have both seen and built areas with non-Euclidian
layouts (and one area that is completely non-geometric). These cases
are not hypothetical, they are real.
So, let's say it clearer:
The power of MUDS *today* is that one can build and represent is
limited *only* by what one can write about (and for some MUDs,
code for). I believe very firmly that MUDS in 2 years should be
less restrictive, not *more*, in what they can be used to build and
represent. Unless people make tragic mistakes, like assuming that
people only care about places with simple Euclidean geometry and
real-world 3-d spacial relationships, this should not be a problem.
Alas, people seem very determined to make said mistakes, apparently
you among them -- and then being unable to understand when people
mention this.
[yes, this has been a gratuitous slam. So was the article to which
I'm replying to.]
Mud Admin
>m...@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>| popular MUDs around" is correct, then it's worth figuring out
>| why and what can be done to help it.
>
> It strikes me that one core difference between the average Diku/LP
>and the average TinyM* is that the former is a game, while the latter
>is a society. I find it unsurprising that more people play a game than
>participate in a new society. I also suspect that a game MUD will be
>noticably differently constructed than a society MUD (for example,
>world consistency is probably a much bigger thing in a game).
Well, if you were to login to TMI, you'd find a ton of folks just
there to talk and code. Not much killing (and killing doesn't mean
anything, sorta like a Tiny) and only experimental monsters.
Sure, TMI isn't your standard LP, but I don't know any LP where people
don't talk. I happen to only play LP's where I can enjoy the people
I have to talk to. Then again, sometimes it's fun exploring someone's
area, and solving a few quests. If you have a well-written mud, there
will be plenty of these sorts of things to be involved in.
Just because something is an LP (or Diku I suppose) doesn't mean
everyone on the system is hacking and slashing their hearts out.
Sulam @ { TMI, Igor, DreamShadow, ... }
--
| This article is the individual opinion of a TMI Admin.
| The Mud Institute: dogstar.colorado.edu (128.138.248.32) 5555
| Ftp: "" "" 5554
| TMI serves as an information and development center for LPmuds.
Marcus J. will do TCP/IP for food Ranum
Coming soon, REALMUD!!!
In REALMUD you start off as a muling, puking, helpless infant
character(*). After your first several months of play, you'll get to have
some basic emote commands, but until then, all you can do is roughly
schedule the "wee" and "poo" and "waaah" commands.
After you've played for several years, you get enough experience
that you get to go to a series of adventures called "school" in which
you battle your way through horrible monsters ("classmates") to try to
learn enough to go up levels. Surprisingly, there is no limit to the
levels that you seem to be able to go - if you're successful enough
in these levels, and succeed in a mighty topological quest, you will
attain a "PHd in Mathematics" and then suddenly find yourself in a
wilderness adventure populated with tax collectors, tenure tracker
beasts and other horrible monsters. You get to struggle for ever in
this level until you starve or die or are killed and eaten by
horrible little carnivorous monsters ("undergrads").
No thanks - I'll take my MUDs as unreal as possible.
mjr.
*(like Felix, kind of, but you can't even post to USENET!) ;)
Mud Admin
We've done some preliminary work with this on TMI. One guy wrote
some animals that wandered around, reproduced, etc. We also talked
long and hard about how a 'true' economy would work, where the player
gets to attach the value to items, instead of being forced to buy/sell
at a certain price. One problem with the economy idea is that it's
hard to get around setting a basic price on things like food, drink,
or basically any services. Now you could always fudge it, or you
could do like you are saying, and have a vast amount of objects
all contributing to the whole system (although you'd have to figure
a way to code a bargaining system into your peasants). The trouble
then (the REAL problem) is that you've got a LOT of objects that
NEVER sit still. In a standard LP, an object is generally only
alive' when there is a player in the room to be alive for. This is
a simple optimization that allows a mud to have 100's of monsters all
around at the same time, but without swamping the cpu with heart_beat
activity. For the kind of system you are speaking of, a much quicker
machine would be needed, or the rate at which things happen would have
to slow down.
ps. One major objection people had with the economy idea is that you
don't have the critical mass of people on a mud that would be necessary
for something like this to work.
Sulam
Ron A. 5150 Echeverri
>Not to mention the fact that he engages in USENET vandalism (I've seen
>Ron cascading at least twice now).
Hey scotty don't you have a mudlist to print or sumthin?
--
"All this machinery making modern music \ Ron Echeverri-BSCS 1995
Can still be open-hearted. \ Univ. of So. Cal.
Not so coldly charted, it's really just a question \______________________
Of your honesty, yeah, your honesty." - Rush, 'The Spirit of Radio'
Bruce Woodcock
>For the players, the keyword must be 'believability'. The world model must
>be able to make itself believable through the interface to the user, this
>means that the range of actions the interface allows the user must result
>in responses from the world model through the interface that are in some
>sense realistic and complete.
I agree here. It is also crucial that the inner workings not be "revealed"
to the user, to preserve the illusion.
>For the creator, the keyword must be 'freedom'. A creator must not be
>limited by the design of the world model. Anything conceivable should be
>possible to implement.
Again, agreement here.
>To fulfill the 'believability' demand the simulation model must probably
>be based on something other than 'responses to commands'. A simplified
>simulation of newtonian mechanics should probably be an essential part
>of the model, including of course a Euclidean geometry.
I disagree violently with this approach. See below.
> - Everything is objects.
> - It is object interaction that contitutes the game.
> - There is nothing else, all information reside within objects.
>The server should have no concept of the game. It should merely execute
>code within objects. There are compromises to this in LPmud.
The approach you are talking about is very similar to Lucasfilm's Habitat,
but you have to use *conceptual* objects, not real ones. The simulation is
a conceptual one, not a real one. I back this up partially with an excerpt
from an essay, reprinted without permission. Btw, I recommend the book this
came from... it has many essays relevant to the future of VR and also current
problems we find on muds.
Morningstar, Chip, and Farmer, F. Randall, "The Lessons of Lucasfilm's
Habitat." In Benedikt, Michael, ed., Cyberspace: First Steps (MIT Press,
Cambridge, 1991).
"[An object-oriented data representation is essential.] Taken at
its face value, this assertion is unlikely to be controversial, as
pbject-oriented programming is currently the methodology of choice
among the software engineering cognoscenti. However, what we mean
here is not only that you should adopt an object-oriented approach,
but that the basic objects from which you build the system should
correspond more or less to the objects in the user's conceptual model
of the virtual world, that is, people, place, and artifacts. You
could, of course, use object-oriented programming techniques to
build a system based on, say, polygons, but that would not help to
cope with the fundamental problem.
"The goal is to enable the communications between machines to take
place primarily at the behavioral level (what people and things are
doing) rather than at the presentation level (how the scene is
changing). The description of a place in a virtual world should be in
terms of what is there rather than what it looks like. INTERACTIONS
BETWEEN OBJECTS SHOULD BE DESCRIBED BY FUNCTIONAL MODELS RATHER THAN
BY PHYSICAL ONES. [Empahsis mine -- Bruce] The computation necessary
to translate between these higher-level representations and the lower-
level representations required for direct user action is essentially
a local function. At the local processor, dispay-rendering techniques
may be arbitrarily elaborate and physical models arbitrarily
sophisticated. The data channel capacities required for such
computations, however, need not and should not be squeezed into the
limited bandwidth available between the local processor and the remote
ones. Attempting to do so just leads to disasters such as NAPLPS
(ANSI 1983, Alber 1985), which couples dreadful performance with a
display model firmly anchored in the technology of the 1970s."
Perhaps I've quoted enough... read the book for yourself. :)
Bruce
--
| ster...@netcom.com | "If I can sell explosives to IH, then |
| sirb...@gnu.ai.mit.edu | there's no reason you can't sell me a |
| bwoo...@isis.cs.du.edu | box of condoms." - Jasper, to me, RL |
Bruce Woodcock
>Well, since I'm not a server hacker myself, or very much of
>one, I'm concerned mostly about the social impact that MUDs
>will have, and how their social and group interaction will
>change. MUDs are still an evolving society, with primitive
>controls on behavior, that can be changed in the future.
While this is true, the control is on the part of the users,
not the admins.
>At the moment, MUDs are ruled with a primitive type of
>government, namely that of totalitarianism, and not one of
>the more complex and higher evolved government.
>Will MUDs develop along the lines of human history? They
>seem to be changing more and more each day. Will we have to
>deal with virtual red tape?
I personally don't think any one system of government should
be written into MUDs, but rather they be given the flexibility
for any form of government to evolve as the players need.
Okay, okay, both this idea and the previous one came from the
Habitat article I mentioned in one of by other posts. :)
Let's just say I really liked the conclusions they made in it...
eri...@mit.edu
> eri...@mit.edu writes:
> | I see MUDs as the ultimate interface to computers.
>
> Can you elaborate on how a MUD would have a better interface to,
> say, netnews or electronic mail than we currently have? People are
> always saying this, and I am always disbelieving them; MUDS today
> are natural interfaces for very few things, and most of what I do
> with computers is not included.
There are a lot of reasons I think this. To really see it, I think you
have to look at existing interfaces and compare them to what MUDs have
now. Essentially there are two types of interfaces to computers today:
command line interfaces (CLIs) and graphical interfaces (GUIs). GUIs are
the hot thing these days because they are supposedly easy to use. You
don't have to be a computer wiz to use a GUI. Now why is that? Is it
because pointing and clicking with a mouse is a natural and intuitive
thing to do? I don't think so. From experience teaching people who have
never really used computers before, they seem to have a lot of problems
with the mouse at first. If you're not used to it, it's kind of a pain to
get the hang of. So what is it then? There are probably two primary
reasons. One possibility is that you have a limited set of actions which
define all responses (pointing, clicking, dragging, etc.) and it is easy
to remember these simple combinations. The other, and I believe more
significant thing that GUIs have is a natural physical metaphor for
certain actions. For example, to destroy a file, you put it in the trash
can. To move a file from one directory to another, you move it from one
folder to another. When you want to move text, you "cut" and "paste" it.
Drawing programs use tools which look like their real world counterparts
(pencils , paintbrushes, etc). These things are easy for new users to get
because they're just like what they do in real life. They're easy to
remember. I think this is much more significant.
For CLIs, their benfits are pretty obvious. They have a rich and
descriptive vocabulary. It's very easy to build complex expressions out
of simpler ones. It's easy to say "remove all files that begin with the
letter 'a' and end in '.c'". This is something that just can't be done in
graphical interfaces. However, the commands are often cryptic and hard to
remember. "rm *.c" looks like gibberish to the average person.
So let's look at MUDs and compare it to these two interfaces. I believe
that what you have is a combination of the best of both worlds. You go a
step beyond command line parsing's flexibility by creating something which
is closer to spoken language. Although I haven't seen a MUD with parsing
this good, it's certainly possible to be able to say "throw away all files
which are older than one month", and to have the MUD understand it. You
keep it's incredible flexibility and power (and still have the ability to
have powerful aliases and obscure commands for the power user), and gain a
more natural way of expressing yourself. From graphical interfaces, we
have the physical metaphor. Since we are in a miniature virtual reality,
how we interact with programs can have a direct relation to how we would
do similar activities in real life. To write a note, you could use a
pencil to write on a postit note, and a mailbox to send and receive mail.
The mailman could pickup and deliver your electronic mail. The news you
read comes on a virtual newspaper. Although most MUDs don't go to this
extreme, my point is that they easily could. (and should, IMHO)
Another case in point of this is Infocom games. Do you know anybody who
took more than a couple of minutes to really figure out how to move around
and use those programs? Again, I think that the reason that this is true
is because everything makes sense. It has a direct relationship to real
life. Things work and behave in ways that you expect and predict. You
can speak in your own language to it, you don't have to learn a complex
new "language" of actions.
I think that MUDs naturally extend into the interfaces that programmers
are spending a lot of time working on. For example, many people are
working on speech recognition systems. How easy do you think it will be
to extend most of your standard PC or Mac software packages to really make
good use of speech recognition and parsing systems? They'll practically
have to write the equivalent of a MUD parser to translate natural speech
into actions in their programs. Meanwhile MUDs, since they either do or
can use close to natural languages, extend naturally into speech
recognition. Then of course is virtual reality. Yes, this is a long way
off, but once again, when it arrives, MUDs extend into that model simply
and naturally.
One final point that shouldn't be ignored is that transparent network
connectivity and communication is getting to be a necessity in most
companies with computers. MUDs currently support a natural way for people
to communicate over the network. In the next year or so, I think we'll
see improvements in distibuted MUDs to the point where we could
potentially walk from MUD to MUD as transparently as one room to the next.
As has been discussed this is not an easy problem, but we're already
seeing the beginnings of such things in Unter's and MudOS. For MUDs, this
sort of transparency is second-nature once the underlying server exists.
Meanwhile, most computer interfaces to networking and network
communications are klunky and generally a pain to use.
later,
Erik
Wayfarer@{MIRE, Portals, TMI, Overdrive}
Jack L Needles
A few ideas on economic systems on muds:
The concept of supply and demand is such an easily implemented concept, it isd
ludicrous. The time to code the manaer for it is the problem, and given the
current levels of mud prsing and code, it is a bit bulky. Howevere assume
that all money in the world is created ONCE. That is a money manager the first
time it is created makes x amount of coins. From here on out, any object that
is created must be purchased. <Monsters need to have enough gold to buy the
item, stores enough cash reserves, etc.> The general problem with a system
like this is that too many wizards are too high and mighty to be forced to use
something no matter how beneficial it is. And no Admin likes to force people
to use manager x because that stifles creativity.. WRONG.
If the manage creates 2,000,000 coins upon creation and all the money in the
game is alotted from there, the game can function smoothly. Thus cash is only
created once and is in fact static. If players begin hording gold, they can no
longer aquire more, prices go up on needed items, and they are forced to spend
some of their hard earned cash.
As an example. Upon total ame reset <Crash, etc> the ame resets the cash
manager to the orinial 2 million, it then subtracts the total monetary amount
of carried and depositied cash. From this point, all monsters, shops, smithies
etc that selkl items or carry gold call into the manager and aquire their
holdings from the cash that is left. When this amount is gone, they no longer
will have the cash players expect, or will no longer be able to buy items from
the expected places.
Stores will keep track of items, and their value and raise prices of individual
items accordingly.
I have the full economic model drawn up in detail, and easily workable, though
it would require some restrictions on wizards coding, but none of them are
truly as severe as many would think. Feel free to write and I'll more than
happily share my thoughts and ideas.
Jack L Needles
Prydain (TMI, Vincent's Hollow, Adversary Diku, DR, OverDrive, EOTL)
--
-------------------------------------------------------------------------------
'Half a Bee, philosophicly, must ipso facto, half not bee'
Jack L. Needles <Jnee...@magnus.acs.ohio-state.edu>
Bruce Woodcock
>ru...@math.okstate.edu (Russ "Random" Smith) writes:
>>Bear in mind this comes from the individual who one message back
>>couldn't distinguish between a MUD server program, and the machine it
>>runs on.
>Not to mention the fact that he engages in USENET vandalism (I've seen
>Ron cascading at least twice now).
Some people would consider posting to rec.games.mud at all (or even the fact
that it exists) to be USENET vandalism.
Cascades are annoying, but I've seen posts with even less informational
content than a cascade.
Bruce Woodcock
What's more interesting is exactly where players will fall within those food
chains. :)
Jack L Needles
The future of muds and what they are to become is something that needs to be
discussed heavily.
Currently, there are two things that I think need to be corrected.
Unfortunately, as I have said in my previous posting, many wizards are
unwilling to deal with a few restrictions in order to make the mud as a whole
more exciting.
1) Objects need to be standardized. Having 11 different types of shortswords
all with different weights, weapon classes, and having all the same
descriptions of 'a shortsword' is ludicrous. In rpg's there are standardized
weapons and armor and generic objects and if muds are to emulate a 'fantasy
world' they should as well.
2) Predicitiblity. Too many muds have their rooms all reset after the same
length of time, and the monsters are consistantly in the same place with the
same items.
Both of these problems are easily correctable and the cures easily implemented.
Along with these changes, and the current workability of LP 3.0 it is not
unfeasible to have a mud with the look of a game such as ultima or an infocom
game usin this text format.. it just takes some work. Undocumented quests and
puzzles are thus easily created and implemented, making things more vast and
interesting.
Jack
Prydain
Geoff Wong
>cg10...@icogsci1.ucsd.edu (Keith C. Estanol) writes:
>| At the moment, MUDs are ruled with a primitive type of
>| government, namely that of totalitarianism, and not one of
>| the more complex and higher evolved government.
>| Will MUDs develop along the lines of human history?
> It's hard to argue with the person who's giving you free disk space, or
>a free living spot. If you can pack up and move, and you own or rent
>your own MUD 'house', then we can have democracy. Until then, any
Well as soon as (fully) distributed MUDs become common (I'm sure they
will) you'll find some form of "democracy" among the land holders
(i.e. the machine owners/account owners etc). Interesting (but
irrelevant) parallel with ancient Greece.
geoff
--
No comment.
Johan Andersson
I wrote:
>To fulfill the 'believability' demand the simulation model must probably
>be based on something other than 'responses to commands'.
>
methodology hardcoded into the world model inflicts. To me this is the
culprit that produces all the 'What ?'s until I find the combination of words
that the implementor expected me to use.
> A simplified
>simulation of newtonian mechanics should probably be an essential part
^^^^^^^^^^^^^^
>of the model, including of course a Euclidean geometry.
>
This was a suggestion of something else. Note that I do not suggest that
the world model be based on newtonian mechanics. That would contradict
the idea of total freedom for a creator.
In article <qg3kyw-....@netcom.com> ster...@netcom.com (Bruce Woodcock) writes:
> I disagree violently with this approach. See below.
>
Do you want to keep the 'command response' method or do you have a better
suggestion?
> - Everything is objects.
> - It is object interaction that contitutes the game.
> - There is nothing else, all information reside within objects.
> The approach you are talking about is very similar to Lucasfilm's Habitat,
>
I'll let Lars and Lucasfilm fight it out on who thought of it first then :-)
> but you have to use *conceptual* objects, not real ones. The simulation is
> a conceptual one, not a real one.
>
Hmm, I do not entirely see how this fits with the excerpt:
> Morningstar, Chip, and Farmer, F. Randall, "The Lessons of Lucasfilm's
> Habitat." In Benedikt, Michael, ed., Cyberspace: First Steps (MIT Press,
> Cambridge, 1991).
> However, what we mean
> here is not only that you should adopt an object-oriented approach,
> but that the basic objects from which you build the system should
> correspond more or less to the objects in the user's conceptual model
> of the virtual world, that is, people, place, and artifacts. You
> could, of course, use object-oriented programming techniques to
> build a system based on, say, polygons, but that would not help to
> cope with the fundamental problem.
>
This could be an exact description of how LPC is both object oriented and
not. It is very OO in the above sense of 'world modeling'. The language
itself is not very OO at all.
To me when the excerpt talk of 'conceptual' objects it talks of objects
that are 'real' inside the virtual world, people, places artifacts. I do not
see the contradiction you state.
> INTERACTIONS
> BETWEEN OBJECTS SHOULD BE DESCRIBED BY FUNCTIONAL MODELS RATHER THAN
> BY PHYSICAL ONES. [Empahsis mine -- Bruce]
>
Oki, what is a 'functional model'? Is this 'command response' in disguise?
My idea with a physical model was that it would be easier to achieve
completeness. The biggest lack in MUDs today are all the 'What ?'s. Maybe
a 'functional model' of interaction could achieve completeness too. I just
have problems with how to identify the below commands as identical.
'get match'
'get the small wooden stick on the table'
'move the little firemaker from the table to the left shirt pocket'
'take match'
> Perhaps I've quoted enough... read the book for yourself. :)
>
I'll dig it up. I'll have to visit the library. *gasp*
/Johan
--
Johan Andersson | "You don`t have conversations with microprocessors
Chalmers, Sweden | you tell them what to do, and then you helplessly
Email: | watch the disaster when they take you literally."
d8a...@dtek.chalmers.se | Sah`ot in David Brins "Startide Rising"
Keith C. Estanol
>| At the moment, MUDs are ruled with a primitive type of
>| government, namely that of totalitarianism, and not one of
>| the more complex and higher evolved government.
>| Will MUDs develop along the lines of human history?
>
> It's hard to argue with the person who's giving you free disk space, or
>a free living spot. If you can pack up and move, and you own or rent
>your own MUD 'house', then we can have democracy. Until then, any
>democracy introduced will be fake democracy, always at the mercy of the
>tyrant's tolerance.
>
Hmm.. you have a good point there. Maybe what I meant was
internal MUD control, instead of total control by the ruling
wizard powers that be. Or is this already in place?
At least in some places.. Hm.
Keith C. Estanol | st...@ucsd.edu
UCSD, Cognitive Science | st...@ucsd.bitnet
Time Traveller Wizard's Council,
Wanted: An office with a window, and a SPARCstation
------------------------------------------------------------
"You can choose from phantom fears or kindness that can kill.
I will choose a path that's clear, I will choose free will!"
- Rush -
Daniel Crow
>amol...@eagle.wesleyan.edu writes:
>
>>In article <fortony.706768594@murphy>, for...@murphy.cs.uiuc.edu (Felix Ortony) writes:
>>> * fills in details using some form of AI (currently doable)
>
>> Tell us more. I think you know more about this than anyone else
>>currently, uh, contributing. Does that whatsit you worked on do something
>>like this?
>
>which whatsit? Anyway, there are algorithms out there, the names of
>which are not currently important, which make deriving logical conclusions
>and implications a breeze in well-formed universes like the blocks world.
>For those of you who don't know what the blocks world is, it's a postulated
>universe in which there are only eight or so objects -- a table, blocks
>of various size, shape and color, and a hand which accepts instructions.
>If you tell the hand to 'put the red cube on the blue cone,' it says,
>"I am sorry, the cube would fall off the cone," even though it doesn't
>have explicit rules about red cubes not being able to handle balancing on
>blue cones. The hand uses 'backwards chaining,' which allows it to take
>a bunch of rules (cones are NOTFLAT, cubes require FLAT to be ON,
>FLAT has nothing to do with COLOR, etc) and derive an answer. The problem
>with this is that the mud universe is not 'well formed' -- nobody has yet
>come up with a completely satisfactory list of classes and qualities which
>could instantiate an interesting mud reality.
>
I'd agree with this, but there is a second problem with MUDs. It is not just
that they are currently not "well formed" (this is a significant problem in
itself), but also that the computation rises exponentially with the sort of
system Felix describes. Thus it is feasible to do this sort of stuff with
blocks world (a *very* limited world) but if you move towards worlds of the
size of typical current MUDs (let alone ones which are more complex) this
approach becomes computationally intractable. This would certainly conflict
with the requirement for the system to be fast.
On a realted point: at what granularity should the Mud world be modelled? The
obvious answer is to model it at the level of objects (cf. the blocks world),
but there are examples where moving to a finer granularity would be
advantageous (for example, modelling items which were made up of sub-objects,
say a lamp which has glass (transparent and breakable) wick (flamable) and
metal (unbreakable) components which *could* be modelled separately). In the
extreme case you could model a Mud world as a series of interacting sub-atomic
particles. This is obviously unecessary, but as you move to finer granularities,
the computational problems grow, but the set of rules you need to supply
becomes smaller (Note: this is only a heuristic, there are counter-examples)
>>> * fast (doable, for the exploring server)
>
>> Err, this depends on the AI jazz above, surely?
>
>Yep. Even machines like 4/110s, though, are perfectly adequate for
>fifteen, twenty concurrent backwards chaining database mungers. And in
>two years, the average mud machine is gonna probably be more equivalent to
>a RS/6000, which kicks the 4/110 around.
>
Not sure this isn't missing the point: the sort of expert system engine you
describe is bounded by the size of its rule and data bases. Although a 4/110
may be able to support 20 simple expert systems with trivial rulebases, if
you wanted to model a MUD world at this level, I don't believe it is
possible with current hardware and software. I am happy to accept good
evidence to disprove this point, as I think this is a good path to follow 8*)
>--
>a b c d e f g h i j k l m n o p q r s t u v w x y z
>Felix Sebastian Ortony for...@murphy.gis.uiuc.edu
--
Dan Crow
dan...@scs.leeds.ac.uk
Marcus J. will do TCP/IP for food Ranum
>$ It's hard to argue with the person who's giving you free disk space, or
>$a free living spot. If you can pack up and move, and you own or rent
>$your own MUD 'house', then we can have democracy. Until then, any
>Well as soon as (fully) distributed MUDs become common (I'm sure they
>will) you'll find some form of "democracy" among the land holders
>(i.e. the machine owners/account owners etc). Interesting (but
>irrelevant) parallel with ancient Greece.
I doubt it. UnterMUD's inter-MUD object portability and database
layout was designed so that anyone with 512K of free disk space could
support a very small MUD. The object was to support an environment where
each player (who wanted to) could own their own "home" MUD, and link
them to some main MUDs someplace. Thus, when I felt like MUDding, I'd
fire up my server, connect to it, walk off to some other MUD, poke around
for a while, then walk "home" and shut it down. The original model of
the UnterNET was many many many small servers, connecting and linking
eachother into one huge virtual network of worlds. What actually happened
reflect (IMHO) the interests of the typical "social MUD" user - sitting
in one room, very occasionally moving about, almost never just exploring.
The other design goal was to facilitate everyone's customizing
their own world by making the server's internals easy to understand
and modify.
Both goals were met, but apparently weren't interesting to the
user community.
mjr.
Felix Ortony
> In REALMUD you start off as a muling, puking, helpless infant
>character(*). [...]
>*(like Felix, kind of, but you can't even post to USENET!) ;)
At least I know how to spell 'mewling,' you ignorant philistine.
>mjr.
Felix
William Henry Timmins
>alive' when there is a player in the room to be alive for. This is
>a simple optimization that allows a mud to have 100's of monsters all
>around at the same time, but without swamping the cpu with heart_beat
>activity. For the kind of system you are speaking of, a much quicker
>machine would be needed, or the rate at which things happen would have
>to slow down.
I've thought of this problem, and had an interesting idea- the
concept of 'unreal' objects.
ie-
A room, called 'Road' is defined as taking 2 days to travel from end
to end. The position of a group of people varies as they travel. The
density of life along the road allows them to hunt for a certain amount
of food (slowing them down, but requiring less food.)
However- if they are attacked at some point, or someone else is on
the road, the interaction CREATES a room, at that point on the road, in
which the interaction occurs.
Diagram-
========================== (road)
^
/ \
---------
Section of road room
_________
This could apply to forests, mountains, etc.
Also, cities could handle individuals as simply statistics, until the
player interacts with them. At which point, the character (NPC) is
CREATED.
Or, there are, say, 10,000 people in a town. Only important NPCs are
created, and continue to exist.
In other words, reality doesn't exist except virtually until it is
observed.
>ps. One major objection people had with the economy idea is that you
>don't have the critical mass of people on a mud that would be necessary
>for something like this to work.
Exactly. PCs, as it were, should be nobles or other powerful
characters. (Which appeals to the desires of most MUDders I know)
-Me
Russ Random Smith
: In article <GOEHRING.92...@mentor.cc.purdue.edu> goeh...@mentor.cc.purdue.edu writes:
: >ru...@math.okstate.edu (Russ "Random" Smith) writes:
: >>Bear in mind this comes from the individual who one message back
: >>couldn't distinguish between a MUD server program, and the machine it
: >>runs on.
: >Not to mention the fact that he engages in USENET vandalism (I've seen
: >Ron cascading at least twice now).
:
: Some people would consider posting to rec.games.mud at all (or even the fact
: that it exists) to be USENET vandalism.
:
: Cascades are annoying, but I've seen posts with even less informational
: content than a cascade.
Bruce, you've posted posts with less content than a cascade, and with more
volume. But I digress.
rec.games.mud was passed in a legitimate fashion, and ergo is not, by
definition, 'USENET vandalism'.
Cascading is stupid, regardless what else you call it. Tedious.
Anyway, this is all somewhat beside the point.
--
Russ "Random" Smith
+----===Comedy! Sudden, violent comedy!===-------...@okstate.edu--------+
| Godfather of the Random Gang; Diplomat of the Brotherhood of Evil MUDders |
+-----------------------------------------------------------------------------+
mm...@jaguar.uofs.edu
>>Not to mention the fact that he engages in USENET vandalism (I've seen
>>Ron cascading at least twice now).
>
> Some people would consider posting to rec.games.mud at all (or even the fact
> that it exists) to be USENET vandalism.
>
> Cascades are annoying, but I've seen posts with even less informational
> content than a cascade.
>
someone please explain what "cascading" is? For that matter, it would be
useful if someone could post a glossary of terms occasionally...
--Matt
Lisa Dusseault
about future MUDs as much as about what MUDs should do now.
I. English
I've seen many postings talking about language. Most of them are
concerned with parsing and commands. These are valid concerns, but I have
a different comment about MUDs and the English Language.
I think that in general descriptions could be written better. I don't
want to see descriptions for every part of every object if that will cut
down on speed or other important factors, but what descriptions do exist
should be free of typos/spelling errors and be made of full, grammatically
correct English sentences. Also, they should be organized in a logical
manner from a player's perspective (spatial order, order of importance,
etc.).
I understand that gods and wizards are human :), and I will therefore
tolerate most of these errors. However, I do not want to mud in an
unimaginative environment. At first, the novelty of a VR is enough, but I
have become more discriminating, and want true creativity. Make things
beautiful or beautifully ugly, but at all costs avoid drab, dull and
normal. That's not what I mud for. My screen has enough grey already: I
don't need more colourless scenarios to read as I wander through a mud.
This, to me, is even more important, although harder, than grammatically
correct descriptions.
Many postings have also discussed Infocom and used it as an example, and I
wish to do that as well. However, Infocom style is also limited. I could
list countless other examples of making text come alive, ranging from
Tolkien with his classical much-imitated style to Lewis Carrol and his
vivid descriptions of his own alternate reality. I don't need to, though,
because I know through experience that many, if not most MUDders are
well-read: I discovered one of my close friends by reciting "Jabberwocky"
with him in a bar in a now-defunct mud.
To close, I wish to say that I do not wish to be derogatory. I have
resisted the urge to include examples of bad descriptions in order to
avoid insulting anyone. But for a good example of how to describe a room
and how not to describe a room, I'd suggest wizards look at a bulletin
board posting at TMI in the admin section. (I am not affiliated in any
way with TMI, BTW.)
II Crashing and Lag
MUDs crash an intolerable number of times. This week has been very
frustrating for me in that respect: I could not log on to several of my
favourite muds for a variety of reasons. Any MUD that wants to see their
characters return should do whatever possible to limit crashes and
Armageddons, because every time a mud crashes, players try another one
while waiting, and may switch if that mud has advantages. Lag is my
number two gripe about physical MUD problems, although I realize little
can be done about it.
This has been / is a most memorable Newsnet discussion, and I'd like to
say how thankful I am to have seen so few flamethrowers out there. :)
Lisa
Gordon Henderson
... about other things, but this is what I'm interested in ...
>What actually happened
>reflect (IMHO) the interests of the typical "social MUD" user - sitting
>in one room, very occasionally moving about, almost never just exploring.
>
>mjr.
I am in the process of creating a MUD (It's an UberMUD for anyone
that may be interested) and I was wondering about this. Do most
people want to play the muds or just add their favourite castles,
or whatever to them and sit and chat to people???
As my MUD isn't going to be user programmable, I wonder if anyone will
actually play it???
(Anyone who does play it can sumbit to me via email room descriptions,
funky objects if they like, they just won't be able to do it online)
-- Gordon (Irn-Bru) Henderson
(Armed with little more than a cattle-prod and instant camera!)
Ps. Does anyone out there want to tell me about their favourite castle or
puzzles or want to convert it to run on my mud? I'm currently looking
for 3 towers of a large castle (possibly a dungeon) and an island!
Gordon Henderson
>I have a few comments to make to add to this discussion: these are not
>about future MUDs as much as about what MUDs should do now.
>
>
>I think that in general descriptions could be written better. I don't
>want to see descriptions for every part of every object if that will cut
>down on speed or other important factors, but what descriptions do exist
>should be free of typos/spelling errors and be made of full, grammatically
>correct English sentences. Also, they should be organized in a logical
>manner from a player's perspective (spatial order, order of importance,
>etc.).
>
>
>Lisa
Something I wory about in my MUD is what do I do about objects in
the room description that are not really there? Eg. One location
I have looks like this:
The Town Square
This is a nice, clean and tidy town square with a working fountain in
the middle. A small cafe is to the North with the towns public house
to the South. The main road through Fort-Nog runs East-West.
Any objects present would be listed under the room description, indented
by 2 spaces. Eg.
There is a paper bag here.
And objects can have a different description when on the ground. Eg.
for "a red neon sign" (object name) you could have
A Red neon sign floats nearby.
Now, the room description mentions a fountain, but if you type "examine
fountain", you get the "I see no fountain here" message. I have a fair
few rooms like this, and I am at a bit of a loss as to how to handle this.
Do I just leave them as they are, or re-do the descriptions and add objects
for everything? (I personally prefer the way I have it just now) One thing
I could do is to add invisible objects, so I could have a nice
room description, but people would still be able to examine things in
the room. I'm not short of disk space, just time!
I've only had 1 real complaint about this. Feedback welcome!
BTW: The room description above is how it actually comes out from the
look command. I wasn't too sure about clients when I started, on this
(about a year ago) so I decided to pre-format all the text in the game
so using it with telnet wasn't a problem! (I now find that TinyTalk
strips leading spaces )-: but I've been testing a new client (mudview)
and if anyone wants a client for my mud, that is what I'll recomend)
For anyone who is interested, you coud type "get red neon", or "get sign"
or various approximations of whats there. The game is written in Uber
and if anyone wants the matching code I have written, get in touch!
(It handles names with spaces and ambiguous names, case insensitive,
etc. Perhaps you could bolt in into your Unter2s ...)
-- Gordon (Irn-Bru) Henderson
Ps. you can have a look on 192.131.108.2, 6123, but it is by no means
finished yet!
91F9774
>
>A few ideas on economic systems on muds:
>
>The concept of supply and demand is such an easily implemented concept, it isd
>ludicrous. The time to code the manaer for it is the problem, and given the
>current levels of mud prsing and code, it is a bit bulky. Howevere assume
>that all money in the world is created ONCE. That is a money manager the first
>time it is created makes x amount of coins. From here on out, any object that
>is created must be purchased. <Monsters need to have enough gold to buy the
>
>
>As an example. Upon total ame reset <Crash, etc> the ame resets the cash
>manager to the orinial 2 million, it then subtracts the total monetary amount
>the expected places.
>
>Stores will keep track of items, and their value and raise prices of individual
>items accordingly.
>
>I have the full economic model drawn up in detail, and easily workable, though
>it would require some restrictions on wizards coding, but none of them are
>truly as severe as many would think. Feel free to write and I'll more than
>happily share my thoughts and ideas.
>
In the real world, we also *create* new wealth all the time. This is one
of the reasons we had to leave the gold standard. It was stifling economic
growth.
There is also the fact that some creatures actually do add to the wealth
of the game as time goes on (dwarven mining communities for example) by
mining new gems and new gold.
---
Stephen McLeod
The Eternal Student
Ron A. 5150 Echeverri
> For those of us who are still relatively new to USENET and the like, could
>someone please explain what "cascading" is? For that matter, it would be
>useful if someone could post a glossary of terms occasionally...
:-) subscribe to alt.cascade today! If your site doesn't carry it, mail several
cascades to your sysadmin until he does! :>
Bruce Woodcock
> >simulation of newtonian mechanics should probably be an essential part
> ^^^^^^^^^^^^^^
> >of the model, including of course a Euclidean geometry.
> >
>This was a suggestion of something else. Note that I do not suggest that
>the world model be based on newtonian mechanics. That would contradict
>the idea of total freedom for a creator.
Yes, but you suggest the world model simulate it, as well as geometry. To
simulate such events well, you would basically need a world model based on
such things. Sorry if this was nowhat you meant.
>Do you want to keep the 'command response' method or do you have a better
>suggestion?
Yes, the command response method. (See below.)
>To me when the excerpt talk of 'conceptual' objects it talks of objects
>that are 'real' inside the virtual world, people, places artifacts. I do not
>see the contradiction you state.
By 'conceptual' objects I me objects that the user perceives functionally,
not one based on Newtonian mechanics or Euclidean geometry. That is the
contradiction... the world model should be concerned with how the user
sees the world and modifies it, and not on the simulation of the particulars
of atoms meeting atoms, or water having to change a shape attribute when
moving from a square cup to a circular one. Functionally, the water has
simply moved as the user perceives it. Simulating exactly what goes on
during this move is not important, and largely uninteresting. We want the
model to simulate the stuff we see as important and meaningful when changed.
>> INTERACTIONS
>> BETWEEN OBJECTS SHOULD BE DESCRIBED BY FUNCTIONAL MODELS RATHER THAN
>> BY PHYSICAL ONES. [Empahsis mine -- Bruce]
>Oki, what is a 'functional model'? Is this 'command response' in disguise?
I think it is more easily derived from command response, yes, than from
Newtonian mechanics. The world model should be concerned with the user's
interactions that cause changes important to the user (command response),
rather than the physical interactions that occur to get from state A to
state B (newtonian mechanics and euclidian geometry). Muds aren't meant
to copy and reimplement the real world on a smaller scale.
>My idea with a physical model was that it would be easier to achieve
>completeness. The biggest lack in MUDs today are all the 'What ?'s. Maybe
>a 'functional model' of interaction could achieve completeness too.
I think a functional model can have reasonable completeness. Sure, the user
could always try something the mud doesn't expect, but I think you can have
some default cases as well. In any case, I think a few holes are better than
simulating a lot of stuff that the user will never have need to use. A
recursively complex model that "creates as needed" might be necessary here.
Bruce Woodcock
>Well as soon as (fully) distributed MUDs become common (I'm sure they
>will) you'll find some form of "democracy" among the land holders
>(i.e. the machine owners/account owners etc). Interesting (but
>irrelevant) parallel with ancient Greece.
A more interesting parallel is one with the "laws" of history Brooks Adams
came up with around the turn of the century. He proposed that every
civilization progresses (more or less) through four stages:
1. The monopolization of knowledge. By priests, for example, or other
religious leaders.
2. The monopolization of military power. Conquerers, for instance, who
took other people's civilizations by force and divided the land among their
relatives and sycophants.
3. The monopolization of the land. These Land-Lords extract a tribute of
some sort ("rent") for those who live on their land.
4. The monopolization of the issue of currency. Banks, in this way, extract
a tribute ("interest") for each piece of currency put into circulation.
So for muds, then, the series would be similar.
1. The knowledge to run a mud. Originally, only someone who new programming
and such very well could run a mud, and the average user had no alternative
but to abide by that someone's rules, as that was the only mud.
2. The power to run a mud. Once muds were easier to run, they still had to
have a the resources to run one. The average user had to abide by the rules
because the admin put in so much time and effort, and it consumed a lot of
resources.
3. The site to run a mud. Even with a mud that uses little resources (such
as a personal Unter), a viable site has to be available. Admins still have
control, because they have a site, and you don't. The advice of "If you
don't like it, start your own mud" illustrates the problem.
4. This would be the next step, in the future you suggest when it is easy
to have your own mud at your local site. So what then? What's the equivalent
of "currency" in this analogy?
Of course, as you suggest, this whole parallel may be irrelevant. :)
Marcus J. will do TCP/IP for food Ranum
>I think that in general descriptions could be written better. I don't
>want to see descriptions for every part of every object if that will cut
[...]
That's not a server issue, though. That's the same problem for
potentially all MUDs.
I think the thread's intent was discussing future functionality
that servers should include or omit.
mjr.
Johan Andersson
>
> By 'conceptual' objects I me objects that the user perceives functionally,
> not one based on Newtonian mechanics or Euclidean geometry. That is the
> contradiction...
>
Got it.
> I think it is more easily derived from command response, yes, than from
> Newtonian mechanics. The world model should be concerned with the user's
> interactions that cause changes important to the user (command response),
> rather than the physical interactions that occur to get from state A to
> state B (newtonian mechanics and euclidian geometry). Muds aren't meant
> to copy and reimplement the real world on a smaller scale.
>
I hope you're right. It would be much easier to implement, it is basically
already here. The problems I see is to achieve completeness within a system
like this. Current MUDs are exteremely focused on which specific word you
happen to use. All _words_ must essentially be expected by the programmer
and dealt with. Can one have a functional model without focusing on the
specific wording of commands?
> I think a functional model can have reasonable completeness. Sure, the user
> could always try something the mud doesn't expect, but I think you can have
> some default cases as well.
>
You still hold true that the MUD must expect all the different wordings of
commands? What then is the progress compared to the current LPmud?
This is exactly the problem I want to attack. If the creator must explicitely
expect all the things a player could do in a given situation I don't think
a MUD will ever reach reasonable completeness.
> In any case, I think a few holes are better than
> simulating a lot of stuff that the user will never have need to use.
>
I'm pessimistic. I think 'some default cases' will leave much more than
'a few holes'. They do today.
> A
> recursively complex model that "creates as needed" might be necessary here.
>
A nice thought. It must however be related to the 'functional model' of
object interaction. The way it sounds to me with command response, all things
a player can do is already expected by the creator. A given command will
then result in an instant change from state A to state B. There is no need
for a recursively complex model. This is why I find this scheme to be
too primitive to achieve reasonable completeness.
Sonja Orlavski
|> I hope you're right. It would be much easier to implement, it is basically
|> already here. The problems I see is to achieve completeness within a system
|> like this. Current MUDs are exteremely focused on which specific word you
|> happen to use. All _words_ must essentially be expected by the programmer
|> and dealt with. Can one have a functional model without focusing on the
|> specific wording of commands?
The reason current MUDs are focused on which specific word you
use is that most MUDs that I know of do not contain natural-language parsers,
which can parse an entire language (English, for example). Unless you can
parse the entire language and turn it into something the MUD can understand
(predicate logic, for example) you'll have to worry about covering exactly
what the user types. Unfortunately.
It might be interesting to see what would come out of someone
sticking a natural-language processor in front of a MUD...Definately not
a simple prospect, though.
-Devin
--
Devin Hooker (RP90) DoD #0034 de...@boulder.colorado.edu
"It's being both that's a bitch."
"I'm entirely TOO lucid right now."
"This howling in the distance, it's a captivating sound.
Can't tell if it's ecstasy or pain..." -DW
Jack L Needles
Yet again, also in the real world, we are constantly destroying money every
day, and less money actually exists than is changing hands. By far and away
most money exists as 'electronic currency' than real money. But the problem
here lies not in the fact that new money is created. If we assume that money
is created AND destroyed in equal amounts <a not wholly realistic argument to
be sure, but we are not talking reality are we ;) > then there is suitable
cause to maintain a constant level of the amount of gold available. as the
size of the mud grows from say 5 castles to 7 castles or more, the
corresponding pool of available monies should also increase. And again if we
choose to decide to make a fully detailed economy, then yes, we will have NPC
mining companies, and smithies buying their ore from the companies, and so on
with every day life.. but how many players actually think that THAT much detail
is enjoyable. I don't.
I feel that with just the right amount of realistic economy, a mud becomes just
a touch more enjoyable, and a touch more thought provoking. In terms of
creatig a VR world, then yes, the things you mention would need to be
considered with the other underlying factors of any economy.
Cheradenine Zakalwe
>m...@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum) writes:
>| If the observation that "LP and Diku seem to be the most
>| popular MUDs around" is correct, then it's worth figuring out
>| why and what can be done to help it.
> It strikes me that one core difference between the average Diku/LP
>and the average TinyM* is that the former is a game, while the latter
>is a society. I find it unsurprising that more people play a game than
>participate in a new society. I also suspect that a game MUD will be
>noticably differently constructed than a society MUD (for example,
>world consistency is probably a much bigger thing in a game).
Don't we wish. Unfortunately, most administrators of DikuMUDs, at least,
are fairly unconcerned with a global consistancy between their realms.
Also, although TinyM* operate on different precepts than game oriented
MUDs, I don't think this precludes the concept of a society being formed
in a gaming mud. Indeed, in a gaming mud you tend to get all the concepts
of society ... those that like to go out and do things, those that like to
sit around and talk, those that like to destroy the property of others
(all very valid actions, really) ... if there's one flaw in this, it's the
attempts to flush players out and force them to play the game actively. I
find rent particularly annoying (esp. since it doesn't bear any real life
similarity, since your pay is scaled to what you have with you, rather
than simply how long and how much space you want). Ummm, this isn't to
say that players should never be influenced by external events. It might
be nice if a dragon made an attack on a town occasionally in search of
food, etc. But the disruptions should at least have a semi-realistic
feel.
| bai...@rigel.cs.pdx.edu | "The bomb lives only as it is falling." from |
| o--[=====- % @>-^-v---- | _Use of Weapons_ by Iain M. Banks |
Darin Johnson
>>| popular MUDs around" is correct, then it's worth figuring out
>>| why and what can be done to help it.
Gosh, you make it sound like such a bad thing to happen :-)
>> It strikes me that one core difference between the average Diku/LP
>>and the average TinyM* is that the former is a game, while the latter
>>is a society. I find it unsurprising that more people play a game than
>>participate in a new society. I also suspect that a game MUD will be
>>noticably differently constructed than a society MUD (for example,
>>world consistency is probably a much bigger thing in a game).
>
>Don't we wish. Unfortunately, most administrators of DikuMUDs, at least,
>are fairly unconcerned with a global consistancy between their realms.
Unfortunately, this happens quite a lot in LP's too (leading to a bad
LP rap in general). But then again, most all TinyM* have little
consistency either, although Perns are an exception.
>Also, although TinyM* operate on different precepts than game oriented
>MUDs, I don't think this precludes the concept of a society being formed
>in a gaming mud.
Societies in gaming muds have the advantage that money (or whatever)
actually means something (although not too much), and that there is
always the threat of violence holding things together - just like real
life :-). Society in Tiny* is much like communism though - it
requires that everyone participate in order to work. (both are odd
societies, in that people sit around and talk/whatever all day long,
and no one actually works in the fields, etc.)
>It might be nice if a dragon made an attack on a town occasionally
>in search of food, etc.
I've been thinking of things like this off and on. I do remember
though when a similar sort of thing was done on HeroMud, with the idea
that players would put aside their differences and band together for
the greater good. Was actually working for a few minutes, until it
crashed the game :-)
But this brings up something essential to gaming muds. You can log in
at any time, and it doesn't matter if your friends (or anybody) is on,
you can still have fun, explore, experience the scenario, etc. Things
have been set up before hand, and you experience them - much like
reading a book. In Tiny* stuff, you must form your own scenarios,
experiences, tinyplots, etc. Much like writing a book. However, it
doesn't work too well if when you log in, your friends aren't there,
there aren't any tinyplots going on, so you head off to the local
hangouts that are virtually indistinguishable from IRC's... (So why
are gaming muds more common then? Because they're the movie theatres,
and Tiny*'s are the coffee houses :-)
Anyway, if you pulled off this dragon thing, there would probably be
quite a few players who weren't on and missed it (and if you run the
scenario again, it takes all the charm out). How do you solve this
problem? One of my ideas for a mud would be The Village (ala The
Prisoner TV show), but it would take a lot of behind the scenes effort
to actually get the thing to work - and for times when wizards aren't
on to run scenarios, you need precoded stuff for players to do that
won't get old quickly. (probably in LPC or Moo - *gasp* but isn't
LPC only for hack and slash!)
--
Darin Johnson
djoh...@ucsd.edu
Where am I? In the village... What do you want? Information...
Jack_Daniels
|> In article <fortony.706768594@murphy> for...@murphy.cs.uiuc.edu (Felix Ortony) writes:
|> >They've been written, in the main, by people who don't have much
|> >imagination or skill. TinyMUD is limited; MUCK is bloated and
|> >not disk-based; MUSH is a heap; LP is a slow bad idea; Aber is
|> >limited; Uber is a bit too heavy; Diku is LP wearing a leather mask,
|>
|> Heh. GUess what. This is an opinion.
|>
|> Calling Diku an "LP wearing a leather mask" is like calling a BMW a "Yugo
|> wearing a leather mask">
Guess what, that WHOLE section is completely opinion
Tinymud is limited - hrm, tell that to tederuxpin who ran tinyworld to greater
than 10000 objects, and Islandia, and Classic, the last 2 crashed from size,
yet I have NEVER heard anyone complain that they are severly limited, and
limited only by the imagination, I know of safes that were designed, and you could
do a whole hell of a lot if you worked hard enough.
MUCK is bloated and not disk-based - well, that may be true, not that I would
know, not being a great MUCK fan, but I know lots of people that are REALLY into
it, and will swear by it, it's flexibility is great, and the speed of it's MUF
programs is great also. It's not beind disked base isn't necessarily a bad thing
either.
MUSH is a heap - Well, thats just a little bit opinionated now isn't it, I really
like MUSH, it's programming language, as someone said earlier is REALLY easy to
learn, and is the same as the walking around language, you can make simple things
easily, without having to know allot of commands, and while 1.x may be a hacked
version, it is still fairly stable (twilight MUSH was up for 30 days without a
crash, tho I see it has gone down recently, possibly for a code revision of some
kind.) and the hacks mostly revolve around commands, and not the overall
performance of the game. I have not messed around with 2.0 at all, and I wont use
it because of the incredible size of the code, which quite overloads my account,
even tho it is disk based, and quote, unquote, more stable, I don't like it (my
opinion), but then again, I know people that really dislike using anything else,
and would prefer to stay only with 2.0... also, this heap constitues a large
number of worlds, odd, that so many people like 'trash'
Lp is a slow bad idea - here we go again, You say it is a bad idea, I know more
people that play lp, and enjoy hack and slash, then I know who play any other type
of game, and there are more lp's than other types of mu*, so obviously your opinon
here is obviously not even the popular one.
Aber is limited - No comment, I don't know abber
Diku is LP wearing a leather mask - same as aber, but 1 question, do you play
anything at all, or do you just like writing to this group to piss people off by
calling there creation/toy/world/preference a pile of shit??? seeing as you listed
most of the main mu*'s I greatly suspect not
You want to know what I really want in my ideal game??
lets combine everything, make it small and fast
You can use muf or Mush or aber, or whatever to program in, Mage is a good idea,
just poorly done, and by the time it gets done, outdated terribly. But too many
people like too many different things to make anything else, and if it is too
huge, then no one could afford computationally to use it, and it would have to
affect performance time.
The idea about interlinking all the games on the net is a good one, but with the
variety of code out there on the net, that is almost an impossibility, first, you
would have to find some kind of code that everyone likes, something that everyone
would not mind using, and then second, you would have to figure out some way to
upgrade all the code at once, otherwise, you would have sections that were badly
out of date, and this would handicap the whole idea, and thirdly, you would have
to figure out some way to universally store objects, and to make all of this
kind to the net, and bandwidth, otherwize, you would get it installed just intime
to see the entire idea banned
-these are my opinions, and mine alone, feel free to flame, critisize, or even
agree with them
-jack
_________________________________________________________________________
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<OB.SIG> It seems everyone has got to have at least 1, so here mine is!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
-------------------------------------------------------------------------
Bruce Woodcock
>Tinymud is limited - hrm, tell that to tederuxpin who ran tinyworld to greater
>than 10000 objects, and Islandia, and Classic, the last 2 crashed from size,
>yet I have NEVER heard anyone complain that they are severly limited, and
>limited only by the imagination, I know of safes that were designed, and you
>could do a whole hell of a lot if you worked hard enough.
Well, it was limited to some extent, but I think it was a nice system, all
things considered.
Anyway, while Islandia and Classic were indeed large, they didn't really
"crash" from their size. Islandia was too big for the machine it ran on,
but what relly doomed it was the politics of the wizards involved, who did
not want to keep it running anymore. However, I think even if they had, it's
size might have made finding a new site prohibitive.
Classic (at least when I ran it) was also big, but not too big for the machine
it was on. It died because of department politics when I lost my account, but
would have died in another week or two anyway as the machine was going away.
It too would have had trouble finding a site because of its size.
So yeah, they did suffer from bloat, but that wasn't primary to their downfall.
Chris Gray
(Gordon Henderson) writes:
>Something I wory about in my MUD is what do I do about objects in
>the room description that are not really there? Eg. One location
>I have looks like this:
>
>The Town Square
> This is a nice, clean and tidy town square with a working fountain in
> the middle. A small cafe is to the North with the towns public house
> to the South. The main road through Fort-Nog runs East-West.
>
>Any objects present would be listed under the room description, indented
>by 2 spaces. Eg.
>
> There is a paper bag here.
>
>And objects can have a different description when on the ground. Eg.
>for "a red neon sign" (object name) you could have
>
> A Red neon sign floats nearby.
>
>Now, the room description mentions a fountain, but if you type "examine
>fountain", you get the "I see no fountain here" message. I have a fair
>few rooms like this, and I am at a bit of a loss as to how to handle this.
>Do I just leave them as they are, or re-do the descriptions and add objects
>for everything? (I personally prefer the way I have it just now) One thing
>I could do is to add invisible objects, so I could have a nice
>room description, but people would still be able to examine things in
>the room. I'm not short of disk space, just time!
>
>I've only had 1 real complaint about this. Feedback welcome!
I ran into this when doing a standard mudlib for my AmigaMUD. I wanted to
put nice descriptions in, and when I sat people down to playtest, they
almost always tried to do things with the stuff in the descriptions. It
makes sense that they would - much of the puzzle solving in adventures like
Infocom ones is that of thinking of things to try.
What I came up with was the idea of having 'scenery' in each location.
My parser stuff uses a standardized form like 'noun;adj,adj...' for noun
phrases, and allows multiple such forms to be strung together, separated
by periods. E.g. for the front of a house, I have this:
scenery(r_porch,
"house."
"wall;white,siding-covered.wall;white,siding,covered."
"trim,shutters;green."
"porch."
"railing;white,and,green."
"loveseat;swinging.seat;love,swinging."
"table;round,white."
"chair;four,matching,wicker."
"flowerpot;hanging.pot;hanging,flower."
"post;support."
"flower;blooming."
"fern;trailing."
"door;front").
This just stores a string in the object representing the room. Then for all
commands (I provide standard routines in the mudlib to make it trivial), which
look for something 'here', if I don't find the object as a real (perhaps
hidden) object, I check it against the scenery string. If it matches, then
the object is 'sort of here', and the command gives a generic 'you can't
do that' response, like 'get love seat' => 'You can't get the love seat.'
Only if I want to get real flowery would I make a hidden object with an
actual description string.
--
Chris Gray alberta!ami-cg!cg or cg%ami...@CS.UAlberta.CA
Chris Gray
d8a...@hacker.dtek.chalmers.se
>I hope you're right. It would be much easier to implement, it is basically
>already here. The problems I see is to achieve completeness within a system
>like this. Current MUDs are exteremely focused on which specific word you
>happen to use. All _words_ must essentially be expected by the programmer
>and dealt with. Can one have a functional model without focusing on the
>specific wording of commands?
>
>>[deleted]
>
>You still hold true that the MUD must expect all the different wordings of
>commands? What then is the progress compared to the current LPmud?
>
>This is exactly the problem I want to attack. If the creator must explicitely
>expect all the things a player could do in a given situation I don't think
>a MUD will ever reach reasonable completeness.
This is a bothersome aspect of some MUDs, like LP. By not going to quite
that extreme of having the basic driver not have much parsing, you can make
things a lot friendlier. As an example from AmigaMUD:
[some of the setup for the 'look' verb]
Verb1(G, "look", Word(G, "at"), v_look).
Verb0(G, "look", Word(G, "around"), v_lookAround).
Synonym(G, "look", "examine").
Synonym(G, "look", "l").
[the setup for the 'pad of paper' object]
ignore AddForSale(r_mallStore, "pad,paper;writing.paper;pad,of",
"The writing pad is quite ordinary. It provides an "
"infinite supply of sheets to write on.",
1, nil).
With nothing more than this on the part of the MUD programmer, the user can
type any of the following:
Look at the writing pad.
examine pad of paper
l pad
etc. [it's also happy with 'examine at of paper', but so what?]
and they will all work just fine. This is because the concepts of articles,
adjectives and nouns are known the the server's parsing code. There is no
global dictionary of anything other than the initial verbs, however, so
problems about multi-use words don't come up.
Cheradenine Zakalwe
>What do you think MUDs should be able to do 2 years from now?
I think an important change in the server design might be the use of multi-
threading. Note that when I say multi-threading, I do _not_ mean forking
or vforking a copy of the mud and creating another Unix process. What I'm
talking about here are multiple-threads of execution within one process, as
in the Light Weight Processes library included with later versions of
SunOS. Effort is being put forth to implement these at a kernel level,
which will add even more functionality. The thing about using multi-
threading is that it makes storing context information completely
uneccesary, as this is handled automatically by the seperate stacks of the
multiple threads (obviously, this has to be taken into account at a design
level, since you'll need to worry about resource sharing among threads,
avoid local static data, etc.).
Larger amounts of memory in workstations should make it so that we can
design muds with larger in-memory databases (this is not to say that disk
based servers will be invalidated, but rather you'll be able to cache more
data and you'll be able to concentrate on making more complicated objects).
Another design issue I've considered is that everything in the server
should be an object. This one is questionable, perhaps. In Diku, for
example, everything is split into three major categories: mobiles, rooms,
and objects. This leads to a lot of coding hassles as well as leaving out
a lot of functionality. A system I've toyed around with would give the
ability to assign any object "properties", such as mobile properties,
weapon properties, light properties, etc., allowing a single object to be
many things. The big questions here are, "Does it take up too much space?"
and "Is it too inefficient?" As processor speeds and memory amounts
increase, this should become less of a problem.
>What are the biggest problems with the current generation of MUDs?
First on my list is predictability. The current ranges of MUDs out there
are, for the most part, static. I'm using Diku here a lot because I favor
gaming oriented MUDs and because I'm most familiar with its design. In
Diku, mobiles tend to appear in the same places, act in the same
predictable ways, and for the most part the whole thing is fairly
predictable once you've got some experience in. This isn't to say one can
never make a mistake on the game, but rather that it becomes fairly
obvious what mistake you've made each time, and in a similar situation you
can expect the same results.
Gaming MUDs also tend to favor on some of the worst aspects of role-
playing (building wealth, killing for no reason, etc.), and it would be
nice to see it include some of the better aspects, such as waging a war
against others for a reason (a difference of opinion, to gain the other
fellow's land, etc.), solving puzzles and interacting with NPCs. NPC
interaction is, however, the only one I don't expect to see major improve-
ments upon in the next two years.
MUD worlds tend to be less than cohesive. I'd like more of a feal of
walking around a single world than one of stepping through some magic
curtain from one completely different realm to another. Niceties would
include things such as a global economy with multiple currencies, wars
between lands, etc.
>What would your ultimate MUD server be able to do? And why?
Basically, the above comments reflect my attitude of what a MUD should
do with what we've currently got or are fairly close to. The reason? Well,
the current rank of MUDs seem somewhat stagnant (i.e., not a whole lot of
new, radical servers seem to appear, perhaps understandably, since writing a
server is a lot of work.).
>(to put comments in perspective) What purpose do you see in MUDs?
My own personal perception is that MUDs are games and although they can
make nice environments for someone unfamiliar with computers to communicate
in, they'll tend to remain games first and foremost. This is not to say
that games are bad. Look at how much of this nation's industries are
devoted towards entertaining people. What I'd like to see is a wider
acceptance that playing games is okay, and that games have their proper
place. The narrow minded seem to want to remove MUDs from existance because
most are built upon "educational institutions". I think it's high time
these so called "places of learning" learned that entertainment is a valid
form of education and that a MUD can be deemed a valid use of resources, as
long as some sort of discussion occurs between the people running the MUD
and the educational administrators. If university resources are to be
utilized only for education, I suggest we remove all of the arcades, all of
the sporting equipment, and all of the drama and art departments from every
university in the nation. Might I suggest that since computers are seen as
a more serious medium, those of us who see entertainment as a viable medium
are frowned upon because we violate some inner code that computers are for
number crunching only.
>What is the single most important thing that makes a MUD good? And why?
Whew, you sure like to ask hellish questions! I'd say the single most
important thing that makes a MUD good is quality. That is, there needs to
be a desire at every level to bring the player the utmost of playing
experiences that can be devised. Not this ramshackle attitude of slapping
together a MUD server overnight, nor of featuritis by adding in everything
indiscriminatorily.
>If you could put together a server with a wave of a magic wand,
>describe it.
It would make an honest effort to encompass as many of the above mentioned
things as possible. In fact, I do intend to finish a MUD server at some
point, and it will attempt to support the things mentioned above (or at
least those I deem practical), it's just that it's a hell of a lot harder
than waving a magic wand. Maybe I should work on writing a MUD server
coder special for Diku and let the mobiles do the work. :)
Gordon Henderson
Excelent idea and trivial to add to my Uber universe rules! Thank you!
----
Gordon (Inr-Bru) Henderson
Joern Rennecke
>In article <DANDJO.92M...@hacker.dtek.chalmers.se>, d8a...@hacker.dtek.chalmers.se (Johan Andersson) writes:
>|> I hope you're right. It would be much easier to implement, it is basically
>|> already here. The problems I see is to achieve completeness within a system
>|> like this. Current MUDs are exteremely focused on which specific word you
>|> happen to use. All _words_ must essentially be expected by the programmer
>|> and dealt with. Can one have a functional model without focusing on the
>|> specific wording of commands?
> The reason current MUDs are focused on which specific word you
>use is that most MUDs that I know of do not contain natural-language parsers,
>which can parse an entire language (English, for example). Unless you can
>parse the entire language and turn it into something the MUD can understand
>(predicate logic, for example) you'll have to worry about covering exactly
>what the user types. Unfortunately.
> It might be interesting to see what would come out of someone
>sticking a natural-language processor in front of a MUD...Definately not
>a simple prospect, though.
> -Devin
I think that putting the natural langage procerssor *in front* of the mud would
be a misconception of the meaning of natural language.
Although there might be some demand for server support to get efficiency,
all natural language parsing should be within the objects of the game, so that
you don't hard-code a particular language into the server.
Moreover, the basic vocabluary has to be provided by the objects that define
actions, lest you want to end with a vocabluary that simply can't support
new things that require unknown words.
To get more completeness than there would be with a medium-detailed worked out
object oriented vocabluary, there sould be a user model, that represents some
of the conceptions of the player that the language is parsed for, and some
global world rules - and maybe some less global world rules, that are only
visible in a convex subset of the space .
To face the ambiguity of natural language parsing, a number of objects might
have to be enquired how believable a given possible derivation is. If there is
a single interpretation possibility with outstanding likelyness, it is
considered to be the meaning of the input sentence. Else, the player is queried
for further explanation of his desire, with some hints on the current
ambiguity.
To make continued use of tools with artifical command languages possible
without bloating the natural language processer, the tools actions should be
checked first; this can be implemented stragtforward in an LPmud.
amylaar
Johan Andersson
> This is a bothersome aspect of some MUDs, like LP. By not going to quite
> that extreme of having the basic driver not have much parsing, you can make
> things a lot friendlier.
>
Yes, by having a global parser it is easier to add synonyms. You have to
add them though. The big drawback is that you now have a centralised
piece of code in the driver managing game related information. This is in
deep conflict with the principle of 'creative freedom' for builders. Also,
you haven't really solved the problem. You still have to expect all the
synonyms.
> As an example from AmigaMUD:
>
> [some of the setup for the 'look' verb]
> Verb1(G, "look", Word(G, "at"), v_look).
> Verb0(G, "look", Word(G, "around"), v_lookAround).
> Synonym(G, "look", "examine").
> Synonym(G, "look", "l").
>
>
> [the setup for the 'pad of paper' object]
> ignore AddForSale(r_mallStore, "pad,paper;writing.paper;pad,of",
> "The writing pad is quite ordinary. It provides an "
> "infinite supply of sheets to write on.",
> 1, nil).
>
This looks similar to old ADL stuff. This kind of system lacks the power of
ease of extension that a fully object oriented MUD like LP gives. OO in the
modelling sense not in the language sense, that is. You have bought minor
advantages in parsing by sacrificing the capability to support hundreds of
simultaneos independant builders.
> With nothing more than this on the part of the MUD programmer, the user can
> type any of the following:
>
> Look at the writing pad.
> examine pad of paper
> l pad
> etc. [it's also happy with 'examine at of paper', but so what?]
>
This much and more is possible in LPmud too, through parse_command. But
synonyms are not the essential problem. Let me state, a hopefully, clarifying
example:
You're mission is to bring the head of a Demon to your king. You have
turned your foe into a wooden statue with a spell.
The builder expects you to type: 'chop head from statue with axe'
with synonyms for chop, statue and axe prepared.
A possible dialogue:
>get head
There is no head here.
>get head from statue
There is no head in the statue.
>cut away head
What?
>take statue apart with axe
The statue is too heavy.
>use axe to chop away the head from the statue
What?
>cut the statues neck off
Cut what?
....... etc
I could continue. You wouldn't believe what a lot of alternatives
people come up with that you as a builder didn't think of.
This is why I'm not convinced by a functional model based on command response.
If I had a ready solution I'd present it, but I haven't. This is to me the
central crux in MUDs today.
Felix Ortony
>
>Guess what, that WHOLE section is completely opinion
>
No doubt. Imagine! Someone posting opinion to the net!
>Tinymud is limited - hrm, tell that to tederuxpin who ran tinyworld to greater
>than 10000 objects, and Islandia, and Classic, the last 2 crashed from size,
>yet I have NEVER heard anyone complain that they are severly limited, and
>limited only by the imagination,
Then you've been hanging around the wrong people. The TinyMUD command set
is very small and not very powerful, and the fact that the entire database
is stored in RAM is a major sticking point.
>I know of safes that were designed, and you could
>do a whole hell of a lot if you worked hard enough.
"if you worked hard enough," you could mount enormous engines on the Earth
and PROPEL IT DIRECTLY INTO THE HEART OF THE FLAMING MAELSTROM THAT IS THE SUN!
TinyMUD's limited because it makes you work too hard for results that aren't
as interesting as other MUDs' results are.
>
>MUCK is bloated and not disk-based - well, that may be true, not that I would
>know, [... - ed] , but I know lots of people that are REALLY into
>it, and will swear by it,
Swearing by it and getting into it makes MUCK neither nonbloated nor
diskbased. If you're going to attack my opinions, at least, well, attack them.
>it's flexibility is great, and the speed of it's MUF
'its' is the neuter possessive, first of all, and neither of these points
are being argued here.
>programs is great also. [...]
>It's not beind disked base isn't necessarily a bad thing
>either.
Well, false, unless you happen to have a machine that doesn't mind dedicating
64M of real memory to a game.
>
>MUSH is a heap - Well, thats
contraction of 'that is' is "that's."
>just a little bit opinionated now isn't it, I really
Yes, it is. Of course it is. What newsgroup do you think you're reading?
>like MUSH, it's programming language,
Good for you. What makes your particular opinion interesting?
By the way, the line breaks in the following piece of prose poetry are mine.
I had to insert them because you failed miserably to press RETURN at the
appropriate times.
>as someone said earlier is REALLY easy to
>learn, and is the same as the walking around language,
>you can make simple things
>easily, without having to know allot of commands, and while 1.x may be a hacked
>version, it is still fairly stable (twilight MUSH was up for 30 days without a
>crash, tho I see it has gone down recently,
>possibly for a code revision of some
>kind.) and the hacks mostly revolve around commands, and not the overall
>performance of the game.
Hey, I've got a quick quiz for you -- what compromises the game? The user
interfacing with a virtual world? Yes? Ooh, scribble down for yourself
a point! Now, here's another question -- how does the user do it? Through
commands, you say? Say, if the command set is a grotesquely hacked piece
of garbage...
>I have not messed around with 2.0 at all, and I wont use
>it because of the incredible size of the code,
>which quite overloads my account,
>even tho it is disk based, and
> quote, unquote, more stable, I don't like it (my
>opinion), but then again,
Right. So even though it's clearly better, you don't like it. At least
my opinions have loose theoretical support.
>I know people that really dislike using anything else,
>and would prefer to stay only with 2.0... also, this heap constitues a large
>number of worlds, odd, that so many people like 'trash'
A surprisingly huge number of people watch Roseanne Barr. This doesn't make
her gorgeous, interesting, funny or urbane, and it doesn't make those people
tasteful or cultured.
>Lp is a slow bad idea - here we go again,
>You say it is a bad idea, I know more
>people that play lp, and enjoy hack and slash,
>then I know who play any other type
>of game,
Ooh. Write that down, everyone -- Jack Daniels' experience includes more
people who play LP than who play any other kind of MUD. This is clearly
the weighty fact which breaks the back of my opinion.
> and there are more lp's than other types of mu*, so obviously your opinon
>here is obviously not even the popular one.
Even assuming that you were right in your false claim that there are more
LPMUDs than other types of MUD, my answer would be "so?" My opinion is
the correct one, and yours is the false one based on illogical sentiment
and useless pseudofacts cooked up by a mind dulled by drooling repetitive
hours gazing dully at a telnet session to a hack and slash server which
basically amounts to a big Pavlovian rat-pellet gedankenexperiment.
>
>Aber is limited - No comment, I don't know abber
>
>Diku is LP wearing a leather mask - same as aber, but 1 question, do you play
>anything at all,
>or do you just like writing to this group to piss people off by
>calling there
their
>creation/toy/world/preference a pile of shit??? seeing as you listed
>most of the main mu*'s I greatly suspect not
Oops, you fail. I play MUSH 2.0 and UnterMUD 2.1s, currently. Both of
which could use some serious improvement.
>
>You want to know what I really want in my ideal game??
No. Given the shoddy quality of your opinions and grammar above, I suspect
I won't, either.
>lets combine everything, make it small and fast
Hey, that's a great idea. While we're at it, why don't we make an operating
system that fits within 1K of memory, a chip that runs at ten gips, a cure
for cancer derivable from toothpaste and sealing wax, and a bomb that kills
ONLY THE STUPID PEOPLE?
>You can use muf or Mush or aber,
> or whatever to program in, Mage is a good idea,
>just poorly done,
>and by the time it gets done, outdated terribly. But too many
>people like too many different things to make anything else, and if it is too
>huge, then no one could afford computationally to use it, and it would have to
>affect performance time.
Hey, you sound like quite the brilliant programmer. Why don't you go
ahead and tell us your proof that mjr's Object Interchange Format doesn't
exist?
>The idea about interlinking all the games on the net is a good one,
>but with the
>variety of code out there on the net, that is almost an impossibility,
False.
>first, you
>would have to find some kind of code that everyone likes,
False.
>something that everyone
>would not mind using, and then second,
>you would have to figure out some way to
>upgrade all the code at once,
False.
>otherwise, you would have sections that were badly
>out of date, and this would handicap the whole idea,
False.
>and thirdly, you would have
>to figure out some way to universally store objects, and to make all of this
Already been done.
>kind to the net, and bandwidth, otherwize,
>you would get it installed just intime
>to see the entire idea banned
False.
>-these are my opinions, and mine alone, feel free to flame, critisize, or even
>agree with them
Okay.
>-jack
Felix Ortony
>de...@frodo.colorado.edu (Sonja Orlavski) writes:
>> It might be interesting to see what would come out of someone
>>sticking a natural-language processor in front of a MUD...Definately not
>>a simple prospect, though.
>
>be a misconception of the meaning of natural language.
Your point is interesting, but unfortunately, you're postulating a system
which actually understands natural language. Such a system doesn't exist,
and probably never will.
>Although there might be some demand for server support to get efficiency,
>all natural language parsing should be within the objects of the game, so that
>you don't hard-code a particular language into the server.
MUDding is a very small domain, and doesn't require the heavyweight
artificial intelligence support you're recommending here. In fact,
hard-coding a particular language into the server (the reduced set of
instructions generated by the parsing of the english language front end)
is The Right Thing To Do.
>Moreover, the basic vocabluary has to be provided by the objects that define
>actions, lest you want to end with a vocabluary that simply can't support
>new things that require unknown words.
A good front end will supply extensibility.
>To get more completeness than there would be with a medium-detailed worked out
>object oriented vocabluary, there sould be a user model, that represents some
>of the conceptions of the player that the language is parsed for, and some
>global world rules - and maybe some less global world rules, that are only
>visible in a convex subset of the space .
I can't parse what you're saying, but taking a few words at a time, it
sounds like you're talking about caches and compiling. No problems there.
>To face the ambiguity of natural language parsing, a number of objects might
>have to be enquired how believable a given possible derivation is. If there is
>a single interpretation possibility with outstanding likelyness, it is
>considered to be the meaning of the input sentence. Else, the player is queried
>for further explanation of his desire, with some hints on the current
>ambiguity.
Standard implementation of a natural language parser, yes.
>To make continued use of tools with artifical command languages possible
>without bloating the natural language processer, the tools actions should be
>checked first; this can be implemented stragtforward in an LPmud.
LPMud will not be the platform of choice for a natural language parser.
>
> amylaar
Felix
Mud Admin
>1) Objects need to be standardized. Having 11 different types of shortswords
>all with different weights, weapon classes, and having all the same
>descriptions of 'a shortsword' is ludicrous. In rpg's there are standardized
>weapons and armor and generic objects and if muds are to emulate a 'fantasy
>world' they should as well.
Hmmm, I have a feeling that there is more to forging a sword than
pouring a standard amount of liquid steel/iron into a mold of the
appropriate size and shape. It seems to me that there is a huge
amount of difference between swords of the same class, unless they
have been manufactured by machines. The little reading I have done
concerning Japanese katana collecting strongly supports this idea.
I would tend to agree that someone should describe a weapon more
thoroughly if they want it to be 'special', but to limit everyone to
one sword if they want a shortsword is a bit much.
sulam
--
| This article is the individual opinion of a TMI Admin.
| The Mud Institute: dogstar.colorado.edu (128.138.248.32) 5555
| Ftp: "" "" 5554
| TMI serves as an information and development center for LPmuds.
Roger B. Dubbs III
>A possible dialogue:
>>get head
>There is no head here.
>>get head from statue
>There is no head in the statue.
>>cut away head
>What?
>>take statue apart with axe
>The statue is too heavy.
>>use axe to chop away the head from the statue
>What?
>>cut the statues neck off
>Cut what?
>....... etc
>I could continue. You wouldn't believe what a lot of alternatives
>people come up with that you as a builder didn't think of.
>
>This is why I'm not convinced by a functional model based on command response.
>If I had a ready solution I'd present it, but I haven't. This is to me the
>central crux in MUDs today.
>
>/Johan
Hi, Commander! *smile* I just have one point to make about this. In
our LP (Genesis) we have an "idea" command. To me, when a player finally
accomplishes the task, by the appropriate command, he should then tell
the builder all the possibilities he tried, that should have worked,
with the idea command. If the builder then adds those patterns to his
list of acceptable ones, eventually, nearly any sentence would work,
assuming it is to perform the correct action.
The key here is feedback from the players, and action by the builder.
Without either, the system doesn't work. There is probably too little
of both of these.
/Roger (aka Quis)
Mud Admin
> I've thought of this problem, and had an interesting idea- the
>concept of 'unreal' objects.
*Nod*, this idea has been implemented successfully on several
different muds, although the 'correct' term is virtual objects.
The TMI driver, MudOS, supports this more completely through
a method in master.c. If an object references a file that
doesn't exist, then compile_object(string file) is called.
If compile_object returns an object, then the driver treats
that object as if it was loaded from whatever file we wanted.
However, this doesn't really solve the problem that we were
discussing. Unless you have a set of rules that can calculate
how much 'resource' should be created in a given time, you need
the objects in question to exist at all times. And if you were
to create such a rule you would be explicitly affecting the market.
I doubt there's any real solution to this problem, since everything
has to be coded--unless people want to sit and harvest wheat for
a while... ;-)
Sulam
ps. Perhaps the solution is some sort of random distribution
based on climate, worker psychology, and tendency towards
disaster--but I'm not going to spend my time trying to figure
out how to write the equation... ;)
Mud Admin
>Something I wory about in my MUD is what do I do about objects in
>the room description that are not really there?
The way an LPmud handles this is to add to the things a room
will 'id' to. If someone looks for something, then a call to
present() is made, and the driver checks the function id() in
all the objects in the room. The room would have a list of
items that are referred to in the description. present() returns
the object that we are trying to find, and then we call query_long()
in that object. In the case of 'look' we call it with the string
that one is looking at as an argument. The room then indexes on
that string, and writes the appropriate description to the screen.
It is also standard practice to have 'take' write something useful
to the player, and some mudlibs go so far as to allow a room to
specify a 'get-function' for an item, so that you can have more
realistic effects (perhaps the object would be created, or maybe
trying to pick up a book on a bookshelf would open a secret door
somewhere).
A typical working example follows:
inherit "/std/room";
void setup()
{
set_light(1);
set_short("Sulam's Workroom");
set_long(
" This is Sulam's workroom. It's a friendly little place, with\n"
...
);
set_exits(
...
);
set_item_descriptions(
({
"desk", ... "books",
}),
({
"The desk is...",
...
"There are enough books...",
})
Roger B. Dubbs III
>jnee...@magnus.acs.ohio-state.edu (Jack L Needles) writes:
>
>>1) Objects need to be standardized. Having 11 different types of shortswords
>>all with different weights, weapon classes, and having all the same
>>descriptions of 'a shortsword' is ludicrous. In rpg's there are standardized
>>weapons and armor and generic objects and if muds are to emulate a 'fantasy
>>world' they should as well.
>
>Hmmm, I have a feeling that there is more to forging a sword than
>pouring a standard amount of liquid steel/iron into a mold of the
>appropriate size and shape.
Quite right. A sword is forged, not cast. This is a process which
involves repeatedly heating a bar of metal, and pounding the cr-p out of
it until it is in the correct shape. There is more to it than that, but
I wanted to set the record straight. 8) 8)
> It seems to me that there is a huge
>amount of difference between swords of the same class, unless they
>have been manufactured by machines. The little reading I have done
>concerning Japanese katana collecting strongly supports this idea.
>I would tend to agree that someone should describe a weapon more
>thoroughly if they want it to be 'special', but to limit everyone to
>one sword if they want a shortsword is a bit much.
>
>sulam
Nobody is in favor of restricting a creators imagination. I have been
wrestling with this problem on Genesis, somewhat. The problem is, that
many creators have different ideas on what weapons values are. It is
not bad to establish a baseline, and let people deviate from that, due
to quality (or lack of), materials, magic, and so on. The key, IMHO, is
in _justifying_ why you are different from the baseline. This
justification is what makes your world consistent.
/Roger (aka Quis)
Mud Admin
>Jack_Daniels writes:
>>fortony writes:
>>> Lp is a slow bad idea -
>
>> here we go again, You say it is a bad idea, I know more people that
>> play lp, and enjoy hack and slash, then I know who play any other type
>> of game,
>
>Ooh. Write that down, everyone -- Jack Daniels' experience includes more
>people who play LP than who play any other kind of MUD. This is clearly
>the weighty fact which breaks the back of my opinion.
>
>> and there are more lp's than other types of mu*, so obviously your opinon
>>here is obviously not even the popular one.
>
>Even assuming that you were right in your false claim that there are more
>LPMUDs than other types of MUD, my answer would be "so?" My opinion is
>the correct one, and yours is the false one based on illogical sentiment
First things first. If I look at Scott's mudlist I find quite
a few more LP's than I do other muds. On what are you basing your
refutation of Jack's claim?
Second, exactly what has your experience of LP's been? Have you
ever run one? Ever coded on one? Ever been on one for more than
an hour? If you want us to agree that your opinion is "the correct
one" you'll have to do more than just state that this is so.
You have said that "LPmud is a slow, bad idea". Can you clarify
exactly what you mean here? Admittedly an interpreted language
is probably going to run slower than a compiled one, but it does
offer considerable bonuses in flexibility and design. I also
haven't noticed that LP's run noticeably slower than the Mucks,
Moos, or Mushes that I have logged into.
Sulam
Scott Goehring
>> and there are more lp's than other types of mu*, so obviously your opinon
>>here is obviously not even the popular one.
>Even assuming that you were right in your false claim that there are
>more LPMUDs than other types of MUD, my answer would be "so?"
From my mudlist, v3i9:
66 LPmuds, 38 DikuMUDs, 20 TinyMUSHes, 12 AberMUDs, 8 TinyMUCKs, 7
UnterMUDs, 7 TinyMUSEs, 4 MUDWHO servers, 2 TinyMUDs, 2 MOOs, 2 DUMs,
1 uber, 1 phoenix, 1 naive, 1 mage, 1 YAMUD, 1 Visual MUD, 1 UriMUD, 1
TeenyMUD, 1 MUG.
Now, I don't claim that my list is all-inclusive, but LPmuds outnumber
the "leading competitor" by quite a bit, and compose 37% of the muds
on the list. Not a majority, but a strong plurality.
--
A man walks into a crowded theater and shouts, "ANYBODY WANT TO BUY A
CAR?" The crowd stands up and shouts back, "WRONG THEATER!"
-- Edward Vielmetti (e...@msen.com), news.admin
Darin Johnson
>>the room description that are not really there?
> set_item_descriptions(
> ({
> "desk", ... "books",
> }),
On our mud (Marches of Antan), we also allow the description to
actually be a function or contain strings that are expanded via
function calls. For some simple examples:
add_item("door", "The door is @@door_status@@.\n");
add_item("shadow#shadows#corner", "*look_shadow*");
door_status() { return (door_open ? "open" : "closed"); }
look_shadow() {
write("You glimpse something hidden in the shadows.\n");
clone_object(blah);
move_object(blah, here);
}
Turns out to be really useful, and you don't have to be a great programmer
to get interesting effects.
I think you can do similar stuff in MUCK or MOO, but haven't looked at
that in awhile (and I refuse to call MUSH a progamming language). I
think SLUDGE (?) supports lazy semantics (similar to Scheme), so that
one could define a string to be something like:
(concat "The door is " door-state ".\n")
and it won't be evaluated until the string is actually printed. These
sorts of non-C semantics would be really useful to have in future
muds. (Actually, I'd like to see examples of modern commercial muds)
--
Darin Johnson
djoh...@ucsd.edu
- Grad school - just say no.
Darin Johnson
>UnterMUDs, 7 TinyMUSEs, 4 MUDWHO servers, 2 TinyMUDs, 2 MOOs, 2 DUMs,
>1 uber, 1 phoenix, 1 naive, 1 mage, 1 YAMUD, 1 Visual MUD, 1 UriMUD, 1
>TeenyMUD, 1 MUG.
To be fair, there's a large number of crappy LP's out there. Anyone
out there willing to divide things into worthy and unworthy muds? :)
Scott Goehring
>To be fair, there's a large number of crappy LP's out there. Anyone
>out there willing to divide things into worthy and unworthy muds? :)
Count me out. It's enough work just keeping track of them.
--
"No, I don't know that atheists should be considered as citizens, nor should
they be considered patriots. This is one nation under God."
-- President George Bush, Chicago, August 27, 1988
Jack L Needles
Exactly, Roger. My basic reasoning for standardization is to make things a bit
more cohesive. As someone who has tried to make his own sword, and seen how
vastly inferior it was to his mentors work, I know there can be large
differences in quality from place to place. The question that needs to be
asked however, is how much variation can be justified, and how extreme that
variation can be. A weapon is much more likely to be of worse quality than the
norm if it is farther from a main living center than it is in a major town.
That is unless magic or some special unknown techniques are located nearby.
But I do not think that a shortsword should be able to be the equivilent of
someone else's longsword unless that longsword is of a really sad quality.
Prydain
Jean Marie Diaz
But then again, most all TinyM* have little
consistency either, although Perns are an exception.
Hey, we all know this is because Perns are run by the most
anal-retentive, unfriendly, bitchy, fascist, obnoxious, martinet-like
excuses for wizards that have ever existed.
But hey, what Darin says above is a hell of a compliment to every single
one of 'em anyway. Thanks.
Dosage: take this posting with a liberal sprinkling of smileys.
AMBAR
One of the few. The proud. The totally insane. The SouCon/PernMUSH wizards.
Jean Marie Diaz
I think you can do similar stuff in MUCK or MOO, but haven't looked at
that in awhile (and I refuse to call MUSH a progamming language). I
think SLUDGE (?) supports lazy semantics (similar to Scheme), so that
one could define a string to be something like:
(concat "The door is " door-state ".\n")
and it won't be evaluated until the string is actually printed.
MUSH may not be a programming language, but;
&desc here = A brightly lit office. The window is [v(window)], the
desk is [v(desk)], and the door to the hallway is [v(door)].
&desk here=littered with paper
&window here=open to admit light, air, and the occasional firelizard
&door here=closed
Now, 'look here' produces:
A brightly lit office. The window is open to admit light, air, and the
occasional firelizard, the desk is littered with paper, and the door to
the hallway is closed.
Now, add a bit of code to provide control of the state of these things,
and voila. (This is a greatly simplified example of what Fylora's
office on SouCon actually looks like.)
MUSH isn't a programming language. Maybe this is why it can be used by
biochem majors and other non-programmers to produce some fairly complex
objects. (Stop into PernMUSH sometime and ask for a tour of one of the
Thread trainers.)
cheers,
AMBAR, code hack at large
IO1...@maine.maine.edu
to program a language. However the MUSH code is great in allowing
somebody like me to design a very complex area. What you need in any
type of MU* where you expect people to be able to program is a basic
easy language that any of us can learn. To see what a simple computer
illeterate can design on a MUSH stop by the Dryad Forest on BelgariadMUSH
someday.
Oh by the way, while I think PernMUSH is consistent, its not alone,
syop by Belgariad sometime, and see another consistent MU* done on
an entirely different concept. The works of Deavid Eddings.
Also I think you'll start to see more roleplaying MUSHs based on entirely
new worlds, the soon to be up TaeisMUSH is an example.
X'leda @BelgariadMUSH