What is the Mud State of the Art?
leg...@dbtech.net
decided to see if anyone would nibble on this one. Consider this a nice
long thought-experiment.
Basic assumptions: (which I hope someone will challenge :) else no fun)
- The building of virtual spaces can be regarded as an art form that
involves some engineering (as do many arts)
- Game design can be regarded as an art form
- There is a well-established custom of critique within both of the above
disciplines
- Those who value the art form desire to see it improve as a whole
- Without an awareness of the state of the art, there is no basis for
critique and thus for general improvement
Given the above for the sake of the argument, what do you see as the state
of the art among muds, mushes, moos, mucks, etc etc etc? Granted that
these have differing design needs and so on?
Examples of stuff I have seen advanced as state of the art in the last
month on these newsgroups: (I advance these in all seriousness as things I
have seen, NOT saying that any of these are state of the art)
- mobs that can walk from one room to another at specific times
- mobs that remember attackers
- text triggers
- careful competent writing
- randomly generated areas
- ANSI color codes embedded in customizable output
- ability to connect to the site from multiple servers
- more classes
- more races
- more areas
- formations as an extension to grouping
- vehicles
- missile weapons
The question: what do you regard as state of the art? If you know
specifics, can you name the mud that implemented it and why it is more
advanced or innovative than what others do?
Looking forward to angry, amused, bemused, or thoughtful answers, be they
Joel or Amberyl camp *grin*.
-Ptah@LegendMUD
--
Lege...@bashful.cc.utexas.edu 9999 * "History the way it should have been." Classless * Word-based magic * Technology * Guns * Medical skills * Herbalism * variable rate fights * OOC Lounge * Dozens of automated quests * Bardic skills * 150+ spells * 75+ skills * Researched all original areas like Beowulf, Arabian Nights, Viking Scandinavia, Victorian London, French-Indian War * customizable color * free and open debate on email discussion group * the Legendary Times newsletter * optional pkill * mature atmosphere * three eras * "If you're only visiting one mud, make it Legend" - The Electronic Newsstand * MudGate Pick of the Week for Six Months, do they ever update it?
Michael Sellers
make another stab at replying to this post. This is not easy to do, as
MUD development appears to be so fractured that there is no one "state of
the art" nor even *one* "art" that serves all players. Some muds appear
nearly artless in design, some far too contrived for my tastes, and nearly
all spend too little time relfecting on their construction, design, and
goals to qualify as an artistic (rather than simply a chaotically
creative) pursuit.
That said, here are a few thoughts on the advancing development of MUDs:
leg...@dbtech.net wrote:
: Basic assumptions: (which I hope someone will challenge :) else no fun)
: - The building of virtual spaces can be regarded as an art form that
: involves some engineering (as do many arts)
: - Game design can be regarded as an art form
: - There is a well-established custom of critique within both of the above
: disciplines
I'll challenge that one easily: there is no established and well-formed
method of substantive critique. The custom is well-established, but
consists mainly of shouts like "<your game> sucks rocks." Not quite what
I call critique.
: - Those who value the art form desire to see it improve as a whole
: - Without an awareness of the state of the art, there is no basis for
: critique and thus for general improvement
While I agree with this in general, I think we are seeing some
incremental improvement due to the efforts of various individuals
following their own vision rather than responding to the criticism of
others. I expect this will continue for at least a year or two, until
MUD commericalization is complete (though free MUDs will still be around).
On that note, here's my prediction for the general future of Muds:
Text MUDs will see increased commercialization in the near future, like
it or not (Interactive Age, July 3, 1995, page 1: under "Scribble sneak
peek" it says "Microsoft [is working with] Simon & Schuster Inc. and another
unnamed publisher to craft text-based virtual worlds that are slated to
launch on the Microsoft Network later this summer...") and graphical muds
will quickly follow. This will change our little cottage non-industry
completely over the next 24 months; what has been a nice little InterNet
tide pool is going to hit the Big Time... and I don't think we're all
(players and designers alike) ready.
: Given the above for the sake of the argument, what do you see as the state
: of the art among muds, mushes, moos, mucks, etc etc etc? Granted that
: these have differing design needs and so on?
Let me throw the graphics question out on the floor right off. Is
graphics (first-person, third person, whatever) requisite for being
bleeding-edge? I'm beginning to think so. Will this add to gameplay?
Probably, though in unexpected ways -- and a poor mud with graphics is
still a poor mud (a reality I expect to see missed by some of the larger
players entering this area).
Other than that, some of my SoA benchmarks include:
- improved AI for monsters, whether basic state-driven or more advanced
NN-driven actions.
- "ecological" communities, even if modeled abstractly, but including
producers, consumers, and decomposers of various resources. Among
other things, this helps, IMO, get beyond the technological
constraints that require "resets" and loss of equipment on many muds.
Others will argue that this is part of their atmosphere, but it still
emerges from a technological rather than game-balance constraint.
- Player-driven organizations and in-game social units, such as shops,
guilds, castles, etc.
- Detailed skill, magic, and combat systems, including group and ranged
combat
- No classes
- I'm undecided about races, unless real and significant abilites differ
between races
- Real and changing world politics and events; wars, famines, etc
- No player politics; no "immorts are better than morts" creeping in
Unfortunately, I see few muds that have done much to implement any of these.
Other opinions?
--
Michael Sellers Terra Nova Interactive Corp. mi...@terranova.com
(503) 538-2745 FAX (503) 538-9517 http://www.terranova.com/~sellers
Email me for info on UI Design seminars: 2-5 days, in-house or public
Ian Macintosh SLIP
: Examples of stuff I have seen advanced as state of the art in the last
: month on these newsgroups: (I advance these in all seriousness as things I
: have seen, NOT saying that any of these are state of the art)
:
: - mobs that can walk from one room to another at specific times
: - mobs that remember attackers
: - text triggers
: - careful competent writing
: - randomly generated areas
: - ANSI color codes embedded in customizable output
: - ability to connect to the site from multiple servers
: - more classes
: - more races
: - more areas
: - formations as an extension to grouping
: - vehicles
: - missile weapons
:
: The question: what do you regard as state of the art? If you know
: specifics, can you name the mud that implemented it and why it is more
: advanced or innovative than what others do?
I have implemented time based mob movment, mobs that remember attackers
(memory is cleared if killed), mobs that hunt attackers if they flee, text
triggers, probably not careful competant writing :), NO random areas (I
may do this later, maybe not), ANSI color for everything, you CAN'T
connect from multiple servers, *shrug* on more classes, races and areas.
I am busy writing the grouping code, and the formation is leader and
rear-guard only. If you can think of why it should be more complex than
that, let me know. The leader assigns the rear-guard.
I have vehicles and ranged combat under construction :)
The vehicles are battlemechs. I'll add more types later when I've
finished them. In the 'barbarian' area, I want to make dragons rideable.
Regards,
Ian.
melp...@cruzio.com
>While I agree with this in general, I think we are seeing some
>incremental improvement due to the efforts of various individuals
>following their own vision rather than responding to the criticism of
>others. I expect this will continue for at least a year or two, until
>MUD commericalization is complete (though free MUDs will still be around).
Hrmmm. I suppose so, but there will continue to be free muds which
meet "commercial" standards, IMO. Programmers who do it for the love
of the game will still be around.
>Let me throw the graphics question out on the floor right off. Is
>graphics (first-person, third person, whatever) requisite for being
>bleeding-edge? I'm beginning to think so. Will this add to gameplay?
>Probably, though in unexpected ways -- and a poor mud with graphics is
>still a poor mud (a reality I expect to see missed by some of the larger
>players entering this area).
My experience in computer games is that far too many game companies
throw most of their budgets into bells and whistles, which make the
game appear more attractive; however, without a game behind it, my
interest in playing the game disappears.
I suspect this will also occur with graphical muds, to some extent.
--Mel
melp...@cruzio.com
leg...@dbtech.net
(melp...@cruzio.com) wrote:
I started this thread and then went off on vacation. :P In any case, lemme
address the graphics question very briefly.
No graphics are currently capable of delivering over the net or indeed at
home, the sort of detailed interaction that are the basis of certain types
of server. This means that you aren't going to see high quality graphical
MUSHes for some time. Gaming style muds are possible as these place less
of a premium on the quality of text and depth of the 'reality.'
But at the same time, I question whether this means that graphics will be
'state of the art' as they in essence mean accepting a backwards step in
many areas of mud design (interface, emote/pose, speech and communication,
area design, social actions, mobile/NPC behaviors and interactivity).
Brandon Van every
>>Let me throw the graphics question out on the floor right off. Is
>>graphics (first-person, third person, whatever) requisite for being
>>bleeding-edge? I'm beginning to think so. Will this add to gameplay?
>>Probably, though in unexpected ways -- and a poor mud with graphics is
>>still a poor mud (a reality I expect to see missed by some of the larger
>>players entering this area).
>My experience in computer games is that far too many game companies
>throw most of their budgets into bells and whistles, which make the
>game appear more attractive; however, without a game behind it, my
>interest in playing the game disappears.
>I suspect this will also occur with graphical muds, to some extent.
And you can bet that among commercial 3d muds, many companies will
lose their shirt finding this out the hard way. Especially when they
try to charge a lot of money for their lame on-line experiences.
Cheers,
Brandon
--
Brandon J. Van Every | Computer Graphics | The sun attempts
| | to be white,
vane...@rbdc.rbdc.com | C++ UNIX X11 Motif | as white as
http://rbdc.rbdc.com/~vanevery | HTML CGI Perl TCL/Tk | daytime.
leg...@dbtech.net
though. Let me try here to tug it back to the direction I was curious
about.
What's the best feature you've seen in the following categories? Name the
mud and the implementation of the feature.
roleplaying:
- best speech system (adverbs? speech tags?)
- out of character features
- description system (short descs? introductions?)
- character generation system for rp backgrounds?
- approval system or not?
gameplay:
- combat system (rounds? pulse-based? multiattacks?)
- missile weapons?
- grouping systems (formations? 'distance' system?)
- quests? run by admins or automated?
- reward for rp? for exploration? for quests?
interface:
- configurable prompts? Color? boards? mudmail?
- command completion
- help system interface
- name completion
- aliases or not?
building:
- best writing
- quests
- npcs
internal:
- scripting system or full language? ( I think saying 'none' is probably
safely not 'state of the art' :) ) Or, does anyone have detailed AI
systems in place for NPCs?
- is online building desirable?
- full mud reset, area reset, individual resets by npc/item, ecological
resets?
- distinction between NPCs and items? Or are they both 'objects' with
different flags?
The reason I ask these things is that I sense that the mud community has
NO sense of where it has been and where it is going. It was argued with me
in private email that many servers are perfectly happy with the status quo
and feel no need to develop, that the community is too darn touchy for any
sort of self-critique... but I'd like to know, what really ARE the best
features out there, because without that knowledge I don't think we as
admins can try to improve our systems except in a fitful
catch-as-catch-can way. Think of it as a critical approach for muds, as I
mentioned in an earlier post. Anyone think this is valuable, or is it
foolish?
In an earlier post, one person (sorry, it's gone from my newsreader) said
that there wasn't really a critical apparatus for the game design
community as a whole--I think there is, but as is true with any such
apparatus, much of it is pathetic and self-serving and encourages
mediocrity. One might praise Doom for the speed and adrenaline rush, for
the competent execution; but it is stupid to praise it for the concept
which is largely a rehash of tank games done with just as much adrenaline
rush back in 1979. Likewise, I see a lot of praise of superficial
enhancements on the mud newsgroups, and a lot of mention of things that
are far from being state of the art. ANSI color is NOT cutting edge, nor
are the notions of randomly generated areas, pkill teams, adverbial speech
systems or social commands, script system for npcs, mudmail and boards,
aliases... yet all of these are claimed as such.
So, anyone have a checklist of what is the basic minimum stuff a mud needs
to be current? In Their Humble Opinions, of course. :) And what is cutting
edge stuff?
Travis S Casey
>This thread hasn't quite gone the way I was thinking. :) Interesting
>though. Let me try here to tug it back to the direction I was curious
>about.
>
>What's the best feature you've seen in the following categories? Name the
>mud and the implementation of the feature.
I haven't played a lot of muds, so this will, of course, be
limited.
>roleplaying:
>
> - best speech system (adverbs? speech tags?)
Personally, I believe the best speech systems are say and emote,
which encourage players to actually come up with their *own*
ways of putting things instead of using "canned" emotes.
> - out of character features
Umm... if you're out of character, you're not roleplaying.
> - character generation system for rp backgrounds?
I'd say that state of the art in roleplaying is *not* to have
a system that generates a background for you. Most pencil-and-
paper RPG's have been moving away from this for some time.
>gameplay:
>
> - combat system (rounds? pulse-based? multiattacks?)
We've just implemented a combat daemon on our mud... it ensures
that if one person loses heartbeat and stops fighting, so does
everyone else, preventing problems arising from that. :-)
It also allows for movement restriction (keeping people from
using "bouncing" techniques), and has allowed us to turn off
heartbeats in almost all the monsters on the mud.
> - missile weapons?
I've only seen one mud with real missile weapons; SWmud. The
missile weapon system allows for weapons with special effects,
things to happen when weapons miss (e.g., if you miss with
a bow, you might be able to recover the arrow), monsters that
shoot back, monsters that move at right angles to your line
of fire to try to get out of the way, snipers, and other such
things.
I've personally implemented a monster which uses a hand-to-hand
weapon on opponents in the same room, and switches to a missile
weapon when fighting opponents at a distance. The same monster
also uses first aid on itself when it's not fighting, and will
give up using its missile weapons when they run out of ammo.
A few things that I think should have been in this section:
- skill-based systems
SWmud has skills which are associated with different guilds;
skills are increased by using them, rather than by spending
experience points. Another mud I'm working on, which we are
currently building the mudlib for, abandons the idea of classes
entirely for a completely skill-based system, and eliminates
experience points completely; thus, there's no need for
advancement rooms, etc.
Gradual build-up of characters is handled through a system
of skill prerequisites; for instance, before you can learn
medicine, you have to have some knowledge of anatomy.
>interface:
>
> - configurable prompts? Color? boards? mudmail?
I would consider using a newsreader-type setup to be SoA
(as compared to boards, that is).
> - help system interface
The best general help system I've seen is the tree-style
help system, as in Nightmare's more recent releases. A
feature we implemented on SWmud was a help index, where you
could do "panicindex xxx" and a list of help files relating
to xxx would be shown, with short descriptions of each one.
Unfortunately, the index soon got out of sync with the
actual help files, as people kept forgetting to add their
new entries to the index.
>internal:
>
> - scripting system or full language? ( I think saying 'none' is probably
> safely not 'state of the art' :) ) Or, does anyone have detailed AI
> systems in place for NPCs?
Why would you want detailed AI systems for NPCs? I can only see
two possible reasons for them: (1) natural-language communication
with NPC's, and (2) monsters that fight back intelligently.
(1) can be handled without making the monsters intelligent; on
SWmud, monster chats can be functions as well as strings, so that
monsters can say things appropriate to the situation, use the names
of people around them, etc. In addition, it's possibe to make monsters
respond to a wide range of queries in a reasonable way without using
AI, simply by taking advantage of the fact that you know the setting
that the monster and player will be in.
(2) can also be handled without AI; for non-mobile monsters, you can
write code to make them take advantage of the surrounding environment
and to allow them to switch weapons, heal themselves, and do other
things that players can do. This can be done to a more limited
extent with mobile monsters.
It's much easier to solve the little problem of how an individual
monster can act more intelligently than to solve the big problem
of how any monster in any situation can act more intelligently; in
addition, by solving the problem beforehand and then coding the
solution you save a great deal of CPU time; using true AI, the
monsters would be using the mud's CPU time up on solving the
problem, and then would still need to implement the solution.
Lastly, humans are still smarter than AI programs. :-)
Note: most fighting-type games, do not, in fact, use AI to control
the opponents; instead, they use pre-programmed strategies like I'm
describing. Some minor AI may be involved in choosing which strategy
to use at any given time, but this is a far cry from the level of AI
needed to come up with new strategies on the fly.
> - is online building desirable?
I would say yes, but only because I prefer to build that way. :-)
Also, it's very nice for quick tests of ideas.
> - full mud reset, area reset, individual resets by npc/item, ecological
> resets?
I'd say an ecological reset would be SoA; however, I haven't seen
any muds that actually implement that.
> - distinction between NPCs and items? Or are they both 'objects' with
> different flags?
Umm... in the mudlibs I've used, there are distinctions between NPC's
and items, but they are also both objects which share certain
characteristics (e.g., location, description, etc.)
>The reason I ask these things is that I sense that the mud community has
>NO sense of where it has been and where it is going. It was argued with me
>in private email that many servers are perfectly happy with the status quo
>and feel no need to develop, that the community is too darn touchy for any
>sort of self-critique... but I'd like to know, what really ARE the best
>features out there, because without that knowledge I don't think we as
>admins can try to improve our systems except in a fitful
>catch-as-catch-can way. Think of it as a critical approach for muds, as I
>mentioned in an earlier post. Anyone think this is valuable, or is it
>foolish?
Trying to improve the state of the art is definitely not foolish;
the only problem is that different people have different likes and
dislikes, so getting people to agree on what are good ideas can be
very difficult; see the recent thread on connecting muds for an
example. :-)
>So, anyone have a checklist of what is the basic minimum stuff a mud needs
>to be current? In Their Humble Opinions, of course. :) And what is cutting
>edge stuff?
IMHO, most muds are far behind paper-and-pencil RPG's when it
comes to how characters are defined and how the "game engines"
work. The majority of muds that I've seen are still using
class/level systems where the characters can only have a single
class; some have attached skill systems to this, but still
mostly rely on the classes and levels.
Part of this (again IMHO) is due to the nature of muds; many mud
players are new to muds, and many of them have also never played
any modern RPGs; lots played AD&D a few times in high school, but
AD&D is really a pretty horrible example. Most of them also have
no idea of what roleplaying is, so they make characters with names
like Cooldude and never do any "in-character" chatting.
A class/level system is easy to understand and to implement;
since most people don't want to spend a lot of time explaining
their mud to newbies, they use these kinds of systems. Also, the
majority of people making new muds don't seem to be interested
in trying to come up with new things to improve mud-dom; they just
are enamored with the idea of running their own mud. So, they grab
one of the existing mud systems, set it up, make some modifications
to the existing classes and races, and start making areas.
Of course, as I said, I haven't played on a lot of muds; thus, my
opinion is biased by the ones I have played on, which have been
mostly combat muds. If things are different in the MOO/MUSE/MUSH/etc
communities, I'd be glad to hear about it.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ FAQ maintainer for rec.games.design
|,4- ) )-,_..;\ ( `'-' confirmed cat person
'---''(_/--' `-'\_) No one agrees with me. Not even me.
"We are GNU of Borg. Your operating system will be assimilated."
leg...@dbtech.net
> <leg...@dbtech.net> wrote:
> > - best speech system (adverbs? speech tags?)
> Personally, I believe the best speech systems are say and emote,
> which encourage players to actually come up with their *own*
> ways of putting things instead of using "canned" emotes.
stock say:
Goober says, 'Hello. How are you today?'
[prefaces with standard tag, no moods or adverbs]
adverb system:
Goober says warmly, 'Hello. How are you today?'
[permits insertion of moods. More common on socials, I think]
simple tag system:
Goober asks, 'Hello. How are you today?'
[Inserts 'asks' and perhaps 'exclaims' based on punctuation]
as compared to say, what we have on LegendMUD:
'Hello,' Goober says, eyes twinkling warmly. 'How are you today?'
[parses sentences, selects tags based on a mood specified by the
speaker, places tags at start, end, or middle of sentences based
on punctuation and random chance. Multiple tags possible for each
mood, well over 150 moods.]
Emoting can of course get you the equivalent of the latter, but you are
limited to tags at the front. MUSHes and other more rp-oriented systems
may permit the player to echo out their speeches with even greater
flexibility, of course, but then we're not in a speech system anymore. :)
> > - out of character features
> Umm... if you're out of character, you're not roleplaying.
Which means what? Absolute ban on distance communication? an OOC channel?
An OOC location? An OOC location you walk to or you can teleport to?
> > - character generation system for rp backgrounds?
>
> I'd say that state of the art in roleplaying is *not* to have
> a system that generates a background for you. Most pencil-and-
> paper RPG's have been moving away from this for some time.
This could easily lead into a whole other debate on whether or not one
should HAVE such a thing. Offhand, I'd say these are helpful for those who
can't rp, and a challenge for those who can and are thus forced to rp
someone not in their standard repertoire. They of course, do not permit
freedom of character.
> >gameplay:
> >
> > - combat system (rounds? pulse-based? multiattacks?)
>
> We've just implemented a combat daemon on our mud... it ensures
> that if one person loses heartbeat and stops fighting, so does
> everyone else, preventing problems arising from that. :-)
You don't have problems with people severing link purposely? I'll admit
that the heartbeat nomenclature is not in use on my mud, so I may not
quite follow here.
> > - missile weapons?
>
> I've only seen one mud with real missile weapons; SWmud. The
> missile weapon system allows for weapons with special effects,
> things to happen when weapons miss (e.g., if you miss with
> a bow, you might be able to recover the arrow), monsters that
> shoot back, monsters that move at right angles to your line
> of fire to try to get out of the way, snipers, and other such
> things.
We've got special effects, missiles to other rooms, are working on the
recovering arrows bit, any monsters can shoot back if they are scripted
to, snpiing is easy... I would agree that very few muds have a decent
missile weapons system, so I'd consider what you described to be state of
the art. How wide a range of missiles does it supply? Are there skill
levels for the use? Archery? Guns? Mountable on vehicles?
> I've personally implemented a monster which uses a hand-to-hand
> weapon on opponents in the same room, and switches to a missile
> weapon when fighting opponents at a distance. The same monster
> also uses first aid on itself when it's not fighting, and will
> give up using its missile weapons when they run out of ammo.
>
Rather easily done with our script system... I don't know what system you
are using, but we'd simply trigger a reload or abandomnent of the weapon
based on the messages for out of ammo...
> A few things that I think should have been in this section:
>
> - skill-based systems
Agreed! Dunno how I forgot them. :P
> SWmud has skills which are associated with different guilds;
Is this state of the art? I see more and more muds moving to a no-guild
system altogether. We've had it for almost two years now. Dert's
mud-in-design incorporates many approaches to this issue. DartMUD has some
interesting fillips to it...
> skills are increased by using them, rather than by spending
> experience points. Another mud I'm working on, which we are
> currently building the mudlib for, abandons the idea of classes
> entirely for a completely skill-based system, and eliminates
> experience points completely; thus, there's no need for
> advancement rooms, etc.
I would say the notion of advancement rooms is at least four years out of
date. Eliminating XP is a more radical notion but hardly new. I haven't
heard of any muds that do it that have survived for a long time (note I
speak of gaming system,s not pure rpg systems). Anyone know of one, I'd be
curious to visit.
> Gradual build-up of characters is handled through a system
> of skill prerequisites; for instance, before you can learn
> medicine, you have to have some knowledge of anatomy.
We've got that too, I know Worlds of Carnage has had it since summer of 94
and I am sure others had it earlier... They did not use quite a specific a
tree as you describe however, but that reaches the point of being finicky,
not trying to determine what is state of the art.
> >interface:
> >
> > - configurable prompts? Color? boards? mudmail?
>
> I would consider using a newsreader-type setup to be SoA
> (as compared to boards, that is).
Hmm. Why? I can think of pros and cons. I'll name cons just to be
contrary: lack of localization, shattering of the rp illusion, more
cumbersome amount of information to manage.
> > - help system interface
>
> The best general help system I've seen is the tree-style
> help system, as in Nightmare's more recent releases. A
> feature we implemented on SWmud was a help index, where you
> could do "panicindex xxx" and a list of help files relating
> to xxx would be shown, with short descriptions of each one.
> Unfortunately, the index soon got out of sync with the
> actual help files, as people kept forgetting to add their
> new entries to the index.
I'd agree that an indexed system would be necessary. What about help mode
vs invoked keywords? Pulls you out of the game or leaves you vulnerable?
> >internal:
> >
> > - scripting system or full language? ( I think saying 'none' is probably
> > safely not 'state of the art' :) ) Or, does anyone have detailed AI
> > systems in place for NPCs?
>
> Why would you want detailed AI systems for NPCs? I can only see
> two possible reasons for them: (1) natural-language communication
> with NPC's, and (2) monsters that fight back intelligently.
>
> (1) can be handled without making the monsters intelligent; on
> SWmud, monster chats can be functions as well as strings, so that
> monsters can say things appropriate to the situation, use the names
> of people around them, etc. In addition, it's possibe to make monsters
> respond to a wide range of queries in a reasonable way without using
> AI, simply by taking advantage of the fact that you know the setting
> that the monster and player will be in.
Yes, and every script system out there, even Merc's fairly crude MobProgs,
can do this. And the fact is, it's clumsy. I've coded hundreds of mobs
using our script system and triggers, and you can program in a wide range
of FIXED responses using a system like this. But the mob will not be fully
interactive... it's more like pushing buttons to get a cup of coffee.
> (2) can also be handled without AI; for non-mobile monsters, you can
> write code to make them take advantage of the surrounding environment
> and to allow them to switch weapons, heal themselves, and do other
> things that players can do. This can be done to a more limited
> extent with mobile monsters.
You can do it with mobile monsters too, if they have the ability to
recognize items by type and specific instance, etc etc. I wouldn't think
an AI system is needed for this either.
> It's much easier to solve the little problem of how an individual
> monster can act more intelligently than to solve the big problem
> of how any monster in any situation can act more intelligently;
Naturally. It also leads to a less developed mud... let's push the
envelope some. :)
>Some minor AI may be involved in choosing which strategy
> to use at any given time, but this is a far cry from the level of AI
> needed to come up with new strategies on the fly.
Nor would I say new strategies are needed on the fly. I was really getting
more at a natural extension of the
> > - full mud reset, area reset, individual resets by npc/item, ecological
> > resets?
>
> I'd say an ecological reset would be SoA; however, I haven't seen
> any muds that actually implement that.
I'd be curious too. We don't, we use individual resets, and provide
withhin script for individual mobs to create miniature ecologies, but it's
not exactly fancy or anything.
> > - distinction between NPCs and items? Or are they both 'objects' with
> > different flags?
>
> Umm... in the mudlibs I've used, there are distinctions between NPC's
> and items, but they are also both objects which share certain
> characteristics (e.g., location, description, etc.)
Yeesss... not quite what I meant. They have different structure
definitions, they are not internally the same. But I believe there are
systems whereby the only real differences between items and NPCs are
whether or not the objects moves or talks.
> Trying to improve the state of the art is definitely not foolish;
> the only problem is that different people have different likes and
> dislikes, so getting people to agree on what are good ideas can be
> very difficult; see the recent thread on connecting muds for an
> example. :-)
Yes, I know. :) I've posted several times about the need to recognize the
range of possible uses and wants in a mud server.
> IMHO, most muds are far behind paper-and-pencil RPG's when it
> comes to how characters are defined and how the "game engines"
> work. The majority of muds that I've seen are still using
> class/level systems where the characters can only have a single
> class; some have attached skill systems to this, but still
> mostly rely on the classes and levels.
So throwing classes out the window fits your definition of the state of
the art. Anyone got a list of classless muds?
[plenty good stuff snipped]
> Also, the
> majority of people making new muds don't seem to be interested
> in trying to come up with new things to improve mud-dom; they just
> are enamored with the idea of running their own mud. So, they grab
> one of the existing mud systems, set it up, make some modifications
> to the existing classes and races, and start making areas.
So very true. So it behooves those of us who care to make them aware of
the wider range of possibilities, and of the desirability of ehancing the
state of the art overall, yes? :)
-Ptah@LegendMUD
--
Lege...@dopey.cc.utexas.edu 9999 * "History the way it should have been." Classless * Word-based magic * Technology * Guns * Medical skills * Herbalism * variable rate fights * OOC Lounge * Dozens of automated quests * Bardic skills * 150+ spells * 75+ skills * Researched all original areas like Beowulf, Arabian Nights, Viking Scandinavia, Victorian London, French-Indian War * customizable color * free and open debate on email discussion group * the Legendary Times newsletter * optional pkill * mature atmosphere * three eras * "If you're only visiting one mud, make it Legend" - The Electronic Newsstand * MudGate Pick of the Week for Six Months, do they ever update it?
leg...@dbtech.net
Eliasson) wrote:
> > >I expect this will continue for at least a year or two, until
> > >MUD commericalization is complete (though free MUDs will still be around).
> Commercial MUDs?? Do they exist? Only text-based or are you talking about
> future games like Quake and Crusade?
There are several commercial text muds on the Internet.
There are many graphical and text muds on game networks and online services.
There are several companies/groups developing commercial graphical muds
for Internet usage--these are NOT
Quake-make_doom-Play-over_the_net-and-blow-people-up, but actual real rpg
environments. You can check out Dr. Cat's try right now. I would be
surprised if there were not more than the three I am aware of.
Brandon Van every
>> Also, the
>> majority of people making new muds don't seem to be interested
>> in trying to come up with new things to improve mud-dom; they just
>> are enamored with the idea of running their own mud. So, they grab
>> one of the existing mud systems, set it up, make some modifications
>> to the existing classes and races, and start making areas.
>So very true. So it behooves those of us who care to make them aware of
>the wider range of possibilities, and of the desirability of ehancing the
>state of the art overall, yes? :)
Making people aware of theoretical design ideas is one thing. Giving
them the software tools to actually implement them in real-world time
is quite another. All existing muds suffer from an enormous baggage
of embedded methodology throughout the entire code base. The reason
you see only minor, incremental changes in mud technology, is that the
technology itself is very hard to modify.
Really radical changes in the way people do muds, are always going to
take rewrites from scratch.
Johan Eliasson
> >MUD commericalization is complete (though free MUDs will still be around).
Commercial MUDs?? Do they exist? Only text-based or are you talking about
future games like Quake and Crusade?
--
/********************************************************************\
* Johan Eliasson : m94...@student.tdb.uu.se * Any opinions expressed *
* herein are mine and not necessarily those of my compiler. *
\********************************************************************/
leg...@dbtech.net
every) wrote:
> Making people aware of theoretical design ideas is one thing. Giving
> them the software tools to actually implement them in real-world time
> is quite another. All existing muds suffer from an enormous baggage
> of embedded methodology throughout the entire code base. The reason
> you see only minor, incremental changes in mud technology, is that the
> technology itself is very hard to modify.
I've been following your threads on social conduct within muds in
r.g.m.misc with interest. I have to disagree with you here however. First
of all, I suspect you underestimate the importance of minor incremental
changes. Radical changes rarely advance the state of the art--it's usually
the small stuff that improves. Small changes make for big results quite
often.
> Really radical changes in the way people do muds, are always going to
> take rewrites from scratch.
Always? I doubt it. I've seen far too many total rewrites that look
exactly the same as earlier muds. *shrug*.
A place that seems to have a quite a nice design paradigm is DartMUD.
They've done a LOT of extension of the basic mud paradigm without doing
more than extension of the basic LP code. Yes, undoubtedly they have hit
or will soon hit the point where a rewrite to a more suitable system will
be needed, but the opint is that they managed to implement what they
wanted (which IS radically different from most muds out there) without
needing to go over to LISP.
[Disclaimer, if they have and I haven't noticed, I'll stand corrected.]
Christopher J. Dickey
we define what is SoA? Is it something that is unique, something
difficult to implement, something easy to use? If everyone has that
feature, is it technically SoA anymore? Does it need to be changed?
I think one big problem in defining this is that different servers are
aimed at different audiences. Not everyone wants to role-play, some
people like hack-and-slash only. Do you think they are interested in
have neat role-play features? Probably not. Some servers are basically
Doom-ish, while some might be Ultima-ish (ie, combat oriented,
role-playing/combat), while others might be pure role-playing. But
taking these thoughts into consideration, I suppose we can come up with
some sort of list of what should be considered state of the art, or at
least something more desireable than the stock server supplies. It seems
that many coders forget that the reason alot of servers are vanilla is to
leave room for the coder to be creative. Maybe the vanilla servers need
to step up a bit to include what we feel should be common?
: What's the best feature you've seen in the following categories? Name the
: mud and the implementation of the feature.
: roleplaying:
: - best speech system (adverbs? speech tags?)
As far as this is concerned, the adverb system and speech tag system are
both pretty nice, and combine nicely. Again, a hack-and-slasher could
care a less, but it's nice to have the option to express oneself in a
myriad of ways. Personally, I prefer the code not to interpret the
emotions in my text, even if I decide to put a question-mark at the end,
so I'd say almost an echo/emote type of speech system where you can add
emotion to your text.
: - description system (short descs? introductions?)
I suppose this depends on what kind of realism you want in your server.
I don't know if I prefer any way.
: - character generation system for rp backgrounds?
: - approval system or not?
I don't know if you can consider things such as these as SoA. They are
easy to code, and are put in only if the mud needs it.
: gameplay:
: - combat system (rounds? pulse-based? multiattacks?)
Not AD&D ;) It all again depends on the world. Take the mud I'm working
on as an example. Combat rounds take place approximately every 3
seconds. Everyone rolls initiative to see who attacks first. The
quicker you are, the more attacks you get. However, the attacks are not
successive (ie, my quickness is 6, I automatically get 4 attacks in a
row). As people can only perform any action so fast, others will
probably get an action before your next one comes up. Basically, you
have combat rounds, and each round is broken up into actions. Is this
SoA? Maybe, maybe not. I'm making no claims, just giving an example.
: - missile weapons?
Since alot of muds don't have missile weapons, this is probably
considered SoA currently. The ability to see further because of
enhancements, and shoot from one area to another, is not seen on many
muds (there are some though).
: - grouping systems (formations? 'distance' system?)
The idea of having a structured group is fine, but I think it should be
based on some sort of ability. How many people out there know anything
about strategy, and would remember it in a battle? Maybe people should
fall out of formation if their skill sucks, hehehe.
Part of the problem with groups, and missile weapons, is the way most
muds are structured. Rooms can be of varying sizes. So, we can cram two
groups of 10 into a broom closet, and at the same time shoot an arrow
across the lakes and the mountains. One idea would be to give rooms
sizes, and limit the amount of volume that can occupy it. You could also
determine quite easily how far that arrow or bullet should fly. Even
mobs should have some sort of size so that 10 people can't simultaneously
attack a roach.
: - quests? run by admins or automated?
Both are nice. Obviously admin-run quests are many times more
interesting because of the ability to change on the fly. Automated
quests are good if the system is good. I'd think that built in quests
might be considered SoA just because few systems have them. Of course,
way back when, lights were considered SoA, but if they burnt out every 5
seconds, they would be basically useless. The same thing with built in
quests. If they are poorly designed, they are useless. What I do on my
mud is have the automated quests draw from a pool of ideas so that they
change constantly. If you come up with a new idea, throw it in the pool
and it gets added. Variety is the spice of life. Futher, you don't have
folks handing out tintin scripts to complete every quest on you mud (=
: - reward for rp? for exploration? for quests?
We are levelless and basically classless. A little xp is gained for
killing. However, ALOT more is gained for quests. XP will also be
gained for role-playing.
: interface:
: - configurable prompts? Color? boards? mudmail?
: - command completion
: - help system interface
: - name completion
: - aliases or not?
Alot of muds allow abbreviations of names. Color, though not SoA, by now
SHOULD be included in every server. I'm sure I'll get flamed for that
comment, but it's like arguing weather or not we should use
black-and-white TV or color TV. Color makes things distinguishable,
makes the screen more pleasant, and adds to the mood (red pools of
blood). However, it should ALL be customizable. If I want room titles
purple, so be it, we all have different tastes.
I'm glad you brought it up, cause one thing people overlook is the
command interface. It would be nice (as I'm implementing on my mud,
hehehe) to be able to hit your 'up arrow' key and scroll through a small
command history, and further be able to edit that list, like you do with
your shell.
Aliases are also nice, if only because not everyone can use a client to
mud with. Though common, they probably are a necessity for many people
(ie, those who can't type fast).
: building:
: - best writing
: - quests
: - npcs
OLC is usually considered SoA if you're on a diku-type mud. The question
is how it's handled, and if there are any side effects (lag from saving
big files, etc). SoA on line building would possibly be something that
passes on room data to a forked process to do any saving, etc, in order
to keep lag down. Along with your next set of questions, you might
include what is considered SoA as far as data structures are concerned.
Does the mud handle rooms in a array which starts off oversized, and then
gets expanded when needed (ie, you filled up the extra 300 rooms you had
space for). Do you use an enumerated binary tree? Hash table?
: internal:
: - scripting system or full language? ( I think saying 'none' is probably
: safely not 'state of the art' :) ) Or, does anyone have detailed AI
: systems in place for NPCs?
: - full mud reset, area reset, individual resets by npc/item, ecological
: resets?
Having to reset your mud by shutting it down and rebooting is definately
not considered SoA, I'd dare say ;) Resets should be more than the usual
"less than 5? okay load". SoA would include something more detailed,
possibly including economy, and resources. On my mud, corporations will
produce items for stores to sell. Each corp needs money, people, and
resources to stay in business. Corps can war with each other, knock each
other out of business, and wreck havoc on the economy. Of course, this
model is appropriate for my mud (in the future), but you get the idea.
The idea is possibly to submerge the players in a dynamic world.
Is a dynamic world what the mud community should be striving for? It's
really hard to say. For a combat/hack-and-slash mud, it probably doesn't
matter much. In those cases, an easy but powerful interface, and a more
complex set of game mechanics are probably considered state of the art.
In a role-playing/combat oriented mud, you'd probably need the above,
plus a dynamic world. And in a pure-roleplaying mud, the emphasis is
obviously on the dynamic world (though the last two types can't always be
distinguished).
CJD
Brandon Van every
>> Really radical changes in the way people do muds, are always going to
>> take rewrites from scratch.
>Always? I doubt it. I've seen far too many total rewrites that look
>exactly the same as earlier muds. *shrug*.
Fair enough. We'll have to start talking specifics if we want to get
farther than generalities here.
I want a MUD that has a complex physical universe, allows players to
code new objects online, cannot be hacked or imbalanced by "infinite
wealth" bugs, does not use any human administrators, and has an
@IGNORE command which will absolutely and fundamentally ignore
everything a harassing player says or does, as well as all his
attempts to do the same via 3rd party channels.
No existing MUD has done this. No existing MUD can manage this.
It must be written completely from scratch, and the new functionality
built-in from the ground up. You can't incrementally add these
features to a "legacy" software system. It's like trying to make DOS
do multi-tasking.
>A place that seems to have a quite a nice design paradigm is DartMUD.
>They've done a LOT of extension of the basic mud paradigm without doing
>more than extension of the basic LP code. Yes, undoubtedly they have hit
>or will soon hit the point where a rewrite to a more suitable system will
>be needed, but the opint is that they managed to implement what they
>wanted (which IS radically different from most muds out there) without
>needing to go over to LISP.
Ok, I'll bite. What makes DartMUD so different? Assume for the
moment that I'm very busy and really don't have time to wander around
and see for myself. Your executive summary, if you please. :-)
leg...@dbtech.net
every) wrote:
> I want a MUD that has a complex physical universe, allows players to
> code new objects online, cannot be hacked or imbalanced by "infinite
> wealth" bugs, does not use any human administrators, and has an
> @IGNORE command which will absolutely and fundamentally ignore
> everything a harassing player says or does, as well as all his
> attempts to do the same via 3rd party channels.
Please clarify 'complex physical universe' as I am sure that everyone
reads it differently. :)
@IGNORE is fairly simple to implement, and is what I would call an
incremental addition... clients have of course supported it for years.
Hacking and imbalance in a system where players can create objects is
always a problem--your challenge is to do it, as you say, without human
admins. I am unsure of the desirability of lack of human control, to tell
the truth--not only does adminning provide a valuable experience for
people, but also a hardcoded system will lack leniency and understanding.
All a matter of what you plan to outlaw of course--which seems to be as
yet undefined. A server that can artificially control things like the
economy or restrain the degree to which players can create is fairly
simple; doing it so that the limits are not obnoxious is another story.
But again, not a paradigmatic shift until you discuss no admins
whatsoever. There, I'd agree, one must have a new server from scratch. Not
sure if it fits in a state of the art discussion, but perhaps it would if
there were concrete details as to how it would/could/(does? dunno how far
Brandon has gotten) work.
> No existing MUD has done this. No existing MUD can manage this.
Agreed. They can manage most of it under existing code bases, though, save
for the supervision aspect.
> >A place that seems to have a quite a nice design paradigm is DartMUD.
> Ok, I'll bite. What makes DartMUD so different?
Well, i have no affiliation with the place, and bopped on in my ongoing
quest for good design. :) Some of the things which I noted which I have
not seen functioning well elsewhere (and to tell the truth, do not know
how well they function there):
- no 'admins' per se, builders yes, but 'justice' over the breaking of
'rules' is administered by a court of players--playerkilling wide open of
course
- a hex map wilderness system with true moving weather patterns across the
surface
- full weather function to go along with that, including environmental
details like temperature, etc
- a largely player-based economy, something always discussed but rarely
implemented, with craftsmen and businessmen and player shops and so on
- a revamped alignment system that mostly throws alignment out of the
window in favor of a system based on your attitude when doing certain
actions
- a rather permanent attitude toward death (not as far as say Armageddon,
but still much more than the usual)
- a 'concentration' based system of learning skills and spells
- plus various other things not particularly original, such as limb based
combat, etc etc, although they add the interesting fillip that one good
blow to the head may just crush it and you're toast--limbs are permanently
damaged short of magical aid, and critical wounds can happen any number of
ways based on where the blows land... likewise, magical reincarnation
requires a decent body, which may mean reincarnation into the closest
available intact corpse...
All in all, it's a pretty coherent and well-thought out system for a
fairly-rp based adventure style MUD. I have not seen a combination of such
features all in one place before. Offhand, my critiques would center
around annoying interface aspects from the LP base that was used, the
apparent lack of playerbase which would be needed to make a true player
economy work (one fact often ignored in debates on this is that it doesn't
work unless you have a critical mass of players), implementation troubles
with how their concentration system works...
Unfortunately, I didn't stay for too long, as I was just checking the place out.
leg...@dbtech.net
(Christopher J. Dickey) wrote:
> I guess a big question (as probably previously stated), is how exactly do
> we define what is SoA? Is it something that is unique, something
> difficult to implement, something easy to use? If everyone has that
> feature, is it technically SoA anymore? Does it need to be changed?
If everyone has it, then I'd say it's not SoA anymore. But if it is truly
worthwhile, then surely we want everyone to have it. :) As far as should
it change--well, depends on the need of the server, of course, but I'd say
that every server should attempt to keep evolving and developing.
> I think one big problem in defining this is that different servers are
> aimed at different audiences. Not everyone wants to role-play, some
> people like hack-and-slash only.
Of course. I'd say that some features apply onyl to one type of server,
others are more broadly applied. Example, the speech system discussed
below and in my other post, which you could slap into a hack n slash mud,
and if they wanna ignore it, they do, they get the stock says.
> : roleplaying:
> : - best speech system (adverbs? speech tags?)
> As far as this is concerned, the adverb system and speech tag system are
> both pretty nice, and combine nicely. Again, a hack-and-slasher could
> care a less, but it's nice to have the option to express oneself in a
> myriad of ways. Personally, I prefer the code not to interpret the
> emotions in my text, even if I decide to put a question-mark at the end,
> so I'd say almost an echo/emote type of speech system where you can add
> emotion to your text.
BTW, the system we have at Legend is the one I described in a previous
post, where you can specify moods and tags are randomly selected from
those that apply, as well as automatic parsing for multiple placements of
speech tags. Tags like 'asks' are never assigned to the text by the
server, you do it yourself. It does determine based on punctiuation
whether to place it at start, end, or middle of a sentence.
> : - description system (short descs? introductions?)
> I suppose this depends on what kind of realism you want in your server.
> I don't know if I prefer any way.
Optional system? We have it optional, where a person can have it but may
turn it off. Because of current site constraints, we lack an introduction
system. Thoughts on the need for those? ALso, we do not let those LOOKING
turn them off as some like to use descs as a disguise system. Thoughts on
that?
> : - character generation system for rp backgrounds?
> : - approval system or not?
> I don't know if you can consider things such as these as SoA. They are
> easy to code, and are put in only if the mud needs it.
What's the best one anyone's seen?
> : gameplay:
> : - combat system (rounds? pulse-based? multiattacks?)
> Not AD&D ;) It all again depends on the world. Take the mud I'm working
> on as an example. Combat rounds take place approximately every 3
> seconds. Everyone rolls initiative to see who attacks first. The
> quicker you are, the more attacks you get. However, the attacks are not
> successive (ie, my quickness is 6, I automatically get 4 attacks in a
> row). As people can only perform any action so fast, others will
> probably get an action before your next one comes up. Basically, you
> have combat rounds, and each round is broken up into actions. Is this
> SoA? Maybe, maybe not. I'm making no claims, just giving an example.
We used a pulse based system whereby things like weapon quality, weight,
attacker skill, previous actions such as skill suage, etc, determine a
delay in pulses between each attack. Internally it is fully discontinuous,
one person might attack every 4 pulses with a dagger (but only every 18
with a sword cause they suck as swords) and their opponent might attack
every 9 pulses. We ran for a while with this system reporting messages
discontinuously, but found that the spam was too much to take. Hence we
went to REPORTING it by rounds, and have not yet fully resolved the
cosmetic side of it. Internally pulses are what matter, and you can see
people not getting any attacks in a 'round' or having pulses left over
from a previous rounds and thus getting 2 attacks one round and 1 the
next, predictably.
> : - missile weapons?
> Since alot of muds don't have missile weapons, this is probably
> considered SoA currently. The ability to see further because of
> enhancements, and shoot from one area to another, is not seen on many
> muds (there are some though).
>
I think that the question of how FAR a range missile weaons can have
raises the question of how muds handle scale (see the interesting thread
just started on modeling physical space, perhaps?). Firing through
multiple rooms would be quite possible on our server, but we decided not
to permit it because we have variable size rooms with no internal value
for size that could be referenced. Hence one could, on Legend, fire a bow
across the English Channel (high mv cost but few rooms, to alleviate the
tedium of modeling the actual historical Earth to scale... be quite boring
to write and to travel through as well).
> : - grouping systems (formations? 'distance' system?)
> The idea of having a structured group is fine, but I think it should be
> based on some sort of ability. How many people out there know anything
> about strategy, and would remember it in a battle? Maybe people should
> fall out of formation if their skill sucks, hehehe.
Excellent point. We only go so far as to have a 'wary/aggressive' setting
players can modify, in essence moving them closer to or father away from
the fight. Skill is not an issue and perhaps it should be.
> One idea would be to give rooms
> sizes, and limit the amount of volume that can occupy it.
> Even
> mobs should have some sort of size so that 10 people can't simultaneously
> attack a roach.
Interesting notion! Anyone done this? I'd be interested in seeing amud
that implemented it fully.
> : - quests? run by admins or automated?
> Both are nice. Obviously admin-run quests are many times more
> interesting because of the ability to change on the fly. Automated
> quests are good if the system is good. I'd think that built in quests
> might be considered SoA just because few systems have them
Why DO so few systems have them? Is it that big a deal to implement a
detailed easy to use script language for a mud? Having looked at code for
Valhalla's system, i find it very cumbersome for novice builders. World of
Carnage's excellent acts system is much easier to handle, though I do not
know if it is as powerful. (are they the first? Merc credits them as
originators of the MOBprogs concept).
> The same thing with built in
> quests. If they are poorly designed, they are useless. What I do on my
> mud is have the automated quests draw from a pool of ideas so that they
> change constantly. If you come up with a new idea, throw it in the pool
> and it gets added. Variety is the spice of life. Futher, you don't have
> folks handing out tintin scripts to complete every quest on you mud (=
Hmm, I'd be curious to know the nature of these quests. They sound like
what we call 'fetch and carry' style quests. Our script system permits
more complex interaction than that, including the performing of very
specific actions (say, dance in a particular room during the night, while
wearing a specific item, and having tossed the magical powder into the pit
of the Volcano of Doom, and perhaps Gobbog the Demon will appear). Do your
randomized automated quests have that sort of flexibility?
> : interface:
> : - configurable prompts? Color? boards? mudmail?
> : - command completion
> : - help system interface
> : - name completion
> : - aliases or not?
>
> Color, though not SoA, by now
> SHOULD be included in every server....Color makes things distinguishable,
> makes the screen more pleasant, and adds to the mood (red pools of
> blood). However, it should ALL be customizable. If I want room titles
> purple, so be it, we all have different tastes.
Why do so few muds have it fully customizable?
> I'm glad you brought it up, cause one thing people overlook is the
> command interface. It would be nice (as I'm implementing on my mud,
> hehehe) to be able to hit your 'up arrow' key and scroll through a small
> command history, and further be able to edit that list, like you do with
> your shell.
Hmm. I admit to not having been thinking in that direction. Sounds like a
partial incorporation of client software into the basic mud interface. How
much is that a desirable goal (I realize now that everything in the
interface category is exactly that)...
> Aliases are also nice, if only because not everyone can use a client to
> mud with. Though common, they probably are a necessity for many people
> (ie, those who can't type fast).
Funny, we lack aliases on Legend purposely, finding that people use them
to pay less attention to the game. But it's been challenged in the past on
many grounds, including that it favors the client users.
> : building:
> : - best writing
> : - quests
> : - npcs
> OLC is usually considered SoA if you're on a diku-type mud. The question
> is how it's handled, and if there are any side effects (lag from saving
> big files, etc). SoA on line building would possibly be something that
> passes on room data to a forked process to do any saving, etc, in order
> to keep lag down. Along with your next set of questions, you might
> include what is considered SoA as far as data structures are concerned.
> Does the mud handle rooms in a array which starts off oversized, and then
> gets expanded when needed (ie, you filled up the extra 300 rooms you had
> space for). Do you use an enumerated binary tree? Hash table?
WHY is OLC state of the art on Dikus? I have never seen it done very well
(decent editing, for example, seems beyond the reach of any muds that I
have seen), and it also seems to me to limit the scope for script
langages, as unles syou are very careful with memory protection or
severely limit the script language, crashing the server with buggy scripts
is quite possible. Aesthetically, I have also found that OLC tends to
produce poorer written areas, not to mention more gridlike ones as
generally speaking the ability to rearrange the map on the fly is lacking.
> : internal:
> : - full mud reset, area reset, individual resets by npc/item, ecological
> : resets?
> Having to reset your mud by shutting it down and rebooting is definately
> not considered SoA, I'd dare say ;)
Quite common to pkill muds, though.
> Resets should be more than the usual
> "less than 5? okay load". SoA would include something more detailed,
> possibly including economy, and resources. On my mud, corporations will
> produce items for stores to sell. Each corp needs money, people, and
> resources to stay in business. Corps can war with each other, knock each
> other out of business, and wreck havoc on the economy. Of course, this
> model is appropriate for my mud (in the future), but you get the idea.
> The idea is possibly to submerge the players in a dynamic world.
A huge issue: can any sort of ecological system (my term for what you are
describing) survive without some sort of oversight or maintenance? Or for
that matter, without a minimum base of players to provide a functioning
economy? What happens when you have a system of 50 consumers and no
producers? Or of 50 deer killers that kill all the deer until the species
is EXTINCT?
Note that i too think that this is the way it HAS to go. Dert's
MUD-in-progress proposes a system whereby individual monsters learn the
longer they survive and thus get tougher. DartMUD provides for this with
specific monsters only, that have a save file. DartMUD's system also uses
a notion similar to Dert's, with critters learning by seeing what the
enemy does. In a fully ecological system, if players imbalance the
structure, one of these guys could well become all-powerful--do we then
provide for the logical consequence, an all-powerful orc taking over the
world and poutting all the players to death? :)
melp...@cruzio.com
>I want a MUD that has a complex physical universe, allows players to
>code new objects online, cannot be hacked or imbalanced by "infinite
>wealth" bugs, does not use any human administrators, and has an
>@IGNORE command which will absolutely and fundamentally ignore
>everything a harassing player says or does, as well as all his
>attempts to do the same via 3rd party channels.
>No existing MUD has done this. No existing MUD can manage this.
>It must be written completely from scratch, and the new functionality
>built-in from the ground up. You can't incrementally add these
>features to a "legacy" software system. It's like trying to make DOS
>do multi-tasking.
Hm. The LambdaMOO muds seem to come pretty close to what you are
suggesting. Given the basic core, it can be made into pretty much
whatever type of mud you want (social, puzzle, hack-n-slash).
However, I'm puzzled by what you mean by "does not use any human
administrators." There has to be at least one who is omnipotent (to
maintain the core db, among other janitorial tasks).
--Mel
melp...@cruzio.com
Brandon Van every
>vane...@rbdc.rbdc.com (Brandon Van every) wrote (in part):
>>I want a MUD that has a complex physical universe, allows players to
>>code new objects online, cannot be hacked or imbalanced by "infinite
>>wealth" bugs, does not use any human administrators, and has an
>>@IGNORE command which will absolutely and fundamentally ignore
>>everything a harassing player says or does, as well as all his
>>attempts to do the same via 3rd party channels.
>>No existing MUD has done this. No existing MUD can manage this.
>>It must be written completely from scratch, and the new functionality
>>built-in from the ground up. You can't incrementally add these
>>features to a "legacy" software system. It's like trying to make DOS
>>do multi-tasking.
>Hm. The LambdaMOO muds seem to come pretty close to what you are
>suggesting. Given the basic core, it can be made into pretty much
>whatever type of mud you want (social, puzzle, hack-n-slash).
However, it doesn't have the necessary technical base to implement
robust security features. Probably it could do much of the rest, but
security really is critical to advancing the MUD state of the art,
both in terms of general acceptance by the public, and in terms of
improved game play. You can't make a complex physical universe if Joe
Schmo can come along and unbalance it with some infinite wealth
generatione bug, thereby giving himself the Atomic Bomb.
>However, I'm puzzled by what you mean by "does not use any human
>administrators." There has to be at least one who is omnipotent (to
>maintain the core db, among other janitorial tasks).
Was it Descartes who said, when asked about God by some cardinal or
something: "I have no need for that hypothesis." :-)
Having one person compile the sources and make sure the game is still
running, is a very different order of business from having a GOD
within the game itself. There's no reason janitorial tasks can't be
automated. It just takes more sophisticated memory and disk
management algorithms.
Having God-like players in the game might be desireable to some,
especially to stir things up and create new things to do when the
universe stabilizes and gets boring. However, there's no compelling
reason to have an omnipotent God like mud admins of today. The
role of a "God," or even of several Gods, should be a matter of choice
in terms of game design, and not a technological necessity. So if I
want to implement a traditional hierarchy of "Wizards" on top of a
totally secure system, I could do that. Or if I want a Monotheistic
society with only One True God, I could do that too. Or if I prefer
an anarchist or egalitarian society where everyone has pretty much
equal power, I could do that as well. It should be a matter of what
game you want to play, and not an inherent limit of the mud server
technology.
One thing I definitely want to eliminate, is the role of mud admins as
the arbiters of player disputes. I want players to settle their own
disputes, such as by @IGNOREing each other, or stepping out of the
safe haven zones and killing each other. I have seen too much free
speech trampled on, even by "good" admins. Basically, when one has
unchecked power over another, civil liberties get trampled on sooner
or later.
leg...@dbtech.net
every) wrote:
a long answer to
> melp...@cruzio.com (melp...@cruzio.com) writes:
who wrote a brief answer to
> >vane...@rbdc.rbdc.com (Brandon Van every) wrote (in part):
completely ignoring MY answer! *sigh*
Why dones't Brandon answer my posts?
Ptah@LegendMUD, tongue firmly in cheek
Mark Clements
MUDs these days are things that I feel should be pretty much standard.
Things such as missile weapons which can go between rooms, roving
monsters and so on, seem so logical, that I am surprised they aren't
present in all MUDs (or rather those they apply to).
The other things I see are just expansions on old things, in the form
of 'greater number of'. e.g. 2000 races, over 9,000,000 levels etc.
I think state of the art these days seems to be behind the logical
expectations of someone who had never played a MUD, but had heard
about them.
Having told someone they are games which many players can play at once,
it seems to be unnecessary to tell them you can talk to other players.
Similarly having told them that a lot of MUDs emphasise fighting, saying
that you can *gasp* shoot an arrow from one location to another seems
a little silly.
But then why do so few MUDs support this feature?
--
___ ,';_,-,__
Writing is just backwards reading. /~_ ,',' |O|,:,\,
Reading is just clever seeing. / /,',' /--|_|-;:;|
Seeing is believing. ( )',_) ) ):;)
To write, you must believe... >\,(__ / /:;;|
:...Mark...//~ /:;:;:\
leg...@dbtech.net
> Most of the 'new' or 'special' features that I see in adverts for
> MUDs these days are things that I feel should be pretty much standard.
> Things such as missile weapons which can go between rooms, roving
> monsters and so on, seem so logical, that I am surprised they aren't
> present in all MUDs (or rather those they apply to).
>
> The other things I see are just expansions on old things, in the form
> of 'greater number of'. e.g. 2000 races, over 9,000,000 levels etc.
>
> I think state of the art these days seems to be behind the logical
> expectations of someone who had never played a MUD, but had heard
> about them.
>
> Having told someone they are games which many players can play at once,
> it seems to be unnecessary to tell them you can talk to other players.
> Similarly having told them that a lot of MUDs emphasise fighting, saying
> that you can *gasp* shoot an arrow from one location to another seems
> a little silly.
>
> But then why do so few MUDs support this feature?
I asked this a while ago and nobody answered. :)
-Ptah@LegendMUD
Christopher J. Dickey
: In article <3vf6tm$h...@empire.texas.net>, cdi...@millenium.texas.net
: > (Christopher J. Dickey) wrote:
: If everyone has it, then I'd say it's not SoA anymore. But if it is truly
: worthwhile, then surely we want everyone to have it. :) As far as should
: it change--well, depends on the need of the server, of course, but I'd say
: that every server should attempt to keep evolving and developing.
Perhaps we need a thread describing what should be considered STANDARD on
a mud, hehehe. At some point all those straggling muds should catch up.
: BTW, the system we have at Legend is the one I described in a previous
: post, where you can specify moods and tags are randomly selected from
: those that apply, as well as automatic parsing for multiple placements of
: speech tags. Tags like 'asks' are never assigned to the text by the
: server, you do it yourself. It does determine based on punctiuation
: whether to place it at start, end, or middle of a sentence.
Sounds good but I don't like the server to interpret what I say, even if
I do put in punctuation. Easy example:
Bob asks 'Do you think I'm dumb?'
Here the server replaced says with asks because bob put in a question mark
Bob glares at you and says 'Do you think I'm dumb?'
Here we have a completely different sentence. Giving the player the
ability to emote/say is quite powerful as far as expressing emotions.
Of course one might argue that by using emotes before and after the
above first question could produce the same effect. I think it's just
a matter of tastes. Perhaps it is something that should be able to
be toggled, so you can have the server flavor your communication if you
please.
: Optional system? We have it optional, where a person can have it but may
: turn it off. Because of current site constraints, we lack an introduction
: system. Thoughts on the need for those? ALso, we do not let those LOOKING
: turn them off as some like to use descs as a disguise system. Thoughts on
: that?
Explain further by the LOOKING flag (assuming that's what you mean). In
many cases I can see why a player might want to disguise themselves. How
about sneaking into a town if they are wanted? Disguise themseleves with
some sort of skill, people only recognize them if they roll a successful
test. Of course at this point we are talking about skills.
: cosmetic side of it. Internally pulses are what matter, and you can see
: people not getting any attacks in a 'round' or having pulses left over
: from a previous rounds and thus getting 2 attacks one round and 1 the
: next, predictably.
In other words, pulses are sped up rounds, and rounds are used just for
sending messages. Players do damage per round equal to the total damage
they did in the pulses of that round. I suppose it depends on how long
your rounds are supposed to represent in real time. Anways, I don't
think that combat in pulses, rounds, etc, can be considered state of the
art either way. What really matters is the mechanics behind it. I tend
to be of the school that the more you take into consideration for combat,
the more realistic you can simulate it. However, I don't think this
applies to every mud. If I was on a cartoon mud, who would care if it
'simulated combat in great detail'. All I'd care is that my anvil did
loads of damage to the wascilly wabbit (=
: I think that the question of how FAR a range missile weaons can have
: raises the question of how muds handle scale (see the interesting thread
: just started on modeling physical space, perhaps?). Firing through
: multiple rooms would be quite possible on our server, but we decided not
: to permit it because we have variable size rooms with no internal value
: for size that could be referenced. Hence one could, on Legend, fire a bow
: across the English Channel (high mv cost but few rooms, to alleviate the
: tedium of modeling the actual historical Earth to scale... be quite boring
: to write and to travel through as well).
Again, this is one excuse people can use for NOT implementing missile
weapons. The only thing you could possibly do to use missile weapons in
one room would be to have unused ammo be able to be collected. Though,
your assessment is correct in that the modelling of physical space is a
problem most muds never consider. One simple solution would be to use 3
variables for a room to represent height, width, and depth (or
north-south, east-west, up-down). This way each missile weapon could
take into account how big the room is, if it'd ever make it out of
the room, and how far it would go. This would in turn make certain
missile weapons more valuable, as throwing rocks wouldn't go nearly as
far as a heavy crossbow. Further, by having the 3 dimensions, you could
take into consideration volume of the room, so that 50 people couldn't
fit into a closet, while the entire mud could fit at the shore of the
beach. Something I'm implementing on my mud anways, to see how well it
works. *shrug*
: > One idea would be to give rooms
: > sizes, and limit the amount of volume that can occupy it.
: > Even
: > mobs should have some sort of size so that 10 people can't simultaneously
: > attack a roach.
: Interesting notion! Anyone done this? I'd be interested in seeing amud
: that implemented it fully.
Once I get out of alpha, I'll show you what I mean (=
: Why DO so few systems have them? Is it that big a deal to implement a
: detailed easy to use script language for a mud? Having looked at code for
: Valhalla's system, i find it very cumbersome for novice builders. World of
: Carnage's excellent acts system is much easier to handle, though I do not
: know if it is as powerful. (are they the first? Merc credits them as
: originators of the MOBprogs concept).
Well, it's hard to say. Perhaps people can implement simple script
systems, but many want much more. Could be a limitation on the way the
server is coded, especially if you are of the diku genre.
: > The same thing with built in
: > quests. If they are poorly designed, they are useless. What I do on my
: > mud is have the automated quests draw from a pool of ideas so that they
: > change constantly. If you come up with a new idea, throw it in the pool
: > and it gets added. Variety is the spice of life. Futher, you don't have
: > folks handing out tintin scripts to complete every quest on you mud (=
: Hmm, I'd be curious to know the nature of these quests. They sound like
: what we call 'fetch and carry' style quests. Our script system permits
: more complex interaction than that, including the performing of very
: specific actions (say, dance in a particular room during the night, while
: wearing a specific item, and having tossed the magical powder into the pit
: of the Volcano of Doom, and perhaps Gobbog the Demon will appear). Do your
: randomized automated quests have that sort of flexibility?
A few are 'fetch and carry', since these are easiest for beginners to
grasp. Some are 'protect', some are 'extract', some are a complicated
combination of these. By 'protect' I mean to escort and protect a
certain mob travelling from one place to another. This is another simple
type quest. By extract, I mean enter an area, and extract a certain
item. You have to take into consideration that breaking into a major
corporation is no easy task ;) On top of this, add the law, and players
don't want to spend time in the slammer, so quests become a little more
difficult than the average "go in with guns a blazing, and kill
everything that gets in your way". Another example of a quest is a
'manipulation' quest. This is what you described, and though it sounds
complex, the system supports this type to pretty easily. Obviously if
you have some of the variables randomized, you must make sure the choices
it can pick from are viable to the quest. Perhaps the only difficulty in
coding any of these is making these group quests. You have to be able to
make sure all the group members assist, or else 'Bob' sits at a bar,
while his group completes the quest, and then he gets credit. By adding
'checkpoints' throughout the quest, you can somewhat absolve this
problem. Further, by making teamwork necessary, one person can't
complete the quest for then entire group (ie, the decker turns off the
cameras on level 4, then turns off the elevator alarms, meanwhile, the
mage knocks out the security dogs and the group goes in through the back
enterance).
: Why do so few muds have it fully customizable?
Not sure.
[note to non-color muds]
If your mud doesn't have color, and you want it, email me, and
I'll send you a list of ansi-screen codes, and vt100 codes, so you can
put them in. It's really very easy (=
: Hmm. I admit to not having been thinking in that direction. Sounds like a
: partial incorporation of client software into the basic mud interface. How
: much is that a desirable goal (I realize now that everything in the
: interface category is exactly that)...
The only reason this should be done is for that reason. Not everyone has
access to client software. We don't have to care, but there are people
who legitimately need features such as this. See below for an explanation.
: Funny, we lack aliases on Legend purposely, finding that people use them
: to pay less attention to the game. But it's been challenged in the past on
: many grounds, including that it favors the client users.
While this may be true, there is one big group you are missing. I desire
to make my mud an experience for everyone. Contrary to popular belief,
there are handicap people out there who cannot mud because the interface
is so terrible. Aliases serve to help these people, as do actions, and
other such things we consider 'niceties'. Which brings me to another
point I want to rant about ;) If I see another mud that uses obscure
symbols to act as commands (ie, shift-characters), I'm gonna scream.
You'd think that 12 years after the first Infocom games came out, we'd
have parsers at least equal to those old games. There's a rule I just
thought up, and I can imagine it holds true:
The number of 'shift-characters' required in use with commands on a mud
is inversely proportional to the maximum number of players said mud can
obtain.
In other words, the more funky your commands are, the less people you
attract. Not everyone has time to read a 500 page manual describing the
commands used on your mud. If your mud is in english, PLEASE use
english. Same goes for any language. Diku is horrible for this:
get all.bread bag
Rather silly and ugly. Makes searching for multiple objects the easy,
but looks silly. Fine if you don't want all the extra prepositions such
as:
get all of the breads out of the bag
but at least allow this
get all breads bag
Just as easy from a parsing perspective.
: WHY is OLC state of the art on Dikus? I have never seen it done very well
: (decent editing, for example, seems beyond the reach of any muds that I
: have seen), and it also seems to me to limit the scope for script
: langages, as unles syou are very careful with memory protection or
: severely limit the script language, crashing the server with buggy scripts
: is quite possible. Aesthetically, I have also found that OLC tends to
: produce poorer written areas, not to mention more gridlike ones as
: generally speaking the ability to rearrange the map on the fly is lacking.
OLC is state of the art on dikus because they don't come with any sort of
OLC to begin with. And yes, most versions I've seen suck (= It's a
problem with the way dikus are generally coded, which is horribly ;).
Let's face it, the easiest mud out there to run is a diku mud. You don't
have to learn anything new to run it, it's not complicated, and if you
know C, you can add to it fairly easy. One big lack of dikus is the
ability to create on line. This is not necessarily a feature one may
want though, so I suppose we can't complain too much. However, what do
you use on an lp mud? Ed (generally) yek! You use ed to write lpc,
which is a funkified form of C. Is this more acceptable? For an lp-mud
yes, because you have much greater flexibility in objects, however you
introduce another problem most dikus don't experience, and that is
security issues. Dikus don't have to worry, because players in no way
have access to the code that makes the mud tick, like you do in an lp.
If something is coded wrong in an lp, you can really screw things up.
Again, the flip side is that dikus have basically no object flexibility
unless hard coded in, and errors crash the mud in general (well they
don't have to, but few put in the necessary checks).
: A huge issue: can any sort of ecological system (my term for what you are
: describing) survive without some sort of oversight or maintenance? Or for
: that matter, without a minimum base of players to provide a functioning
: economy? What happens when you have a system of 50 consumers and no
: producers? Or of 50 deer killers that kill all the deer until the species
: is EXTINCT?
If npcs play a role, you could theoretically have 0 players and have the
system work. But just as the world works, there seems to be a need for
everything to have a balance. Everything should be cause and effect.
You'd definately need some sort of maintenance at the outset. I guess I
just don't know, no one has really set up an ecological system to that
degree. Time to find out ;)
CJD
leg...@dbtech.net
(Christopher J. Dickey) wrote:
> Perhaps we need a thread describing what should be considered STANDARD on
> a mud, hehehe. At some point all those straggling muds should catch up.
I'd sort of hoped people would do so in this thread, but none did. :P
I said:
> : BTW, the [speech] system we have at Legend...
> : ...you can specify moods and tags are randomly selected from
> : those that apply... multiple placements of
> : speech tags. Tags like 'asks' are never assigned to the text by the
> : server, you do it yourself. It does determine based on punctiuation
> : whether to place it at start, end, or middle of a sentence.
>
> Sounds good but I don't like the server to interpret what I say, even if
> I do put in punctuation. Easy example:
>
> Bob asks 'Do you think I'm dumb?'
> Here the server replaced says with asks because bob put in a question mark
>
> Bob glares at you and says 'Do you think I'm dumb?'
> Here we have a completely different sentence. Giving the player the
> ability to emote/say is quite powerful as far as expressing emotions.
> Of course one might argue that by using emotes before and after the
> above first question could produce the same effect. I think it's just
> a matter of tastes. Perhaps it is something that should be able to
> be toggled, so you can have the server flavor your communication if you
> please.
*nod* I don't like it either. What I am talking about is this:
Goober types: HAPPY SAY HELLO! WELCOME TO MY HUMBLE DOMAIN.
Others see: 'Hello!' Goober says happily. 'Welcome to my humble domain.'
The location of 'Goober says happily' varies randomly, and in fact 'says
happily' can vary as well, to such things as 'says, eyes twinkling'
(actually, I think that one is for 'amused' mood, not 'happy').
We've got 150+ moods and each has 3 tags with it...
I said, regarding aplayer description system:
> : ...We have it optional, where a person can have it but may
> : ...ALso, we do not let those LOOKING
> : turn them off as some like to use descs as a disguise system.
> Explain further by the LOOKING flag (assuming that's what you mean). In
> many cases I can see why a player might want to disguise themselves. How
> about sneaking into a town if they are wanted? Disguise themseleves with
> some sort of skill, people only recognize them if they roll a successful
> test. Of course at this point we are talking about skills.
Not a flag--literally, those in the room who look. And yes, a disguise
skill was part of the design for the player desc system on Legend.
> : cosmetic side of it. Internally pulses are what matter, and you can see
> : people not getting any attacks in a 'round' or having pulses left over
> : from a previous rounds and thus getting 2 attacks one round and 1 the
> : next, predictably.
>
> In other words, pulses are sped up rounds, and rounds are used just for
> sending messages. Players do damage per round equal to the total damage
> they did in the pulses of that round.
Not sped up rounds, unless rounds without nobody attacking are normal wher
eyou come from. :) But yes, players do damage per 'round' (which just
means when messages are sent) equal to whatever happened since the last
message was sent. *chuckle* Not much way around that no matter WHAT you
do, the point of messages is to report damage since the last message.
> I suppose it depends on how long
> your rounds are supposed to represent in real time. Anways, I don't
> think that combat in pulses, rounds, etc, can be considered state of the
> art either way. What really matters is the mechanics behind it. I tend
> to be of the school that the more you take into consideration for combat,
> the more realistic you can simulate it. However, I don't think this
> applies to every mud. If I was on a cartoon mud, who would care if it
> 'simulated combat in great detail'. All I'd care is that my anvil did
> loads of damage to the wascilly wabbit (=
Except that targeting particular fingers on a hand gets unbearably tedious
in actual game play. Which is why people make compromises. Right now in
fights we model physical abilities, skills with given types of weaponry,
quality of weaponry, weight of weaponry, attack speed... We're essentially
a skill and stat based system, and it is concentration in skills and stats
that makes you special with a weapon, and even gets you faster attacks at
all.
> : I think that the question of how FAR a range missile weaons can have
> : raises the question of how muds handle scale (see the interesting thread
> : just started on modeling physical space, perhaps?). Firing through
> : multiple rooms would be quite possible on our server, but we decided not
> : to permit it because we have variable size rooms with no internal value
> : for size that could be referenced. Hence one could, on Legend, fire a bow
> : across the English Channel (high mv cost but few rooms, to alleviate the
> : tedium of modeling the actual historical Earth to scale... be quite boring
> : to write and to travel through as well).
> Again, this is one excuse people can use for NOT implementing missile
> weapons. The only thing you could possibly do to use missile weapons in
> one room would be to have unused ammo be able to be collected.
Not at all. First off all, we DO have missile weapons. :) Just they only
fire into one adjacent room rather than traveling great distances. There
is no way of representing everything from rifles to slingshots to longbows
to cannon with accurate ranges on a mud that does not use scale in its
rooms. And I don't know of many that do.
> Though,
> your assessment is correct in that the modelling of physical space is a
> problem most muds never consider. One simple solution would be to use 3
> variables for a room to represent height, width, and depth (or
> north-south, east-west, up-down). This way each missile weapon could
> take into account how big the room is, if it'd ever make it out of
> the room, and how far it would go. This would in turn make certain
> missile weapons more valuable, as throwing rocks wouldn't go nearly as
> far as a heavy crossbow. Further, by having the 3 dimensions, you could
> take into consideration volume of the room, so that 50 people couldn't
> fit into a closet, while the entire mud could fit at the shore of the
> beach. Something I'm implementing on my mud anways, to see how well it
> works. *shrug*
You should read the ongoing thread on modelling physical space. :) There
are huge problems with all the approaches I have seen. In the case of the
one you are citing, you better have someone doing very careful firm
oversight of the building if you hope to maintain a straightforward
Euclidean geometry. You'll get rooms overlapping in no time. You will also
have to deal with the possibility of multiple exits in the same direction,
which means named exits rather than cardinal directions, unless you can
think of some other interface for it. Or, perhaps a continuously modelled
space... in any case, something for the other thread.
> : Why DO so few systems have them? Is it that big a deal to implement a
> : detailed easy to use script language for a mud? Having looked at code for
> : Valhalla's system, i find it very cumbersome for novice builders. World of
> : Carnage's excellent acts system is much easier to handle, though I do not
> : know if it is as powerful. (are they the first? Merc credits them as
> : originators of the MOBprogs concept).
> Well, it's hard to say. Perhaps people can implement simple script
> systems, but many want much more. Could be a limitation on the way the
> server is coded, especially if you are of the diku genre.
We are. *shrug* Sadist coded an acts system that is fully recursive, with
pre-emptive and co-operative multitasking, and event queues for each mob
with acts. Interacts fully with rooms and can alter the in-memory database
on the fly. Easily learned and easy to use, goes directly with the mobile
or room in the area file. Quite powerful. We don't use any C spec procs in
Legend at all, and implement dozens of quests in acts, alter mobiles upon
loading to tailor names and appearances, control the Out Of Character
lounge and the clan halls with it, run automated recall tag with it...
[questions about his script system and quests snipped]
> A few are 'fetch and carry', since these are easiest for beginners to
> grasp. Some are 'protect', some are 'extract', some are a complicated
> combination of these. By 'protect' I mean to escort and protect a
> certain mob travelling from one place to another. This is another simple
> type quest. By extract, I mean enter an area, and extract a certain
> item. You have to take into consideration that breaking into a major
> corporation is no easy task ;) On top of this, add the law, and players
> don't want to spend time in the slammer, so quests become a little more
> difficult than the average "go in with guns a blazing, and kill
> everything that gets in your way". Another example of a quest is a
> 'manipulation' quest. This is what you described, and though it sounds
> complex, the system supports this type to pretty easily. Obviously if
> you have some of the variables randomized, you must make sure the choices
> it can pick from are viable to the quest. Perhaps the only difficulty in
> coding any of these is making these group quests. You have to be able to
> make sure all the group members assist, or else 'Bob' sits at a bar,
> while his group completes the quest, and then he gets credit. By adding
> 'checkpoints' throughout the quest, you can somewhat absolve this
> problem. Further, by making teamwork necessary, one person can't
> complete the quest for then entire group (ie, the decker turns off the
> cameras on level 4, then turns off the elevator alarms, meanwhile, the
> mage knocks out the security dogs and the group goes in through the back
> enterance).
There are many tactics for good group quest design... I wrote a couple
thousand words on the subject the other day, but I dont' feel like
repeating myself :)
> : Funny, we lack aliases on Legend purposely, finding that people use them
> : to pay less attention to the game. But it's been challenged in the past on
> : many grounds, including that it favors the client users.
>
> While this may be true, there is one big group you are missing. I desire
> to make my mud an experience for everyone. Contrary to popular belief,
> there are handicap people out there who cannot mud because the interface
> is so terrible. Aliases serve to help these people, as do actions, and
> other such things we consider 'niceties'.
*nod* I am quite sure there are. Yet it DOES impact upon game play. Giving
everyone access to quick and easy ways of doing things will mean they
still leave the handicapped in the dust :(
> Which brings me to another
> point I want to rant about ;) If I see another mud that uses obscure
> symbols to act as commands (ie, shift-characters), I'm gonna scream.
> You'd think that 12 years after the first Infocom games came out, we'd
> have parsers at least equal to those old games. There's a rule I just
> thought up, and I can imagine it holds true:
>
> The number of 'shift-characters' required in use with commands on a mud
> is inversely proportional to the maximum number of players said mud can
> obtain.
>
> In other words, the more funky your commands are, the less people you
> attract. Not everyone has time to read a 500 page manual describing the
> commands used on your mud. If your mud is in english, PLEASE use
> english. Same goes for any language. Diku is horrible for this:
>
> get all.bread bag
>
> Rather silly and ugly. Makes searching for multiple objects the easy,
> but looks silly. Fine if you don't want all the extra prepositions such
> as:
>
> get all of the breads out of the bag
>
> but at least allow this
>
> get all breads bag
>
> Just as easy from a parsing perspective.
Very true. I want to go change that myself :) I can only think of one
shift character we use--no, two. We can do 3*(command) to repeat something
that many times, and we can do the usual ! to repeat something.
I said:
> : WHY is OLC state of the art on Dikus? I have never seen it done very well
> : (decent editing, for example, seems beyond the reach of any muds that I
> : have seen), and it also seems to me to limit the scope for script
> : langages, as unles syou are very careful with memory protection or
> : severely limit the script language, crashing the server with buggy scripts
> : is quite possible. Aesthetically, I have also found that OLC tends to
> : produce poorer written areas, not to mention more gridlike ones as
> : generally speaking the ability to rearrange the map on the fly is lacking.
>
> OLC is state of the art on dikus because they don't come with any sort of
> OLC to begin with. And yes, most versions I've seen suck (= It's a
> problem with the way dikus are generally coded, which is horribly ;).
...
> If something is coded wrong in an lp, you can really screw things up.
> Again, the flip side is that dikus have basically no object flexibility
> unless hard coded in, and errors crash the mud in general (well they
> don't have to, but few put in the necessary checks).
The same problem with coding wrong can easily happen on dikus with a
powerful script langage (In fact, oddly, all the script languages I know
the most about are ON Dikus. Wonder why).
Brandon Van every
>> Similarly having told them that a lot of MUDs emphasise fighting, saying
>> that you can *gasp* shoot an arrow from one location to another seems
>> a little silly.
>>
>> But then why do so few MUDs support this feature?
>I asked this a while ago and nobody answered. :)
It's probably that old bugaboo of software reuse/compatibility.
People are so busy "innovating" that nobody can agree on the ANSI
standard mud. :-)
Cheers,
Brandon
root
<leg...@dbtech.net> wrote:
>> Having told someone they are games which many players can play at once,
>> it seems to be unnecessary to tell them you can talk to other players.
>> that you can *gasp* shoot an arrow from one location to another seems
>> a little silly.
>>
>> But then why do so few MUDs support this feature?
>
>
>I asked this a while ago and nobody answered. :)
>
Maybe cause most muds dont like it when a newbie can kill the strongest
monsters around by just standing outside and shooting arrows in?
It will only really work if it is a PK only mud, or if it only works for pk.
(Being able to kill monsters without being hit will unbalance a mud strongly,
unless the average balance of that mud is even worse already, in which case
you can better ditch the whole crap and start all over again.)
root
Travis S Casey
>>> Having told someone they are games which many players can play at once,
>>> it seems to be unnecessary to tell them you can talk to other players.
>>> Similarly having told them that a lot of MUDs emphasise fighting, saying
>>> that you can *gasp* shoot an arrow from one location to another seems
>>> a little silly.
>>>
>>> But then why do so few MUDs support this feature?
>
>monsters around by just standing outside and shooting arrows in?
>It will only really work if it is a PK only mud, or if it only works for pk.
>(Being able to kill monsters without being hit will unbalance a mud strongly,
> unless the average balance of that mud is even worse already, in which case
> you can better ditch the whole crap and start all over again.)
This is why any mud which *does* have ranged weapons should change
their monsters to account for this fact. On SWmud, wizards have
several options about what to do with their monsters to account
for ranged weapons:
1. They can give the monsters ranged weapons, so that they can
shoot back.
2. Any monster that doesn't have a ranged weapon and isn't set
up to do something else when shot at will begin "dodging"
while staying in its room. This lowers the chance to hit
a great deal, making it at least take longer. The monster
continues to dodge until someone engages it in melee combat.
3. Monsters can be set up to charge; that is, if someone starts
firing at them from a distance, they move directly to that
character and attack.
4. Monsters can be set up to do a moving dodge. That is, when
someone fires at them, they will try to move at a right angle
to the direction of fire. Should this be impossible, they
will dodge as in (2) above.
Other options are of course possible; these are the ones that
are pre-built and can be added to a monster with no more than
two extra lines of code (except for 2, which is built-in to
all monsters and requires no extra code).
IMHO, one of the dumbest things that a lot of muds do is give
players access to special abilities, like ranged weapons and
healing, while not giving them to monsters. Thus, I've also
set up code which allows monsters that have medical supplies
to heal themselves when not in combat, and other such things
that drive players used to "dumb" monsters crazy. :-)
Mark Clements
> >> Having told someone they are games which many players can play at once,
> >> it seems to be unnecessary to tell them you can talk to other players.
> >> Similarly having told them that a lot of MUDs emphasise fighting, saying
> >> that you can *gasp* shoot an arrow from one location to another seems
> >> a little silly.
> >>
> >> But then why do so few MUDs support this feature?
> >
> >
> >I asked this a while ago and nobody answered. :)
> >
>
> Maybe cause most muds dont like it when a newbie can kill the strongest
> monsters around by just standing outside and shooting arrows in?
So how about having the monster you shoot come chasing you after you
have shot it. Doesn't that make some sort of sense?
I find it an odd concept that someone stays in one place whilst being
shot at, without either retaliating or running away.
But then, in a world where it can take 20 hits with a sword to kill
a frog, there is very little to surprise me.
--
(Happiness can't buy you money)
leg...@dbtech.net
I said, regarding missile weapons firing more than one room:
> >> But then why do so few MUDs support this feature?
> Maybe cause most muds dont like it when a newbie can kill the strongest
> monsters around by just standing outside and shooting arrows in?
> It will only really work if it is a PK only mud, or if it only works for pk.
> (Being able to kill monsters without being hit will unbalance a mud strongly,
> unless the average balance of that mud is even worse already, in which case
> you can better ditch the whole crap and start all over again.)
Good Lord, that only happens if your mobs just stand there and take it.
Ours rush at you and attack you, and even that doesn't satisfy me, I'd
like those capable to start shooting back, take cover, etc. They can in
acts, but I'd like to have a little more automatic brain. :) There's no
reason to leave it at the situation you describe.
-Ptah@Legend
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
LegendMUD : the world the way they thought it was
bashful.cc.utexas.edu 9999 -=- 128.83.108.17 9999
http://www.cs.cmu.edu:8001/Web/People/johnmil/legend/legend.html
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Michael Sellers
: In article <legend-0408...@ppp24.dbtech.net>,
: <leg...@dbtech.net> wrote:
: >> Having told someone they are games which many players can play at once,
: >> it seems to be unnecessary to tell them you can talk to other players.
: >> Similarly having told them that a lot of MUDs emphasise fighting, saying
: >> that you can *gasp* shoot an arrow from one location to another seems
: >> a little silly.
: >> But then why do so few MUDs support this feature?
: >I asked this a while ago and nobody answered. :)
: >
: Maybe cause most muds dont like it when a newbie can kill the strongest
: monsters around by just standing outside and shooting arrows in?
: It will only really work if it is a PK only mud, or if it only works for pk.
: (Being able to kill monsters without being hit will unbalance a mud strongly,
: unless the average balance of that mud is even worse already, in which case
: you can better ditch the whole crap and start all over again.)
Your scenario assumes the monster isn't smart enough to come attackt he
newbie that is peppering it wtih missiles (and that the newbie is able to
hit and damage this monster!).
Which leads me to another SoA topic: NPC scripting. How many muds do
this beyond a real rudimentary level? What do you think is SoA for NPC
scripting? I have some definite thoughts on this, but I'd like to ehar
from others. (And I *was* goig to discuss this offline with Ptah, but
now I can't... :-P ).
--
Michael Sellers Terra Nova Interactive Corp. mi...@terranova.com
(503) 538-2745 FAX (503) 538-9517 http://www.terranova.com/~sellers
Email me for info on UI Design seminars: 2-5 days, in-house or public
Martian
++>> Having told someone they are games which many players can play at once,
++>> it seems to be unnecessary to tell them you can talk to other players.
++>> Similarly having told them that a lot of MUDs emphasise fighting, saying
++>> that you can *gasp* shoot an arrow from one location to another seems
++>> a little silly.
++>>
++>> But then why do so few MUDs support this feature?
++>
++>
++>I asked this a while ago and nobody answered. :)
++>
++Maybe cause most muds dont like it when a newbie can kill the strongest
++monsters around by just standing outside and shooting arrows in?
++It will only really work if it is a PK only mud, or if it only works for pk.
++(Being able to kill monsters without being hit will unbalance a mud strongly,
++ unless the average balance of that mud is even worse already, in which case
++ you can better ditch the whole crap and start all over again.)
I think the real reason is that 95% of the muds pick a driver and a
mudlib and start. Since none of the popular mudlibs seems to support
this feature, most muds won't get it. If you are creative enough, you
can have a newbie shooting arrows to a high monster from an outside
room, and still not make much chance. But creativity is not found much
in the mudworld these days.
Abigail
Chris Gray
> >>
> >> But then why do so few MUDs support this feature?
>
Probably because it's a pain to specify:
fire arrow at Fred who is to the north
[Mud code follows 'north' links, looking for something called "Fred".]
[Mud code has to figure out if the arrow hits. How far is too far? Is]
[there some kind of "distance" concept built into the mud? Do all]
[builders have to specify how far it is along every link they setup?]
I suspect that if you presented the idea to a typical mudlib builder,
they would say it isn't worth it. It doesn't add enough to the game to
outweigh the cost and complexity of adding it.
--
Chris Gray c...@ami-cg.GraySage.Edmonton.AB.CA
Martian
++Which leads me to another SoA topic: NPC scripting. How many muds do
++this beyond a real rudimentary level? What do you think is SoA for NPC
++scripting? I have some definite thoughts on this, but I'd like to ehar
++from others. (And I *was* goig to discuss this offline with Ptah, but
++now I can't... :-P ).
I don't think the scripting technique itself is hard to do. I've
implemented it a few times, and the basic principle is using an array
of commands, and letting the NPC do the first command of the array
each heart_beat. Starting from there, it's easy to place hooks which
call functions in the NPC itself to do special cases, or load new
commands. (i.e. when fighting, you call every few heartsbeats a
function which let the NPC check its hitpoints, letting it flee and
heal when it's low, and letting it cast some spells if not).
Much more complicate is it to let the NPC make sensible reactions on
what a player does and says. Trying to make sense out of natural
language isn't easy. :(
Abigail
Ed Snible
>Which leads me to another SoA topic: NPC scripting. How many muds do
>this beyond a real rudimentary level? What do you think is SoA for NPC
>scripting? I have some definite thoughts on this, but I'd like to ehar
>from others. (And I *was* goig to discuss this offline with Ptah, but
>now I can't... :-P ).
I don't think any MUDs do this beyond a rudimentary level. I've looked
all over the Internet, at least, and I can't find it. Some interesting
WWW pages on the topic are:
TinyMUD bot that is entered into AI competitions and pretends it is human
http://fuzine.mt.cs.cmu.edu/mlm/julia.html
OZ project to develop AI cartoon characters for story telling
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/oz/web/oz.html
Miscellenous graphical MUD, MUD AI, and DIKU editor links
http://www.goodnet.com/~esnible/mudinfo.html
Maur the dragon
telnet://debra.dgbt.doc.ca:3000
I think that the standard MOBprograms are decent for picking up key words
and actions, and I think LegendMUD has extended that with some kind of
system where the mobile keeps internal variables.
I think the next step is going to be a system where keywords and a few local
state variables are put into a 'grab bag' and can be combined for a mobile,
so that mobiles can be created as "BasicShopkeeper+Baking+TalkAboutWeather".
I think that mobiles will be taught to hunt and remember more things. I
think that we WON'T see mobiles that a player can carry on a conversation
with until we see business applications with "Intelligent Agents", because
agents seems to be what people are actually researching full-time.
Slash
esn...@goodnet.com
Brandon Van every
[about shooting arrows]
>Maybe cause most muds dont like it when a newbie can kill the strongest
>monsters around by just standing outside and shooting arrows in?
>It will only really work if it is a PK only mud, or if it only works for pk.
>(Being able to kill monsters without being hit will unbalance a mud strongly,
> unless the average balance of that mud is even worse already, in which case
> you can better ditch the whole crap and start all over again.)
I don't understand your reasoning here. What's to stop a monster from
being coded to shoot back?
Travis S Casey
>> >> Similarly having told them that a lot of MUDs emphasise fighting, saying
>> >> that you can *gasp* shoot an arrow from one location to another seems
>> >> a little silly.
>> >>
>> >> But then why do so few MUDs support this feature?
>>
>> >I asked this a while ago and nobody answered. :)
>
>Probably because it's a pain to specify:
>
> fire arrow at Fred who is to the north
With that kind of a syntax, yes it would be a pain, just as having
to type "attack Fred with sword in my right hand" instead of "kill
fred" would be a pain. On SWmud, our ranged weapon syntax is like
this: "fire fred north". Just one more word than "kill fred"
> [Mud code follows 'north' links, looking for something called "Fred".]
> [Mud code has to figure out if the arrow hits. How far is too far? Is]
> [there some kind of "distance" concept built into the mud? Do all]
> [builders have to specify how far it is along every link they setup?]
Following links north is trivial; any mud which has lpeer or a similar
command to look multiple rooms in a given direction already has the
code to do it. Looking for something called "Fred" in a room is also
trivial; this has to be done when you type "kill fred" as well.
Figuring out whether the arrow hits is fairly trivial as well; the
hardest part there is deciding how to calculate the hit probability.
Distance is the worst part of a ranged weapon system. On SWmud, we
use rooms as a measure of distance, and encourage our builders not
to make giant rooms for outdoor areas (we encourage them to use
virtual areas for big outdoor stuff).
>I suspect that if you presented the idea to a typical mudlib builder,
>they would say it isn't worth it. It doesn't add enough to the game to
>outweigh the cost and complexity of adding it.
Cost and complexity? A decent mudlib coder should be able to make
a working ranged weapon system in under a week, easy. I'm sure that
I could write one from scratch in less than a day, but then, I've
worked on a working system already, so I know what needs to be done.
How much it adds to the game is a matter of opinion; our players
seem to like it, and I do too. :-)
IMHO, the hardest thing about adding a ranged weapon system is
rewriting the monsters to account for it. Once you've added
ranged weapons, you need to make monsters be able to shoot back,
dodge, or do other actions so that they don't just stand there
and let someone one room away slowly kill them with a bow.
Paul Wouters
>I think that mobiles will be taught to hunt and remember more things. I
>think that we WON'T see mobiles that a player can carry on a conversation
>with until we see business applications with "Intelligent Agents", because
>agents seems to be what people are actually researching full-time.
The problem with mobiles being very smart in hunting a player down is
that it is not visible to the player. For istance, creating a 'master
police agent' with 10 deputies, who automaticly map the area and report
to the master, and then zoom in quickly when they find a suspect is a
very good and neat piece of code, but a player will only see a policeman,
move franticlly through some rooms and encounter more of them. He doesn't
know the nifty backtracking algorithms used to simulate RL.
Interesting projects, but not for muds that are being used as a
game/meeting ground.
Paul
--
Say a prayer for me, help me to feel the strength I did
My identity, has it been taken, is my heart breaking on me
All my plans, they fell through my hands, they fell through my hands
All my dreams, it suddenly seems.....Empty - The Cranberries
Travis Casey
>esn...@goodnet.com (Ed Snible) writes:
>
>>I think that mobiles will be taught to hunt and remember more things. I
>>think that we WON'T see mobiles that a player can carry on a conversation
>>with until we see business applications with "Intelligent Agents", because
>>agents seems to be what people are actually researching full-time.
>
>The problem with mobiles being very smart in hunting a player down is
>that it is not visible to the player. For istance, creating a 'master
>police agent' with 10 deputies, who automaticly map the area and report
>to the master, and then zoom in quickly when they find a suspect is a
>very good and neat piece of code, but a player will only see a policeman,
>move franticlly through some rooms and encounter more of them. He doesn't
>know the nifty backtracking algorithms used to simulate RL.
Well, depending on the mud setup, it can be easier than that. For example,
Nightmare (at least 3.x, I haven't looked at IV) has tracks in each room.
You can query a room to see if someone has been here and what direction
they left in.
With a system like that, our hypothetical policeman can simply wander until
it finds the track of the player it's looking for, then follow it. This is,
of course, easier and less CPU and memory-intensive than using backtracking
algorithms.
However, I agree with the previous poster than "off-stage" activities do not
have to be handled as if they were occurring where players could see them.
Another method to handle this would be to have the police officer move around
randomly until it had completed a few moves (say, 4) without encountering
anyone, and then have it teleported to an empty room adjacent to the player
being tracked, then move normally into the player's room.
Using this method, it would appear as if the police had been searching for the
player and then found him. Of course, the illusion wouldn't be perfect, since
people might notice officers disappearing from areas with no way out but past
a player, but it would be fairly good, and *much* easier than doing a real
search for the player.
Peter Waltenberg
>>> Similarly having told them that a lot of MUDs emphasise fighting, saying
>>> that you can *gasp* shoot an arrow from one location to another seems
>>> a little silly.
>>>
>>> But then why do so few MUDs support this feature?
>>I asked this a while ago and nobody answered. :)
>It's probably that old bugaboo of software reuse/compatibility.
>People are so busy "innovating" that nobody can agree on the ANSI
>standard mud. :-)
In our case it's a straight forward problem of game balance, we have ranged
weapons coded and working, we just can't use them yet, nothing quite like
getting an arrow through your back while you are reading mail. Yeah that can
be got round, but the actual weapon code is easy compared to solving all the
little "bugs" it causes.
PeterW
Ed Snible
>
>esn...@goodnet.com (Ed Snible) writes:
>The problem with mobiles being very smart in hunting a player down is
>that it is not visible to the player. For istance, creating a 'master
>police agent' with 10 deputies, who automaticly map the area and report
>to the master, and then zoom in quickly when they find a suspect is a
>very good and neat piece of code, but a player will only see a policeman,
>move franticlly through some rooms and encounter more of them. He doesn't
>know the nifty backtracking algorithms used to simulate RL.
If I was going to have the city guards coordinate a search for the player
who had just looted the city treasury, I would have them YELL to the other
guards in the zone the current location of the player.
There are a lot of really easy things to do to make the mobiles appear more
'intelligent'. For example, one of the things that players like to do is
find some mob with good armor and kill him and either take it or sell it.
Now, if mobiles were programmed to kill any player with better eq than the
mobile that they thought they could take and then either wear it or sell it
a lot of players would think that was really cool. However, it would totally
wreck the game of players who have their high-level buddies give them super
high level equipment and send them off to kill kobolds, and that probably
isn't acceptable to a lot of MUDs.
Brandon Van every
>In article <409qor$7...@kelly.teleport.com>, sel...@teleport.com says...
>>Which leads me to another SoA topic: NPC scripting. How many muds do
>>this beyond a real rudimentary level? What do you think is SoA for NPC
>>scripting? I have some definite thoughts on this, but I'd like to ehar
>>from others. (And I *was* goig to discuss this offline with Ptah, but
>>now I can't... :-P ).
>I don't think any MUDs do this beyond a rudimentary level. I've looked
>all over the Internet, at least, and I can't find it. Some interesting
>WWW pages on the topic are:
>I think that mobiles will be taught to hunt and remember more things. I
>think that we WON'T see mobiles that a player can carry on a conversation
>with until we see business applications with "Intelligent Agents", because
>agents seems to be what people are actually researching full-time.
I don't think we'll see any significant advances in robotry until
mudders are _forced_ to accept Mimics as first-class citizens in their
universes. People are very afraid of anything that imitates human
behavior, or fools people into thinking that they've had a
conversation with something that is "false" or "misrepresented." It
plays havoc with their sense of personal identity and personal
boundaries.
Gads, it's like something out of an Isaac Asimov novel....
Ian Macintosh
: >I think that mobiles will be taught to hunt and remember more things. I
: >think that we WON'T see mobiles that a player can carry on a conversation
: >with until we see business applications with "Intelligent Agents", because
: >agents seems to be what people are actually researching full-time.
: The problem with mobiles being very smart in hunting a player down is
: police agent' with 10 deputies, who automaticly map the area and report
: to the master, and then zoom in quickly when they find a suspect is a
: very good and neat piece of code, but a player will only see a policeman,
: move franticlly through some rooms and encounter more of them. He doesn't
: know the nifty backtracking algorithms used to simulate RL.
Heh. The answer I feel lies in your last few words. Simulate RL.
Depending on the timezone you are simulating, you would use either
'shouting' by the various agents, or a 'radio'.
Let's assume D&D barbarian times. Player Sneaky commits a crime by
stealing from another player, Innocent.
Innocent gets a saving throw against the theft, and being successful,
shouts 'Sneaky is a thief. (He/She/It) just tried to steal from me.'
The code triggers the appropriate field/property on the law enforcement
agency mobiles in the close vicinity. Your code elects one of them to go
and report to the local controller/lieutenant/commander. He/she then
walks to the office, and reports verbatim. Any player in that location
will hear the 'conversation'.
The lieutenant issues a warrant of execution, which the agent then
carries back to the executioner. He/she reports verbatim again, and any
player there will hear the second 'conversation'.
The agents quickly move to block the city exits, and start a co-ordinated
sweep of the city. You could even have the agents report that Sneaky
must have slipped out, but will be watched for at the gates.
If properly implemented, you will soon see the 'chat' channel filled with
warnings, laughter, advice, etc as Sneaky is told what's happening.
Players will quickly appreciate the reality simulation, and, if you have
done your homework, you'll generate tons of fun as players attempt to
circumvent your 'code' by trying to kill the lieutenant, steal the
warrant, ambush the agent on the way to the executioner, etc.
Regards,
Ian.
Sebastian Andersson
>In our case it's a straight forward problem of game balance, we have ranged
>weapons coded and working, we just can't use them yet, nothing quite like
>getting an arrow through your back while you are reading mail. Yeah that can
>be got round, but the actual weapon code is easy compared to solving all the
>little "bugs" it causes.
The biggest problem is that muds that are not designed for ranged weapons
have to get a new world in order to have them... Simple things like guards
that cover a door might need a friend that can guard the door while they run
after people with bows. Directions have to be two way exits in order for people
to be able to shot back. Mobiles need to look around much more to be able to
shoot at their enemies.
There is also the thing with muds that are affraid of letting players
attack each other... How can they control the arrows to such a degree that
you don't hit a player next to a mobile? Well, that is probably not a problem
since they just add another completly illogical thing to the game.
/Sebastian
--
---> Play DUMII with "telnet dum.ts.umu.se 2001" at your nearest computer. <---
OB DISCLAIMER: Pepsi, the Devil, made me do it.
Travis S Casey
>In <p.waltenberg....@irl.cri.nz> p.walt...@irl.cri.nz (Peter Waltenberg) writes:
>
>>In our case it's a straight forward problem of game balance, we have ranged
>>weapons coded and working, we just can't use them yet, nothing quite like
>>getting an arrow through your back while you are reading mail. Yeah that can
>>be got round, but the actual weapon code is easy compared to solving all the
>>little "bugs" it causes.
>
>The biggest problem is that muds that are not designed for ranged weapons
>have to get a new world in order to have them... Simple things like guards
>that cover a door might need a friend that can guard the door while they run
>after people with bows. Directions have to be two way exits in order for people
>to be able to shot back. Mobiles need to look around much more to be able to
>shoot at their enemies.
I wouldn't call that a new world... I'd call it a slight redesign
of the existing one. The *best* way to put in ranged weapons is
to do it when the mud is initially being set up, before any areas
are built. That way, all area coders can design their areas with
ranged weapons in mind. Unfortunately, most muds operate on a
"tack it on" method; they bring up a mud using a standard setup,
start building areas, and don't worry about putting in new races,
guilds, object types, etc until after things are up and running
with several areas.
Still, all these problems are surmountable, if the wizards don't
mind having to modify their areas a bit. For a major change like
adding ranged weapons, it would probably be best to close the
mud for a week or so, to give wizards an opportunity to make
changes. (That is, if you're working with a mud that doesn't
have to be shut down to modify it).
>There is also the thing with muds that are affraid of letting players
>attack each other... How can they control the arrows to such a degree that
>you don't hit a player next to a mobile? Well, that is probably not a problem
>since they just add another completly illogical thing to the game.
How is this any more illogical than the fact that two character
in melee with the same mobile never accidentally hit the other
character? If you've ever seen inexperienced people try to
fight in a group with weapons, you'll know that it's not uncommon
for this to happen.
For that matter, how do you know when a character is next to a
mobile? All the muds I've seen use room/area-based movement,
so that all you know is that the two are in the same space.
Unless that space is very small, you can't assume that the
character is "next to" the mobile (unless they're in melee...
then it would be a safe assumption).
As you pointed out, though, many things on muds are already
illogical; however, people only seem to notice illogical things
that inconvenience them or that are new. Is it logical that
it's impossible to kill most humans on most muds with a single
sword blow? Is it logical that characters can heal themselves
by drinking alcohol on many muds? Is it logical that a
character can walk around carrying a sword, wearing armor,
and carrying another sword and another set of armor without
having a bag or backpack, and even fight while carrying all
that? Of course not. But people don't usually care about
these kinds of illogical things; they care about the ones
that limit them somehow.
Ah, well... I'm venting. It's just human nature to notice
the things that limit you, and not pay attention to the
things that don't.
oemlen
>these kinds of illogical things; they care about the ones
>that limit them somehow.
Very, *very* true. I would like to hear some other ideas about the
ultimate 'state of the art' mud. I will be opening Midpoint Void on
August 28th or thereabouts, and would like input. I feel like the mud
is fairly state-of-the-art, but I am always looking for ways to improve.
BTW, ranged weapons are in and working, but have been posponed until I
decide the invention has been accomplished by the inhabitants of the mud
:) Anyway, probably sounds lame to most, but if you give everyone
everything right away, it gets dull fast. I'd like to know other ideas
that would allow a player to get away from the regular hack-n-slash. If
quests, how do you handle them? Anyway, any input would be appreciated.
...And if anyone has a temporary site from now until the 27th of August,
I would love to talk to you :) Mudstats: 6-9meg mem, 10-25meg disk.
Thank you,
Owen Emlen
(Aka Orin)
Travis Casey
>>that? Of course not. But people don't usually care about
>>these kinds of illogical things; they care about the ones
>>that limit them somehow.
>
>Very, *very* true. I would like to hear some other ideas about the
>ultimate 'state of the art' mud. I will be opening Midpoint Void on
>August 28th or thereabouts, and would like input. I feel like the mud
>is fairly state-of-the-art, but I am always looking for ways to improve.
>BTW, ranged weapons are in and working, but have been posponed until I
>decide the invention has been accomplished by the inhabitants of the mud
>:) Anyway, probably sounds lame to most, but if you give everyone
>everything right away, it gets dull fast. I'd like to know other ideas
>that would allow a player to get away from the regular hack-n-slash. If
>quests, how do you handle them? Anyway, any input would be appreciated.
Well, if you're trying to avoid a hack-n-slash mud, the basic question
to ask is this: why do players want to kill things so much? Well, the
way I see it there are two basic reasons:
1. A lot of muds give out experience either solely or primarily for
killing monsters.
2. By killing monsters, players get money and treasure.
3. A lot of muds don't have many other things to do.
4. Most muds don't have any monsters that you're punished for killing.
Now, people tend to do the things they're rewarded for, and not do
what they're punished for. If they often get rewarded for killing
monsters, and never get punished for it, they're gonna kill monsters
every chance they get.
What can you do about this? Break the things given above. Give out
experience for things other than killing monsters; if you really want
to decrease killing monsters, give out little or no experience for
killing them. Make sure that there are other things for players to
do besides kill monsters. Have places where people are punished for
killing monsters, or monsters that people are punished for killing.
Some examples:
In an area I built, I didn't want players to be killing things.
However, I don't like arbitrary limits like "no combat" areas, so
I took another tack. If you attack anything in that area, the
police arrive a short time later and haul you off to jail. Your
character is stuck in the jail for a few minutes, then released.
It didn't take long for people to quit attacking things there. :-)
A friend of mine once proposed a "peaceful quest." You enter
an area where there are all sorts of strange and horrible monsters;
in the center of the area is a tower. An evil magician lives in the
tower, and to complete the quest, you have to defeat him... at least,
so you're told. :-) In truth, you can't defeat him. If you fight
him, he'll win and lock you up in a cage. *If* you've been nice to
the monsters in the area, all the monsters there will finally revolt
against the evil wizard when he locks you up; they kill him and free
you, and you complete the quest. Of course, there are clues for
the player; things like a monster with a thorn in his paw, monsters
locked up in the wizards' tower being tortured that you can free, and
who will tell you (if you free them) that the "monsters" are all
really people who the wizard has experimented on, etc. He's never
gotten to implement it anywhere yet, but I think it's a wonderful
idea for making hack-n-slashers reconsider their ways. :-)
Lastly, a mud I'm helping with the mudlib on right now is being
designed to not have experience points; instead, you go up in
skills by using them. Thus, combat makes you better at combat,
but not at anything else. This should encourage people to do
a wider variety of things. :-)
tl...@ic.net
>root@ (root) writes:
>
>++>> Having told someone they are games which many players can play at once,
>++>> it seems to be unnecessary to tell them you can talk to other players.
>++>> Similarly having told them that a lot of MUDs emphasise fighting, saying
>++>> that you can *gasp* shoot an arrow from one location to another seems
>++>> a little silly.
>++>>
>++>
>++>
>++>I asked this a while ago and nobody answered. :)
>++>
>
>++Maybe cause most muds dont like it when a newbie can kill the strongest
>++monsters around by just standing outside and shooting arrows in?
>++It will only really work if it is a PK only mud, or if it only works for pk.
>++(Being able to kill monsters without being hit will unbalance a mud strongly,
>++ unless the average balance of that mud is even worse already, in which case
>++ you can better ditch the whole crap and start all over again.)
How about the mob catching the arrows that don't hit it, and throwing them
back?
Todd
Aaron Brand
: Sebastian Andersson <dvl...@cs.umu.se> wrote:
: >In <p.waltenberg....@irl.cri.nz> p.walt...@irl.cri.nz (Peter Waltenberg) writes:
: >
: >>In our case it's a straight forward problem of game balance, we have ranged
: >>weapons coded and working, we just can't use them yet, nothing quite like
: >>getting an arrow through your back while you are reading mail. Yeah that can
: >>be got round, but the actual weapon code is easy compared to solving all the
: >>little "bugs" it causes.
: >
: >The biggest problem is that muds that are not designed for ranged weapons
: >have to get a new world in order to have them... Simple things like guards
: >that cover a door might need a friend that can guard the door while they run
: >after people with bows. Directions have to be two way exits in order for people
: >to be able to shot back. Mobiles need to look around much more to be able to
: >shoot at their enemies.
: I wouldn't call that a new world... I'd call it a slight redesign
: of the existing one. The *best* way to put in ranged weapons is
: to do it when the mud is initially being set up, before any areas
: are built. That way, all area coders can design their areas with
: ranged weapons in mind. Unfortunately, most muds operate on a
: "tack it on" method; they bring up a mud using a standard setup,
: start building areas, and don't worry about putting in new races,
: guilds, object types, etc until after things are up and running
: with several areas.
There are "ranged weapons" on Tron (polaris.king.ac.uk 3000).
Tron did initially start off as a LpMUD 2.4.5 mudlib.