Diku vs. LP from the player's POV (was: muds on port 23)
Piotr Banski
I have been interested in this topic ever since - after spending several
years as a dedicated lpmud player and then coder - I got involved with
diku-style muds a few months ago. I was actually going to prepare a
longer post and ask for a discussion, but my research and personal
matters do not allow for this at the moment. I hope that the loose
remarks I offer below may nevertheless elicit some interesting comments
from people who know the diku side of the story much better than myself.
Bob Farmer (ucs...@unx1.shsu.edu) wrote:
: In article <AKBW.68$Q7.3...@ptah.visi.com>,
: George Reese <bo...@imaginary.com> wrote:
: >Your mud is an LP no matter how much you wish to claim it is not. An
: >LPMud is ANY mud written in LPC. The LP-ness has absolutely nothing
: >to do with theme or atmosphere. Wake up Aristotle, you don';t have
: >the only role-playign oriented LPMud.
:
: On a related note: I agree with your definition of what an "LPmud" is, and
: of course that definition makes the fact that something is an "LPmud"
: totally useless to a player. So, why do the mudlists/connectors/whatever
^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't believe this is true. Some players do prefer either lp or
diku-style codebases, and can recognise them well, often already in the
login sequence. I return to this below.
: still feel the need to group LPmuds together? The fact they're an "LPmud"
: means absolutely nothing. Why aren't all the Diku variants grouped under
: "C", since that's the language their game is written in?
As you surely know, the names have to do with the origin of both
codebases. The LP comes from the initials of the original creator of this
type of server, and Diku was probably (please correct me if I'm wrong)
the name of the mud whose creators decided to distribute the source
publically. Or maybe the name of the source, since it wasn't very playable
right 'out of the box' as I think I read somewhere (?).
In other words, a historical coincidence which gave rise to what became a
convenient way of classifying these types of muds. Convenient despite
being not utterly precise, given that although genetically the DGD driver
does not come from Lars's original driver, most if not all of the lp
community will not hesitate to classify it as an LP driver, by virtue of
its design, which to _some_ extent follows Lars's original. Likewise,
there are quite a few scratch-written servers out there which genetically
have nothing to do with diku, although the similarity of design remains,
and their authors have afaik no problem with calling them 'diku-style'.
: I noticed one mudlist actually subdividing the LPmuds further, into like
: MudOS, DGD, CD, Amylaar, etc. As if that has anything whatsoever to do
: with the content of the game. Totally useless information for players.
Firstly, it needn't always be information for players. Each of the
drivers above has its own dialect of lpc, and often this dialect is
changing together with the driver version. Thus, such information is
relevant for people who (even though they may want to play the given mud
first) are e.g. thinking of applying for a coding position there.
Secondly, most often each of these drivers has some specific mudlib(s)
that go with it. So a player used to the features of a CD lib will look
for a mud running on CD (*sigh* for Enulal here), and someone used to
Nightmare search among MudOS muds.
Of course, the above assumes a higher level of the player's
'mud-consciousness', which I agree is not a standard. In the standard cases
the player will look for a mud 'which is like ThatMud', and even then
someone better oriented will follow the driver/lib trace to point the
asker to some other mud similar to what they long for.
Another possible scenario is that the player will find their lost mud on
say, Doran's list, and will follow to check out all other muds in the
same 'slot' on the list.
In other cases, and here I refer to your mentioning the 'content of the
game', the player will look for similar muds on the basis of their theme
(this may, I agree, be probably the most common case, at least with
places like the Mud Connector).
However, theme alone is not all. Many players, I strongly believe, pay
attention to what _features_ are being offered by the given mud. And such
features are most easily (although of course not most precisely) defined
by the kind of mudlib used, or even the kind of server.
Which brings me to the diku vs. lp comparison from the player's point of
view. Given that there is a great diversity within both diku an lp type
of servers, I will try to restrict myself to the most striking differences,
none of which is probably absolute.
As I said above, my experience with diku-style servers is limited, so let
me apologize in advance for any blunders, and also ask for corrections.
I hope some of the readers will find the following worth adding to/
commenting upon.
One of the most apparent features of diku-style muds is the prompt,
which is pretty verbose, and which appears roughly every chunk of text
output from the server, as opposed to the simple '>' found on most (not
all) lps, which I believe 'universally' appears only once per input.
Next, I noticed that I think all diku-style muds I played allow for
abbreviating _both_ commands and their arguments, limited only by
ambiguity, meaning that in an unambiguous context, 'p b s' is a perfectly
well formed input, meaning e.g. 'put bread (into) sack'. (okay, some of
those muds allowed this to a greater extent than others)
A short note on the parser is in order. Apart from allowing for
abbreviations, the diku-style parser either ignores grammatical words
like articles or prepositions, or disallows them (I admit that I haven't
tried all options on all the diku-style muds I played).
The newest MudOS global parser is on the opposite pole - it does not
generally allow for anything to be 'dropped'.
The traditional add_action parser would stand somewhere in the middle,
basically leaving the parsing to the particular coder.
(and please, let's _not_ indulge into the discussion of what's 'better')
Of course, from the player's POV, the above would amount to rules like
'here I can strip everything, here it doesn't let me drop anything,
and here it's either this or that'.
The next thing - combat - all the diku-style muds I tried do not allow to
escape your opponent by just going in some direction - you have to
expliciltly 'flee', succeeding or not. I seem to vaguely recall an lpmud
which did the same, can't be sure though.
Then come the auto* commands, meaning autoloot, autosplit, autojunk, etc.
Something that usually (or 'almost always', rather) requires a separate
command on an lpmud.
The very concept of junking stuff in the player's inventory seems quite
characteristic of diku-style bases, as well.
Next, exits - on the 'dikus' I played I haven't seen exits other than the
standard 6 directions (one of them might also have the four additional -
'ne', etc. - not sure now).
Here, it has to be stressed that the difference will probably be most
striking to people coming from the diku-style background - meaning that
those who come from lps will only encounter a subset of the exit types
they are accustomed to use. In other words, for an lp player, not
encountering an 'in' or 'porch' exit for a hundred rooms of a new mud is
not a proof that such an exit doesn't exist somewhere, while for a
typical diku-style player encountering one such exit may be something
very new.
A subset of players may also notice the difference in ansi code
equivalents, which on diku-style muds are either verbose or consist of
some two characters, while the lp worlds prevalently use %^s (the Pinkfish
notation.. *grin* :).
The last thing that comes to my mind is that the diku-style muds I have
tried ask you to choose your class at the first login, while the lpmuds
generally wait with this until you're in the game.
Let me stress that this is NOT meant as a debate on which codebase is
'better', and I do hope that no one will attempt to change this, at least
in this thread.
I will be grateful for comments on / additions to the points above.
Thanks,
Piotr
Derek
Piotr Banski (ban...@indiana.edu) wrote:
: Next, exits - on the 'dikus' I played I haven't seen exits other than the
: standard 6 directions (one of them might also have the four additional -
: 'ne', etc. - not sure now).
: Here, it has to be stressed that the difference will probably be most
: striking to people coming from the diku-style background - meaning that
: those who come from lps will only encounter a subset of the exit types
: they are accustomed to use. In other words, for an lp player, not
: encountering an 'in' or 'porch' exit for a hundred rooms of a new mud is
: not a proof that such an exit doesn't exist somewhere, while for a
: typical diku-style player encountering one such exit may be something
: very new.
With the SMAUG code base, we've been working on tightening the gap between
the mud base worlds by making a Diku-derivative that is more flexible and
puts more power into the hands of the non-coder implementor and the online
builders.
On the point above specifically, SMAUG's exits are no longer based on the
standard six exits alone. You have use of the extra four exits (ne, nw,
se, sw), special command exits (enter, leave, climb) as well as keyword
exits (ie: like a "porch" exit). You can also have any number of exits in
a room.
Holly Sommer
Piotr Banski wrote:
: As you surely know, the names have to do with the origin of
: both codebases. The LP comes from the initials of the
: original creator of this type of server, and Diku was probably
: (please correct me if I'm wrong) the name of the mud whose
: creators decided to distribute the source publically.
The name "Diku" was the name of the Danish university where the
server was developed :)
: As I said above, my experience with diku-style servers is
: limited, so let me apologize in advance for any blunders,
: and also ask for corrections. I hope some of the readers
: will find the following worth adding to/commenting upon.
Mine is pretty much -zero- for Lp, so I can speak from the
other side of the fence :)
: One of the most apparent features of diku-style muds is
: the prompt, which is pretty verbose, and which appears
: roughly every chunk of text output from the server, as
: opposed to the simple '>' found on most (not all) lps,
: which I believe 'universally' appears only once per input.
I do believe that every diku derivitive allows you to set the
prompt to whatever you want - including just a CR - or to turn it
off entirely. Some people want their prompt to practically list
all their vital stats plus condition of their opponent. Others
just want the > so that the scrolling text is broken up some.
: Next, I noticed that I think all diku-style muds I played
: allow for abbreviating _both_ commands and their arguments,
: limited only by ambiguity, meaning that in an unambiguous
: context, 'p b s' is a perfectly well formed input, meaning
: e.g. 'put bread (into) sack'. (okay, some of those muds
: allowed this to a greater extent than others)
This is an implementation-specific "feature." The older MUDs
in the diku family tree require that you type the whole thing out,
every word (in caveman-speak "put bread bag", rather than "put
bread in bag"). The newer ones allow for shortening each arg,
if you want.
: A short note on the parser is in order. Apart from allowing
: for abbreviations, the diku-style parser either ignores
: grammatical words like articles or prepositions, or disallows them
This is also a remnant of older codebases in the diku tree. The
newer servers allow for articles like at and on - so that if you
are in a room which has carvings on the walls, and you also have
a staff with carvings on it, you can specify "look at carvings" or
"look carvings" to see the ones on the wall, but "look carvings
staff" or "look at carvings staff" or "look at carvings on staff"
will yield expected results.
I'm not as familiar with other servers as I am with NiMUD, but
the 1.5 release of NiM didn't allow for the at and on modifiers
to CL parsing, so we added it in - now you can specify which
extra description keywords you want to see :) It's far more
precise and natural-language like.
: The newest MudOS global parser is on the opposite pole -
: it does not generally allow for anything to be 'dropped'.
While this makes for a more elegant and natural-feeling
command interface for the players, it is not the easiest.
The aforementioned cavemanspeak is easier... just clunky.
: The next thing - combat - all the diku-style muds I tried do
: not allow to escape your opponent by just going in some
: direction - you have to expliciltly 'flee', succeeding or not.
This is definitely a large difference between the two server
types. Although, it's a pretty trivial change to code, should
a coder decide to implement it.
: Next, exits - on the 'dikus' I played I haven't seen exits
: other than the standard 6 directions (one of them might also
: have the four additional - 'ne', etc. - not sure now).
While the extra four directions aren't *quite* commonplace, they
*are* standard on some distributions - NiMUD and I think Smaug
come with them, by default.
There is also the enter/go command, for moving through portals.
: encountering an 'in' or 'porch' exit for a hundred rooms of a new mud
is
: not a proof that such an exit doesn't exist somewhere, while for a
: typical diku-style player encountering one such exit may be something
: very new.
What is a 'porch' exit?
: The last thing that comes to my mind is that the diku-style
: muds I have tried ask you to choose your class at the first
: login, while the lpmuds generally wait with this until you're
: in the game.
And then, there is the case of NiMUD, which is classless, or those
which are multiclass, in which case, the choice you make at login
time isn't as life-determining as in a single-class MUD.
: I will be grateful for comments on / additions to the points above.
There are mine. Surely leaning toward a particular server, but with
enough general diku-esque information to be of use, I hope.
-Holly
Threshold RPG
In article <6gftee$ts0$1...@jetsam.uits.indiana.edu>, ban...@indiana.edu (Piotr Banski) wrote:
>Bob Farmer (ucs...@unx1.shsu.edu) wrote:
>: On a related note: I agree with your definition of what an "LPmud" is, and
>: of course that definition makes the fact that something is an "LPmud"
>: totally useless to a player. So, why do the mudlists/connectors/whatever
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I don't believe this is true. Some players do prefer either lp or
>diku-style codebases, and can recognise them well, often already in the
>login sequence. I return to this below.
The reason for this is mainly because in the early years of mudding people did
not stray very far from stock. They spent their time making areas, spells, and
other such add ons and did not make any major alterations to the actual "deep
magic" of the codebase.
As mudding enters a new era, the focus is different. Stock is generally
considered "lame" and the goal of many (perhaps most) mud designers is to
plan their design beginning at a much deeper level.
Thus, some of the "obvious" differences will disappear. The things you
mentioned about exits, auto commands, etc, will become design decisions made
by all programmers rather than codebased decisions. This is part of the
evolution of all muds, and as it progresses you will see "LPMUD" features on
diku muds and "DIKUmud" features on lp muds. As people take a more objective
view towards the assets and interesting features of both codebases, they will
seek to use their program to replicate the effects of cool things they have
seen on another codebase.
-Aristotle@Threshold
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, rich, detailed roleplaying environment.
http://www.threshold.counseltech.com
telnet://threshold.counseltech.com:23
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Threshold RPG
In article <352B9B95...@micro.ti.com>, Holly Sommer <hso...@micro.ti.com> wrote:
>Piotr Banski wrote:
>
>: One of the most apparent features of diku-style muds is
>: roughly every chunk of text output from the server, as
>: opposed to the simple '>' found on most (not all) lps,
>: which I believe 'universally' appears only once per input.
>
>prompt to whatever you want - including just a CR - or to turn it
>off entirely. Some people want their prompt to practically list
>all their vital stats plus condition of their opponent. Others
>just want the > so that the scrolling text is broken up some.
This can be done on most (if not all) LPmuds. It can be done on Threshold for
example but I do not allow it to players b/c I think its too hack n slash-ish.
>[stuff about parser's snipped]
I think all of these parser differences are a simple matter of design rather
than anything endimic to the codebases. I believe Holly made that same point
and I agree with her (I also agree that sometimes "caveman speak" is easier to
use).
>: Next, exits - on the 'dikus' I played I haven't seen exits
>: other than the standard 6 directions (one of them might also
>: have the four additional - 'ne', etc. - not sure now).
>
>While the extra four directions aren't *quite* commonplace, they
>*are* standard on some distributions - NiMUD and I think Smaug
>come with them, by default.
>
>>There is also the enter/go command, for moving through portals.
I don't know about other codebases but I can use any word as an exit and there
is no necessity of typing go or enter.
>What is a 'porch' exit?
It is easier to just type "porch" rather than go porch. (imho at least)
>: The last thing that comes to my mind is that the diku-style
>: muds I have tried ask you to choose your class at the first
>: login, while the lpmuds generally wait with this until you're
>: in the game.
>
>And then, there is the case of NiMUD, which is classless, or those
>which are multiclass, in which case, the choice you make at login
>time isn't as life-determining as in a single-class MUD.
Again, this is totally a matter of design.
Katrina McClelan
>As you surely know, the names have to do with the origin of both
>codebases. The LP comes from the initials of the original creator of this
>type of server, and Diku was probably (please correct me if I'm wrong)
>the name of the mud whose creators decided to distribute the source
>publically. Or maybe the name of the source, since it wasn't very playable
>right 'out of the box' as I think I read somewhere (?).
From the license:
This document contains the rules by which you can use, alter or publish
parts of DikuMud. DikuMud has been created by the above five listed
persons in their spare time, at DIKU (Computer Science Instutute at
Copenhagen University). You are legally bound to follow the rules
described in this document.
DIKU is the accronym for a department at a university in Denmark where the
code was created. So you're half right.
>Next, I noticed that I think all diku-style muds I played allow for
>abbreviating _both_ commands and their arguments, limited only by
>ambiguity, meaning that in an unambiguous context, 'p b s' is a perfectly
>well formed input, meaning e.g. 'put bread (into) sack'. (okay, some of
>those muds allowed this to a greater extent than others)
This depends on which calls are made. As arguments are parsed in
routines, each command can parse its arguments different. Most diku
varients call the function that the interpreter uses to check
abbrieviations, but not all. A good example, if I recall, is that the
standard remove command will not allow abbriviations.
>Let me stress that this is NOT meant as a debate on which codebase is
>'better', and I do hope that no one will attempt to change this, at least
>in this thread.
Agreed, the above are just a couple points to add. :) I don't want to go
there either :)
-Kat
michael...@abnamro.com
[A lot of stuff. Forgive me for not reposting it all here...]
> : On a related note: I agree with your definition of what an "LPmud" is, and
> : of course that definition makes the fact that something is an "LPmud"
> : totally useless to a player. So, why do the mudlists/connectors/whatever
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> I don't believe this is true. Some players do prefer either lp or
> diku-style codebases, and can recognise them well, often already in the
> login sequence. I return to this below.
Definately, some players prefer one base to another, although I would guess
that the number of *exclusively* LP players is smaller than the number of
exclusively Diku players, because the LP style muds can be so absolutely
variable. I play Diku and derivitives on occassion, and I have a hard time
distinguishing between Diku, ROM, Merc, Circle and whatever else. Yet two LPs
run on the same driver, and based on the same mudlib can be easilly modified
to the point where they're no longer recognizable as the same game. I don't
think that tends towards exclusive player loyalty to a codebase. LP players
are more likely to shop around based on a mud's theme and features. If a Diku
happened to offer what they were looking for, they'd play there.
I think a listing of LP's based on their theme would be far more useful to
players than a big list where the LPs are all grouped into one lump. And this
list where they're divided up by driver is pretty much useless to players.
How many players know or care how my floating point decimals are handled, or
how much information we can store in a mapping before it pukes?
>
> In other words, a historical coincidence which gave rise to what became a
> convenient way of classifying these types of muds. Convenient despite
> being not utterly precise, given that although genetically the DGD driver
> does not come from Lars's original driver, most if not all of the lp
> community will not hesitate to classify it as an LP driver, by virtue of
> its design, which to _some_ extent follows Lars's original. Likewise,
> there are quite a few scratch-written servers out there which genetically
> have nothing to do with diku, although the similarity of design remains,
> and their authors have afaik no problem with calling them 'diku-style'.
I have no problem with my mud being referred to as an LP, but I don't think
that will help a player decide if they want to play there. The base we
started from didn't specify in any way what our theme would be, or the limits
of our world. I don't mean to say that Diku's *can't* have a different theme,
but I've never seen a science fiction Diku. A few good Apocolyptic fantasy
ones, yes, but even that doesn't stray too far from the sword & sorcery
archetype.
> Secondly, most often each of these drivers has some specific mudlib(s)
> that go with it. So a player used to the features of a CD lib will look
> for a mud running on CD (*sigh* for Enulal here), and someone used to
> Nightmare search among MudOS muds.
> Of course, the above assumes a higher level of the player's
> 'mud-consciousness', which I agree is not a standard. In the standard cases
> the player will look for a mud 'which is like ThatMud', and even then
> someone better oriented will follow the driver/lib trace to point the
> asker to some other mud similar to what they long for.
> Another possible scenario is that the player will find their lost mud on
> say, Doran's list, and will follow to check out all other muds in the
> same 'slot' on the list.
The above also assumes a certain degree of stock-ishness in the mud listed.
To say that Dreamshadow runs on MudOS is meaningless; even to say that we're
based on the LP 2.whatever mudlib is meaningless. The MudOS driver had
several mudlibs designed for it; we share a few features with TMI only because
our Tech staff (Dainia & Kirian) were involved in swapping goodies back &
forth with their staff. If you went by the mudlib specification, which is
admittedly more relavent for *most* LPs, you'd log into DS expecting to find
yourself in Larstown... Boy, what a suprise! Over the course of 7 years a
mud can make some pretty significant changes...
We could, of course, ask to have ourselves designated as a 'DreamLib' mud.
This would end the confusion of being associated with places that have very
little in common with us. Of course, our library is not available for
distribution, so we'd be the *only* Dreamlib mud. Not a bad idea, for a
single mud, but what about Threshold? Their mud is unique, too. So Aristotle
would ask politlely to be classified as a Threshold Library mud. And his is
the only one. And so on, and so on... (Maybe this is the answer to standing
out above stock muds?)
> However, theme alone is not all. Many players, I strongly believe, pay
> attention to what _features_ are being offered by the given mud. And such
> features are most easily (although of course not most precisely) defined
> by the kind of mudlib used, or even the kind of server.
Good point! Unfortunately, there aren't too many features that can't be
emulated on an LP. Since the recent discussions about emulating MUSH code
with an LP game have shown that a number of people can, have, or will do
exactly that, would it be surprising to find that the same holds true for
Diku, which is a much closer relative?
> One of the most apparent features of diku-style muds is the prompt,
> which is pretty verbose, and which appears roughly every chunk of text
> output from the server, as opposed to the simple '>' found on most (not
> all) lps, which I believe 'universally' appears only once per input.
I'm pretty sure that's common among TMI based libs. (I think that's where we
got that toy from. We *did* have a Diku-heavy coding staff at one time, and
so picked up a few Diku like features.)
> Next, I noticed that I think all diku-style muds I played allow for
> abbreviating _both_ commands and their arguments, limited only by
> ambiguity, meaning that in an unambiguous context, 'p b s' is a perfectly
> well formed input, meaning e.g. 'put bread (into) sack'. (okay, some of
> those muds allowed this to a greater extent than others)
Well, we still use the old add_action command system, so we don't have this.
But I don't see why it would be impossible, or even difficult for a LP with a
command parser.
> A short note on the parser is in order. Apart from allowing for
> abbreviations, the diku-style parser either ignores grammatical words
> like articles or prepositions, or disallows them (I admit that I haven't
> tried all options on all the diku-style muds I played).
> The newest MudOS global parser is on the opposite pole - it does not
> generally allow for anything to be 'dropped'.
> The traditional add_action parser would stand somewhere in the middle,
> basically leaving the parsing to the particular coder.
> (and please, let's _not_ indulge into the discussion of what's 'better')
> Of course, from the player's POV, the above would amount to rules like
> 'here I can strip everything, here it doesn't let me drop anything,
> and here it's either this or that'.
True, but that doesn't preclude the possiblilty of emulating the way a Diku
parser works.
> The next thing - combat - all the diku-style muds I tried do not allow to
> escape your opponent by just going in some direction - you have to
> expliciltly 'flee', succeeding or not. I seem to vaguely recall an lpmud
> which did the same, can't be sure though.
Easy enough to do in LP. I think it's not done here more often because we
don't generally like the idea...
> Then come the auto* commands, meaning autoloot, autosplit, autojunk, etc.
> Something that usually (or 'almost always', rather) requires a separate
> command on an lpmud.
I think that your need to add 'almost always' to that statement is an answer
in and of itself. I know you're having a difficult time pinning down the
standard features of an LP to compare to Dikus. I'd suggest it's because the
creature doesn't exist...
> The very concept of junking stuff in the player's inventory seems quite
> characteristic of diku-style bases, as well.
Characteristic of, but not exclusive to. We've got it. (Though we may have
taken it out to encourage donations to the newbie equipment stash)
> Next, exits - on the 'dikus' I played I haven't seen exits other than the
> standard 6 directions (one of them might also have the four additional -
> 'ne', etc. - not sure now).
> Here, it has to be stressed that the difference will probably be most
> striking to people coming from the diku-style background - meaning that
> those who come from lps will only encounter a subset of the exit types
> they are accustomed to use. In other words, for an lp player, not
> encountering an 'in' or 'porch' exit for a hundred rooms of a new mud is
> not a proof that such an exit doesn't exist somewhere, while for a
> typical diku-style player encountering one such exit may be something
> very new.
A good point. But a lot of LPs discourage excessive use of non standard
directions as 'tacky', so your Diku player might not notice it.
> The last thing that comes to my mind is that the diku-style muds I have
> tried ask you to choose your class at the first login, while the lpmuds
> generally wait with this until you're in the game.
Hmm. I've seen both ways of doing it in LPs.. Some will ask you to choose a
class when you create the character, some will restrict you from choosing a
guild for several levels (and some have done away with classes and levels
altogether).
There are also a few things you missed which seem to be common to Dikus and
the like:
Movement points
Needing to consume food and water
Multiple light levels
Positions (Standing/Resting/Sleeping)
Level-restricted equipment
'Renting' equipment
I'm sure there are more.. But I've seen most of these features used in a LP
game, as well
> Let me stress that this is NOT meant as a debate on which codebase is
> 'better', and I do hope that no one will attempt to change this, at least
> in this thread.
I also want to stress that this is not meant as any kind of putdown as to the
abilities of diku and it's derivatives. I also seriously doubt that a Diku
player would *ever* mistake Dreamshadow for a Diku, no matter what our
features.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
michael...@abnamro.com
In article <6gg72j$1o4$2...@usenet11.supernews.com>,
thre...@counseltech.com (Threshold RPG) wrote:
>
> In article <6gftee$ts0$1...@jetsam.uits.indiana.edu>, ban...@indiana.edu (Piotr
Banski) wrote:
> >: On a related note: I agree with your definition of what an "LPmud" is,
and
> >: of course that definition makes the fact that something is an "LPmud"
> >: totally useless to a player. So, why do the mudlists/connectors/whatever
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >I don't believe this is true. Some players do prefer either lp or
> >diku-style codebases, and can recognise them well, often already in the
> >login sequence. I return to this below.
>
did
> not stray very far from stock. They spent their time making areas, spells,
and
> other such add ons and did not make any major alterations to the actual
"deep
> magic" of the codebase.
>
> As mudding enters a new era, the focus is different. Stock is generally
> considered "lame" and the goal of many (perhaps most) mud designers is to
> plan their design beginning at a much deeper level.
>
> Thus, some of the "obvious" differences will disappear. The things you
> mentioned about exits, auto commands, etc, will become design decisions made
> evolution of all muds, and as it progresses you will see "LPMUD" features on
> diku muds and "DIKUmud" features on lp muds. As people take a more objective
> view towards the assets and interesting features of both codebases, they
will
> seek to use their program to replicate the effects of cool things they have
> seen on another codebase.
>
> -Aristotle@Threshold
An excellent point! Looking at some of the responses to this thread, it's
obvious that both bases are very open to borrowing good ideas from the other,
and within a few years, none of the features we associate with either game
will be exclusive, or even existant!
michael...@abnamro.com
In article <352B9B95...@micro.ti.com>,
Holly Sommer <hso...@micro.ti.com> wrote:
>
> Piotr Banski wrote:
> is
> : not a proof that such an exit doesn't exist somewhere, while for a
> : typical diku-style player encountering one such exit may be something
> : very new.
>
I'd assume it would lead to the porch of whatever building you're in. A lot
of LP's don't encourage exits like that, since it's a bit tacky.
>
> : The last thing that comes to my mind is that the diku-style
> : muds I have tried ask you to choose your class at the first
> : login, while the lpmuds generally wait with this until you're
> : in the game.
>
> And then, there is the case of NiMUD, which is classless, or those
> which are multiclass, in which case, the choice you make at login
> time isn't as life-determining as in a single-class MUD.
Really? I don't think I've ever played on a NiMUD. I generally like
classless games.. It ends a lot of the 'cookie cutter character' syndrome.
What's your address?
Holly Sommer
michael...@abnamro.com wrote:
: Holly Sommer <hso...@micro.ti.com> wrote:
: > What is a 'porch' exit?
:
: I'd assume it would lead to the porch of whatever building
: you're in.
So, it's just an edit that goes outside? Uh... are there also
"bathroom" or "parlor" or "stoop" exits? (<- in jest)
: A lot of LP's don't encourage exits like that, since it's a
: bit tacky.
Well, "odd" I can see (odd to me because I've never seen it),
but "tacky"? How?
: > And then, there is the case of NiMUD, which is classless,
: > or those which are multiclass, in which case, the choice
: > you make at login time isn't as life-determining as in a
: > single-class MUD.
:
: Really? I don't think I've ever played on a NiMUD.
Yeah, NiM is classless by default. I'm not surprised you've never
played on one - for some reason, they never proliferated (I like
to think it's because they were "too different" from the other
merc-derived servers that came out at the same time... ie: ROM
and Envy :) As far as I know, there are only two of them out there
anymore: Grok (the one I front) and The Isles (the original, by Locke).
: I generally like classless games.. It ends a lot of the 'cookie
: cutter character' syndrome.
So long as it doesn't end up achieving the same thing as a
multiclass game does. That is to say: everyone can learn every
spell or skill, because it's not a single-class MUD.
: What's your address?
Grok runs at grok.envy.com 8000. Also, Locke (the original
NiMUD author) has recently surfaced, and requested roleplayers,
imagination folks, etc. Look for the thread in rgmd called
"Remembering the Isles".
-Holly
Mehbisdokutie
About the prompt discussion below: I'm not sure about MudOS, since it's
been
a couple of yrs since I've messed with it, but on the Amylaar side of
drivers, there
is an efun called set_prompt(), which can be used to change the prompts for
players
and/or wizards. Of course, this is specific to the mudlib, and few MUDs
using the Amylaar
driver take advantage of this function. Of the ones that do, they are
either clones of TubMud's
mudlib, or they only allow wizards to set their prompt.
Holly Sommer wrote:
> Piotr Banski wrote:
>
> : One of the most apparent features of diku-style muds is
> : the prompt, which is pretty verbose, and which appears
> : roughly every chunk of text output from the server, as
> : opposed to the simple '>' found on most (not all) lps,
> : which I believe 'universally' appears only once per input.
>
> I do believe that every diku derivitive allows you to set the
> prompt to whatever you want - including just a CR - or to turn it
> off entirely. Some people want their prompt to practically list
> all their vital stats plus condition of their opponent. Others
> just want the > so that the scrolling text is broken up some.
>
> -Holly
The Wildman
On Wed, 08 Apr 1998 10:45:25 -0500, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Holly Sommer <hso...@micro.ti.com> said
the following fighting words:
>Piotr Banski wrote:
>
[snip]
>: encountering an 'in' or 'porch' exit for a hundred rooms of a new mud
>is
>: not a proof that such an exit doesn't exist somewhere, while for a
>: typical diku-style player encountering one such exit may be something
>: very new.
>
>
You are standing in front of an old house. You can return to the street, or
take a closer look at the house - starting with the porch.
Available exits: street, porch
It's useful when a direction is not necessarily a compass heading.
The Wildman
zeb...@wwa.com
>michael...@abnamro.com wrote:
>
>: Holly Sommer <hso...@micro.ti.com> wrote:
>: > What is a 'porch' exit?
>:
>: I'd assume it would lead to the porch of whatever building
>: you're in.
>
>So, it's just an edit that goes outside? Uh... are there also
>"bathroom" or "parlor" or "stoop" exits? (<- in jest)
No, it is actually true...
>
>: A lot of LP's don't encourage exits like that, since it's a
>: bit tacky.
>
>Well, "odd" I can see (odd to me because I've never seen it),
>but "tacky"? How?
>
[snip]
From my standpoint this is one of the largest drawbacks of this
system. I have not played an LP recently, but I never found one that
handled the exits well (for what _I_ wanted in a game, obviously
others liked it). There are thousands of "rooms" in the game and one
of them has an exit called porch. One has an exit called steps, and
one has a tightrope exit (circus area), etc.
What I found was that one of a few things happened. Either the exits
were listed in the exit choices for a room [North, Porch, West], in
which case I now have to type in 'porch' (or set a new alias) instead
of a standard 'n' or 'sw', etc. It is listed there for all to see so
I do not have to explore any harder. It is just something more to
type. A good description about the "...inviting porch" to my west
would be just as "realistic" to me. I do not feel more "immersed" in
the game for having to type 'porch' instead of 'w'. A good area
builder accomplishes more than a new exit command IMHO.
Or, the exit is not obvious. In the hundreds of rooms that desribe
windows, closets, porches, parlors, etc. a couple will actually have a
new exit. It is not reasonable to expect that a normal player would
be able to find it (unless the description is SO obvious, then it is
the same as the above paragraph). What I found happened, is that the
builders, that were also players, would put these exits in and then
hide excellent EQ there for them and their friends. They built it, so
they know where the exits are. Noone else does though. Not very
fair.
If you have 10 exits available to you (n,s,e,w,u,d,ne,nw,se,sw) there
seems to be more than enough choices to work with. It is then up to
the creative builders to describe these exits in such a way that the
player feels he is in the actual world.
I am sure that others enjoy this system (it just was not for me).
Also, someone may have come up with a better method for handling these
'special' exits since I last played an LP.
-Zeboim
John Adelsberger
In rec.games.mud.lp Piotr Banski <ban...@indiana.edu> wrote:
: I don't believe this is true. Some players do prefer either lp or
: diku-style codebases, and can recognise them well, often already in the
: login sequence. I return to this below.
YM 'can recognize _existing_ ones well.' A diku clone would be easy in
LPC. Of course, the title screen wouldn't credit the Diku team, but
still...:-)
: type of server, and Diku was probably (please correct me if I'm wrong)
: the name of the mud whose creators decided to distribute the source
Diku is the name of the school the developers were at.
: One of the most apparent features of diku-style muds is the prompt,
: which is pretty verbose, and which appears roughly every chunk of text
: output from the server, as opposed to the simple '>' found on most (not
: all) lps, which I believe 'universally' appears only once per input.
Both the prompt and the frequency of printing it are controllable under
MudOS; it can be made to behave like Diku.
: Next, I noticed that I think all diku-style muds I played allow for
: abbreviating _both_ commands and their arguments, limited only by
: ambiguity, meaning that in an unambiguous context, 'p b s' is a perfectly
: well formed input, meaning e.g. 'put bread (into) sack'. (okay, some of
: those muds allowed this to a greater extent than others)
Again, you could do this on an LP; the code would be fairly simple since
LPC has builtin regex stuff.
: A short note on the parser is in order. Apart from allowing for
: abbreviations, the diku-style parser either ignores grammatical words
: like articles or prepositions, or disallows them (I admit that I haven't
: tried all options on all the diku-style muds I played).
This can be done on an LP.
: The next thing - combat - all the diku-style muds I tried do not allow to
: escape your opponent by just going in some direction - you have to
: expliciltly 'flee', succeeding or not. I seem to vaguely recall an lpmud
: which did the same, can't be sure though.
Isn't hard, but I don't like it. It promotes the use of triggers and bots
to no good end.
: Then come the auto* commands, meaning autoloot, autosplit, autojunk, etc.
: Something that usually (or 'almost always', rather) requires a separate
: command on an lpmud.
This could be done on an LP with the utmost of ease.
: The very concept of junking stuff in the player's inventory seems quite
: characteristic of diku-style bases, as well.
Most LPs I've played call it burying; same thing. Sacrificing is another
thing entirely, but htats just stupid.
: Next, exits - on the 'dikus' I played I haven't seen exits other than the
: standard 6 directions (one of them might also have the four additional -
: 'ne', etc. - not sure now).
I prefer nsew, ne,nw,sw,se, in, out, up, down, and enter <target>, but
any such system is easily doable on an LP.
: A subset of players may also notice the difference in ansi code
: equivalents, which on diku-style muds are either verbose or consist of
: some two characters, while the lp worlds prevalently use %^s (the Pinkfish
: notation.. *grin* :).
I thought %^ was originally a Nightmare thing? Anyway, to repeat myself,
Diku style color is not hard to do.
: The last thing that comes to my mind is that the diku-style muds I have
: tried ask you to choose your class at the first login, while the lpmuds
: generally wait with this until you're in the game.
I won't repeat it anymore.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
Threshold RPG
In article <352c0742...@news.wwa.com>, zeb...@wwa.com wrote:
>
>If you have 10 exits available to you (n,s,e,w,u,d,ne,nw,se,sw) there
>seems to be more than enough choices to work with. It is then up to
>the creative builders to describe these exits in such a way that the
>player feels he is in the actual world.
What if your character doesnt currently know what direction is north? Then you
need left, right, straight, back, or some other exit? What if the object is
something that can be entered from a variety of angles, and thus it really is
inaccurate to say you are going "east" to enter it.
10 exits fit most situations. However, there are many situations it does not
fit. Having the flexibility to use other exits is a big help. Using them
poorly like in some of your excellent examples of poor use is pretty lame.
However, a system should not be judged by the work produced by poor/cheating
coders.
Piotr Banski
John Adelsberger (j...@umr.edu) wrote:
: In rec.games.mud.lp Piotr Banski <ban...@indiana.edu> wrote:
[cut]
:
: This can be done on an LP.
[cut]
: I won't repeat it anymore.
You needn't have said it even once. I wasn't claiming it can't be done on
an LP; I tried to characterise the stardard differences between LPs and
Dikus from the player's point of view, generalizing over a great variety
of server types, which necessarily involves simplification.
The point wasn't to specify what you can do with LP, but what you
standardly do (or don't do) with it, again generalizing over a great
variety of libs.
Thanks for your other answers though.
Piotr
John Adelsberger
In rec.games.mud.lp Holly Sommer <hso...@micro.ti.com> wrote:
: So, it's just an edit that goes outside? Uh... are there also
: "bathroom" or "parlor" or "stoop" exits? (<- in jest)
There could be:-)
Scatter ///oo/\)
In <352BE723...@micro.ti.com>, Holly Sommer <hso...@micro.ti.com> writes:
>michael...@abnamro.com wrote:
>: > And then, there is the case of NiMUD, which is classless,
>: Really? I don't think I've ever played on a NiMUD.
>Yeah, NiM is classless by default. I'm not surprised you've never
[snip]
>: I generally like classless games.. It ends a lot of the 'cookie
>: cutter character' syndrome.
>So long as it doesn't end up achieving the same thing as a
>multiclass game does. That is to say: everyone can learn every
>spell or skill, because it's not a single-class MUD.
I've decided on a classless system for the mud I'm building, mainly to get away
from the cliched mage/fighter/thief/priest moulds and because I feel 'class' to
be a highly artificial way to restrict what people can learn. My concern at the
moment is how to make sure players don't become clones of each other with
all the sames skills and commands.
I'd be interested to know what methods you use to prevent that happening?
--
Scatter
///\oo/\\\
Tyler
In article <6gi9s0$996$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter
///\oo/\\\) wrote:
> I've decided on a classless system for the mud I'm building, mainly to
get away
> from the cliched mage/fighter/thief/priest moulds and because I feel
'class' to
> be a highly artificial way to restrict what people can learn. My concern
at the
> moment is how to make sure players don't become clones of each other with
> all the sames skills and commands.
>
> I'd be interested to know what methods you use to prevent that happening?
I based a player's ability to learn skills off of their attributes.
Ok, let's say you set a base point amount for each skill in your game.
Depending on your attributes, the base points are modified if a player
tries to learn the skill in one way or another. For example,
Mr. Mage, a real witty guy, has no problem learning easy magic spells.
For example, he might receive a bonus: (base points / 2) or something
similar. Then we take Oscar Ogre, who's dumb as a rock. Now Oscar may
want to learn some easy mage spells, but he's gonna spend most of his life
doing it, or (base points * 10) This creates a really good balance
throughout the game, and is more realistic than class restrictions.
There's a really good example of this on Archipelago. I don't have the
address, so you might want to search for it on the mud connector and take
a look at it.
Happy coding,
tyler
--
"I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." -- Albert Einstein
-------------------------------------------------------------------
michael...@abnamro.com
In article <352BE723...@micro.ti.com>,
Holly Sommer <hso...@micro.ti.com> wrote:
>
> michael...@abnamro.com wrote:
>
> : Holly Sommer <hso...@micro.ti.com> wrote:
> : > What is a 'porch' exit?
> :
> : I'd assume it would lead to the porch of whatever building
> : you're in.
>
> "bathroom" or "parlor" or "stoop" exits? (<- in jest)
Yup. (<- Not in jest. ;-) )
>
> : A lot of LP's don't encourage exits like that, since it's a
> : bit tacky.
>
> Well, "odd" I can see (odd to me because I've never seen it),
> but "tacky"? How?
Well, given the above examples...
Foyer
You stand in the foyer of a large plantation house.
Exits: North, Stairs, Bathroom, West, Porch
It gets the point across, but doesn't look that great in print. I'd prefer to
see what you're probably used to seeing; The rooms are referred to in the
description, (The bathroom is to the east, the porch is to the south, the
stairs lead up, etc.) & the exits are directions.
Although, if you were consistant with this, and *every* exit was referred to
by a name rather than a direction, it wouldn't be so bad... Hmm...
Threshold RPG
In article <6gi9s0$996$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>I've decided on a classless system for the mud I'm building, mainly to get away
>from the cliched mage/fighter/thief/priest moulds and because I feel 'class' to
>be a highly artificial way to restrict what people can learn. My concern at the
>moment is how to make sure players don't become clones of each other with
>all the sames skills and commands.
>I'd be interested to know what methods you use to prevent that happening?
I prefer a class based system for a variety of reasons but thats not the
question =). I do have some suggestions for keeping people from all becoming
copies of each other with the 'best' compliment of skills.
I would divide skills/spells into groups. By this I mean you would think of a
progression for various skills so you had to learn certain abilities in
succession if you wanted to learn them (like prerequisites). If you keep the
various groups of skills all somewhat useful, people will be motivated to
progress down all the various groups of skills.
Also, every "group" of skills/spells should have a few that are very very
useful. This way there is a definite reward for choosing various groups.
Learning skills in some groups should preclude learning those of another
group.
Finally, when you start learning which groups of skills people seem to never
take, try to think of something particularly useful to drop in that group.
Through this process you can hopefully get to a system where all types of
skills are useful and desireable.
The Wildman
On 9 Apr 1998 11:02:24 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Scatter ///\oo/\\\
<sca...@thevortex.com> said the following fighting words:
>
>I've decided on a classless system for the mud I'm building, mainly to get away
>from the cliched mage/fighter/thief/priest moulds and because I feel 'class' to
>be a highly artificial way to restrict what people can learn. My concern at the
>moment is how to make sure players don't become clones of each other with
>all the sames skills and commands.
>
>I'd be interested to know what methods you use to prevent that happening?
giant can learn 25 skills, whereas an elf can learn 50, and a human 40. (I'm
guessing at the numbers).
It is possible to combine flexibility with class-like restrictions. The mud
I code on uses a point based system with skills and guilds. Skills fall into
3 categories - those that can be learned on their own, those that can only be
taught by guilds, and those that the guilds teach only to members.
Characters can be members of multiple guilds - each guild costs so many
points (the more guilds you belong to, the fewer points you have to spend on
skills)
The skills that guilds will teach to non-members have a monetary cost. So to
learn basket weaving from the Too-Much-Time-On-Their-Hands Guild (example
only) it may cost $10000, as well the points required to learn it.
--
The Wildman
Holly Sommer
Scatter ///oo/\) wrote:
: I've decided on a classless system for the mud I'm building,
: moulds and because I feel 'class' to be a highly artificial
: way to restrict what people can learn. My concern at the
: moment is how to make sure players don't become clones of each
: other with all the sames skills and commands.
:
: I'd be interested to know what methods you use to prevent
: that happening?
Well, part of the solution to that was built into the server, and
part of it we added through some tightening. In most MUDs, players
are distinguished by name, and (race and/or class). We kept names.
There are no classes. There are quite a few races.
The total number of skills/spells you can learn in a lifetime are
restricted by race. A kenku can't learn as many as a human, for
example. The system which NiM uses is that of a learn-practice
system. You must first learn a skill/spell, and then you practice
it. Learn and practice points are gained through leveling. Granted,
this is a fairly vanilla way of gaining these points, but it works.
Also, stats and attributes (hp, dex, etc.) are very expensive to
raise, so this blocks the formulaeic approach of "max wis, then con,
then int, then str, then dex and be a killing machine by the time
I reach 2/3 maximum mort level." Our first Avatar has not maxed more
than two attributes, and some of his weapons proficiencies need alot
of work :) (wp, btw, go up with use... skills/spells do not - something
I'm not all that happy with, so it may change).
All this will be somewhat... optionally moot, though, once we
implement something I've been pushing for a year or so, so if you want
to see how it works (and it works well, it just could be made even
more different than it is now), you should check us out sometime
soon :)
-Holly
michael...@abnamro.com
writes:
> >michael...@abnamro.com wrote:
>
> >: > And then, there is the case of NiMUD, which is classless,
> >: Really? I don't think I've ever played on a NiMUD.
> >Yeah, NiM is classless by default. I'm not surprised you've never
> [snip]
> >: I generally like classless games.. It ends a lot of the 'cookie
> >: cutter character' syndrome.
> >So long as it doesn't end up achieving the same thing as a
> >multiclass game does. That is to say: everyone can learn every
> >spell or skill, because it's not a single-class MUD.
>
away
> from the cliched mage/fighter/thief/priest moulds and because I feel 'class'
to
> be a highly artificial way to restrict what people can learn. My concern at
the
> moment is how to make sure players don't become clones of each other with
> all the sames skills and commands.
>
> I'd be interested to know what methods you use to prevent that happening?
> Scatter
> ///\oo/\\\
>
>
Have a *lot* of skills to choose from. That way, you *can't* really be great
at everything; you have to specialize. It's easy for us, since our theme is a
'multi-cosm' universe, so we can have every kind of setting from the Stone Age
to Space Opera.
We're also debating getting rid of experience points entirely. A side effect
of this would be to make players complete quests to gain any skills that can't
be used unskilled, like magic, prayers, medicine, or whatever. Once you get
the first point, you gain through practice, so time becomes another reason why
you can't be great at everything. Attributes are another. If you spread out
your initial attributes to the point where you can learn every skill, you
will be an average character. You can do anything, but not as well as someone
who specializes.
Hope this helps...
Scatter ///oo/\)
In <6gijpr$a42$1...@usenet54.supernews.com>, thre...@counseltech.com (Threshold RPG) writes:
>In article <6gi9s0$996$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>>I've decided on a classless system for the mud I'm building, mainly to get away
>>from the cliched mage/fighter/thief/priest moulds and because I feel 'class' to
>>be a highly artificial way to restrict what people can learn. My concern at the
>>moment is how to make sure players don't become clones of each other with
>>all the sames skills and commands.
>>I'd be interested to know what methods you use to prevent that happening?
>
>question =).
Just out of interest, why do you prefer a class based system? I'm in the
interesting position at the moment of having implemented a class system
in my mudlib a few months ago, and have just recently (whilst polishing off
the combat system, and 'living' object) decided that I don't really want it.
>I do have some suggestions for keeping people from all becoming
>copies of each other with the 'best' compliment of skills.
>
>I would divide skills/spells into groups. By this I mean you would think of a
>progression for various skills so you had to learn certain abilities in
>succession if you wanted to learn them (like prerequisites). If you keep the
>various groups of skills all somewhat useful, people will be motivated to
>progress down all the various groups of skills.
This is more or less what I have. If you're at all familiar with the DW style
skill heirarchy, mine looks very similar although the actual skills themselves
are different and the code behind it was written from scratch.
>Also, every "group" of skills/spells should have a few that are very very
>useful. This way there is a definite reward for choosing various groups.
Offhand I think the total number of distinct skills I have is around 150 though
the list does need a rethink as when it was designed I had a class system in
mind to base it on. Either way I'd like to have each skill used for something
and thus be desirable, but it's going to be a lot of work to get there. :)
>Learning skills in some groups should preclude learning those of another
>group.
That's a key idea I hadn't considered. The problem now becomes which skills
preclude which? Do certain types of skill preclude certain other types, or
can even closely related skills block each other? A danger of this route that
occurs to me is classes via the back door - if you learn magic you can't learn
much combat etc etc.
>Finally, when you start learning which groups of skills people seem to never
>take, try to think of something particularly useful to drop in that group.
That one's definitely a long way down the line. :)
--
Scatter
///\oo/\\\
The Wildman
On 9 Apr 1998 14:29:37 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Scatter ///\oo/\\\
>can even closely related skills block each other? A danger of this route that
>occurs to me is classes via the back door - if you learn magic you can't learn
>much combat etc etc.
>
because you're a mage".
--
The Wildman
Scatter ///oo/\)
In <slrn6iplgt.amt.w...@foobar.net>, wildman-s...@microserve.net (The Wildman) writes:
><sca...@thevortex.com> said the following fighting words:
>>
>>I've decided on a classless system for the mud I'm building, mainly to get away
>>from the cliched mage/fighter/thief/priest moulds and because I feel 'class' to
>>be a highly artificial way to restrict what people can learn. My concern at the
>>moment is how to make sure players don't become clones of each other with
>>all the sames skills and commands.
>>
>>I'd be interested to know what methods you use to prevent that happening?
>giant can learn 25 skills, whereas an elf can learn 50, and a human 40. (I'm
>guessing at the numbers).
I don't think I could use that approach, having a single player race. (Having
lots of different races wandering around the land would not fit my theme,
though I'm happy to add more races in the future, having had time to code
them lands and cities of their own).
However, at a guess, the number of skills learned by the race would presumably
be a function of the average intelligence of the race, so I could apply that to
individual people and restrict the total number of differing skills learned
depending on their intelligence. (Or possible wisdom).
>It is possible to combine flexibility with class-like restrictions. The mud
>I code on uses a point based system with skills and guilds. Skills fall into
>3 categories - those that can be learned on their own, those that can only be
>taught by guilds, and those that the guilds teach only to members.
My plan is to make the only restriction upon learning a skill to be that you
must find someone willing to teach you it (be that player or npc). Practicing
(gaining experience in) a skill means that the cost of learning the next level
in the skill drops, but practicing of itself will never let you learn something
new. I may make the odd exception for 'research' type scenarios.
>Characters can be members of multiple guilds - each guild costs so many
>points (the more guilds you belong to, the fewer points you have to spend on
>skills)
I'm not sure I understand that. So if you were a giant who could learn 25 skills,
you could sacrifice some of those skills in return for being able to choose from
a larger range of available skills?
>The skills that guilds will teach to non-members have a monetary cost. So to
>learn basket weaving from the Too-Much-Time-On-Their-Hands Guild (example
>only) it may cost $10000, as well the points required to learn it.
As far as my npc teachers go, they will 99% of the time charge for training
(or require some service performed in return). Experience points, gained by
using skills, will be associated with the skill used to earn them and will
be used to reduce the amount of training needed for the next level of the
skill.
--
Scatter
///\oo/\\\
Scatter ///oo/\)
Belatedly realising the crossposting I think I'd better point out it is an LPMud
I'm building rather than any other - still most of the points being discussed
can be applied to anything so I won't trim anything from the newsgroups line.
In <352CD751...@micro.ti.com>, Holly Sommer <hso...@micro.ti.com> writes:
>Scatter ///oo/\) wrote:
>
>: I've decided on a classless system for the mud I'm building,
>: mainly to get away from the cliched mage/fighter/thief/priest
>: moulds and because I feel 'class' to be a highly artificial
>: way to restrict what people can learn. My concern at the
>: moment is how to make sure players don't become clones of each
>: other with all the sames skills and commands.
>:
>: I'd be interested to know what methods you use to prevent
>: that happening?
>
>Well, part of the solution to that was built into the server, and
>part of it we added through some tightening. In most MUDs, players
>are distinguished by name, and (race and/or class). We kept names.
>There are no classes. There are quite a few races.
I've dropped classes and have but a single race (as mentioned elsewhere, until
such time as I can build lands and cities as starting points for each race I won't
add those races for players to choose from). This leaves me with name only.
>The total number of skills/spells you can learn in a lifetime are
>restricted by race. A kenku can't learn as many as a human, for
>example. The system which NiM uses is that of a learn-practice
>system. You must first learn a skill/spell, and then you practice
>it. Learn and practice points are gained through leveling. Granted,
>this is a fairly vanilla way of gaining these points, but it works.
Assuming that NiMUD is a Diku derivative, would that mean that
learning the skill makes it available to the player at say 1% and
then that practicing it increases it eventually to 100%?
>Also, stats and attributes (hp, dex, etc.) are very expensive to
>raise, so this blocks the formulaeic approach of "max wis, then con,
>then int, then str, then dex and be a killing machine by the time
>I reach 2/3 maximum mort level."
I intend to fix int/str/dex/con/wis at the moment of character creation -
never to be modified during the game (except temporarily). The reason
being, I see these as being representative of the 'inherent attributes' of
the character, physical things built in that can't be changed. You can
learn to use them better by gaining skills, but if you're just naturally
clumsy then you're never going to be able to dodge very well no matter
what amount of fine detail in the art of dodging you manage to learn.
> Our first Avatar has not maxed more
>than two attributes, and some of his weapons proficiencies need alot
>of work :) (wp, btw, go up with use... skills/spells do not - something
>I'm not all that happy with, so it may change).
That's a nice change from the stock (diku) muds then, whom these days
tend to give a new character sufficiently large amounts of 'trains' that they
can max all their stats in the first room of mud school...
>All this will be somewhat... optionally moot, though, once we
>implement something I've been pushing for a year or so, so if you want
>to see how it works (and it works well, it just could be made even
>more different than it is now), you should check us out sometime
>soon :)
I might just do that.
--
Scatter
///\oo/\\\
The Wildman
On 9 Apr 1998 14:42:26 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Scatter ///\oo/\\\
>
>I'm not sure I understand that. So if you were a giant who could learn 25 skills,
>you could sacrifice some of those skills in return for being able to choose from
>a larger range of available skills?
>
mine (which is MudOS/Foundation II) NiMUD restricts the number of skills
according to race, mine uses a point based system. Points are used for
everything, including skills and guild membership. But you got the gist of
it, which is fewer skills from a wider range.
Of course, you get more points as you go and thus can eventually learn all
the skills. Provided you don't die of old age. Also, you can't start out
being a member of one guild and later on join another guild as well - you
can only choose multiple guilds at creation. (This isn't very realistic, but
there has to be _some_ limit.)
--
The Wildman
Scatter ///oo/\)
In <slrn6ipodu.b03.w...@foobar.net>, wildman-s...@microserve.net (The Wildman) writes:
>froth dripped from his fangs when Scatter ///\oo/\\\
><Sca...@thevortex.com> said the following fighting words:
>>occurs to me is classes via the back door - if you learn magic you can't learn
>>much combat etc etc.
>>
>Well... to me that seems more realistic than saying "you can't steal,
>because you're a mage".
Granted. :)
I think what I would prefer is a system which rather than saying "You are in
the mage class and therefore can never learn to steal" says instead "you are
a bright and intelligent person who is very good at magic but face it, you're
a real clumsy clot and no matter how much tuition you get, you'll never make
a good thief."
I.e. rather than preventing the skill being learned because they are in the
mage class, or because they have learned a different skill already, I'd prefer
that they could learn the skill but just wouldn't be as good at using it.
--
Scatter
///\oo/\\\
Holly Sommer
Scatter ///oo/\) wrote:
: I've dropped classes and have but a single race (as mentioned
: elsewhere, until such time as I can build lands and cities as
: starting points for each race I won't add those races for players
: to choose from). This leaves me with name only.
Well, since names are purely subjective identifiers (not even
quantifiable), if you want some other means of distinguishing
players, you'll need to do it with something like races or guilds.
: Assuming that NiMUD is a Diku derivative, would that mean that
: learning the skill makes it available to the player at say 1% and
: then that practicing it increases it eventually to 100%?
It's a decendant of Merc 2.1 And yes, when you learn it, you "get"
the skill at 1%, and then spending practice points (which, as I
mentioned previously, is a somewhat contrived and stiff
implementation, IMO) will raise it. 100% isn't possible through
use or practice. How many things can you do with 100% accuracy?
(ie: never EVER make a mistake) Guys can't even pee without misting
the toilet seat sometimes... and they've been doing that all their
lives! ;)
: I intend to fix int/str/dex/con/wis at the moment of character
creation -
: never to be modified during the game (except temporarily). The reason
: being, I see these as being representative of the 'inherent
attributes' of
: the character, physical things built in that can't be changed. You can
: learn to use them better by gaining skills, but if you're just
naturally
: clumsy then you're never going to be able to dodge very well no matter
: what amount of fine detail in the art of dodging you manage to learn.
This applies to some attributes, but not all. I don't think intelligence
should change. It seems like a fixed thing (well, for humans who live
in earth,anyhow :) Strength... now this DEFINITELY changes - both
with age and with exercise. Dexterity changes with age. Wisdom
changes with experience (usually). Constitution should be more of a
general "health barometer" than it is, most of the time - perhaps
even tie it in with strength and dexterity, as well as your eating
habits (do you always wait until "You feel hungry."?)
: That's a nice change from the stock (diku) muds then, whom these
: days tend to give a new character sufficiently large amounts of
: 'trains' that they can max all their stats in the first room of mud
: school...
It doesn't sit quite as well with the
numbercrunching-gotta-max-everything
crowd, but.... tough :)
: >All this will be somewhat... optionally moot, though, once we
: >implement something I've been pushing for a year or so, so if you
want
: >to see how it works (and it works well, it just could be made even
: >more different than it is now), you should check us out sometime
: >soon :)
:
: I might just do that.
Hope to see you there :) Check the helpfile on professions if you
drop in. It may be of interest to you.
-Holly (Newman@Grok)
Threshold RPG
In article <6gim0h$kog$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>In <6gijpr$a42$1...@usenet54.supernews.com>, thre...@counseltech.com (Threshold
> RPG) writes:
>>I prefer a class based system for a variety of reasons but thats not the
>>question =).
>
>Just out of interest, why do you prefer a class based system? I'm in the
>interesting position at the moment of having implemented a class system
>in my mudlib a few months ago, and have just recently (whilst polishing off
>the combat system, and 'living' object) decided that I don't really want it.
Well, since you asked...
1) I think classes are realistic in that people often "define" themselves by
what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
computer programmer, etc. There is a natural tendency to have some kind of
class/job/etc. that you use to classify yourself.
2) They provide a good framework for beginning "politics" in your game.
Especially for roleplaying games, classes/guilds provide one of the first
things that "separate" players into groups. This creates loyalties, conflicts,
etc. that can make things exciting. (Clans and other things are similar in
this respect).
3) The help prevent the problem that you addressed in this thread. By dividing
into classes or guilds, you have a more concrete ability to maintain balance.
You can build in limitations to certain classes, and you can make some classes
excel in certain areas. On Threshold, I allow customization within the guild.
Every guild has some abilities that they can design, alter, etc. In some
instances, like the mages who have to research or find new spells through
exploring/finding tutors, there is a lot of customization b/c only those who
are able to find/learn a spell/skill possess it. However, since I still have
the framework of the class, I can be certain that unplanned "super awesome
skill/spell combinations" are not that easily created.
4) I think classes encourage partying. If you need someone with lockpicking
skills, you will try to befriend a thief. If you didn't have classes, you
might just learn that skill yourself instead. Partying is an important part of
social interaction and fun (since MULTIplayer/user is part of the MUD
acronym), and it is also important for roleplaying I think.
Those are some of the main reasons at least. I hope they shed some light on
the situatiobn for you.
Threshold RPG
In article <6gim0h$kog$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>In <6gijpr$a42$1...@usenet54.supernews.com>, thre...@counseltech.com (Threshold
> RPG) writes:
>>
>>group.
>
>That's a key idea I hadn't considered. The problem now becomes which skills
>preclude which?
Well, those are the decisions which will demonstrate how creative of a game
designer you are =)
Threshold RPG
In article <6giohn$kpa$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>In <slrn6ipodu.b03.w...@foobar.net>,
> wildman-s...@microserve.net (The Wildman) writes:
>>froth dripped from his fangs when Scatter ///\oo/\\\
>><Sca...@thevortex.com> said the following fighting words:
>>>
>>because you're a mage".
>
>Granted. :)
>I think what I would prefer is a system which rather than saying "You are in
>the mage class and therefore can never learn to steal" says instead "you are
>a bright and intelligent person who is very good at magic but face it, you're
>a real clumsy clot and no matter how much tuition you get, you'll never make
>a good thief."
>
>I.e. rather than preventing the skill being learned because they are in the
>mage class, or because they have learned a different skill already, I'd prefer
>that they could learn the skill but just wouldn't be as good at using it.
Keep in mind that medieval/fantasy guilds are going to be VERY protective of
their skills and won't take kindly to strangers encroaching on their
bailiwick. Think of this as REALLY REALLY ornery unions =).
Not only would it be VERY hard for a mage, fighter, etc. to find someone to
teach them how to steal, if they were ever discovered doing this, the entire
thieves guild might want to wipe this person out.
There are more factors in why members of a certain class/guild cannot learn
certain abilities besides just what is POSSIBLE for them
physically/intellectually. It is also a factor of the politics and structure
of the society. (imho of course =) )
Matt Chatterley
On Wed, 8 Apr 1998, Holly Sommer wrote:
> Piotr Banski wrote:
>
> : both codebases. The LP comes from the initials of the
> : original creator of this type of server, and Diku was probably
>
> The name "Diku" was the name of the Danish university where the
> server was developed :)
Heh, cute. Now what we all really want to know: Why *Tiny*MUD?
> : As I said above, my experience with diku-style servers is
> : limited, so let me apologize in advance for any blunders,
> : and also ask for corrections. I hope some of the readers
> : will find the following worth adding to/commenting upon.
>
> Mine is pretty much -zero- for Lp, so I can speak from the
> other side of the fence :)
I've blundered around most servers in my time, and also done some work on
things that might not meet intial categorisation as muds, but which I
would certainly consider to be multiuser virtual worlds. :)
> : One of the most apparent features of diku-style muds is
> : the prompt, which is pretty verbose, and which appears
> : roughly every chunk of text output from the server, as
> : opposed to the simple '>' found on most (not all) lps,
> : which I believe 'universally' appears only once per input.
>
> I do believe that every diku derivitive allows you to set the
> prompt to whatever you want - including just a CR - or to turn it
> off entirely. Some people want their prompt to practically list
> all their vital stats plus condition of their opponent. Others
> just want the > so that the scrolling text is broken up some.
Ditto from the LP side of things, many libs allow users to redefine their
prompts to include more or less information. I know that my own lib has
different prompts for each of the 'shells' which exist, as well as the
potential to allow redefinition.
To expand the thread slightly, this is one of the things that makes MUSH
bases look and feel different to others - no 'prompt' to speak of. I
actually find this inconvenient (hard to tell if you're just lagged, or if
its ready to take input).
> : Next, I noticed that I think all diku-style muds I played
> : allow for abbreviating _both_ commands and their arguments,
> : limited only by ambiguity, meaning that in an unambiguous
> : context, 'p b s' is a perfectly well formed input, meaning
> : e.g. 'put bread (into) sack'. (okay, some of those muds
> : allowed this to a greater extent than others)
>
> This is an implementation-specific "feature." The older MUDs
> in the diku family tree require that you type the whole thing out,
> every word (in caveman-speak "put bread bag", rather than "put
> bread in bag"). The newer ones allow for shortening each arg,
> if you want.
And most LPs provide a system of command aliasing, and expansion of
'keywords', for instance aliasing 'p' to put, and setting 'b' to expand to
'bread' and 's' to 'sack'. The more common way that players tend to do
these things are to make short aliases to entire commands, eg: 'pbs' for
'put bread sack'.
A large portion of games offer slightly more flexible aliasing, for
instance 'pt *1 *2: put *2 into *1' and so forth.
> : A short note on the parser is in order. Apart from allowing
> : for abbreviations, the diku-style parser either ignores
> : grammatical words like articles or prepositions, or disallows them
>
> This is also a remnant of older codebases in the diku tree. The
> newer servers allow for articles like at and on - so that if you
> are in a room which has carvings on the walls, and you also have
> a staff with carvings on it, you can specify "look at carvings" or
> "look carvings" to see the ones on the wall, but "look carvings
> staff" or "look at carvings staff" or "look at carvings on staff"
> will yield expected results.
This is something that frequently annoys me on many games (notably LPs,
but I don't visit many Dikus nowadays), being unable to type in various
forms of language and have my commands equally understood. One of my aims
is to ensure that 'take the bread from the bag' works as well as 'take
bag bread' or 'take bread bag'.
[Snip]
> : The newest MudOS global parser is on the opposite pole -
> : it does not generally allow for anything to be 'dropped'.
>
> While this makes for a more elegant and natural-feeling
> command interface for the players, it is not the easiest.
> The aforementioned cavemanspeak is easier... just clunky.
Also, it may not be desirable to universally dump words like 'at', for
instance you may want 'look under', 'look at', 'look through' and so forth
to all behave in different ways, with 'look' on its own defaulting to
something else. :)
> : The next thing - combat - all the diku-style muds I tried do
> : not allow to escape your opponent by just going in some
> : direction - you have to expliciltly 'flee', succeeding or not.
>
> This is definitely a large difference between the two server
> types. Although, it's a pretty trivial change to code, should
> a coder decide to implement it.
Yeah. This is one of those sort of 'design legacy' things, I think.
Speaking personally, my game will not allow you to escape in a direction
of your choice, nor does it provide an explicit 'flee' command to speak of
(although there are equivalents to this), as combat is based upon a
coordinate grid; you must be in close proximity to an exit before you can
use it, and moving closer is done by specifying move direction during
combat and/or applying manouvers such as a 'fighting withdrawal'. You
can't move past or around opponents easily (unless you are significantly
faster, or they are incapacitated), and FWIW, there is also a 'panic' mode
which is applied to characters who have the undergarments scared off them
by particularly intimidating foes.
> : Next, exits - on the 'dikus' I played I haven't seen exits
> : other than the standard 6 directions (one of them might also
> : have the four additional - 'ne', etc. - not sure now).
>
> While the extra four directions aren't *quite* commonplace, they
> *are* standard on some distributions - NiMUD and I think Smaug
> come with them, by default.
>
> There is also the enter/go command, for moving through portals.
One thing which differs LP here is that it tends to provide the ability
for creators to add exits in any direction of their choice, so that a
player might type 'cupboard' to enter a cupboard. Not particularly
desirable to me, but you pays your money..
> : encountering an 'in' or 'porch' exit for a hundred rooms of a new mud
> is
> : not a proof that such an exit doesn't exist somewhere, while for a
> : typical diku-style player encountering one such exit may be something
> : very new.
>
> What is a 'porch' exit?
I think he means whereby you would type 'porch' to go through an exit.
Personally I prefer the use of an 'enter' command (or the in/out verbs) to
non-standard (non-cardinal) exit names.
> : The last thing that comes to my mind is that the diku-style
> : muds I have tried ask you to choose your class at the first
> : login, while the lpmuds generally wait with this until you're
> : in the game.
>
> And then, there is the case of NiMUD, which is classless, or those
> which are multiclass, in which case, the choice you make at login
> time isn't as life-determining as in a single-class MUD.
Yup.
> : I will be grateful for comments on / additions to the points above.
>
> There are mine. Surely leaning toward a particular server, but with
> enough general diku-esque information to be of use, I hope.
Interestingly enough, the underlying feeling that I pick up from this
thread so far is that the codebases are a lot more alike than many people
may suspect, believe, or in some cases, like.
--
Regards,
-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html
Cimri
I love classless systems myself. There are lotsa pretty easy things
to do to avoid the 'cookie cutter player' result. Here's one:
Get rid of that stupid 0-100 scale for skills. Make all actions
a comparison of skill, difficulty, and counterskill (if present).
This replaces the system where we all learn skills up to
100, or near it, and that 100 means I succeed 100% of the time,
and then maybe some counterskill cuts down on that (e.g. I swing
with a weapon, skill 100, so it hits, but then your 'dodge' skill
has a certain chance of working, and then your 'parry' skill has
a certain chance, etc.)
So I could have any skill value, 0 to <large>. And each action
takes my skill, say, 120, and compares it to the relevant difficulty
of the act (say, jump kicking from 20' away, which would be VERY
difficult) and perhaps some counterskills and characteristics on
the side of the person being attacked.
I think it works out quite well in practice, and nobody ever reaches
the top in any skill, since there is none.
Jay
Scatter ///oo/\) wrote:
>
> In <352BE723...@micro.ti.com>, Holly Sommer <hso...@micro.ti.com> writes:
> >michael...@abnamro.com wrote:
>
> >: > And then, there is the case of NiMUD, which is classless,
> >: Really? I don't think I've ever played on a NiMUD.
> >Yeah, NiM is classless by default. I'm not surprised you've never
> [snip]
> >: I generally like classless games.. It ends a lot of the 'cookie
> >: cutter character' syndrome.
> >So long as it doesn't end up achieving the same thing as a
> >multiclass game does. That is to say: everyone can learn every
> >spell or skill, because it's not a single-class MUD.
>
> I've decided on a classless system for the mud I'm building, mainly to get away
> from the cliched mage/fighter/thief/priest moulds and because I feel 'class' to
> be a highly artificial way to restrict what people can learn. My concern at the
> moment is how to make sure players don't become clones of each other with
> all the sames skills and commands.
>
> I'd be interested to know what methods you use to prevent that happening?
> --
> Scatter
> ///\oo/\\\
m.g.w...@usa.net
I think Aristotle made a few good points about why you would want to use
classes in your game.. As somebody from a game that has gotten rid of them, I
would like to present the other side of the coin..
In article <6gisht$ia5$1...@usenet49.supernews.com>,
thre...@counseltech.com (Threshold RPG) wrote:
>
> 1) I think classes are realistic in that people often "define" themselves by
> what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
> computer programmer, etc. There is a natural tendency to have some kind of
> class/job/etc. that you use to classify yourself.
This is true. Classes have a certain degree of realism, in that many people
share certain common professions, and a lot of people also define themselves
by their professions. However, a skill-based system doesn't preclude players
from following a particular archetype, say fighter or starship engineer. And
classes have a limited usefulness outside of a fantasy environment, as the
number of available professions grows quickly. A skill based system will also
allow for more individualized characters, for instance a thief who dabbles in
magic or a bounty hunter who also happens to be an ordained minister. You can
become a jack of all trades, but I've found that these characters are far less
powerful than those who specialize.
>
> 2) They provide a good framework for beginning "politics" in your game.
> Especially for roleplaying games, classes/guilds provide one of the first
> things that "separate" players into groups. This creates loyalties,
conflicts,
> etc. that can make things exciting. (Clans and other things are similar in
> this respect).
True. But classes are not the only way to do this. They are not even the
most realistic way. Some groups, like mages or thieves, may have good reason
to congregate together, usually for mutual protection. But not every member
of this profession would share the same views. They would more likely form
seperate groups that may be violently opposed to each other, as one magical
school views the other's work as heresy, and one thieves guild strives against
another for control of a city. And some groups, like warriors, are
everywhere! For every cause you can think of, there is an army of warriors
fighting for it. Considering that the class's most likely profession is to be
employed fighting another of their own, would that lend them to a strong guild
association?
Instead, I'd suggest a guild system that's not based on profession. A band of
murders and thieves would very likely include fighters and mages in their
number, possibly outnumbering those who can actually pick pockets well. A
religion needs followers of all types, not just clergy. A merchant family
would hire anyone who had useful skills. Where would an army be without
spies, medics, and magical firepower?
>
> 3) The help prevent the problem that you addressed in this thread. By
dividing
> into classes or guilds, you have a more concrete ability to maintain
balance.
> You can build in limitations to certain classes, and you can make some
classes
> excel in certain areas. On Threshold, I allow customization within the
guild.
> Every guild has some abilities that they can design, alter, etc. In some
> instances, like the mages who have to research or find new spells through
> exploring/finding tutors, there is a lot of customization b/c only those who
> are able to find/learn a spell/skill possess it. However, since I still have
> the framework of the class, I can be certain that unplanned "super awesome
> skill/spell combinations" are not that easily created.
The problem addressed was the jack-of-all-trades syndrome, wasn't it? Don't
forget the second part of that saying: "Master of none." If you balance the
difficulty of skill progression well, it will become uneconomical to remain a
jack for long. If you don't specialize in something, you won't get far. You
may be able to specialize in a few things, if you're talented, and those
combinations can be very unusual, and very interesting. The secret is to have
enough skills to spread out players' options, and make advancement
exponentially more difficult as levels increase.
>
> 4) I think classes encourage partying. If you need someone with lockpicking
> skills, you will try to befriend a thief. If you didn't have classes, you
> might just learn that skill yourself instead. Partying is an important part
of
> social interaction and fun (since MULTIplayer/user is part of the MUD
> acronym), and it is also important for roleplaying I think.
True. We find particularly that thief skills are being picked up as common
'backup skills'. This has shown us that players may find these skills useful
at times, but aren't willing to specialize in them. This has pointed out a
deficiency in our library: there isn't enough use for these thief skills!
This is a pair of very interesting reason to eliminate classes: The directions
players take in developing characters is *very* interesting, and the choices
they *don't* make are very illuminating to designers.
Once you balance your game to eliminate the 'Jack' element, you'll find that
players aren't any less likely to party now than they were before. If you add
in quests and monsters that can't be tackled alone, that will more than make
up for any drop in partying.
>
> Those are some of the main reasons at least. I hope they shed some light on
> the situatiobn for you.
>
> -Aristotle@Threshold
>
Again, I think Aristotle made some excellent points. I hope my counter-points
were just as illuminating.
Mike Willey, soon returning as Mickelian@DreamShadow
(reply to michael dot willey at abnamro dot com)
The Wildman
On Thu, 09 Apr 1998 10:39:42 -0500, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Holly Sommer <hso...@micro.ti.com> said
the following fighting words:
>It's a decendant of Merc 2.1 And yes, when you learn it, you "get"
>the skill at 1%, and then spending practice points (which, as I
>mentioned previously, is a somewhat contrived and stiff
>implementation, IMO) will raise it. 100% isn't possible through
>use or practice. How many things can you do with 100% accuracy?
skill levels instead.
>(ie: never EVER make a mistake) Guys can't even pee without misting
>the toilet seat sometimes... and they've been doing that all their
>lives! ;)
You try to pee standing up while drunk or half asleep. In fact, I'll bet you
fair no better while sober and fully awake :D
--
The Wildman
The Wildman
On Thu, 09 Apr 1998 16:30:15 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Threshold RPG <thre...@counseltech.com>
said the following fighting words:
>
>certain abilities besides just what is POSSIBLE for them
>physically/intellectually. It is also a factor of the politics and structure
>of the society. (imho of course =) )
>
Since fantasy worlds are not subject to reality checks, you could have
guilds that teach anybody anything if you wanted.
--
The Wildman
The Wildman
On Thu, 9 Apr 1998 00:24:01 +0000, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Matt Chatterley <ma...@mpc.dyn.ml.org> said
the following fighting words:
>
>Heh, cute. Now what we all really want to know: Why *Tiny*MUD?
>is to ensure that 'take the bread from the bag' works as well as 'take
>bag bread' or 'take bread bag'.
bread?
--
The Wildman
The Wildman
On Thu, 09 Apr 1998 16:25:21 GMT, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Threshold RPG <thre...@counseltech.com> said
the following fighting words:
>1) I think classes are realistic in that people often "define" themselves by
>what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
>computer programmer, etc. There is a natural tendency to have some kind of
>class/job/etc. that you use to classify yourself.
in the army on a rotational basis, so I know how to swing a sword, too.
--
The Wildman
Holly Sommer
The Wildman wrote:
: I've always despised that skill percentage thing. FWIW the mud
: I'm coding uses skill levels instead.
A man after my own heart :) Either that or Great Minds... ;)
: You try to pee standing up while drunk or half asleep. In fact,
: I'll bet you fair no better while sober and fully awake :D
Heh. I know my limits. Dribbling is out. However, I can say with
certainty, actually, that my pee skill as a female is at 100% :)
Also, never been drunk, and I don't intend to - not even to see
how poor my aim becomes :)
-Holly
Nathan Alexander Simington
Scatter ///oo/\) wrote:
> >Also, stats and attributes (hp, dex, etc.) are very expensive to
> >raise, so this blocks the formulaeic approach of "max wis, then con,
> >then int, then str, then dex and be a killing machine by the time
> >I reach 2/3 maximum mort level."
>
> I intend to fix int/str/dex/con/wis at the moment of character creation -
> never to be modified during the game (except temporarily). The reason
> being, I see these as being representative of the 'inherent attributes' of
> the character, physical things built in that can't be changed. You can
> learn to use them better by gaining skills, but if you're just naturally
> clumsy then you're never going to be able to dodge very well no matter
> what amount of fine detail in the art of dodging you manage to learn.
>
> > Our first Avatar has not maxed more
> >than two attributes, and some of his weapons proficiencies need alot
> >of work :) (wp, btw, go up with use... skills/spells do not - something
> >I'm not all that happy with, so it may change).
>
> That's a nice change from the stock (diku) muds then, whom these days
> tend to give a new character sufficiently large amounts of 'trains' that they
> can max all their stats in the first room of mud school...
Er...not are diku muds are stock, nor does the stock code allow in-
creasing stats via training. You are thinking of Envy or Merc muds,
which are a specific family of diku derivatives. I have no idea of
NiMud's derivation, so perhaps Holly could inform me here whether its
training system was inherited, or is original. In any case, there are
many notable dikumuds that exclude stat training, such as JediMUD and
Toril, to name two examples off the top of my head.
Also, if the mud admin think that all PCs deserve to max stats in the
first room of mud school, then I need see no more to know that that mud
sucks big chunks of granite. :)
Nathan
Matt Chatterley
On 9 Apr 1998, The Wildman wrote:
> On Thu, 9 Apr 1998 00:24:01 +0000, Wildman's eyes rolled up in his head and
> froth dripped from his fangs when Matt Chatterley <ma...@mpc.dyn.ml.org> said
> the following fighting words:
> >
> >Heh, cute. Now what we all really want to know: Why *Tiny*MUD?
> Because, compared to MUDs, TinyMUDs are _tiny_.
>
> >is to ensure that 'take the bread from the bag' works as well as 'take
> >bag bread' or 'take bread bag'.
> But which is it? Take the bread from the bag, or take the bag from the
> bread?
In the latter case, I think a system should be clever enough to swap the
arguments, and test if it works in reverse *before* returning an error. :)
m.g.w...@usa.net
In article <6giusr$ict$1...@gte1.gte.net>,
ci...@technologist.com wrote:
>
> I love classless systems myself. There are lotsa pretty easy things
> to do to avoid the 'cookie cutter player' result. Here's one:
>
> Get rid of that stupid 0-100 scale for skills. Make all actions
> a comparison of skill, difficulty, and counterskill (if present).
>
> This replaces the system where we all learn skills up to
> 100, or near it, and that 100 means I succeed 100% of the time,
> and then maybe some counterskill cuts down on that (e.g. I swing
> with a weapon, skill 100, so it hits, but then your 'dodge' skill
> has a certain chance of working, and then your 'parry' skill has
> a certain chance, etc.)
>
> So I could have any skill value, 0 to <large>. And each action
> takes my skill, say, 120, and compares it to the relevant difficulty
> of the act (say, jump kicking from 20' away, which would be VERY
> difficult) and perhaps some counterskills and characteristics on
> the side of the person being attacked.
>
> I think it works out quite well in practice, and nobody ever reaches
> the top in any skill, since there is none.
[Mickelian *boggles*]
Good point.. I had forgotten that some people still do skills on some 0 to
<max> point system... We've been doing it so long this way, I completely
forgot there was another option ;-)
The Wildman
On Thu, 9 Apr 1998 20:25:37 +0000, Wildman's eyes rolled up in his head and
froth dripped from his fangs when Matt Chatterley <ma...@mpc.dyn.ml.org> said
the following fighting words:
>arguments, and test if it works in reverse *before* returning an error. :)
>
out. What happens if you have a bag inside a box, and a box inside a bag?
--
The Wildman
John Bertoglio
Some Thoughts on Classes
The key to classes is building a skill system in a tree which directs people
down a certain road but does not require it. It is easier for a RL lawyer to
become a better lawyer than to be come a journeyman lumberjack...but not
impossible. Our system uses character archtypes which model traditional
classes by making skill bundles available for a "discount" during character
creation. This creates psuedo-classes which conform to the benefits of
classes described by Aristotle but still allowing for growth and a
'mid-life' crisis where the character takes a different road.
Balance is the key here or you end up with the "Everyone's a Tank-Mage" trap
found in Orign's Ultima Online. In that game no matter how you start,
characters will end up about the same in the end. (Note: UO has many flaws
but since it has a huge team working to make it better, good ideas are bound
to be developed there. No... I don't like graphic based online games. Take a
look at their new character rating system. It uses an two dimentional array
to slot characters based on their behaviour. Looks like a good way to reward
roleplaying behavior).
John Bertoglio
www.paper.net
Threshold RPG wrote in message <6gisht$ia5$1...@usenet49.supernews.com>...
>In article <6gim0h$kog$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter
///\oo/\\\) wrote:
>>In <6gijpr$a42$1...@usenet54.supernews.com>, thre...@counseltech.com
(Threshold
>> RPG) writes:
>>>I prefer a class based system for a variety of reasons but thats not the
>>>question =).
>>
>>Just out of interest, why do you prefer a class based system? I'm in the
>>interesting position at the moment of having implemented a class system
>>in my mudlib a few months ago, and have just recently (whilst polishing
off
>>the combat system, and 'living' object) decided that I don't really want
it.
>
>Well, since you asked...
>
> <SNIPED: Four good arguments for classes>
>
>Those are some of the main reasons at least. I hope they shed some light on
>the situatiobn for you.
>
>-Aristotle@Threshold
>
mor...@niuhep.physics.niu.edu
sca...@thevortex.com (Scatter ///\oo/\\\) writes:
>Holly Sommer <hso...@micro.ti.com> writes:
>>michael...@abnamro.com wrote:
>
>>: > And then, there is the case of NiMUD, which is classless,
>>: Really? I don't think I've ever played on a NiMUD.
>>Yeah, NiM is classless by default. I'm not surprised you've never
>[snip]
>>: I generally like classless games.. It ends a lot of the 'cookie
>>: cutter character' syndrome.
>>So long as it doesn't end up achieving the same thing as a
>>multiclass game does. That is to say: everyone can learn every
>>spell or skill, because it's not a single-class MUD.
>I've decided on a classless system for the mud I'm building, mainly to get
>away from the cliched mage/fighter/thief/priest moulds and because I feel
>'class' to be a highly artificial way to restrict what people can learn.
>My concern at the moment is how to make sure players don't become clones
>of each other with all the sames skills and commands.
>I'd be interested to know what methods you use to prevent that happening?
Guilds, It is easier to get training if you belong to a particular guild.
Training is much easier for starting a skill than trying to do it
on your own. The guilds don't all get along.
Another way is to make characteristics VERY important in ability
to learn and ability to succeed, and then limit character creation
in such a way as to keep people from being better than mediocre in more
than one or two areas.
create a world in which /not/ being a competent fighter is /not/ a death
sentence. Make things interesting for good thieves or good mages or ...
Robert
who hopes to succeed in implementing the first and third methods.
Piotr Banski
The Wildman (wildman-s...@microserve.net) wrote:
: >Heh, cute. Now what we all really want to know: Why *Tiny*MUD?
: Because, compared to MUDs, TinyMUDs are _tiny_.
Last time I heard, they were everything _but_ tiny :)
P.
Cimri
Bravo Mr. Bertoglio! I agree completely. Glad to hear someone
write so well :-)
John Bertoglio wrote:
>
> Some Thoughts on Classes
>
> The key to classes is building a skill system in a tree
> which directs people down a certain road but does not require it.
<snippetia>
> John Bertoglio
> www.paper.net
>
Holly J. Sommer
Nathan Alexander Simington wrote:
> I have no idea of NiMud's derivation, so perhaps Holly could inform me here
> whether its training system was inherited, or is original.
NiMUD followed Merc 2.1 in heirarchy, but doesn't much resemble it, to the player.
The
training system is different than Merc's, so I can only assume it was of Locke's own
invention. He would be the definitive source for answering this, though.
-Holly
Jason Goodwin
In article <6gji73$8vl$1...@nnrp1.dejanews.com>, <m.g.w...@usa.net> wrote:
>In article <6giusr$ict$1...@gte1.gte.net>,
>> Get rid of that stupid 0-100 scale for skills. Make all actions
>> a comparison of skill, difficulty, and counterskill (if present).
>> This replaces the system where we all learn skills up to
>> 100, or near it, and that 100 means I succeed 100% of the time,
>> and then maybe some counterskill cuts down on that (e.g. I swing
>> with a weapon, skill 100, so it hits, but then your 'dodge' skill
>> has a certain chance of working, and then your 'parry' skill has
>> a certain chance, etc.)
>[Mickelian *boggles*]
>Good point.. I had forgotten that some people still do skills on some 0 to
><max> point system... We've been doing it so long this way, I completely
>forgot there was another option ;-)
There are quite a few other options. Hmmm, come to think of it,
how many types of systems are there? and which are optimized
for a computerized system of dealing with skill checks?
For instance, Shadowrun uses a system that marks your ability in
skills by how many dice you can roll to pass a skill check.
For instance, if I have sharp shooting at a 6, then I roll
6 dice (6 siders) to pass the skill check. Each level of
difficulty has a different number I have to surpass.
this allows for a truly huge skill rating with a smaller storage
space. downside? All those random die rolls, I think. I'm not
up to date on the how optimized it is.
Nathan Alexander Simington
Holly Sommer wrote:
>
> The Wildman wrote:
>
> : You try to pee standing up while drunk or half asleep. In fact,
> : I'll bet you fair no better while sober and fully awake :D
>
> Heh. I know my limits. Dribbling is out. However, I can say with
> certainty, actually, that my pee skill as a female is at 100% :)
> Also, never been drunk, and I don't intend to - not even to see
> how poor my aim becomes :)
>
> -Holly
No wonder this thread is titled 'classless muds' :P
In the words of Tarantino, via Uma Thurman, "That's a bit more infor-
mation than I needed.'
Actually, it's funny to see this once. But try to remain germaine to the
newsgroup topic (=
Nathan
Joseph B Fritz
IMHO what skills you learn and how good you are at useing them should be
based on stats.
IE a player with a very high dex and int could be an excelllent mage and
thief but if their strength was low they
might not be a good fighter. In this case you need to decide which skills
apply to the skill and decide how well
a given player can learn it from that.
Sincerly
Necroscope
(If I had Telnet access would be at aftershock.mudservices.com:5000)
Scatter ///oo/\) wrote
>>>can even closely related skills block each other? A danger of this route
that
>>>occurs to me is classes via the back door - if you learn magic you can't
learn
>>>much combat etc etc.
>>>
>>Well... to me that seems more realistic than saying "you can't steal,
>>because you're a mage".
>
>Granted. :)
>I think what I would prefer is a system which rather than saying "You are
in
>the mage class and therefore can never learn to steal" says instead "you
are
>a bright and intelligent person who is very good at magic but face it,
you're
>a real clumsy clot and no matter how much tuition you get, you'll never
make
>a good thief."
>
>I.e. rather than preventing the skill being learned because they are in the
>mage class, or because they have learned a different skill already, I'd
prefer
>that they could learn the skill but just wouldn't be as good at using it.
>
>--
>Scatter
>///\oo/\\\
>
John Adelsberger
Cimri (cim...@gte.net) wrote:
: Bravo Mr. Bertoglio! I agree completely. Glad to hear someone
: write so well :-)
Its worth noting that Mr. Bertoglio's ideas have been around for a long
time. Discworld has such a system, and has for many, many moons, and
several of the descendants of the DW mudlib have refined the skill tree
to the point at which class(some call it guild) is more a description
of a chosen profession than of the skills the individual possesses.
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
Threshold RPG
In article <slrn6iq3um.bq6.w...@foobar.net>, wildman-s...@microserve.net wrote:
>On Thu, 09 Apr 1998 16:25:21 GMT, Wildman's eyes rolled up in his head and
>froth dripped from his fangs when Threshold RPG <thre...@counseltech.com>
> said
>the following fighting words:
>>what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
>>computer programmer, etc. There is a natural tendency to have some kind of
>>class/job/etc. that you use to classify yourself.
>
>Ok... I'm a basket weaver. Our king requires every able-bodied man to serve
>in the army on a rotational basis, so I know how to swing a sword, too.
Blah blah. Thats a nice example. However, for the most part, when people want
to learn VERY complex skills, like spell casting, they aren't going to be able
to be journeymen like that.
Dominic J. Eidson
On Thu, 9 Apr 1998, Threshold RPG wrote:
> What if your character doesnt currently know what direction is north? Then you
> need left, right, straight, back, or some other exit? What if the object is
> something that can be entered from a variety of angles, and thus it really is
> inaccurate to say you are going "east" to enter it.
I have some notes somewhere lying around from when Is tarted designing a
way to replace the standard 6 exits (Yes, I admit to it) that are on my
mud. What I had planned was a way to change north, west, south and east
to left of, behind, in front of and right of - as directions, and these
would change depending on the way you entered the room. A direction that
would face west (provided you used a compass), when you came from the
south, would be to your left, but if you entered from the north, it would
be to your right... However, the implementation of this was a little
bit too much for me at the time, but maybe I should dig out the notes and
revise it again before I try to implement it.
Nick
The Infinite Point
-----------------------------------------------------------------------------
Implementor http://www.kdi.com/~infinite
Head Programmer
cyberwizards.com 6000
hub.kdi.com 6000
208.21.240.2 6000
-----------------------------------------------------------------------------
Peter S. Young
Heh... just finished doing this on my code base... it is a pain... fun
though... now when people get stuck in the dark... if they're not carful,
they'll really be stuck in the dark.
otoh, I think that the NEWSUD is nice in that the computer/mud sorta knows
how rooms are arranged relative to each other. It's not utterly perfectly
(actually, it's far from it), but the computer can assume a sort of
gemoetry then...
On that note, has anyone ever managed to make a completely grided 2D or 3D
system? I wanted to do this, but there were a couple problems:
1) Room descriptions... how?
2) Space... this was ugly.
3) Converting everything... the ABs would have lynched me, I think.
4) Revamping the OLC... 'nother hard to do thing.
5) Movement... I'd wanted the grid to be the same one used for combat...
only, this would mean that each move took 1 - 5 seconds... or there's a
1 : 5 ratio of real time to game time. Which makes a majority of
things take a long, long time. (Did anyone ever figure out a solution
to this? I keep meaning to try to prove that no solution exists (i.e.,
you can't have players moving a different time speeds), but I've never
gotten around to it.)
Matt Chatterley
On 9 Apr 1998, Jason Goodwin wrote:
> In article <6gji73$8vl$1...@nnrp1.dejanews.com>, <m.g.w...@usa.net> wrote:
> >In article <6giusr$ict$1...@gte1.gte.net>,
> >> Get rid of that stupid 0-100 scale for skills. Make all actions
> >> a comparison of skill, difficulty, and counterskill (if present).
>
> >> This replaces the system where we all learn skills up to
> >> 100, or near it, and that 100 means I succeed 100% of the time,
> >> and then maybe some counterskill cuts down on that (e.g. I swing
> >> with a weapon, skill 100, so it hits, but then your 'dodge' skill
> >> has a certain chance of working, and then your 'parry' skill has
> >> a certain chance, etc.)
>
> >[Mickelian *boggles*]
> >Good point.. I had forgotten that some people still do skills on some 0 to
> ><max> point system... We've been doing it so long this way, I completely
> >forgot there was another option ;-)
>
> There are quite a few other options. Hmmm, come to think of it,
> how many types of systems are there? and which are optimized
> for a computerized system of dealing with skill checks?
There are literally as many systems as you can imagine (granted they are
not all practical to use). A number draw from existing RPGs, and others
come from formulae which the creator(s) found to provide a reasonable
model. Others come from simplifications of these principles; in short they
all relate back to a statistical model as far as I see, *but* since I am
in part a maths student, and other part physicist, I tend to break things
down this way subconciously. :)
> For instance, Shadowrun uses a system that marks your ability in
> skills by how many dice you can roll to pass a skill check.
>
> For instance, if I have sharp shooting at a 6, then I roll
> 6 dice (6 siders) to pass the skill check. Each level of
> difficulty has a different number I have to surpass.
>
> this allows for a truly huge skill rating with a smaller storage
> space. downside? All those random die rolls, I think. I'm not
> up to date on the how optimized it is.
I don't really like the shadowrun model, although it has one or two good
points and bad points that I'll list:
At low skill levels, gaining one point is very significant (1-6 better),
while at high levels it is not so dramatic (going from 199d6 to 200d6
for instance).
It's too random. If you had a rating of 200 in a skill, you roll 200d6,
and come up with 200-1200 as a result; quite a dramatic spread. Now, you
may consider a solution is just not to use this many 'points', but I
suspect most people want a very 'smooth' transition from novice to expert,
and thus a lot of levels inbetween (my own system uses 1000).
Some other interesting notions about skill-systems:
The skill tree (or web) idea, which allows interlinked and reliant skills
(for instance, to be an expert in sharpshooting, you must also be good
with handguns in general; the skills show inheritance in one or arguably
both directions).
Skills do not have to be static! They can go *down* as well as up..
Matt Chatterley
On Fri, 10 Apr 1998, Dominic J. Eidson wrote:
>
> > What if your character doesnt currently know what direction is north? Then you
> > need left, right, straight, back, or some other exit? What if the object is
> > something that can be entered from a variety of angles, and thus it really is
> > inaccurate to say you are going "east" to enter it.
>
> way to replace the standard 6 exits (Yes, I admit to it) that are on my
> mud. What I had planned was a way to change north, west, south and east
> to left of, behind, in front of and right of - as directions, and these
> would change depending on the way you entered the room. A direction that
> would face west (provided you used a compass), when you came from the
> south, would be to your left, but if you entered from the north, it would
> be to your right... However, the implementation of this was a little
> bit too much for me at the time, but maybe I should dig out the notes and
> revise it again before I try to implement it.
I've certainly given some thought to a system which listed possible exits
relative to each individual. The 'world' would be built around a three
dimensional compass (or two dimensional if you don't care about up or
down), and exits from a room given as coordinates or bearings (when being
'installed' by a creator). The orientation of a PC would be stored (eg:
bearing that they are facing and/or moving in), and exits calculated
relative (eg: 'left' would be assigned to the 180-360 quadrant, and right
to the other half). It might be good to divide commands to turn, and move
separately.
This seems over complicated for personal movement, but is probably the
only sane way to handle vehicle movement is most situations.
Has anyone considered, constructed, or seen a mud based soley around
piloting craft of some fashion? It's an interesting idea.
John Bertoglio
On Classless Skill Systems:
Some other suggestions.
General comment. The idea of classes is a good one. A party of specialists
whose skills form an interdependent group creates a great role playing
experience. The reason to avoid conventional classes is to avoid the classic
D&D concept, "You're a mage, you can't wear armor" and all the goofiness
surrounding arbitrary limits.
1) Strong grounding skills form prerequisites for other skills. A perfect
example is literacy....a skill that should be very "expensive" in any
fantasy setting. It should be even more expensive if learned later in life.
That way if Conan decides he wants to be Merlin, this path will be very
difficult and mage skills will come slowly because of the slow learning rate
due to a weak grounding in reading.
2) Make some precursor skills only available during character creation. If
character was raised by wolves...so be it. You get a skill bundle which
includes certain skills which cannot be acquired any other way (in this
example, say, Animal Empathy). Say a particularly powerful form of magic is
found in a culture which trains its adepts at an early age....same
thing...not born into that culture, no access to the form of magic. If you
can't read Drewish, you cannot advance in the art...
3) Make exception to the rules, but exact a price. Perhaps the Drews above
have a monastery which will accept one player at a time as a junior
adept...complete a difficult quest for them, wash their roof...something
that is a challenge and you're in. During the initiation ritual the head
Drew says that some of your arts are incompatible with the Way of the
Drews..if you accept their training you will find your ability to use
weapons severely diminished...or some other penalty...like a reduction in
STR because of the intellectual rigors of the training...
Cimri wrote in message <6giusr$ict$1...@gte1.gte.net>...
>
>Get rid of that stupid 0-100 scale for skills. Make all actions
>a comparison of skill, difficulty, and counterskill (if present).
4) Absolutely, allow skills to go above 100...use the extra numbers to
modify chances for critical success and failure. But make improvement move
much slower at higher levels. Robin Hood has a 300 skill in archery...he
will probably always hit a stationary target. The rare critical failure for
him might be comical event (broken bow string, trips on a grue...could
happen to anyone). He shoots an arrow a Jackie Chan who has an unarmed
combat of 300....a clash of skills is calculated and Jackie comes up the
winner. The server tells the player that Jackie catches the arrow in his
teeth (ok, a little absurd, just trying to make a point.) It is important to
always allow for success and failure, even at high and low skill levels. A
newbie named David got Goliath with a rock. Even the best miss once in a
while. The uncertainty lends fun to the game.
>
>This replaces the system where we all learn skills up to
>100, or near it, and that 100 means I succeed 100% of the time,
>and then maybe some counterskill cuts down on that (e.g. I swing
>with a weapon, skill 100, so it hits, but then your 'dodge' skill
>has a certain chance of working, and then your 'parry' skill has
>a certain chance, etc.)
5) Skill interaction is critical to creating balance and a believable world.
When Gods battle, the balance is the same as newbies...just more thunder and
smoke.
>
><SNIP>
Peter S. Young
Actually, if I remember correctly, shadow run doesn't add up the rolls...
what happens is, they give you a number to beat... sometimes modded by an
attribute... this is one part of the difficulty. Now, you get <x> number
of dice to roll, each time you get over (or equal, can't remember) to the
number, you get a success. The second half of the difficulty is how many
successes you needed. It's fairly decent as probability goes, and you can
scale difficulties. An interesting thing, is that if your skill is low
enough, there are things you *can't* do... they require more success than
you have dice to roll. - Peter Young
On Fri, 10 Apr 1998, Matt Chatterley wrote:
> I don't really like the shadowrun model, although it has one or two good
> points and bad points that I'll list:
>
> At low skill levels, gaining one point is very significant (1-6 better),
> while at high levels it is not so dramatic (going from 199d6 to 200d6
> for instance).
>
> It's too random. If you had a rating of 200 in a skill, you roll 200d6,
> and come up with 200-1200 as a result; quite a dramatic spread. Now, you
> may consider a solution is just not to use this many 'points', but I
> suspect most people want a very 'smooth' transition from novice to expert,
> and thus a lot of levels inbetween (my own system uses 1000).
>
> Some other interesting notions about skill-systems:
>
> The skill tree (or web) idea, which allows interlinked and reliant skills
> (for instance, to be an expert in sharpshooting, you must also be good
> with handguns in general; the skills show inheritance in one or arguably
> both directions).
>
> Skills do not have to be static! They can go *down* as well as up..
>
David Skidmore
On Thu, 9 Apr 1998, Matt Chatterley wrote:
> On 9 Apr 1998, The Wildman wrote:
>
> > On Thu, 9 Apr 1998 00:24:01 +0000, Wildman's eyes rolled up in his head and
> > froth dripped from his fangs when Matt Chatterley <ma...@mpc.dyn.ml.org> said
> > the following fighting words:
> > >
> > >Heh, cute. Now what we all really want to know: Why *Tiny*MUD?
> > Because, compared to MUDs, TinyMUDs are _tiny_.
> >
> > >is to ensure that 'take the bread from the bag' works as well as 'take
> > >bag bread' or 'take bread bag'.
> > But which is it? Take the bread from the bag, or take the bag from the
> > bread?
>
> In the latter case, I think a system should be clever enough to swap the
> arguments, and test if it works in reverse *before* returning an error. :)
Actually, the latter case is the correct one. 'take bread bag' removes a
bread-thing from a bag-thing. It you typed 'take bag bread', and the bread
was in the bag, then (on the MUD I play most, anyhow) it says "I see no bread
here", which makes sense, because there is no bread except what's in the bag.
If the bread isn't in the bag, or there is some both in and out, and you type
'take bag bread' it says "That's not a container.", because this particular
bread isn't. If it was a container, then you couldn't eat it, because of the
way objects work in Diku-deriv. MUDs. This could be changed, but it's just
not done, because no-one, (except perhaps Matt Chatterly?) really gives a
care, and just uses objects for what they appear to be for.(i.e. bread for
eating, bags for holding stuff)
> Regards,
> -Matt Chatterley
Just my few thoughts from diku-land,
--Raptor
Scatter ///oo/\
Threshold RPG intoned these words...
>In article <6giohn$kpa$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>
>>I.e. rather than preventing the skill being learned because they are in the
>>mage class, or because they have learned a different skill already, I'd prefer
>>that they could learn the skill but just wouldn't be as good at using it.
>
>their skills and won't take kindly to strangers encroaching on their
>bailiwick. Think of this as REALLY REALLY ornery unions =).
>
>Not only would it be VERY hard for a mage, fighter, etc. to find someone to
>teach them how to steal, if they were ever discovered doing this, the entire
>thieves guild might want to wipe this person out.
One thing I'm hoping to get away from in dropping classes is the concept
of mud-wide guilds that restrictively teach one class alone. To learn skills
won't be a simple 'go to your local guild branch and type "advance"' -
players will need to seek out teachers willing to teach them, be those
teachers npc or player. Npc teachers may have some exacting requirements
before they will teach, a thief teacher might be highly unlikely to
teach this big strong player who strides up clanking armour all over the
place, but might actively want to teach the player who sneaks up behind
him without being noticed. On the other hand, if that big strong player
offers enough money...
Things like a thieves guild might exist, but is unlikely to have much
influence beyond the city where it is based, though indeed it may have
contacts in other cities...
Ideally I'd like to get players role-playing this sort of thing - player
thieves ganging up to wipe out that other player who dared to teach the
fighter to steal...
>There are more factors in why members of a certain class/guild cannot learn
>certain abilities besides just what is POSSIBLE for them
>physically/intellectually. It is also a factor of the politics and structure
>of the society. (imho of course =) )
Agreed - I'd like to make the latter the only restrictions on what can be
learned. :)
--
Scatter ///\oo/\\\
Scatter ///oo/\
Threshold RPG intoned these words...
>>
>>Just out of interest, why do you prefer a class based system?
>
>1) I think classes are realistic in that people often "define" themselves by
>what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
>computer programmer, etc. There is a natural tendency to have some kind of
>class/job/etc. that you use to classify yourself.
What I'm hoping is that people will do exactly that - classify themselves
rather than have the computer do it for them.
>2) They provide a good framework for beginning "politics" in your game.
>Especially for roleplaying games, classes/guilds provide one of the first
>things that "separate" players into groups. This creates loyalties, conflicts,
>etc. that can make things exciting. (Clans and other things are similar in
>this respect).
That's true, although I have noticed that the interaction that begins this
way tends to be of the 'wimpy mage/dumb fighter' type. :)
>3) They help prevent the problem that you addressed in this thread.
Indeed, they eliminate it. :)
{snip}
>
>4) I think classes encourage partying.
Now that's a good reason, and definitely true.
>If you need someone with lockpicking
>skills, you will try to befriend a thief. If you didn't have classes, you
>might just learn that skill yourself instead.
Hopefully I can skew the difficulties such that it is much easier to get
a trained thief to help you rather than to (a) find someone willing to
teach you and (b) spend the time and effort learning something that you
aren't naturally good at.
When I get to writing that part, I want the character creation system to
be much less forgiving in generating stats - to make sure that characters
are good in some things and bad in others, if they are really good in
one thing then they are really bad at another etc. And so that the
jack of all trades will definitely be master of none.
>Partying is an important part of
>social interaction and fun (since MULTIplayer/user is part of the MUD
>acronym), and it is also important for roleplaying I think.
Agreed 100% there.
I think the only thing I'll arbitrarily restrict will be magic - the
rationale being that use of magic is a gift you either have at birth
or can never get. Those players who choose to have the gift at character
creation will have a much harder time learning skills in other areas and
those who don't can never learn to do magic. My main reasons for this are
(a) it fits my theme perfectly and (b) it prevents that tank-mage
combination someone mentioned elsewhere. :)
--
Scatter ///\oo/\\\
Scatter ///oo/\
Threshold RPG intoned these words...
>In article <6gim0h$kog$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter ///\oo/\\\) wrote:
>>>group.
>>
>>That's a key idea I hadn't considered. The problem now becomes which skills
>>preclude which?
>
>Well, those are the decisions which will demonstrate how creative of a game
>designer you are =)
Hah! You know if I'd realised a year ago just how many decisions (and how
much work!) go into building a mud from scratch I might never have
bothered...
--
Scatter ///\oo/\\\
Scatter ///oo/\
Nathan Alexander Simington intoned these words...
>Scatter ///oo/\) wrote:
>> That's a nice change from the stock (diku) muds then, whom these days
>> tend to give a new character sufficiently large amounts of 'trains' that they
>> can max all their stats in the first room of mud school...
>
>Er...not are diku muds are stock, nor does the stock code allow in-
>creasing stats via training. You are thinking of Envy or Merc muds,
>which are a specific family of diku derivatives.
True, I was using 'diku' in a too generic sense there. The muds in question
of the ROM and ROT variaties and I see far more than I ever wanted to of
them because my other half has an unfortunate liking for them.
>Also, if the mud admin think that all PCs deserve to max stats in the
>first room of mud school, then I need see no more to know that that mud
>sucks big chunks of granite. :)
Indeed. :) Half the time the 'IMP's are incapable of even adding fully
documented code snippets correctly...
I once tried suggesting that they forget the initial 'train's altogether
and just generate characters with maximum stats but apparently I "just
don't understand!"
@:)
--
Scatter ///\oo/\\\
Scatter ///oo/\
Holly Sommer intoned these words...
>Scatter ///oo/\) wrote:
>
>: I've dropped classes and have but a single race (as mentioned
>: elsewhere, until such time as I can build lands and cities as
>: starting points for each race I won't add those races for players
>: to choose from). This leaves me with name only.
>
>Well, since names are purely subjective identifiers (not even
>quantifiable), if you want some other means of distinguishing
>players, you'll need to do it with something like races or guilds.
There will be guilds within the cities that players may or may not
join, and who would be choosy about their membership and what (if anything)
they teach. I also intend to have a system of player-run guilds and clans
by which players can group themselves. (And would also provide a handy
way for me to filter out those huge sums of cash player's inevitably
aquire, in the form of payments for coding extensions to clan buildings).
>: then that practicing it increases it eventually to 100%?
>It's a decendant of Merc 2.1 And yes, when you learn it, you "get"
>the skill at 1%, and then spending practice points (which, as I
>mentioned previously, is a somewhat contrived and stiff
>implementation, IMO)
I agree with your thoughts on the implementation. :)
>will raise it. 100% isn't possible through
>use or practice. How many things can you do with 100% accuracy?
Breathe? :)
>(ie: never EVER make a mistake)
Ok, I choke sometimes.... *sigh*
>Guys can't even pee without misting the toilet seat sometimes...
>and they've been doing that all their lives! ;)
Well that's why we like to have the seat up....
>: I intend to fix int/str/dex/con/wis at the moment of character creation -
>: never to be modified during the game (except temporarily). The reason
>: being, I see these as being representative of the 'inherent attributes' of
>: the character, physical things built in that can't be changed. You can
>: learn to use them better by gaining skills, but if you're just naturally
>: clumsy then you're never going to be able to dodge very well no matter
>: what amount of fine detail in the art of dodging you manage to learn.
>
>This applies to some attributes, but not all. I don't think intelligence
>should change. It seems like a fixed thing (well, for humans who live
>in earth,anyhow :) Strength... now this DEFINITELY changes - both
>with age and with exercise. Dexterity changes with age. Wisdom
>changes with experience (usually). Constitution should be more of a
>general "health barometer" than it is, most of the time - perhaps
>even tie it in with strength and dexterity, as well as your eating
>habits (do you always wait until "You feel hungry."?)
I agree to a point, but I'm going to get around this by redefining what
the attributes mean. For example, yes you can increase your strength by
weight training etc. What your strength attribute reflects is your bodies
capacity for strength if you see what I mean. There would be a skill,
say 'physical.strength', that you could increase that would allow you to
increase the amount of your bodies available capacity for strength. This
allows you to weight train and increase your effective strength but means
that if you're a short, thin person with frail bones you can never make
your strength as good as that 6'5 athlete over there.
The strength attribute will reflect your body's capacity for strength.
Similarly the dexterity attribute reflects your natural, inbuilt dexterity,
intelligence reflects your capacity to learn knowledge, wisdom reflects
your 'cleverness' in applying learned knowledge and constitution reflects
your bodies basic build.
There will be skills to learn to maximise the effectiveness of your
attributes, but on a fundamental level you're stuck with what you were
born with.
>: >different than it is now), you should check us out sometime soon :)
>: I might just do that.
>Hope to see you there :) Check the helpfile on professions if you
>drop in. It may be of interest to you.
Will do.
--
Scatter ///\oo/\\\
Scatter ///oo/\
Robert intoned these words...
>sca...@thevortex.com (Scatter ///\oo/\\\) writes:
>
>Another way is to make characteristics VERY important in ability
>to learn and ability to succeed, and then limit character creation
>in such a way as to keep people from being better than mediocre in more
>than one or two areas.
That's one thing I'm definitely doing.
>create a world in which /not/ being a competent fighter is /not/ a death
>sentence. Make things interesting for good thieves or good mages or ...
Very good point. I'm aiming for a mud where the primary purpose of playing
is not "kill things to get xp to advance skills to kill things". The
obvious question is what purpose(s) to provide instead. At the moment I'm
thinking in the main to leave it up to the players to decide what they
want to do in the world I provide, but I will need to provide mechanisms
for things like politics, guilds, clans etc for them to do it with.
--
Scatter ///\oo/\\\
Threshold RPG
In article <6gm49f$no6$1...@zeus.tcp.net.uk>, sca...@thevortex.com wrote:
>Threshold RPG intoned these words...
>>In article <6gim0h$kog$1...@news.uk.ibm.com>, sca...@thevortex.com (Scatter
>>>
>>
>>Well, since you asked...
>>
>>1) I think classes are realistic in that people often "define" themselves by
>>what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
>>computer programmer, etc. There is a natural tendency to have some kind of
>>class/job/etc. that you use to classify yourself.
>
>What I'm hoping is that people will do exactly that - classify themselves
>rather than have the computer do it for them.
Wonderful. However, keep in mind that you don't have hundreds or thousands of
years of time for society to evolve (meaning, people aren't going to play
your mud for many years just to be the "cavemen" of your civilization). If you
don't provide some kind of structure to get people started you aren't going to
have much of a society.
Richard
Matt Chatterley <ma...@mpc.dyn.ml.org> writes:
> I've certainly given some thought to a system which listed possible exits
> relative to each individual. The 'world' would be built around a three
> dimensional compass (or two dimensional if you don't care about up or
> down), and exits from a room given as coordinates or bearings (when being
> 'installed' by a creator). The orientation of a PC would be stored (eg:
> bearing that they are facing and/or moving in), and exits calculated
> relative (eg: 'left' would be assigned to the 180-360 quadrant, and right
> to the other half). It might be good to divide commands to turn, and move
> separately.
>
> This seems over complicated for personal movement, but is probably the
> only sane way to handle vehicle movement is most situations.
Just a FYI, the Discworld mudlib allows this.
It is pretty useless though, as if you are going to have this method of
movement rather than the directional one you might as well have a 3d
client IMO. The Discworld mudlib also supports the normal directions
north, south, east.. otherwise I suspect no-one would play on the Discworld
mud :)
The only use for left, right.. that I ever heard of was someone (Eggjon)
who mapped the commands to his keypad and you could use them kind of like
you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
I can see it being easier to hit "left cursor", "left cursor", "up cursor"
than typing "east" (three keys vs a more complex 5).
--
Richard Tew (above spudent -> student, lame spam avoidance thingy)
Matt Chatterley
On Fri, 10 Apr 1998, Peter S. Young wrote:
> Actually, if I remember correctly, shadow run doesn't add up the rolls...
> what happens is, they give you a number to beat... sometimes modded by an
> attribute... this is one part of the difficulty. Now, you get <x> number
> of dice to roll, each time you get over (or equal, can't remember) to the
> number, you get a success. The second half of the difficulty is how many
> successes you needed. It's fairly decent as probability goes, and you can
> scale difficulties. An interesting thing, is that if your skill is low
> enough, there are things you *can't* do... they require more success than
> you have dice to roll. - Peter Young
My fault entirely if I've misconceived the system - its been a *long* time
since I looked at Shadowrun. :) Sounds fairly interesting, but is probably
not a model I'd like to use - partly because of the wide range when a lot
of dice are involved, but also because if difficulty is scaled against
each dice you have a very limited range. Alternately scaling difficulty
against totals is a good concept - that would prohibit performing certain
actions with low skill (perhaps making allowances for 'flukes' and so
forth).
What really becomes important in the model you pick is the amount of
influence you want skills to have in your game environment (this ties into
how often you check them, too). Also, I find it important to bear in mind
that you have a lot more flexibility to hand than you would for a tabletop
game - you can use more complicated maths if you so wish. The system I
employ for skills is basically:
Your skill is a number from 1-1000. This changes at regular intervals
based on the rate-of-change (this can be modelled by a graph where the
rate of change dy/dx is simply the gradient of the curve, and the curve
vaguely resembles a bell curve or similar).
The rate of change decreases with time (to a given minimum threshold, most
likely negative), and increases when a skill is applied, or training in
that skill is received. This means that the effects of training spread out
over time, and the losses from inactivity do so as well.
Matt Chatterley
> > I've certainly given some thought to a system which listed possible exits
> > relative to each individual. The 'world' would be built around a three
> > dimensional compass (or two dimensional if you don't care about up or
> > down), and exits from a room given as coordinates or bearings (when being
> > 'installed' by a creator). The orientation of a PC would be stored (eg:
> > bearing that they are facing and/or moving in), and exits calculated
> > relative (eg: 'left' would be assigned to the 180-360 quadrant, and right
> > to the other half). It might be good to divide commands to turn, and move
> > separately.
> >
> > This seems over complicated for personal movement, but is probably the
> > only sane way to handle vehicle movement is most situations.
>
> Just a FYI, the Discworld mudlib allows this.
>
> It is pretty useless though, as if you are going to have this method of
> movement rather than the directional one you might as well have a 3d
> client IMO. The Discworld mudlib also supports the normal directions
> north, south, east.. otherwise I suspect no-one would play on the Discworld
> mud :)
Yeah. It's a stupidly longwinded way (to me) of handling personal
movement. The situations where one could apply it are really more
vehicular, ie: A submarine, where there are controls to set
bearing/heading, speed, tilt, and so forth, and these settings are
constantly applied over a period of time (rather than player movement
whereby you type east and instantly go east).
Hmm. This is quite interesting..
> The only use for left, right.. that I ever heard of was someone (Eggjon)
> who mapped the commands to his keypad and you could use them kind of like
> you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
> I can see it being easier to hit "left cursor", "left cursor", "up cursor"
> than typing "east" (three keys vs a more complex 5).
Cute. :) I'd still find typing 'east' easier to hitting a bunch of cursor
keys - easier to correct fumbles. =)
Dominic J. Eidson
On Fri, 10 Apr 1998, Matt Chatterley wrote:
> I've certainly given some thought to a system which listed possible exits
> relative to each individual. The 'world' would be built around a three
> dimensional compass (or two dimensional if you don't care about up or
> down), and exits from a room given as coordinates or bearings (when being
Well, up and down are up and down... Unless you allow people to walk on
the walls, or walk on the ceiling, in which case... Interesting idea,
I'll remember that :)
> This seems over complicated for personal movement, but is probably the
> only sane way to handle vehicle movement is most situations.
Hehe... Well, I believe once players got used to this method of movement,
it would not be too hard to move around... The biggest problem would be
to remember the maps of towns, and the rest of the realm. As for vehicle
movement, after that last post I wrote, I looked over the notes, and
descided to make a test implementation of it on my vehicles... It will be
interesting to see how it turns out.
> Has anyone considered, constructed, or seen a mud based soley around
> piloting craft of some fashion? It's an interesting idea.
Not solely around piloting a vehicle, but I have implemented vehicles on
my mud. For now though, it's limited to a small wagon that can be found
somewhere hidden in the game world...
John Adelsberger
Piotr Banski (ban...@indiana.edu) wrote:
: The point wasn't to specify what you can do with LP, but what you
: standardly do (or don't do) with it, again generalizing over a great
: variety of libs.
I only made the point because I don't want anyone to think LP has to
be that way, or is that way because it would be hard to do it otherwise.
In fact, I suspect you could make my current setup look and act like
a Diku in at most a few weeks of work.
Matt Chatterley
On Sat, 11 Apr 1998, Dominic J. Eidson wrote:
> On Fri, 10 Apr 1998, Matt Chatterley wrote:
>
> > I've certainly given some thought to a system which listed possible exits
> > relative to each individual. The 'world' would be built around a three
> > dimensional compass (or two dimensional if you don't care about up or
> > down), and exits from a room given as coordinates or bearings (when being
>
> Well, up and down are up and down... Unless you allow people to walk on
> the walls, or walk on the ceiling, in which case... Interesting idea,
> I'll remember that :)
If you were going for full 3d orientation, you could easily have things
which were upside down, which is what makes this so appealing for things
in space or underwater, but less so for single characters (and arguably
ground-based movement). Perhaps someone should write a multi-player
version of Elite, running via clients/servers ;)
> > This seems over complicated for personal movement, but is probably the
> > only sane way to handle vehicle movement is most situations.
>
> Hehe... Well, I believe once players got used to this method of movement,
> it would not be too hard to move around... The biggest problem would be
> to remember the maps of towns, and the rest of the realm. As for vehicle
> movement, after that last post I wrote, I looked over the notes, and
> descided to make a test implementation of it on my vehicles... It will be
> interesting to see how it turns out.
Eek, yes, mapping would be horrendous for individuals, I would think.
Especially when I'm talking about 'indefinite' rather than 'definite'
moves (giving something a heading, and a speed, rather than just moving
it from point to point). Obviously this wouldn't fit in with
'conventional' rooms very well (cue more debates on 'flowing' terrain).
> > Has anyone considered, constructed, or seen a mud based soley around
> > piloting craft of some fashion? It's an interesting idea.
>
> Not solely around piloting a vehicle, but I have implemented vehicles on
> my mud. For now though, it's limited to a small wagon that can be found
> somewhere hidden in the game world...
Heh. Same here (transport anyway; horses, boats, magic carpets, and so
forth). I wish I had time for another project, perhaps along the lines of
Elite. ;)
Marian Griffith
In article <Pine.BSD/.3.91.9804111144...@hub.kdi.com>,
Dominic J. Eidson <URL:mailto:sau...@hub.kdi.com> wrote:
> On Fri, 10 Apr 1998, Matt Chatterley wrote:
> > I've certainly given some thought to a system which listed possible exits
> > relative to each individual. The 'world' would be built around a three
> > dimensional compass (or two dimensional if you don't care about up or
> > down), and exits from a room given as coordinates or bearings (when being
> > This seems over complicated for personal movement, but is probably the
> > only sane way to handle vehicle movement is most situations.
Actually, it is not that complicated to use. It may be unfamiliar to you
americans who are used to grid based cities. I do assure you that there
are many europeans who find nothing complicated or inconvenient about it
as it is the way most of our cities are laid out.
> Hehe... Well, I believe once players got used to this method of movement,
> it would not be too hard to move around... The biggest problem would be
> to remember the maps of towns, and the rest of the realm. As for vehicle
> movement, after that last post I wrote, I looked over the notes, and
> descided to make a test implementation of it on my vehicles... It will be
> interesting to see how it turns out.
The best way really, to solve this is to provide players with landmarks
that they can walk to. Rather than saying 'turn left' you would say 'go
to the armoury' and eventually go there. Only when there are no clear
directions, or you do not know where you should be going will you ever
use the 'left' and 'right' commands. As your knowledge of the city ex-
pands the need for remembering a map decreases rather than increases.
You simply remember the fact that something is there and which sequence
of landmarks will eventually take you to the place you want to go. This
also is much more convenient in navigating wilderness, where the exits
are really a little awkward.
Marian
(visit whirl's roleplaying pages at http://www.iaehv.nl/users/gryphon/)
--
Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...
Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey
Cimri
The Eternal City is doing this (landmark-related travel commands).
Interesting implementation!
Jay // Cimri
Matthew R. Sheahan
Matt Chatterley (ma...@mpc.dyn.ml.org) wrote:
> bearing that they are facing and/or moving in), and exits calculated
> relative (eg: 'left' would be assigned to the 180-360 quadrant, and right
> to the other half). It might be good to divide commands to turn, and move
> separately.
i've done some work on something related to this, and i feel as if i should
note that the numbers are a lot nicer if you use gradians instead of degrees.
chiaroscuro
Matt Chatterley
On Sun, 12 Apr 1998, Marian Griffith wrote:
> In article <Pine.BSD/.3.91.9804111144...@hub.kdi.com>,
> Dominic J. Eidson <URL:mailto:sau...@hub.kdi.com> wrote:
>
> > On Fri, 10 Apr 1998, Matt Chatterley wrote:
>
> > > I've certainly given some thought to a system which listed possible exits
> > > relative to each individual. The 'world' would be built around a three
> > > dimensional compass (or two dimensional if you don't care about up or
> > > down), and exits from a room given as coordinates or bearings (when being
>
> > > This seems over complicated for personal movement, but is probably the
> > > only sane way to handle vehicle movement is most situations.
>
> Actually, it is not that complicated to use. It may be unfamiliar to you
> americans who are used to grid based cities. I do assure you that there
> are many europeans who find nothing complicated or inconvenient about it
> as it is the way most of our cities are laid out.
Speaking as a Brit, I still fine it complicated to have to set a
directional bearing, and select a speed in order to move, rather than
typing directions. ;) This does seem an amicable way to handle what you
could call 'wilderness' travel (prolonged movement over large fairly
nondescript/generic regions of terrain).
> > Hehe... Well, I believe once players got used to this method of movement,
> > it would not be too hard to move around... The biggest problem would be
> > to remember the maps of towns, and the rest of the realm. As for vehicle
> > movement, after that last post I wrote, I looked over the notes, and
> > descided to make a test implementation of it on my vehicles... It will be
> > interesting to see how it turns out.
>
> The best way really, to solve this is to provide players with landmarks
> that they can walk to. Rather than saying 'turn left' you would say 'go
> to the armoury' and eventually go there. Only when there are no clear
> directions, or you do not know where you should be going will you ever
> use the 'left' and 'right' commands. As your knowledge of the city ex-
> pands the need for remembering a map decreases rather than increases.
> You simply remember the fact that something is there and which sequence
> of landmarks will eventually take you to the place you want to go. This
> also is much more convenient in navigating wilderness, where the exits
> are really a little awkward.
Yeah, all objects being set at a point in the grid, so that they can be
used relationally, is a good notion to aid navigation. You could also add
fixed things (suns, stars, and so forth), to provide general points rather
than specific points. :)
Craig S Dohmen
Richard wrote in message ...
>The only use for left, right.. that I ever heard of was someone
(Eggjon)
>who mapped the commands to his keypad and you could use them kind of
like
>you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
No no. The REAL reason for it is to get people lost in the Library.
:)
--Craig (Presto)
Nathan Fenenga Yospe
Richard, is it true that on 11 Apr 98 22:58:19 +1200, you posted to
rec.games.mud.admin:
: Matt Chatterley <ma...@mpc.dyn.ml.org> writes:
: > 'installed' by a creator). The orientation of a PC would be stored (eg:
: > bearing that they are facing and/or moving in), and exits calculated
: > relative (eg: 'left' would be assigned to the 180-360 quadrant, and right
: > to the other half). It might be good to divide commands to turn, and move
: > separately.
: > This seems over complicated for personal movement, but is probably the
: > only sane way to handle vehicle movement is most situations.
: Just a FYI, the Discworld mudlib allows this.
I remember this; Discworld was my second LP mud.... the first didn't have a
tendancy to named exits. I later added named exits, then LRFBUD exits, to a
mud of my own... Rom based, Diku. I also had a bunch of other messages that
associated with movement, including turning and what direction every person
was facing. I happen to like LRFBUD, though only certain rooms actually had
them.
: It is pretty useless though, as if you are going to have this method of
: movement rather than the directional one you might as well have a 3d
: client IMO. The Discworld mudlib also supports the normal directions
: north, south, east.. otherwise I suspect no-one would play on the Discworld
: mud :)
Hmm. Possible, I remember their names for named exits being ridiculous. The
LRFBUD approach is only a hassle in mazeish situations, and that's intended
to be tough.
: The only use for left, right.. that I ever heard of was someone (Eggjon)
: who mapped the commands to his keypad and you could use them kind of like
: you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
: I can see it being easier to hit "left cursor", "left cursor", "up cursor"
: than typing "east" (three keys vs a more complex 5).
I actually use a fourth method now, though I do use a bit of LRFBUD... they
make more sense than cardinals... I now rely mainly on approach, with a key
of > shortcutting "approach", and the client has a switch that assumes that
you mean "approach Foo" on any unparseable "Foo". Approach is quite good if
you have a roomless landscape system. There's also "face", "look left/back/
right/up/down/ahead", and other commands for positioning and movement. Some
motion even assumes curvature. Scouting a wall, for example.
--
Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/
Sorabain W De Lioncourt
In article <TjRROx...@cantva.canterbury.ac.nz>,
Richard <rm...@spudent.canterbury.ac.nz> wrote:
[snip]
>
>The only use for left, right.. that I ever heard of was someone (Eggjon)
>who mapped the commands to his keypad and you could use them kind of like
>you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
>I can see it being easier to hit "left cursor", "left cursor", "up cursor"
>than typing "east" (three keys vs a more complex 5).
>
>--
>Richard Tew (above spudent -> student, lame spam avoidance thingy)
I thought it was pretty standard for most muds to have
built-in aliases of 'e' for 'east' etc. (If not then you'd get
a client and alias it to that yourself). So it's only really 2 keys
to go 'east' rather than the 3 cursor key hits. It's still a nice idea
though, i might try it one day to see if it aids immersion in the game
world. Going e;s;w;n doesn't usually convey a circular 'feeling', in my
mind's eye i'm viewing my character from above. Using this left/right
lark might bring me mentally into the first-person.
~Sorabain Wolfheart de Lioncourt
--
It makes me mad when people say I turned and ran like a scared rabbit.
Maybe it was like an angry rabbit, who was running to go fight in another
fight, away from the first fight.
Richard Woolcock
Joseph B Fritz wrote:
>
> IMHO what skills you learn and how good you are at useing them should be
> based on stats. IE a player with a very high dex and int could be an
> excelllent mage and thief but if their strength was low they might not
> be a good fighter. In this case you need to decide which skills apply to
> the skill and decide how well a given player can learn it from that.
I disagree. A low strength might well result in poor fighting abilities,
but it should have NO bearing at all on how skilled the person in question
is. The only exceptions to this would be intelligence and intellectual
skills, but even in this case, skill development would usually just be
slower than usual.
IMO a 'class' should be determined by skills, not the other way around.
KaVir.
Richard Woolcock
Peter S. Young wrote:
>
> Heh... just finished doing this on my code base... it is a pain... fun
> though... now when people get stuck in the dark... if they're not carful,
> they'll really be stuck in the dark.
Not as much as they could be - players turn 90 degrees at a time. Change
that, and your players will get REALLY lost in the dark (random variations
on turning if they can't see ;) No, I've not coded this, but I know someone
who has (the angle bit, not the dark bit)...
> otoh, I think that the NEWSUD is nice in that the computer/mud sorta knows
> how rooms are arranged relative to each other. It's not utterly perfectly
> (actually, it's far from it), but the computer can assume a sort of
> gemoetry then...
>
> On that note, has anyone ever managed to make a completely grided 2D or 3D
> system? I wanted to do this, but there were a couple problems:
Yup, I did a 2D one first, then scrapped it and did a 3D one.
> 1) Room descriptions... how?
The mud makes them up for me. Not very imaginative descriptions, I admit,
but at least they're accurate. I can also write descriptions if I want.
> 2) Space... this was ugly.
I have two arrays, each 512x512, one of unsigned chars and the other of
pointers. This takes up 1.25 meg of ram. I also have upto 1000 structures
containing room data floating around at any one time, which takes up about
another 0.5 meg (at worst case). There are a few other bits (template list,
upto 1000 reusuable rooms), but all-in-all the max usuage shouldn't be more
than about 2-3 meg of ram. The real problem is disk space...
> 3) Converting everything... the ABs would have lynched me, I think.
Just do it. I don't know what codebase you're working on, due to the
crosspost, but I managed it on a diku/merc.
> 4) Revamping the OLC... 'nother hard to do thing.
Yeah a friend of mine helped take some of the load off my shoulders by
writing some terraforming commands.
> 5) Movement... I'd wanted the grid to be the same one used for combat...
> only, this would mean that each move took 1 - 5 seconds... or there's a
> 1 : 5 ratio of real time to game time. Which makes a majority of
> things take a long, long time. (Did anyone ever figure out a solution
> to this? I keep meaning to try to prove that no solution exists (i.e.,
> you can't have players moving a different time speeds), but I've never
> gotten around to it.)
Well I still have the normal movement system atm, but I guess you could have
movement commands take time (eg you move north 0.5 seconds after typing it,
and keep moving until you type stop? Someone else might only take 0.4 seconds
to move, or might be running, and thus be able to catch up with you, while
another person might be driving their car...)
KaVir.
Richard Woolcock
Threshold RPG wrote:
[snip]
> 1) I think classes are realistic in that people often "define" themselves by
> what they do. Whether they are a student, a doctor, a lawyer, a plumber, a
> computer programmer, etc. There is a natural tendency to have some kind of
> class/job/etc. that you use to classify yourself.
Logging on to Real Life mud...
Enter your name: Aristotle
Please select your class:
[1] Student: Generally learned in most skills, but with no specialties.
[2] Doctor: Skilled in all areas of medicine, with low technology skills.
[3] Lawyer: Skilled in law practice, very poor with technological skills.
[4] Plumber: Good at fixing leaks, medium technological skills.
[5] Computer programmer: Good technological skills, low social skills.
Which class do you belong to?
The problem with classes is that they are TOO broad.
[rest snipped]
KaVir.
Matthew Julius
On Thu, 09 Apr 1998 04:31:24 GMT, thre...@counseltech.com (Threshold
RPG) wrote:
>In article <352c0742...@news.wwa.com>, zeb...@wwa.com wrote:
>>
>>If you have 10 exits available to you (n,s,e,w,u,d,ne,nw,se,sw) there
>>seems to be more than enough choices to work with. It is then up to
>>the creative builders to describe these exits in such a way that the
>>player feels he is in the actual world.
>
>What if your character doesnt currently know what direction is north? Then you
>need left, right, straight, back, or some other exit? What if the object is
>something that can be entered from a variety of angles, and thus it really is
>inaccurate to say you are going "east" to enter it.
>
>10 exits fit most situations. However, there are many situations it does not
>fit. Having the flexibility to use other exits is a big help. Using them
>poorly like in some of your excellent examples of poor use is pretty lame.
>However, a system should not be judged by the work produced by poor/cheating
>coders.
<aside>
I was going to try out mozilla, but it didn't look like I was going to
figure out how to *not* post in html. So I started up tin on my unix
account and posting in that seemed to clobber what I wrote, for some
reason. I tried to cancel that message, and it appears that was
successful, and I apologise if anyone sees it. I caved in and decided
to use MS OE, but I started that up (after 15 seconds of loading) and
I saw MSN right away ... closed OE as soon as I saw it. I remembered
I have Forte Free Agent, which is supposed to be pretty good, so now
is as good an opportunity to try it as any. Again, my apologies if
anything is unusual about this posting. The original text as I wrote
over an hour ago follows.
</aside>
I think the best example of 'non-standard' exits is with rooms of
varying shapes. It is a common view on muds that rooms all have to
be in the shape of a grid, and a whole set of rooms fit nicely within
this grid. As I call it for lack of better words, a one-to-one ratio.
Take this room for example ...
.---------------------.
| / Closet |
| | |
| |----------'
| Bedroom / Hall
| |----------.
| | |
| \ Bathroom |
'---------------------'
Perhaps it's difficult to see, but the three slashes are doors. Now
what happens when you're in the bedroom is that there are three east
exits. Most folks would probably split the bedroom up into three
parts and have each with an eastern exit. I don't particularly like
this solution though. I see the bedroom as a single entity that
shouldn't be broken up. So what do you do ? You can have the closet
and bathroom be northeast and southeast exits respectively, but I feel
this is worse than splitting up the bedroom.
The best solution is to have 'closet' and 'bathroom' exits, which may
or may not require 'go' or 'enter' preceeding them. Of course, I
don't put it past myself to be missing another alternative. If anyone
can see another solution, aside from restructuring the room, I'd like
to hear it, since I had this situation actually come up once.
--
Matthew Julius o_o
( _ )
s01...@discover.wright.edu ( | | )
Peter S. Young
On Mon, 13 Apr 1998, Richard Woolcock wrote:
> Peter S. Young wrote:
> >
> > Heh... just finished doing this on my code base... it is a pain... fun
> > though... now when people get stuck in the dark... if they're not carful,
> > they'll really be stuck in the dark.
>
> Not as much as they could be - players turn 90 degrees at a time. Change
> that, and your players will get REALLY lost in the dark (random variations
> on turning if they can't see ;) No, I've not coded this, but I know someone
> who has (the angle bit, not the dark bit)...
*wince*... the only thing I've stuck in is that players occassionally make
a turn that they don't intend to... go long enough in the dark and you
will get lost. Somewhat.
> > otoh, I think that the NEWSUD is nice in that the computer/mud sorta knows
> > how rooms are arranged relative to each other. It's not utterly perfectly
> > (actually, it's far from it), but the computer can assume a sort of
> > gemoetry then...
> >
> > On that note, has anyone ever managed to make a completely grided 2D or 3D
> > system? I wanted to do this, but there were a couple problems:
>
> Yup, I did a 2D one first, then scrapped it and did a 3D one.
>
> > 1) Room descriptions... how?
>
> The mud makes them up for me. Not very imaginative descriptions, I admit,
> but at least they're accurate. I can also write descriptions if I want.
>
> > 2) Space... this was ugly.
>
> I have two arrays, each 512x512, one of unsigned chars and the other of
> pointers. This takes up 1.25 meg of ram. I also have upto 1000 structures
> containing room data floating around at any one time, which takes up about
> another 0.5 meg (at worst case). There are a few other bits (template list,
> upto 1000 reusuable rooms), but all-in-all the max usuage shouldn't be more
> than about 2-3 meg of ram. The real problem is disk space...
Since my current mud is probably taking up around 6-8 megs, that's around
a 50% increase in size... (well, it's ugly to me...)
> > 3) Converting everything... the ABs would have lynched me, I think.
>
> Just do it. I don't know what codebase you're working on, due to the
> crosspost, but I managed it on a diku/merc.
>
> > 4) Revamping the OLC... 'nother hard to do thing.
>
> Yeah a friend of mine helped take some of the load off my shoulders by
> writing some terraforming commands.
>
> > 5) Movement... I'd wanted the grid to be the same one used for combat...
> > only, this would mean that each move took 1 - 5 seconds... or there's a
> > 1 : 5 ratio of real time to game time. Which makes a majority of
> > things take a long, long time. (Did anyone ever figure out a solution
> > to this? I keep meaning to try to prove that no solution exists (i.e.,
> > you can't have players moving a different time speeds), but I've never
> > gotten around to it.)
>
> Well I still have the normal movement system atm, but I guess you could have
> movement commands take time (eg you move north 0.5 seconds after typing it,
> and keep moving until you type stop? Someone else might only take 0.4 seconds
> to move, or might be running, and thus be able to catch up with you, while
> another person might be driving their car...)
Actually, the problem wasn't the timing (i.e., you move north for <x>
number of time steps), it's that it'd be bloody boring going from town to
town. Can you imagine? I mean, if you used the same grid that you use
for combat... well, going north should move you about a yard tops... now
imagine you had to type out all the commands to go to another town 3 miles
away... in 1 yard increments... can we say painful? (that could explain
why the 'N' on my keyboard's managed to completely fade out.) I suppose
that's the problem of having 40 (my mud should only be so lucky!) main
characters or so. - Peter Young
Jason Goodwin
In article <Pine.LNX.3.93.980413...@buiyee.berkeley.edu>,
Peter S. Young <pyo...@uclink4.berkeley.edu> wrote:
>*wince*... the only thing I've stuck in is that players occassionally make
>a turn that they don't intend to... go long enough in the dark and you
>will get lost. Somewhat.
Well, making a random turn isn't the greatest :) If I'm in my house
completely in the dark, I can find my way around just from rote memory.
If I walked the forest road a thousand times, I'm sure the same thing
would apply :)
>Since my current mud is probably taking up around 6-8 megs, that's around
>a 50% increase in size... (well, it's ugly to me...)
Well, that's the cost of progress :) To add more features, you _have_
to expend more resources. (granted, the new features may allow you
to replace some of the things you have now, which could reduce their
cost) The newest FPS games are starting to require a good graphics
accelerator. Why? Because the programmers are lazy and don't want
to optimize? No, there are just things they can't do within a
reasonable amount of resources without the accelerators. (the trick
is balancing the cost of the addition, and seeing if it is really
worth it. 5 megs of ram just for the mount code? I don't think so :)
>Actually, the problem wasn't the timing (i.e., you move north for <x>
>number of time steps), it's that it'd be bloody boring going from town to
>town. Can you imagine? I mean, if you used the same grid that you use
>for combat... well, going north should move you about a yard tops... now
>imagine you had to type out all the commands to go to another town 3 miles
>away... in 1 yard increments... can we say painful? (that could explain
>why the 'N' on my keyboard's managed to completely fade out.) I suppose
>that's the problem of having 40 (my mud should only be so lucky!) main
>characters or so. - Peter Young
Well, depending on the sytem you are using to build the features
of the terrain, you definately should modify the movement. If
you can't add "Follow road north" or "Go to eastern mountains"
then the system will be horrendous :)
(How well the commands are followed, well, that's another thing.)
Richard Woolcock
Peter S. Young wrote:
>
> On Mon, 13 Apr 1998, Richard Woolcock wrote:
>
> > Peter S. Young wrote:
[snip]
> > > On that note, has anyone ever managed to make a completely grided 2D or 3D
> > > system? I wanted to do this, but there were a couple problems:
> >
> > Yup, I did a 2D one first, then scrapped it and did a 3D one.
[snip]
> > > 2) Space... this was ugly.
> >
> > I have two arrays, each 512x512, one of unsigned chars and the other of
> > pointers. This takes up 1.25 meg of ram. I also have upto 1000 structures
> > containing room data floating around at any one time, which takes up about
> > another 0.5 meg (at worst case). There are a few other bits (template list,
> > upto 1000 reusuable rooms), but all-in-all the max usuage shouldn't be more
> > than about 2-3 meg of ram. The real problem is disk space...
>
> Since my current mud is probably taking up around 6-8 megs, that's around
> a 50% increase in size... (well, it's ugly to me...)
Ah, but think of the amount of space you'll save in areas - you no longer need
all those horrible space-wasting static areas...
[snip]
> > Well I still have the normal movement system atm, but I guess you could have
> > movement commands take time (eg you move north 0.5 seconds after typing it,
> > and keep moving until you type stop? Someone else might only take 0.4 seconds
> > to move, or might be running, and thus be able to catch up with you, while
> > another person might be driving their car...)
>
> Actually, the problem wasn't the timing (i.e., you move north for <x>
> number of time steps), it's that it'd be bloody boring going from town to
> town. Can you imagine? I mean, if you used the same grid that you use
> for combat... well, going north should move you about a yard tops... now
> imagine you had to type out all the commands to go to another town 3 miles
> away... in 1 yard increments... can we say painful? (that could explain
> why the 'N' on my keyboard's managed to completely fade out.) I suppose
> that's the problem of having 40 (my mud should only be so lucky!) main
> characters or so. - Peter Young
Hmmm okay well that is a problem. Even so, imagine with the example above,
if you could type (for example):
]n
You turn to face the north.
]walk 40
You start walking through the forest.
[a while later]
The forest opens up ahead, leading onto a plain.
[second later]
You walk out of the forest onto the plain.
[a while later]
In the distance, you see a large lake.
etc...
Not perfect, but still, better than typing 'n' 40 times...
KaVir.
Matthew Schuyler Peck
This subthread relates quite closely to a project I began to design (think about) not
too long ago. What I intended (before I decided I didn't want to spend the time doing
it) was to make a graphical MUD using OpenGL or some other render-on-the-fly package.
The idea was to have a tile-less world that was defined by specific three-dimensional
objects with six degress of freedom and (near) infinite adjustment in all directions.
That is, because everything is defined by functions, the game lets players move in any
direction they want as far as they want (assuming they don't run into obstacles).
Instead of having square rooms of the same size, you could have ovular rooms, or
windows that people can climb through, or towers people can use a grappling hook to
climb. I still think it would be very cool, but the horsepower necessary to handle
even one player would be relatively tremendous, not to mention the time it would take
to implement any kind of sizable world if you had to define each surface
mathematically. I suppose you could have randomization algorithms (with some
fundamental rules) that would create the world for you. Still, it would be a massive
project. Perhaps if I find several interested people with quite a bit of time I might
actually pursue at least the framework of this project and then sell it to some big
gaming company who would mutilate and bastardize it. Wow, did I say that?
Matthew S Peck
Richard Woolcock wrote:
--
"God and the soldier we adore,
in times of trouble but not before,
when the trouble is over and the world is righted,
God is forgotten and the soldier slighted."
--scrawled inside a Prussian sentry box, circa 1700
nob...@student.anu.edu.au
(Threshold RPG) wrote:
> ban...@indiana.edu (Piotr Banski) wrote:
> >I don't believe this is true. Some players do prefer either lp or
> >diku-style codebases, and can recognise them well, often already in the
> >login sequence. I return to this below.
Heh ... most _libs/flavours_ are recogniseable from login unless people
have gone to the trouble of recoding them (and few do beyond changing the
messages)
> The reason for this is mainly because in the early years of mudding
people did
> not stray very far from stock. They spent their time making areas,
spells, and
> other such add ons and did not make any major alterations to the actual "deep
> magic" of the codebase.
Lets see ... early years of Mudding .. this would be what?
1981ish? Every MUD was unique.
1985ish? Admittedly Abers are more stock than most, but that's part of
Abermud's charms :), and besides, there have never been a large number of
them around anyway.
Late 80s when LP and Tinys came out? Well Tinys you're expected to really
only change the areas, and few change the mechanics (such as they are),
since they're not really about spells and so on. LPs? Is there anyone that
opened a non-enhanced 2.4.5 and kept it non-enhanced? (and attracted
players)? A non-enhanced TMI?
Perhaps 91ish when Diku came out? Gamma Diku, so I've read, was a lib
which was released with deliberate bugs which needed to be fixed in order
to actually get the thing to compile.
Or what about when Merc 1 came out? Merc 2? ROM 2? TMI-2? Nightmare 3? Circle?
All these are relatively new - last 5 years or so.
The Stock-Mud syndrome, with muds differentiated merely by a few areas and
spells is a relatively new phenomenon - for two simple reasons:
1/ computing space used to be relatively expensive and rare, thus if you
were lucky enough to get a site, you wanted to differentiate your product
from everything else.
2/ Mud servers released with everything that one needed to run a full game
are fairly new.
> As mudding enters a new era, the focus is different. Stock is generally
That would be graphical? Headset-mounted Virtual Reality?
> considered "lame" and the goal of many (perhaps most) mud designers is to
Yet Another Stock Muds have generally been considered lame, methinks,
which is why there's such amusement/despair/irritation when somebody posts
a five page ad, detailing their mud, where the highlights are "ansi
color"[BeekBait *Tm], "5000 levels", and "497 races, each with their own
slightly different base stats". It's just there are so many more Stock
Muds (though this isn't the fault of those who originated them, but of
those who haven't been using them as a launching pad) nowadays, and the
numbers are growing.
> plan their design beginning at a much deeper level.
I'm under the impression that the design should begin at "fun", and go
deeper from there, but I guess it's OK to attempt to shoehorn fun in on
top of the deep stuff too :)
> Thus, some of the "obvious" differences will disappear. The things you
> mentioned about exits, auto commands, etc, will become design decisions made
auto commands were, I believe, a Merc innovation (though they may have
borrowed it from one of the custom code bases that they derived their
distribution areas from). I'm not sure about named exits, since old-style
muds tend to be fairly strict about using compass directions (a hangover
from Dungeon [Zork]).
> by all programmers rather than codebased decisions. This is part of the
> evolution of all muds, and as it progresses you will see "LPMUD" features on
Those would be features found on 2.4.5? .. well I hope I don't see those
on diku muds. Don't you mean "as it progresses you will see "custom"
features on diku muds"?
> diku muds and "DIKUmud" features on lp muds. As people take a more objective
But at any rate, more advanced dikus have on-line editing, and scripting
for objects and monsters - MUME has had it for years (provided it's still
alive of course), for instance.
> view towards the assets and interesting features of both codebases, they will
> seek to use their program to replicate the effects of cool things they have
> seen on another codebase.
Until people stop releasing servers which can be downloaded, compiled and
opened ready for full play in 30 minutes, things aren't going to change:
Some will attempt to make a unique product, others will attempt and fail,
others won't do more than tweak areas and spells, and others will just
change the title screen and the lib name :) [Shish .. why does this sound
like the sunscreen song]
--OH. "Only been around for five years, so i'm not a dino."
"And so we return and begin again" - El Fayed, "The Invisibles"
Matt Chatterley
On Tue, 14 Apr 1998 nob...@student.anu.edu.au wrote:
> (Threshold RPG) wrote:
> > ban...@indiana.edu (Piotr Banski) wrote:
> > >I don't believe this is true. Some players do prefer either lp or
> > >diku-style codebases, and can recognise them well, often already in the
> > >login sequence. I return to this below.
>
> Heh ... most _libs/flavours_ are recogniseable from login unless people
> have gone to the trouble of recoding them (and few do beyond changing the
> messages)
But are they? A question: What makes a given server (lib, or codebase)
easily recognisable? Is it the text used for the prompts, the style of
prompt, the way the login screen is displayed, the information given?
[Snip rest, with a nod of concurrance]
mor...@niuhep.physics.niu.edu
Richard Woolcock <Ka...@dial.pipex.comNOSPAM> writes:
>Peter S. Young wrote:
>
>[snip]
>
>>
>> number of time steps), it's that it'd be bloody boring going from town to
>> town. Can you imagine? I mean, if you used the same grid that you use
>> for combat... well, going north should move you about a yard tops... now
>> imagine you had to type out all the commands to go to another town 3 miles
>> away... in 1 yard increments... can we say painful? (that could explain
>> why the 'N' on my keyboard's managed to completely fade out.) I suppose
>> that's the problem of having 40 (my mud should only be so lucky!) main
>> characters or so. - Peter Young
>Hmmm okay well that is a problem. Even so, imagine with the example above,
>if you could type (for example):
>
>]n
>You turn to face the north.
>]walk 40
>You start walking through the forest.
>
>[a while later]
The problem, I believe, is that Peter wanted to have or does have a static
relationship between mud time and real time.
So, walking at 4 mph it takes 2 hours mud time and 120min/5= 20 minutes
real time to go 8 miles. My suggestion for dealing with this is to make
wilderness travel high speed as long as nobody and nothing else is around.
To maintain a certain amount of time sanity the multiple might only be
3, but while 7 minutes is pretty long, it is viable, esp. as in many
cases you arent' going to make it 8 miles without running into something
interesting.
Robert
Richard
ba...@dcs.warwick.ac.uk (Sorabain W De Lioncourt) writes:
> Richard <rm...@spudent.canterbury.ac.nz> wrote:
>> The only use for left, right.. that I ever heard of was someone (Eggjon)
>> who mapped the commands to his keypad and you could use them kind of like
>> you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
>> I can see it being easier to hit "left cursor", "left cursor", "up cursor"
>> than typing "east" (three keys vs a more complex 5).
> I thought it was pretty standard for most muds to have
> built-in aliases of 'e' for 'east' etc. (If not then you'd get
> a client and alias it to that yourself). So it's only really 2 keys
> to go 'east' rather than the 3 cursor key hits. It's still a nice idea
Ok, that occurred to me in the weekend. You could even map the compass
directions to the keypad if you wished to make it one key.
> though, i might try it one day to see if it aids immersion in the game
> world. Going e;s;w;n doesn't usually convey a circular 'feeling', in my
> mind's eye i'm viewing my character from above. Using this left/right
> lark might bring me mentally into the first-person.
Thinking about it during the week, it occurs to me that the main advantage
IMO is the first person perspective. Thats what I like about Bloodwyche,
I had most of the game memorised as to the turns and movements I had to make
to get from A to B, I could see in my minds eye where I was going even though
the 3d perpective of the character was moving too fast to really see.
With the compass directional approach, I would suspect that most players
would have an alias for all the directions from A to B and just hit that rather
than type in all the directions from memory.
Also, add 'around' as another option relatively (i.e. 'turn around').
Richard
In article <6gsg72$4...@news.Hawaii.Edu>, yo...@Hawaii.Edu (Nathan Fenenga Yospe) writes:
> I actually use a fourth method now, though I do use a bit of LRFBUD... they
> make more sense than cardinals... I now rely mainly on approach, with a key
> of > shortcutting "approach", and the client has a switch that assumes that
> you mean "approach Foo" on any unparseable "Foo". Approach is quite good if
> you have a roomless landscape system. There's also "face", "look left/back/
> right/up/down/ahead", and other commands for positioning and movement. Some
> motion even assumes curvature. Scouting a wall, for example.
If I even suggested this on my mud, the comment that would come up would be
that no-one would play because of the difference and complexity over what
they are used to. Personally I agree but also, for me this level of detail
comes under the 'might as well code a 3d client' umbrella. I wonder if your
mud is role-playing oriented (which would warrant it IMO)?
Although I would have to stick my neck out and say that all my creators
are die-hard lp people, what diku-ites like is not something I am familiar
with at all.
Richard
> (Eggjon)
>>who mapped the commands to his keypad and you could use them kind of
> like
>>you would play a 3d game. e.g. like Dungeon Master or Bloodwyche.
> :)
>
> --Craig (Presto)
>
>
Dammit! I knew someone from Discworld was going to pop up and point that out :)
John Adelsberger
In rec.games.mud.lp Matt Chatterley <ma...@mpc.dyn.ml.org> wrote:
: I don't really like the shadowrun model, although it has one or two good
: points and bad points that I'll list:
: It's too random. If you had a rating of 200 in a skill, you roll 200d6,
: and come up with 200-1200 as a result; quite a dramatic spread. Now, you
: may consider a solution is just not to use this many 'points', but I
: suspect most people want a very 'smooth' transition from novice to expert,
: and thus a lot of levels inbetween (my own system uses 1000).
SR skills of 8 are doctoral degree level. This means that even if you're
the god of war, your unarmed skill of 10 or so has a spread of 10-60.
Given that we're modelling people, and not infallible beings, that spread
is reasonable, _because_ the VAST majority of those dice are going to fall
in the middle range or cancel each other towards the middle range; for
instance, on 2 dice, the spread is 2-12, but the likely spread is more
like 5-8 or 4-9. As such, you _can_ really screw up or do amazingly well,
but it doesn't happen that often. The odds of rolling all 6s on 5 dice
are vanishingly small, but it _could_ happen.
My problem with the SR system is not the skill system; my problem is
power inflation caused by the need to sell more books and by the utterly
insanely stupid magic system they've got. I cast Analyze device as a
brand spanking new hermetic mage, throw all my pool dice into it, and
I have more skill with that weapon than an Olympic fencer could ever
dream of. Please...
Matthew R. Sheahan
the Shadowrun skill system is severely broken. do you know of a single
Shadowrun character with a swimming skill? because the numbers are so
small and because skills are only useful with 4 or more dice, only a moron
would put 1 die into swimming when that same die could increase their
firearms skill by 20% to 50%.
then there's how those dice are actually used, which is incredibly
brain-dead. sit down and work out the statistics on target numbers 1
through 18 with six skill dice. talk about your ugly-ass graphs.
target number 6 is twice as difficult as target number 5 while target
numbers 6 and 7 are _identical_, for one thing, and that's just the
start of how the probabilities skew all over the place. (White Wolf
has a much smaller version of this problem, deflated because they use
bigger dice, don't do the whole reroll-and-add thing, and combine stats
and skills for effects rather than relying solely on skill dice.)
me, i like the Shadowrun setting. it's great as GURPS source material.
chiaroscuro
Craig Hackenmueller
news.cc.umr.edu> <2_HZ.29$O1.4...@nntp1.nac.net>
Organization: Cloudnet - St. Cloud, MN (320) 240-8243
Distribution:
I like shadowrun system because of the setting and theme. But if you want
to get into skill systems and spells. My favorite is the Earthdawn system.
It is a little less random that the AD&D system and more structured than
SR. BTW, you folks talking about shadowrun and adding up dice totals. It
isn't done that way. You have to hit a target number with EACH die, not
just a total. And any intelligent GM wouldn't give you a target number of
7 cause they would know that a 6 is just as likely.
On a mud, I believe a %age based system would be the easist to design and
implement. Doubt it is the best from how our own mud is. I'd like to see
an Earthdawn system implemented somewhere, and see how that fairs.
Anyone wondering how Earthdawn works...go buy a source book and read, too
long to explain :)
Raheal of Ebon Mists
ebonmists.ml.org 8888