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
- 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
It is amazing to me how untactfully I can manage to state ideas and
opinions at times. Hopefully this thread can generate some useful
ideas in spite of my poor choice of words.
> From: "Travis Casey" <efindel@polaris.net>
> Brian Price <blprice@bedford.net> wrote:
>
> >The first area of attack, preventing multiple commands and repetitive
> >sequences of commands, is simple, even trivial. Multiple commands
> >can be defeated easily in five steps:
<snip Scripters Anonymous 5 step program>
> We've done something like this on SWmud -- specifically, we made
> a running total of commands entered in the last four seconds. If
> that total exceeds a threshold, commands are rejected with an error
> message. If it exceeds a second, higher threshold, the character is
> logged off from the mud.
>
> Before implementing it, we did a bit of testing to find a good rate --
> one that wouldn't bother fast typers too often. If I remember right,
> we wound up choosing 10 command/four seconds for the first threshold,
> and 20/four seconds for the second. Those might not be right (I haven't
> gone and looked at the code to be sure), but whatever the rates were,
> we were rarely able to even get a warning issuing a one-letter command
> as fast as we could manually.
Yep, SWmud is where I first saw any implementation of that general
idea. It seems to work well, but does not rule out mapping hotkeys
to say, a sequence of 4 commands. I'm not even certain that small
command sequences can be eliminated using the telnet protocol given
the way packets sometimes 'bunch up' in a stream connect over the
net. It might require a custom client to implement some parts of
the 5 step idea.
> >Repetitive sequences of commands to a certain depth could be detected
> >using a command history buffer together with a simple counter
> >and flag a wizard or a wizard-bot. A wizard-bot would simply halt
> >the player's input (perhaps moving them to a temporary safe zone)
> >until the player answered one of a number of randomly selected
> >questions. If it was a false detection, no (or little) harm
> >comes to the player, if a correct detection, an unattended script is
> helpless
> >to respond. All detections, true and false, should be logged.
>
> That depends to some extent on how the mud's set up... I've heard people
> discussing the idea of a mud where the player would have to manually issue
> a command to attack a monster each round of combat (yes, I think they're
> insane too). If someone actually implemented a system like that, then
> a history-checker would often get false positives on it.
Yes, some command systems would choke a history-checker and even a
decent system might cause false positives. That's why I'd propose
using either a sophisticated wiz-bot to check for an actual player,
or an actual wiz/imp, or even just logging it. In general I'm
assuming that a well done command system and mud implmentation will
require little repetitive input from the player.
> >The second area of attack, confusing and complicating triggers could
> >be a lot of fun. (Yes I have a warped view of fun) Take the common
> >case of a pk script which has a tracking attack trigger. Instead of
> >always having the mud display the text:
> > " Boffo flees and leaves to the east."
> >Use a randomly selected phrase such as:
> > "Panicing, Boffo runs to the east in terror."
> >or "Boffo quickly retreats eastward."
> >
> >In combination with multiple phrases, add random events that
> >duplicate much of the likely trigger text, such as:
> > "Paniced by the fight, a cat leaves to the east."
> >
> >Cleverly selected random event phrases could easily make the use of
> >triggers disasterous, or at least counter-productive, for the user.
>
> I like these ideas... not only do they make triggers harder to use,
> but they also add variety to the mud. The only down side I see is that
> someone has to come up with the various alternative phrasings and program
> the random events.
I was primarily aiming at preventing combat triggers with this idea
and being most familiar with diku/merc/rom muds was assuming that
combat would be isolated structurally into one place. Of course, the
idea could likely be applied elsewhere and could perhaps entail extra
work for builders. Also my mud vision includes random events as an
integral part so that programming and development of those events
would not be an 'extra' step. It would still require careful
selection of phrasing however.
<snip example of my lack of tact>
>
> As someone who has often championed such systems, and who has helped
> to implement several of them, I have to take exception to this
> comment. :-) The basic idea behind such a system is that a character
> should be able to get better at a skill by practicing it. This is
> quite realistic, and, ideally, should lead to players being better
> able to define their characters and should encourage roleplaying.
> Quite simply, a warrior *should* get better at fighting by fighting,
> a thief *should* get better at stealing by stealing, and a chef *should*
> get better at cooking by cooking.
To a point I agree with you, however... in general basic training of
some sort is required to gain an initial level of competency in a
given skill. After some time spent actually using the skills, one
may profit from advanced training in the skill. Likewise after a
period of using the skill at the more advanced level, one might be
able to recieve 'masters' level training, allowing one to progress
eventually to mastery of the skill.
A poorly trained cook will _not_ get better at cooking by doing it
(my gf is a prime example here), there must be in addition to
practice, a desire and a conscious effort to advance in the art.
While I suppose in some exceptional case a chef might go from
flipping burgers in a fast food joint to becoming a world-renowned
chef by sheer practice, this would not be the normal case by any
means. Of course, we all know that training alone does not suffice
either, I'd bet we all know of individuals who have completed some
course of training, barely passing, and never achieved any degree of
success in the trained skill. (Such individuals do tend to become
managers however :) j/k).
> The problem, IMHO, is not in the concept, but in the implementation.
> I think Brian's talking about the implementation of this idea that he's
> seen on SWmud, so I'm going to talk specifically about that implementation
Actually the implementation on SWmud (for reasons you detail below)
is one of the better implementations of that general idea that I've
seen. My main exposure to skill systems has been from Diku/Merc/Rom.
> and its problems. Hopefully some of this will still be helpful to others
> implementing such systems -- sort of a warning about what I'd change if
> I could do it over.
>
> 1 - There are many cases where it's possible to attempt to use a skill,
> and thereby advance it, when the character simply shouldn't be able
> to. The best example of this is hiding -- on SWmud, any character who
> can hide can try to hide at any time, and gets advancement in the
> hiding skill for it. A more logical implementation would only test
> the skill, and therefore allow for advancement, when there was a chance
> that someone would notice you -- after all, it's hard to improve a skill
> with no feedback about whether you're doing it right!
Yep, couldn't agree more. However I'm in favor of light-wieght
solutions to these types of problems.
> In some cases, this is due to a lack of reality in other parts of the
> game. For example, a player who wants his/her character to get better
> at lockpicking can simply find a lock and try to pick it over and over,
> 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...
Yes, this is actually (in my mind) an example of poor mud design.
Failure at a task should in many cases have repercussions, when they
don't you end up with the above situation.
> 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.
>
> 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.
While a very interesting and seemingly (at first glance anyways) a
realistic solution, implementing this in a mud would (I think) be a
rather involved task.. ie. a heavyweight solution.
> 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. :-)
Nod nod, once you start down this road, the level of complexity
increases greatly in order to correctly represent situations as you
describe in the above paragraph.
> 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.
On this we are in 100% agreement. While basic electronics training
in the Air Force did not make me a circuit designer or engineer, it
did allow me to have a fair degree of proficiency in soldering and
unsoldering components from a pc board (among other things).
<snip SWmud specific info>
> >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.
In many cases, in order to 'play the game' a certain level of
proficiency in some skills is pretty much required. All skill
systems I have seen implemented to date (granted a narrow subset)
have all had the fatal flaw of being imbedded in a game system that
rewarded the 'powergamer'. Every player I have observed on such
muds (unless just plain clueless newbies that never stuck with the
game) all engaged in spamming of one sort or another to increase
skill levels to a certain point. I have adopted a playing style on
such muds which incorporates skill improvement efforts into leveling
efforts and even manage to solve a few quests/explore a bit in the
process, still in many cases, I'm reduced to useless spamming to
increase skills to a competitive level.
Having gone this far, even though it is somewhat off topic, I'd be
remiss if I did not present an alternative, lightwieght, solution.
First, the premise I'm operating under is:
A. No levels
B. No classes per se (may use careers which give bonuses or
penalties to certain skills).
C. The object of the game is to develop one's character and
over a period of time gain power and influence thru play.
D. The gaining of and training in a skill implies that the
character percieves a need for, and will use, the skill.
The lightweight solution is then:
A. Each level of skill mastery requires training.
B. Training requires an expenditure of experience points,
game play time, and money.
C. Higher levels of training cost ever increasing amounts of B.
D. Training requires an instructor, an instructor must be
located in order to train. (instructor could be an object
in some cases though this requires additional considerations)
E. The more rare a skill, and the higher the level of training
offered by the instructor, the harder it is to find and
costlier it is to reach said instructor.
There are quite a number of variations on the above theme that I will
likely implement but that is the general 'look and feel' of the
system I propose as a lightweight solution. It is modeled to a
degree upon a modified paper Traveller rpg system I've had a number
of years experience with. Such a system has a degree of realism
built in, is easy and low cost to implement, and generates a number
of game-play situations similar to quests.
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