Ressurect: Future of Mudding - User Interfaces and Distrbuted MudServers
Emmanuel Turner
Et casts a Resurrect on the Future of Mudding Thread.....*Ping* It's alive
Jim...
Here's a couple of ideas about the future of mudding, or where mudding
can/might/will improve...
User Interfaces
I reckon that the commandline user-interface used by most muds is too
daunting for a large number of users, but telnet is standard and is freely
available to almost any client OS. It seems that every time a thread
starts to develop on a using a different interface, it gets shot into the
"Is Not Standard" or "Would Eliminate Lots of Clients" basket.
Is there any work being done on creating a graphical mud protocol standard
so that clients can be written for it? or Do you think that it is better
to write the clients as downloadable java applets ?
In short, in order to capture a wider audience, mudding will need to have a
nicer (ie less typing) interface. Even if your mud is based purely on
text, a couple of short-cut buttons, or having the text arranged into
windows (eg one for comms, one for location descriptions, one for stats
etc.) will make your users life easier.
Distributed Mud-Drivers
With the internet becoming more and more popular, and with the potentially
huge numbers of people that could play MUDs in future, and from potentially
globally diverse places in the world, I think that creating a distributable
mudlib could help to ease lag problems. Also looking at LPC, the language
would scale to a distributed model quite well, only the LP Driver would
need to be changed to be able to support the distribution model.
Distributing a mud like this can also mean that more CPU intensive stuff
can be done, simply because the CPU load is shared between physically
seperate machines.
That's the bluesky part of this message, I do see many technical/political
issues to be dealt with in regard to the above to ideas. Does anyone else
have any ideas ? I personally see the Distributed Mud-Driver area as
having a lot of potential infrastructure-wise, but having little benefit to
users unless something is done about the unweildy batch of interfaces which
still involve a lot of typing!
Et
Stormrose the Warder on 3k
George Reese
While I agree that the user interface is the number one priority of what
needs to change, I seriously disagree that distributing a mud would have
any meaningful impact on the quality of a mud or what you can do with
it.
I think it is however a neat technical toy.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
ik ben de borg
Jeff Taylor
If you have only one or two verbs (e.g., kill/shoot, pickup, and use)
graphical interfaces work. When there are many possible actions, they
are unweildy. I've played some computer RPG and they always struck me
as unwieldy: select the object, page thru the menu/screens to the action
menu, optionally select the target, confirm). I find the same is thru
for IDE's and debuggers. I prefer Codeview to Borland's and Watcom's
debuggers. I do use the hotkeys and GUI environment for the things that
are at the top level or two of the menus. Anything below that, I'd
rather type it.
Kairos
Emmanuel Turner
George Reese <bo...@imaginary.com> wrote in article
<335CA6F8...@imaginary.com>...
> While I agree that the user interface is the number one priority of what
> needs to change, I seriously disagree that distributing a mud would have
> any meaningful impact on the quality of a mud or what you can do with
> it.
provide any new possibilities things you can do on a MUD in a direct sense.
BUT, distributing a mud does allow a larger mud, that is more locally
accessible to the client. You can run a larger MUD, simply because you
have a larger amount of computational power available, this extra power may
even be needed to supply the computational overhead that new interfaces
need. Remember I am talking about a possible future of MUDding, not the
present.
Looking at the situations where distributed systems are used sucessfully,
I'd hazard a guess the Mudding would fit into the same category. ie Many
many many users accessing the same service. The users are in many
different locations, at some distance to the service and over low bandwidth
lines.
> I think it is however a neat technical toy.
Yes, there are some *big* technical issues here, but the area does have
enough research to cover most of the technical problems.
I'd be interested in more details for why you feel that mudding is not
suited to a distributed environment.
Et
George Reese
Emmanuel Turner wrote:
> > I think it is however a neat technical toy.
> Yes, there are some *big* technical issues here, but the area does have
> enough research to cover most of the technical problems.
>
> I'd be interested in more details for why you feel that mudding is not
> suited to a distributed environment.
I did not say muds were not suited to distributed environment. I said
that they don't need one and providing one would make no difference.
Perhaps when we have 100,000 concurrent users.
Tim Hollebeek
In article <01bc4edb$c84e72c0$44c731ca@sven>, "Emmanuel Turner" <e...@shadowfax.whanganui.ac.nz> writes:
>
> Et casts a Resurrect on the Future of Mudding Thread.....*Ping* It's alive
> Jim...
>
> Here's a couple of ideas about the future of mudding, or where mudding
> can/might/will improve...
>
> [...]
>
> Distributed Mud-Drivers
> With the internet becoming more and more popular, and with the potentially
> huge numbers of people that could play MUDs in future, and from potentially
> globally diverse places in the world, I think that creating a distributable
> mudlib could help to ease lag problems. Also looking at LPC, the language
> would scale to a distributed model quite well, only the LP Driver would
> need to be changed to be able to support the distribution model.
> Distributing a mud like this can also mean that more CPU intensive stuff
> can be done, simply because the CPU load is shared between physically
> seperate machines.
People have been saying this for years, and it is no more useful today than
it was six years ago when I first saw it suggested. From a practical point
of view, there really is very little, if any, need for it.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
news...@blah.dircon.co.uk
The thing which worries me most is that IRC seems to have a massive
following, whoever heard of an IRC server being short of people. Yet
MU* often seem to starve for users. OK some of this is down to the
specialised nature of some places, not everyone likes the hack'n'slash
stuff. But still, why with the massive expanse of users on the Net
are MUDs not expanding as quick. MUD's have so much less of a profile
than IRC despite the fact that I *personally* think they are
better.....by this I mean u rarely see articles in internet mags etc.
Why is that?
I think it is cos there is an impression that MUDs are just for
teenages who played D&D. I code LPC but I accept that there are as
many sorts of MU* as interests. The other thing is that telnet is
horrid to use and as the Net moves into multi-media the best way of
making them good is to widen the audience. I think this is done by
making them easier to use (easy clients and GUI) and with a more
immersive feeling (Audio, pcitures etc) - afterall Multi-Users
Dimension (or Dungeon) is the name.
I have never heard of there being any development of a GUI interface
in the public domain. I think that Pueblo (www.chaco.com) is the
right way to go and am hoping that our MUD will support it shortly.
OK so it's only available for win95 right now but the protocol is the
important part here - it at least points the way to extending the
content of MUDs. With the protocol others could develop their own
clients etc. I understand that Pueblo can actually get it's
multi-media content from elsewhere than the MUD site so allowing for
bandwidth usage. Pueblo may not be *the* answer but I it's certainly
something to think about.
Bishop
On 22 Apr 1997 05:16:31 GMT, "Emmanuel Turner"
<e...@shadowfax.whanganui.ac.nz> wrote:
<snip>
>
>User Interfaces
>I reckon that the commandline user-interface used by most muds is too
>daunting for a large number of users, but telnet is standard and is freely
>available to almost any client OS.
<snip>
>
>Is there any work being done on creating a graphical mud protocol standard
>so that clients can be written for it? or Do you think that it is better
>to write the clients as downloadable java applets ?
>
>In short, in order to capture a wider audience, mudding will need to have a
>nicer (ie less typing) interface. Even if your mud is based purely on
>text, a couple of short-cut buttons, or having the text arranged into
>windows (eg one for comms, one for location descriptions, one for stats
>etc.) will make your users life easier.
<snip>
Peter Register
In article <336096af...@news.dircon.co.uk>, newst...@blah.dircon.co.uk wrote:
>
>The thing which worries me most is that IRC seems to have a massive
>following, whoever heard of an IRC server being short of people. Yet
>MU* often seem to starve for users. OK some of this is down to the
>specialised nature of some places, not everyone likes the hack'n'slash
>stuff. But still, why with the massive expanse of users on the Net
>are MUDs not expanding as quick. MUD's have so much less of a profile
>than IRC despite the fact that I *personally* think they are
>better.....by this I mean u rarely see articles in internet mags etc.
>Why is that?
The answer to this question, in my opinion, is pornography. While new WWW and
IRC technologies are developed at a staggering rate to cope with the demand
for more pornography on the internet, MUD research in this field is very low.
Only when users are able to freely view and trade pornographic materials
through text or graphical (can you imagine this??) virtual reality systems
will MUD's reclaim their status as "neat thing on the net".
I ask the mud community to come together (ha ha) as a whole to develop a new
protocol which I am tentatively calling MIPP (Mud Internet Pornography
Protocol).
Imagine a mud in which you can reference a file on your pc as a mud object and
//give// that object to another player (transferring it to their pc as in
IRC's /dcc send). Sentients could be created to cull a particular newsgroup
for binaries and sell these objects at a shop. For example, who wouldn't like
seeing Sid's alt.binaries.pictures.erotica.bestiality.hamsters.duct-tape
Art-House right next to Bob's _Torches and Lanterns_???
MUDS focusing on other times, the Dark Ages for example, could sell widely
imaginative Wood Carvings to the players.
If you wish to see these things and more happen YOU need to help develop the
protocol. It is time to see MUDs catch up with the rest of the internet.
-peter
Yes, I'm bored.
Emmanuel Turner
Jeff Taylor <el...@dcn.davis.ca.us> wrote in article
<335D3B...@dcn.davis.ca.us>...
I also think that this is one of the major limitations of a GUI. Current
GUIs tends to make the UI more vertical (that is less horizontal options,
go through more layers (menus etc) to find the command you need) On the
other extreme, the pure text UI is a very horizontal, all commands
available with little vertical-ness. I also can remember games that had a
graphical display, but the commands were all typed, not pretty :-)
The other problem with current GUI's is that they don't have a very easy
way to select arguments to a command. You end up either clicking on a
object, or scrolling through pages and pages of inventory/character sheets.
On the other hand, the text UIs are too verbose, too much typing, far too
much typing. In fact most mudders I know slowly build up a library of
triggers ( sin :-) ) and aliases to reduce much of the hassle. I think
that perhaps GUIs would benefit from an alias type system too, where users
had a lot more control over configuring their interface.
I wonder too if something similiar to (I thinks it's Huffman) encoding
would help reduce the depth of menus/contexts in a GUI, by migrating the
more commonly used commands up the menu/context tree. Could be done by
starting all comands an equal depth down the menu-tree, then migrating them
upwards in the menu tree, leaving an aliases at lower levels for historical
reasons. This fine-tuning could happen over time, and would eventually
result in very quick access to the most commonly used commands.
Speaking of contexts, a MUD could alter the UI to show the options that are
available at this time, that the MUD thinks that the user may want to do.
Kinda like how Red Alert and C&C add the currently available building
options to that menu on the right. Fine tuning this by looking at the user
has done historically in similar cirumstances will make the interface even
more accessible.
I do think that GUI will be the way to go, once ways are found to make the
GUI more expressive, simply because a GUI is easier to learn. But, lets
face it, click, drag-and-drop, dbl-click and rollover, even with a second
button involved is not that expressive, thats only 12 actions (left, right,
both doing the above) combined with a little extra spatial information.
Remembering also that changing the spatial state of a mouse takes more time
then a reasonably competant hunt-n-pecker can type. Compare that to about
80 symbols that can be rapidly combined in many different ways and text
wins in the expressiveness stakes.
Having said that, I currently think that one of the best ways to GUI-ise a
MUD is for each MUD to provide its own down-loadable java applet, which is
the UI. This would virtually eliminate the hassles of having to come up
with a graphical mud standard, though a de facto 'base' will probably
emerge to cover the 'grunt' code. There's nothing stopping having a hybrid
interface either, one that combines the best of text and the best of GUI,
even in the short term. zMud offers some of this functionally itself, but
at the moment it is at best lumpy until the MUD itself supports it. Maybe
it could be done as an alternative terminal type and kept running alongside
the traditional text only mud.
I wonder what you peoples reckon could be done to improve MUD UI's ?
Et
Emmanuel Turner
>
> Emmanuel Turner wrote:
> > > I think it is however a neat technical toy.
> > Yes, there are some *big* technical issues here, but the area does have
> > enough research to cover most of the technical problems.
> > I'd be interested in more details for why you feel that mudding is not
> > suited to a distributed environment.
> I did not say muds were not suited to distributed environment. I said
> that they don't need one and providing one would make no difference.
>
> Perhaps when we have 100,000 concurrent users.
Perhaps that's what we should be aiming for :-)
Seriously, the on-line game is becoming very very popular, look at the
sucess of Quake & Diablo to name a few. (You could say that these games
are MUD's with very attractive front ends and very little depth) You log
onto battle.net and see how many players they have online. A little more
(IMHO: much needed) work on the user interface and MUDding could go
mainstream.
Et
Abigail
On 24 Apr 1997 18:59:43 GMT, Tim Hollebeek wrote in rec.games.mud.lp
<URL: news:5joaiv$gmc$4...@cnn.Princeton.EDU>:
++
[ Distributed muds ]
++
++ People have been saying this for years, and it is no more useful today than
++ it was six years ago when I first saw it suggested. From a practical point
++ of view, there really is very little, if any, need for it.
I fully agree with that, and I believe making distributed muds is an
order of a magnitude harder than making threaded muds.
Abigail
Abigail
On 26 Apr 1997 01:32:40 GMT, Emmanuel Turner wrote in rec.games.mud.lp
<URL: news:01bc51e1$2a26f960$44c731ca@sven>:
++ George Reese <bo...@imaginary.com> wrote in article
++ <335DFA3F...@imaginary.com>...
++ >
++ > Emmanuel Turner wrote:
++ > > > I think it is however a neat technical toy.
++ > > Yes, there are some *big* technical issues here, but the area does have
++ > > enough research to cover most of the technical problems.
++ > > I'd be interested in more details for why you feel that mudding is not
++ > > suited to a distributed environment.
++ > I did not say muds were not suited to distributed environment. I said
++ > that they don't need one and providing one would make no difference.
++ >
++ > Perhaps when we have 100,000 concurrent users.
++
++ Perhaps that's what we should be aiming for :-)
++ Seriously, the on-line game is becoming very very popular, look at the
++ sucess of Quake & Diablo to name a few. (You could say that these games
++ are MUD's with very attractive front ends and very little depth) You log
++ onto battle.net and see how many players they have online. A little more
++ (IMHO: much needed) work on the user interface and MUDding could go
++ mainstream.
Well, maybe if you want to dumb down muds. As you said quake etc have
very attractive front ends and very little depth. The latter part is
very important in making those games popular. It's so easy, no myriad
of commands, quests, long battles, spells, different types of armour
etc. I think MUDs get a different kind of public, people who prefer
depth.
I don't think MUDs need to compete with quake et al. MUDs have
their own public.
Abigail
Emmanuel Turner
Abigail <abi...@fnx.com> wrote in article <E98o6...@nonexistent.com>...
I would agree that creating a threaded mud driver would have to come first.
Perhaps little work is being done in creating a MT muddriver because the
current single threaded driver is completely fine (fast enough) for what it
is currently being asked to do. Maybe when MUDs have to do a little more
work to support a different style UI then maybe we'll need it.
Et
Emmanuel Turner
We all appreciate the fine work being done on advanced parsers, he's just a
couple of other ideas I thought I'd throw out there.
Command completion.
Type in ex, press <TAB> (or something) and the computer chooses examine for
you.
In the case of ambiguities, (not enough letters to uniquely identify this
word) just display the list of words. eg.
Type in f, press <TAB> MUD responds with fight, finger, fireball, flee, fly
etc. Type in ig, press <TAB> and computer responds with fight .
Synonyms, Reducing the number of command words and making Command words
consistant across the MUD.
It is very surprising how many areas I see that require such exacting
syntax. Go to one part of the MUD and you have to MOVE the switch, go to
anyother part of the MUD and its PULL/PUSH the switch, TURN ON/TURN OFF
switch, TOGGLE switch etc. I would be good to see these words being
standardised and a MUDwide standard being made.
Just ideas..
ne...@ogham.demon.co.uk
"Emmanuel Turner" <e...@shadowfax.whanganui.ac.nz> wrote:
>Having said that, I currently think that one of the best ways to GUI-ise a
>MUD is for each MUD to provide its own down-loadable java applet, which is
>the UI. This would virtually eliminate the hassles of having to come up
>with a graphical mud standard, though a de facto 'base' will probably
>emerge to cover the 'grunt' code. There's nothing stopping having a hybrid
>interface either, one that combines the best of text and the best of GUI,
I don't know if anyone has come up with this idea before but perhaps you
could have a standard text based mud which has the option of a downloadable
applet interface. All this applet would do would sit between you and the muds
text interface (ie it would telnet to the mud and pretend to be a user) and
convert your graphics commands to text commands whilst getting back the text
info from the mud which it would display as normal. This method would avoiding
having muds where you have to have either the server supporting 2 methods of
data entry (text and some sort of applet protocol) or the user having to
download an applet before they can play on an applet only supporting mud.
Just a thought.
NJR
Michael W. Ryan
"Emmanuel Turner" <e...@shadowfax.whanganui.ac.nz> wrote:
[snipped for bandwidth]
> Synonyms, Reducing the number of command words and making Command words
> consistant across the MUD.
> It is very surprising how many areas I see that require such exacting
> syntax. Go to one part of the MUD and you have to MOVE the switch, go to
> anyother part of the MUD and its PULL/PUSH the switch, TURN ON/TURN OFF
> switch, TOGGLE switch etc. I would be good to see these words being
> standardised and a MUDwide standard being made.
This issue is what the MudOS verb parsing system is supposed to
handle. By having all verbs and commands defined centrally (i.e. not
through add_action), you can cut down on the redundancy and confusion
of multiple verbs for similar actions.
----------
Michael W. Ryan
Email: mr...@netaxs.com
WWW: http://www.netaxs.com/~mryan/
Supporter of Python and Python Software Activity
http://www.python.org/
George Reese
Matthew Julius wrote:
>
> Michael W. Ryan wrote:
> >
> > "Emmanuel Turner" <e...@shadowfax.whanganui.ac.nz> wrote:
> >
> > [snipped for bandwidth]
> > > Synonyms, Reducing the number of command words and making Command words
> > > consistant across the MUD.
> > > It is very surprising how many areas I see that require such exacting
> > > syntax. Go to one part of the MUD and you have to MOVE the switch, go to
> > > anyother part of the MUD and its PULL/PUSH the switch, TURN ON/TURN OFF
> > > switch, TOGGLE switch etc. I would be good to see these words being
> > > standardised and a MUDwide standard being made.
> >
> > This issue is what the MudOS verb parsing system is supposed to
> > handle. By having all verbs and commands defined centrally (i.e. not
> > through add_action), you can cut down on the redundancy and confusion
> > of multiple verbs for similar actions.
>
> I mean, duh ?
> This kind of problem is due more to poor administration/approval
> and building than it is to what driver you're using. Personally,
> I don't think MudOS even solves this problem.
>
> As I said, the problem resides in the administration, approvers and
> builders. If the builder has an object which uses push and another
> has one which has move, it's up to approval to make them consistent.
> Ultimately, both should work (and any other possible actions). This
> is just as likely to happen using MudOS than any other driver. As
> I said, it's up to the approvers to pick out these variations or
> inconsistencies.
Actually, that is not true at all. Move and push ina MudOS system are
synonyms, so both work everywhere. It is not up to the builder to
decide this issue.
> If a builder hasn't accounted for a verb in an object using MudOS,
> instead of seeing the usual What ?, you see a You can't blah with
> the blah. Course, if you didn't use add_action() to begin with
> (which I think is obvious that you should not use add_action()),
> you'd get a sensible error message with or without MudOS's parser.
> If the verb doesn't exist, it doesn't exist. With the parser or
> without the parser.
Knowing that the verb does not exist is more important than every
possible verb existing. The issue is that I want to move a rock. I try
'move rock'. Well, if 'move' is not a verb, then you try 'push', etc.
Eventually you will find the right verb. And you know that verb will
work for the desired actiuon *anywhere on the mud*. Not 'move' in one
place and 'push' in another.
> It's up to the administrators to provide an environment that can
> handle all those various verbs.
> It's up to the builders to understand this environment.
> And it's up to the approvers to keep everything consistent and
> playable.
This is true no matter what tools you are using.
Matthew Julius
If a builder hasn't accounted for a verb in an object using MudOS,
instead of seeing the usual What ?, you see a You can't blah with
the blah. Course, if you didn't use add_action() to begin with
(which I think is obvious that you should not use add_action()),
you'd get a sensible error message with or without MudOS's parser.
If the verb doesn't exist, it doesn't exist. With the parser or
without the parser.
It's up to the administrators to provide an environment that can
handle all those various verbs.
It's up to the builders to understand this environment.
And it's up to the approvers to keep everything consistent and
playable.
--
Matthew Julius o_o
( _ )
s01...@discgate.wright.edu ( | | )
Matthew Julius
George Reese wrote:
> Actually, that is not true at all. Move and push ina MudOS system are
> synonyms, so both work everywhere. It is not up to the builder to
> decide this issue.
I assume then they're magically the same. I don't care if they're
equal or not. The point is, somewhere, sometime, these rules have
to be generated. Giving a case where two words are synonyms is
like saying your mud handles 'l' and 'look' the same. Alright,
think of an example when the two words don't behave the same, maybe
twist and move, whatever floats your boat. Whatever the application.
> > If a builder hasn't accounted for a verb in an object using MudOS,
> > instead of seeing the usual What ?, you see a You can't blah with
> > the blah. Course, if you didn't use add_action() to begin with
> > (which I think is obvious that you should not use add_action()),
> > you'd get a sensible error message with or without MudOS's parser.
> > If the verb doesn't exist, it doesn't exist. With the parser or
> > without the parser.
>
> Knowing that the verb does not exist is more important than every
> possible verb existing. The issue is that I want to move a rock. I try
> 'move rock'. Well, if 'move' is not a verb, then you try 'push', etc.
> Eventually you will find the right verb. And you know that verb will
> work for the desired actiuon *anywhere on the mud*. Not 'move' in one
> place and 'push' in another.
This is a little redundant isn't it ?
Isn't it a little obvious that you have some help file or something
saying which actions can be performed on the game ? My point was that
the builder still has to specify what happens when an action is done.
If someone thinkd they're supposed to be able to move something, and the
builder hasn't provided any code to say what happens, a person is just
gonna see either "Nothing happens when you move the ball" or "You
cannot move the ball here." Some sensible error message. It appears
to me that you think some hidden tunnel will appear with no work
by the builder whenever somebody, for example, moves a statue.
All I'm saying is that MudOS parser or no, the builder has to account
for the actions that can be performed on an object. Whoopy-do if
an example was given where the two words are treated the same.
The point is that commands, instead of specifically being given
through add_action(), become global to the mud. And this can be
done on any mud, but the administrators, approvers, and builders
all have to understand how it works.
> > It's up to the administrators to provide an environment that can
> > handle all those various verbs.
> > It's up to the builders to understand this environment.
> > And it's up to the approvers to keep everything consistent and
> > playable.
>
> This is true no matter what tools you are using.
My point exactly.
Emmanuel Turner
ne...@ogham.demon.co.uk wrote in article <86214172...@ogham.demon.co.uk
>...
And a good thought too, I thought of doing this too, but only as an
interim. It was actually this thought which prompted me to start thinking
more of the whole interface thingy. In order to support a decent GUI
interface (so far I'm leaning towards a self-tuning GUI) the MUD will need
to drive the interface, meaning it will be will need to be a different
protocol. The MUD needs to drive the interface because providing the
intelligence needed for a learning interface in an applet would not be
practical.
Et
The Mystic
Matthew Julius (s01...@discgate.wright.edu) uttered:
: George Reese wrote:
: > Actually, that is not true at all. Move and push ina MudOS system are
: > synonyms, so both work everywhere. It is not up to the builder to
: > decide this issue.
: I assume then they're magically the same. I don't care if they're
: equal or not. The point is, somewhere, sometime, these rules have
: to be generated. Giving a case where two words are synonyms is
: like saying your mud handles 'l' and 'look' the same. Alright,
: think of an example when the two words don't behave the same, maybe
: twist and move, whatever floats your boat. Whatever the application.
the 'twist' and 'move' commands would be treated the same where it was
seen as appropriate, just like 'push' and 'press' are treated the same on
in the Nightmare system (and many others), but done so at the system
level. that goes back to the admin and approval people doing their jobs.
: > Knowing that the verb does not exist is more important than every
: > possible verb existing. The issue is that I want to move a rock. I try
: > 'move rock'. Well, if 'move' is not a verb, then you try 'push', etc.
: > Eventually you will find the right verb. And you know that verb will
: > work for the desired actiuon *anywhere on the mud*. Not 'move' in one
: > place and 'push' in another.
: This is a little redundant isn't it ?
: Isn't it a little obvious that you have some help file or something
: saying which actions can be performed on the game ?
yes, the help file is a rather good idea indeed.
but..
with most systems i've seen, if you type an unsupported command, you get a
"What?" flashed on your screen. and, if you type a supported command, yet
use it wrongly, you also get a "What?" flashed across your screen.
requiring the user to look to the helpfile when they happen to type the
wrong command is silly. whatever method you use, you should tell the user
that the particular command is not supported. if they use the command
incorrectly but it is supported, you should say that as well. the MudOS
parsing system makes that easy too.
: My point was that
: the builder still has to specify what happens when an action is done.
: If someone thinkd they're supposed to be able to move something, and the
: builder hasn't provided any code to say what happens, a person is just
: gonna see either "Nothing happens when you move the ball" or "You
: cannot move the ball here." Some sensible error message. It appears
: to me that you think some hidden tunnel will appear with no work
: by the builder whenever somebody, for example, moves a statue.
: All I'm saying is that MudOS parser or no, the builder has to account
: for the actions that can be performed on an object. Whoopy-do if
: an example was given where the two words are treated the same.
i believe the example he pointed out, was related to using add_action as
opposed to not using it. normally, when using MudOS, one uses the
add_action method or the parser method. seldom is neither used, because
people either dont have the time to write a custom method, or find one or
the other of the pre-existing methods satisfactory.
when using add_action, its a headache at best trying to keep all the
actions consistent across the mud. you may have to press the button in
one location, yet push it in another.
: The point is that commands, instead of specifically being given
: through add_action(), become global to the mud. And this can be
: done on any mud, but the administrators, approvers, and builders
: all have to understand how it works.
disable add_action altogether.
then the builders are forced to learn how to support the system commands.
whether those commands use the MudOS parsing system or not should be
hiidden from the builder, in the event the implementation is to change.
its also simply good programming practice, and allows the builders to be
more creative than trying to learn to reinvent the wheel whenever they
want to add support.
: > > It's up to the administrators to provide an environment that can
: > > handle all those various verbs.
: > > It's up to the builders to understand this environment.
: > > And it's up to the approvers to keep everything consistent and
: > > playable.
: >
: > This is true no matter what tools you are using.
: My point exactly.
the tool in question, in this case, is the MudOS parser.
you are arguing that it doesnt do its job.
it does its job quite well, in fact. it provides, without the need to
create it yourself, the administrators with a method of translating what
the user types, into iinformation meaningful to the mud. and it allows
flexibility to added by simply creating a new rule, and a few functions to
handle that rule.
the MudOS parsing system makes it easier to be user-friendly, and still be
consistent across the mud. you dont have to use it. it is merely a
helpful tool. you are completely free to write your own method.
but it does what it was designed to do, and fairly well.
The Mystic
rlo...@franck.princeton.edu.composers
In article <E98o6...@nonexistent.com>, abi...@fnx.com writes:
> On 24 Apr 1997 18:59:43 GMT, Tim Hollebeek wrote in rec.games.mud.lp
> <URL: news:5joaiv$gmc$4...@cnn.Princeton.EDU>:
> ++
> [ Distributed muds ]
> ++
> ++ People have been saying this for years, and it is no more useful today than
> ++ it was six years ago when I first saw it suggested. From a practical point
> ++ of view, there really is very little, if any, need for it.
>
>
> I fully agree with that, and I believe making distributed muds is an
> order of a magnitude harder than making threaded muds.
*gasp* I can die happy now. Abigail agreed with me about something :-)
Chris Lawrence (Contra)
Abigail (abi...@fnx.com) wrote:
: On 24 Apr 1997 18:59:43 GMT, Tim Hollebeek wrote in rec.games.mud.lp
: <URL: news:5joaiv$gmc$4...@cnn.Princeton.EDU>:
: ++
: [ Distributed muds ]
: ++
: ++ People have been saying this for years, and it is no more useful
: ++ today than it was six years ago when I first saw it suggested.
: ++ From a practical point of view, there really is very little, if
: ++ any, need for it.
: I fully agree with that, and I believe making distributed muds is an
: order of a magnitude harder than making threaded muds.
I'd note that if you moved your server to a pure DB model vs keeping
your process/MUD state in memory, then a lot of the work of moving to
a distributed server can be done for you. Move the DB side to a
distributed DB which supports distributed nested transactions
and much of the rest falls out.
This is not to say that a distributed DB server with nested transaction
support is a trivial proposition. Its not. There are however examples
in the area to start from (cf tdbm).
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Abigail
On 29 Apr 1997 18:50:47 GMT, Chris Lawrence (Contra) wrote in
rec.games.mud.lp URL: news:5k5fu7$c8p$1...@hpax.cup.hp.com:
++
++ Abigail (abi...@fnx.com) wrote:
++
++ : I fully agree with that, and I believe making distributed muds is an
++ : order of a magnitude harder than making threaded muds.
++
++ I'd note that if you moved your server to a pure DB model vs keeping
++ your process/MUD state in memory, then a lot of the work of moving to
++ a distributed server can be done for you. Move the DB side to a
++ distributed DB which supports distributed nested transactions
++ and much of the rest falls out.
Surely you are not claiming a DB model is a fast one? A DB has one
primary concern: don't lose transactions, and always return to a
consistant state. Everything else will be sacrificed for it.
I've seen processed blocked for hours just because some other process
kept needed a table.
++ This is not to say that a distributed DB server with nested transaction
++ support is a trivial proposition. Its not. There are however examples
++ in the area to start from (cf tdbm).
I hardly doubt you will have gained anything.
Abigail
George Reese
Chris Lawrence (Contra) wrote:
>
> Abigail (abi...@fnx.com) wrote:
> : On 29 Apr 1997 18:50:47 GMT, Chris Lawrence (Contra) wrote in
> : rec.games.mud.lp URL: news:5k5fu7$c8p$1...@hpax.cup.hp.com:
>
> : ++ : I fully agree with that, and I believe making distributed muds is an
> : ++ : order of a magnitude harder than making threaded muds.
> : ++
> : ++ I'd note that if you moved your server to a pure DB model vs keeping
> : ++ your process/MUD state in memory, then a lot of the work of moving to
> : ++ a distributed server can be done for you. Move the DB side to a
> : ++ distributed DB which supports distributed nested transactions
> : ++ and much of the rest falls out.
>
> : Surely you are not claiming a DB model is a fast one?
>
> No, but a DB model *CAN* be a fast one. There is a difference. You
> don't need a full SQL server for a MUD (tho I've had thoughts about
> mSQL). A simple ISAM base will do quite nicely. cf ColdX, Cool,
> Interlude, and all the various other disk based servers (usually
> using a dbm variant). Tools like Yooda, tdbm, etc with a decent
> cacheing layer start looking very attractive here. Just the
> lightweight basics are all that's needed for a MUD server.
mSQL gets you nothing in the mud world because of its lack of
transaction management capabilities. If you are going to use a
relational database in the mud world, it would ostensibly be to provide
you with some hot querying capabilities. To do this, you need a proper
data model. A mud has a sufficiently complex data model to require
transaction management anywhere beyond the first normal form.
It is also important to note that an LPMud at heart is really a poor
man's object database anyways as it stands. If you want to add a
database backend for persistence, you would hope to gain something out
of it. The current LPMud persistence mechanism sucks big time.
Anything would be better, but I do not think going to dbm or a
relational model would *necessarily* be the right move.
Abigail
On 28 Apr 1997 21:41:59 GMT, rlo...@franck.Princeton.EDU.composers wrote
in rec.games.mud.lp URL: news:5k35j7$8aj$1...@cnn.Princeton.EDU:
++
++ *gasp* I can die happy now. Abigail agreed with me about something :-)
++
I'll put that in my cookies file.
Abigail
Chris Lawrence (Contra)
Abigail (abi...@fnx.com) wrote:
: On 29 Apr 1997 18:50:47 GMT, Chris Lawrence (Contra) wrote in
: rec.games.mud.lp URL: news:5k5fu7$c8p$1...@hpax.cup.hp.com:
: ++ : I fully agree with that, and I believe making distributed muds is an
: ++ : order of a magnitude harder than making threaded muds.
: ++
: ++ I'd note that if you moved your server to a pure DB model vs keeping
: ++ your process/MUD state in memory, then a lot of the work of moving to
: ++ a distributed server can be done for you. Move the DB side to a
: ++ distributed DB which supports distributed nested transactions
: ++ and much of the rest falls out.
: Surely you are not claiming a DB model is a fast one?
No, but a DB model *CAN* be a fast one. There is a difference. You
don't need a full SQL server for a MUD (tho I've had thoughts about
mSQL). A simple ISAM base will do quite nicely. cf ColdX, Cool,
Interlude, and all the various other disk based servers (usually
using a dbm variant). Tools like Yooda, tdbm, etc with a decent
cacheing layer start looking very attractive here. Just the
lightweight basics are all that's needed for a MUD server.
Note: "DB" is a generic term for a type of application or storage
method, not a label for a class of products.
: A DB has one
: primary concern: don't lose transactions, and always return to a
: consistant state. Everything else will be sacrificed for it.
:
: I've seen processed blocked for hours just because some other process
: kept needed a table.
Now just where did I say that anything of this caliber is needed?
There is no design requirement for even a transactional DB to follow
such an aggressive model (cf tdbm) -- which gives the wonderful
opportunity for the server programmer to use something a lot more
suitable (perish the thought)
: ++ This is not to say that a distributed DB server with nested transaction
: ++ support is a trivial proposition. Its not. There are however examples
: ++ in the area to start from (cf tdbm).
: I hardly doubt you will have gained anything.
I'm glad your doubts are so small.
George Reese
Emmanuel Turner wrote:
> >It is also important to note that an LPMud at heart is really a poor
> >man's object database anyways as it stands. If you want to add a
> >database backend for persistence, you would hope to gain something out
> >of it. The current LPMud persistence mechanism sucks big time.
> >Anything would be better, but I do not think going to dbm or a
> >relational model would *necessarily* be the right move.
> DB?
Two answers:
#1 I am.
#2 There is no reason to.
I am doing that only out of a personal interest in distributed
computing. I do not think you gain a lot in a mud by doing this.
Emmanuel Turner
George Reese wrote in article <3367C890...@imaginary.com>...
>mSQL gets you nothing in the mud world because of its lack of
>transaction management capabilities. If you are going to use a
>relational database in the mud world, it would ostensibly be to provide
>you with some hot querying capabilities. To do this, you need a proper
>data model. A mud has a sufficiently complex data model to require
>transaction management anywhere beyond the first normal form.
I don't think that a relational model would be an ideal "fit" for the mud
world, because most data accesses to a MUD only involve a single instance
of an object. Relational databases have a large overhead for returning a
single record, but the second and rest of the records follow suit pretty
quickly.
Emmanuel Turner
Abigail wrote in article ...
>Surely you are not claiming a DB model is a fast one? A DB has one
>primary concern: don't lose transactions, and always return to a
>consistant state. Everything else will be sacrificed for it.
>I've seen processed blocked for hours just because some other process
>kept needed a table.
A DB, even a relational one, doesn't necessarily need to have such a savage
priority given to transactions and preserving consistancy. Many optimistic
locking techniques get around the locking problem. Look at Interbase, it
uses no locks!
Et
Jon A. Lambert
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote in article <5k8br9$3pp$3...@hpax.cup.hp.com>...
>
> Abigail (abi...@fnx.com) wrote:
> : On 29 Apr 1997 18:50:47 GMT, Chris Lawrence (Contra) wrote in
> : rec.games.mud.lp URL: news:5k5fu7$c8p$1...@hpax.cup.hp.com:
>
> : ++ : I fully agree with that, and I believe making distributed muds is an
> : ++ : order of a magnitude harder than making threaded muds.
> : ++
> : ++ I'd note that if you moved your server to a pure DB model vs keeping
> : ++ your process/MUD state in memory, then a lot of the work of moving to
> : ++ a distributed server can be done for you. Move the DB side to a
> : ++ distributed DB which supports distributed nested transactions
> : ++ and much of the rest falls out.
I prefer to view persistent objects as managed by a storage subsystem. The
storage subsystem may be running as a separate process or , in my case,
within the currently running process as its own task. The storage subsystem
has three layers (access/translation/database). Access is provided within
the normal framework of OOP. Ctors, dtors, associations, inheritance, etc. make
requests to the storage subsystem . The storage subsystem maintains an
configurable object cache based on reference counting. As far as the application
is concerned all objects are in memory. All disk activity in backing the cache is
asynchronous. In my model this disk activity involves translation of the object
model to a relational one. I currently use a commercial SQL-based RDMS that
has a very small footprint. I'm not really satisfied with this, but it does provide
some flexibility at this layer (It is ODBC compliant). Even my small RDBMS has
a great deal of unnecessary functionality (full SQL, its own caching).
Translation from object to relational model, while at first glance appearing to
have much in common, have many subtle differences which add overhead.
The storage subsystem does provide for a primitive locking mechanism.
I have yet to get the logging for recovery aspect down. The hope is that, if I
simply unplug the server the database will recover and/or rollback to an acceptable
state upon reboot. I plan on keeping my database layer as an RDBMS for now
simply because I can easily update and configure it with a number of external
tools. Later on if speed becomes an imperative issue or I find something really
excellent in the OODBMS world, it will likely move. Ideally this will entail only
modifying the translation layer of the storage subsystem.
JL
Chris Lawrence (Contra)
George Reese (bo...@imaginary.com) wrote:
: Chris Lawrence (Contra) wrote:
: > No, but a DB model *CAN* be a fast one. There is a difference. You
: > don't need a full SQL server for a MUD (tho I've had thoughts about
: > mSQL). A simple ISAM base will do quite nicely. cf ColdX, Cool,
: > Interlude, and all the various other disk based servers (usually
: > using a dbm variant). Tools like Yooda, tdbm, etc with a decent
: > cacheing layer start looking very attractive here. Just the
: > lightweight basics are all that's needed for a MUD server.
: mSQL gets you nothing in the mud world because of its lack of
: transaction management capabilities.
Precisely. My interest is solely for queries rather than management.
: If you are going to use a
: relational database in the mud world, it would ostensibly be to provide
: you with some hot querying capabilities. To do this, you need a proper
: data model. A mud has a sufficiently complex data model to require
: transaction management anywhere beyond the first normal form.
This is partially arguable. MOO for example is in the first normal form
with records == objects and the single key of a Record# == ObjectID,
and it wouldn't be incredibly difficult to roll transactions under MOO.
: It is also important to note that an LPMud at heart is really a poor
: man's object database anyways as it stands. If you want to add a
: database backend for persistence, you would hope to gain something out
: of it. The current LPMud persistence mechanism sucks big time.
: Anything would be better, but I do not think going to dbm or a
: relational model would *necessarily* be the right move.
I have little to no LP experience and can't comment well on LP other than
to agree abstractly with the object DB comment. Using standardised DB
approaches for persistance offers standardised and very well known
simplifications. Those can be some pretty weighty pro's -- you're not
breaking new ground anywhere. Moving to a proper persistant object store
ala Texas or ObjectStore offers the flexibility and immediate translation
of the current model, but does little to represent the complexities added
by persistance.
George Reese
Emmanuel Turner wrote:
>
> George Reese wrote in article <33681E17...@imaginary.com>...
> >#1 I am.
> I've just gone on a brush up tour of imaginary.com and have seen the work
> you are doing in Java. I'm impressed :-)
FYI: Those docs are about a year old :) I am significantly further
along with JavaMud now :)
Emmanuel Turner
>> >It is also important to note that an LPMud at heart is really a poor
>> >man's object database anyways as it stands. If you want to add a
>> >database backend for persistence, you would hope to gain something out
>> >of it. The current LPMud persistence mechanism sucks big time.
>> >Anything would be better, but I do not think going to dbm or a
>> >relational model would *necessarily* be the right move.
>> DB?
>#1 I am.
I've just gone on a brush up tour of imaginary.com and have seen the work
you are doing in Java. I'm impressed :-)
>#2 There is no reason to.
>I am doing that only out of a personal interest in distributed
>computing. I do not think you gain a lot in a mud by doing this.
I think that at the moment you will not gain anything, but as muds get
bigger and more users logon, you'll start to notice the benefits. Still,
your comment and mine are starting to sound like deja vu so I stop here.
Peace Favour your typing fingers :-)
Et
Emmanuel Turner
Jon A. Lambert wrote in article <01bc55ec$ab98ec60$503b...@jlsysinc.ix.net
com.com>...
There are some potential problems if you are using a certain relational
table to represent all object instances of a certain class. Perhaps the
biggest is preserving the inheritance heirarchy. Gets even trickier when
using the multiple inheritance.
Another potential problem is that SQL database are generally optimised for
returning large lists of records because many relational database use B+
Indices. An object store generally only retrieves a single object at a
time, making hashing indices probably better performance-wise. Your
caching would help to hide some of this performance hit though.
Et
Jon A. Lambert
Emmanuel Turner <e...@shadowfax.whanganui.ac.nz> wrote in article <5kgtr9$a...@nethost.whanganui.ac.nz>...
>
> There are some potential problems if you are using a certain relational
> table to represent all object instances of a certain class. Perhaps the
> biggest is preserving the inheritance heirarchy. Gets even trickier when
> using the multiple inheritance.
Definately. I must admit that my interest in this is largely professional.
More of my clients are recognizing, even demanding, an OO approach
to design and programming. However relational is still the standard
when it comes down to implementation. :-(
Rather than go into the details, here are a few links that point out
some of the major headaches, for those who are interested.
<http://www.ksccary.com/ordbjrnl.htm>
<http://www.rwi.com/smalltalk/topics/articles/object_to_relational.html>
JL