Skill based systems
Filipe G. Magro
> bra...@mbox.vol.it (Marco Braga) wrote in article
<31e96764...@nntpserver.vol.it>...
> I must admit I've never played a skill based MUD, but basing on
> various threads about them on this group I must admit they seem to be
> an intriguing alternative if not a real win over the old D&D
> level/experience systems.
I have never really played any MUDs, but I play ElendorMUSH which I think
has an awesome Combat system that might help.
First, ElendorMUSH is a MUSH heavily based to Role-Play of your character,
but
combat is a major part of the game. I have lost characters in combat.
[stuff deleted]
> 2) Another idea is to just "flag" used skills, but then require some
> time to pass before the skill can raise, so that a fastly repeated use
> won't do the trick. But if you do this, players will just try all
> available skills and then quit just to logon later and try it again,
> or just sit idly waiting for their skill to raise, or even worse try a
> larger range of skills so that when they reach the end of the list the
> first they used have improved and can start the sequence again.
[stuff deleted]
This second idea of yours, I feel is rather workable. ElendorMUSH has
players that having been around long enough, and decided to go that way,
have become trainers with certain weapons within their cultures. Combat
approved players, are registered with a primary weapon, but may use any
weapon (albeit poorly at first) and can improve their combat skills (these
are Strength, Dexterity, Endurance, etc.) by recieving training from the
trainers. Only catch is, the game forces a RL week between training
sessions. So, if I train on one day, I can only be trained again 8 days
later. Another neat feature, is the fact that training with a long sword,
improves my skill (though not as much) with other similar weapons (staff,
other swords, etc.). :)
*** If it ain't RP, it ain't RL! ***
--
=================
Filipe G. Magro
================= -/- ma...@frontiernet.net
<LinuxLord>
=================
Marco Braga
On 15 Jul 1996 13:35:06 GMT, acc...@tam2000.tamu.edu (Anthony C.)
wrote:
>No one single hack can fix "cheating" of skills, but if the game
>infrastructure is built around skills then improvement through use
>can work fine.
That's right, the bat part of this is that players seem sometimes to
be really good at finding holes in game systems, so che sytem you
might think is good will prove to be not so good or unworable at all.
>1) improvement costs money, if the player just sits and tries to improve
> then he will run out of money. If someone wants to give him money thats
> fine, but it will be very expensive. Higher skill levels require higher
> stats, sometimes training will require a quest. There is more to it than
> this but this is the basic idea. Requires that money is always an issue.
This seems a good idea, but in the system I am thinking about
improvement is an automatic thing, so if a cost in gold seems rather
logical when training with masters, it does not seem to good when
training by simple use of the skill. How do you justify the cost in
this last case?
>2) Age, training ages you, so eventually you die of old age. The most
> expensive and rare items in the game are deaging potions, if you just
> train yourself without doing anything then you will never be able to
> afford the expensive potions, even the highest level chars have trouble
> paying for them.
Sure age must be an important part, but the point "training ages you"
seems quite unlogical and unrealistic. Time ages you, not training.
>3) Experience for combat skills is based on difficulty of creatures fought.
Yes, this is a solution for combat based skills, but what about a
"hide" skill?
>4) Spells require spell components, these must be found or purchased.
That's a good idea, as components will cost gold and this will provide
a good reason not to waste spells, even if you do that just to learn.
>What kind of algorithms should be used for improvement? I personally
>like to take a mathematical approach to looking at improvements.
Me too, but sometimes seems a rather hard job to come out with the
magic of a really working formula..
>Did that make sense? Essentially I want a mathematical description of
>the predicted improvement, players could do worse than this but this would
>provide the fastest rate of improvement in game years and in player hours.
Well, I suppose it's not very easy to tell in advance how many uses
will be necessary to become a master. Of course there are factors
influencing this, such as wisdom and intelligence, but even the bare
number is not easy to predict.
My question is, since there are muds using skill systems how do they
solve the problems I've told about?
[snip]
> How many times should they be used to reach a reasonable proficiency?
Well that's another problem, but I think this is the old balancement
question, all new systems need to be trimmed to working values. Btw,
don't ask me the magic number, because I've asked first.. 8-]
Marco
-=======================================-
- Marco Braga - email: bra...@mbox.vol.it -
-=======================================-
Anthony C.
In article <31ea9a48...@nntpserver.vol.it>,
Marco Braga <bra...@mbox.vol.it> wrote:
:On 15 Jul 1996 13:35:06 GMT, acc...@tam2000.tamu.edu (Anthony C.)
:wrote:
:
:>No one single hack can fix "cheating" of skills, but if the game
:>infrastructure is built around skills then improvement through use
:>can work fine.
:
:That's right, the bat part of this is that players seem sometimes to
:be really good at finding holes in game systems, so che sytem you
:might think is good will prove to be not so good or unworable at all.
I hope you all can help me find holes too :)
:
:>1) improvement costs money, if the player just sits and tries to improve
:> then he will run out of money. If someone wants to give him money thats
:> fine, but it will be very expensive. Higher skill levels require higher
:> stats, sometimes training will require a quest. There is more to it than
:> this but this is the basic idea. Requires that money is always an issue.
:
:This seems a good idea, but in the system I am thinking about
:improvement is an automatic thing, so if a cost in gold seems rather
:logical when training with masters, it does not seem to good when
:training by simple use of the skill. How do you justify the cost in
: is last case?
Ok so the way I have it planned is that there are several ways to improve
skills. My skill system is out of 1000, your skills can improve alone
automatically but every 10 levels you require training which requires a
skill role on the part of the trainer. Training can be self taught,
guild taught, or other player taught. The advantage of self teaching
is free, the disadvantage is that you age a lot more, and have a high
risk of failure at low levels. The advantage of guild teaching is that
its automatically successful (or has a high prob of success) but the
disadvantage is that it costs a lot. The advantage of having someone else
teach you is that someone can be your friend and you can do it for free.
The disadvantage is that you both age (and years are the most expensive
commodity in the game) and that the skill roll for training depends on the
skill of the teacher. So you could both age a lot in the process.
Someone who is high level enough to have a high success in training will
also be likely to start having to worry about age.
:>2) Age, training ages you, so eventually you die of old age. The most
:> expensive and rare items in the game are deaging potions, if you just
:> train yourself without doing anything then you will never be able to
:> afford the expensive potions, even the highest level chars have trouble
:> paying for them.
:
:Sure age must be an important part, but the point "training ages you"
:seems quite unlogical and unrealistic. Time ages you, not training.
Uh yeah the point is training under the tutelage of an instructor takes time.
Seems very reasonable and logical to me :) thats why Im using it.
:>3) Experience for combat skills is based on difficulty of creatures fought.
:
:Yes, this is a solution for combat based skills, but what about a
:"hide" skill?
See below, that is what my whole question was. Im not sure how to improve
a hide skill. Thats the original reason why I wrote this post :)
:>4) Spells require spell components, these must be found or purchased.
:
:That's a good idea, as components will cost gold and this will provide
:a good reason not to waste spells, even if you do that just to learn.
:>What kind of algorithms should be used for improvement? I personally
:>like to take a mathematical approach to looking at improvements.
:
:Me too, but sometimes seems a rather hard job to come out with the
:magic of a really working formula..
Well thats why I wanted to ask people who may already have experience
doing this :) I know Im not the first to use a fully skill use based
system. Lets pick their brains.
:>Did that make sense? Essentially I want a mathematical description of
:>the predicted improvement, players could do worse than this but this would
:>provide the fastest rate of improvement in game years and in player hours.
:
:Well, I suppose it's not very easy to tell in advance how many uses
:will be necessary to become a master. Of course there are factors
:influencing this, such as wisdom and intelligence, but even the bare
:number is not easy to predict.
No just the absolute fastest, the shortest possible time.
:My question is, since there are muds using skill systems how do they
:solve the problems I've told about?
My question too :)
:[snip]
:> How many times should they be used to reach a reasonable proficiency?
:
:Well that's another problem, but I think this is the old balancement
:question, all new systems need to be trimmed to working values. Btw,
:don't ask me the magic number, because I've asked first.. 8-]
heheheh ok :) Well we are both asking those who have come before us. :)
If it takes on average 10 swings to kill a mob of your equivalent power,
and you can kill say 500 in one night, thats 5000 swings. Thus the
total number of swings for advancement with a target of perfection at
6 months of play time is 180 days * 5000 swings = 900,000 swings.
So the algorithm should be based on about 900,000 swings for combat.
Combat spells should be based on approximately the same number.
How about the other skills? Something more like 50,000 uses for the less
used skills, where the situation doesnt come up as often?
--
Anthony C.
Nacht
> Marco Braga <bra...@mbox.vol.it> scrupulously scribbled:
> I must admit I've never played a skill based MUD, but basing on
> various threads about them on this group I must admit they seem to be
> an intriguing alternative if not a real win over the old D&D
> level/experience systems.
Don't have it yet, but I've been tossing the idears around for long while.
Glad to see other great minds thinking alike. ;-)
However, I prefer to let the players select for themselves how to "spend"
their earned experience (yeah, it's less *realistic* but the whole thing
is
just a game anyway, for most of us). I try to envision how I would prefer
things to be were I a player inside the system, and that's what I think I
would prefer.
Point in case, myself and a lot of other players of ROM muds, prefer those
which give us bonus trains for using fewer than 40 creation points in the
customized character creation system. This gives us *choice* about how
to spend our accumulated "adolescent/apprenticeship" knowledge...
A mildly random chance of earning an "experience point" which can be used
in a variety of ways would be ideal to me. Make it depend on the
difficulty of
the task completed, etc. Use it to raise stats or skills...
Also, I envision such things as a max of two "experience points" per game
month for normal human endeavor and learning potential, which would lead
eventually, say fifteen years later, to a character who did nothing but
train
in one field to become recognizable as a "master" of that skill...
I think that gradations of skill, inside of which are equal bonuses, are
also
more believable (better word than realistic for RPGs). I.e.:
0 xps = Untrained = -5 (on a d20 scale)
1 to 20 xps = Novice = +0
21 to 50 xps = Initiate = +2
...
180+ xps = Master = +20
You could adjust the learning curve to be as steep or shallow as you want,
or even key it off of the skill in question, to make a Master swordsman
much
better relative to a Novice Swordsman than a Master computer programmer
would be relative to a Novice computer programmer (if you feel that to be
more
believable).
Yes, those are similar to the rules I use for my own homebrew
paper-n-pencil
RPG... Someday I'll get around to coding it. Right. ;-)
--
David Reed <na...@neosoft.com> Armed with PGP
Refuge Technologies Member - HWG
Marco Braga
I must admit I've never played a skill based MUD, but basing on
various threads about them on this group I must admit they seem to be
an intriguing alternative if not a real win over the old D&D
level/experience systems.
Some people here think they score a win against all those players
rushing on combat just to gain experience, and then use that
experience to practice skills they never really practiced by use. A
learn by use based system seems to be the solution, but how do you
discourage players from just repeating the same skill over and over
till they reach a decent knowledge of it? For example a thief might
just type hide over and over, and learn by failure; a cleric might try
to kill a mob and then heal him (it?) just to improve his healing
skills.
I've played several skill based paper RPG, but the presence of a human
DM seems to be necessary to judge if an effort using a skill is really
worth some experience and improvement.
None of the ideas I've made up seem to prevent this unwanted abuse of
the system:
1) Making combat skills improve just after a fight and not on each use
seems a good idea, but the players would start a fight and try to use
all available skills just to improve a broad range of them. I.e.
repeating the sequence bellow, kick, bash, disarm, flee. Over and
over.
2) Another idea is to just "flag" used skills, but then require some
time to pass before the skill can raise, so that a fastly repeated use
won't do the trick. But if you do this, players will just try all
available skills and then quit just to logon later and try it again,
or just sit idly waiting for their skill to raise, or even worse try a
larger range of skills so that when they reach the end of the list the
first they used have improved and can start the sequence again.
All this seems to point out the real problem: a computer program might
have hard time trying to judge when a skill is used in an intelligent
way and it is used stupidly just to exploit the mechanics.
Any solutions? How have the various skill based MUDs solved those
problems?
gry...@iaehv.nl
In article <31e96764...@nntpserver.vol.it>,
Marco Braga <bra...@mbox.vol.it> wrote:
>learn by use based system seems to be the solution, but how do you
>discourage players from just repeating the same skill over and over
>till they reach a decent knowledge of it?
>For example a thief might
>just type hide over and over, and learn by failure
Make a failed hide actually -loose- you some proficiency in the skill.
Or, as the player repeats the same skill over and over again, increase
the change to forget rather than learn from the skill slowly.
> a cleric might try
>to kill a mob and then heal him (it?) just to improve his healing skills.
A cleric that attacks monsters to be able to heal them deserves to
find her healing skills diminished. That's a matter of the way Healing
is supposed to work. By typing kill or assist the cleric should become
uncapable to learn to heal for a long time.
>1) Making combat skills improve just after a fight and not on each use
>seems a good idea, but the players would start a fight and try to use
>all available skills just to improve a broad range of them.
Just flag one of the possible skill and allow only that skill to be
learned. Each use of a different skill reduces the maximum percentage
you can learn. After three or four times you hit zero and won't learn
anything from using that skill. If you leanr many skills you don't
have much chance of improving it through learning.
>All this seems to point out the real problem: a computer program might
>have hard time trying to judge when a skill is used in an intelligent
>way and it is used stupidly just to exploit the mechanics.
Probably, but that doesn't mean the game designer cna't do something
smart. Perhaps have a variety of systems one of which is chosen at
random until the player improves a skill. That will defeat all but
the most persistent players that are planning to cheat the system.
And the best of all. Don't tell players how well they do in a skill.
Marian
Anthony C.
In article <4se78k$p...@news.cic.net>, <sti...@phish.nether.net> wrote:
:I know I didn't articulate that well, but my basic desire is to make eq a
:challenge to get. It shouldn't just be hacking away at monsters and
:getting the Super Dragon Sword. To get the Super Dragon Sword players
:would have to hunt out the hide of a dragon, a bronze hilt, and a steel
:broadsword......all challenges in themselves. To balance this out, spell
:casting should also be hard to do, if players really want to learn Mass
:Lightning then they're going to have to collect a vial of water from
:some dangerous body of water, and the scales of a shark.
Yes! So I have a basic set of equipment (which is very extensive) but
also generic. If people want some fancy equipment they have to find
a magic Tome which will tell them how to make it, then they have to gather
the pieces to make it. When say a manual of that type is found, the dragon
king (who is run by a game master) is alerted and he can send dragons out to
hunt the person who possesses the Tome for making such a weapon. etc etc :)
If other people find out about it maybe they will want it too.. :>
When an item of this sort is found, perhaps some NPCs can somehow find out
about it and casually mention it to other players. In any case this
is exactly what Im attempting to do in my mud :)
>
>This is just randoming thinking, but I really hope someone gets the idea.
>
>Jguile/Muiy
>
--
Anthony C.
Anthony C.
:various threads about them on this group I must admit they seem to be
:an intriguing alternative if not a real win over the old D&D
:level/experience systems.
No one single hack can fix "cheating" of skills, but if the game
infrastructure is built around skills then improvement through use
can work fine.
Here is what I do:
1) improvement costs money, if the player just sits and tries to improve
then he will run out of money. If someone wants to give him money thats
fine, but it will be very expensive. Higher skill levels require higher
stats, sometimes training will require a quest. There is more to it than
this but this is the basic idea. Requires that money is always an issue.
2) Age, training ages you, so eventually you die of old age. The most
expensive and rare items in the game are deaging potions, if you just
train yourself without doing anything then you will never be able to
afford the expensive potions, even the highest level chars have trouble
paying for them.
3) Experience for combat skills is based on difficulty of creatures fought.
4) Spells require spell components, these must be found or purchased.
There are probably some other things I do but they dont come to
mind immediately.
What I really want to discuss is the mechanism of improvement on
skill based only systems, ignoring reptition and cheating and focusing
on the normal mechanism for advancement.
What kind of algorithms should be used for improvement? I personally
like to take a mathematical approach to looking at improvements.
Like it should take at the fastest, X gold, Y number of uses, Z number
of game years, and W number of player hours assuming a maximum experience
gain of V experience/hour (or U creatures/hour) to reach maximum proficiency .
Did that make sense? Essentially I want a mathematical description of
the predicted improvement, players could do worse than this but this would
provide the fastest rate of improvement in game years and in player hours.
Combat Skills (used often so should require more uses 10,000 to max out?)
experience is given by the relative strength of the creature or player
opponent. But what sort of skill improvement rate would be good?
I just want to know approximately how many uses should it take to
max out the skill, I could probably make the algorithm fit this.
Should it only take 1000 uses?
Skills used a lot (combat, healing etc) these are improved on a per use
basis, not based on the creature killed. (see 1 above about just reusing
the skill over and over on wimpy creatures to improve). Should they
improve as a roll against failure? i.e. if the chance of success is
20% the chance of improvement is 80%? or should it be something like
if the chance of success is 20% I need to make an 80% 5 times before the
skill improves? Again it comes down to how many times a skill needs to
be practiced before it becomes maxed. How many till the user is moderately
proficient etc. Obviously the early levels should improve faster than the
later levels. Some sort of log algorithm would work fine.
Skills used less often, teleport, identify, swim.
How many times should they be used to reach a reasonable proficiency?
So the things I like to consider are, in the normal lifespan of a human
(50 years) what is the absolute maximum number of total skill
levels a player could have? (training takes time) How much gold should
this take? (my economy is closed and fixed) and how many uses should
it take to reach a max level?
If this doesnt make sense please let me know and I will try to clarify.
--
Anthony C.
Anthony C.
I was proofreading after I posted and realized that I had a couple
of homonym spelling errors. Those of you who read the other thread where
I mentioned that I seem to be doing that a lot more will see this as a
classic case where the speech part of my brain takes control of my fingers
and spells words like skill roll as skill role. :) Oh well
One day I will begin to proofread before I post :>
--
Anthony C.
Matt Chatterley
On Mon, 15 Jul 1996, Marco Braga wrote:
> I must admit I've never played a skill based MUD, but basing on
> various threads about them on this group I must admit they seem to be
> an intriguing alternative if not a real win over the old D&D
> level/experience systems.
It is IMHO a real win yes, gives the characters more flavour than if
theyre just an X level Mage with Y and Z abilities, it all depends on what
theyre skilled at, level only governing the maximum skill levels (usually
in my experience there are levels.. but they have no effect other than the
above).
> Some people here think they score a win against all those players
> rushing on combat just to gain experience, and then use that
> experience to practice skills they never really practiced by use. A
> learn by use based system seems to be the solution, but how do you
> discourage players from just repeating the same skill over and over
> till they reach a decent knowledge of it? For example a thief might
> just type hide over and over, and learn by failure; a cleric might try
> to kill a mob and then heal him (it?) just to improve his healing
> skills.
>
> I've played several skill based paper RPG, but the presence of a human
> DM seems to be necessary to judge if an effort using a skill is really
> worth some experience and improvement.
>
> None of the ideas I've made up seem to prevent this unwanted abuse of
> the system:
>
> 1) Making combat skills improve just after a fight and not on each use
> seems a good idea, but the players would start a fight and try to use
> all available skills just to improve a broad range of them. I.e.
> repeating the sequence bellow, kick, bash, disarm, flee. Over and
> over.
Well, in this example, using combat skills generally has a time delay
between uses (ie you can only bash once every 5 seconds for example), and
uses some form of points (say.. Stamina Points, SPs), if you dont have
enough you cant do it. The amount that skills train is usually less the
higher the skill is, requiring you to spend mroe and more points using
better and better abilities to train.
> 2) Another idea is to just "flag" used skills, but then require some
> time to pass before the skill can raise, so that a fastly repeated use
> won't do the trick. But if you do this, players will just try all
> available skills and then quit just to logon later and try it again,
> or just sit idly waiting for their skill to raise, or even worse try a
> larger range of skills so that when they reach the end of the list the
> first they used have improved and can start the sequence again.
>
> All this seems to point out the real problem: a computer program might
> have hard time trying to judge when a skill is used in an intelligent
> way and it is used stupidly just to exploit the mechanics.
>
> Any solutions? How have the various skill based MUDs solved those
> problems?
See above. :) You can see how the system is implemented on a number of
MUDs (I refer particularly to insomnia MUD).
> Marco
>
> -=======================================-
> - Marco Braga - email: bra...@mbox.vol.it -
> -=======================================-
>
>
Regards,
-Matt Chatterley
http://user.itl.net/~neddy/index.html
"Do not meddle in the affairs of Wizards, for they are subtle and quick to
anger." --J.R.R Tolkien
Travis S Casey
Marco Braga <bra...@mbox.vol.it> wrote:
>I must admit I've never played a skill based MUD, but basing on
>various threads about them on this group I must admit they seem to be
>an intriguing alternative if not a real win over the old D&D
>level/experience systems.
>
>rushing on combat just to gain experience, and then use that
>experience to practice skills they never really practiced by use. A
>learn by use based system seems to be the solution, but how do you
>discourage players from just repeating the same skill over and over
>till they reach a decent knowledge of it? For example a thief might
>just type hide over and over, and learn by failure; a cleric might try
>to kill a mob and then heal him (it?) just to improve his healing
>skills.
>
>I've played several skill based paper RPG, but the presence of a human
>DM seems to be necessary to judge if an effort using a skill is really
>worth some experience and improvement.
>
>None of the ideas I've made up seem to prevent this unwanted abuse of
>the system:
>
>1) Making combat skills improve just after a fight and not on each use
>seems a good idea, but the players would start a fight and try to use
>all available skills just to improve a broad range of them. I.e.
>repeating the sequence bellow, kick, bash, disarm, flee. Over and
>over.
>
>time to pass before the skill can raise, so that a fastly repeated use
>won't do the trick. But if you do this, players will just try all
>available skills and then quit just to logon later and try it again,
>or just sit idly waiting for their skill to raise, or even worse try a
>larger range of skills so that when they reach the end of the list the
>first they used have improved and can start the sequence again.
>
>All this seems to point out the real problem: a computer program might
>have hard time trying to judge when a skill is used in an intelligent
>way and it is used stupidly just to exploit the mechanics.
>
>Any solutions? How have the various skill based MUDs solved those
>problems?
Here are a few more possible solutions:
1. Redefine what "use" means. For example, if a thief hides in
a room when there's no one around who can see him anyways,
should it count?
My personal feeling on "hide"-type skills is that they should
work like this:
When the character types "hide", a toggle is turned on
which indicates that he/she is hiding.
The skill is not checked until/unless someone comes in
who might see the thief. If you want to get complicated,
you could check first whether the character in question
is hostile to the thief (for monsters, at least).
b) It's possible to divorce advancement checks from skill
checks. Thus, advancement might only be allowed under
certain circumstances. For instance, combat skills might
only advance when you are fighting a monster. This can
be useful for muds which allow players to stop attacking
each other.
2. The chance of advancement can be tied to the chance of
success. That is, if something is easy, the character
shouldn't be able to advance as much as if they were
doing something hard. You might want very easy uses
to give *no* advancement. On the other end of things,
you can have a point of diminishing returns... if
something is too hard, you won't learn as much from it.
3. Have different skills advance at different rates. Skills
which are used a lot can advance more slowly than others.
For instance, on a typical combat-intensive mud, it would
be reasonable for combat skills to take more uses to
improve than other skills.
4. Skill forgetting. In real life, if you don't do something
for a long time, you tend to forget how to do it. In the
same way, skills that a character doesn't use often can
decay with time.
These don't really directly address the problem you mention, but
could be helpful:
5. Prerequisite skills. That is, before you can learn
skill X, you have to know skill Y at at least level Z.
This encourages characters to "branch out" as their
skill level improves.
6. Have lots of skills. If there are hundreds of different
skills, it'll be very hard for a character to become good
at all of them.
7. Have the difficulty of going up in a skill be a function
of how good you are at it; that is, an expert is less
likely to learn something that he doesn't already know
than a novice.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Manager, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-4290; Room 101C Carothers
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
sti...@phish.nether.net
Since everyone and their grandmother are giving their ideas on a skill
based system, I figured it was about time I gave mine.
I suppose that the basic premise this system works on is that no player
can become _that_ skilled. That every player will eventually 'max out' in
their skills, and if they wish to improve at other skills, they'll get
weaker in others.
I'm not sure what form this should take, so I'll just throw out random
ideas:
1) Skill improvement is based on use. Combat skills are improved by
using them in combat (important: skill improvement is also dependent on
the skill of the target (mob, in this case), spells are improved by
studying and casting, metal forging is improved by, you guessed it, metal
forging, etc.
The different that I would like to see from most people's ideas is that
when a skill is neglected it gets worse. If I don't cast 'color spray'
for 10 game days while I work on bash, then I'm going to be pretty bad at
making pretty colors come out of my hands next time around.
Basically what happens is that no super-players exist. There are lot of
players who are, skill-wise, equal. They just do different things.
2) The crux then, to who is 'most powerful' is eq and player skills.
I'll start with character skills, because that will probably be the more
debatable one. My thought is this: If there are a significant number of
more or less 'equal' players, then the people who have the most impact on
the power struggles of the mud are those who are part of the biggest,
best-run clans. Your influence on the mud then, is not so dependent on
how physically skilled your character is, but how much charisma,
leadership, eloquence (do I hear roleplaying?) you, as a player, have.
The second determinant is eq. I think this is a pretty obvious
relationship, if players are equal in skills, then eq will determine who
wins in a fight, can kill the large mob, etc.
What would make the eq a 'just' determinant (by 'just' I mean an increase
in power that takes more than just hours of mud time, but actual thought)
in my system is how difficult good eq is to get. Only the barebones sort
of eq would be found on monsters. The powerful eq would either have to be
bought (in this system, making money would be a challenge in itself) or
gained by collecting various components and making it, or questing.
Similarly, all spells would need certain components to be cast.
I know I didn't articulate that well, but my basic desire is to make eq a
challenge to get. It shouldn't just be hacking away at monsters and
getting the Super Dragon Sword. To get the Super Dragon Sword players
would have to hunt out the hide of a dragon, a bronze hilt, and a steel
broadsword......all challenges in themselves. To balance this out, spell
casting should also be hard to do, if players really want to learn Mass
Lightning then they're going to have to collect a vial of water from
some dangerous body of water, and the scales of a shark.
This is just randoming thinking, but I really hope someone gets the idea.
Jguile/Muiy
Orion Henry
>challenge to get. It shouldn't just be hacking away at monsters and
>getting the Super Dragon Sword. To get the Super Dragon Sword players
>would have to hunt out the hide of a dragon, a bronze hilt, and a steel
>broadsword......all challenges in themselves. To balance this out, spell
This is fine, as long as you don't make items possible to get like
Super Dragon Boots, Super Dragon Undies, Super Dragon Pinkie-Rings,
etc. Because players will eventually get all the pieces of Super
gear that they can. Weapons are usually good for this: you end up
with Coinspinner or Anduril, Flame of the West. But rarely do you
see characters in books with boots named "Ironsoul, Protector of my
Feet" or gloves named "Silverhands, Which Keep my Hands Warm."
George Reese
A lot of this talk seems to miss the fact that players like to compare
themselves with others based on some sort of absolute scale (aka
level). Nightmare works this by being entirely skill based but
providing a level system that allows them to choose how they wish to
be measured. While not quite absolute (a level 5 fisher does not
compare in any meaningful way to a level 5 mage), it still provides a
method for basic "who is doing best" comparisons.
Classes are used simply to define how the player views themself. In
other words, players can advance and learn skills outside their
classes, but the measure of what kind of player they are is done in
terms of what class they are.
For example, take in real life the best darn bus driver in the world
and Michael Jordan. The bus drver is a level 100 bus driver and
Michael Jordan a level 100 basketball player. How good of a
basketball player the bus driver is has no effect on how he is viewed
professionally so long as he is a bus driver. Similarly, Michael
Jordan can be a damn good bus driver, but that is irrelevant to the
fact he is primarily a basketball player.
Of course, some very talented people can have multiple professions.
Oddly enough, Nightmare supports this too :)
More interesting, of course, would be comparing Michael Jordan chosing
to drive if he were a poor bus driver. The fact that he can play
basketball incredibly is totally irrelevant to his measure as a bus
driver.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
i think i've reached that point/where every wish has come true/
and tired disguised oblivion/is everything i do
-the cure
Anthony C.
In article <4sf9gc$6...@sdcc12.ucsd.edu>,
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
:will result in druids not needed money but thieves can't get enough
:of it. (If you're doing a skill based system I highly recommend
:yanking classes, but I still tend to refer to characters' general
:skill types by class.)
class=guild=profession or whatever.
Hmm ok I dont refer to skill types by class, any player can learn any
skill since any player can potentially teach any skill he has learned.
The purpose of a guild is to provide a training ground for certain skills.
The primary benefit to joining a class is to get the advantages of
the best training available in certain skills. Not joining a class
does not preclude learning skills, but it means they are more expensive
to learn (in terms of age if not gold). People with similar skills
would tend to band together to help each other improve their skills
and to "share secrets" moreover if the use of their skills is a commodity,
then most likely they will try to hide those secrets from others to keep
their skills a valuable commodity. If thieves are the only guild that
can cast magic opening spells, then they should be in demand, if somehow
other people learn those skills (which they will of course - no reason to
preven that) the value will go down, but thieves will improve the fastest
for the cheapest amount.
:
:>2) Age, training ages you, so eventually you die of old age. The most
:> expensive and rare items in the game are deaging potions, if you just
:> train yourself without doing anything then you will never be able to
:> afford the expensive potions, even the highest level chars have trouble
:> paying for them.
:
:Sounds hacky to me. There are many better ways, I think.
Weird.. I dont know why this sounds hacky.. learning skills should age
you, the time spent training should be significant and should increase
as you get more skilled. Think of the learning process as two stepped,
you fight in combat and learn, but you also have to practice what you learn
and this takes time in months. Anyway I dont think this is hacky at all :)
:>3) Experience for combat skills is based on difficulty of creatures fought.
:
:Absolutely! It's completely stupid to think I'm going to get better
:at bash by bashing a cat, just as it is silly to think I'll get
:better at doding by trying to dodge a stone golem with a dex of 3.
Plus if you use awesome equipment that increases your power, so killing
the orcs that normally would be around your power level doesnt help you
at all.
>>What kind of algorithms should be used for improvement? I personally
>>like to take a mathematical approach to looking at improvements.
>>Like it should take at the fastest, X gold, Y number of uses, Z number
>>of game years, and W number of player hours assuming a maximum experience
>>gain of V experience/hour (or U creatures/hour) to reach maximum proficiency .
>>Did that make sense? Essentially I want a mathematical description of
>>the predicted improvement, players could do worse than this but this would
>>provide the fastest rate of improvement in game years and in player hours.
>
>I suppose this would be all right, but it sounds kind of arbitrary.
>How do you really decide upon these values realistically?
It is arbitrary, Im not trying to mimic real life here, my game isnt
exactly a mud, its more like a multiplayer dungeon hack. My rules are
arbitrary, and I am basing improvement on a timeline of how I would
like to have people improve. So for example I would like the average
player to take 3 months to max out a skill. As opposed to one day or as
opposed to 10 years.
:You're still looking from the wrong angle. I can punch the wall
:1000 times, but I'll probably learn more about fist-fighting by
:going down to my local tavern and getting in a fight or two.
:Even if I only throw sixteen punches, I've already gained more
:knowledge and experience.
Well I dont think you quite understand the approach Im taking.
I understand the above and have implemented increase of combat skills
based upon the power of your opponent. However at the most abstract
level you CAN look at it as how many uses should it take against an
opponent of identical power to max out? Against superior opponents then
the number of uses will decrease, against inferior opponents the number
will increase. At some point as a game designer you have to estimate
how long it should take players to complete certain tasks, otherwise
your game might only last an hour, or might be too long at 10 years.
Does this make sense? I just want to estimate these numbers for playability
not for realism.
:>Skills used less often, teleport, identify, swim.
:> How many times should they be used to reach a reasonable proficiency?
:
:How do you determine what's used less often? A fighter uses his
:weapon skills constantly, and a druid not at all. A thief uses
:sneak and hide constatly, but spells not at all. And this is just
:generalizing - there's one thief who's got a lot of fighter skills
:but a few underhanded kind of things, like maybe sneak, or another
:who knows nothing about fighting but can pick locks and pockets like
:a champ.
Yes but there are more opportunities for a fighter to kill creatures,
i.e. a fighter can swing his sword 1000 times in 1 hour of play time,
but a thief can only find about 100 locks to pick. If there is one
lock per encounter and the warrior gets 100 swings/encounter then
the thiefs skills is used on average 100 times less. Obviously
there are other places where a thief might use his lockpicking skill
but lockpicking in general cannot be used as often as a combat skill.
The point is not that the druid doesnt use his fighting skill
vs some other skill, but relative to all skills available in the game,
what opportunities are available for that skill to be used. Teleport might
get used once every 10 minutes, but combat skills get used 10 times a minute,
should they improve at the same number of uses? no, so based on
a max skill of about 1000, it might take 50,000 sword uses, vs 5,000 teleport
uses to max out. Teleport costs money etc and just wont be used much.
:>So the things I like to consider are, in the normal lifespan of a human
:>(50 years) what is the absolute maximum number of total skill
:>levels a player could have? (training takes time) How much gold should
:>this take? (my economy is closed and fixed) and how many uses should
:>it take to reach a max level?
:
:Of course training takes time - this is why I can never be both the
:best computer programmer in the world and the best basketball player
:simutaneously. But there's no reason I can't be damn good at both -
:I just have to divide my time between coding and playing basketball.
:And of course, if ALL I do is eat, sleep, code, and shoot hoops, I'm
:gonna be both a damn good coder and a damn good basketball player.
:But I won't have much time for anything else.
I see the misunderstanding, I meant to ask what is the total number of
maxed skills a player should have. If a player can have 10 maxed skills
and 1 max skill is about equal to 10 halfway improved skills then lots
of combinations of course are possible. My error..
:Also, why is your economy closed and fixed? I doubt such a thing
:has ever existed, except in fantasy worlds, and even there it's not
:terribly interesting. And despite code attempts to the contrary,
:I've yet to see a MUD where money doesn't start to devaule
:(inflation) over time.
Of course it exists, we just havent reached the limit in our world.
What I mean is fixed in the sense that the whole world has a certain amount
of wealth that can be given out, as players die, their money is taken
by creatures, as creatures die their money is taken by players. The game
may have a pool of 100 million and so if the players have too much money
then the creatures have less. Im not sure any muds do this, I was
under the impression that creatures were given a certain amount of gold
each time they repopped. In my game each nation gets a certain amount of
money, as those creatures kill players the nation gets more money. As
the nation loses money, its members possess less and less money. Players
will be putting money back into the game via guilds store etc.
:There are two main pitfalls to watch out for in skill based systems.
:If anyone ever played the old YaMUD, this one was a perfect example.
:First of all was the jack-of-all-trades syndrome. You started with
:a race, which defined your stats and made a big difference how you
:played your character at first; namely, whether you relied on
:fighting, spells, or a combination of both. Later on, though, you
:could buy up your stats and get +stat gear until any skill was
:atainable by anyone, and with enough time and money, you could
:eventually learn every single skill and spell offered to its maximum.
Yes thats why I think its important to do the statistics I mentioned
above. How many maxed skills should a player be able to max out in
a normal lifespan? 10? How much gametime should it take to max out a
skill? 6 months? 3 months? And that is from guild training which ages
you the least. If you learned all your skills from other players you
would only be able to max out 3 skills in a normal lifetime. The mud
above didnt try to estimate these parameters and so the result was the
jack of all trades syndrome. That is precisely why I am trying to estimate
them.
Second, the guilds in my system wont take you after a certain age. They
are very jealous about guarding their secrets to keep their skills valuable.
So you might be able to learn at maybe 3 guilds. Its similar to the
real guild system where apprentices were taken on as children, but if you
were an old man no one would want you as an apprentice.
:Secondly was that they were rather unbalanced (and this is mostly a
:matter of playtesting and some forethought by the skill
:designer(s)). The hold spell was so incredibly powerful (there was
:no save and you did auto-crit hits while they were held) that there
:was very little reason to learn any other spell. Other skills or
:spells were near useless - yet all of them took roughly the same
:amount of time to advance.
Yes, so there are spells like this, but some spells that would be low level in
DND should be the most powerful spells in the game. Invis and hold are
two examples. Although there is no level system, guilds have ranks
guilds will not teach a powerful spell to a low ranking member as those
skills are their most prized possessions. Morever if some low level power
player (i.e. he has a more powerful char and is trying to improve his new
char) has the help of a powerful player he most likely wont have the stats
or the SP to use the skill. Stats and deaging will be the most valuable
commodities in the game. And stats cannot be improved any other way
except by magic.
:How to avoid this? Obviously it's going to depend on your system.
:For many (YaMUD being no exception) combat is so important that
:non-combat skills are, by default, far less useful.
Right, my non combat skills are very useful, I dont bother to put in skills
like singing, dancing etc. My game is geared towards a certain type of player
and doesnt try to be all things to all people. Its primarily hack and
slash, but combat skills are definitely balanced against other skills.
:dikus you'd rather make a dwarven thief than an elvish one, because
:dwarves get a better strength (thus do more damage). Often, dex is
:ignored for using and/or learning backstab, sneak, hide, or other
:dex-relating things, because the roll usually looks like this:
In my game strength determines the amount of damage, dex determines
how well you defend and hit. Con determines hits, int&wis determine SP
Cha determines how creatures react. Skills are based on the appropriate
stats.
:One trick that is handy is to not tell players when their skills
:advance. Arctic had one of the best skill-systems I've seen,
:particularly for being a level/exp based diku, yet I still figured
:out how skills advanced eventually because of the "you feel
:enlightened" message. I quickly figured out that the best way to
:learn up hide was to go hide in market square where people were
Well my system is pretty simple, if people want to do those types of
things thats fine by me. It can be done in real life too, but is boring.
The main defenses against that is that someone who is practicing a skill
but not gaining any gold from other activites wont be able to afford to
train (or if they have a high level char to help) will age in such a way that
his useful lifespan wont be longer than anyone else his age. Morever
if he doesnt improve his stats then his hits/combat will be lower than
a fully built char of the same skill. But with enough money yes
someone can build a full char in a few minutes. The trick is to make
it cost a lot. In my game it would cost about 500 million gold-1 billion to do
that. In a system where the richest person in the game should have about
3 billion, only a very few select people would be able to max out
a low level char.
There are many other things I didnt mention but I feel that the mechanics
are well thought out - even if you do think aging during training is hacky.
What I really want are estimates of how many uses a skill should have before
its maxed under the best circumstances. i.e. a player with a lot of money
maxing out a low level char. All other situations will take longer.
Also, how much play time should it take? 1000 hours? 100 hours? etc.
Thanks!
--
Anthony C.
Anthony C.
[People like to compare themselves]
Yeah I realize that, thats why the class system uses ranks which
are essentially levels. However the levels dont determine the skills,
the skills determine the levels. If that makes any sense :). It
makes sense to me that as your skills improve your rank increases as
you become more powerful in the guild. Each guild has its own system for
measuring power, fighters on fighting skills, sorcerors on spells etc.
A level 100 sorceror wont have the same power as a level 100 fighter,
but after players play for awhile they will get an intuitive feel for
what the level of each class means.
--
Anthony C.
Brandon Joseph Rickman
>using them in combat (important: skill improvement is also dependent on
>the skill of the target (mob, in this case), spells are improved by
>studying and casting, metal forging is improved by, you guessed it, metal
>forging, etc.
>
>The different that I would like to see from most people's ideas is that
>when a skill is neglected it gets worse. If I don't cast 'color spray'
>for 10 game days while I work on bash, then I'm going to be pretty bad at
>making pretty colors come out of my hands next time around.
One of the advantages of role-playing on a MU* is that we can do a lot of
skill calculations that would be a nuisance to do on paper. One of the
quirks of skill-based paper RPGs is that no matter what the character has
done you can only give out so much experience/potential points and the
player doesn't have to allocate the points in a reasonable way. For example,
Shoehorn the warrior just finished a session where all he did was kill an
ogre and he got 3 potential points. Rather than improve his combat skills,
Shoehorn decides the learn how to swim and improve his stunt driving skill.
Sure, you can hold off implementing the new skills until an appropriate
"leaning" situation arrives - Shoehorn falls off a boat and desperately
needs to know how to swim - but then the player is gambling that the
skills will eventually get used, meanwhile Shoehorn isn't any better
at combat and the GM has gone a little more gray.
This is old hat I imagine, but I'll toss in my hat on the skill-based MU*
discussion:
Instead of tracking one number per skill we have 2, a permanent or absolute
skill value and a temporary or relative skill value. The absolute value is
the "real" skill value and the relative value is always less than or equal to
the absolute value. All die rolls are based on the relative value as this
is the character's current ability. This allows for skill degradation - the
relative skill might tend to zero over time - but relearning a skill is
easier than learning something new.
Example: In the futuristic cyberpunk
world, Shoehorn is an expert cyberspace cowboy. In his younger days he coded
some 100,000 lines of C++ but he hasn't touched a compiler in 15 years.
The skill has gone dormant, but now he needs to write a virus and all he has
is a C compiler and some old PRIMOS manuals. His C++ skill gradually
returns.
Another example: Shoehorn is a master wizard. As an apprentice his most
practiced skill was lighting fires. Unfortunately Shoehorn was magically
lobotomized by a rival wizard and has taken a loss to his permanent fire
lighting skill. He will have to learn the skill as if it were new.
Now there should also be a distinction between studying a skill, training a
skill, and learning a skill "in the field". We can split each skill into
two different skills, theoretical and applied. Yes, we now have to keep track
of 4 numbers for every skill, but isn't that what a MU* is good for?
Theoretical skills represent book learning and analytical ability. If
Shoehorn reads a book on combat his theoretical combat skill goes up. If
he reads a Linux manual at the bookstore his theoretical Linux skill goes
up. Characters could study while their player/owners are offline.
Applied skills would generally be more physical. Shoehorn kicked some Ogre
butt, so his applied combat skill increases. Or he hacked into Steve Jackson
Games and improved his hacking skills. This is really what characters do best
while online or in the field.
The benefit of training a skill, with a(n un)qualified instructor, is that
it would improve both your theoretical and applied skills. A trainer knows
why something works and can show you the motions, though good training will
probably cost money.
Theoretical and applied skills should also work to balance one another out.
A lot of book learning will do you a lot of good, in the long run, when you
are out in the field. And conversely, a wicked swordsman could quickly
pick up new techniques of swordplay from a lecture demonstration.
So now Shoehorn has at least 3 learning tracks he can follow:
The low-risk track: Shoehorn checks out lots of library books on martial arts,
reads them at home, and practices in his living room. His theoretical
knowledge would be disproportionately higher.
The monetary-risk track: Shoehorn finds a sensei and spends a fair amount of
time and money learning how to fight. He improves his theoretical and
applied skills gradually but evenly.
The high-risk track: Shoehorn goes out looking for trouble, trying to kick
knives out of mugger's hands. Maybe Shoehorn is a natural fighter. If he
lives, Shoehorn will become very good at street fighting, but he'll never
win any refereed tournaments.
You can use a combination of the four skill values, relative/absolute
theory/application skills, to give a background to new characters. A newbie
16 year old has a few maturing skills that merely lack discipline. We could
set up a level 1 fighter with skills like these:
fighting-applied: 0 (rel) / 10 (abs) - has fought with his cohorts
fighting-theoret: 0 (rel) / 20 (abs) - read lots of adventure novels
Now when Motch the Newbie Fighter starts killing beasties his relative skills
start to pick up pretty quickly (without learning anything new). Then his
theoretical knowledge helps him increase his absolute applied skill a few
points more. Learning higher skills then become progressively more difficult.
[Note that Motch's theoretical learning curve will have a sharper
increase in difficulty because his applied knowledge isn't as high.]
---
Now we still need to govern the rate that a character can increase skills.
I think it might be interesting to try and queue up skill improvements and
slowly apply them to a character. Say we inject the skills every game hour,
so if Shoehorn learned 5 points of swordplay while killing the ogre it will
take 5 game hours for his skills to improve. You can even cycle the queue
to slow down dramatic skill improvements of really "busy" characters. In
Shoehorn's ogre battle he did the following:
- rode a horse 20 miles (2 points in horse riding)
- snuck into the ogre's cave (1 point in stealth)
- attacked and killed the ogre (5 points in sword)
Now for the next 8 game hours Shoehorn's skills will improve in this order:
1st hour: +1 horse riding (1 point back on the queue)
2nd hour: +1 stealth
3rd hour: +1 sword (4 points back on the queue)
4th hour: +1 horse riding
5th hour: +1 sword (3 points back on the queue)
...
You could apply theoretical versus applied advances consecutively or
simultaneously:
- battle as above
- Shoehorn also stole and read a cook book from the ogre's library (1 point
in cooking [theoretical])
Shoehorn's skills improve:
1st hour: +1 horse riding, +1 cooking
...
Now perhaps during the battle the ogre throws Shoehorn into a nearby lake,
and Shoehorn doesn't know how to swim! Well, he knows some basic swimming
_theory_ (people float, don't breathe water, &c), so if he doesn't drown
he quickly learns a 5 point swimming skill. Since Shoehorn needs the skill
_now_ it is applied instantly, penalizing the rate he learns all his
other new skills. You might say he has exhausted his learning potential for
the next 5 game hours, but after that his learning potential will return.
This might encourage players to spend some downtime off the MU*, allowing
skills to improve "overnight".
The penalty for a character's death would be the loss of all potential
skills of the most recent campaign.
Game hours in the above could be replaced with some interval based on a
character's innate learning ability. Stupid creatures would learn slowly,
cyborgs would learn quickly.
Comments are welcome.
- Brandon - as...@oxy.edu - http://www.oxy.edu/~ashes/
Orion Henry
>:I must admit I've never played a skill based MUD, but basing on
>:various threads about them on this group I must admit they seem to be
>:an intriguing alternative if not a real win over the old D&D
>:level/experience systems.
>
>infrastructure is built around skills then improvement through use
>can work fine.
Try not to think of it as a "hack to fix cheating", think of it
instead as building a realistic and intersting skill system. Chances
are you'll enjoy writing it more and your players will enjoy playing
it more. If we consider shifting a MUD to a totally skill-based
system, then of course you're going to have to invest more time and
code into maintaining those skills.
>Here is what I do:
>1) improvement costs money, if the player just sits and tries to improve
> then he will run out of money. If someone wants to give him money thats
> fine, but it will be very expensive. Higher skill levels require higher
> stats, sometimes training will require a quest. There is more to it than
> this but this is the basic idea. Requires that money is always an issue.
I assume by this you mean that teachers (usually misnamed
"guildmasters") will charge money for their lessons, rather than
simply draining cash out of a person's pocket. This is certainly a
good idea, although it should vary - a druid-y guy probably won't
charge money, but the thief-y dude will charge a shitload. This
will result in druids not needed money but thieves can't get enough
of it. (If you're doing a skill based system I highly recommend
yanking classes, but I still tend to refer to characters' general
skill types by class.)
>2) Age, training ages you, so eventually you die of old age. The most
> expensive and rare items in the game are deaging potions, if you just
> train yourself without doing anything then you will never be able to
> afford the expensive potions, even the highest level chars have trouble
> paying for them.
Sounds hacky to me. There are many better ways, I think.
>3) Experience for combat skills is based on difficulty of creatures fought.
Absolutely! It's completely stupid to think I'm going to get better
at bash by bashing a cat, just as it is silly to think I'll get
better at doding by trying to dodge a stone golem with a dex of 3.
In addition, there should be a skill "window" for advancing skills.
In order to advance a skill, you need to use said skill against
someone or something which is difficult, but not incredibly so, for
you. Thus a person trying to learn basic first aid is not going to
get better by trying to heal someone who has extensive internal
bleeding in the kidneys any more than the world's best swordsman is
going to become better at parrying by fighting a run-of-the-mill
swordfighter.
>4) Spells require spell components, these must be found or purchased.
Sure, although this is more like witchery than thaumaturgy.
> There are probably some other things I do but they dont come to
>mind immediately.
>What I really want to discuss is the mechanism of improvement on
>skill based only systems, ignoring reptition and cheating and focusing
>on the normal mechanism for advancement.
You're looking at this the wrong way. Don't think of it is a way to
"get around" cheating - think of it as trying to design a realistic
and interesting system. I don't really become a better fistfighter
by standing and punching the wall all day long, not to mention there
are other complications involved (hunger, thirst, fatigue, sore
fists).
A well designed system will make it so that someone who just goes
out and uses their skills normally will advance, someone who has the
guts and/or ingenuity to use them in new and different ways will
advance faster, and the guy who does "#20 sneak" will advance little
or not at all.
>What kind of algorithms should be used for improvement? I personally
>like to take a mathematical approach to looking at improvements.
>Like it should take at the fastest, X gold, Y number of uses, Z number
>of game years, and W number of player hours assuming a maximum experience
>gain of V experience/hour (or U creatures/hour) to reach maximum proficiency .
>Did that make sense? Essentially I want a mathematical description of
>the predicted improvement, players could do worse than this but this would
>provide the fastest rate of improvement in game years and in player hours.
I suppose this would be all right, but it sounds kind of arbitrary.
How do you really decide upon these values realistically?
>Combat Skills (used often so should require more uses 10,000 to max out?)
> experience is given by the relative strength of the creature or player
> opponent. But what sort of skill improvement rate would be good?
> I just want to know approximately how many uses should it take to
> max out the skill, I could probably make the algorithm fit this.
> Should it only take 1000 uses?
You're still looking from the wrong angle. I can punch the wall
1000 times, but I'll probably learn more about fist-fighting by
going down to my local tavern and getting in a fight or two.
Even if I only throw sixteen punches, I've already gained more
knowledge and experience.
>Skills used less often, teleport, identify, swim.
> How many times should they be used to reach a reasonable proficiency?
How do you determine what's used less often? A fighter uses his
weapon skills constantly, and a druid not at all. A thief uses
sneak and hide constatly, but spells not at all. And this is just
generalizing - there's one thief who's got a lot of fighter skills
but a few underhanded kind of things, like maybe sneak, or another
who knows nothing about fighting but can pick locks and pockets like
a champ.
>So the things I like to consider are, in the normal lifespan of a human
>(50 years) what is the absolute maximum number of total skill
>levels a player could have? (training takes time) How much gold should
>this take? (my economy is closed and fixed) and how many uses should
>it take to reach a max level?
Of course training takes time - this is why I can never be both the
best computer programmer in the world and the best basketball player
simutaneously. But there's no reason I can't be damn good at both -
I just have to divide my time between coding and playing basketball.
And of course, if ALL I do is eat, sleep, code, and shoot hoops, I'm
gonna be both a damn good coder and a damn good basketball player.
But I won't have much time for anything else.
Also, why is your economy closed and fixed? I doubt such a thing
has ever existed, except in fantasy worlds, and even there it's not
terribly interesting. And despite code attempts to the contrary,
I've yet to see a MUD where money doesn't start to devaule
(inflation) over time.
There are two main pitfalls to watch out for in skill based systems.
If anyone ever played the old YaMUD, this one was a perfect example.
First of all was the jack-of-all-trades syndrome. You started with
a race, which defined your stats and made a big difference how you
played your character at first; namely, whether you relied on
fighting, spells, or a combination of both. Later on, though, you
could buy up your stats and get +stat gear until any skill was
atainable by anyone, and with enough time and money, you could
eventually learn every single skill and spell offered to its maximum.
Secondly was that they were rather unbalanced (and this is mostly a
matter of playtesting and some forethought by the skill
designer(s)). The hold spell was so incredibly powerful (there was
no save and you did auto-crit hits while they were held) that there
was very little reason to learn any other spell. Other skills or
spells were near useless - yet all of them took roughly the same
amount of time to advance.
How to avoid this? Obviously it's going to depend on your system.
For many (YaMUD being no exception) combat is so important that
non-combat skills are, by default, far less useful.
One thing is to keep in mind that you may want to store more than
just a number 0 through 100 for the skill level. In my system we
use 16 bits for each skill on each character, and only 7 of those
bits are used for the skill "level".
Another thing is to simply make it so that you _can't_ do stuff like
"#20 sneak". Many use lag to avoid this, but this is a sloppy
method IMO. You shouldn't advance sneaking when you attempt to
sneak, you should advance when you are actually moving around, past
other people, while attempting to sneak.
Difficulty is of course necessary, as mentioned above. A good
pick-pocket isn't going to learn much by stealing from a paralyzed
dragon. Does it mater that the dragon is a level 60 mob? Of course
not - he's paralyzed, so he can't do anything about it any way it
goes. You can just walk up and take it. If said dragon were asleep
you might learn something, since you would have to avoid waking him.
If he were awake and fully alert, than you should learn quite a bit
from trying to steal from him, whether you make it or not.
Some other things to keep track of are how long it's been since you
used the skill; this is handy if you want to let skills decay after
a long peroid of non-use. You can also keep track of how long it's
been since they gained in the skill, so that you get a steady
progession in a skill, and learn more by just using the skill every
so often rather than using it over and over and over again.
Skill difficulties are handy, since you can make something like
bludgeoning weapons easier to learn than slashing weapons. Thus the
stupid troll who has trouble learning much of anything is going to
go for the easiest weapon he can learn.
Having stats make a large difference in skills (both learning and
using) is also handy. One thing that annoys me is that on most
dikus you'd rather make a dwarven thief than an elvish one, because
dwarves get a better strength (thus do more damage). Often, dex is
ignored for using and/or learning backstab, sneak, hide, or other
dex-relating things, because the roll usually looks like this:
if (number(0, 101) > GET_SKILL(ch, SKILL_BACKSTAB)
Not only does this ignore stats, it ignores the target's ability to
dodge the blow. At the very least it should look something like
this:
if (number(0, GET_SKILL(ch, SKILL_BACKSTAB)) + GET_DEX(ch) >
number(0, GET_SKILL(vict, SKILL_AWARENESS)) + GET_INT(vict))
You can do a lot more than that, of course - like letting them see
it coming but not make the dex roll to get out of the way, or
jumping out of the way thanks to their racial insticts rather than
any skill, or whatever. You could even make it so that a good
backstabber will start his backstab, then _notice_ the other person
noticing him, so retreat back into the shadows and wait for a better
oportunity.
One trick that is handy is to not tell players when their skills
advance. Arctic had one of the best skill-systems I've seen,
particularly for being a level/exp based diku, yet I still figured
out how skills advanced eventually because of the "you feel
enlightened" message. I quickly figured out that the best way to
learn up hide was to go hide in market square where people were
going in and out until I got the you feel enlightened message, then
run over to my guild and learn the skill up. Or with steal, to go
try to steal from the highest-level sentinal mob I could find. Or
with track, go into the desert and do "#loop 1,100 track %0.goblin".
And so on.
There's more of course, but none of this is really anything
spectacularly inovative, when you really thing about it.
All it takes is the right mindset and some well-thought-out design.
Travis S Casey
Marco Braga <bra...@mbox.vol.it> wrote:
>ca...@mu.cs.fsu.edu (Travis S Casey) wrote:
>
>> b) It's possible to divorce advancement checks from skill
>> checks. Thus, advancement might only be allowed under
>> certain circumstances. For instance, combat skills might
>> only advance when you are fighting a monster. This can
>> be useful for muds which allow players to stop attacking
>> each other.
>
>checked only when a fight ends with a flee or a victory. It is a bit
>more problematic with "one shoot" skills, such as "find water" or
>similar. While in the example you made "hide" can be transformed from
>"one shoot" to "continuous", there are a lot of skills where success
>or failure is immediate. These are subject to the "repeat" cheat, i.e.
>the player continues to repeat the skill just to learn more. I can try
>to solve this by saving the time of last use of the skill, and then
>check if the "delay" among uses is above a minimum value, but what
>delay will be reasonable?
Well, there are other things that can be done... for example,
it's possible to implement things so that skills can take
time to perform, and if the character does something else or
is attacked during that time, the skill use is abandoned.
For example, on most muds, picking a lock is an instant use
of a skill. In a realistic environment, though, it should
take some time spent fiddling with the lock, during which the
character can't do anything else (or is very limited in his/her
actions.) This doesn't necessarily have to be a very long
time... even 15 seconds or so would be a vast improvement.
Of course, this would have to be set up very carefully, and
there's a lot to consider, but I think the basic idea is
workable.
This not only limits how often the skill can be used, but
also can introduce an element of risk; for example, if a
castle has wandering guards, one of them might come along
while you're trying to pick the lock.
Another possibility that's just occured to me is to keep
track of things that the character has used the skill on,
and not allow skills to go up again for using them on the
same thing. For instance, how much can a thief really
learn by picking the same lock over and over? Of course,
this should be limited in which skills it's used for, and
it probably isn't practical to keep track of *everything*
the skill has ever been used on. However, keeping track of
the last two or three things that a limited selection of
skills that this applies to have been used on might be
workable, and would prevent a thief from learning by
picking the same lock over and over.
>>4. Skill forgetting. In real life, if you don't do something
>> for a long time, you tend to forget how to do it. In the
>> same way, skills that a character doesn't use often can
>> decay with time.
>
>This should keep players from becoming masters in "each" skill, and
>also seems to be a good idea.
Many people have already mentioned this, but I'll throw it in
anyways... it's probably also a good idea to make relearning
a skill you once knew be easier than learning it for the
first time.
>I think that some statisitic values should be useful to trim a system:
>how many times per hour is each skill used by each class/race in an
>average play session? This seems a rather difficult question to
>answer, but it is very important to set values for the system.
>A wrong predicion, and all players will become master in 1 hour of
>play, instead of the months you calculated...
This is an important step, and one that many muds seem to leave
out--playtesting. Ideally, a skill-based mud would spend several
months playtesting. This could be done by having the mud be "open",
but having the opening message state that the mud is being tested,
and that when the playtest period is over, all characters will
be wiped. Some people may not want to play under those conditions,
but a fair number will be willing to... at least, if your mud is
interesting/fun enough. :-)
Travis S Casey
>One of the advantages of role-playing on a MU* is that we can do a lot of
>skill calculations that would be a nuisance to do on paper. One of the
>quirks of skill-based paper RPGs is that no matter what the character has
>done you can only give out so much experience/potential points and the
>player doesn't have to allocate the points in a reasonable way. For example,
>Shoehorn the warrior just finished a session where all he did was kill an
>ogre and he got 3 potential points. Rather than improve his combat skills,
>Shoehorn decides the learn how to swim and improve his stunt driving skill.
>Sure, you can hold off implementing the new skills until an appropriate
>"leaning" situation arrives - Shoehorn falls off a boat and desperately
>needs to know how to swim - but then the player is gambling that the
>skills will eventually get used, meanwhile Shoehorn isn't any better
>at combat and the GM has gone a little more gray.
This isn't true of all paper RPGs; most allow this, but some do not.
RuneQuest, for example, uses a system in which skills can only be
advanced in two ways: by using them or by training in them. There are
some systems in which the GM, not the players, decides which skills
improve.
>This is old hat I imagine, but I'll toss in my hat on the skill-based MU*
>discussion:
>
>Instead of tracking one number per skill we have 2, a permanent or absolute
>skill value and a temporary or relative skill value. The absolute value is
>the "real" skill value and the relative value is always less than or equal to
>the absolute value. All die rolls are based on the relative value as this
>is the character's current ability. This allows for skill degradation - the
>relative skill might tend to zero over time - but relearning a skill is
>easier than learning something new.
In other, possibly less confusing terms, we keep track of both the
character's current skill level and his/her greatest achieved skill
level.
The current skill level can go down from lack of use; the greatest
achieved level can only be lowered by brain damage, magic, and other
extraordinary circumstances.
>Now there should also be a distinction between studying a skill, training a
>skill, and learning a skill "in the field". We can split each skill into
>two different skills, theoretical and applied. Yes, we now have to keep track
>of 4 numbers for every skill, but isn't that what a MU* is good for?
>
>Theoretical skills represent book learning and analytical ability. If
>Shoehorn reads a book on combat his theoretical combat skill goes up. If
>he reads a Linux manual at the bookstore his theoretical Linux skill goes
>up. Characters could study while their player/owners are offline.
>
>Applied skills would generally be more physical. Shoehorn kicked some Ogre
>butt, so his applied combat skill increases. Or he hacked into Steve Jackson
>Games and improved his hacking skills. This is really what characters do best
>while online or in the field.
Some skills, however, don't have an applied side; what is "applied
history", for example? On the reverse side, what is "theoretical
engineering?"
(I'm sure a bunch of people are going to reply to that if I don't
say something here... feel free to skip this part if you're not one
of those people. :-)
"Applied history" is something else, depending on what you apply it
to. If you apply it to predicting the actions of a society, it's
sociology (or politics). If you apply it by digging up artifacts
and cataloging them, it's archaeology. Any application of history
that I can think of comes under another field in such a manner.
The same is true of "theoretical engineering." Engineers study
physics, chemistry, materials science, economics, mathematics,
and other disciplines which form the theoretical basis of what
they do.)
A better way of organizing things might be to have lots of skills,
which can affect each other. For example, "fencing" could be
subdivided into "epee combat", "saber combat", "foil combat",
"etiquette of fencing", "history of fencing", "personal combat
tactics", and a myriad of other skills. Of course, this introduces
a ton of skills and relationships to keep track of, but the computer
can do that.
>The benefit of training a skill, with a(n un)qualified instructor, is that
>it would improve both your theoretical and applied skills. A trainer knows
>why something works and can show you the motions, though good training will
>probably cost money.
In this setup, trainers would teach multiple skills to their clients.
A qualified fencing teacher, for example, will teach you some of each of
the skills mentioned above. Learning from a swordsman who doesn't
fence formally, though, you wouldn't learn the etiquette or history
of fencing.
>The high-risk track: Shoehorn goes out looking for trouble, trying to kick
>knives out of mugger's hands. Maybe Shoehorn is a natural fighter. If he
>lives, Shoehorn will become very good at street fighting, but he'll never
>win any refereed tournaments.
Or, to put it another way, he's a very good martial arts fighter,
but he doesn't know have any skill in "martial arts: tournament
rules" and "martial arts etiquette".
A question, though... how is all this going to come into play? To
make it be really needed, the mud's builders will have to provide
opportunities to learn skills in all three ways. Not only that,
but there should be opportunities for such skills as "theoretical
swordsmanship" to come into play in some other way than through
their influence on applied skills, or else there will be no benefit
to differentiating these skills.
In other words, it's a good, realistic idea... but that doesn't
necessarily mean it's something that should be done. :-)
>Now we still need to govern the rate that a character can increase skills.
>I think it might be interesting to try and queue up skill improvements and
>slowly apply them to a character. Say we inject the skills every game hour,
>so if Shoehorn learned 5 points of swordplay while killing the ogre it will
>take 5 game hours for his skills to improve. You can even cycle the queue
>to slow down dramatic skill improvements of really "busy" characters. In
>Shoehorn's ogre battle he did the following:
>
>- rode a horse 20 miles (2 points in horse riding)
>- snuck into the ogre's cave (1 point in stealth)
>- attacked and killed the ogre (5 points in sword)
>
>Now for the next 8 game hours Shoehorn's skills will improve in this order:
>1st hour: +1 horse riding (1 point back on the queue)
>2nd hour: +1 stealth
>3rd hour: +1 sword (4 points back on the queue)
>4th hour: +1 horse riding
>5th hour: +1 sword (3 points back on the queue)
This leads to a potential problem... let's say that I play for 5 hours,
and earn 30 points in skill improvements during that time. 18 hours
later I log on, play some more, and earn 20 points in skill improvements.
If this sort of cycle continues, then I'm always going to have a
"backlog" of learning for my character. This might cause people to
take longer breaks, yes... but it could also result in a huge backlog
of skill advances, such that when someone takes, say, a three week
vacation, they come back to a vastly improved character.
Second: Is this realistic? How long does someone need to "mull over"
what they've done in order for enhancements in technique to sink in?
How does this relate to the time scale of the mud?
Third: Is it necessary? The same general effect can be achieved
by limiting the rate at which skills can be learned, without
the delay factor; the only thing lost is the incentive for people
to log out. Is the increased complication worth the benefit?
(Of course, different people will have different answers to these
questions. :-)
>You could apply theoretical versus applied advances consecutively or
>simultaneously:
>
>- battle as above
>- Shoehorn also stole and read a cook book from the ogre's library (1 point
>in cooking [theoretical])
>
>Shoehorn's skills improve:
>1st hour: +1 horse riding, +1 cooking
>...
>
>Now perhaps during the battle the ogre throws Shoehorn into a nearby lake,
>and Shoehorn doesn't know how to swim! Well, he knows some basic swimming
>_theory_ (people float, don't breathe water, &c), so if he doesn't drown
>he quickly learns a 5 point swimming skill. Since Shoehorn needs the skill
>_now_ it is applied instantly, penalizing the rate he learns all his
>other new skills. You might say he has exhausted his learning potential for
>the next 5 game hours, but after that his learning potential will return.
A question; if skills that are needed immediately are applied immediately,
what happens if Shoehorn fights an Ogre, gains 3 points of sword skill
improvement, then goes and fights something else five minutes later?
Surely he needs his improvement now... it might save his life!
Marco Braga
On 15 Jul 1996 14:59:19 GMT, ca...@mu.cs.fsu.edu (Travis S Casey)
wrote:
>Here are a few more possible solutions:
>
>1. Redefine what "use" means. For example, if a thief hides in
> a room when there's no one around who can see him anyways,
> should it count?
Yes, that's a good point. It's obvious that not every use is a "good"
one, also difficulty of the feat must be considered, so too easy or
too hard uses won't teach anything.
> b) It's possible to divorce advancement checks from skill
> checks. Thus, advancement might only be allowed under
> certain circumstances. For instance, combat skills might
> only advance when you are fighting a monster. This can
> be useful for muds which allow players to stop attacking
> each other.
This is right too, for example you can state that advancement is
checked only when a fight ends with a flee or a victory. It is a bit
more problematic with "one shoot" skills, such as "find water" or
similar. While in the example you made "hide" can be transformed from
"one shoot" to "continuous", there are a lot of skills where success
or failure is immediate. These are subject to the "repeat" cheat, i.e.
the player continues to repeat the skill just to learn more. I can try
to solve this by saving the time of last use of the skill, and then
check if the "delay" among uses is above a minimum value, but what
delay will be reasonable?
>4. Skill forgetting. In real life, if you don't do something
> for a long time, you tend to forget how to do it. In the
> same way, skills that a character doesn't use often can
> decay with time.
This should keep players from becoming masters in "each" skill, and
also seems to be a good idea.
>7. Have the difficulty of going up in a skill be a function
> of how good you are at it; that is, an expert is less
> likely to learn something that he doesn't already know
> than a novice.
I think this is a basic and a must for a skill system, there are a lot
of smart ways to do this.
I think that some statisitic values should be useful to trim a system:
how many times per hour is each skill used by each class/race in an
average play session? This seems a rather difficult question to
answer, but it is very important to set values for the system.
A wrong predicion, and all players will become master in 1 hour of
play, instead of the months you calculated...
Marco
Marco Braga
On 15 Jul 1996 23:13:06 +0200, gry...@IAEhv.nl wrote:
>Make a failed hide actually -loose- you some proficiency in the skill.
>Or, as the player repeats the same skill over and over again, increase
>the change to forget rather than learn from the skill slowly.
Sadly this will not be realistic. Why should someone forget a thing
just by repeating it over and overe. There must be another way...
A better way seems to be setting a minimum delay among uses of a skill
before they can be considered for a learn effort. This brings us to a
question: how long this delay should be?
Marco
-========================================================-
Marco Braga (Tempus) - implementor at *The Gate MUD*
telnet mondeo.vol.it 4000 - WWW http://mondeo.vol.it
email: .......................... bra...@mbox.vol.it
-========================================================-
Orion Henry
>This isn't true of all paper RPGs; most allow this, but some do not.
>RuneQuest, for example, uses a system in which skills can only be
>advanced in two ways: by using them or by training in them. There are
>some systems in which the GM, not the players, decides which skills
>improve.
One of my favorites. Simple, easy to keep track of, and fun. The
only thing lacking was the fact that skills didn't get any "harder"
to learn as that got better, it was just d4 every skill check if you
had used that skill.
>>Theoretical skills represent book learning and analytical ability. If
>>Shoehorn reads a book on combat his theoretical combat skill goes up. If
>>he reads a Linux manual at the bookstore his theoretical Linux skill goes
>>up. Characters could study while their player/owners are offline.
>>Applied skills would generally be more physical. Shoehorn kicked some Ogre
>>butt, so his applied combat skill increases. Or he hacked into Steve Jackson
>>Games and improved his hacking skills. This is really what characters do best
>>while online or in the field.
>
>Some skills, however, don't have an applied side; what is "applied
>history", for example? On the reverse side, what is "theoretical
>engineering?"
>"Applied history" is something else, depending on what you apply it
>to. If you apply it to predicting the actions of a society, it's
>sociology (or politics). If you apply it by digging up artifacts
>and cataloging them, it's archaeology. Any application of history
>that I can think of comes under another field in such a manner.
>The same is true of "theoretical engineering." Engineers study
>physics, chemistry, materials science, economics, mathematics,
>and other disciplines which form the theoretical basis of what
>they do.)
Neither are really skills. A skill is definted by Webster's as "the
ability to use one's knowledge effectively and readily in execution
or performance." I'm not sure how you perform applied history.
This sort of thing would fall into a knowledge sort of category,
which is different from skills IMO.
Now, for something like engineering (rather broad, don't you think?)
you're going to have a skill named something like physics. Your
ability in physics will reflect time spent in the lab; your
knowledge of working with this stuff hands-on. The "theoretical"
part of it would be the other skill value, which is of use to you
only for taking your Physics 2B midterm. Now, a high theoretical
value would be useful even if you were thrown into a real
experiement situation, because after only a few mistakes you'd
quickly figure things out (in terms of skill values, your applied
would go up by leaps and bounds), versus the guy who doesn't know
anything about physics and could bumble around for days before he
figures out the right combination.
These are kind of bad examples, I think, because I doubt anyone has
plans to implement history or physics as skills on a MUD. :)
A better, yet similar, skill would be language skills. If my
theoretical knowledge of spoken french was very high (say, I listen
to language tapes in my car every day) but I had never actually
attempted to use the language, I would find a trip to France rather
trying. First of all, understanding them - people in real life talk
quite differently than any language tape. Secondly, in speaking the
language myself - I "know" the correct accent, language
contrstructs, and whatever else, but never having tried it I'm very
poor at actually shaping my mouth into the right shapes or thinking
in the proper grammatical structure. This is versus the high
applied person, who grew up on the streets of France and never saw a
language textbook or learned a simgle gramatical rule, but can speak
and understand it without difficulty. Now, an educated frenchman
might notice their lack of schooling, but they would still
understand whatever they were trying to convey.
>A better way of organizing things might be to have lots of skills,
>which can affect each other. For example, "fencing" could be
>subdivided into "epee combat", "saber combat", "foil combat",
>"etiquette of fencing", "history of fencing", "personal combat
>tactics", and a myriad of other skills. Of course, this introduces
>a ton of skills and relationships to keep track of, but the computer
>can do that.
I wouldn't really divide it that way, but yeah that's the idea. The
last two (etiquette and history) wouldn't really fall into the
category of skills. For the purposes of a MUD I don't see them as
being highly useful - part of the problem is that knowledge is
something largely controled by the player, so if I know fencing
etiquette I can remember to cross swords before begining or whatever
else regardless of my character. There are a few places where
there might be exceptions to this, certainly - I found it useful to
implement herbalism as a knowledge base (knowing that a maple tree
is a member of the Aceracae family) and things like preparing
tinctures, salves, teas, and other herbal-y abilties as skills.
>In this setup, trainers would teach multiple skills to their clients.
>A qualified fencing teacher, for example, will teach you some of each of
>the skills mentioned above. Learning from a swordsman who doesn't
>fence formally, though, you wouldn't learn the etiquette or history
>of fencing.
Without a doubt. That's what makes a skill system cool, versus a
class system - no two characters are completely alike, even two that
know many of the same skills. So you can learn from the
swashbuckler guy who likes to dual wield for the purposes of
parrying, or the one across the way who considers two weapons
overkill and only teaches single-wielded swordsmanship.
>A question, though... how is all this going to come into play? To
>make it be really needed, the mud's builders will have to provide
>opportunities to learn skills in all three ways. Not only that,
>but there should be opportunities for such skills as "theoretical
>swordsmanship" to come into play in some other way than through
>their influence on applied skills, or else there will be no benefit
>to differentiating these skills.
Theoretical is more important for learning that skill "for real."
Thus I will learn much faster if I go train for a while with the
swordsmaster in my town, THEN go spar with my buddies. Versus just
running out the town gates and attacking rabbits in a manical rage.
Your applied skill can still go up, of course, but it will be far
slower.
>In other words, it's a good, realistic idea... but that doesn't
>necessarily mean it's something that should be done. :-)
Nautrally. Of course, I don't really think of things without them
automatically being something that "should" be done. That is to
say, I think "What can I do to make the system realistic and rich"
versus "How can I fit this feature into the system in a realistic
way?"
In this respect, I found the applied/theoretical thing incredibly
useful. I originally came up with it fairly early on in the project
as a way to get rid of the standard diku practices.
[other stuff I agree with deleted]
Orion Henry
>One of the advantages of role-playing on a MU* is that we can do a lot of
>skill calculations that would be a nuisance to do on paper. One of the
Absolutely! That's one of the reasons I so favor ditching just
about everything from pen and paper RPGs and rethinking from
scratch, keeping in mind the limitations and special abilities
afforded to us by having the computer as a DM.
>quirks of skill-based paper RPGs is that no matter what the character has
>done you can only give out so much experience/potential points and the
>player doesn't have to allocate the points in a reasonable way. For example,
>Shoehorn the warrior just finished a session where all he did was kill an
>ogre and he got 3 potential points. Rather than improve his combat skills,
>Shoehorn decides the learn how to swim and improve his stunt driving skill.
>Sure, you can hold off implementing the new skills until an appropriate
>"leaning" situation arrives - Shoehorn falls off a boat and desperately
>needs to know how to swim - but then the player is gambling that the
>skills will eventually get used, meanwhile Shoehorn isn't any better
>at combat and the GM has gone a little more gray.
Part of this is because most pen and paper RPGs don't spend much
time with mundane stuff. You rarely say, "okay, I'm gonna go
practice swimming for the next two weeks" because there are other
players there and you're just going to be sitting there while they
do two weeks' worth of fun stuff. On a MUD, you do indeed go
practice these things, although certainly not to the extent that you
would in real life. Also, I would imagine most characters would
start out as pretty good swimmers; if you felt like increasing it to
the point where you can swim up a waterfall, feel free. (This is
also a nice way to balance out skill-rich races like dwarves: they
may start with more combat skills than everyone else, but toss them
into a lake and they're finished.)
[lots of good stuff bobbited]
>Applied skills would generally be more physical. Shoehorn kicked some Ogre
>butt, so his applied combat skill increases. Or he hacked into Steve Jackson
>Games and improved his hacking skills. This is really what characters do best
>while online or in the field.
This is true to a certain extent, but almost every skill is really
going to benefit far more from practical field knowledge than just
studying in a book. You can study herbalism and botany for a long
time, reading tons of books and such, but it's never going to be
able to compare to actually standing in a forest picking out the
various flora and fauna by touch, smell, taste, sight, etc.
Even something like casting spells (which is difficult to make a
call on, of course, since there is no real-life counterpart) should
be more beneficial than just reading about magic.
>The benefit of training a skill, with a(n un)qualified instructor, is that
>it would improve both your theoretical and applied skills. A trainer knows
>why something works and can show you the motions, though good training will
>probably cost money.
Absolutely. On thing that bugs me is that normally you have to go
out and "risk your life" against rabbits and such in order to gain
levels, and thereby have your skills increase. Any semi-intelligent
fighter is going to spend a while swinging at practice dummies,
sparring with sticks with their peers, etc, before actually testing
their skills in a life or death situation.
>Theoretical and applied skills should also work to balance one another out.
>A lot of book learning will do you a lot of good, in the long run, when you
>are out in the field. And conversely, a wicked swordsman could quickly
>pick up new techniques of swordplay from a lecture demonstration.
I would tend to consider the applied skill value far more important
for the reasons outlined above, and in addition I think it would be
easier to reach high levels in the skill by exclusively applied
knowledge versus book study. On the other hand, both together will
be better than either seperately. I would also tend to think that
the book is most useful for getting started; I read a lot of books
when I was getting started programming, but once I was decently
proficient I found that experiementing on my own was really the only
way to get any better.
>The low-risk track: Shoehorn checks out lots of library books on martial arts,
>reads them at home, and practices in his living room. His theoretical
>knowledge would be disproportionately higher.
The result being that he'd be a great commentator for sparring
matches ("Hey, that was impressive low sweep, coming in just under
Billy the Minotaur's guard!") but wouldn't be much of a real
fighter himself.
>The monetary-risk track: Shoehorn finds a sensei and spends a fair amount of
>time and money learning how to fight. He improves his theoretical and
>applied skills gradually but evenly.
This is a good method, certainly. He'll probably be best at winning
sparring matches with rules; once out in a "real" fight he may face
things he's not expecting, or possibly loose his nerve.
>The high-risk track: Shoehorn goes out looking for trouble, trying to kick
>knives out of mugger's hands. Maybe Shoehorn is a natural fighter. If he
>lives, Shoehorn will become very good at street fighting, but he'll never
>win any refereed tournaments.
More like, he'll never win because he'll always be breaking the
rules. If someone can live long enough to do this track, then they
should be far better of a fighter than either of the previous two.
>You can use a combination of the four skill values, relative/absolute
>theory/application skills, to give a background to new characters. A newbie
>16 year old has a few maturing skills that merely lack discipline. We could
I don't know that four values are really necessary, though you could
certainly do it this way. Also, the detail on this might depend on
the number of skills you have. If there are just general "melee
combat" and "botany" skills, then you probably want to go into a
fair amount of detail with the skill levels. If you have it divided
up into "kung fu", "tae kwon do", "karate", etc...then you may not
need as much detail. Namely is that I don't think you need relative
and absolute; just make only the applied skill decay. Of course
this also depends on how important decay is. If your system
emphasizes this a lot, then all four might be good. I tend to
consider decay just a little something to keep character in check; I
don't want to discourage people from hanging around doing nothing
just because they'll feel like they are wasting time they could be
maintaining their skills.
>Now we still need to govern the rate that a character can increase skills.
>I think it might be interesting to try and queue up skill improvements and
>slowly apply them to a character. Say we inject the skills every game hour,
[bunch of stuff snipped]
That's not a bad method, though it seems a bit convulted to me.
You'd defeinitely have to be very careful with this - it would suck
if a really busy character was playing for 20 hours straight and had
so many skills queued up that it takes five hours from the time he
starts practicing a skill to see any kind of improvement in that
skill. On the other hand, it might encourage people not to run
non-stop and to instead stop and chat at the local tavern, which
would certainly be a good benefit.
>Now perhaps during the battle the ogre throws Shoehorn into a nearby lake,
>and Shoehorn doesn't know how to swim! Well, he knows some basic swimming
>_theory_ (people float, don't breathe water, &c), so if he doesn't drown
>he quickly learns a 5 point swimming skill. Since Shoehorn needs the skill
>_now_ it is applied instantly, penalizing the rate he learns all his
>other new skills. You might say he has exhausted his learning potential for
>the next 5 game hours, but after that his learning potential will return.
Again this seems like a lot of trouble. I'm far more in favor of
adding to all skills as soon as you "learn" them, but keeping some
sort of check on how fast you can learn (based on your character's
int and possibly wis, making smart warriors popular).
>This might encourage players to spend some downtime off the MU*, allowing
>skills to improve "overnight".
I'm not sure whether this good or bad, but it would certainly be
different (which always scores points in my book).
>The penalty for a character's death would be the loss of all potential
>skills of the most recent campaign.
Heh...how the hell do you plan to keep track of "campagins"?
>Game hours in the above could be replaced with some interval based on a
>character's innate learning ability. Stupid creatures would learn slowly,
>cyborgs would learn quickly.
This is absoultely necessary, I feel. Making mind stats important
for everyone makes those troll warriors a little less appealing. In
addition, people should have talents for various skills that will
help shape their character. Whether you want to do this just as
random rolls or base it on their stats/race/upbringing is up to you.
But this gives a bit more character depth; this way you not only
give some directions to new characters (instead of, "gee, work on my
necromancy skills or my skills as an auto-mechanic?"), but helps
buffer against the jack-of-all-trades problem, since people will
only be able to become masters in certain areas, whereas others they
will only ever get so good.
Travis S Casey
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>>This isn't true of all paper RPGs; most allow this, but some do not.
>>RuneQuest, for example, uses a system in which skills can only be
>>advanced in two ways: by using them or by training in them. There are
>>some systems in which the GM, not the players, decides which skills
>>improve.
>
>One of my favorites. Simple, easy to keep track of, and fun. The
>only thing lacking was the fact that skills didn't get any "harder"
>to learn as that got better, it was just d4 every skill check if you
>had used that skill.
Hmm... it's been a long time since I played RuneQuest, but I have
a copy of Chaosium's ElfQuest, which used the same basic system,
at home. In it, the players are required to make a roll on each
checked skill to see if it can increase. That roll has to be over
their current skill level, so that higher-skill characters are less
likely to improve.
>>Some skills, however, don't have an applied side; what is "applied
>>history", for example? On the reverse side, what is "theoretical
>>engineering?"
>>
>>"Applied history" is something else, depending on what you apply it
>>to. If you apply it to predicting the actions of a society, it's
>>sociology (or politics). If you apply it by digging up artifacts
>>and cataloging them, it's archaeology. Any application of history
>>that I can think of comes under another field in such a manner.
>>The same is true of "theoretical engineering." Engineers study
>>physics, chemistry, materials science, economics, mathematics,
>>and other disciplines which form the theoretical basis of what
>>they do.)
>
>Neither are really skills. A skill is definted by Webster's as "the
>ability to use one's knowledge effectively and readily in execution
>or performance." I'm not sure how you perform applied history.
>This sort of thing would fall into a knowledge sort of category,
>which is different from skills IMO.
Webster's also defines a skill as "a learned power of doing something
competently." It doesn't specify that that has to be something
physical; it could include remembering facts or making inferences.
Thus, "knowledge skills" are valid... whether they're useful on
a mud is another question, of course. :-)
>A better, yet similar, skill would be language skills. If my
>theoretical knowledge of spoken french was very high (say, I listen
>to language tapes in my car every day) but I had never actually
>attempted to use the language, I would find a trip to France rather
>trying. First of all, understanding them - people in real life talk
>quite differently than any language tape. Secondly, in speaking the
>language myself - I "know" the correct accent, language
>contrstructs, and whatever else, but never having tried it I'm very
>poor at actually shaping my mouth into the right shapes or thinking
>in the proper grammatical structure. This is versus the high
>applied person, who grew up on the streets of France and never saw a
>language textbook or learned a simgle gramatical rule, but can speak
>and understand it without difficulty. Now, an educated frenchman
>might notice their lack of schooling, but they would still
>understand whatever they were trying to convey.
This, however, can be easily handled by breaking "French" up into
two subskills: read/write French and speak/understand French.
Someone who learned French from books would have a better skill
in reading and writing French, and a worse skill in speaking it.
This sort of skill division becomes even more useful when dealing
with non-alphabetic languages, such as Chinese. Mandarin and
Cantonese are very different spoken languages, but are both
written the same way. For that matter, Chinese characters are
often used in writing Japanese. (To make things extra fun,
Japanese also has at least two other forms of writing).
>Without a doubt. That's what makes a skill system cool, versus a
>class system - no two characters are completely alike, even two that
>know many of the same skills. So you can learn from the
>swashbuckler guy who likes to dual wield for the purposes of
>parrying, or the one across the way who considers two weapons
>overkill and only teaches single-wielded swordsmanship.
Yep. :-)
>>A question, though... how is all this going to come into play? To
>>make it be really needed, the mud's builders will have to provide
>>opportunities to learn skills in all three ways. Not only that,
>>but there should be opportunities for such skills as "theoretical
>>swordsmanship" to come into play in some other way than through
>>their influence on applied skills, or else there will be no benefit
>>to differentiating these skills.
>
>Theoretical is more important for learning that skill "for real."
>Thus I will learn much faster if I go train for a while with the
>swordsmaster in my town, THEN go spar with my buddies. Versus just
>running out the town gates and attacking rabbits in a manical rage.
>Your applied skill can still go up, of course, but it will be far
>slower.
To me, though, it seems somewhat redundant to keep two separate
skill values for this... I'd simply allow "theoretical" learning
to increase the skill, but more slowly and with a limit to how
much can be learned that way. Granted, you don't get the full
effect that way, but you get most of the good points, with less
complication and less storage needed.
Anthony C.
In article <4skid1$8...@sdcc12.ucsd.edu>,
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
:>One of the advantages of role-playing on a MU* is that we can do a lot of
:>skill calculations that would be a nuisance to do on paper. One of the
:
:Absolutely! That's one of the reasons I so favor ditching just
:about everything from pen and paper RPGs and rethinking from
:scratch, keeping in mind the limitations and special abilities
:afforded to us by having the computer as a DM.
Yeah you should see some of my algorithms- logs, exponents and summations
would be impossible to do with a pen and paper rpg but are actually
easier to implement on a computer than a table of values with ranges
like an pen and paper rpg.
--
Anthony C.
Brandon Joseph Rickman
I have to reply to a followup to a followup because the followup hasn't gotten
to my server yet...
In article <4skkme$8...@sdcc12.ucsd.edu>,
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>>A better way of organizing things might be to have lots of skills,
>>which can affect each other. For example, "fencing" could be
>>subdivided into "epee combat", "saber combat", "foil combat",
>>"etiquette of fencing", "history of fencing", "personal combat
>>tactics", and a myriad of other skills. Of course, this introduces
>>a ton of skills and relationships to keep track of, but the computer
>>can do that.
Of course one has to be careful not to create too many (more than say 1000)
skills to keep the system consistent and maintainable. There can also be
weird discrepancies between the relative value of skills - increasing one's
sword-crossing techinique might get ignored in favor of increasing general
offensive fencing. To again take advantange of the computer we can easily
wrap several skills into a "functional" skill (as the fencing skill above) but
this new functional skill is only relative to the component skills. Now for
skills of inequivalent grades - general combat versus katana fighting - we can
bias the skills when we add them up. In a MOO I am working on my favorite way
of doing this is to make a traingular sum:
3 x katana skill +
2 x bladed weapon skill +
1 x general combat skill
/ 6 = current attack skill
Someone who is just a good fighter (a high general combat skill) gets a little
extra boost, even if she has never used a katana before. (Improvements to the
finer skills should be allowed to trickle down to the broader skills for this
to be really effective.) Bladed weapon skill could actually be an average of,
say, thrusting and piercing weapon skills.
Now if you wanted to get crazy and come up with something like KarateMUD we
could have a lot of fun. For every physical move we create a skill, then we
make up a secord order of skills, "kicks", "punches", "blocking", &c. Then
we come up with broader skills, "karate offense", "karate counterattack".
If someone tries to kick a character the defense would be based on "kicks"
plus "karate defense" plus "unarmed combat" plus "general combat"...
The visible effect might be quite subtle but probably more interesting, not to
mention modular.
>>A question, though... how is all this going to come into play? To
>>make it be really needed, the mud's builders will have to provide
>>opportunities to learn skills in all three ways. Not only that,
>>but there should be opportunities for such skills as "theoretical
>>swordsmanship" to come into play in some other way than through
>>their influence on applied skills, or else there will be no benefit
>>to differentiating these skills.
The benefit for players will probably be quite transparent, but then a player
doesn't really know everything that goes into an "attack roll" anyway. Some
muds have that charisma stat where no one knows what skills it actually affects
but everyone increases it anyway. Use a character's perception and theoretical
combat skill to predict what the opponent will do, then bias the actual attack
based on how correct the prediction was. It doesn't have to be a _real_
prediction, just roll some dice. A horribly flubbed prediction means "He
looked like he would lunge to the left but he actually leapt over my head" and
the player would have a good chance of missing completely.
For non-combat stuff this requires more clever
planning. Quests and puzzles often rely on
a player's, not the character's, knowledge (this is not a new problem).
Knowledge-based skills have to be applied to more situations where the player
knows what must be done but the character doesn't. When Shoehorn the herbalist
goes out to pick some wolfsbane he rolls his skill and picks the right plant.
If the player controlling Motch the Drunkard knows where a field of wolfsbane
is, once he gets there Motch should check his skills or he will pick the wrong
plant (even in a field of the right stuff) or perhaps stumble into some poison
oak, or both. Hopefully the player is frustrated but amused, Motch learns a
new skill, and the world's entropy increases.
>Theoretical is more important for learning that skill "for real."
>Thus I will learn much faster if I go train for a while with the
>swordsmaster in my town, THEN go spar with my buddies. Versus just
>running out the town gates and attacking rabbits in a manical rage.
>Your applied skill can still go up, of course, but it will be far
>slower.
I just like the idea of characters being able to do something beside sleep when
you are not logged on. It would probably be a bad idea to train real skills
offline, but if a character logs off while in the guild library he might do
some browsing. Reading books while online is a little too expensive, in a
Marxian sense.
Now as for guilds having special skills only they can learn...
- Brandon as...@oxy.edu
Orion Henry
>>>This isn't true of all paper RPGs; most allow this, but some do not.
>>>RuneQuest, for example, uses a system in which skills can only be
>>>advanced in two ways: by using them or by training in them. There are
>>>some systems in which the GM, not the players, decides which skills
>>>improve.
>>
>>One of my favorites. Simple, easy to keep track of, and fun. The
>>only thing lacking was the fact that skills didn't get any "harder"
>>to learn as that got better, it was just d4 every skill check if you
>>had used that skill.
>
>Hmm... it's been a long time since I played RuneQuest, but I have
>a copy of Chaosium's ElfQuest, which used the same basic system,
>at home. In it, the players are required to make a roll on each
>checked skill to see if it can increase. That roll has to be over
>their current skill level, so that higher-skill characters are less
>likely to improve.
For standard RuneQuest it is (I believe) just d4 every time you make
a "skills check", usually at the end of a gaming session. The DM
could simulate slower learning by calling skills checks less often,
I suppose. *shrug*
>>>Some skills, however, don't have an applied side; what is "applied
>>>history", for example? On the reverse side, what is "theoretical
>>>engineering?"
>>>
>>Neither are really skills. A skill is definted by Webster's as "the
>>ability to use one's knowledge effectively and readily in execution
>>or performance." I'm not sure how you perform applied history.
>>This sort of thing would fall into a knowledge sort of category,
>>which is different from skills IMO.
>
>Webster's also defines a skill as "a learned power of doing something
>competently." It doesn't specify that that has to be something
>physical; it could include remembering facts or making inferences.
>Thus, "knowledge skills" are valid... whether they're useful on
>a mud is another question, of course. :-)
Again we're quibling over symantics, which I was trying to avoid. I
guess what I wanted to say was that a skill has to be something that
you can _do_. How do you _do_ history? You don't, of course - it
is knowledge. If you write a paper about history, you are using
your writing skills, and drawing upon your knowledge of history. A
small difference, perhaps, but an important one to my mind.
>>A better, yet similar, skill would be language skills. If my
>>theoretical knowledge of spoken french was very high (say, I listen
>>to language tapes in my car every day) but I had never actually
>>attempted to use the language, I would find a trip to France rather
>>trying. First of all, understanding them - people in real life talk
>>quite differently than any language tape. Secondly, in speaking the
>>language myself - I "know" the correct accent, language
>>contrstructs, and whatever else, but never having tried it I'm very
>>poor at actually shaping my mouth into the right shapes or thinking
>>in the proper grammatical structure. This is versus the high
>>applied person, who grew up on the streets of France and never saw a
>>language textbook or learned a simgle gramatical rule, but can speak
>>and understand it without difficulty. Now, an educated frenchman
>>might notice their lack of schooling, but they would still
>>understand whatever they were trying to convey.
>
>This, however, can be easily handled by breaking "French" up into
>two subskills: read/write French and speak/understand French.
Certainly - but I still think it's useful to have the theoretical
and applied. In the situation I outlined above, the car-tape guy
would have a high theoretical in spoken, and none in written. The
streets-dude would have a high applied in spoken and none in
written.
This gets more complex when you consider that, since the
card-tape-dude (presumably) knows how to read and write english, he
can figure out how many of the french words will be spelling. But
this is related to skill-trees, another highly useful and easy to
implement way to break up your skills, allowing certain overlap
between related skills.
>Someone who learned French from books would have a better skill
>in reading and writing French, and a worse skill in speaking it.
I never mentioned books, I was speaking purely of spoken. :)
>This sort of skill division becomes even more useful when dealing
>with non-alphabetic languages, such as Chinese. Mandarin and
>Cantonese are very different spoken languages, but are both
>written the same way. For that matter, Chinese characters are
>often used in writing Japanese. (To make things extra fun,
>Japanese also has at least two other forms of writing).
Ugh, don't even start with Asian languages. There's so much overlap
there it makes me twitch just to think about trying to code THAT.
>>Theoretical is more important for learning that skill "for real."
>>Thus I will learn much faster if I go train for a while with the
>>swordsmaster in my town, THEN go spar with my buddies. Versus just
>>running out the town gates and attacking rabbits in a manical rage.
>>Your applied skill can still go up, of course, but it will be far
>>slower.
>
>To me, though, it seems somewhat redundant to keep two separate
>skill values for this... I'd simply allow "theoretical" learning
>to increase the skill, but more slowly and with a limit to how
>much can be learned that way. Granted, you don't get the full
>effect that way, but you get most of the good points, with less
>complication and less storage needed.
Well, the original post I was replying to suggested this, and I
support it for the same reason he did: because as long as you're
going to center your MUD around skills, you damn well better make
them complex and interesting. I find the difference between the
theoretical and applied skills pretty cool, myself.
In addition, I'd use them even if I didn't think they were cool.
Two values is a great way to regulate the rate of learning; and I've
found that this is true for many, many dynamic values found
throughtout the MUD. By breaking skills, movement points, mana,
hunger and thirst, and other stuff into two values you can make
things work more realsticially in a chronological sense, whether it
be by using the relative difference between the values (skills) or
by using one of the values as the derivative (rate of increase) of
the other.
Orion Henry
>However, I prefer to let the players select for themselves how to "spend"
>their earned experience (yeah, it's less *realistic* but the whole thing
>things to be were I a player inside the system, and that's what I think I
>would prefer.
I think the original post in this thread was something like, "How
can I get rid of levels and experience on my MUD?"
One of the best things about a skill based system, IMO, is that you
can just nuke experience, fixing a whole slew of problems by simply
abandoning the tired old experience-road.
Marco Braga
On 19 Jul 1996 09:12:21 +0200, gry...@IAEhv.nl wrote:
>:>Make a failed hide actually -loose- you some proficiency in the skill.
>:>Or, as the player repeats the same skill over and over again, increase
>:>the change to forget rather than learn from the skill slowly.
>
>>Sadly this will not be realistic. Why should someone forget a thing
>>just by repeating it over and overe. There must be another way...
>
>Not realistic? Just claim that if you fail to do something
>right you learn a little to do it wrongly. Or you 'unlearn' it.
Well, this seems to be an acceptable explanation, but sometimes it's
not true. As ancient wisdom teaches ("learn by mistake") most of the
time mistakes don't teach you to do things wrong, but what not to do
to avoid failure. I.e. if I do something in some way and I fail, I
figure out that the method I used is not right, and I won't repeat it.
You are saying that I will continue to repeat the mistake in the same
way, and get even worse at it.
>I don't know. I don't think forcing players to delay learning is any
>more realistic than making them risk getting less proficient.
To be honest consider all "one shoot" skills, such as evaluating. What
I do want to avoid is that a player sets up his client to repeat the
skill a thousand of times and learn something by failure/successes.
Of course I could use spell reagents to avoid this on spells or use
stamina for combat skills, but there are a lot of skills that can't be
fixed this way. Someone mentioned I could avoid to teach something if
I do reapeat the same skill on the same subject, but how do I save
information on the subject, considering how volatile can be
object/char pointers/addresses on muds. Consider picking locks: I
should memorize the last lock was picked and compare it with new
attempts, while apparaise should memorize the bunch of gold, or the
object was last appraised, and so on. This doesn't seem to be an easy
task, and also seems to be a bit heavy on memory/CUP time.
>And combine that with a system that to learn more advanced skills you
>must be sufficiently proficient in other skills (e.g. a mage must learn
>'create fire' and 'control file' to be able to learn 'fireball' and
>can't learn the last spell no better than the required spells combined.)
This seems to be a good idea, but in the system I am considering
skills aren't trained with a master, they improve by use. So if
casting a fireball requires 'create fire' and 'control file', those
skills should be learned by trying to cast fireballs. Also nothing
denies the player from repeating skills that improve 'create fire'
first, and then skills that require 'control fire' later...
Brandon Joseph Rickman
In article <4sir0b$9...@news.fsu.edu>,
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>In other, possibly less confusing terms, we keep track of both the
>character's current skill level and his/her greatest achieved skill
>level.
Yes, those are probably better terms.
>This leads to a potential problem... let's say that I play for 5 hours,
>and earn 30 points in skill improvements during that time. 18 hours
>later I log on, play some more, and earn 20 points in skill improvements.
>If this sort of cycle continues, then I'm always going to have a
>"backlog" of learning for my character. This might cause people to
>take longer breaks, yes... but it could also result in a huge backlog
>of skill advances, such that when someone takes, say, a three week
>vacation, they come back to a vastly improved character.
Well, if there is a huge skill backlog then I would guess this is something
that could be fixed by rebalancing how skills are earned and how short/long
the game hour is. But I think there _should_ be a small backlog for any
excessively active character. Not only can this combat client abuse, it will
mean a certain amount of real game time is required to master any skill. Just
to play with numbers for a minute, assume a game hour is 15 minutes long (note:
a game hour isn't even a game hour here. It could be a game day/month, I don't
care. It is just some time unit within the environment). An active player
would be able to increase some skill every game hour on average. Say they play
for 6 hours and rest 18, but during that 6 hours of play they could stack up
96 points of skill increases, to be doled out in game hour intervals over the
next 24 hours. Is it reasonable to earn 16 skill points in an hour of game
play? If 100 points is mastery, the character has mastered one skill (kind of
like cramming for a test), or has two pretty useful skills, or 4 okay skills.
Yes, when someone takes a 3 week vacation they can come back to a dramatically
improved player, _but_ since they haven't used any skills for 3 weeks their
current skills are well below the learned skill level.
>Is the increased complication worth the benefit?
If you want a skill-based system and you want it to be flexible, I say yes.
There are enough MUDs - and perhaps this is why they are so popular - that are
mind-numbingly simple and very inflexible. With good code you wouldn't have to
understand the complexity.
>A question; if skills that are needed immediately are applied immediately,
>what happens if Shoehorn fights an Ogre, gains 3 points of sword skill
>improvement, then goes and fights something else five minutes later?
>Surely he needs his improvement now... it might save his life!
I thought it was clear from my examples that Shoehorn is a bumbling fool.
Okay, the system changes some essential concepts around: you can't go kill a
level 20 monster every 5 minutes. The pseudo story arc a character is playing
should lead to a climax, the skills you learn early in the adventure will help
you most when you confront the final bad guy. Fighting one big hairy monster
after another is fine for an epic hero, but then any hero probably had massive
stats before starting the adventure. This is why quests are fun, because they
are good at balancing out characters that already know how to slaughter orcs.
If Shoehorn needs a sword skill that badly, well, he should take it a little
more slowly.
- Brandon
Travis S Casey
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>>
>>Webster's also defines a skill as "a learned power of doing something
>>competently." It doesn't specify that that has to be something
>>physical; it could include remembering facts or making inferences.
>>Thus, "knowledge skills" are valid... whether they're useful on
>>a mud is another question, of course. :-)
>
>Again we're quibling over symantics, which I was trying to avoid. I
>guess what I wanted to say was that a skill has to be something that
>you can _do_. How do you _do_ history? You don't, of course - it
>is knowledge. If you write a paper about history, you are using
>your writing skills, and drawing upon your knowledge of history. A
>small difference, perhaps, but an important one to my mind.
The viewpoint I'm taking is that a skill doesn't have to be something
that you do directly--it can simply provide a modifier to another
skill. For instance, a "physics" skill doesn't have a direct
application, but it could be used in combination with other skills
to determine whether, say, the player can design a good bridge.
Knowledge skills can also be used as prerequisites for other skills;
knowledge of some mathematics, for example, is required for many
practical skills, such as mechanical engineering, electronics,
computer programming, etc. Requiring characters to build values
in skills that don't have a direct application can be another way
of slowing down skill advancement. :-)
Lastly, one can argue that even if you're not doing anything
*physical* with a skill, you're still doing something with it.
For example, a physics skill might have an application in
deciding whether or not a character can understand a set of notes
left behind by a mad scientist.
In any case, though, whether you call them a skill or not doesn't
matter... what really matters is how the game uses them. :-)
>>This, however, can be easily handled by breaking "French" up into
>>two subskills: read/write French and speak/understand French.
>
>Certainly - but I still think it's useful to have the theoretical
>and applied. In the situation I outlined above, the car-tape guy
>would have a high theoretical in spoken, and none in written. The
>streets-dude would have a high applied in spoken and none in
>written.
Umm... someone who grew up on the streets in a French-speaking
area will probably at least be able to read street signs. :-)
Further, I'd argue that the car-tape guy won't have a high
theoretical knowledge of French... he probably won't, for
instance, be able to understand complex sentences better than
the person who grew up on the streets. He might have a better
skill in, say, "formal French" (are there terms for French
analogous to High German/Low German?), but he wouldn't have
as high a skill in "colloquial French."
To use an example I'm more familiar with... I took three
semesters of German in college, and when I took a trip to
Germany the summer after I graduated, I was able to understand
people somewhat. My father, however, lived in Germany for
several years while he was in the Air Force. He can't read
or write German, and he doesn't have much of a grasp of
proper German grammar, but he can make himself understood in
and understand German better than I can.
>>To me, though, it seems somewhat redundant to keep two separate
>>skill values for this... I'd simply allow "theoretical" learning
>>to increase the skill, but more slowly and with a limit to how
>>much can be learned that way. Granted, you don't get the full
>>effect that way, but you get most of the good points, with less
>>complication and less storage needed.
>
>Well, the original post I was replying to suggested this, and I
>support it for the same reason he did: because as long as you're
>going to center your MUD around skills, you damn well better make
>them complex and interesting. I find the difference between the
>theoretical and applied skills pretty cool, myself.
Hmm... given that class-centered muds don't generally have
what I'd consider complex or interesting class systems, and
still seem to attract plenty of players, I'd have to disagree
with your first point. :-)
I do find the idea of theoretical vs. applied skills to be
interesting, but I think it can be better handled in other
ways. Also, I'm not sure that using it would actually make
enough of a difference in the ultimate results to justify
the coding time and extra storage. Ah, well... to each
their own. :-)
>In addition, I'd use them even if I didn't think they were cool.
>Two values is a great way to regulate the rate of learning; and I've
>found that this is true for many, many dynamic values found
>throughtout the MUD. By breaking skills, movement points, mana,
>hunger and thirst, and other stuff into two values you can make
>things work more realsticially in a chronological sense, whether it
>be by using the relative difference between the values (skills) or
>by using one of the values as the derivative (rate of increase) of
>the other.
That's often true... however, I never said that skills shouldn't
have different rates of increase or other associated values; indeed,
the skill system I've worked out for the mud I'm working on allows
skills to have variable rates of increase.
Ah, well... I don't think either of us is going to convince
the other, and I think we both have a good grasp of what
we're talking about... so let's just live and let live. :-)
gry...@iaehv.nl
In article <31ec387c...@nntpserver.vol.it>,
Marco Braga <bra...@mbox.vol.it> wrote:
>On 15 Jul 1996 23:13:06 +0200, gry...@IAEhv.nl wrote:
:>Make a failed hide actually -loose- you some proficiency in the skill.
:>Or, as the player repeats the same skill over and over again, increase
:>the change to forget rather than learn from the skill slowly.
>Sadly this will not be realistic. Why should someone forget a thing
>just by repeating it over and overe. There must be another way...
Not realistic? Just claim that if you fail to do something
right you learn a little to do it wrongly. Or you 'unlearn' it.
>A better way seems to be setting a minimum delay among uses of a skill
>before they can be considered for a learn effort. This brings us to a
>question: how long this delay should be?
I don't know. I don't think forcing players to delay learning is any
more realistic than making them risk getting less proficient.
How about a skill that gets rusty when not used (trained) regularly.
And combine that with a system that to learn more advanced skills you
must be sufficiently proficient in other skills (e.g. a mage must learn
'create fire' and 'control file' to be able to learn 'fireball' and
can't learn the last spell no better than the required spells combined.)
Marian
Marco Braga
On 19 Jul 1996 02:17:08 GMT, ohe...@sdcc10.ucsd.edu (Orion Henry)
wrote:
>I think the original post in this thread was something like, "How
>can I get rid of levels and experience on my MUD?"
Right, since I am the original poster I can confirm you're right.
Paper RPG have changed from old exp/level systems to skill system, why
shouldn't MUDS do the same?
>One of the best things about a skill based system, IMO, is that you
>can just nuke experience, fixing a whole slew of problems by simply
>abandoning the tired old experience-road.
Exactly, since experience is often used to advance knowledge and is
gained from actions, why don't cut the middle passage through
experience and simply assume that use modifies knowledge/power/skill?
A lot of MUDs are based on exp/level systems and seem to have reached
balancement among those aspects, the main problem in new skill systems
is how to find the same balancement. One of the most important aspects
is that player enjoyment must be constant during the entire
developement of the character and game time; also character
advancement must give to good and smart players the feeling of
improvement. This is I think the goal to be reached.
I toss in another question. On average, how much playtime must be
spent on average muds to reach maximum power? Sure
class/race/gamesytyle is a point here, but I think everyone of you
should have an idea about this. How much time should a player play to
reach mastery in its class/skills of choice? 1 month? 6 months?
Wait, wait, I am not saying that the goal of MUDs is to maximize a
character, I am just asking since I have to figure out some average
values I need to trim difficulty on a system I am starting to work on.
Vorlon Ambassador
Archaeological digs found the words of Marco Braga (bra...@mbox.vol.it):
> On 19 Jul 1996 09:12:21 +0200, gry...@IAEhv.nl wrote:
>
> >:>Make a failed hide actually -loose- you some proficiency in the skill.
> >:>Or, as the player repeats the same skill over and over again, increase
> >:>the change to forget rather than learn from the skill slowly.
> >
> >>Sadly this will not be realistic. Why should someone forget a thing
> >>just by repeating it over and overe. There must be another way...
> >
> >Not realistic? Just claim that if you fail to do something
> >right you learn a little to do it wrongly. Or you 'unlearn' it.
>
> not true. As ancient wisdom teaches ("learn by mistake") most of the
> time mistakes don't teach you to do things wrong, but what not to do
> to avoid failure. I.e. if I do something in some way and I fail, I
> figure out that the method I used is not right, and I won't repeat it.
> You are saying that I will continue to repeat the mistake in the same
> way, and get even worse at it.
>
practicing spinning a knife in the air and catching it, every mistake
would teach me what NOT to do in the future. What about using a computer
though? It seems that Microsloth has taught an awful lot of people that
the proper solution to your computer not responding is to give it the
three-finger salute, or poke the reset button. Many people I know have
"learned" this. ANY time something freezes or bombs out, they automatically
reach for the reboot keys without even trying to figure out why something
died. I would propose that their "computer use skill" is getting worse
through repeated failure.
> >I don't know. I don't think forcing players to delay learning is any
> >more realistic than making them risk getting less proficient.
>
> To be honest consider all "one shoot" skills, such as evaluating. What
> I do want to avoid is that a player sets up his client to repeat the
> skill a thousand of times and learn something by failure/successes.
>
Someone else mentioned here (and a friend of mine also worked on a
variant of this idea) the concept of putting a delay time in your
skill's advancement eligibility. That is, if you have just gotten
a bit better at "swing one-handed blade", you won't continue to get
better until X amount of time passes. Thus the player who sits in
the chicken coop and hacks dozens of defensless little birds to bits
won't improve more than a little bit at a time.
The argument here would be, what about the players who really do
wade through monsters? Won't they get penalized from not improving
as much as they should? Well, if they really can wade through things
that easily, they don't NEED to improve do they?
> Of course I could use spell reagents to avoid this on spells or use
> stamina for combat skills, but there are a lot of skills that can't be
> fixed this way. Someone mentioned I could avoid to teach something if
> I do reapeat the same skill on the same subject, but how do I save
> information on the subject, considering how volatile can be
> object/char pointers/addresses on muds. Consider picking locks: I
> should memorize the last lock was picked and compare it with new
> attempts, while apparaise should memorize the bunch of gold, or the
> object was last appraised, and so on. This doesn't seem to be an easy
> task, and also seems to be a bit heavy on memory/CUP time.
To do it this way, you would need to save some number of 'last reference'
tags for each skill. Perhaps the last 20 things you used it on would be
sufficient. In an lp, this would end up being an array of (probably)
filenames to test against when considering the skill advancement...
if(member_array(target, last_target_list) < 0) {
if(advance_ok()) {
advance();
last_target_list= last_target_list[0..19] + target;
}
}
If you wanted a failed advancement to still count for varying the things
you're working with, just move the target_list adjusting line out of the
if statement.
In a diku, I suppose you'd have to remember "VNUMs" and pray to the
God of Hardcoded Messes that nobody switched vnums on you so you suddenly
had already defeated Ulga the Towering Troll of Telluria but had never
even seen a Newbie Biter.
>
> >And combine that with a system that to learn more advanced skills you
> >must be sufficiently proficient in other skills (e.g. a mage must learn
> >'create fire' and 'control file' to be able to learn 'fireball' and
> >can't learn the last spell no better than the required spells combined.)
>
> This seems to be a good idea, but in the system I am considering
> skills aren't trained with a master, they improve by use. So if
> casting a fireball requires 'create fire' and 'control file', those
> skills should be learned by trying to cast fireballs. Also nothing
> denies the player from repeating skills that improve 'create fire'
> first, and then skills that require 'control fire' later...
>
Hmmmmm... so you allow players to learn any skill they want from
thin air? Nothing wrong with that I suppose, I'm just curious on
how they gain the skill in the first place. In a hierarchical
skill system, you would have to know 'create fire' and 'control fire'
before you could attempt anything like 'fireball'... In fact, you
might not even know that 'fireball' exists until you've learned
the prereq's sufficiently.
If nobody ever shows you a fireball, how would you even know to
try and make one? On the other hand, if you knew fire skills,
maybe it would occur to you to see if you can summon up a glob
of fire and pitch it at someone.... thus inventing fireball.
I have often thought that half the enjoyment and variety of a
good mud derives from the variance and complexity of the messages
one gets when something happens. Seeing "Yukolv's fireball
**!^@# UTTERLY LOBOTOMIZES YOU!!! #@^!** with its BURN!" just
is not sensible to Ugh the Fighter who barely knows what fire
is. It's much more fun to see 'Yukolv mutters and makes rude
gestures at you. Suddenly a brilliant orange glob of flame
steaks out from his hand and smashes into you! The impact
hurls you to the ground and the stench of your own flesh
curls around you."
It is most successful if the message is one of a farily large
set which is chosen randomly. The idea here is that if the
target has no clue what spell that was, he should get a pretty
generic description of the effects only. A fellow mage on
the receiving end, who also knew the fireball spell, might see
something more like "With a smirk, Yukolv begins incanting
fireball. Before you can duck for cover, the spell forms and
you see him hurl a huge gout of fire straight at you. The
fireball smashes you to the ground and seems to sear off half
your skin!"
-Chris.
> Marco
>
> -========================================================-
> Marco Braga (Tempus) - implementor at *The Gate MUD*
> telnet mondeo.vol.it 4000 - WWW http://mondeo.vol.it
> email: .......................... bra...@mbox.vol.it
> -========================================================-
--
__________ .________ The Babylon Project is our last best hope for quality
\______ \| ____/ television programming.
| | _/|____ \
| | \/ \
|______ /______ / Chris Meshkin <http://yakko.cs.wmich.edu/~chris>
\/ \/ The Vorlon Empire denies any involement in the above text.
Marco Braga
On 20 Jul 1996 04:36:58 GMT, ch...@yakko.cs.wmich.edu (Vorlon
Ambassador) wrote:
>Someone else mentioned here (and a friend of mine also worked on a
>variant of this idea) the concept of putting a delay time in your
>skill's advancement eligibility. That is, if you have just gotten
>a bit better at "swing one-handed blade", you won't continue to get
>better until X amount of time passes.
Yeah, this seems to be a rather good solution. Well, what number do
you think the X should be? I'm trying to figure out some numbers,
let's say 5 seconds? Wait, wait, there is a better solution. Instead
of denying any learning from skills used before the set mimimum delay,
why not to cut the learning gained acording to time?
I.e. if 5 secs is the minimal time, a reuse of the skill after 1 sec
will gain 1/5, a use after 4 secs will give 4/5... You can even use a
greater divisor, so that you will learn less:
If delay is below max_delay:
learn = learn / (max_delay*mult)
else
learn isn't changed.
So if the skill multiplier is set to 2 and I repeat the skill after 1
sec I will only gain 1/10. With this system if min_delay is set to 5
secs and mult is 2, I will gain at 1/2 the normal rate if I repeat the
skill every 1 second (1/10 * 5 times every 5 seconds).
>The argument here would be, what about the players who really do
>wade through monsters? Won't they get penalized from not improving
>as much as they should? Well, if they really can wade through things
>that easily, they don't NEED to improve do they?
Well, I am already considering the difficulty of the task, so that if
a player can wade through monster it means that those monsters are not
very hard, so doing this will not make the char learn much.
>To do it this way, you would need to save some number of 'last reference'
>tags for each skill.
Yes, I could save the number of the skill used and its target.
>Hmmmmm... so you allow players to learn any skill they want from
>thin air?
My idea is that players improve their skills by practicing them. So
for example they become better at casting fireballs when they cast
them (or try to cast). If you consider this, yes, they "improve" trom
thin air.
> Nothing wrong with that I suppose, I'm just curious on
>how they gain the skill in the first place.
That's another point. They do learn new skills from masters at guilds,
or from their heritage or background.
>If nobody ever shows you a fireball, how would you even know to
>try and make one? On the other hand, if you knew fire skills,
>maybe it would occur to you to see if you can summon up a glob
>of fire and pitch it at someone.... thus inventing fireball.
Well, you can't just "try" to invoke a fireball if you're not adept in
the magical arts, and you can't become adept without prior training.
There are some skills which are "innate", others are "acquired". As an
example swinging a sword is "innate", i.e. even if you won't perhaps
become a master you do already have what you do need to handle a sword
(hands, intelligence, etc.). Other skills are "dormant" or better
can't be learned without prior study. Even if I try, I will never be
able to cast a fireball if I don't have the basics of magic and
spellcasting, simply because I do lack the "instruments" to do it.
Needed basic knowledge can be gained only from anoter mage or from
books. Instead when I do know about the magical arts I can try to
create a fireball, even if I never tried to do it, and even improve my
skill in the process.
>I have often thought that half the enjoyment and variety of a
>good mud derives from the variance and complexity of the messages
>one gets when something happens.
I agree, but this is not really relevant to the subject of the thread.
I am interested in game mechanics needed to handle skills. Btw, it is
a nice idea.
Orion Henry
>> >:>Make a failed hide actually -loose- you some proficiency in the skill.
>> >:>Or, as the player repeats the same skill over and over again, increase
>> >:>the change to forget rather than learn from the skill slowly.
>> >
>practicing spinning a knife in the air and catching it, every mistake
>would teach me what NOT to do in the future. What about using a computer
>though? It seems that Microsloth has taught an awful lot of people that
>the proper solution to your computer not responding is to give it the
>three-finger salute, or poke the reset button. Many people I know have
>"learned" this. ANY time something freezes or bombs out, they automatically
>reach for the reboot keys without even trying to figure out why something
>died. I would propose that their "computer use skill" is getting worse
>through repeated failure.
Possibly, but I think that loosing skill for repeated failures is,
in general, a bad idea. Since we're speaking in generalities,
things that will apply to all the skills, I think there are far
better options for pacing advancement. (And it is pacing, not
limiting.)
>Someone else mentioned here (and a friend of mine also worked on a
>variant of this idea) the concept of putting a delay time in your
>skill's advancement eligibility. That is, if you have just gotten
>a bit better at "swing one-handed blade", you won't continue to get
>better until X amount of time passes. Thus the player who sits in
>the chicken coop and hacks dozens of defensless little birds to bits
>won't improve more than a little bit at a time.
That was me.
>The argument here would be, what about the players who really do
>wade through monsters? Won't they get penalized from not improving
>as much as they should? Well, if they really can wade through things
>that easily, they don't NEED to improve do they?
Right, in which case you've created a skill system which isn't
balanced. Assuming the system is coded well, just tweaking a few
numbers should fix that problem. Basically, in order to bring a
system like this into balance, you have to find a equilibrium
between chance for advancement and chance for "punishment" (usually
something fun like maiming or death for combat skills). Thus
sitting in a chicken coop is easy, but the skill levels of the
chickens are so low that your skills never go up. Going and
attacking a big buff mob is silly because you die right away, and/or
don't learn much of anything anyways because it's so much better
than you. The point of equilibrium is where you can go attack a
critter, and if you win/live, expect to get a little better in whatever
skills you applied. If you just do this nonstop, however, the law
of probabilty says sooner or later you're going to get rocked.
>> object/char pointers/addresses on muds. Consider picking locks: I
>> should memorize the last lock was picked and compare it with new
>
>To do it this way, you would need to save some number of 'last reference'
>tags for each skill. Perhaps the last 20 things you used it on would be
>sufficient. In an lp, this would end up being an array of (probably)
>filenames to test against when considering the skill advancement...
I believe Arctic uses something like this, though I'm not positive.
Personally I think this takes up too much space and processor time
for the "advantages" it gives. One of the main things I noticed on
Arctic was that fighting tough critters I had found a hundred times
rarely advanced my skills, whereas going to fight something I
slaughter easily advanced three seperate skills just because I had
never fought them before. This does seem a tad silly; as long as
something continues to provide a challange for me, I should learn
from using my skills against it. Of course Arctic is still bound to
the exp/levels thing, which is rather bad for skill based systems.
>If nobody ever shows you a fireball, how would you even know to
>try and make one? On the other hand, if you knew fire skills,
>maybe it would occur to you to see if you can summon up a glob
>of fire and pitch it at someone.... thus inventing fireball.
Of course the trick is implementing this. If you just give players
a bunch of seperate runes that combine to make spells, player will
just attempt every possible combination and see which ones do things.
(Witness Legend MUD.) If you combine them automatically into
spells, you have something which looks esentially exactly like the
old spell system (withness Tera MUD).
>is. It's much more fun to see 'Yukolv mutters and makes rude
>gestures at you. Suddenly a brilliant orange glob of flame
>steaks out from his hand and smashes into you! The impact
>hurls you to the ground and the stench of your own flesh
>curls around you."
>target has no clue what spell that was, he should get a pretty
>generic description of the effects only. A fellow mage on
>the receiving end, who also knew the fireball spell, might see
>something more like "With a smirk, Yukolv begins incanting
>fireball. Before you can duck for cover, the spell forms and
>you see him hurl a huge gout of fire straight at you. The
>fireball smashes you to the ground and seems to sear off half
>your skin!"
Well, those are rather verbose to be real messages, but point taken.
I tend to favor a generic description for everyone; I mean, what is
there really to say about a glob of fire hurling through the air at
you? Thus Uglug the Troll sees:
Murazor mumbles an incantation.
The hairs on the back of your neck stand up....
A huge ball of fire streaks through the air, straight into your chest!
Whereas Ulfang, Murazor's buddy, sees:
Murazor begins chanting a fireball spell!
A huge ball of fire streaks through the air, straight into Uglug's chest!
You could get more involved than this, of course, but I think this
method serves pretty well.
For the "lesser" fire mage, who only knows "conjure", "throw" and
"fire":
Murazor begins chanting a conjure spell.
Murazor begins chanting a throw spell.
Murazor begins chanting a fire spell!
Then they could figure out to do:
cast 'conjure throw fire'
or whatever.
gry...@iaehv.nl
In article <31ef8d54...@nntpserver.vol.it>,
Marco Braga <bra...@mbox.vol.it> wrote:
>On 19 Jul 1996 09:12:21 +0200, gry...@IAEhv.nl wrote:
>To be honest consider all "one shoot" skills, such as evaluating. What
>I do want to avoid is that a player sets up his client to repeat the
>skill a thousand of times and learn something by failure/successes.
I understand. But to be honest I don't see why you should bother.
If a player wishes to 'cheat' they will find ways. I would just let
them. The fun of the game is not maxing out but to team up and
struggle against overwhelming odds. Having a little program typing
'hide' a thousand times is incredibly boring, and lame. But if that's
what a player wants to do I'd say let them. And give them a sword of
ultimate destruction (+100 +100 -500AC) to boot. That way they can
walk round the game, do anything they like and quickly leave for another
one because yours has no challenge. Players who are interested in playing
will stay and don't have to deal with all the time and effort you have
put into foiling the spoilsports.
>object/char pointers/addresses on muds. Consider picking locks: I
>should memorize the last lock was picked and compare it with new
>attempts, while apparaise should memorize the bunch of gold, or the
>object was last appraised, and so on. This doesn't seem to be an easy
>task, and also seems to be a bit heavy on memory/CUP time.
Keep track for each skill what time at the earliest that skill can
be considered for learning again. Or randomly select three skills
that can improve (including skills that haven't been learned yet).
Everytime a skill is changed it will be replaced by another one on
that little list. Since everything is random no player can hope to
achieve figuring out what skill to type, and they might as well go
out and enjoy themselves in the world.
>>And combine that with a system that to learn more advanced skills you
>>must be sufficiently proficient in other skills (e.g. a mage must learn
>>'create fire' and 'control file' to be able to learn 'fireball' and
>>can't learn the last spell no better than the required spells combined.)
>This seems to be a good idea, but in the system I am considering
>skills aren't trained with a master, they improve by use. So if
>casting a fireball requires 'create fire' and 'control file', those
>skills should be learned by trying to cast fireballs. Also nothing
>denies the player from repeating skills that improve 'create fire'
>first, and then skills that require 'control fire' later...
That's the idea indeed. Of course as they no longer 'practice' the
fairly useless skill 'create fire' (I mean, which powerhungry player
is going to bother with a spell that can light a candle, or put a
bit of kindle to fire?) This skill degenerates, and because of that
their fireball skill fades too. There's no need to -tell- the
players any of that, and if they figure out they still have to spent
all that time keeping their minor skills at adept level.
Most skill-based systems require the transfer of some kind of
knowledge, either through a teacher, sage, guildmaster or tome of
knowledge before a skill can be trained. This is to lock powerfull
skills away from the low level players. Of course there needn't be
levels but at least a player should be able to outclass a certain
degree of monsters before being able to learn more advanced skills.
Such systems work well with a 'tree of knowledge' <love that little pun>
Marian
Matthew R. Sheahan
Orion Henry (ohe...@sdcc10.ucsd.edu) wrote:
> These are kind of bad examples, I think, because I doubt anyone has
> plans to implement history or physics as skills on a MUD. :)
Lost Souls implements history. it's useful for identifying artifacts.
btw, "applied history" is connecting the information from "theoretical
history" into a useful model that helps you understand what's happened,
what's happening, and what's going to happen.
chiaroscuro
Carter Butts
Anthony C. wrote:
>
> In article <4skid1$8...@sdcc12.ucsd.edu>,
> Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
> :>One of the advantages of role-playing on a MU* is that we can do a lot of
> :>skill calculations that would be a nuisance to do on paper. One of the
> :
> :Absolutely! That's one of the reasons I so favor ditching just
> :about everything from pen and paper RPGs and rethinking from
> :scratch, keeping in mind the limitations and special abilities
> :afforded to us by having the computer as a DM.
>
> would be impossible to do with a pen and paper rpg but are actually
> easier to implement on a computer than a table of values with ranges
> like an pen and paper rpg.
>
> --
> Anthony C.
Of course, some RL RPGs are better suited to M** implementation
than others. A system which some folx and I have cooked up, for
instance, called _Alternate_Realities_ would be (IMHO) excellent
for such a purpose. (On a MOO, anyway...I'm not sure about
non-object oriented systems.) I say this because AR uses a lot of
principles (object orientation, a diminishing returns function,
etc.) from the World 'O Code (C), and hence it's not a lot of a
stetch to reify the rules in software...
Of course, you'd still have the tricky question of how the
GM fits in...but you would at least be working with a system which
was isomorphic with the medium in use....
(I'll stop plugging now. ;-))
-Carter
(The AR home page is at http://son3.mc.duke.edu/~eagle/AR, for those
who are interested...)
mor...@niuhep.physics.niu.edu
ohe...@sdcc10.ucsd.edu (Orion Henry) writes:
>>> >:>Make a failed hide actually -loose- you some proficiency in the skill.
>>> >:>Or, as the player repeats the same skill over and over again, increase
>>> >:>the change to forget rather than learn from the skill slowly.
>>> >
>>I believe this depends on the skill in question. Certainly if I were
>>practicing spinning a knife in the air and catching it, every mistake
>>would teach me what NOT to do in the future. What about using a computer
>>though? It seems that Microsloth has taught an awful lot of people that
>>the proper solution to your computer not responding is to give it the
>>three-finger salute, or poke the reset button. Many people I know have
>>"learned" this. ANY time something freezes or bombs out, they automatically
>>reach for the reboot keys without even trying to figure out why something
>>died. I would propose that their "computer use skill" is getting worse
>>through repeated failure.
>
>Possibly, but I think that loosing skill for repeated failures is,
>in general, a bad idea. Since we're speaking in generalities,
>things that will apply to all the skills, I think there are far
>better options for pacing advancement. (And it is pacing, not
>limiting.)
Hi,
Below is the method I will be using in my (as yet etherial) mud.
It limits experience gained via failure without screwing the players.
I think it is clear that if someone fails 5-10 times in a row sie is
missing something.
Robert
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FPmax: Maximum amount of experience learnable through failure with
no successes.
FPtot: Total amount of experience learned through failure since
last success.
SP(event): The amount of experience that would have been gained had
the player succeeded.
FPsubtract: Flag indicating FPmax has been exceeded.
I would expect FPmax to be no more than twice the average SP(event).
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
If FPtot .ge. FPmax
then
FPsubtract = 1
endif
If FPsubtract .eq. 0
then
FPtot=FPtot+SP(event)/5
else
FPtot=FPtot-SP(event)/5
endif
If FPtot .le. 0 then FPsubtract = 0
[alternatively the last line could be:
If FPtot .le. (-1)*FPmax then FPsubtract = 0]
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Orion Henry
>>To be honest consider all "one shoot" skills, such as evaluating. What
>>I do want to avoid is that a player sets up his client to repeat the
>>skill a thousand of times and learn something by failure/successes.
>
>I understand. But to be honest I don't see why you should bother.
>If a player wishes to 'cheat' they will find ways. I would just let
>them. The fun of the game is not maxing out but to team up and
>struggle against overwhelming odds. Having a little program typing
>'hide' a thousand times is incredibly boring, and lame. But if that's
>what a player wants to do I'd say let them. And give them a sword of
There does have to be some limitations to this stuff, and giving
them a chance to learn hide every time they hide is just silly.
Yes, there will probably always be ways to cheat, but it's not that
hard to get around the obvious problems.
Secondly, it's that "suspension of disbelief" thing. If you play a
MUD which claims to be realistic, how can you really believe that
when you manage to become the world's best lock pick by picking the
same lock 10,000 times?
>>object/char pointers/addresses on muds. Consider picking locks: I
>>should memorize the last lock was picked and compare it with new
>>attempts, while apparaise should memorize the bunch of gold, or the
>>object was last appraised, and so on. This doesn't seem to be an easy
>>task, and also seems to be a bit heavy on memory/CUP time.
>
>Keep track for each skill what time at the earliest that skill can
>be considered for learning again. Or randomly select three skills
>that can improve (including skills that haven't been learned yet).
>Everytime a skill is changed it will be replaced by another one on
>that little list. Since everything is random no player can hope to
>achieve figuring out what skill to type, and they might as well go
>out and enjoy themselves in the world.
This isn't a bad method, but again it's got that hacky, clever twist
to it that most of diku is based on. There's nothing wrong with
this idea, persay, it's just not an acurate representation of the
world. Any trick you come up with players will eventually "figure
out" - so you might as well just model the system in a realistic
manner. Thus "figuring it out" will consist of realizing that the
best way to advance skills is to go out and use them in a variety of
situations.
>That's the idea indeed. Of course as they no longer 'practice' the
>fairly useless skill 'create fire' (I mean, which powerhungry player
>is going to bother with a spell that can light a candle, or put a
>bit of kindle to fire?) This skill degenerates, and because of that
>their fireball skill fades too. There's no need to -tell- the
>players any of that, and if they figure out they still have to spent
>all that time keeping their minor skills at adept level.
Are you saying you should have to keep your candle-lighting skill
maintained seperately from your Ball of Fiery Death skill? I have
trouble envisioning a master wizard going home after a long day of
toasting baddies to practice on his shield, magic missile, and
detect invis spells. One would thing that as long as I'm keeping up
my skills in magical fire, candle-lighting comes along with that.
>Most skill-based systems require the transfer of some kind of
>knowledge, either through a teacher, sage, guildmaster or tome of
>knowledge before a skill can be trained. This is to lock powerfull
>skills away from the low level players. Of course there needn't be
>levels but at least a player should be able to outclass a certain
>degree of monsters before being able to learn more advanced skills.
>Such systems work well with a 'tree of knowledge' <love that little pun>
Skill trees are easy to implement, fun for the players to explore,
and a great way to model skills. This even makes the "locking away"
thing kind of moot. You can indeed teach a newbie mage Ball of
Fiery Death but until he's mastered candle lighting, Ball of Really
Warm Air, Ball of Really Pretty Uncomfortably Hot Air, and Ball of
Fiery Nasty Wounds he'll find that knowledge both useless and
difficult to grasp.
Travis S Casey
<gry...@IAEhv.nl> wrote:
>Marco Braga <bra...@mbox.vol.it> wrote:
>>On 19 Jul 1996 09:12:21 +0200, gry...@IAEhv.nl wrote:
>
>>I do want to avoid is that a player sets up his client to repeat the
>>skill a thousand of times and learn something by failure/successes.
>
>I understand. But to be honest I don't see why you should bother.
>If a player wishes to 'cheat' they will find ways. I would just let
>them. The fun of the game is not maxing out but to team up and
>struggle against overwhelming odds. Having a little program typing
>'hide' a thousand times is incredibly boring, and lame. But if that's
>what a player wants to do I'd say let them. And give them a sword of
>walk round the game, do anything they like and quickly leave for another
>one because yours has no challenge. Players who are interested in playing
>will stay and don't have to deal with all the time and effort you have
>put into foiling the spoilsports.
If someone really wants to steal your car, they'll find a way. Does
that mean that you shouldn't lock the doors and you should leave the
key in the ignition? After all, locking the doors and taking the
key away makes things harder for the legitimate users of the car.
In the same way as with the car, the fact that players will find ways
to cheat no matter how hard we make it doesn't mean that we shouldn't
try to make it hard. Making it reasonably difficult to cheat will
deter 90%+ of cheaters... just as locking your car doors and not
leaving the key with the car will deter 90%+ of would-be car thieves.
>>object/char pointers/addresses on muds. Consider picking locks: I
>>should memorize the last lock was picked and compare it with new
>>attempts, while apparaise should memorize the bunch of gold, or the
>>object was last appraised, and so on. This doesn't seem to be an easy
>>task, and also seems to be a bit heavy on memory/CUP time.
>
>Keep track for each skill what time at the earliest that skill can
>be considered for learning again. Or randomly select three skills
>that can improve (including skills that haven't been learned yet).
>Everytime a skill is changed it will be replaced by another one on
>that little list. Since everything is random no player can hope to
>achieve figuring out what skill to type, and they might as well go
>out and enjoy themselves in the world.
This is effectively the same as simply giving each skill a small
chance to go up when used, instead of letting them go up each time.
Consider:
Let's say the mud has 100 skills, and you randomly select three
that can improve. In that case, if you pick a skill at random,
there's a 3% chance that it can improve right then. Thus, we
can achieve the same effect simply by giving skills only a 3%
chance to go up when used... without having to keep track of
which three skills can improve right now.
>>This seems to be a good idea, but in the system I am considering
>>skills aren't trained with a master, they improve by use. So if
>>casting a fireball requires 'create fire' and 'control file', those
>>skills should be learned by trying to cast fireballs. Also nothing
>>denies the player from repeating skills that improve 'create fire'
>>first, and then skills that require 'control fire' later...
>
>That's the idea indeed. Of course as they no longer 'practice' the
>fairly useless skill 'create fire' (I mean, which powerhungry player
>is going to bother with a spell that can light a candle, or put a
>bit of kindle to fire?) This skill degenerates, and because of that
>their fireball skill fades too. There's no need to -tell- the
>players any of that, and if they figure out they still have to spent
>all that time keeping their minor skills at adept level.
This is something that many people seem to have a hard time grasping;
the difference between skills and commands, or between skills and
spells. A fireball spell consists of the *application* of several
skills: create fire, move fire, shape fire, and possibly some
sort of targetting skill.
Someone who's using fireball *is* practicing the skill of "create
fire"; if he/she doesn't create that fire, where's it coming from?
To put it another way, if I go around igniting bonfires with magic,
is it reasonable to assume that I'm going to get worse at it
because I'm not lighting candles anymore? It might be reasonable
to say that I'll get worse at targetting, since a pile of wood for
a bonfire is easier to "hit" than a candle wick, but I don't think
that my ability to create fire is going to suffer.
>Most skill-based systems require the transfer of some kind of
>knowledge, either through a teacher, sage, guildmaster or tome of
>knowledge before a skill can be trained. This is to lock powerfull
>skills away from the low level players. Of course there needn't be
>levels but at least a player should be able to outclass a certain
>degree of monsters before being able to learn more advanced skills.
>Such systems work well with a 'tree of knowledge' <love that little pun>
That is, with a system of skill prerequisites. There are several
different kinds of skill "trees."
Marco Braga
On 21 Jul 1996 15:39:45 +0200, gry...@IAEhv.nl wrote:
>If a player wishes to 'cheat' they will find ways. I would just let
>them. The fun of the game is not maxing out but to team up and
>struggle against overwhelming odds. Having a little program typing
>'hide' a thousand times is incredibly boring, and lame. But if that's
>what a player wants to do I'd say let them.
[snip]
> Players who are interested in playing
>will stay and don't have to deal with all the time and effort you have
>put into foiling the spoilsports.
Yes, perhaps you're right. Unfortunatedly there is a part of them that
loves becoming a walking tank and still they would spend their entire
life just looping through mobs. Btw, I'll follow your advice: I'll not
concentrate on spoiling cheats, I'll work to create a good system.
>Keep track for each skill what time at the earliest that skill can
>be considered for learning again.
That's what I'll do, but even this isn't very cheap in memory: 300
skills * 4 bytes (size of an int) will take 12K per char... But
perhaps this will be useless. In the system I am working on skills
don't just go up on each use, but difficulty is considered. So for
example to learn something you must repeat the skill on a considerable
target not just on any target. Also spells will need components, and
all this should make repetition not very easy.
>Most skill-based systems require the transfer of some kind of
>knowledge, either through a teacher, sage, guildmaster or tome of
>knowledge before a skill can be trained. This is to lock powerfull
>skills away from the low level players. Of course there needn't be
>levels but at least a player should be able to outclass a certain
>degree of monsters before being able to learn more advanced skills.
That's again another good idea, since teachers will cost gold and
tomes won't be common to find.
Btw, I reapeat a question I asked some time ago, hoping someone will
reply. Since I must balance the system, I need some data. My question
is: how many hours of play takes on average muds to reach max level,
or to become a master in a skill? 200 hours? 1000?
Raph Koster
Orion Henry wrote:
>...(witness Legend MUD)...
OK, by my count, LegendMUD has now come up at least a half-dozen times
in the "Skill based systems", "Realism and Roleplaying", "Call for MUD
evolution", and "Best mud features" threads. What's the deal? ;)
-Ptah@LegendMUD
http://mud.aus.sig.net
mud.aus.sig.net 9999
Orion Henry
>> These are kind of bad examples, I think, because I doubt anyone has
>> plans to implement history or physics as skills on a MUD. :)
>
>btw, "applied history" is connecting the information from "theoretical
>history" into a useful model that helps you understand what's happened,
>what's happening, and what's going to happen.
It's not that that I'm arguing, really. It's more the "in practice"
kind of thing that I'm talking about, and the connection between
player and character. I don't want to wax philosophical about this
(which I tend to do in this sort of discussion), so I'll try to keep
it specific to the topic.
The fundamental difference between knowledge and skills, IMO, is
just that skills are something learnable only by practice, whereas
knowledge can be gleaned from a book. The overlap a little bit -
knowledge is certainly very useful in certain skills, and certain
skills help one aquire and retain knowledge faster and longer.
Since these skills are just represented by a couple numbers, it's
not really sufficient to model the fact that one historian knows
that Aegis-fang was created by Bruenor Battlehammer, but doesn't
know anything about the creation of Anduril, Flame of the West. The
second historian knows that Anduril, Flame of the West was created
from the fragments of Narsil, the Sword Which was Broken, but is
at a loss when his friend brings up Aegis-fang. This can depend on
a lot of things, not the least of which are where they studied, what
resources they had access to, what teachers they had, where their
own beliefs about important facts and unimportant ones lie, and so
on. Unless you want to create a "skill" for each piece of
information related to any given topic, MUD "skills" really aren't
good enough for this.
On top of all this, it's kind of nullified by the fact that I can
make a historian, find all this shit out, then when I'm playing my
troll warrior with the 2 int I still "know" it all. Even if I can't
use the "identify" skill on that rune-covered warhammer I found when
raiding Mithril Hall, my previous knowledge tells me that it's
Aegis-fang.
So I guess it's just me - things like this bother me, in the same
way that not being able to attack objects or getting messages like
"you can't go that way" bother me. On Lost Souls you guys also nuke
any objects in the "temporary" rooms of the big map as soon as you
leave the room - although I can totally understand why you would do
this, it is inexcusable from the context of making a realistic MUD,
in my mind. So by the same token, having a single number which
tells me how much my character "knows" about something seems to me a
gross oversimplification. It makes more sense to me for "doable"
skills, since most of these only come from practicing the same basic
stuff over and over until it's perfect.
Travis S Casey
Matthew R. Sheahan <ch...@crystal.palace.net> wrote:
>Orion Henry (ohe...@sdcc10.ucsd.edu) wrote:
>> These are kind of bad examples, I think, because I doubt anyone has
>> plans to implement history or physics as skills on a MUD. :)
>
>
>btw, "applied history" is connecting the information from "theoretical
>history" into a useful model that helps you understand what's happened,
>what's happening, and what's going to happen.
Nope. Understanding what has happened can be considered to simply be
knowledge, since it can't be applied (except as it helps you with what
is happening or will happen, but you mentioned those separately).
Understanding what is or what will happen requires the application
of other skills, which in turn draw on your knowledge of history:
for example, sociology or politics. That is, you don't directly
apply your knowledge of history to the problem; you use that knowledge
to help you in your use of another skill. The practice of doing
this is called "applied history"; however, that doesn't mean that
applied history has to exist as a skill.
To use another example, the use of mathematics to do something can
be called "applied mathematics." However, it can also be called
something else depending on the problem domain: for example,
physics is one application of mathematics.
The best way, IMHO, to represent these things is to do two things:
1 - Allow skills to have prerequisites. For example, physics
could have a prerequisite of mathematics--you're never going
to learn much in the way of useful physics without knowing
some math.
2 - Allow multiple skills to be applied to an action. For example,
if a character finds a magical sword which has orcish runes
on the hilt, his/her skills in magic, history, and reading
orcish could all be used to help decide if he/she can identify
it.
Travis S Casey
In article <4t2rtp$h...@sdcc12.ucsd.edu>,
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>>> These are kind of bad examples, I think, because I doubt anyone has
>>> plans to implement history or physics as skills on a MUD. :)
>The fundamental difference between knowledge and skills, IMO, is
>just that skills are something learnable only by practice, whereas
>knowledge can be gleaned from a book. The overlap a little bit -
>knowledge is certainly very useful in certain skills, and certain
>skills help one aquire and retain knowledge faster and longer.
One question, however, is what has to be done to practice
something. Mathematics, for example, can be practiced without
having to go anywhere; you can sit there with the book, some
paper, and a pencil and practice it. There are many other
skills which can be practiced without having to go anywhere.
There are also skills that merely need some equipment and
supplies to practice. I can practice lockpicking in my spare
time all I want; all I need is some picks and some locks to
work on.
>Since these skills are just represented by a couple numbers, it's
>not really sufficient to model the fact that one historian knows
>that Aegis-fang was created by Bruenor Battlehammer, but doesn't
>know anything about the creation of Anduril, Flame of the West. The
>second historian knows that Anduril, Flame of the West was created
>from the fragments of Narsil, the Sword Which was Broken, but is
>at a loss when his friend brings up Aegis-fang. This can depend on
>a lot of things, not the least of which are where they studied, what
>resources they had access to, what teachers they had, where their
>own beliefs about important facts and unimportant ones lie, and so
>on. Unless you want to create a "skill" for each piece of
>information related to any given topic, MUD "skills" really aren't
>good enough for this.
As they're traditionally implemented, no. However, it's perfectly
possible to implement something like this:
- Label each thing to which a skill might apply on the mud with
a unique label. For example, example, the lock to a certain
vault might be "banklock#322", and the knowledge of who created
Anduril might be "andurilfact#3".
- Now, whenever a skill is used on one of these things, store
what it is, whether or not it succeeded (and possibly by how
much), and what the player's skill level was then.
- If the skill should be applied to the same thing again, then
you can either let it automatically succeed or fail, or
adjust the chance of success or failure, depending on the
stored information.
Now, this probably isn't *practical* for any mud right now...
but it's certainly *possible*.
Indeed, there's a pencil-and-paper RPG which has something similar
as a rule: in Arduin, if a skill fails to do something, the player
will automatically fail on any further attempts until his/her skill
goes up, at which point it can be tried again. Similarly, if a
monster makes its saving throw against a magician's spell, it will
automatically make its saving throw every time that magician tries
that spell on it until the mage goes up a level.
Of course, this applies in reverse as well; if the orc fails its
saving throw, it won't get another one. In this case, it won't
get another one *ever*, since the mage's getting better shouldn't
make it harder for him/her to affect the orc.
On a mud, as I said above, it might be more practical to use
the data to calculate a modifier instead of allowing automatic
success or failure.
>On top of all this, it's kind of nullified by the fact that I can
>make a historian, find all this shit out, then when I'm playing my
>troll warrior with the 2 int I still "know" it all. Even if I can't
>use the "identify" skill on that rune-covered warhammer I found when
>raiding Mithril Hall, my previous knowledge tells me that it's
>Aegis-fang.
This is a problem with the player, not with the system. A player
who is using information that his/her character shouldn't have is
cheating, plain and simple.
There are possible ways around this... for example, if Aegis-fang
has certain special powers, they might not be usable unless the
character succeeds in identifying the item.
To use a different example, let's say that there's a wand that
throws fireballs in the room. The player knows from having run
a mage character through here what it is, and what the command
to use it is. His new character, however, won't be allowed to
use the command until and unless *that* character succeeds in
identifying the item.
Of course, this can't be applied universally. :-( In the end,
it's like any other form of cheating.... you can discourage it,
but you'll never stamp it out completely.
>So I guess it's just me - things like this bother me, in the same
>way that not being able to attack objects or getting messages like
>"you can't go that way" bother me. On Lost Souls you guys also nuke
>any objects in the "temporary" rooms of the big map as soon as you
>leave the room - although I can totally understand why you would do
>this, it is inexcusable from the context of making a realistic MUD,
>in my mind. So by the same token, having a single number which
>tells me how much my character "knows" about something seems to me a
>gross oversimplification. It makes more sense to me for "doable"
>skills, since most of these only come from practicing the same basic
>stuff over and over until it's perfect.
It is a gross oversimplification... however, it provides a way of
somewhat separating player knowledge and character knowledge, without
too much work on the part of the mud's coders and the mud. Improvement
is certainly possible... for one thing, skills can be broken up,
subskills can be created, and other things. I'm at work right now,
and I'm going out of town for a long weekend, but I'll be making
a post about ways to interrelate skills when I get back... :-)
Anthony C.
In article <4t5hi5$h...@news.fsu.edu>,:There are also skills that merely need some equipment and
:time all I want; all I need is some picks and some locks to
:work on.
Yeah, this is very true, so up to a certain point you will improve.
At your own pace this might take 6 months to get your skill up to a
certain level. But what if you had an instructor who could teach you?
Then you would certainly learn faster say 2 months. In addition there are
some locks that you might not be able to get your hands on - electronic
locks or some proprietary locks - and an instructor would provide the
instruction and materials to learn these advanced locks. So to simulate this
instruction needs to occur periodically - you practice on your own for
awhile and get better, but to attain the next "level" you need to do
specific research on your own or go to an instructor who charges you.
The advantage of learning on your own is its free, the disadvantage is
that it takes a lot more time without the aid of an instructor (your
character ages). The advantage of having an instructor is that you learn
more quickly, however the disadvantage isthat it costs money. So in a given
lifetime (assuming no deaging magic) a person who learns completely from
the guild can learn 10 skills to max, but a person who learns on his own
can only learn 2 skills to max. This is the beginnings of a balanced
system that I think makes sense and prevents players from improving
a skill all the way with a bot. There are other factors of course like
high levels of skills require high stats, you will never become a master
of lockpicking unless you also have a minimum level of dexterity. Someone
with a lot of money who can buy stats, pay for training etc could
max a character very fast, but isnt that like real life? :)
[misusing privileged info]
:This is a problem with the player, not with the system. A player
:who is using information that his/her character shouldn't have is
:cheating, plain and simple.
:
:There are possible ways around this... for example, if Aegis-fang
:has certain special powers, they might not be usable unless the
:character succeeds in identifying the item.
My solution to this is to not have a mud that has areas that repop, I have
always thought that was kind of stupid anyway. There is no way you can
stop the solutions from getting out, so why even try? For me making a mud
is like being a DM, you dont try to force your players into specific plots
and stories that you have written (i.e. like most muds) what you do do is
create an interesting and rich world that allows the players to interact
with each other and the world and occassionally add disturbances that
create conflict. Creating simple goals is much more entertaining than
a long chained thread.
For example the rumor is the Giants have a sword which is good for slaying
dragons, the dragons want this sword and will pay a lot for it. However
the Orcs also want the sword. Each nation is offering money to players for
getting the sword.. So then the players invade the giant kingdom searching
for the sword, following clues that have been placed around. The sword
might be found right away, or it may never be found. Once it is found though
one group of players may attack another group to get the sword for their
"side". Someone may end up with the sword, or maybe the dragons get it
and then send players out to have it destroyed. Regardless, there is
no specific sequence that has to be followed. Maybe the sword doesnt
even exist.. Scenarios could be murder mysteries, i.e. some PC kills
the store proprietor, the DM can then create some NPCs that happened to
see a person leaving, fitting a general description. Maybe there are some
clues... maybe the murder is never solved :). These are the things that
I think would makea good game..
--
Anthony C.
Chris Lawrence (Contra)
Travis S Casey (ca...@mu.cs.fsu.edu) wrote:
: In article <4t2rtp$h...@sdcc12.ucsd.edu>,
: Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
: >On top of all this, it's kind of nullified by the fact that I can
: >make a historian, find all this shit out, then when I'm playing my
: >troll warrior with the 2 int I still "know" it all. Even if I can't
: >use the "identify" skill on that rune-covered warhammer I found when
: >raiding Mithril Hall, my previous knowledge tells me that it's
: >Aegis-fang.
: This is a problem with the player, not with the system. A player
: who is using information that his/her character shouldn't have is
: cheating, plain and simple.
While this impacts the design of the game and RPGing heavily, I don't
feel that it is the job of the game to attempt to control or limit
this sort of cross-fertilisation. Rather it should be expected and
used as anormal course of events -- it is unpreventable after all.
This harks back to previous articles of mine here, I think on this
thread, promoting the view of the player-characters as tempory bodies,
puppets if you will, for the player behind them. Think of it as
role-playing a god or minor deity.
: There are possible ways around this... for example, if Aegis-fang
: has certain special powers, they might not be usable unless the
: character succeeds in identifying the item.
Trick, nasty, and requires state variables to be maintained all /over/
the place. Unghh.
: To use a different example, let's say that there's a wand that
: throws fireballs in the room. The player knows from having run
: a mage character through here what it is, and what the command
: to use it is. His new character, however, won't be allowed to
: use the command until and unless *that* character succeeds in
: identifying the item.
It would be easier to make the spell command different dependant on
who cast it, possibly even dependant on the name of the player casting
the spell. No state variables etc etc etc yada yada, very clean and
simple, only minor computation required.
: Of course, this can't be applied universally. :-( In the end,
: it's like any other form of cheating.... you can discourage it,
: but you'll never stamp it out completely.
Precisely, which is why I propose folding it into the worldview of the
game.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
gry...@iaehv.nl
In article <31f5204d...@nntpserver.vol.it>,
Marco Braga <bra...@mbox.vol.it> wrote:
>Btw, I reapeat a question I asked some time ago, hoping someone will
>reply. Since I must balance the system, I need some data. My question
>is: how many hours of play takes on average muds to reach max level,
>or to become a master in a skill? 200 hours? 1000?
I think that on the average diku you'll spent something between
200 and 400 hours to reach max level. Depending how 'tough' the
monsters are and how well you know the mud. On such diku's you can
max out a skill in about 10 mins (providing you have 18 for int)
I think that about 30 to 60 mins playing time to get reasonably
adept in a skill is acceptable to give players a sense of improvement
for the time they'll be able to spent on the game (on average).
That is if the player can concentrate on just improving a single
skill. If thats' not possible it should take that time to grow
so much better that something you could barely defeat when you
started playing becomes something you can tackle reasonably confident
after about an hour.
All this of course means that your game shouldn't have an excess
of levels.
Marian
Brandon Joseph Rickman
I have been analyzing the various approaches used in MU*s and suggested here
for skill based systems. I believe that the goal of skill based gaming is not
to accurately model reality but to achieve some degree of complexity that does
a good job of emulating/replacing reality. With that in mind here is a quick
breakdown of how skill systems could work:
-- When do skills increase?
Player controlled (standard): Players select which stats/skills to improve and
artificially train/practice.
- Pro: Instant gratification.
- Con: Players tend to emphasize combat skills and can train skills they've
never used. Requires some sort of xp/reward system.
Per session: After each successful use[/combat session/campaign] all applied
skills are [randomly] rolled for improvements.
- Pro: Improvements are limited to character's actions.
- Con: Does not account for frivolous skill attempts (hiding in empty rooms,
&c).
Minimum time increase: Skills can only improve every so often.
- Pro: Discourages players from repetitive actions (a favored client tactic).
- Con: Requires more careful game balance.
Streamed increases: Skill improvements are delayed over time, e.g. character
can increase at most one skill per game hour, extras skill increases are
deferred.
- Pro: Prevents tanking and client abuse. Allows more interesting integration
of "intelligence" attributes. Promotes character downtime.
- Con: Difficult to implement. May frustrate character development. Requires
more careful game balance.
-- What skills can increase?
Jack-of-all-trades: Character can learn any skill at any time. If there are
too few skills or they are too general high level characters start to look
very similar.
Chargen controlled: Player selects all possible character skills at generation.
Some skills are not available until a certain level is reached. Characters can
never learn new skills.
Guild/class controlled: Available skills depend on a character's current
profession, which may change. When character changes guild/class, some skills
may be lost.
Dependent skills: Skill A can only increase relative to skill B. There are
a variety of implementations:
- "mudslide" skills - Character must have a minimum skill in Earth Magick and
Water Magick to start learning the mudslide spell.
- trickle down - Skill in a general category allows skill in a specific area.
Fire Magick allows the fireball spell.
- trickle up - Skill in specific areas allow skill in a general category.
Skills in epee combat and sabre combat increase fencing skill.
-- Slope of skill increases:
This gets a little mathematical but I hope it is easy enough to understand.
Given that it is desirable for character skills to increase, what should the
rate of increase be over time? Basically, take the derivative of the skill
function.
Linear improvements: Skills increase at a constant rate (per use/per xp).
Skills checks are quick. We can dampen higher skills with a log curve. This
is effectively how most MU*s implement stats and leveling (to go from 1 to 2
you need the same xp as twice from 0 to 1).
Less than linear: Skill increases become more difficult as skills get
higher. Almost, but not quite, the same as using a dampening curve with
linear improvements, because skill improvements will gradually become less
frequent but could occur more often.
{Explanatory diversion: For linear improvements, assume a skill's chance to
increase is 1 out of 3. With the dampening curve each increase has a smaller
effect, so in this example let it take 3 improvements to effectively improve
the skill. After using the skill 3 times we have a 1/27 chance that the skill
has "gone up".
For a less than linear curve we can duplicate this 1/27 chance by making the
chance 1 out of 81. After 3 tries we have 3/81 or 1/27 chance of any
improvement, _but_ there is a [tiny] chance that the skill has actually
increased by 2 or even 3 (chance: 1/81 * 1/243 * 1/729 = 1/3^15).
End of diversion}
sawtooth: Skills increase at some rate, then suddenly stall.
This is how the improvement curves tend to work on a lot of MU*s. Certain
levels are comparably more difficult than previous and subsequent levels. This
is usually the fault of unbalanced zones, e.g. you can play in a newbie zone
until level 6, then you have to play in the level 6-10 zones which are too
difficult and/or continually depleted.
1 + cos x: Skills improve slowly, then quickly, in a cycle. Skills
will reach local plateaus followed by dramatic increases. Currently my
favorite skill curve is something like 2 * ln ( (sin(2x) + 2x) / 2) ^ 2 (the
derivative is left as an exercise for the reader). This has plenty of nice
bumps and includes the mandatory natural log.
------
There are many combinations and variations of the above. I would love to hear
of any unique systems.
- Brandon as...@oxy.edu
My newsfeed is terrible, email if you want a quick reply.
Visit the Plastic Mud Index: http://www.zennet.com/pub/plastic/mud/
gry...@iaehv.nl
In article <4t0070$p...@news.fsu.edu>,
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
><gry...@IAEhv.nl> wrote:
|>I understand. But to be honest I don't see why you should bother.
|>If a player wishes to 'cheat' they will find ways. I would just let
|>them. The fun of the game is not maxing out but to team up and
|>struggle against overwhelming odds. Having a little program typing
|>'hide' a thousand times is incredibly boring, and lame. But if that's
|>what a player wants to do I'd say let them. And give them a sword of
|>ultimate destruction (+100 +100 -500AC) to boot. That way they can
|>walk round the game, do anything they like and quickly leave for another
|>one because yours has no challenge. Players who are interested in playing
|>will stay and don't have to deal with all the time and effort you have
|>put into foiling the spoilsports.
>If someone really wants to steal your car, they'll find a way. Does
>that mean that you shouldn't lock the doors and you should leave the
>key in the ignition? After all, locking the doors and taking the
>key away makes things harder for the legitimate users of the car.
>
>In the same way as with the car, the fact that players will find ways
>to cheat no matter how hard we make it doesn't mean that we shouldn't
>try to make it hard. Making it reasonably difficult to cheat will
>deter 90%+ of cheaters... just as locking your car doors and not
>leaving the key with the car will deter 90%+ of would-be car thieves.
I don't understand your analogy. What I was trying to say is that if a
player wants to be a lame type who wants all the power without the fun
of earning it why not hand it out and spoil the rest of the fun?
Nothing worse than being immortal without immortal abilities or
responsibilities. Especially if the -real- imms are constantely looking
over you shoulder to see if you don't break the rules.
That's not the same as allowing your car to be stolen. It merely
drives home the point that playing a mud isn't necessarily about
getting all powerfull.
|>Keep track for each skill what time at the earliest that skill can
|>be considered for learning again. Or randomly select three skills
|>that can improve (including skills that haven't been learned yet).
|>Everytime a skill is changed it will be replaced by another one on
|>that little list. Since everything is random no player can hope to
|>achieve figuring out what skill to type, and they might as well go
|>out and enjoy themselves in the world.
>
>This is effectively the same as simply giving each skill a small
>chance to go up when used, instead of letting them go up each time.
No it most definitely is not the same.
>Consider:
> Let's say the mud has 100 skills, and you randomly select three
> that can improve. In that case, if you pick a skill at random,
> there's a 3% chance that it can improve right then. Thus, we
> can achieve the same effect simply by giving skills only a 3%
> chance to go up when used... without having to keep track of
> which three skills can improve right now.
Actually only those three (or five or ten) skills have a chance to
improve, and not until either of them actually improves through use
will there be a chance for another skill to improve. This means you
can practice pick lock till you're blue in the face but if it isn't on
that list you won't improve it. And there's no telling whether it is
or is not on that list, other than by using the skill.
Marian
Travis S Casey
>>that mean that you shouldn't lock the doors and you should leave the
>>key in the ignition? After all, locking the doors and taking the
>>key away makes things harder for the legitimate users of the car.
>>
>>In the same way as with the car, the fact that players will find ways
>>to cheat no matter how hard we make it doesn't mean that we shouldn't
>>try to make it hard. Making it reasonably difficult to cheat will
>>deter 90%+ of cheaters... just as locking your car doors and not
>>leaving the key with the car will deter 90%+ of would-be car thieves.
>
>player wants to be a lame type who wants all the power without the fun
>of earning it why not hand it out and spoil the rest of the fun?
>Nothing worse than being immortal without immortal abilities or
>responsibilities. Especially if the -real- imms are constantely looking
>over you shoulder to see if you don't break the rules.
However, allowing the players who wish to gain power quickly to
do so may spoil the game for other players, especially if the
player then uses the power he/she's gained to do nasty things
to other players.
When I mud, I try to do things on the basis of what I think my character
would do... not on the basis of what I think will give me the most
benefit. I most especially do not take advantage of bugs that allow
my character to do things he/she shouldn't be able to do. When other
people do these things, I don't like it. It's no fun to see other players
zoom up ten levels in a day doing things that you consider to be
cheating.
I know... it's my fault. I can do the same things they can, if I
want to. However, while I may have to put up with it on other muds,
I don't have to allow this kind of thing to happen on a mud I run.
>That's not the same as allowing your car to be stolen. It merely
>drives home the point that playing a mud isn't necessarily about
>getting all powerfull.
To some people, that is the the point of playing a mud.
Also, I didn't say that it was the same as allowing your car to
be stolen; an analogy is not an identity.
>|>Keep track for each skill what time at the earliest that skill can
>|>be considered for learning again. Or randomly select three skills
>|>that can improve (including skills that haven't been learned yet).
>|>Everytime a skill is changed it will be replaced by another one on
>|>that little list. Since everything is random no player can hope to
>|>achieve figuring out what skill to type, and they might as well go
>|>out and enjoy themselves in the world.
>>
>>This is effectively the same as simply giving each skill a small
>>chance to go up when used, instead of letting them go up each time.
>
>No it most definitely is not the same.
Whoops... you're right in your assessment of my example. I forgot
that the list of usable skills will only change when one of them
is upped.
However, this brings in more problems... what if the list of
skills that can go up right now includes one or more skills that
the character can't or won't use? For example, let's say that I'm
trying to play an honorable thief (i.e., a Robin Hood type of
thief). Now, "backstab" might be one of the skills that's on the
list of ones that I can improve right now... but if that happens,
then it's never going to come *off* the list, because I'm never
going to use it.
IMHO, the system you've come up with punishes players for playing
in character... which is not something that I want to do.
gry...@iaehv.nl
In article <4t5aut$d...@news.fsu.edu>,
Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>However, allowing the players who wish to gain power quickly to
>do so may spoil the game for other players, especially if the
>player then uses the power he/she's gained to do nasty things
>to other players.
That's true, but not terribly relevant. Players that want to harass
others will do so regardless of their power (not entirely tru but it's
close enough). If a high level player does something then you could
allways kick him or her off.
Mind I'm not saying you -should- allow let alone encourage cheating,
merely that it is't the end of the world game-wise. If you ensure that
cheating leads to a boring game, and concentrate on making the game
interesting for those that follow the rules only, then I think you
won't have anunmanageable problem.
|>Keep track for each skill what time at the earliest that skill can
|>be considered for learning again. Or randomly select three skills
|>that can improve (including skills that haven't been learned yet).
|>Everytime a skill is changed it will be replaced by another one on
|>that little list. Since everything is random no player can hope to
|>achieve figuring out what skill to type, and they might as well go
|>out and enjoy themselves in the world.
>However, this brings in more problems... what if the list of
>skills that can go up right now includes one or more skills that
>the character can't or won't use? For example, let's say that I'm
>trying to play an honorable thief (i.e., a Robin Hood type of
>thief). Now, "backstab" might be one of the skills that's on the
>list of ones that I can improve right now... but if that happens,
>then it's never going to come *off* the list, because I'm never
>going to use it.
hmm. you're right. This might happen and it would be a problem.
I guess there would be easy ways around this though. Like resetting
the list at connect time (e.g. every time a player enter the game or is
killed by something big and nasty?) If the players never get told what
skills they could improve it would prevent this problem to a large
extent I think. Also the number of skills that can be improved might
need some carefull adjustment for this to work.
Of course it's only an idea for a way how you can make certain that
repeatedly practicing the same skill for hours isn't going to do
any good to a player. And at the same time foil other clver ways to
trick the system.
Marian
Travis S Casey
>
>: >On top of all this, it's kind of nullified by the fact that I can
>: >make a historian, find all this shit out, then when I'm playing my
>: >troll warrior with the 2 int I still "know" it all. Even if I can't
>: >use the "identify" skill on that rune-covered warhammer I found when
>: >raiding Mithril Hall, my previous knowledge tells me that it's
>: >Aegis-fang.
>
>: This is a problem with the player, not with the system. A player
>: who is using information that his/her character shouldn't have is
>: cheating, plain and simple.
>
>feel that it is the job of the game to attempt to control or limit
>this sort of cross-fertilisation. Rather it should be expected and
>used as anormal course of events -- it is unpreventable after all.
>
>This harks back to previous articles of mine here, I think on this
>thread, promoting the view of the player-characters as tempory bodies,
>puppets if you will, for the player behind them. Think of it as
>role-playing a god or minor deity.
That's fine, if you want to build your world around that view.
Personally, I don't want to. :-)
I don't think there's a right or wrong stance here; whether or
not players should be able to let their knowledge "filter over"
to characters is a matter of personal taste.
>: There are possible ways around this... for example, if Aegis-fang
>: has certain special powers, they might not be usable unless the
>: character succeeds in identifying the item.
>
>Trick, nasty, and requires state variables to be maintained all /over/
>the place. Unghh.
Well, that depends on how many such special items you have. Also,
I don't think that it's tricky or nasty to do at all... I've done
it several times on different muds. The storage required is the
only bad part, really.
Now, just to be clear, I'm not advocating this as a general thing:
I'm just pointing out that there *are* ways to limit how much
knowledge players can "carry over" to another character.
>: To use a different example, let's say that there's a wand that
>: throws fireballs in the room. The player knows from having run
>: a mage character through here what it is, and what the command
>: to use it is. His new character, however, won't be allowed to
>: use the command until and unless *that* character succeeds in
>: identifying the item.
>
>It would be easier to make the spell command different dependant on
>who cast it, possibly even dependant on the name of the player casting
>the spell. No state variables etc etc etc yada yada, very clean and
>simple, only minor computation required.
A better solution than either of these just occured to me; make
the command be random, but choose it at the time the item is
created. This way, the player still can't use the item the first
time without identifying it, but afterwards, he/she can tell the
command to others--equivalent to showing them how the wand works.
>: Of course, this can't be applied universally. :-( In the end,
>: it's like any other form of cheating.... you can discourage it,
>: but you'll never stamp it out completely.
>
>Precisely, which is why I propose folding it into the worldview of the
>game.
As stated above, however, that requires that you be willing to
work with such a worldview.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Administrator, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-7339; Room 011 Love
mor...@niuhep.physics.niu.edu
>: Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>
>: >On top of all this, it's kind of nullified by the fact that I can
>: >make a historian, find all this shit out, then when I'm playing my
>: >troll warrior with the 2 int I still "know" it all. Even if I can't
>: >use the "identify" skill on that rune-covered warhammer I found when
>: >raiding Mithril Hall, my previous knowledge tells me that it's
>: >Aegis-fang.
>
>: This is a problem with the player, not with the system. A player
>: who is using information that his/her character shouldn't have is
>: cheating, plain and simple.
>
>feel that it is the job of the game to attempt to control or limit
>this sort of cross-fertilisation. Rather it should be expected and
>used as anormal course of events -- it is unpreventable after all.
to a certain extent...
>This harks back to previous articles of mine here, I think on this
>thread, promoting the view of the player-characters as tempory bodies,
>puppets if you will, for the player behind them. Think of it as
>role-playing a god or minor deity.
interesting
>: There are possible ways around this... for example, if Aegis-fang
>: has certain special powers, they might not be usable unless the
>: character succeeds in identifying the item.
>Trick, nasty, and requires state variables to be maintained all /over/
>the place. Unghh.
why?
If it has powers either anybody who picks it up will be affected
or they need to be activated. If they need to be activated then
one needs to identify the object.
If char(wielder).identify(Aegis-fang) = true
Then
damage := damage + 5;
...
Endif;
That needs to be run each time you wield the weapon but...
>: to use it is. His new character, however, won't be allowed to
>: use the command until and unless *that* character succeeds in
>: identifying the item.
>
>It would be easier to make the spell command different dependant on
>who cast it, possibly even dependant on the name of the player casting
>the spell. No state variables etc etc etc yada yada, very clean and
>simple, only minor computation required.
I don't see the big difference.
Clearly an experienced Atman will know where things are. To some extent
this is reasonable, for whatever reason the character has heard more
rumors... and this doesn't really upset play balance that much. But
for powerfull items I think needing to identify them may be a useful
idea.
>Precisely, which is why I propose folding it into the worldview of the
>game.
That is one answer.
>J C Lawrence Internet: co...@ibm.net
Robert
mr. dert,,,,
In article <4t89a7$c...@news.fsu.edu>, Travis S Casey wrote:
>A better solution than either of these just occured to me; make
>the command be random, but choose it at the time the item is
>created. This way, the player still can't use the item the first
>time without identifying it, but afterwards, he/she can tell the
>command to others--equivalent to showing them how the wand works.
this doesn't prevent "knowledge carry-over", and you better code out
global communication:
dert gossips, 'whats the command for the flamin wand with lil balls on it?'
smarty-pants gossips, 'tyuio'
on a similar topic, if you choose to base your spell-knowledge on an
encryption system, i suggest using the player id as a key. if you use the
name, a player could create a spell-caster named dert, find all the spells
with that character, then recreate the character as a warrior and use all
the spells. i only bring this up because i exploited it on a mud recently.
to discourage the player from using a client to find all the spells (as i
did) it might be better to provide a method for finding spells without
trial and error.
most cheaters dont cheat unless they have a need. (i no i dont)
-dert
Matthew R. Sheahan
Orion Henry (ohe...@sdcc10.ucsd.edu) wrote:
> Since these skills are just represented by a couple numbers, it's
> not really sufficient to model the fact that one historian knows
> that Aegis-fang was created by Bruenor Battlehammer, but doesn't
> know anything about the creation of Anduril, Flame of the West.
yep, a single MUD skill is useless for modelling different spheres of
knowledge. i don't think it needs to; for one thing, unlike the case
the real world, we have access to a one true model of history (whatever
the designers decide upon), and we can say without being entirely
specious that anyone with a given quantified degree of familiarity with
the overall history of the world would know about such-and-such. this
is just a flimsy rationalization, of course. the real basis of using it
is that it enhances versimilitude enough to be worthwhile.
that said, Lost Souls is 100% capable of modelling the situation above
through its item identification mechanics, which is actually just a
topic-based rather than overall-rating-based knowledge modelling system.
the introduction mechanics from Genesis could likely be adapted to the
same end without much travail.
> On top of all this, it's kind of nullified by the fact that I can
> make a historian, find all this shit out, then when I'm playing my
> troll warrior with the 2 int I still "know" it all. Even if I can't
well, certainly. out of character knowledge cannot be avoided. but i
don't think throwing up one's hands at the concept of modelling character
knowledge is the appropriate response.
again, unlike the case in the real world, we can be quite certain that
characters are influenced by the presence of an external animating
intelligence that is persistent beyond their destruction and is often
reincarnated. this intelligence may direct the character to do things
which seem inexplicable to it due to its separate drives and stores of
knowledge. that's okay. the character is only responsible for reporting
what _it_ knows; what's done with it by the ghost in the machine is out
of its hands.
this is the actual relationship between player and character, and it
is probably best to recognize it as the baseline, whatever your goals.
a good role-player, of course, will attempt to model a more closely
identified relationship than this, but this can only take place as an
entirely elective process; it's barely relevant to coding rather than
social issues.
> So I guess it's just me - things like this bother me, in the same
> way that not being able to attack objects or getting messages like
> "you can't go that way" bother me.
hmm. what are you proposing to see rather than "you can't go that way"?
> On Lost Souls you guys also nuke
> any objects in the "temporary" rooms of the big map as soon as you
> leave the room - although I can totally understand why you would do
> this, it is inexcusable from the context of making a realistic MUD,
> in my mind.
yeah, well. i fixed a large memory leak the other day, so maybe we'll
be able to afford to lighten up on that behavior a bit.
besides, name me another MUD where you can whack off someone's arm,
pick it up, and beat them to death with it. hah.
> So by the same token, having a single number which
> tells me how much my character "knows" about something seems to me a
> gross oversimplification.
to put it kindly, if you don't like gross oversimplifications, you're in
the wrong neighborhood. we only have one model of the universe available,
and it's actual size. if you want more from a game than to provide a
decent feel to a character aspect which holds some reasonable analogy to
what we smirkingly call "reality", you're going to design some very RAM
abusive mudlibs someday.
if not being able to model something with total "realistic" precision
(realism is nothing; consistency is what matters) were a good reason not
to do it, we all would've packed up a long time ago.
chiaroscuro
mor...@niuhep.physics.niu.edu
Why did you feel you needed to in the above example?
I know I have been harassed when I simply gave clues (and damned obvious
ones to my way of thinking) instead of spelling out how to do something.
Robert
>-dert
>
Orion Henry
[a bunch of knowledge stuff deleted, didn't have anything
enlightning to say about it]
>> So I guess it's just me - things like this bother me, in the same
>> way that not being able to attack objects or getting messages like
>> "you can't go that way" bother me.
>
>hmm. what are you proposing to see rather than "you can't go that way"?
Something like, "A brick wall blocks the way north." Naturally you
can attempt to climb said wall. It just bugs me when I'm on a
forest path, "surrounded by forest" yet I can only go two
directions.
>> On Lost Souls you guys also nuke
>> any objects in the "temporary" rooms of the big map as soon as you
>> leave the room - although I can totally understand why you would do
>> this, it is inexcusable from the context of making a realistic MUD,
>> in my mind.
>
>yeah, well. i fixed a large memory leak the other day, so maybe we'll
>be able to afford to lighten up on that behavior a bit.
Nod. I wasn't trying to pick on Lost Souls specifically, it's just
that we were discussing a (hypothetical) MUD where everything would
behave in a more or less realistic manner before you chimed in about
the knowledge skills. Such a thing as exits which don't lead back
to themselves or objects which go someplace without being
specifically affected by something (like someone picking them up)
would be completely out of place.
>besides, name me another MUD where you can whack off someone's arm,
>pick it up, and beat them to death with it. hah.
This sort of thing would be mandatory for any MUD which claimed to
be realistic. _Any_ item should be usable as a weapon. Not because
this is necessarily a useful or necessary feature, but because
getting messages like "you can't wield that" makes no sense.
>> So by the same token, having a single number which
>> tells me how much my character "knows" about something seems to me a
>> gross oversimplification.
>
>to put it kindly, if you don't like gross oversimplifications, you're in
>the wrong neighborhood.
Heh...well it's all relative. I guess what I meant is that compared
to the other skills, it's an oversimplification. I might be able to
stand it if the breakdown was something like "dwarven lore", "elven
lore", "ancient history", "recent history", etc...but even so, it
just bugs me on the concept level.
>we only have one model of the universe available,
>and it's actual size. if you want more from a game than to provide a
>decent feel to a character aspect which holds some reasonable analogy to
>what we smirkingly call "reality", you're going to design some very RAM
>abusive mudlibs someday.
Well, here's the way I see it. MUDs have always been coded with the
underlying premise that they're just games, and therefore should
just take up a small corner of some machine somewhere. I'm saying
that as processors have gotten faster, memory cheaper, and so on,
there's a lot of potential for stuff to do now that we couldn't have
done four years ago when stuff like LP and Diku were coming into
existance.
So, this whole thread has been basically with the premise of "What
is the next generation of MUDs? How can we make the experience more
enjoyable, enthralling, and (gods help us) adiciting?", keeping in
mind that we have far more resources availible to us than we did
four years ago.
>if not being able to model something with total "realistic" precision
>(realism is nothing; consistency is what matters) were a good reason not
>to do it, we all would've packed up a long time ago.
I guess I'm considering that realism is roughly equivilent to
consistency. Thus, I see the use of knowledge as skills to be
somewhat inconsistent, therefore unrealistic.
Orion Henry
[bunch of stuff about ways to learn skills]
>of lockpicking unless you also have a minimum level of dexterity. Someone
>with a lot of money who can buy stats, pay for training etc could
>max a character very fast, but isnt that like real life? :)
Not necessarily. I know plenty of yuppie-ass motherfuckers that get
"personal trainers" yet never get anywhere with their workout
routine, because they don't have the motivation, mindset, ability
etc. They've spent a huge amount of money and haven't gained much,
whereas the motivated guy with his $150 weight set who puts his all
into it gains far more.
My main problem with the ideas you're broaching here (training causes
aging, training is capped only by availible money) is that you're
looking at skills based on RL effects, rather than RL causes.
Modeling this way will take a lot of tweaking to get right, and if
you ever decide to add new elements to the system you will likely
have to screw with all the rest of the thing. With a cause-based
system, things will work together naturally without having to do
these artificial "features" (like the aging thing).
The other, more basic problem with using money is that it can be
easly transfered to newbies, thus a high level character can say
"let's make a gnome and see how high in skill x he can get" without
actually having to play the character.
>My solution to this is to not have a mud that has areas that repop, I have
>always thought that was kind of stupid anyway. There is no way you can
Repop is just overly simplified, to my mind - it should be more like
a "restocking phase" where there are no PCs anywhere near the zone,
and the MUD sort of figures out things that are "wrong" and need to
be fixed, like dead mobs and missing items. This needs to be much
more than standard repops - if the elite guard is missing his shield
he'll grab another, if the king is dead a new one (with a different
name) will appear, and if there are too few miners it will create a
few new miners. This also creates the need for simplified mob
blueprints whereby it can just make a generic king or guard or miner
for a given zone, then give him details (name/apperance/equipment)
that vary a bit to take away the unending sameness of it all.
>stop the solutions from getting out, so why even try? For me making a mud
>is like being a DM, you dont try to force your players into specific plots
>and stories that you have written (i.e. like most muds) what you do do is
>create an interesting and rich world that allows the players to interact
>with each other and the world and occassionally add disturbances that
>create conflict. Creating simple goals is much more entertaining than
>a long chained thread.
Yes, definitely. The fundamental difference between adventure games
(like single player RPGs on the computer) and multi-player
RP-worlds, like MUDs, is that they are composed of many simple
elements. What makes it interesting is the potentially infinite
number of ways those things can interact. On a stock diku, this is
rather simple - balancing out equipment from various zones to try to
get the best combination, grouping with different people, taking
different paths to reach zones, etc. On a really well-written mud
it involves combining two or more totally unrelated skills, places,
objects, spells, or whatever to come up with something that wasn't
necessarily "intended" by the creator(s) of said object/skills/whatever.
Thus if you wish to make a simple problem for players to overcome,
like getting past a certain mob, you shouldn't make only one
solution and make nothing else work. There should be many different
ways - sneaking by, killing him, befriending him so that he'll let
you pass, going invis and walking by, or whatever. If the MUD is
coded well, this shouldn't be difficult - just make a mob that blocks
passage of anyone who's not his friend and that he can see. If
someone adds a new skill/spell, like say blindness or dancing colors
(distracts target for a few moments) these should work just fine
without changing the zone or writing special code for that specific
mob.
>For example the rumor is the Giants have a sword which is good for slaying
>dragons, the dragons want this sword and will pay a lot for it. However
>the Orcs also want the sword. Each nation is offering money to players for
>getting the sword.. So then the players invade the giant kingdom searching
>for the sword, following clues that have been placed around. The sword
>might be found right away, or it may never be found. Once it is found though
>one group of players may attack another group to get the sword for their
>"side". Someone may end up with the sword, or maybe the dragons get it
>and then send players out to have it destroyed. Regardless, there is
>no specific sequence that has to be followed. Maybe the sword doesnt
>even exist.. Scenarios could be murder mysteries, i.e. some PC kills
>the store proprietor, the DM can then create some NPCs that happened to
>see a person leaving, fitting a general description. Maybe there are some
>clues... maybe the murder is never solved :). These are the things that
>I think would makea good game..
The most important thing to remember is that if you make a truely
vibrant world, you don't need to "make" storylines. Murders and
stealing will work themselves in just fine with playerkilling. All
you have to do is make that sword and stash it somewhere, and the
"storyline" will emerge on its own.
Orion Henry
>>...(witness Legend MUD)...
>
>OK, by my count, LegendMUD has now come up at least a half-dozen times
>in the "Skill based systems", "Realism and Roleplaying", "Call for MUD
>evolution", and "Best mud features" threads. What's the deal? ;)
I always try to mention real examples when talking about vague
concepts. Legend has the distinction of being a very different and
innovative diku MUD, something that is rarer to witness than I'd
really like. To be honest, I didn't like a lot of the ways Legend
did things, especially since I started playing almost immediately
after it first came up. Later on the system was a lot nicer and
more polished, but it's still not really my idea of what a realistic
skill-based system should be like. Still - you guys tried something
new and different, then stuck with it and tried to make it right.
In my opinion that makes Legend 1000% better than any "standard" MUD
out there, whether I like the MUD or not.
Orion Henry
[how difficult cheating should be]
>I don't understand your analogy. What I was trying to say is that if a
>player wants to be a lame type who wants all the power without the fun
Here's the main problem with that. There are many that would use
these shortcuts to make an awesome pkiller and then just cruise
around and make life misserable for all the real players. I know
this seems silly, but it would happen.
More than that, though, is that you take away from the sense of accomplishment
if players know they can just get better by shortcuts than by the
real playing. And any system where you type "#20 #20 hide" and
you're a master hider is a bad system, not because it allows
"cheating", but because it isn't realistic. You don't get better
at hiding by sitting in one place trying to find every nook and
cranny there is to hide in, you get better by learning how to
quickly melt into the shadows/surroundings in a variety of
situations and locations. If the system is designed this way, then
you don't really need to worry about "cheating" - it's already taken
care of.
mr. dert,,,,
In article <4tbh00$2...@corn.cso.niu.edu>, mor...@niuhep.physics.niu.edu wrote:
> de...@TS2-15.upenn.edu (mr. dert,,,,) writes:
>>on a similar topic, if you choose to base your spell-knowledge on an
>>encryption system, i suggest using the player id as a key. if you use the
>>name, a player could create a spell-caster named dert, find all the spells
>>with that character, then recreate the character as a warrior and use all
>>the spells. i only bring this up because i exploited it on a mud recently.
>>
>>to discourage the player from using a client to find all the spells (as i
>>did) it might be better to provide a method for finding spells without
>>trial and error.
>>
>>most cheaters dont cheat unless they have a need. (i no i dont)
>Why did you feel you needed to in the above example?
heh
my need is for accelerated leveling. i dont mud anymore except to steal
ideas. if i'm only gonna visit the mud to see what they have implemented,
i'll cheat cause its fun (and faster). i like finding bugs and exploiting
them. some muds are too boring to play for real, but if they have some
unique features, they are worth investigating.
>I know I have been harassed when I simply gave clues (and damned obvious
>ones to my way of thinking) instead of spelling out how to do something.
>Robert
um, ok. (?)
-dert
Travis S Casey
Brandon Joseph Rickman <as...@oxy.edu> wrote:
>I have been analyzing the various approaches used in MU*s and suggested here
>for skill based systems. I believe that the goal of skill based gaming is not
>to accurately model reality but to achieve some degree of complexity that does
>a good job of emulating/replacing reality. With that in mind here is a quick
>breakdown of how skill systems could work:
I'd have to disagree with you on the goal. IMHO, the primary goal
of skill-based systems is to allow for greater variance between different
characters. That is, rather than being able to describe most of what a
character can do with a word and a number (class and level), characters
can vary widely in many different skills.
>-- When do skills increase?
You seem to be covering several questions here:
- How do skills increase?
- When do skills increase?
- Are players allowed a choice in which skills to increase?
>Player controlled (standard): Players select which stats/skills to improve and
>artificially train/practice.
>- Pro: Instant gratification.
>- Con: Players tend to emphasize combat skills and can train skills they've
>never used. Requires some sort of xp/reward system.
Players tend to emphasize combat skills because those are the skills which
are of the greatest use in gaining XP on most muds. This can be changed.
Also, there's no reason why a player-controlled system *has* to allow
players to train skills they've never used--most do, but it's not an
intrinsic part of this system.
>Per session: After each successful use[/combat session/campaign] all applied
>skills are [randomly] rolled for improvements.
>- Pro: Improvements are limited to character's actions.
>- Con: Does not account for frivolous skill attempts (hiding in empty rooms,
>&c).
Frivolous skill attempts can be accounted for, for at least some skills.
>Minimum time increase: Skills can only improve every so often.
>- Pro: Discourages players from repetitive actions (a favored client tactic).
>- Con: Requires more careful game balance.
This is not actually a separate system; it's a modification of another
system. Thus far, it's only been proposed for use with the per session
system, but there's no reason it couldn't be used with a player-controlled
system.
I'm not sure what you're trying to get at with "requires more careful
game balance." Can you elaborate?
>Streamed increases: Skill improvements are delayed over time, e.g. character
>can increase at most one skill per game hour, extras skill increases are
>deferred.
>- Pro: Prevents tanking and client abuse. Allows more interesting integration
>of "intelligence" attributes. Promotes character downtime.
>- Con: Difficult to implement. May frustrate character development. Requires
>more careful game balance.
Intelligence attributes can also be used with the other systems; for
example, with minimum time increase, intelligence might determine
the time that has to elapse between successive improvements of a
given skill. With player-controlled increase, intelligence could
modify the number of experience points that a skill advancement
costs.
>-- What skills can increase?
Again, there are multiple questions here:
- What skills can be increased at a given time?
(i.e., What skills can Joe Character increase right this minute?)
- What skills can a character have?
(i.e., What are all the skills that Jane Character can ever have?)
- How are skills related?
(e.g., If Joe Character knows short sword, will that help him to
use or learn to use a long sword? If Jane Character wants to
learn Weaponsmithing, will she have to learn other skills first?)
I don't break this one down further because there are dozens of
ways, at least, in which skills can be related.
>Jack-of-all-trades: Character can learn any skill at any time. If there are
>too few skills or they are too general high level characters start to look
>very similar.
"Highly experienced characters" is probably a better description, since
skill-based systems may not have levels.
>Chargen controlled: Player selects all possible character skills at generation.
>Some skills are not available until a certain level is reached. Characters can
>never learn new skills.
Other possible variants of this one are many. For example, if you
still have levels, the character might be able to add one more skill
to the pool of possible skills per level.
>Guild/class controlled: Available skills depend on a character's current
>profession, which may change. When character changes guild/class, some skills
>may be lost.
Race controlled: Available skills depend on the character's race.
>Dependent skills: Skill A can only increase relative to skill B. There are
>a variety of implementations:
>
>- "mudslide" skills - Character must have a minimum skill in Earth Magick and
>Water Magick to start learning the mudslide spell.
This is a subtype of "trickle down" below; the only difference is that
more than one general skill may be necessary to allow learning a specific
skill.
Note also that each spell/command/etc. doesn't have to have its own
skill; thus, you might need a certain minimum skill in Earth and Water
Magic to use the mudslide spell, but there may not be a separate
"mudslide" skill.
>- trickle down - Skill in a general category allows skill in a specific area.
>Fire Magick allows the fireball spell.
Again, a spell may not be a skill. A better example might be: a
certain minimum skill in Blacksmithing might be needed before a
character can learn Armorsmithing. That is, you need to know something
about how to work hard metals in general before you can learn to make
metal armor.
>- trickle up - Skill in specific areas allow skill in a general category.
>Skills in epee combat and sabre combat increase fencing skill.
Combinatations of these are, of course, possible. For instance, a
mud might have some skills which can be learned by any character, some
skills which are restricted to certain guilds, and some skills which
are restricted to certain races.
>-- Slope of skill increases:
>
>This gets a little mathematical but I hope it is easy enough to understand.
>Given that it is desirable for character skills to increase, what should the
>rate of increase be over time? Basically, take the derivative of the skill
>function.
This section appears to be poorly thought-out; for example, logarithmic
scales are included under "linear improvement"; surely a logarithmic
increase is nonlinear?
Other sections should be added:
--Starting skills
What skills does the character have when he/she is first created?
--Skill use
How are skills used?
There are almost certainly other things that could be added; IMHO,
this should serve as a list of questions for mud designers to ask
themselves when building a skill system.
Raph Koster
Well, thanks. :) I posted under the "tennis" thread about some of the
things we are doing to revamp the system. It still will not be 'truly
realistic' in many of the ways that are discussed in this and other
threads, but as has also been discussed, realism isn't always the ideal
goal.
The new skill system will be more 'realistic' but more important than
realism is the possibilities it offers. Within individual rooms, I'd
argue that our writing is often far from realistic, but it is WAY above
the caliber of writing on most muds, and that makes it more immersive.
The magic system is internally consistent, but it does not go to the
extremes that I've sene posted here for the sake of realism. I'd prefer
to replace all instances of that word with words like 'consistency' and
'immersiveness' and 'flexibility'.
In any case, we certainly don't expect everyone to like Legend. Those
who are looking for a mud that really, honestly, truly, isn't like any
others out there, though, they might want to stop by. :)
-Ptah@LegendMUD
http://mud.aus.sig.net
telnet mud.aus.sig.net 9999
Raz
Hi again - long time no write =) Anyway...
It was all I could do to contain my excitement when Orion Henry wrote:
> >hmm. what are you proposing to see rather than "you can't go that way"?
> Something like, "A brick wall blocks the way north." Naturally you
> can attempt to climb said wall. It just bugs me when I'm on a
> forest path, "surrounded by forest" yet I can only go two
> directions.
I think you may *just* be reaching the boundaries of common sense here... =)
Is it not possible that even back when "You can't go that way" first graced
our screens, it was in some way a hint at the intelligent parsers we want to
use nowadays?
I mean, let's do it your way:
>n
A brick wall blocks the way north.
>exa wall
The wall is featureless, no handholds or anything.
>climb wall
Despite your climbing skills, the wall defeats your attempts to scale it.
It seems you can't go that way.
...now, after all that wasted effort, you eventually get the message that,
at the game-level) the builder, for whatever reason, hasn't put a space to
the north. Why force the player to be led through the motions when it isn't
necessary? That's what we want parsers to stop; such things as forcing
players to manually open unlocked doors before moving in a direction, etc.
It pretty much comes down to intelligent building, I think. You may be on a
path winding through a forest, or through mountains, but if the space you're
in is described well enough then you will already have the reason *why* 'you
can't go that way'.
> This sort of thing would be mandatory for any MUD which claimed to
> be realistic. _Any_ item should be usable as a weapon. Not because
> this is necessarily a useful or necessary feature, but because
> getting messages like "you can't wield that" makes no sense.
I do agree with you there, however. There's simply no *reason*, as far as
either the player or the game system is concerned, why this shouldn't be
posible.
Compare that statement to the directions issue above, though. There, there
*is* a definite reason why the player must be stopped at some level from
taking the action they wish to take. Unfortunate but necessary, I think,
unless I'm missing a novel new approach to world building (aside from the
stuff I'm doing for my own engine =)).
Raz
Brandon Joseph Rickman
In article <4tig6f$5...@news.fsu.edu>,
>
>>I have been analyzing the various approaches used in MU*s and suggested here
>>for skill based systems. I believe that the goal of skill based gaming is not
>>to accurately model reality but to achieve some degree of complexity that does
>>a good job of emulating/replacing reality.
>
>of skill-based systems is to allow for greater variance between different
>characters. That is, rather than being able to describe most of what a
>character can do with a word and a number (class and level), characters
>can vary widely in many different skills.
Perhaps we just disagree on the wording. Most of the value of skill systems
is found in the application of skills within the virtual environment; having
unique character traits (your "greater variance") is really a very easy task.
The bigger challenge is to make the differences count for something internal
to the world, which is partially a role-playing problem but largely an
emulation problem. This skill based thread has been more about how skills
are integrated into the system (teaching, ranking, &c) which, as you make
your skill systems more complex, takes care of a lot of those secondary
problems that both admins and players then to complain about (fighters are
too easy to play, multi-classing is hard to program, client users are
cheaters).
>Players tend to emphasize combat skills because those are the skills which
>are of the greatest use in gaining XP on most muds. This can be changed.
>
>Also, there's no reason why a player-controlled system *has* to allow
>players to train skills they've never used--most do, but it's not an
>intrinsic part of this system.
But that is still a problem with player-controlled skills because at some
point you have to code in a way to check what the player has done. IMNSHO
it isn't worth the effort, and given its rarity I imagine most would agree.
>I'm not sure what you're trying to get at with "requires more careful
>game balance." Can you elaborate?
If you are using a system that requires a lot of feedback to keep track
of skills you have to watch out for extreme changes in a character's skills.
If you think skill development is too quick or takes too long you need to
be able to fine tune, and when your skills are interdependent even slight
changes can do unexpected things. I guess these side effects are just
inherent to using a skill system, you just have to/get to make more
choices over how characters improve.
>Intelligence attributes can also be used with the other systems; for
>example, with minimum time increase, intelligence might determine
>the time that has to elapse between successive improvements of a
>given skill. With player-controlled increase, intelligence could
>modify the number of experience points that a skill advancement
>costs.
Yes, factoring intelligence into any system is a "good thing". But with
player-controlled skills the dumbest warrior can increase his stats
faster than a smart scientist if he knows where the good experience is.
Intelligence really works best when you minimize the value of
experience points, but player-controlled skills necessitate some kind
of experience point concept.
>Note also that each spell/command/etc. doesn't have to have its own
>skill; thus, you might need a certain minimum skill in Earth and Water
>Magic to use the mudslide spell, but there may not be a separate
>"mudslide" skill.
If an "ability" is based on skills then it can also be classified as a
skill. Just because it isn't explicit doesn't mean it can't be defined.
(This is an OO way of thinking.)
>Again, a spell may not be a skill. A better example might be: a
>certain minimum skill in Blacksmithing might be needed before a
>character can learn Armorsmithing. That is, you need to know something
>about how to work hard metals in general before you can learn to make
>metal armor.
If spells _can't_ be thought of as skills then we are severely restricting
how a skill based system works.
The classic example of armorsmithing requiring blacksmithing seems quite
silly to me. Why can't I learn something about armorsmithing that will
eventually apply to my blacksmithing knowledge? Yes, armorsmithing is a
specialization of blacksmithing, but this usually a result of professional
drive. A good blacksmith likes to make armor, so he specializes. If I
don't give a fig about blacksmithing but want to make my own armor
there is no natural reason why I can't learn the skill. In a typical
mud setting, blacksmithing is usually pretty _useless_ because it is
a _general_ skill. Developing characters don't need to develop general
skills, they need survival skills. General knowledge is the goal.
Armorsmiths don't make horseshoes.
>This section appears to be poorly thought-out; for example, logarithmic
>scales are included under "linear improvement"; surely a logarithmic
>increase is nonlinear?
No, I didn't say logs were linear. I recommended that linear increases
should be balanced by using a log when the skill is applied. It is all quite
esoteric. The rate you improve in a skill is a function of how you
increase a skill value. I would revise this section to concentrate on
how applied skill values can be curved.
- Brandon
as...@oxy.edu
Travis S Casey
Brandon Joseph Rickman <as...@oxy.edu> wrote:
>Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>>Brandon Joseph Rickman <as...@oxy.edu> wrote:
>>
>>I'd have to disagree with you on the goal. IMHO, the primary goal
>>of skill-based systems is to allow for greater variance between different
>>characters. That is, rather than being able to describe most of what a
>>character can do with a word and a number (class and level), characters
>>can vary widely in many different skills.
>
>Perhaps we just disagree on the wording. Most of the value of skill systems
>is found in the application of skills within the virtual environment; having
>unique character traits (your "greater variance") is really a very easy task.
>The bigger challenge is to make the differences count for something internal
>to the world, which is partially a role-playing problem but largely an
>emulation problem. This skill based thread has been more about how skills
>are integrated into the system (teaching, ranking, &c) which, as you make
>your skill systems more complex, takes care of a lot of those secondary
>problems that both admins and players then to complain about (fighters are
>too easy to play, multi-classing is hard to program, client users are
>cheaters).
I'd say that a difference which doesn't count for anything isn't
really a difference... but that's getting philosophical. :-)
>>Players tend to emphasize combat skills because those are the skills which
>>are of the greatest use in gaining XP on most muds. This can be changed.
>>
>>Also, there's no reason why a player-controlled system *has* to allow
>>players to train skills they've never used--most do, but it's not an
>>intrinsic part of this system.
>
>But that is still a problem with player-controlled skills because at some
>point you have to code in a way to check what the player has done. IMNSHO
>it isn't worth the effort, and given its rarity I imagine most would agree.
I agree; I was just pointing out that it doesn't *have* to be that
way.
>Yes, factoring intelligence into any system is a "good thing". But with
>player-controlled skills the dumbest warrior can increase his stats
>faster than a smart scientist if he knows where the good experience is.
>Intelligence really works best when you minimize the value of
>experience points, but player-controlled skills necessitate some kind
>of experience point concept.
Umm... I wasn't saying that using intelligence in a player-controlled
system means that you don't need XP, or that it makes such a system
work well. Again, I was simply pointing out that something you had
listed as applying to one particular method of increasing skills
can be used in others.
>>Note also that each spell/command/etc. doesn't have to have its own
>>skill; thus, you might need a certain minimum skill in Earth and Water
>>Magic to use the mudslide spell, but there may not be a separate
>>"mudslide" skill.
>
>If an "ability" is based on skills then it can also be classified as a
>skill. Just because it isn't explicit doesn't mean it can't be defined.
>(This is an OO way of thinking.)
I think that we're using two different definitions of "skill" here.
My point is that each ability/command/spell doesn't have to have
a separate skill value associated with it; some skills may be used
by more than one command, and, for that matter, some commands may
use more than one skill.
I'm using "skill" to mean "an area of knowledge or activity which
characters are rated in". One could use a definition of "skill"
in which every use of a skill was itself a skill, whether or not
it had a separate rating; doing so, however, makes it harder to
talk about some things clearly.
>>Again, a spell may not be a skill. A better example might be: a
>>certain minimum skill in Blacksmithing might be needed before a
>>character can learn Armorsmithing. That is, you need to know something
>>about how to work hard metals in general before you can learn to make
>>metal armor.
>
>If spells _can't_ be thought of as skills then we are severely restricting
>how a skill based system works.
I didn't mean "may not" in the sense of "is not allowed to"; I meant
it in the sense of "might or might not".
>The classic example of armorsmithing requiring blacksmithing seems quite
>silly to me. Why can't I learn something about armorsmithing that will
>eventually apply to my blacksmithing knowledge? Yes, armorsmithing is a
>specialization of blacksmithing, but this usually a result of professional
>drive. A good blacksmith likes to make armor, so he specializes. If I
>don't give a fig about blacksmithing but want to make my own armor
>there is no natural reason why I can't learn the skill. In a typical
>mud setting, blacksmithing is usually pretty _useless_ because it is
>a _general_ skill. Developing characters don't need to develop general
>skills, they need survival skills. General knowledge is the goal.
>Armorsmiths don't make horseshoes.
The simple fact is, that before a person can learn to make decent
metal armor, they first must learn the basics of how to properly
heat, shape, etc. metal--the basics of blacksmithing. You *can't*
learn to make metal armor without learning something about blacksmithing;
you *can* learn to make horseshoes without learning how to make
decent armor. Thus, blacksmithing is a prerequisite to armorsmithing,
but not the other way around.
Granted, almost no players on a typical mud are going to want to learn
blacksmithing as a skill; however, one of the possible uses of
prerequisite skills is to make characters have to learn more skills
than they otherwise would want to.
>>This section appears to be poorly thought-out; for example, logarithmic
>>scales are included under "linear improvement"; surely a logarithmic
>>increase is nonlinear?
>
>No, I didn't say logs were linear. I recommended that linear increases
>should be balanced by using a log when the skill is applied. It is all quite
>esoteric. The rate you improve in a skill is a function of how you
>increase a skill value. I would revise this section to concentrate on
>how applied skill values can be curved.
I didn't say that you said that logs were linear. I thought that
the section was about skill advancement, not skill _value_ advancement.
My mistake.
Raz
It was all I could do to contain my excitement when Orion Henry wrote:
[re: "Can't go that way" messages]
>
> several years of fairly hard core MUDing. My point is that with the
> resources availilble now, we can do so much more, if coders and
> builders alike feel like putting up the effort, instead of falling
> by on the tired old tried-and-true methods.
I think the hardware resources have probably been around for a long time -
I mean, an area allowing almost unlimited movement is pretty easy to put
together on a stock codebase from yesteryear, and if builders detailed
their existing areas rather than make 5 more 100-room 'templates', it
wouldn't take any more memory.
The stumbling-block, then and now, is in the building. If we're talking
about areas that restrict movement based purely on player abilities (which
we are), then the building work is going to be immense. An arbitrary area
may, on square-per-room graph paper, fill a grid of 20 x 20, yet only
define 60 rooms, if that. An ulimited-movement area of the same size is
400 rooms, multiplied by 2, perhaps 3, for air movement. That's one
shitload of room descriptions =)
What's the builders point of view on this issue? So far in these Evolution
threads we've all been talking from an implementors p.o.v, but what would
the builders think of making an area such as this?
One thing I've been building into my system is a decent way of
automatically generating an adequate space description (mainly vague
environmental stuff) where no explicit builder's text exists. Thinking
about it more, I think I'll look at ways to expand this generation to
include obvious-exit descriptions (leaving the player to wander down all
the others should they wish) and 'random' room detail... Hmm. Any
thoughts?
> Okay, let see.
>
> > cast 'fly' me
[Flying method snipped]
>
> Also, how many brick walls are really going to stop a master climber
> with a grappling hook? What if [...]
[Several more methods snipped]
Yes, there are *always* valid reasons as why you *should* be able to (at
least try to) go where you want - I was mainly trying to illustrate what
the "can't go that way" message presumes when covering the fact that no
location exists in that direction. Of course, if a fully-defined area
exists, there'd be no need for the message at all, except to state why you
can't go that way *until you try another method*...
[...]
> nearby tool shed? None of this stuff is really difficult to do, so
> it escapes me why very few muds attempt any of this stuff.
Because their builders either (a) won't, (b) haven't thought of trying to,
or (c) have been stopped from attempting to ... build a fully described
area that allows movement any which way in *every* location.
> >in is described well enough then you will already have the reason *why* 'you
> >can't go that way'.
>
> This still doesn't tell me why I can't go north in a forest, just
> becuase the path goes east and west. Supposedly it's because there
> is nothing interesting there, but how do I know that?
If I'm playing, I prefer to assume (or, better, be told) its because the
environment won't let me, for whatever reason. In a forest, the trees and
undergrowth may be so tightly packed or tangled so as to prevent passage,
or offer no place to stand; in mountains, the path may wind through sheer
valley sides; that's what I meant about describing the locations well
enough.
Of course, as you rightly say, in the case of tangled undergrowth,
shouldn't players be able to cut their way through? Can you not scale
sheer rock? Hammer in some climbing spikes? In most muds around, this
isn't an issue, of course.
Incidentally, I've just thought of something which might prove to be an
implementation/building nightmare: Players have access to torches, which
are usually naked flames, and should certainly be able to build fires if
they are able. What's to stop them burning down buildings, or even entire
forest areas if they feel the urge..? Would this activity be allowed by
the system? I suppose it would be easy to (off the top of my head) store a
'burnt' flag in the room structure, which if set would replace the room
descriptions with a general "smoking ruins of..." message; but simulating
the blaze? (Permanently) removing objects and mobs?! Having mobs rebuild
the buildings, or having the forest grow back over the years?!? =) Fun!
> >> getting messages like "you can't wield that" makes no sense.
> >
> >I do agree with you there, however. There's simply no *reason*, as far as
> >either the player or the game system is concerned, why this shouldn't be
> >posible.
>
> Well, I'm not necessarily saying that just because there's no reason
> "why not" is a good reason to implement something.
I dunno... as a general rule for creating a rich and true-to-life world
its not so bad, but it does give rise to some real-world problems that are
very hard to deal with.
> >unless I'm missing a novel new approach to world building (aside from the
> >stuff I'm doing for my own engine =)).
>
> Here's the novel approach I'm considering. Build a world,
> _independant_ of the player. [...]
> At no point should it matter one way or another if
> players are ever going to walk through; you don't design it with
> this in mind. Instead, you make a living, breathing forest which
> functions as a real forest should. [...]
That sounds like a nice system. Something I've thought about which would
suit an outlook like that is to remove the optionality of the direction
blocks in room descriptions. Doing this, every location would have links
to those adjacent in every direction - the job of the direction block
would then be to describe the obstructions, if any, between the current
room an the one on the particular direction. This might even aid in
producing consistent maps =)
Again, I'd be interested to hear what experienced builders think about
this. If you could do anything you wanted when building your area, what
would you want to do? What's your wish list?
Raz
Lars Duening
To throw in my few alu-chips...
In article <4trudp$i...@news.fsu.edu> ca...@nu.cs.fsu.edu writes:
>Brandon Joseph Rickman <as...@oxy.edu> wrote:
>>Travis S Casey <ca...@nu.cs.fsu.edu> wrote:
>>>Brandon Joseph Rickman <as...@oxy.edu> wrote:
[...]
>>>Again, a spell may not be a skill. A better example might be: a
>>>certain minimum skill in Blacksmithing might be needed before a
>>>character can learn Armorsmithing. That is, you need to know something
>>>about how to work hard metals in general before you can learn to make
>>>metal armor.
>>The classic example of armorsmithing requiring blacksmithing seems quite
>>silly to me. Why can't I learn something about armorsmithing that will
>>eventually apply to my blacksmithing knowledge? Yes, armorsmithing is a
>>specialization of blacksmithing, but this usually a result of professional
>>drive. A good blacksmith likes to make armor, so he specializes. If I
>>don't give a fig about blacksmithing but want to make my own armor
>>there is no natural reason why I can't learn the skill.
>The simple fact is, that before a person can learn to make decent
>metal armor, they first must learn the basics of how to properly
>heat, shape, etc. metal--the basics of blacksmithing. You *can't*
>learn to make metal armor without learning something about
>blacksmithing;
I think, you both are correct. Learning to smith an armour also
teaches you some basics about blacksmithing - but it doesn't teach you
blacksmithing.
By learning armoursmithing first, you learn how to heat, shape, etc
metal suitable for an armour, but you won't be able to smith anything
else unless being taught explicitely. You won't be able to develop
radically new ways of smithing armours, either.
By learning blacksmithing first, you are able to smith anything. You'd
still need to be taught how to make real good horseshoes, but you'd be
able to make quite good ones on your own.
--
Lars Duening; due...@ibr.cs.tu-bs.de
Orion Henry
>> >hmm. what are you proposing to see rather than "you can't go that way"?
>
>> Something like, "A brick wall blocks the way north." Naturally you
>> can attempt to climb said wall. It just bugs me when I'm on a
>> forest path, "surrounded by forest" yet I can only go two
>> directions.
>
>I think you may *just* be reaching the boundaries of common sense here... =)
I tend to think that MUDs are reaching the boundries of common sense
by telling me I can only go two directions when I'm standing in the
middle of a forest.
>Is it not possible that even back when "You can't go that way" first graced
>our screens, it was in some way a hint at the intelligent parsers we want to
>use nowadays?
The reason they first used that is because it's easy, simple, and
gets the job done. I have no problem with this, as attested by my
several years of fairly hard core MUDing. My point is that with the
resources availilble now, we can do so much more, if coders and
builders alike feel like putting up the effort, instead of falling
by on the tired old tried-and-true methods.
>I mean, let's do it your way:
>
>>n
>A brick wall blocks the way north.
>>exa wall
>The wall is featureless, no handholds or anything.
>>climb wall
>Despite your climbing skills, the wall defeats your attempts to scale it.
>It seems you can't go that way.
Okay, let see.
> cast 'fly' me
You utter the words, 'yrl'
You rise off the ground.
> up
In the Air
Exits: neswud
> north
Above a Brick Wall
Exits: newsu
> north
In the Air
Exits: neswud
> down
...
Also, how many brick walls are really going to stop a master climber
with a grappling hook? What if I'm a 20 foot storm giant that eats
hobbits for breakfast, is a puny brick wall really going to stop me?
What if I'm in a noncorporeal form, so I can just walk right through
the wall? What if I want to use that ladder I drug over from the
nearby tool shed? None of this stuff is really difficult to do, so
it escapes me why very few muds attempt any of this stuff.
I guess I'll be happy when I see the mud where the minotaur can grab
his hobbit friend, toss him over the wall, then clamber over
himself.
So some players "can't go that way", and some can. But to simply
make an all-encompassing statement like that is so vague and so
stupid that it steals all the charm and realism from any given
location.
>...now, after all that wasted effort, you eventually get the message that,
>at the game-level) the builder, for whatever reason, hasn't put a space to
>the north. Why force the player to be led through the motions when it isn't
>necessary? That's what we want parsers to stop; such things as forcing
>players to manually open unlocked doors before moving in a direction, etc.
Because this takes out 99% of what makes a MUD good - many ways to
do something. The quick thief might blanch at the thought of combat
with the mighty gateguard, but hopping over the fence unnoticed is
easy for him. The burly dwarf warrior couldn't scale the fence if
his life depended on it, but he can happily just slaughter the
gateguard and walk through. And the mage can happily turn himself
into a noncorporeal form and walk right through the wall. This sort
of disinction is what makes a MUD good, but right now most of them
are relegated to something where you have to kill the gateguard one
way or the other, it's just that the warrior does it with swings,
the thief with a backstab, and the mage with big damage spells.
>It pretty much comes down to intelligent building, I think.
Absolutely. Still, the system in stock diku (and most systems, I
think) is pretty basic, and not enough to do all the things I'd want
to do in a really interesting zone. You end up just doing a bunch
of spec procs, which is silly and usually error-prone.
>You may be on a
>path winding through a forest, or through mountains, but if the space you're
>in is described well enough then you will already have the reason *why* 'you
>can't go that way'.
This still doesn't tell me why I can't go north in a forest, just
becuase the path goes east and west. Supposedly it's because there
is nothing interesting there, but how do I know that? Besides
which, if I'm trying to escape and band of marading barabarians, I'm
not exactly going to care if there's anything interesting there or
not.
>> This sort of thing would be mandatory for any MUD which claimed to
>> be realistic. _Any_ item should be usable as a weapon. Not because
>> this is necessarily a useful or necessary feature, but because
>> getting messages like "you can't wield that" makes no sense.
>
>I do agree with you there, however. There's simply no *reason*, as far as
>either the player or the game system is concerned, why this shouldn't be
>posible.
Well, I'm not necessarily saying that just because there's no reason
"why not" is a good reason to implement something. But I find
wielding non-weapons both interesting and fairly easy to implement,
so I think it's worth including.
>Compare that statement to the directions issue above, though. There, there
>*is* a definite reason why the player must be stopped at some level from
>taking the action they wish to take. Unfortunate but necessary, I think,
>unless I'm missing a novel new approach to world building (aside from the
>stuff I'm doing for my own engine =)).
Here's the novel approach I'm considering. Build a world,
_independant_ of the player. Make a forest, full of denziens, with
some paths leading through it, perhaps some hidden secrets and
whatever else. At no point should it matter one way or another if
players are ever going to walk through; you don't design it with
this in mind. Instead, you make a living, breathing forest which
functions as a real forest should. Now when a player comes
strolling through, it's as if he's actually in a forest, instead of
a specially crafted little story just for him or her. (How many
zones have you seen things like, "...As you walk deeper into the
forest, your heart begins to race at the..."?)
Orion Henry
> [re: "Can't go that way" messages]
>> several years of fairly hard core MUDing. My point is that with the
>> resources availilble now, we can do so much more, if coders and
>> builders alike feel like putting up the effort, instead of falling
>> by on the tired old tried-and-true methods.
>
>I think the hardware resources have probably been around for a long time -
>I mean, an area allowing almost unlimited movement is pretty easy to put
>together on a stock codebase from yesteryear, and if builders detailed
>their existing areas rather than make 5 more 100-room 'templates', it
>wouldn't take any more memory.
Yes, true. I'm still speaking in generalities - the little quirks
that we all know and love in diku were mostly there as shortcuts for
a time when we had less resources. Diku was created mostly because
Aber couldn't handle more than around 18 chars online, doing stuff,
at a time. This was fine then, but there's no excuse now.
>The stumbling-block, then and now, is in the building. If we're talking
>about areas that restrict movement based purely on player abilities (which
>we are), then the building work is going to be immense. An arbitrary area
>may, on square-per-room graph paper, fill a grid of 20 x 20, yet only
>define 60 rooms, if that. An ulimited-movement area of the same size is
>400 rooms, multiplied by 2, perhaps 3, for air movement. That's one
>shitload of room descriptions =)
I didn't say it would be easy, I just said that if people are
willing to put in the effort it is most certainly viable. And
20x20x3 rooms of "In the Air above a Forest" don't count as a
"shitload" of room descs, it counts as one used many times. With
good code the area writer shouldn't even have to bother writing
these, though he/she can if he/she wants to.
As an aside, I wonder if anyone has pondered a better method of
movement than the room-oriented stuff found on MUDs? I thought
about it for a long while and finally decided that, given our
current resources, it's the easiest usability-wise and code-wise,
though I did come up with some alternatives that were mildly
interesting. If anyone has come up with anything interesting in
this area I'd like to hear it, though I have a feeling we're gonna
be stuck with standard "rooms" until 3D interfaces become the norm.
>What's the builders point of view on this issue? So far in these Evolution
>threads we've all been talking from an implementors p.o.v, but what would
>the builders think of making an area such as this?
There have been quite a few contributions from non-coder builders,
including Marian and Nick, so apparently there are some that would
be willing to put forth the effort to work with such a system.
(Speaking of which, how's that zone coming Nick? :))
>One thing I've been building into my system is a decent way of
>automatically generating an adequate space description (mainly vague
>environmental stuff) where no explicit builder's text exists. Thinking
>about it more, I think I'll look at ways to expand this generation to
>include obvious-exit descriptions (leaving the player to wander down all
>the others should they wish) and 'random' room detail... Hmm. Any
>thoughts?
Yes, that's an excellent idea. I'd ditch the "Exits: newsd" thing,
in favor of mentioning nearby rooms that are interesting, such as a
door to the north or a river to the west. I doubt it's really
necssary to constantly mention that the ground is beneeth your feet
and the air above your head.
>> Okay, let see.
>>
>> > cast 'fly' me
> [Flying method snipped]
>>
>> Also, how many brick walls are really going to stop a master climber
>> with a grappling hook? What if [...]
> [Several more methods snipped]
>
>Yes, there are *always* valid reasons as why you *should* be able to (at
>least try to) go where you want - I was mainly trying to illustrate what
>the "can't go that way" message presumes when covering the fact that no
>location exists in that direction. Of course, if a fully-defined area
>exists, there'd be no need for the message at all, except to state why you
>can't go that way *until you try another method*...
In the new and improved system I am proposing, there would be no
undefined locations. Such a thing is highly disruptive of one's
suspension of disbelief.
> [...]
>> nearby tool shed? None of this stuff is really difficult to do, so
>> it escapes me why very few muds attempt any of this stuff.
>
>Because their builders either (a) won't, (b) haven't thought of trying to,
>or (c) have been stopped from attempting to ... build a fully described
>area that allows movement any which way in *every* location.
But I don't think we can put this on the builders. The archaic .wld
file format currently in use is more to blame.
Secondly, there is VERY little which is going to stop absolutely
everyone from moving in any given direction. It boggles my mind how
master mages and stalward warriors who eat dragons for lunch and
take out an entire platoon of cityguards just for boredom's sake
would be stoped by a locked wooden door, or a 20 foot wall.
>> >in is described well enough then you will already have the reason *why* 'you
>> >can't go that way'.
>>
>> This still doesn't tell me why I can't go north in a forest, just
>> becuase the path goes east and west. Supposedly it's because there
>> is nothing interesting there, but how do I know that?
>
>If I'm playing, I prefer to assume (or, better, be told) its because the
>environment won't let me, for whatever reason.
Yes, yes...I know the reason it works the way it does. What I'm
saying is why that system is silly and outdated, and how it can be
changed to be better.
>In a forest, the trees and
>undergrowth may be so tightly packed or tangled so as to prevent passage,
>or offer no place to stand;
I've done a lot of backpacking in my day and I have rarely seen a
forest so thick one can't move through it, except in the very
densest of jungles. On top of this, most MUDs allow you to
polymorph into frogs or spiders or things like that - you're telling
me it's too tight for a frog?
>in mountains, the path may wind through sheer
>valley sides; that's what I meant about describing the locations well
>enough.
"Sheer" isn't a be-all-end all way to stop someone from moving that
way. People have scaled thousand foot sheer cliffs with nothing but
their skill, strength, and a bit of chalk to keep their fingers from
slipping. And if I'm a powerful mage riding my flying gryphon
mount, I doubt a "sheer" cliff is going to stand in my way. Etc.
>Of course, as you rightly say, in the case of tangled undergrowth,
>shouldn't players be able to cut their way through? Can you not scale
>sheer rock? Hammer in some climbing spikes? In most muds around, this
>isn't an issue, of course.
Yeah, we've established that. I just think it's time to think about
a new way to do it.
>Incidentally, I've just thought of something which might prove to be an
>implementation/building nightmare: Players have access to torches, which
>are usually naked flames, and should certainly be able to build fires if
>they are able. What's to stop them burning down buildings, or even entire
>forest areas if they feel the urge..? Would this activity be allowed by
>the system? I suppose it would be easy to (off the top of my head) store a
>'burnt' flag in the room structure, which if set would replace the room
>descriptions with a general "smoking ruins of..." message; but simulating
>the blaze? (Permanently) removing objects and mobs?! Having mobs rebuild
>the buildings, or having the forest grow back over the years?!? =) Fun!
Funny you should mention that, because I was just coding that the
other day. Yes, it's tons of fun, and not terribly difficult. And
the thing is, I've seen this on MUDs before, along with most of
these other features that I'm referring to. I've just never seen
them all in one place; moreover, I think these sorts of features
should be the rule and not the exception.
>> Here's the novel approach I'm considering. Build a world,
>> _independant_ of the player. [...]
>> At no point should it matter one way or another if
>> players are ever going to walk through; you don't design it with
>> this in mind. Instead, you make a living, breathing forest which
>> functions as a real forest should. [...]
>
>That sounds like a nice system. Something I've thought about which would
>suit an outlook like that is to remove the optionality of the direction
>blocks in room descriptions. Doing this, every location would have links
>to those adjacent in every direction - the job of the direction block
>would then be to describe the obstructions, if any, between the current
>room an the one on the particular direction. This might even aid in
>producing consistent maps =)
Absolutely. Having built both for stock dikus and for my own system,
I can say that the second is far easier. Of course, I always hated
writing exits - they never seem to match up just right. Getting rid
of exits makes .wld file writing ten times funner and easier. :)
>Again, I'd be interested to hear what experienced builders think about
>this. If you could do anything you wanted when building your area, what
>would you want to do? What's your wish list?
As would I. Still, the important thing is not the individual
features on the wish list, like being able to climb over walls or
chop down trees. The important thing is the overview of the entire
thing: climbing over walls should be a given, and integral part of
the system (along with climbing trees, cliffs, fences, and really
steep staircases, I suppose). By simply defining a wall, the
functionality should be in place automatically. They shouldn't have
to specify that the wall is climbable, or can be knocked down by a
battering ram, or whatever else.
Marian Griffith
In article <4u0j03$8...@sdcc12.ucsd.edu>,
ohe...@sdcc10.ucsd.edu (Orion Henry) wrote:
| [re: "Can't go that way" messages]
|> several years of fairly hard core MUDing. My point is that with the
|> resources availilble now, we can do so much more, if coders and
|> builders alike feel like putting up the effort, instead of falling
|> by on the tired old tried-and-true methods.
|I think the hardware resources have probably been around for a long time -
|I mean, an area allowing almost unlimited movement is pretty easy to put
|together on a stock codebase from yesteryear, and if builders detailed
|their existing areas rather than make 5 more 100-room 'templates', it
|wouldn't take any more memory.
This is probably true, but would it be feasible? A room when properly
desced takes some 7 or 8 lines of text, at the least, not counting
the extra descriptions that -ought- to be present. Or the descriptions
for the exits. If you want to allow unlimited movements that's an
awfull lot of text. Or, and that's what you'll like see happening,
it's not going to be very interesting text.
|The stumbling-block, then and now, is in the building. If we're talking
|about areas that restrict movement based purely on player abilities (which
|we are), then the building work is going to be immense. An arbitrary area
|may, on square-per-room graph paper, fill a grid of 20 x 20, yet only
|define 60 rooms, if that. An ulimited-movement area of the same size is
|400 rooms, multiplied by 2, perhaps 3, for air movement. That's one
|shitload of room descriptions =)
>I didn't say it would be easy, I just said that if people are
>willing to put in the effort it is most certainly viable. And
>20x20x3 rooms of "In the Air above a Forest" don't count as a
>"shitload" of room descs, it counts as one used many times. With
>good code the area writer shouldn't even have to bother writing
>these, though he/she can if he/she wants to.
Surely you don't consider 400 or so rooms that are named and desced
'In the air above a forest' as good building? At least there should
be some hint of what is actualy below, things that attract the
attention which means there are going to be a lot of different
descriptions in those huge areas.
>As an aside, I wonder if anyone has pondered a better method of
>movement than the room-oriented stuff found on MUDs? I thought
>about it for a long while and finally decided that, given our
>current resources, it's the easiest usability-wise and code-wise,
>though I did come up with some alternatives that were mildly
>interesting. If anyone has come up with anything interesting in
>this area I'd like to hear it, though I have a feeling we're gonna
>be stuck with standard "rooms" until 3D interfaces become the norm.
Personally I prefer to look at areas as a collection of locations
with tracks from one to the other. People rarely wander to places
that have nothing particularly interesting. Of course this
approach has its limitations, and it doesn't address the basic
restriction of a diku that a lot of things you -should- be able
to do don't actually can be done.
That problem however lies more in the definition of the exits
than in the amount of them. At the moment there are only two
qualifications to an exit: it can be a door, and if it is it
can be locked. There are two skills that deal with those:
translucence (in one way or another) and pick lock.
By broadening the range of exits (and by considering them to
be tracks/roads rather than doors) you can make the entire
mud more interesting, and it would become easier to do something
remotely smart with blocked directions. The player must of course first
notice there is an exit in a particular direction. A path may
be well hidden to players without forest skills. Or it may simply
be of a nature that only mages or clerics can detect.
The exit could indeed actually be blocked by something, that the
character must negotiate before being able to go in that direction.
e.g. a wall, or a sheer cliff, or a mudslide. If the way it is
blocked is defined then there are possible skills to deal with
that. Like as has been said before a thief could use a rope and
grapple, or simply climb it, as could a feline character. A mage
could fly over it, or walk through it and so on.
Another thing that seems important to me is to do away with the
standard 6 (or 10) exits in a room: NESWUD. Name exits after the
thing you'ld be heading to. That way there's less need to provide
reasons to block unused directions. If it doesn't show up in the
main description of the room then you likely can't go there.
(though that desc may vary according to the sensitivity of the
character looking !)
You could also do away with the chain of rooms to make a road.
And instead make the road go from one landmark to another and
have a slight delay depending on the actual distance between
those two locations. That way the 'rooms' themselves can be
fairly standard sized and a player will still get a sense of
distance when traversing the area. It would also cut down on
the number of basically pointless and boring rooms that each
area seems to develop.
|What's the builders point of view on this issue? So far in these Evolution
|threads we've all been talking from an implementors p.o.v, but what would
|the builders think of making an area such as this?
>There have been quite a few contributions from non-coder builders,
>including Marian and Nick, so apparently there are some that would
>be willing to put forth the effort to work with such a system.
>(Speaking of which, how's that zone coming Nick? :))
|One thing I've been building into my system is a decent way of
|automatically generating an adequate space description (mainly vague
|environmental stuff) where no explicit builder's text exists. Thinking
|about it more, I think I'll look at ways to expand this generation to
|include obvious-exit descriptions (leaving the player to wander down all
|the others should they wish) and 'random' room detail... Hmm. Any
|thoughts?
Yes, do away with the standard 6 exits per room and make it so that
it can vary, and make the default name for an exit that what it
leads to rather than a compass direction (mush style).
>Yes, that's an excellent idea. I'd ditch the "Exits: newsd" thing,
>in favor of mentioning nearby rooms that are interesting, such as a
>door to the north or a river to the west. I doubt it's really
>necssary to constantly mention that the ground is beneeth your feet
>and the air above your head.
I totally agree with that. I allways feel stiffled by this whole
nesw thing. It is confining and forces me into 'chessboard-like'
designs when I would much rather have an area that seems to
curve gradually. It's probably my European heritage (not to mention
my degree in architecture) but I really detest the way cities are
built in America: rectangular grids of roads, with an amorph collection
of buildings designed to attract the eye by pushing aside the others.
There is no sense of unity or cohesion like there is in older cities
that have had the change to evolve and grow.
|Yes, there are *always* valid reasons as why you *should* be able to (at
|least try to) go where you want - I was mainly trying to illustrate what
|the "can't go that way" message presumes when covering the fact that no
|location exists in that direction. Of course, if a fully-defined area
|exists, there'd be no need for the message at all, except to state why you
|can't go that way *until you try another method*...
[ snipped ...]
|> nearby tool shed? None of this stuff is really difficult to do, so
|> it escapes me why very few muds attempt any of this stuff.
|Because their builders either (a) won't, (b) haven't thought of trying to,
|or (c) have been stopped from attempting to ... build a fully described
|area that allows movement any which way in *every* location.
(d) don't have the time to come up with thousands of decriptions for
rooms that are basically totally uninteresting. the way players are
screaming for new areas really leaves you with little time to let
an idea mature before attempting to shape it in an area file. Adding
hundreds of virtually identical rooms is going to take so long that
you're deafened by the clamour of players wanting your new area
yesterday.
>But I don't think we can put this on the builders. The archaic .wld
>file format currently in use is more to blame.
partly. It has also to do with the fact that on a standard mud a
room is basically seen as a stage for the monsters rather than as
an active part of the game.
>Secondly, there is VERY little which is going to stop absolutely
>everyone from moving in any given direction. It boggles my mind how
>master mages and stalward warriors who eat dragons for lunch and
>take out an entire platoon of cityguards just for boredom's sake
>would be stoped by a locked wooden door, or a 20 foot wall.
*grin* of course that's another gripe of mine.
|> >in is described well enough then you will already have the reason
|> >*why* 'you can't go that way'.
|> This still doesn't tell me why I can't go north in a forest, just
|> becuase the path goes east and west. Supposedly it's because there
|> is nothing interesting there, but how do I know that?
Even as a player you have to be practical I'm afraid. If you're
willing to put up with 'You're in a forest. You see trees all around you'
style of descriptions then it's easy to create a forest with thousands
of rooms. You could go north into the forest to your hearts content but
clearly no mud is going to accept such an area.
|If I'm playing, I prefer to assume (or, better, be told) its because the
|environment won't let me, for whatever reason.
>Yes, yes...I know the reason it works the way it does. What I'm
>saying is why that system is silly and outdated, and how it can be
>changed to be better.
Personally I'm not convinced that what you're proposing would actually
improve things that much that the sacrifice (mechanical descriptions
and loads and loads of empty rooms) is worth it. Perhaps I'm not
understanding your ideas properly. (Could well be, it happens often
enought :(
|> Here's the novel approach I'm considering. Build a world,
|> _independant_ of the player. [...]
|> At no point should it matter one way or another if
|> players are ever going to walk through; you don't design it with
|> this in mind. Instead, you make a living, breathing forest which
|> functions as a real forest should. [...]
If you manage to do that you have a very nice area in your hands.
Unfortunately it's often very hard to get to that point of bringing
your area to life.
You're absolutely right about trying to avoid temporalities into an
area (things like 'as you move deeper into the forest'). When back
tracing your way in such areas look exceedingly silly.
While each area tells a little story, it shouldn't do that in the
style of a book, where a player/reader is taken by the hand and
is sent through a sequence of events. Instead a players should be
thought of as an actor or main character they way they should
perceive the story from inside it.
|Again, I'd be interested to hear what experienced builders think about
|this. If you could do anything you wanted when building your area, what
|would you want to do? What's your wish list?
>As would I. Still, the important thing is not the individual
>features on the wish list, like being able to climb over walls or
>chop down trees. The important thing is the overview of the entire
>thing: climbing over walls should be a given, and integral part of
>the system (along with climbing trees, cliffs, fences, and really
>steep staircases, I suppose). By simply defining a wall, the
>functionality should be in place automatically. They shouldn't have
>to specify that the wall is climbable, or can be knocked down by a
>battering ram, or whatever else.
The most important of the things that I feel are essential I've already
addressed in this post so I'll leave this question as it is
Marian
--
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
Orion Henry
I know this thread is getting out of hand when the first page pops
up in my newsreader and it says, "(more) 9%" at the bottom... :)
Hell of a lot more interesting than flames about bad admins, and mud
ads for out-of-the-box specials which seem to populate this ng.
>|together on a stock codebase from yesteryear, and if builders detailed
>|their existing areas rather than make 5 more 100-room 'templates', it
>|wouldn't take any more memory.
>
>This is probably true, but would it be feasible? A room when properly
>desced takes some 7 or 8 lines of text, at the least, not counting
Well, that's a big room. Most players don't bother reading past
about the third sentence. But still, you're talking twenty
characters for the room name, then 500+ bytes of room description,
plus 100 bytes of room-related pointers, plus extra descs and other
stuff (like descriptions which vary with time of day and season).
So yes, it is a sizable amount of space being used by a given room.
But the correct coding can get rid of a lot of redundancies and get
it down to a managable size.
>>I didn't say it would be easy, I just said that if people are
>>willing to put in the effort it is most certainly viable. And
>>20x20x3 rooms of "In the Air above a Forest" don't count as a
>>"shitload" of room descs, it counts as one used many times. With
>>good code the area writer shouldn't even have to bother writing
>>these, though he/she can if he/she wants to.
>
>Surely you don't consider 400 or so rooms that are named and desced
>'In the air above a forest' as good building?
Go back and read it again. The builder doesn't write those 400
rooms, they exist automatically.
>At least there should
>be some hint of what is actualy below, things that attract the
>attention which means there are going to be a lot of different
>descriptions in those huge areas.
Well, if I'm fifty feet off the ground, and all I see are a bunch of
treetops, I consider "In the Air above a Forest" good enough. What
would you prefer?
>>As an aside, I wonder if anyone has pondered a better method of
>>movement than the room-oriented stuff found on MUDs? I thought
>>about it for a long while and finally decided that, given our
>
>Personally I prefer to look at areas as a collection of locations
>with tracks from one to the other. People rarely wander to places
[snip, named exits and so on]
Hmmm. Have you ever tried playing LPs, or possibly MUSHes? They
have this, and though it seems like a good idea I rarely like the
implementation. I get the feeling I'm climbing through a jungle-gym
made especially for big kids...maybe it's just me. If I want to run
away from that dragon that's chasing me, I usually don't feel like
stopping to type "follow road" or "walk towards mountains."
Anyways, I don't like exits. I got tired of writing them and my
zones got smaller and less error-prone when I finally just deleted the
whole exit concept out of the code.
>>Yes, that's an excellent idea. I'd ditch the "Exits: newsd" thing,
>>in favor of mentioning nearby rooms that are interesting, such as a
>>door to the north or a river to the west. I doubt it's really
>>necssary to constantly mention that the ground is beneeth your feet
>>and the air above your head.
>
>I totally agree with that. I allways feel stiffled by this whole
>nesw thing. It is confining and forces me into 'chessboard-like'
>designs when I would much rather have an area that seems to
>curve gradually. It's probably my European heritage (not to mention
>my degree in architecture) but I really detest the way cities are
>built in America: rectangular grids of roads, with an amorph collection
>of buildings designed to attract the eye by pushing aside the others.
>There is no sense of unity or cohesion like there is in older cities
>that have had the change to evolve and grow.
My experience has been that zones on LPs built to try to be less
compass oriented just end up looking like a wierd mish-mash in your
head. Everyone who goes through the zone has a different picture of
it. The cardinal directions thing doesn't really bother me,
particuarly, but rather displaying them as "Exits: ns". Of course
such an exit display would be useless outdoors, since you can almost
always go every direction.
[why can't you enter zones in more than one way?]
>(d) don't have the time to come up with thousands of decriptions for
>rooms that are basically totally uninteresting.
I'm proposing a new code base here, not that builders should try to
do this kind of stuff with the way things are now. They wouldn't
have to come up with descriptions for thousands of useless rooms,
they would only do the "interesting" ones.
>the way players are
>screaming for new areas really leaves you with little time to let
>an idea mature before attempting to shape it in an area file. Adding
>hundreds of virtually identical rooms is going to take so long that
>you're deafened by the clamour of players wanting your new area
>yesterday.
Of course. That's why we're suggesting a system that would save the
builder this trouble. It also ensures a more consistent MUD. There
is a zone on AnotherMUD that has room decs for part of it that look
like this:
A Hallway
The hallway continues north and south here...it's really pretty
boring, infact you don't know why you're here at all. there's
nothing interesting north
Luckily, AnotherMUD isn't too worried about breaking the
"atmosphere", and since there are no mobs in this area, there's no
reason to ever come here once you've acertained this.
(If anyone cares, it's the southwestern part of Sardon, a generally
really poorly written zone but it has kick ass gear so people go
there a lot.)
>>But I don't think we can put this on the builders. The archaic .wld
>>file format currently in use is more to blame.
>
>partly. It has also to do with the fact that on a standard mud a
>room is basically seen as a stage for the monsters rather than as
>an active part of the game.
Well, yes...which results in builders writing zones to reflect this,
which results in adding features to the .wld files that builders
request in order to make their stage more so...it's a big cyclical
process, so at some point someone has to say, "Hey, let's try
something totally different."
>>Secondly, there is VERY little which is going to stop absolutely
>>everyone from moving in any given direction. It boggles my mind how
>>master mages and stalward warriors who eat dragons for lunch and
>>take out an entire platoon of cityguards just for boredom's sake
>>would be stoped by a locked wooden door, or a 20 foot wall.
>
>*grin* of course that's another gripe of mine.
This is actually two different gripes: that normal high-level
characters eat dragons for lunch, and that they are powerless
against non-mobs. I'd be more accepting of me not being able to
hack through that wooden door if I hadn't just come from hacking a
dragon with 10-inch-thick titanium scales into confetti.
>|> >in is described well enough then you will already have the reason
>|> >*why* 'you can't go that way'.
>
>|> This still doesn't tell me why I can't go north in a forest, just
>|> becuase the path goes east and west. Supposedly it's because there
>|> is nothing interesting there, but how do I know that?
>
>Even as a player you have to be practical I'm afraid.
MUDs just aren't practical, so get over that little problem right now. :)
>If you're
>willing to put up with 'You're in a forest. You see trees all around you'
>style of descriptions then it's easy to create a forest with thousands
>of rooms.
Yep.
>You could go north into the forest to your hearts content but
>clearly no mud is going to accept such an area.
Oh? I've seen it before and that's exactly what I'm proposing. It's
hard to make a "secret forest hideout", because people will just
notice "hey, I can go north here, that's funny...?" If you're
hidden in a tiny grove somewhere in the middle of a huge forest,
finding the hideout is actually going to be a real feat. And of
course, this is when you get to bring all those ranger-y skills into
play, instead of just being a warrior that can cast burning hands.
>|If I'm playing, I prefer to assume (or, better, be told) its because the
>|environment won't let me, for whatever reason.
>
>>Yes, yes...I know the reason it works the way it does. What I'm
>>saying is why that system is silly and outdated, and how it can be
>>changed to be better.
>
>Personally I'm not convinced that what you're proposing would actually
>improve things that much that the sacrifice (mechanical descriptions
>and loads and loads of empty rooms) is worth it. Perhaps I'm not
>understanding your ideas properly. (Could well be, it happens often
>enought :(
I doubt it's for everyone. Some people think LPs are tons of fun,
which is great. I'm just not one of those people.
Since I've already incorperated all the ideas I'm broaching here
into my own mud, I can say without a doubt that I think it's tons of
fun. But that's just me. If hacking up the same mob over and over
is your idea of bliss, you'll probably not like it. Personally, I'm
so spoiled now that I can't even log onto another MUD without
wincing at the lack of detail. I'm so incredibly happy with what
we've done that I'm trying to convince others to try the same path,
in order to advance the state of MUDs in general.
>|> Here's the novel approach I'm considering. Build a world,
>|> _independant_ of the player. [...]
>|> At no point should it matter one way or another if
>|> players are ever going to walk through; you don't design it with
>|> this in mind. Instead, you make a living, breathing forest which
>|> functions as a real forest should. [...]
>
>If you manage to do that you have a very nice area in your hands.
Thank you, I have written about ten of them so far. I'm very proud. :)
>Unfortunately it's often very hard to get to that point of bringing
>your area to life.
Are you kidding me? It's not very hard, it's FUCKING hard! I
deleted the first two zones I wrote and totally revamped the second
just because they were so poor, and this is considering the fact
that I was already an experienced diku builder. Those zones would
have been fine on a normal diku, but were complete crap from the
standpoint of what I was trying to achieve (see above).
Once you get used to it though, it gets very natural. Like I said,
I can barely stand to build on regular dikus anymore because I hate
writing "exits" so much.
>You're absolutely right about trying to avoid temporalities into an
>area (things like 'as you move deeper into the forest'). When back
>tracing your way in such areas look exceedingly silly.
Well, from the standpoint that they'll have brief off on the way in
and then never read the room descs again, it's not so bad. What
does bug me are things like, "You shiver in fear at the thought of
the evil residing in the ancient tower" when I'm an evil-ass mage
who energy drains toddlers for kicks. Normally, though, exploring a
new zone looks like this for me:
The Old Forest
Exits: nes
> n
Darkening Forest
Exits: ns
> gt cool, new zone
You group-tell, 'cool, new zone'
> br
BRIEF is now off.
> l
Darkening Forest
As you plunge further into the forest, the trees seem to press in
around you. All your instincts cry for you to go back out the way
you came, for great danger may lie along this path.
Exits: ns
> n
[...]
The Darkening Guardian is dead! R.I.P.
You receive your share of 1500000 experience.
> get all corpse
You get a pile of gold coins from the corpse.
There were 34029 gold coins.
You get the Darkening helm from the corpse.
> gt well, that was a cool zone...let's get out of here
You group-tell, 'well, that was a cool zone...let's get out of here'
> br
BRIEF is now on.
>While each area tells a little story, it shouldn't do that in the
>style of a book, where a player/reader is taken by the hand and
>is sent through a sequence of events. Instead a players should be
>thought of as an actor or main character they way they should
>perceive the story from inside it.
More like the "story" doesn't need to be artificially created. You
make a bunch of cool places and critters and objects, then toss
players into the mix and watch wacky fun ensue. The "stories" that
emerge from this will always be better than the stale things we
somehow mash into zone files.
Raz
It was all I could do to contain my excitement when Marian Griffith wrote
(quoting me with "> |" and Orion with "> >") :
> |I mean, an area allowing almost unlimited movement is pretty easy to put
> |together on a stock codebase from yesteryear, and if builders detailed
> |their existing areas rather than make 5 more 100-room 'templates', it
> |wouldn't take any more memory.
> This is probably true, but would it be feasible? [...]
> If you want to allow unlimited movements that's an
> awfull lot of text.
Mmm, not necessarily - as Orion said, we want a system whereby the 'padding'
of the world, the links between areas of interest, are fleshed out wherever
possible by the engine itself, not by the builder. Of course, the more
areas of interest there are, the better, and if that means more building
work... =)
> Or, and that's what you'll like see happening,
> it's not going to be very interesting text.
A pity. Still, that's down to the particular Mud Admin, and whether they're
prepared to incorporate stale, sparsely detailed areas into their worlds.
> That problem however lies more in the definition of the exits
> than in the amount of them. At the moment there are only two
> qualifications to an exit: it can be a door, and if it is it
> can be locked. [...]
> By broadening the range of exits (and by considering them to
> be tracks/roads rather than doors) you can make the entire
> mud more interesting,
Very true - the current exits have virtually no flexibility, and this is one
of the areas I've already expanded (your interpretation of the exits as
something different to a little portal that sends you between rooms strikes
quite a chord with what I have, actually =) ).
[some good ideas for exit blockages snipped]
> Another thing that seems important to me is to do away with the
> standard 6 (or 10) exits in a room: NESWUD. Name exits after the
> thing you'ld be heading to. That way there's less need to provide
> reasons to block unused directions.
I don't know whether I'd like to see a game with no compass directions for
movement... I don't think it really restricts general movement all that
much (especially when the engine supports the four secondary compass
points). I do still like named exits in some circumstances, though, mainly
for 'enter'ing or 'board'ing something, things like that. Something I don't
particulary like is the LP-like method of having *anything* as an exit and
you simply type that word to go to a new place... From the character's p.o.v
it doesn't seem to make much sense.
> |Any thoughts?
> Yes, do away with the standard 6 exits per room and make it so that
> it can vary, and make the default name for an exit that what it
> leads to rather than a compass direction (mush style).
Like I wrote just above, I don't think that works too well in every
situation... another problem with losing 'directional' movement in favour of
'target' movement (?) is that you create ambiguity; for example:
A path through the Forest
You're on a path which winds through a quiet part of the forest. Flowers
and trees blah blah, forest forest, etc.
If you have no directional movement then presumably you can't tell the
player that the path winds runs north to south, however if they 'follow
path', or 'walk along path', you don't know which way they want to go. Yoiu
could move them in the direction they *didn't* arrive from, but when the
path forks?
I'm not slamming your ideas, and I'd like to hear any other ideas for
alternatives or improvements to the compass directions.
> >Yes, that's an excellent idea. I'd ditch the "Exits: newsd" thing,
> >in favor of mentioning nearby rooms that are interesting, such as a
> >door to the north or a river to the west.
[...]
> I totally agree with that. I allways feel stiffled by this whole
> nesw thing.
From previous things yourself and Orion have said, I believe he actually
meant simply to lose the "Exits" message in favour of greater description,
rather than ditch directional movement (though I could be wrong, the
'exit-less' system sounds most intriguing =) )
> It is confining and forces me into 'chessboard-like'
> designs when I would much rather have an area that seems to
> curve gradually. [...] I really detest the way cities are
> built in [...]
I *do*, however, agree with this. (Especially if you'd written "...cities
are built in Muds" =) ) I'd really like to see a complex town design that
looked and felt like towns and cities in the real world (referring to those
I've seen here in England and in mainland Europe).
I think there are other ways to do this than to scrap compass directions
though. Perhaps coordinates for rooms inside their areas; dimensions of
rooms; placement of exits within those rooms. The rectangular nature of a
room was and still can be seen as merely conceptual; your exit can still
lead southwards, whether it's in the 'middle' of the 'south wall' or in the
'corner' of it.
> Even as a player you have to be practical I'm afraid. If you're
> willing to put up with 'You're in a forest. You see trees all around you'
> style of descriptions then it's easy to create a forest with thousands
> of rooms.
[...]
> Personally I'm not convinced that what you're proposing would actually
> improve things that much that the sacrifice (mechanical descriptions
> and loads and loads of empty rooms) is worth it.
Remember that the aim isn't to create a system that provides the most rooms,
it's to create a system that provides a *world* for players to explore,
rather than X number of areas. In my eyes, the only use for the
auto-generated rooms is to provide links between the explicitly defined
parts of the area. There shouldn't need to be that many of them, and there
*are* too many in one place, its perhaps time to start building some detail
there. Does that sound like a better system? =)
> |Again, I'd be interested to hear what experienced builders think about
> |this. If you could do anything you wanted when building your area, what
> |would you want to do? What's your wish list?
> >As would I. Still, the important thing is not the individual
> >features on the wish list, like being able to climb over walls or
> >chop down trees. The important thing is the overview of the entire
> >thing:
True, but the two are interlinked, I think. While designing I've found that
thinking about an imaginary game and the encounters I'd like to have when
playing it is a great way to envision the functionality of the system, and
to design the structures and whatnot that will allow builders to make the
things I want to play.
Raz
Chris Lawrence (Contra)
Marian Griffith (Mar...@catling.iaehv.nl) wrote:
: Another thing that seems important to me is to do away with the
: standard 6 (or 10) exits in a room: NESWUD. Name exits after the
: thing you'ld be heading to. That way there's less need to provide
: reasons to block unused directions. If it doesn't show up in the
: main description of the room then you likely can't go there.
For verisimilitude you'd have to provide both sorts of exits.
Okay, I'm standing by the castle:
> l
Krak's Castle
A craggy gray castle is descirbed in excruciating detail...and
mentions that I could go onto the drawbrige, or out by the hitching
rail, by the stable, or under the gibbet.
> gibbet
Under the Gibbet
<Description of gory gibbet inserted here>
Why couldn't I also do:
> l
Krak's Castle
...etc...
> n
Under The Gibbet
...etc...
Lord knows I might have kept track of my own compass directions...
: You could also do away with the chain of rooms to make a road.
: And instead make the road go from one landmark to another and
: have a slight delay depending on the actual distance between
: those two locations. That way the 'rooms' themselves can be
: fairly standard sized and a player will still get a sense of
: distance when traversing the area. It would also cut down on
: the number of basically pointless and boring rooms that each
: area seems to develop.
Which then (more or less) guarantee the user: Every Room In This Game
Has Something Interesting In It for You! A lot of the fun in a well
crafted game is figuring out that an otherwise interesting room or
object, in fact has no use or value in the game proper, or that some
decidedly dull and nondescript item is in fact crucially detailed upon
examination.
Admittedly,endless "On the road to Mandalay" rooms are a cop out, but
fiddling with fancy carvings on the wall of the great hall, looking
for secret passages is another deal -- or knowing that if you look at
the otherwise ignorable nonm-descript tree On The Road To Manadaly in
sufficient detail that you'll find a ladder leading to Tarzan's lair...
: Even as a player you have to be practical I'm afraid. If you're
: willing to put up with 'You're in a forest. You see trees all around you'
: style of descriptions then it's easy to create a forest with thousands
: of rooms. You could go north into the forest to your hearts content but
: clearly no mud is going to accept such an area.
Facetiously, "Ohh, I dunno..."
> l
You are in a forest. There are trees all around you.
> l at trees
They are mostly alder and ash trees, growing in a riotous tangle,
though there is a stately elm tree a little to the north with a
lightning blasted hawthorne beside it.
> l at elm
A tall and stately tree, towering above this area of the forest.
Cool, green, and magnificent, it seems larger every time you look at
it.
> l at hawthorne
The hawthorne has been split clear down the middle. You can see the
burnt and ragged spears of wood twisting from the wound. looking
almost like a ladder, leaning up into the elm tree.
> climb hawthorne
In the Elm Tree
...etc
I tend to like very deep objects and rooms (this above would be quite
shallow).
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Raz
It was all I could do to contain my excitement when Orion Henry wrote:
[...]
> >they are able. What's to stop them burning down buildings, or even entire
> >forest areas if they feel the urge..? Would this activity be allowed by
> >the system? I suppose it would be easy to (off the top of my head) store a
[...]
> Funny you should mention that, because I was just coding that the
> other day. Yes, it's tons of fun, and not terribly difficult.
!
Well, I'm not a coder per se (though I am writing the world editor for my
engine), I'm more of a designer, so that seems an almost unbelievably blase
viewpoint! ;)
> This might even aid in producing consistent maps =)
> Absolutely. Having built both for stock dikus and for my own system,
> I can say that the second is far easier. Of course, I always hated
> writing exits - they never seem to match up just right. Getting rid
> of exits makes .wld file writing ten times funner and easier. :)
As I said in another post, this sounds very interesting... =) I think I've
done a fair bit to upgrade and 'empower' the old system of rooms and links
(the least I could do since I haven't thought of a 'better' way) but when it
comes down to it, it *is* still rooms and links. Like I say, it'd be
interesting to hear about your direction if you feel like it.
Raz
The Munch Family
Orion Henry <ohe...@sdcc10.ucsd.edu> wrote:
>Oh? I've seen it before and that's exactly what I'm proposing. It's
>hard to make a "secret forest hideout", because people will just
>notice "hey, I can go north here, that's funny...?" If you're
>hidden in a tiny grove somewhere in the middle of a huge forest,
>finding the hideout is actually going to be a real feat. And of
>course, this is when you get to bring all those ranger-y skills into
>play, instead of just being a warrior that can cast burning hands.
What ranger skills specifically?
--
* * * * * * * * *
mu...@fix.net Harry Browne for President
John and Paz Munch http://www.HarryBrowne96.org/
http://www.fix.net/~munch * * * * * * * * *
gry...@iaehv.nl
In article <4u85pl$l...@hpax.cup.hp.com>,
Chris Lawrence (Contra) <claw...@cup.hp.com> wrote:
>Marian Griffith (Mar...@catling.iaehv.nl) wrote:
: Another thing that seems important to me is to do away with the
: standard 6 (or 10) exits in a room: NESWUD. Name exits after the
: thing you'ld be heading to. That way there's less need to provide
: reasons to block unused directions. If it doesn't show up in the
: main description of the room then you likely can't go there.
>For verisimilitude you'd have to provide both sorts of exits.
>
example snipped.
Of course you can put a compass direction to an exit, but I was
saying that having exactly 6 exits for the 6 main directions leaves
you with more to explain than saying exactly where you can go, and
not describe anything else. This isn't an ideal solution either but
it is slightly more intuitive.
: You could also do away with the chain of rooms to make a road.
: And instead make the road go from one landmark to another and
: have a slight delay depending on the actual distance between
: those two locations. That way the 'rooms' themselves can be
: fairly standard sized and a player will still get a sense of
: distance when traversing the area. It would also cut down on
: the number of basically pointless and boring rooms that each
: area seems to develop.
>Which then (more or less) guarantee the user: Every Room In This Game
>Has Something Interesting In It for You! A lot of the fun in a well
>crafted game is figuring out that an otherwise interesting room or
>object, in fact has no use or value in the game proper, or that some
>decidedly dull and nondescript item is in fact crucially detailed upon
>examination.
This most definitely isn't what I was aiming at. To be interesting
a room doesn't have to be packed with goodies. It merely does have
to be remarkable from a traveller's point of view.
>Admittedly,endless "On the road to Mandalay" rooms are a cop out, but
>fiddling with fancy carvings on the wall of the great hall, looking
>for secret passages is another deal -- or knowing that if you look at
>the otherwise ignorable nonm-descript tree On The Road To Manadaly in
>sufficient detail that you'll find a ladder leading to Tarzan's lair...
This type of room was exactly what I was talking about. Or the 9 or
12 identical rooms to make up that huge hall. Those rooms serve no
purpose other than delay the player. If that's the aim simply delay
the player and spend more time on writing interesting rooms.
All this doesn't mean I'm saying there can't be 'on the road to' type
of roomsbut only that I feel they are exceedingly boring and silly.
If you need a road at least make it like a real road, with things and
landscape to look at and to explore.
[example snipped for brevity]
>I tend to like very deep objects and rooms (this above would be quite
>shallow).
Of course, but would you be allowed to repeat that a couple of hundred
times to make up an otherwise empty forest? Somehow I doubt that. Even
if you can actually make it diverse enough to remain interesting.
My reply initially was aimed at the claim that a player should be able
to enter that forest at the side of the road, and not beeing put off by
a 'you can't go there' type of message. Putting in areas of that mag-
nitude however would be totally unpractical. Both from building point
of view (either too much work or too shallow) and from a player's point
of view (because the entire mud would become a maze this way)
Marian
Chris Lawrence (Contra)
Jens Malare (rai...@dalnet.se) wrote:
...
: > > l
: > Krak's Castle
: > A craggy gray castle is descirbed in excruciating detail...and
: > mentions that I could go onto the drawbrige, or out by the hitching
: > rail, by the stable, or under the gibbet.
: > > gibbet
: > Under the Gibbet
: > <Description of gory gibbet inserted here>
: >Why couldn't I also do:
...
: > > l
: > Krak's Castle
: > ...etc...
: > > n
: > Under The Gibbet
: > ...etc...
: I was thinking of something like this for my mud...
: The builder focuses on some more or less important objects in his newly
: created room. The he creates 'rooms' which describe you standing at/beside
: these objects. That allows this kinds of actions:
I've got something similar done here, but with a bit of a different
approach.
Every room is internally defined (internally to the room) as a 3D
matrix of 1's and 0's where a 1 represents a wall, and a 0 open space.
Each value (currently/supposedly) represents a one foot cube. Objects
are located at specific coordinates within rooms.
Each player then has threshold values which define when something is
"beside them", "near them", or "at a distance". Only objects within
the largest of these categories are reported to the player at a
specific coordinate in a room (some accounting is also made for the
size/visibility of the object). (eg there is a rock in the corner of
the room, but it is so small and so far from the player that he does
not see it)
Exits are defined on verbs on rooms, _OR_ as objects at a specific
coordinate in a room.
eg (example of exit object) A player can walk north down a long room
(his coordinates merely change) until he reaches the end of the room
where there is a "north" exit object. Then, as soon as he is within
range of the exit object (ie it is "beside" him), his next "north"
command will take him out of the room as it matches the exit object
preferentially. (This allows doors for instance, to have specific
locations in walls)
eg (example of exit defined on room) The same player can walk north
down the same long room as in the previous example, but at any point
he can go "up", invoking the "up" exit verb defined on the entire
room, and taking him to some other room. (A common use might be for
an "out" direction)
Jens Malare
>Marian Griffith (Mar...@catling.iaehv.nl) wrote:
<cut>
>For verisimilitude you'd have to provide both sorts of exits.
>Okay, I'm standing by the castle:
> > l
> Krak's Castle
> A craggy gray castle is descirbed in excruciating detail...and
> mentions that I could go onto the drawbrige, or out by the hitching
> rail, by the stable, or under the gibbet.
> > gibbet
> Under the Gibbet
> <Description of gory gibbet inserted here>
>Why couldn't I also do:
> > l
> Krak's Castle
> ...etc...
> > n
> Under The Gibbet
> ...etc...
<cut>
I was thinking of something like this for my mud...
The builder focuses on some more or less important objects in his newly
created room. The he creates 'rooms' which describe you standing at/beside
these objects. That allows this kinds of actions:
---------
> l
A garden shed
This little shed serves as a storage for all kinds of tools used in the
garden. A spade has been put in a corner. (+ some additional info)
The exit from the shed is to the north. The door is opened.
-> Corner & Garden (This is the exits available. They also have aliases,
allowing you to (for example) go north to exit the
shed, and to 'go spade' to go to the corner in which
the spade is located.)
> go corner (the 'go' command could be used if your mud has a
global command named 'corner'.)
You examine the corner a bit closer. (This is a builder-customizable text
shown when someone uses that exit.
At the spade in the shed (this is another room)
The spade looks a bit rusty, but is still fully functional.
(If the builder wants, he could add a modified shed description here, as
it's not a very big room. The character should be able to see the whole
shed even if he's standing at the spades in the corner).
-> Garden
A rusty spade has been stuck into the ground.
> garden <-- I didn't care about the 'go' cmd here.
You walk out to the garden. (This is another example of the
builder-customizable text)
The garden
This is a big green garden, filled with trees. (+ all of the info which
an ordinary builder is supposed to come up with. I'm not a builder. ;)
To the south lies a small garden shed, and to the north is the back entrance
to a large, white house. To the east is a gate, and beyond it lies a gravelled
country road.
-> Shed, House, Road
> worship raidell ..erm.. ;)
---------
I haven't though of how the .wld format should look, but I'll make something
up right now. (Of course the line numbers shouldn't exists in the real file.)
1: #6205
2: A garden shed~
3: This little shed serves as a storage for all kinds of tools used in the
4: garden. A spade has been put in a corner.
5: The exit from the shed is to the north.~
6: E
7: corner spade~
8: 6206~
9: You examine the corner a bit closer.~
10: <additional exit data can be put here>
11: E
12: garden north exit
13: 6204
14: You leave the shed.~
15: <aditional exit data>
...
line 1-5 should be self-expl..
line 6 is the Exit keyword
line 7 is the aliases for that exit
line 8 is the room linked to that exit
line 9 is the text shown when walking through the exit
line 10 ... well, whatever..
and so on..
---------
I know I've made some mistakes about the spade in the room description. It
doesn't care whether the spade is still there or not. This is only an example,
though. I hope I didn't do any more logical mistakes. :)
I feel that this idea isn't more than maybe half finished, so I'd
appreciate any comments or suggestions. No flames thank you.
Btw, please forgive my bad english, as it's not my native language. :)
---
Regards, Jens Malare <rai...@dalnet.se>
David Forthoffer
gry...@IAEhv.nl wrote:
>
> >I tend to like very deep objects and rooms (this above would be quite
> >shallow).
>
Unless the descriptions were algorithmically generated on the fly.
> and from a player's point of view (because the entire mud would become
> a maze this way)
The world as we know it is a maze. We live by staying mostly in familiar
areas and only exploring interesting areas.
--
David Forthoffer
Scott Anderson
>> This might even aid in producing consistent maps =)
>
>> Absolutely. Having built both for stock dikus and for my own system,
>> I can say that the second is far easier. Of course, I always hated
>> writing exits - they never seem to match up just right. Getting rid
>> of exits makes .wld file writing ten times funner and easier. :)
>
>done a fair bit to upgrade and 'empower' the old system of rooms and links
>(the least I could do since I haven't thought of a 'better' way) but when it
>comes down to it, it *is* still rooms and links. Like I say, it'd be
>interesting to hear about your direction if you feel like it.
Well, I'm not going to get to specific, for one because I don't want
to give _all_ my secrets away, and for another because I don't think
you really need to know, anyways. It's just a matter of considering
rooms to be real locations instead of piles of text. That is, you
just say to the mud, "make me a location here, with the following
properties and contents", and it figures out how that fits into the
existing world. If the location is just a chunk of earth with a few
trees, it knows that you will be able to exit in any direction from
it; if you specify a location deep within a mountain it can look and
see there's no way out unless they are specifically mentioned in the
location, and even then the location doesn't have to say much about
them - just what direction they go and how big they are, whether
they have a door, or whatever. Then the mud figures out where it
should lead, hopefully to another location lying nearby. If this is
all done relatively correctly, it will all work together perfectly;
no need to specify the ability to go "up" in every outside room.
This is implied, since there's just air up there. Of course, if you
wish to travel freely through it, you need some means of support,
but you get the idea. And on top of this, making a transition to
another system (such as weightlessness) is extremelly easy: the
locations still exist, but the rules that govern them change. IMO
this is the strength of diku, but it doesn't go _nearly_ far
enough towards making stuff independant of the rest of the world
(from the writers standpoint: the mud does the integration).
Scott Anderson
>>Oh? I've seen it before and that's exactly what I'm proposing. It's
>>hard to make a "secret forest hideout", because people will just
>>notice "hey, I can go north here, that's funny...?" If you're
>>hidden in a tiny grove somewhere in the middle of a huge forest,
>>finding the hideout is actually going to be a real feat. And of
>>course, this is when you get to bring all those ranger-y skills into
>>play, instead of just being a warrior that can cast burning hands.
>
Things like tracking, knowledge of nature, herbalism, animal
friendship, and so on. A straightfoward warrior type should cruise
through the forest and everything seems pretty similar to him: lots
of trees, a few scampering animals, and that's it. He gets lost
pretty easily (it all looks the same, after all) and won't notice
the aforementioned Secret Forest Hideout because of the layout of a
certain tree's branches seeming artificial. The ranger, on the
other hand, will get far more rich descriptions of what are in the
room, clues from the nearby animals to help him out, information
about what has passed that way recently (tracking), and so on. And
even his ability to move more silently may help him: the bandits in
the forest hideout were able to cover up their entrance long before
the warrior guy arrived because he was making so much noise and
scaring away the animals, whereas the ranger might approach
unannounced.
Scott Anderson
>> If you want to allow unlimited movements that's an
>> awfull lot of text.
>
>Mmm, not necessarily - as Orion said, we want a system whereby the 'padding'
>of the world, the links between areas of interest, are fleshed out wherever
>possible by the engine itself, not by the builder. Of course, the more
>areas of interest there are, the better, and if that means more building
>work... =)
Correct. But the stuff is still there. The way I usually find
zones on beta muds is by walking down the road and noticing, "Hey, I
couldn't go east here yesterday!" I have trouble envisioning this
in a "real" situation.
>> Or, and that's what you'll like see happening,
>> it's not going to be very interesting text.
>
>A pity. Still, that's down to the particular Mud Admin, and whether they're
>prepared to incorporate stale, sparsely detailed areas into their worlds.
Let's be realsitic. I love writing really detailed room
descriptions, and as a player I can appreciate the mood they bring.
But 99% of the time, players are just running by with brief on. In
most cases I could just #gag %1 and run wherever I wanted, once I'm
reasonably familiar with the mud. Thus these "stale" areas are no
more or less detailed 99% of the time. There's always going to be
crap to "run" through, so why spend a lot of time on it? (I
considered cutting them out altogether, but then you end up with no
sense of spaciality.)
> [some good ideas for exit blockages snipped]
>> Another thing that seems important to me is to do away with the
>> standard 6 (or 10) exits in a room: NESWUD. Name exits after the
>> thing you'ld be heading to. That way there's less need to provide
>> reasons to block unused directions.
>
>I don't know whether I'd like to see a game with no compass directions for
>movement... I don't think it really restricts general movement all that
>much (especially when the engine supports the four secondary compass
>points). I do still like named exits in some circumstances, though, mainly
>for 'enter'ing or 'board'ing something, things like that. Something I don't
>particulary like is the LP-like method of having *anything* as an exit and
>you simply type that word to go to a new place... From the character's p.o.v
>it doesn't seem to make much sense.
I agree. It's one of those things that, when first described to me, I
thought sounded awesome. After I played a couple of LPs and MUSHes
that use this sort of thing, I realized the clean simplicity of four
to ten cardinal directions is really much better overall. There's
no reason you can't have "board ferry" and "enter house", but
without compass information every player will have a different
conception of what the world looks like. Not to mention the
practicality of it, from a coder's standpoint (simple exit coding),
a builder's standpoint (simple exit creation), and a player's
standpoint (I can type n, n, n, e, e, e just about wherever I am and
I'll take off running from that bad ass dragon after me).
>I'm not slamming your ideas, and I'd like to hear any other ideas for
>alternatives or improvements to the compass directions.
Same here.
>> >Yes, that's an excellent idea. I'd ditch the "Exits: newsd" thing,
>> >in favor of mentioning nearby rooms that are interesting, such as a
>> >door to the north or a river to the west.
> [...]
>> I totally agree with that. I allways feel stiffled by this whole
>> nesw thing.
>
>From previous things yourself and Orion have said, I believe he actually
>meant simply to lose the "Exits" message in favour of greater description,
>rather than ditch directional movement (though I could be wrong, the
>'exit-less' system sounds most intriguing =) )
No, you're right. What I meant was define a path north and east, a
door leading into an inn west, as "exits" (ick). More like, make a
path which runs north and east, place an inn off to the west with a
door on the eastern wall. The mud will figure out that up is just
air, down is the ground, west is the door to the inn, north and east
are the path, and south is a grassy hill (or whatever).
>> It is confining and forces me into 'chessboard-like'
>> designs when I would much rather have an area that seems to
>> curve gradually. [...] I really detest the way cities are
>> built in [...]
>
>I *do*, however, agree with this. (Especially if you'd written "...cities
>are built in Muds" =) ) I'd really like to see a complex town design that
>looked and felt like towns and cities in the real world (referring to those
>I've seen here in England and in mainland Europe).
I agree that this is annoying, and it would be nice to add curving
paths, but I don't think that's going to happen until we go
graphical, along with several other things that really can't be
conveyed in text format.
>I think there are other ways to do this than to scrap compass directions
>though. Perhaps coordinates for rooms inside their areas; dimensions of
>rooms; placement of exits within those rooms. The rectangular nature of a
>room was and still can be seen as merely conceptual; your exit can still
>lead southwards, whether it's in the 'middle' of the 'south wall' or in the
>'corner' of it.
Yeah. I also considered making the coordinate system very small,
thus allowing wierd alignments of small rooms, but I rather gave up
on this, for the simple reason that players just can't _see_ this.
I can visualize it as a zone writer, but the player running through
it only knows north, west, east, south, up, down. I'd be interested
in a better system (which is practical both for creating and for
using on a day to day basis), but I've yet to see anything even
mildly promising. Again, there's only so much we can do with
scrolling text.
>> Even as a player you have to be practical I'm afraid. If you're
>> willing to put up with 'You're in a forest. You see trees all around you'
>> style of descriptions then it's easy to create a forest with thousands
>> of rooms.
> [...]
>> Personally I'm not convinced that what you're proposing would actually
>> improve things that much that the sacrifice (mechanical descriptions
>> and loads and loads of empty rooms) is worth it.
>
>Remember that the aim isn't to create a system that provides the most rooms,
>it's to create a system that provides a *world* for players to explore,
>rather than X number of areas. In my eyes, the only use for the
>auto-generated rooms is to provide links between the explicitly defined
>parts of the area. There shouldn't need to be that many of them, and there
>*are* too many in one place, its perhaps time to start building some detail
>there. Does that sound like a better system? =)
Right. Actually, I disagree that there "shouldn't need to be that
many of them." There will probably be more than actually
"interesting" zonework. It's just that these will be the places
people spend most of their time. If you took all the buildings in
America, they would probably all fit into one of our smaller state
(when packed back-to-back). Yet we probably spend 80% of our time
inside them. This is similar to zones and the filler stuff. The
filler stuff is there, but not necessarily visited a lot, mostly
just passed through. And this is why you can afford to give it far
less detail. Especially rooms like everyplace in the air. If I
polymorphed into a bird I'd be pretty suprised if I couldn't fly
around in the air and end up in different places, but few people are
ever going to see these, so I wouldn't be disapointed if they all
looked pretty similar (air, and in some cases clouds).
>True, but the two are interlinked, I think. While designing I've found that
>thinking about an imaginary game and the encounters I'd like to have when
>playing it is a great way to envision the functionality of the system, and
>to design the structures and whatnot that will allow builders to make the
>things I want to play.
Oh yes, which is half the reason I build. But when I want to add
something new to my zone which isn't possible yet, I don't think
"let's toss in a spec routine on this room to let me hack through
this paper wall", I think, "what is the simplest and most basic way
to implement walls which can be destroyed?" Then when I come back
and make the wall made out of logs, I don't have much to add - I
just adjust the toughness of the wall to be quite a bit higher.
Scott Anderson
>Every room is internally defined (internally to the room) as a 3D
>matrix of 1's and 0's where a 1 represents a wall, and a 0 open space.
>Each value (currently/supposedly) represents a one foot cube. Objects
>are located at specific coordinates within rooms.
Very nice. I considered something like this but rejected it because
I couldn't think of a good, fast way to show the player what the
room looks like, and allow them to move around in such a way that it
makes sense with a minimum of perceptive power required by the
player. Just out of curiosity, what is the size of this matrix and
how is it displayed?
>Each player then has threshold values which define when something is
>"beside them", "near them", or "at a distance". Only objects within
>the largest of these categories are reported to the player at a
>specific coordinate in a room (some accounting is also made for the
>size/visibility of the object). (eg there is a rock in the corner of
>the room, but it is so small and so far from the player that he does
>not see it)
Nice - though I'm still wondering about the scale. If the grid is
small enough, it means you have to actually give a shape to your
objects (the sword takes up three matrix points in a row, whereas
the shotsword only takes up two) or be stuck with the old
Moria/Angband thing where you can drop any object into any space,
regardless of size (a dagger takes the same amount of space as a
two-handed sword). On top of this, characters have to fit in - can
you not drop an item in a certain spot when a player is standing
there?
Chris Lawrence (Contra)
Scott Anderson (sban...@sdcc10.ucsd.edu) wrote:
: >Every room is internally defined (internally to the room) as a 3D
: >matrix of 1's and 0's where a 1 represents a wall, and a 0 open space.
: >Each value (currently/supposedly) represents a one foot cube. Objects
: >are located at specific coordinates within rooms.
: Very nice. I considered something like this but rejected it because
: I couldn't think of a good, fast way to show the player what the
: room looks like, and allow them to move around in such a way that it
: makes sense with a minimum of perceptive power required by the
: player.
I'm undecided as yet. I've though of allowing the space to be
displayed ala 3D maze games:
\ /
\ +
\ +--|
+ /| |
|-------+ | |
| | | |
| | | |
|+------+ | |
+ \| |
/ +--|
/ +
/ \
But this *really* doesn't work well in a forest or open air
situation... The next idea is to allow simple rogue-style ASCII maps.
: Just out of curiosity, what is the size of this matrix and
: how is it displayed?
The size of the matrix is not set. Each room and object determines
how large (or small) its matrix should be. I have a suspicion that
the only real solution will be to do VRML encodings of the rooms.
: >Each player then has threshold values which define when something is
: >"beside them", "near them", or "at a distance". Only objects within
: >the largest of these categories are reported to the player at a
: >specific coordinate in a room (some accounting is also made for the
: >size/visibility of the object). (eg there is a rock in the corner of
: >the room, but it is so small and so far from the player that he does
: >not see it)
: Nice - though I'm still wondering about the scale.
My current scaling has one cell equal to (about) a 25cm cube.
: If the grid is
: small enough, it means you have to actually give a shape to your
: objects (the sword takes up three matrix points in a row, whereas
: the shotsword only takes up two) or be stuck with the old
: Moria/Angband thing where you can drop any object into any space,
: regardless of size (a dagger takes the same amount of space as a
: two-handed sword).
Yeah, I've been thinking about this. The patter above about the
matrix representations is actually a simplification.
I use the matrix internally for the gross checking (do we have any
hope of getting in there?). It makes for fast easy checks, and keeps
the representation for area coders understandable. The matrix
actually has no exposure outside of the object/container. Its an
internal definition which is only manipulated internally. Methods
defined on the object and container then determine whether a
specific object can fit a particular location, even if other things
are located there already. Currently I do this with a %age occupancy
value (how much of the cube does X occupy?).
: On top of this, characters have to fit in - can
: you not drop an item in a certain spot when a player is standing
: there?
With the above, yup, you can. Some day I'll make it difficult to pick
up the shield you are standing on.
James "Dragon Child" Taylor
Well... All I want to know is is it that hard to switch from a level mud
over to a skill based one??
DrgChild
Jonathan Clemens
All,
Here's my take on simulating "real" movement in a mud. In our
pre-alpha LP Mud (the name-not-yet-finalized successor to Dartmud), we're
doing everything in XYZ coordinate planes. While we're having to fudge a
bit on the geometry, we have a 2500x2500 grid that approximates the
surface of a (small) world. Each square is 4KM square (at the equator),
and can, in turn, be broken down into coordinates of 1M: X, Y, and Z.
Of course, that level of detail is not necessary except in towns. We
have servers for surface (land), underwater, air, and underground. The
rooms are all virtual, loaded and unloaded as needed. Yes, a lot of them
will look the same, but each terrain type (plains, hills, mountains, etc.)
will have N descriptions. The first time someone enters a square, it's
specific description is chosen, displayed, and then saved so that all
future adventurers will see the same thing. Add random monster
generators, random underground passage generators, and we've got a nice
background upon which to place cities, castles, caverns, and the other
staples of a mud.
Display? Well, we have a "survey" command, which gives an overhead
view, a la (Rogue/Moria/Ultima/etc.), as well as the typical Nightmare
peer and look commands. We haven't tried doing an in-the-maze
(Wizardry/Dungeon Master/Doom/etc.) display.
Interestingly enough, the entire coordinate system started for two
reasons: 1) we needed a better way to deal with 'ranged' spells, and 2) we
wanted to be able to do flying and underwater movement.
Things are still under development, and one thing we know up front is
that this is not going to be cheap in terms of memory or CPU time. We
should be open for visitors in a month or two, and will post a note to
.announce when we are.
Sorry if you Diku folks aren't interested in hearing how an LP is
approaching the same problem, but I think the idea has merit regardless of
Mud flavor.
Jonathan Clemens
http://www.aa.net/~jclemens
Travis S Casey
James \"Dragon Child\" Taylor <drgc...@chinet.chinet.com> wrote:
>Well... All I want to know is is it that hard to switch from a level mud
>over to a skill based one??
It would take more information to answer that question... for one
thing, are you talking about switching over as a player, as a
coder, or in terms of the work needed to convert a mud over?
I'd guess that you mean the last, in which case it would also
be pertinent to know what kind of mud you're talking about, whether
you already have a skill system installed or would need to build
one, and a lot of other details. There's a tremendous amount
of possible variability, depending on these and other factors.
For example, on SWmud, the main mud where I work, it would
probably not be hard; we already have a working skill system,
so the main problems would be removing levels and working out
a way to keep players from just taking any skill they want, since
some of our skills are very powerful.
It originally took us a few weeks to get the skill system that
we have in place and to tune it. In the last three or so years,
we've made a lot of changes, but only one major one that I
remember.
I doubt that it would take more than 2 months at the outside for
any mud; I'm tempted to say one month, but things always take
longer than you think, especially since time has to be allowed
for planning and testing.
Scott Anderson
> Here's my take on simulating "real" movement in a mud. In our
>pre-alpha LP Mud (the name-not-yet-finalized successor to Dartmud), we're
>doing everything in XYZ coordinate planes. While we're having to fudge a
>bit on the geometry, we have a 2500x2500 grid that approximates the
>surface of a (small) world. Each square is 4KM square (at the equator),
>and can, in turn, be broken down into coordinates of 1M: X, Y, and Z.
> Interestingly enough, the entire coordinate system started for two
>reasons: 1) we needed a better way to deal with 'ranged' spells, and 2) we
>wanted to be able to do flying and underwater movement.
Among other things! The coordinate stuff gives you many many
options, including ranged spells, thrown objects, bows/crossbows (or
guns if you're a more futuristic mud), vastly improved scaning, a
bigger world without requiring tons of memory or builder-timer, etc
etc. And IMO the best bonus is that it forces areas into a real
geometric layout, instead of making mazes by having a bunch of exits
that don't lead back to each other, or places where you can go nwse
and not be in the same room (baring spiral staircases of course).
> Things are still under development, and one thing we know up front is
>that this is not going to be cheap in terms of memory or CPU time. We
>should be open for visitors in a month or two, and will post a note to
>.announce when we are.
No, but it is definitely well worth it. When I first started
working with how I wanted to do this, I was afraid of the same thing
- but in the long run it ended up taking a fairly minimal amount of
memory and isn't really all that bad on the processor time. Slower
than standard rooms, of course, but the gain is so much more.
> Sorry if you Diku folks aren't interested in hearing how an LP is
>approaching the same problem, but I think the idea has merit regardless of
>Mud flavor.
Absolutely - this idea is already in use on both LPs and dikus. I'm
not a big LP player but I've seen it on at least three or four of
them, and I know that there are more than a dozen dikus which have
implemented this (with varying success) over the past couple years.
And it is certainly well within the scope of both r.g.m.lp and
r.g.m.diku to discuss the best ways to implement such a system.
Scott Anderson
>: >Every room is internally defined (internally to the room) as a 3D
>: >matrix of 1's and 0's where a 1 represents a wall, and a 0 open space.
>: >Each value (currently/supposedly) represents a one foot cube. Objects
>: >are located at specific coordinates within rooms.
>
>: Very nice. I considered something like this but rejected it because
>: I couldn't think of a good, fast way to show the player what the
>: room looks like, and allow them to move around in such a way that it
>: makes sense with a minimum of perceptive power required by the
>: player.
>
>I'm undecided as yet. I've though of allowing the space to be
>displayed ala 3D maze games:
>
> \ /
> \ +
> \ +--|
> + /| |
> |-------+ | |
> | | | |
> | | | |
> |+------+ | |
> + \| |
> / +--|
> / +
> / \
>
Heheh...that kicks ass, though I don't consider it practical. :)
It literally gives me shivers to think of how cool a really well
done, in-depth MUD made with a Doom/Descent/whatever 3D engine would
be. But I don't see that as happening soon, and there is still
certain benefits that the text format enjoys, including being
playable from a vast number of platforms. I also knew a guy on
AnotherMUD who was blind in RL, he just had some sort of device to
speak the text out loud. Can't do that in a graphics game...:)
>But this *really* doesn't work well in a forest or open air
>situation... The next idea is to allow simple rogue-style ASCII maps.
I played one or two MUDs that attempted this, the most notable being
3M. Don't know if it's still up, but it was based largely off the
Angband game (a Moria/Rogue derivative), of which I am a fan.
Really liked seeing items like an iron helm of might [5,+8] (+1).
Anyways...the maps had both room descs for the "general" area and
then a little Angband-type map. This allowed for a very large world
and had certain charms, altough I must say it lost a lot of the mood
found in standard room-based MUDs. I guess one thing I've always
liked is that a good log session on a MUD will often read like a
somewhat repetative book; the graphical display usually looses some
of this. But I guess many people don't pay attention to this "mood"
stuff, so perhaps that not a big loss for many.
>: >"beside them", "near them", or "at a distance". Only objects within
>: >the largest of these categories are reported to the player at a
>: >specific coordinate in a room (some accounting is also made for the
>: >size/visibility of the object). (eg there is a rock in the corner of
>: >the room, but it is so small and so far from the player that he does
>: >not see it)
>
>: Nice - though I'm still wondering about the scale.
>
>My current scaling has one cell equal to (about) a 25cm cube.
Wow! Cubic feet to us Yanks...that's a pretty small scale. Allows
for more detail, though, so if you can implement it well more power
to ya.
>: If the grid is
>: small enough, it means you have to actually give a shape to your
>: objects (the sword takes up three matrix points in a row, whereas
>: the shotsword only takes up two) or be stuck with the old
>: Moria/Angband thing where you can drop any object into any space,
>: regardless of size (a dagger takes the same amount of space as a
>: two-handed sword).
>
>Yeah, I've been thinking about this. The patter above about the
>matrix representations is actually a simplification.
>I use the matrix internally for the gross checking (do we have any
>hope of getting in there?). It makes for fast easy checks, and keeps
>the representation for area coders understandable. The matrix
>actually has no exposure outside of the object/container. Its an
>internal definition which is only manipulated internally. Methods
>defined on the object and container then determine whether a
>specific object can fit a particular location, even if other things
>are located there already. Currently I do this with a %age occupancy
>value (how much of the cube does X occupy?).
I like it! Might be tricky to do this without seeming too "hacky",
is all - I find that when you've got a small granularity like you do
but fairly non-specific spacial representations you end up with some
wacky shit from time to time; oddities that detract a little bit
from the immersiveness. On the other hand, MUDs already have this
problem so at worse you'll have a better system that's equally
hacky, and if you do it well you'll have something far better.
>: On top of this, characters have to fit in - can
>: you not drop an item in a certain spot when a player is standing
>: there?
>
>With the above, yup, you can. Some day I'll make it difficult to pick
>up the shield you are standing on.
Well again, it's judgement calls - am I standing on it, or standing
around it? But this gives you a thousand options with tactical
combat - get into a fight and find yourself backing up over that
helm you dropped earlier, triping yourself. Cool.
Anyways it sounds good. I look forward to seeing it - are you using
a code base, or from scratch?
Chris Lawrence (Contra)
Scott Anderson (sban...@sdcc10.ucsd.edu) wrote:
: >: >Every room is internally defined (internally to the room) as a 3D
: >: >matrix of 1's and 0's where a 1 represents a wall, and a 0 open space.
: >: >Each value (currently/supposedly) represents a one foot cube. Objects
: >: >are located at specific coordinates within rooms.
: >
: >: Very nice. I considered something like this but rejected it because
: >: I couldn't think of a good, fast way to show the player what the
: >: room looks like, and allow them to move around in such a way that it
: >: makes sense with a minimum of perceptive power required by the
: >: player.
: >
: >I'm undecided as yet. I've though of allowing the space to be
: >displayed ala 3D maze games:
: >
: > \ /
: > \ +
: > \ +--|
: > + /| |
: > |-------+ | |
: > | | | |
: > | | | |
: > |+------+ | |
: > + \| |
: > / +--|
: > / +
: > / \
: >
: Heheh...that kicks ass, though I don't consider it practical. :)
Yeah. For me the main problem is that it represents outdoor, say
wooded areas so poorly. The above really does not look like a small
glen in a forest...
...
: I also knew a guy on
: AnotherMUD who was blind in RL, he just had some sort of device to
: speak the text out loud. Can't do that in a graphics game...:)
Agreed -- I work next door to a totally blind programmer. She's one
of the better coders I know.
My idea would be to provide the spatial maps as an added-signal level
to the room descriptions. They would not be overtly necessary for
game play, but would add value in determining where one was, and what
was about one.
: > The next idea is to allow simple rogue-style ASCII maps.
: I guess one thing I've always
: liked is that a good log session on a MUD will often read like a
: somewhat repetative book; the graphical display usually looses some
: of this.
Good point. That aspect would be lost.
: >: Nice - though I'm still wondering about the scale.
: >
: >My current scaling has one cell equal to (about) a 25cm cube.
: Wow! Cubic feet to us Yanks...that's a pretty small scale.
Err, actually I am american. <sigh>
: Allows
: for more detail, though, so if you can implement it well more power
: to ya.
Its not hardcoded, and it is purely representational, so it really
doesn't matter when you get down to it. If you want you could think
of it as cubic feet. I just wanted something fine enouth that I could
determine a decent level of "shape" for objects without getting mired
in the details.
...
: > Currently I do this with a %age occupancy
: >value (how much of the cube does X occupy?).
: I like it! Might be tricky to do this without seeming too "hacky",
: is all - I find that when you've got a small granularity like you do
: but fairly non-specific spacial representations you end up with some
: wacky shit from time to time; oddities that detract a little bit
: from the immersiveness. On the other hand, MUDs already have this
: problem so at worse you'll have a better system that's equally
: hacky, and if you do it well you'll have something far better.
Yeah. I've got to fiddle with it a lot more before I'll see which way
it will come out.
: Anyways it sounds good. I look forward to seeing it - are you using
: a code base, or from scratch?
Totally my own code base -- an OO-like system which owes a lot to MOO,
Cool, ColdX, LP etc etc etc.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Chris Lawrence (Contra)
Scott Anderson (sban...@sdcc10.ucsd.edu) wrote:
...discussion of 3D coordinate systems snipped...
: And IMO the best bonus is that it forces areas into a real
: geometric layout, instead of making mazes by having a bunch of exits
: and not be in the same room (baring spiral staircases of course).
Bugger. I always thought this was one of the best features of classic
MUD implementations.
Scott Anderson
>...discussion of 3D coordinate systems snipped...
>: And IMO the best bonus is that it forces areas into a real
>: geometric layout, instead of making mazes by having a bunch of exits
>: that don't lead back to each other, or places where you can go nwse
>: and not be in the same room (baring spiral staircases of course).
>
>Bugger. I always thought this was one of the best features of classic
>MUD implementations.
Erm...I sure hope you're being sarcastic.
Anyways, to reiterate: one thing that any MUD can improve upon
without needing to change a single line of code is to make sure that
all the exits are correct. It drives me nuts how half the time you
can't walk out of a zone, or doing sneak, north, con dragon, south results
in "You go north, ARE YOU MAD?!, You can't go that way."
As for mazes, I can _almost_ see it here, but if you're gonna do a
maze, do a maze for fuck's sake. All the wrapping exit thing does
is make the maps players make look really funny (all those arrows
leading every which way) and let you see yourself on scan. "Hey
guys, look, there's us over there!"
Raz
[Conversation moved from 'Skill-based systems' to here =) ]
It was all I could do to contain my excitement when Scott Anderson wrote:
> Let's be realsitic. I love writing really detailed room
> descriptions, and as a player I can appreciate the mood they bring.
> But 99% of the time, players are just running by with brief on. In
> most cases I could just #gag %1 and run wherever I wanted, once I'm
> reasonably familiar with the mud. Thus these "stale" areas are no
> more or less detailed 99% of the time.
Fair enough. Anyway, as these locations will be the ones to be
auto-generated, it's not really a building problem anymore =) The engine
will likely produce descriptions more rich than they otherwise would have
been.
> No, you're right. What I meant was define a path north and east, a
> door leading into an inn west, as "exits" (ick). More like, make a
> path which runs north and east, place an inn off to the west with a
> door on the eastern wall. The mud will figure out that up is just
> air, down is the ground, west is the door to the inn, north and east
> are the path, and south is a grassy hill (or whatever).
I really have been trying to beat some kind of coordinate system into
submission lately, but there're still stumbling blocks I can't overcome.
Having the engine auto-generate locations based on surroundings and linking
these between or around the standard builder-defined locations pretty much
*requires* a move from current directions-and-vnums, that's obvious, and
using geographic coordinates seems the best alternative.
However, one of the things I would like to implement are varying sizes of
locations; eg, a large, wide street; a grand entrance hall; a cramped broom
cupboard, etc. The only way to achieve this seems to be to use a matrix
with a sensible base unit size (say, 1 meter?) and define the rooms with a
length and breadth in multiples of this. Having variably sized rooms may
cause confusion with exits, but a system such as Chris Lawrence's could be
used to plant 'exit objects' in the correct place. Fine so far, but from
here on (for me), problems present themselves.
Having these builder-defined locations of all lengths and breadths causes
all sorts of problems when trying to slot auto-generated locations around
them. They can't be a common shape/size, because they won't fit in the
nooks and crannies the builder has created. You can't create large
locations, because then the 'filler space' can be traversed too quickly, and
also the chances are you'll need too many exits to link back to defined
rooms.
So then I reluctantly considered forgetting about providing total size
freedom, and using different matrices whose dimensions were restricted to
types of space; outdoor spaces could have, say, 6m x 6m units, interiors
could be 2m x 2m. These feel like nice sizes, but now you're still forcing
spaces to conform to the next matrix size up, in this case forcing buildings
to have 3 rooms by three rooms. What if a building needs 4 rooms in a line?
What do you get, outside, in the location adjacent to the 'full' location
where most of the building is? Of course, you *should* get a slightly
smaller location which informs players that part of a building is present...
But the 'external' matrix doesn't have this much detail, it only knows about
6m x 6m units... For one desperate and foolish moment I thought of
representing the whole world on a matrix of 1m x 1m squares... =)
So I suppose at the moment I have the choice of keeping sizable locations,
but scrapping the auto-generate system; or, basically, visa versa, with the
problems given above.
What I want to know is how the hell the person running the *universe* is
keeping track of every sodding thing... <mutter> (Good chance they have a
damned sight more disk space and RAM than we do)
> >are built in Muds" =) ) I'd really like to see a complex town design that
> >looked and felt like towns and cities in the real world (referring to those
> >I've seen here in England and in mainland Europe).
>
> I agree that this is annoying, and it would be nice to add curving
> paths, but I don't think that's going to happen until we go
> graphical, along with several other things that really can't be
> conveyed in text format.
Perhaps, yeah. Then again, even a street that ran w,w,sw,sw,s,s would be
more than most towns have at the moment...
> Yeah. I also considered making the coordinate system very small,
> thus allowing wierd alignments of small rooms, but I rather gave up
> on this, for the simple reason that players just can't _see_ this.
Yep, plus it's a sod to map, and the values on the axes would get
astronomical (imaging mapping a world the size of Earth with 1m x 1m
units... circumference is, what, 35000kms? Ouch.)
Oh, while I remember: my rambling diatribe above doesn't even begin to
include the joys of the Z axis! =) It's no problem at all to allow players
to fly over any of the outdoor locations in the game, even to let them see
what's below, but I see problems when they come to any sufficiently tall
object, such as a large building or mountain range. Buildings are easier to
deal with, as they tend to rise in a straight line, but how about collision
detection for a mountainside? The mountain itself may be planned out at
ground level, but it will need to slope as it rises, and it needs to reach a
peak at a certain height. This is fine if a path up the mountain has been
defined, but if all that exists is the ground level circumference and some
tunnels and caverns within it, then there's a problem.
> >thinking about an imaginary game and the encounters I'd like to have when
> >playing it is a great way to envision the functionality of the system, and
> >to design the structures and whatnot that will allow builders to make the
> >things I want to play.
> Oh yes, which is half the reason I build. But when I want to add
> something new to my zone which isn't possible yet, I don't think
> "let's toss in a spec routine on this room to let me hack through
> this paper wall", I think, "what is the simplest and most basic way
> to implement walls which can be destroyed?"
Absolutely; what I meant by 'structures' were the parameters and definitions
used in Area files - I come up with something I want to be able to do,
design a method by which it can be extended to cater for variations on the
theme (your paper/log walls, for example), then write a description and
builders syntax which is passed on to my esteemed colleague to code into the
engine =)
Raz
Scott Anderson
>> No, you're right. What I meant was define a path north and east, a
>> door leading into an inn west, as "exits" (ick). More like, make a
>> path which runs north and east, place an inn off to the west with a
>> door on the eastern wall. The mud will figure out that up is just
>> air, down is the ground, west is the door to the inn, north and east
>> are the path, and south is a grassy hill (or whatever).
>
>I really have been trying to beat some kind of coordinate system into
>submission lately, but there're still stumbling blocks I can't overcome.
More like, you can't overcome given the amount of disk space and
processor time and RAM you have availible. :) A system is very easy
to think of, a viable one a tad more difficult.
>Having the engine auto-generate locations based on surroundings and linking
>these between or around the standard builder-defined locations pretty much
>*requires* a move from current directions-and-vnums, that's obvious, and
>using geographic coordinates seems the best alternative.
There's no reason you have to abandon one to achieve the other. Tacking
x, y, z coordiantes on every room, character, and object in the game
is pretty easy; then it's just a matter of manipulating this stuff
and keeping it all lined up correctly.
>However, one of the things I would like to implement are varying sizes of
>locations; eg, a large, wide street; a grand entrance hall; a cramped broom
>cupboard, etc. The only way to achieve this seems to be to use a matrix
>with a sensible base unit size (say, 1 meter?) and define the rooms with a
>length and breadth in multiples of this. Having variably sized rooms may
>cause confusion with exits, but a system such as Chris Lawrence's could be
>used to plant 'exit objects' in the correct place. Fine so far, but from
>here on (for me), problems present themselves.
Yeah, I thought about this one quite a bit and came up with the
conclusion that the result wouldn't be nearly worth the amount of
code, RAM, and building time that it would take. Namely, I couldn't
think of any really big way that it would benefit the player - the
only justification is that "we" (those who coded the system) would
know that our system was very geometrically correct. But I
seriously doubt it would play that much better than what I have now,
which is that each location on the matrix is a "room" of standard
MUD size, ie anything from a grand entry hall to a closet. This
makes life a whole lot easier all around, and the loss of detail
isn't as bad as it first seemed to me.
>Having these builder-defined locations of all lengths and breadths causes
>all sorts of problems when trying to slot auto-generated locations around
>them. They can't be a common shape/size, because they won't fit in the
>nooks and crannies the builder has created. You can't create large
>locations, because then the 'filler space' can be traversed too quickly, and
>also the chances are you'll need too many exits to link back to defined
>rooms.
Yep. This is the sort of thing that would be absolutely _perfect_
for a 3D, graphically-presented MUD. I've basically stuck these
ponderings away in the back of my mind, but someday (hopefully
someday soon) I'll have the oportunity to work on something like
this.
>[more size stuff]
Again, all this is pretty arbitrary - in the end it seems no better
to me than the somewhat mushy diku rooms we all know and love (?).
>What I want to know is how the hell the person running the *universe* is
>keeping track of every sodding thing... <mutter> (Good chance they have a
>damned sight more disk space and RAM than we do)
Lesse:
humungous int world_size()
/* Returns: size of the world, in atomic units. */
{
return sizeof(ATOM) * UNIVERSE_SIZE_X * UNIVERSE_SIZE_Y * UNIVERSE_SIZE_Z;
}
Now there's a project I'd like to code for. The best part?
Programmer: "When do you need this by, sir?"
Manager: "Sometime in the next five billion millenia, please."
Programmer: "Hmm, I'd better get to work then..."
>> I agree that this is annoying, and it would be nice to add curving
>> paths, but I don't think that's going to happen until we go
>> graphical, along with several other things that really can't be
>> conveyed in text format.
>
>Perhaps, yeah. Then again, even a street that ran w,w,sw,sw,s,s would be
>more than most towns have at the moment...
Again...I like this as an idea, but in implementation I'm usually
disappointed. I've got no problem with a road that just runs
straight east-west, given current resource and interface
limitations. Attempts at diagonals and curving lines within the
cardinal system usually just make life more difficult for the newbie
and annoy the experienced player.
>> Yeah. I also considered making the coordinate system very small,
>> thus allowing wierd alignments of small rooms, but I rather gave up
>> on this, for the simple reason that players just can't _see_ this.
>
>Yep, plus it's a sod to map, and the values on the axes would get
>astronomical (imaging mapping a world the size of Earth with 1m x 1m
>units... circumference is, what, 35000kms? Ouch.)
Heheh, that would kick ass. Yeah, I've left my coord system
open-ended, in hopes to someday map my entire MUD-planet. Right now
my map goes between (32000, 32000, 32000) and (32256, 32256, 32256) :)
>Oh, while I remember: my rambling diatribe above doesn't even begin to
>include the joys of the Z axis! =) It's no problem at all to allow players
>to fly over any of the outdoor locations in the game, even to let them see
>what's below, but I see problems when they come to any sufficiently tall
>object, such as a large building or mountain range. Buildings are easier to
>deal with, as they tend to rise in a straight line, but how about collision
>detection for a mountainside? The mountain itself may be planned out at
>ground level, but it will need to slope as it rises, and it needs to reach a
>peak at a certain height. This is fine if a path up the mountain has been
>defined, but if all that exists is the ground level circumference and some
>tunnels and caverns within it, then there's a problem.
Hmmmm...well, again, using the logic that "just about any attempt to
model elevation will be better than what we have currently, since we
don't have _anything_ currently", I kept this pretty simple,
defining things like hills, mountains, and cliffs by terrain type +
elevation change. Thus a fifty-foot (~18m) elevation change would
be considered a cliff, but a twelve-foot (~4m) change would just be
a gentle slope. This gets a little hacky in places - a 12 foot door
is not considered a gentle slope, even though it takes up the
"space" of the 12 foot elevation change in the wilderness, but I
treat them differently for obvious reasons. Thus the system isn't
quite a robust as I might like (making special cases), but it
certainly works. For the rough map itself, I simply use my home PC
(with good ol' Deluxe Paint IIe) in ultra-high-res SVGA to define
the basic terrain types and elevation changes, then upload it to the
machine for detail work in text. It works, but there are a thousand
improvements I'd like to make...someday, once I get this one up and
operational, and see just how well it actually goes over with the
MUD community.
Chris Lawrence (Contra)
Scott Anderson (sban...@sdcc10.ucsd.edu) wrote:
: >...discussion of 3D coordinate systems snipped...
: >: And IMO the best bonus is that it forces areas into a real
: >: geometric layout, instead of making mazes by having a bunch of exits
: >: that don't lead back to each other, or places where you can go nwse
: >: and not be in the same room (baring spiral staircases of course).
: >
: >Bugger. I always thought this was one of the best features of classic
: >MUD implementations.
: Erm...I sure hope you're being sarcastic.
Nope. Written in all seriousness as a strongly held view.
Playing with relative linkages of rooms can provide some very neat
puzzles. Ripping the following off a previous posting of mine on the
area:
--<cut>--
One of the things I always liked was creating directionally sensitive
mazes. If you've ever run into Mobius Row, the Blue Grass Path, the
White Oak Tree, or Fortress Fract, those are areas of mine. Various
aspects of all of them depend on room linkage being directionally
sensitive.
For instance, on Mobius Row, there was a north/south road consisting
of somewhere around 40 rooms in length. The interesting point was
that every room was paired with a duplicate room with an identical
desription etc. One set of the rooms was linked together going
north. The other going south. The two lines of rooms were then
cross linked if the player changed direction.
Ergo, a player could go north on Mobius row and see a certain set of
room descriptions. He could go south on Mobius Row and see the
__exact__ same descriptions (in reverse order of course). He could
say, go north on Mobius Row, and drop an object in Room#5. If he
then went north and then south again he would see the __exact__ same
room description, but the object would not be there. Go south and
then north (reversing the direction of entry) and the object would
be there.
Also double up all the shops and other places off the side of Mobius
Row with appropriate directional sensitivity based on Mobius Row.
Also add magical abilities to the room pairs so that ghost objects
appear occassionally in a room if the object is in the paired
room. Let the ghost object gradually solidify until the object is
in the paired room and is now a ghost (not gettable) in the original
room. Let the object so resonate back and forth between the room
pairs. Very occassionally let them ghost over to a third room, with
an identical description, which was not on the north south chains,
but with all exits leading to them.
** This last one gets round those people who magically transport to
the object location from figuring out what excactly is happening.
Finally make invisible random trap doors in various of the paired
rooms that randomly dump an entrant thru to the other side of the
pair without telling him that anything happened, or which change the
linkage of the room so that now the souther room is a member of the
north linkage and its pair of the souther linkage.
Similar things can be accomplished with mobiles and mobile conflict.
Things to misdirect, break the pattern, and generally allow confusion
while still presenting itself as, and appearing to be consistant.
--<cut>--
: Anyways, to reiterate: one thing that any MUD can improve upon
: without needing to change a single line of code is to make sure that
: all the exits are correct.
I will agree that sloppily designed exits are a PITA. A poor set of
exit linkages can ruin an entire area.
: It drives me nuts how half the time you
: can't walk out of a zone, or doing sneak, north, con dragon, south results
: in "You go north, ARE YOU MAD?!, You can't go that way."
That is just plumb poor design and implementation. There's no excuse
for it, but then there's no excuse for bad coding in general.
: As for mazes, I can _almost_ see it here, but if you're gonna do a
: maze, do a maze for fuck's sake. All the wrapping exit thing does
: is make the maps players make look really funny (all those arrows
: leading every which way) and let you see yourself on scan. "Hey
: guys, look, there's us over there!"
Yet more bad design. Somebody (and there are a lot of such
somebodies) got sloppy and did a slapdash job. Don't use those tripe
to damn the feature set which enables them to write crap and others to
write feature-filled quality rooms.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...