September 1997
- META: Archive report coder@ibm.net
- Virtual World Theory Jon A. Lambert
- Virtual World Theory Jeff Kesselman
- Virtual World Theory Jon A. Lambert
- Virtual World Theory Caliban Tiresias Darklock
- Virtual World Theory Nathan Yospe
- Virtual World Theory Jeff Kesselman
- Virtual World Theory Caliban Tiresias Darklock
- Psychology, psychiatry, and other such coder@ibm.net
- Psychology, psychiatry, and other such Ola Fosheim Grøstad
- OT: Attributions Shawn Halpenny
- OT: Attributions Jeff Kesselman
- OT: Attributions Chris Gray
- OT: Attributions S001GMU@nova.wright.edu
- GURPS v Hero v RuneQuest clawrenc@cup.hp.com
- combat and hit points clawrenc@cup.hp.com
- Modeling spells/skills as collections of affects S001GMU@nova.wright.edu
- Modeling spells/skills as collections of affects Travis Casey
- Modeling spells/skills as collections of affects Shawn Halpenny
- Modeling spells/skills as collections of affects Caliban Tiresias Darklock
- Modeling spells/skills as collections of affects Miroslav Silovic
- Modeling spells/skills as collections of affects S001GMU@nova.wright.edu
- Modeling spells/skills as collections of affects Miroslav Silovic
- Modeling spells/skills as collections of affects Chris Gray
- Modeling spells/skills as collections of affects S001GMU@nova.wright.edu
- Everybody was Kung-Fu fighting.. [was AI and NPCs] Matt Chatterley
- Everybody was Kung-Fu fighting.. [was AI and NPCs] Caliban Tiresias Darklock
- Everybody was Kung-Fu fighting.. [was AI and NPCs] Matt Chatterley
- Everybody was Kung-Fu fighting.. [was AI and NPCs] Ola Fosheim Grøstad
- Everybody was African fighting.. Jeff Kesselman
- MUD Design Fundamentals (Was: Looking for clawrenc@cup.hp.com
- Critical Hits clawrenc@cup.hp.com
- Critical Hits Jeff Kesselman
- MAGE 2 MAGE Spell System clawrenc@cup.hp.com
- MAGE 2 MAGE Spell System Travis Casey
- ramblings on resets and other random things Travis Casey
- ramblings on resets and other random things Adam Wiggins
- Porn threads clawrenc@cup.hp.com
- Porn threads Jeff Kesselman
- Porn threads Nathan Yospe
- Invitation to mudlist, a mailinglist for concepts in mud design Ola Fosheim Grøstad
- Mud Games Jon A. Lambert
- Affecting the world Marian Griffith
- Affecting the world Matt Chatterley
- Affecting the world ##Make Nylander
- Affecting the world Miroslav Silovic
- Affecting the world Maddy
- Affecting the world Jon A. Lambert
- Affecting the world Marian Griffith
- Affecting the world Matt Chatterley
- Affecting the world Jon A. Lambert
- Affecting the world Matt Chatterley
- Affecting the world Jon A. Lambert
- Affecting the world Matt Chatterley
- Affecting the world Nathan Yospe
- Affecting the world Matt Chatterley
- Affecting the world Jon A. Lambert
- Affecting the world clawrenc@cup.hp.com
- Affecting the world Caliban Tiresias Darklock
- Affecting the world clawrenc@cup.hp.com
- Affecting the world Matt Chatterley
- Affecting the world Adam Wiggins
- Affecting the world Caliban Tiresias Darklock
- Affecting the world Jon A. Lambert
- Affecting the world Caliban Tiresias Darklock
- Affecting the world clawrenc@cup.hp.com
- Affecting the world Matt Chatterley
- Affecting the world clawrenc@cup.hp.com
- Affecting the world Marian Griffith
- Affecting the world clawrenc@cup.hp.com
- Affecting the world Chris Gray
- Affecting the world Jon A. Lambert
- Affecting the world Chris Gray
- Affecting the world Jon A. Lambert
- Affecting the world Jon A. Lambert
- Affecting the world Marian Griffith
- Affecting the world Derrick Jones
- Affecting the world coder@ibm.net
- Affecting the world Jon A. Lambert
- MUD Development Digest Matthew R. Sheahan
- NPC AI and Learning. Michael Hohensee
- NPC AI and Learning. Travis S. Casey
- NPC AI and Learning. Michael Hohensee
- NPC AI and Learning. Alex Oren
- Getting players to cooperate (was Modeling spells/skills as collections of affects) Maddy
- Problems with admin thru consensus (long) clawrenc@cup.hp.com
- Problems with admin thru consensus (long) Jon A. Lambert
- Mud Games (fwd) Make Nylander
- Resource management Felix A. Croes
- Resource management clawrenc@cup.hp.com
- PK again (was: Character evolution) Marian Griffith
- PK again (was: Character evolution) Adam Wiggins
- PK again (was: Character evolution) Nathan Yospe
- PK again (was: Character evolution) Chris Gray
- PK again (was: Character evolution) Jon A. Lambert
- PK again (was: Character evolution) Matt Chatterley
- PK again (was: Character evolution) Marian Griffith
- PK again (was: Character evolution) Matt Chatterley
- PK again (was: Character evolution) Maddy
- PK again (was: Character evolution) Jon A. Lambert
- PK again (was: Character evolution) Marian Griffith
- PK again (was: Character evolution) Caliban Tiresias Darklock
- PK again (was: Character evolution) clawrenc@cup.hp.com
- PK again (was: Character evolution) Adam Wiggins
- PK again (was: Character evolution) Jon A. Lambert
- (subject missing) HALE2 Root
- (subject missing) HALE2 Root
- (subject missing) HALE2 Root
- (subject missing) HALE2 Root
- (subject missing) HALE2 Root
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Chris Gray
- Usability and interface and who the hell is supposed to Maddy
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Matt Chatterley
- Usability and interface and who the hell is supposed to Miroslav Silovic
- Usability and interface and who the hell is supposed to Adam Wiggins
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Travis Casey
- Usability and interface and who the hell is supposed to Miroslav Silovic
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Nathan Yospe
- Usability and interface and who the hell is supposed to coder@ibm.net
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Marian Griffith
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Marian Griffith
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Adam Wiggins
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Maddy
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to Ola Fosheim Grøstad
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to be playing, anyway? ##Make Nylander
- Something complete different Marian Griffith
- Something complete different Brandon J. Rickman
- Something complete different Marian Griffith
- Something complete different Brandon J. Rickman
- Something complete different Marian Griffith
- Something complete different Brandon J. Rickman
- Something complete different Matt Chatterley
- Something complete different Jon A. Lambert
- Something complete different clawrenc@cup.hp.com
- Something complete different Travis S. Casey
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo Nathan Yospe
- Usability and interface and who the hell is suppo Maddy
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Todd Lair
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Ola Fosheim Grøstad
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Adam Wiggins
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Adam Wiggins
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Nathan Yospe
- Usability and interface and who the hell is suppo Shawn Halpenny
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Ola Fosheim Grøstad
- Usability and interface and who the hell is suppo Adam Wiggins
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Maddy
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Brandon J. Rickman
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo Brandon J. Rickman
- Usability and interface and who the hell is suppo Michael Hohensee
- Usability and interface and who the hell is suppo Miroslav Silovic
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Matt Chatterley
- Usability and interface and who the hell is suppo Ola Fosheim Grøstad
- Usability and interface and who the hell is suppo Travis Casey
- Usability and interface and who the hell is suppo coder@ibm.net
- Usability and interface and who the hell is suppo Maddy
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Matt Chatterley
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Adam Wiggins
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Marian Griffith
- Usability and interface and who the hell is suppo Caliban Tiresias Darklock
- Usability and interface and who the hell is suppo Chris Gray
- Usability and interface and who the hell is suppo clawrenc@cup.hp.com
- Usability and interface and who the hell is suppo Jon A. Lambert
- Usability and interface and who the hell is suppo Travis Casey
- games gender bias (Affecting the world) Ola Fosheim Grøstad
- games gender bias (Affecting the world) clawrenc@cup.hp.com
- games gender bias (Affecting the world) Caliban Tiresias Darklock
- games gender bias (Affecting the world) Michael Hohensee
- games gender bias (Affecting the world) Marian Griffith
- games gender bias (Affecting the world) Adam Wiggins
- games gender bias (Affecting the world) Ola Fosheim Grøstad
- games gender bias (Affecting the world) clawrenc@cup.hp.com
- games gender bias (Affecting the world) Marian Griffith
- games gender bias (Affecting the world) Ola Fosheim Grøstad
- games gender bias (Affecting the world) Adam Wiggins
- games gender bias (Affecting the world) Jon A. Lambert
- games gender bias (Affecting the world) Marian Griffith
- games gender bias (Affecting the world) Marian Griffith
- games gender bias (Affecting the world) Ola Fosheim Grøstad
- games gender bias (Affecting the world) Marian Griffith
- games gender bias (Affecting the world) Caliban Tiresias Darklock
- Usability and interface Adam Wiggins
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Adam Wiggins
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Adam Wiggins
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Adam Wiggins
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Travis Casey
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Travis Casey
- Usability and interface Alex Oren
- Usability and interface Adam Wiggins
- Usability and interface Dan Shiovitz
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Maddy
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Nathan Yospe
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Jon A. Lambert
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Jon A. Lambert
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Broly
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Maddy
- Usability and interface Maddy
- Usability and interface Adam Wiggins
- Usability and interface Matt Chatterley
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Matt Chatterley
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Shawn Halpenny
- Usability and interface Adam Wiggins
- Usability and interface Shawn Halpenny
- Usability and interface Ola Fosheim Grøstad
- Usability and interface Koster, Raph
- Usability and interface Jon A. Lambert
- Usability and interface Ola Fosheim Grøstad
- Usability and interface Chris Gray
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Caliban Tiresias Darklock
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Jon A. Lambert
- Usability and interface Maddy
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Maddy
- Usability and interface Travis Casey
- Usability and interface Caliban Tiresias Darklock
- Usability and interface Broly
- Usability and interface Nathan Yospe
- Usability and interface Marian Griffith
- Usability and interface Broly
- Usability and interface Marian Griffith
- Usability and interface Matt Chatterley
- Usability and interface Marian Griffith
- Usability and interface Matt Chatterley
- Usability and interface Broly
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Broly
- Usability and interface coder@ibm.net
- Usability and interface Jon Leonard
- Usability and interface Chris Gray
- Usability and interface Todd Lair
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Adam Wiggins
- Usability and interface Maddy
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Jon A. Lambert
- Usability and interface Ola Fosheim Grøstad
- Usability and interface Koster, Raph
- Usability and interface Ola Fosheim Grøstad
- Usability and interface clawrenc@cup.hp.com
- Usability and interface Adam Wiggins
- Usability and interface Chris Gray
- Usability and interface and who the hell is supposed to Chris Gray
- Types of game Matt Chatterley
- Types of game Caliban Tiresias Darklock
- Types of game Koster, Raph
- Types of game Marian Griffith
- Types of game Matt Chatterley
- Types of game Adam Wiggins
- Types of game Travis Casey
- Types of game Travis Casey
- Types of game Marian Griffith
- Types of game coder@ibm.net
- Types of game Ola Fosheim Grøstad
- Types of game clawrenc@cup.hp.com
- To flame or not to flame (was: Usability and ...) Ola Fosheim Grøstad
- To flame or not to flame (was: Usability and ...) Caliban Tiresias Darklock
- To flame or not to flame (was: Usability and ...) clawrenc@cup.hp.com
- To flame or not to flame (was: Usability and ...) Nathan Yospe
- To flame or not to flame (was: Usability and ...) Adam Wiggins
- META: To flame or not to flame (was: Usability and ...) coder@ibm.net
- (fwd) Avios 1.2.0 clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to be Maddy
- META: To flame or not to flame (was: Usability and ...) clawrenc@cup.hp.com
- META: To flame or not to flame (was: Usability and ...) Ola Fosheim Grøstad
- META: To flame or not to flame (was: Usability and ...) clawrenc@cup.hp.com
- META: To flame or not to flame (was: Usability and ...) Ola Fosheim Grøstad
- Stranger in a Strange Land (was Usability and interface clawrenc@cup.hp.com
- Stranger in a Strange Land (was Usability and interface Koster, Raph
- Stranger in a Strange Land (was Usability and interface Ola Fosheim Grøstad
- Stranger in a Strange Land (was Usability and interface Chris Gray
- Stranger in a Strange Land (was Usability and interface Ola Fosheim Grøstad
- Stranger in a Strange Land (was Usability and interface clawrenc@cup.hp.com
- Stranger in a Strange Land (was Usability and interface clawrenc@cup.hp.com
- Stranger in a Strange Land (was Usability and interface Caliban Tiresias Darklock
- Stranger in a Strange Land (was Usability and interface Miroslav Silovic
- Stranger in a Strange Land (was Usability and interface Caliban Tiresias Darklock
- Stranger in a Strange Land (was Usability and interface clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Broly
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Adam Wiggins
- Usability and interface and who the hell is supposed to Caliban Tiresias Darklock
- (fwd) Key, new server code in Java coder@ibm.net
- A place of my own Jon A. Lambert
- A place of my own Shawn Halpenny
- A place of my own Maddy
- A place of my own clawrenc@cup.hp.com
- A place of my own Koster, Raph
- A place of my own Ola Fosheim Grøstad
- A place of my own Caliban Tiresias Darklock
- A place of my own Marian Griffith
- Usability and interface and who the hell is supposed to clawrenc@cup.hp.com
- OT: Usability and interface Jon A. Lambert
- OT: Usability and interface clawrenc@cup.hp.com
- more classes (Usability and interface and who the hell is suppo) Ola Fosheim Grøstad
- more classes (Usability and interface and who the hell is suppo) Brandon J. Rickman
- more classes (Usability and interface and who the hell is suppo) clawrenc@cup.hp.com
- more classes (Usability and interface and who the hell is suppo) Brandon J. Rickman
- more classes (Usability and interface and who the hell is suppo) Matt Chatterley
- more classes (Usability and interface and who the hell is suppo) Matt Chatterley
- more classes (Usability and interface and who the hell is suppo) Marian Griffith
- UI Issues: Anti-scripting techniques Brian Price
- UI Issues: Anti-scripting techniques Travis Casey
- UI Issues: Anti-scripting techniques Adam Wiggins
- UI Issues: Anti-scripting techniques Brian Price
> From: Adam Wiggins <nightfall@user2.inficad.com>
> [Travis:]
> > Brian Price <blprice@bedford.net> wrote:
<snip practice concept>
>
> Yup. This is something that gives a lot of people trouble when they first
> play Arctic. They assume that by typing sneak or hide over and over, they
> can raise those skills. This is not true at all, of course. The best way to
> learn hide is to find a heavily populated area and try to hide for a long time.
> The best way to learn to sneak is to sneak around town, since lots of perceptive
> people are going to have a chance to notice you. Early on you may never manage
> to sneak or hide very well at all, but you still learn from your failures.
> Later on it becomes damn near impossible to learn your skill by just doing it
> around town, but by successfully hiding against very 'high level' mobiles,
> especially aggressive ones, you can still learn.
I'd be very interested to know how much code complexity and data
storage requirements the above added to Artic. It seems to me that
the above is a relatively heavyweight solution, albiet quite a
realistic one given the practice premise.
<snip lockpicking example and resultant spam-improvement problem definition>
> > locking it after each success. In many places, this would be prevented
> > if there were patrols in the area or alarms attached to the lock --
> > realistically, one shouldn't be able to simply sit in the middle of a
> > military base and work on picking a lock without having to worry about
> > being discovered. This leads into the next point...
> > 2. One shouldn't be allowed to indefinitely repeat the exact same attempt
> > and keep learning from it. In the example with the lock, there's only
> > so much one can learn about lockpicking from one lock -- after one or
> > two successful attempts, the character should have to move on to another
> > lock to learn more.
Ok, I'll go way out on a limb here, I don't see any problem
whatsoever with someone trying to pick a lock multiple times and
eventually succeeding given the following:
Random events may limit the time they have to pick the lock.
Failure may have repercussions such as triggering an alarm and/or
breaking a tool. No experience is gained from the task. No skill
improvement results from the attempts.
> Arctic keeps track of what your character does. Learning to lockpick on
> Arctic involves cruising around to every town or fort in the game (there are
> quite a few of both) to try your hand at picking their locks. This is,
> actually, just an extension of their combat regulartor, which keeps track of
> what NPCs you kill frequently. You learn very little from fighting against
> NPCs you fight all the time, which prompts players to explore, just in the hopes
> of finding someone new to fight, and thereby getting a chance to learn their
> weapons skills and such. I rather boggled at how they managed to store
> all this info for their playerbase which hangs out around 15,000 when they
> came up 6 years ago (given technology at the time), but now it seems much less
It sounds as if the Artic regulator approach was required to solve a
game design flaw, namely the lack of an ecology. Given that such a
mechanism was already 'required' extending it to solve a flaw in skill
improvement would make sense.
> impressive. At any rate, it works very well. Once you realize how things
> work, you have a lot of motivation to explore. While playing a thief I
> don't remember anything quite as gratifying as locating a new trap that I
> hadn't tried to disarm before, particularly if it was a tough one.
I had a rather long and involved response to this but I'll sum it up
simply; in reality very little skill improvement occurs during the
normal exercise of a skill. Rapid improvement comes about through
training. A fully realistic model would undertake to merge both
cases. However, given the long time periods involved for gradual
improvement through normal exercise of a skill, in the design of a
playable and implementable game, I'd much prefer to sidestep the
gradual improvement altogether.
The on-topic relevance is that there is no possibility of
spamming/automating skill improvement with the training model.
I rather like solutions which require 0 code and 0 data.
> > The Arduin paper RPG has a wonderful concept which is related to this.
> > In it, once a character has succeeded or failed at a particular task,
> > that character doesn't need to roll for it again unless circumstances
> > change in a way that will lower or raise (respectively) his/her chance
> > of success. For example, if a thief fails to pick a lock, he/she will
> > fail on any subsequent attempt to pick that lock until circumstances
> > change in his/her favor (e.g., the thief gets better at picking locks,
> > obtains a better set of lockpicks, or can spend significantly more time
> > trying). In general, this only applies to long-term actions, not to
> > "instant" actions -- for example, it doesn't apply to hit rolls in
> > combat.
>
> Very nice - player friendly as well as being a good way to limit scripting.
Yes, but at what cost? Unfortunately muds are resource limited, some
muds have to be rebooted every few days to be playable, others
require greater and greater payments to site providers as they
outstrip the memory space allotted. The more data that is tied up in
skill tracking, the more code that is tied up in patching game flaws,
the less that is available for objects, mobs, areas, and code that
makes the game itself better.
Beyond that, I'm not at all certain that such a system is realistic.
Just because I pick a lock once doesn't mean that the next time I try
I don't break a pick or fail due to a case of the jitters
.
> > 3. Difficulty should play a role -- if something is so easy that it can
> > be done automatically, or nearly so, the character shouldn't learn
> > anything by doing it. To give a few examples, a skilled programmer
> > won't learn anything by writing yet another implementation of a
> > bubble sort, calculus teacher isn't going to learn anything about
> > math while balancing a checkbook, and Bobby Fischer isn't going to
> > learn anything about chess by playing me. :-)
The following is all off-topic but I can't let the above pass without
comment:
A skilled programmer will learn by embarking on a course of
self-improvement, experimentation, advanced courses, etc. I doubt
any learn much about the art of programming from hammering yet
another customer spec into submission. A calculus teacher is very
unlikely to learn much of anything from teaching calculus past his
probationary period, if said teacher is to advance in his knowledge
of calculus, he or she would have to attend fewer union meetings and
embark upon a course of study and/or experimentation. Where chess is
concerned, you don't learn much playing the game once you've mastered
the basics. You learn by analyzing past games, studying the moves of
the masters, and experimenting with alternatives to played games at
various points.
>
> And this is what we use. Thus, fighting the same sorts of things over and
> over should eventually cease to help you, since your skill will advance past
> theirs. Unless they learn as quickly as you...
>
> > 4. Lastly, characters should start out reasonably competent in their
> > skills and the players should know that. There's much less
> > incentive for a player to raise a skill which has a 40% chance of
> > success than one that has a 1% chance of success, and the time spent
> > also seems less rewarding -- moving from 1% to 10% seems like a huge
> > difference, but 40% to 49% is less exciting.
>
> IMO on a scale of 1 to 100, 0 to 20 should mean you suck and actually
> fail most of the time, 20 through 50 should mean you're competent but not
> anything special, 50 through 80 means you're really good, and 80+ means
> you are a true master. Arctic suffers from this quite a bit. Anything
> up to an 'average' rating usually means you totally blow, and can barely
> do it at all. This is annoying because it takes quite a while to get
> any skill up to average, even if you know what you're doing. I feel that
> it shouldn't take long to get a skill usable (ie, being able to swim or ride
> a bike) but getting from there to being a master (swiming the english channel
> or riding in the tour de france) should be a serious endevour.
I'd much rather see: basic skill level - you no longer require
training wheels. Medium skill level - you can reliably shift gears
and have a good idea when to be in what gear. Advanced skill level -
you can pace yourself to cover as much ground as possible in a given
period of time. Master skill level - you can specify and make use of
custom designed bicycles which enhance your performance.
An idea that Traveller advanced was that many skills were
performable at a minimal level of competence without any training. A
bicycle with training wheels makes a fair example.
> > On SWmud, we made a mistake that relates to this -- we show character's
> > skill levels as a percentage of how much they can learn, as opposed to
> > a chance of success. Several things factor into chance of success on
> > SWmud -- a base chance of success, score in a related ability, whether
> > the guild which gets the skill is your primary guild, and, lastly, a
> > learned ability with the skill. Hence, a character with "0%" listed
> > for a skill may actually have a 40% chance of success -- and a character
> > with "100%" listed might only have an 80% chance of success. "0%" means
> > only that the character has no learned ability with the skill, and
> > "100%"
> > means only that the character has reached the maximum score in the
> > learned portion of the skill.
>
> Yup. We ommit the % since it's misleading in this way. A rating of 30
> is essentially average; most people think of 50 or even 75 as being average
> when you rate it by percentage.
I'm against numeric displays of anytype except where they represent
something that could be realistically measured on some scale within
the game. In most cases I believe they lead directly to power gaming
attempts and indirectly to scripting/spamming. If you simply must
use a gradual improvement % based skill system, I believe that using
incompetent for 01-10, barely competent for 11-20, etc. would give
the necessary feedback to the player while doing much to hide any
gains from spamming or scripting, reducing the incentive as it were.
> > >I believe that by carefully examining the game constructs used in a
> > >mud design, one can eliminate much, if not all, of the incentive and
> > >opportunity for scripting. In my opinion, this results in a better
> > >game. After all, ask yourself this question: "Why is the player
> > >scripting this process?". In many cases the answer is exceedingly
> > >obvious: "Because it is mind-numbingly boring and adds nothing to
> > >gameplay." Granted, pk/combat scripting is another issue and will
> > >likely still require solutions such as presented in the first and
> > >second attack discussions.
> >
> > I'd submit that something can add to the *game* without adding to
> > *gameplay*.
> > Also, boredom doesn't seem to be a part of it, from my point of view -- I
> > think it would be much more interesting to actually *play* the game instead
> > of mindlessly focusing on simply raising one or two skills as fast as one
> > can. IMHO, many scripters are simply looking for an advantage -- a way to
> > advance more quickly than the other players can by "playing" either faster
> > or more often.
>
> Well, speaking for myself, I have scripted many things on muds. All of
> them were things that I thought were mind-numbingly boring, but that I had
> to do in order to continue my advancement. IMO a good desing rules out the
> need or desire for scripting. If there are a given set of actions that
> I need to repeat on a regular basis without any variation, it should be
> automated. If it is not, I will automate it myself. It's that simple.
> For example: if creating a healing potion means getting a flask and two herbs
> from my pack, mixing the herbs and enchanting the potion, without variation -
> I will eventually automate it. (If I have to do it enough.) If it means
> analyzing the person's wound, deciding which herbs I need, going and finding
> them, grinding them up just so, making a potion for internal wounds or a
> salve for external, applying the concoction in different ways to the wounded
> area, watching the effects on the flesh after the concoction is applied..
> then it's difficult and unproductive for me to automate it, plus I won't want
> to, so I won't.
I fully agree, you've grasped my meaning despite my words :)
Brian Price
Brian Price
<blprice@bedford.net> - UI Issues: Anti-scripting techniques Travis Casey
- UI Issues: Anti-scripting techniques Shawn Halpenny
- UI Issues: Anti-scripting techniques Adam Wiggins
- UI Issues: Anti-scripting techniques Shawn Halpenny
- UI Issues: Anti-scripting techniques Adam Wiggins
- UI Issues: Anti-scripting techniques Travis Casey
- UI Issues: Anti-scripting techniques Broly
- UI Issues: Anti-scripting techniques coder@ibm.net
- UI Issues: Anti-scripting techniques Marian Griffith
- UI Issues: Anti-scripting techniques Brian Price
- UI Issues: Anti-scripting techniques Brian Price
- UI Issues: Anti-scripting techniques Travis Casey
- UI Issues: Anti-scripting techniques Adam Wiggins
- UI Issues: Anti-scripting techniques Brian Price
- UI Issues: Anti-scripting techniques Brandon J. Rickman
- UI Issues: Anti-scripting techniques Caliban Tiresias Darklock
- UI Issues: Anti-scripting techniques Brandon J. Rickman
- UI Issues: Anti-scripting techniques Travis Casey
- UI Issues: Anti-scripting techniques clawrenc@cup.hp.com
- UI Issues: Anti-scripting techniques Brian Price
- UI Issues: Anti-scripting techniques Maddy
- UI Issues: Anti-scripting techniques clawrenc@cup.hp.com
- UI Issues: Anti-scripting techniques Maddy
- UI Issues: Anti-scripting techniques coder@ibm.net
- UI Issues: Dealing with Lag Brian Price
- UI Issues: Dealing with Lag clawrenc@cup.hp.com
- Usability and interface and who the hell is supposed to Michael Hohensee
- Usability and interface and who the hell is supposed to Shawn Halpenny
- Usability and interface and who the hell is supposed to Michael Hohensee
- Usability and interface and who the hell is supposed to be playing Shawn Halpenny
- Usability and interface and who the hell is supposed to be Maddy
- Stranger in a Strange Land (was Usability and interface and Maddy
- War and language (Was: Usability and interface and who Matt Chatterley
- Focus (Was: Usability and interface and who the hell is suppo) Matt Chatterley
- Usability and interface and who the hell is suppon Adam Wiggins
- Balance of Character Power Jon A. Lambert
- Balance of Character Power clawrenc@cup.hp.com
- Balance of Character Power Travis Casey
- Balance of Character Power Shawn Halpenny
- What to do with the first summary? Marian Griffith
- NPC AI Brian Price
- Reusable plots for quests Brian Price
- Reusable plots for quests clawrenc@cup.hp.com
- Reusable plots for quests Brian Price
- Reusable plots for quests Travis Casey
- Reusable plots for quests Brian Price
- Reusable plots for quests Travis Casey
- Reusable plots for quests Brandon J. Rickman
- Reusable plots for quests Travis Casey
- Reusable plots for quests Adam Wiggins
- Reusable plots for quests coder@ibm.net
- Reusable plots for quests Travis S. Casey
- Reusable plots for quests coder@ibm.net
- Reusable plots for quests Adam Wiggins
- Reusable plots for quests coder@ibm.net
- Reusable plots for quests Travis S. Casey
- Reusable plots for quests coder@ibm.net
- Reusable plots for quests Derrick Jones
- Stranger in a Strange Land (was Usability and interface and Maddy
- Stranger in a Strange Land Adam Wiggins
- Stranger in a Strange Land clawrenc@cup.hp.com
- Stranger in a Strange Land Adam Wiggins
- Stranger in a Strange Land coder@ibm.net
- Stranger in a Strange Land (was Usability and interface Adam Wiggins
- Dupes coder@ibm.net
- Stranger in a Strange Land (was Usability and interface Ola Fosheim Grøstad