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
- 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
> From: clawrenc@cup.hp.com
> at 12:15 AM, "Brian Price" <blprice@bedford.net> said:
> >Having done a bit of scripting and 'pseudo-scripting' with zMud, I
> >immediately saw three seperate 'areas of attack' to greatly reduce
> >the payoff for scripting. The first area of attack is to prevent
> >multiple commands and repetitive sequences of commands. The second
> >is to confuse and complicate the scripting of triggers. The third
> >is to design the game itself so that scripting is a marginal
> >enterprise.
>
> #1 is actually not a problem for a scripter and can be trivially
> defeated by almost any scriptable MUD client out there. You just need
> to intersperse the scripted commands with other no-op commands to
> break the pattern, or to insert timed pauses between commands. #2
> just raises the ante. Scripting is more difficult, but not impossible
> or unprofitable.
>
> The net result of #1 and #2 in general are to impede scripting, not to
> reduce its profitability.
Agreed, it's kind of like a lock on your door, it helps keep honest
people honest. It does very little to stop the determined burglar.
> #3 is where the real gold lies -- design a game which cannot be
> profitably scripted, or (more likely) for which scripting is not
> sufficiently profitable over non-scripting to make the difference
> worth while.
Yes, indeed on the system I'm envisioning, scripting would be very
hazardous to a character's health. (some details below)
> Caliban touched on this recently in commenting that he likes to script
> rote actions which don't add to game-play. This of course begs the
> question on why those actions are required if they don't add value to
> the actual game play?
Nod, eliminating these actions where possible should be part of the
game design.
> >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:
...
> This would annoy the crap out of me as a player. The classical case
> is speed walking. If I'm at point A and wish to get to point B, and
> know the exact sequence of commands to get from A to B (very likely if
> I've played more than a day or two), then I want to be able to sit
> there and bang out commands as fast as my KB will take them. The game
> can catch up later.
I'm guilty of a few assumptions here, in the mud I'm working on,
speed-walking is a hazardous endeavor. Features such as full pk,
random events (stepping out in front of a speeding vehicle or into a
crossfire complete with grenades landing short is not a bright idea),
vehicle use, spaceflight, etc make moving from point A to point B
an integral part of game play and definately a non-trivial
sequence of events.
> Note: A key value here is the ability to interrupt such a stack of
> entered commands. Consider the case:
>
> > n,n,n,n,n,e,e,s,s,w,w,u,u,e,u,w,w,w,s,e
> Room 1.
> Room 2.
> Room 3.
> There is a huge pile of gold here.
> Room 4.
> Room 5
> Room 6
> Room 7
> ...etc.
>
> Better would be:
>
> > n,n,n,n,n,e,e,s,s,w,w,u,u,e,u,w,w,w,s,e
> Room 1.
> Room 2.
> Room 3.
> There is a huge pile of gold here.
> Room 4.
> Room 5
> > !stop
> Room 5
> >back,back
> Room 3.
> There is a huge pile of gold here.
> > get gold
> ...etc.
>
> This is of course an extension of the more general Panama Canal
> scenario.
Given the mud system I'm assuming, this capability would, I believe,
encourage scripting. When you combine multi-room events, random
events, 'fall-out' from ranged weapons combat, etc, any public area
is a dangerous place. Helping players to speedwalk through areas
would in general shortcut game-play. I will admit however that it
could make sense for 'safe' areas although those areas would be the
exception rather than the rule for my system.
> >The second area of attack, confusing and complicating triggers could
> >be a lot of fun. (Yes I have a warped view of fun)
>
> Agreed. This ups the ante, adds flavour, and increases apparent
> complexity for little to no cost. It also encourages mistakes of the
> form Nathan has commented taking advantage of (emoting the last
> character exit to lead the follower into a DT or similar).
>
> >Therefore the best attack against scripting
> >attempts is to design the game such that scripting has a marginal
> >return on investment.
>
> Bingo. This is my main interest.
>
> >Randomness is the enemy of scripters and
> >random events can also spice up a mud.
>
> Care needs to be taken with the definition of "randomness" here.
I'd better define what I mean by random events. Some modified Diku
descendants have random mob resets, I'm taking this concept further
by using the idea from paper rpgs of random encounter tables. With
such a system, most mobs have no set load location, rather, when an
area is observed by a player (or a player henchman/pet NPC), a check
is made to see if anything is there, if something is, then a number
is generated and used as a lookup into a table of mobs (not
necessarily a table of even distributions however). The net result
of this is that you could pass thru an area hundreds of times and
then on pass 203 run into a mob or event which you didn't even know
was a possiblity. This type of randomness not only is _very_
difficult to script, but also (imo) adds much to game play.
> Back when I wrote many scripts to automate logging on to a BBS,
> getting a mail packet, grabbing new files, and logging back off again.
> Of course Sysops tended to add new menus, or news screens to confuse
> scripts. The temptation was to write increasing complex scripts in
> attempt to handle all the variations. I abandoned that approach for
> the inanely successful:
>
> Script:
> logon stuff
> Look for XXX prompt
> Send 20 [ENTER] keys
> Look for XXX prompt
> Not there? Send more [ENTER] keys.
> issue command to get mail
> Look for XXX prompt
> Send 20 [ENTER] keys
> Look for XXX prompt
> Not there? Send more [ENTER] keys.
> get new files
> Look for XXX prompt
> Send 20 [ENTER] keys
> Look for XXX prompt
> Not there? Send more [ENTER] keys.
> etc.
>
> Absolutely minimal intelligence. Instead it was an application of
> least required stupidity. Similar can be done with most other forms
> of randomity if the expense of getting the desired trigger is low
> enough.
I don't believe the system I described briefly above is subject to
this type of attack, at least, not unless you have access to the
area's design and encounter tables. I'd also note that I'd like to
make the system such that encounter tables can and will be changed
occasionally by the admin.
> >One of the biggest and juiciest targets for casual scripters has to
> >be the (IMO) absolutely moronic skill percentages which rise slowly
> >with use. I cannot begin to count the number of times I have seen
> >such systems result in players spamming commands to improve the skill
> > percentage or use timers to automate skill improvement. This type
> >of game construct practically begs to be scripted. Compare it to
> >its alternative however, what if you had skill ratings for those
> >same skills say from 0 to 9 which were trained at a cost of xp and
> >money at a trainer somewhere? Bingo, the incentive and opportunity
> >for scripting that construct has been removed in one fell swoop.
> Nope, you've just trivialised it a different way:
>
> Endless loop:
> Go to woods/city/whereever
> Kill frodo's
> Kill beggars
> Get money.
> Go to trainer
> Get trained.
> Anything weird happens, logoff.
> Repeat.
>
> I could easily see working out such a script for most any hack'n'slash
> in a couple minutes and leaving it running overnight.
This makes a number of assumptions (namely that you're dealing with a
hack'n'slash with a diku-like mob loading mechanism). While I
probably will allow a small amount of xp to be derived from killing
mobs, I'd like to make most xp come from performing quest-like
activities (ala Traveller's patron system with a mechanism to make
complex quests re-usable). Also, I'm aiming more at a quick-start
char gen game without char levels. While some skill advancing is
necessary, it shouldn't been the main focus of the game. The whole
system is further complicated for the scripter by being a perma-death
possible, full pk game system. In my opinion, the smarter the mud
(with human pk adversaries being the smartest, sort of), the less
payoff for scripting.
My assumed goal in all of this is to develop a mud which is aimed at
both the programmer and non-programmer alike. I'm also aiming for a
character startup cost (in player time and effort) about one-quarter
of the way between doom and a leveling diku. If I'm successful, the
end result will focus more on game play than character development.
> For those interested, I once wrote such a script to automate SHADES.
> It looked for empty games (no players), and then did a very simple
> sweep of the game, cleaning out all the obvious and common treasure.
> It would then log off that game, log on to game #9 (intended for
> newbies, but there were backdoors into it), clean out that game, reset
> the game, do it again on game #1, then game #9, and repeated the whole
> set ad infinitum. Leave that puppy running a couple nights and anyone
> could make Wiz without ever learning anything about the game.
>
> Aside: Wiggins has recently commented here on Artic's approach to
> skill improvement which seems considerably more attractive (and an
> interesting variation on travel points)
>
> >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 seperate scripting into two camps: Triggers, and Automation. There
> is some bleed-over between the two, but it seems to be minimal.
>
> Triggers are simple reactive things. They look for certain inputs and
> react with canned predicted outputs. Classic triggers enclude such
> things as eating when hungry, following other players or NPC's,
> automatic responses when attacked, etc. I'm aware of the abuses and
> problems (eg trigger wars). I *despise* them as a player as I feel
> they needlessly weaken the game. I'm not terribly worried by them as
> an Admin or Imm, most especially since they can be fairly easily
> de-emphasized (eg fight reaction triggers aren't much use when ranged
> weapons are common).
Depends on how ranged weapons are implemented, what messages are
given, what countermeasures are availble, etc.
> Automation is a different kettle of fish. This covers longer term
> actions where an entire process is automated. The problem is systemic
> in character rather than behavioural. The example above of killing
> the frodos and beggars and training is a classic example. Other
> similar scripts abound. These I feel are actively and massively
> destructive to the games and the playability of the games. The mere
> fact of their presence suggests to me that the game is inherently and
> fatally flawed.
Nod, agree entirely, I'm attempting to make the game design such that
automation is penalized, unless you invent true AI (or close to it)
at which point I'll quit developing muds althogether and rest happy
with a small footnote in the history of AI research :)
> The challenge is to identify the systemic short circuits which can be
> spun on by a script profitably.
>
> The problem is that this is a short sighted solution. Almost any game
> system can be profitably automated if you make the time period of the
> script long enough. Sure, its easy to script the training as above.
> Its also easy to script getting your character up thru the first
> couple levels on a Diku. Put enough work into it and you could also
> script a character all the way up to Wiz. The base principle is that
> a game is made of predictable, mechanical systems, and as such can be
> handled by a mechanical automator.
Yes, most systems I've seen implemented in present muds are very
vulnerable to these kinds of attacks. As you note, the trick to
preventing it is to make the game apparently non-predictable.
> Consider: Most of us got a feel for where the balance points were
> in SimCity. The result was that we could with a fairly minimal amount
> of effort get an infinite treasury. Just build a set of nicely
> profitable cities and keep them there, wobbling slightly (tear
> down/build back) to keep your populace busy/happy.
>
> Even randomness isn't a saving grace if it is known (and it is) that
> the injected randomity can be from a defined and known small set of
> permutations. Once you know the possible permutations that can be
> injected, it is simple to work around them.
The biggest injector of randomness into a mud is other players (esp
in pk). Good mob-AI also injects a degree of randomness that can be
sufficiently complex to mask or hide some permutations from a single
observer for quite a long time. Likewise the mechanism of non-linear
probability encounter tables can effectively hide all possible
permutations from the would-be scripter. While defeating each one of
these seperately might be possible, defeating the synergetic effects
could be well-nigh impossible depending upon the richness of the
system.
> Asie: Speedwalking is a variation on automation, tho not one I decry.
>
> My major attack on this area has been:
>
> 1) To make many activities one-time-only.
>
> 1a) As a variation on #1, to make many actions only profitable
> for players of a narrow range.
>
> 1a1) As a variation on #1a, to make many actions heavily
> penalising for players outside of that narrow range.
>
> 2) To make many processes require indeterminate state transforms.
>
> #1 is tricky. It mostly maps out to variations on the quest concept
> -- once a certain character has done XXX, either XXX never occurs
> again (see #2), or there is no profit (penalty?) in doing XXX again.
Or XXX mutates into an essentially unrecognizable configuration.
> #1a is a bitch, and I'm moving away from this approach heavily in the
> general case. My main problem is making the limitation "reasonable"
> within the game context. cf the current r.g.m.diku thread on level
> limited equipment. Aside from the facts that I don't have levels, I
> don't have level limited equipment, and I'm not running a monty haul,
> most of the concerns there apply to me.
The effect of #1a might be achieved through a sufficiently
inter-dependant set of activities. Thus an activity B might only be
profitable if A has been done and no one has done C. The badly named
plot element node theorem I posted points towards one way to
interconnect events in this manner.
> About my only hold-over for #1a are puzzles which require certain
> weight limits (eg the previously described White Oak Tree and Human
> Catapult), or other narrow band physical stat requirements. I've also
> been toying with a mobiles collections (cf earlier discussion on
> combat intelligence by mobiles) which are sensitive to the rate at
> which their bodies are stolen (speed is assumed proportional to
> attacker's level for this context). Too fast and the mobile squeals
> to its master who then attacks in force, too slow and it takes time to
> summon reinforcements, just right and you have the chance to win.
> This also allows the possibility for a character to deliberately tone
> his attack to hit the middle zone, tone it up to get the master, or go
> very low to get the crowd.
>
> <<I'm also playing with ideas of decoy attacks here, say to distract
> NPC forces. Tthe concept of automating generalship in an NPC
> population is fascinating. See earlier discussions of seargent
> mobiles coordinating the operations of small bands for loose
> coverage>>
>
> #1a1 really is a minor variation, just noted for compleatness. The
> human catapult is fatal of course if your weight is outside of a
> fairly broad band (perma-death (reason for running multiple bodies)).
> Lesser tolerances merely put you in more or less
> intractable/impossible positions.
>
> #2 is the the more general approach of removing resets and
> predetermined state machines for various randomly interacting systems
> (typically feedback loops operating on shared resoureces) which
> mutually conspire to tear down some desired state, or to create some
> very undesirable state. (cf Orcs/breeders/fighters/nobles,
> Princess/orcs/kidnap, mobile population migration, mobile royalty
> systems, mobile inheritance thru children, scenarios etc)
This is the general approach I'm aiming for although I'm attempting
to implment it with a combination of simple mechanisms. Especially
if I can ever find a realistic way to implment the aforementioned pnel
theory in a buildable and useable manner.
Brian Price
Brian Price
<blprice@bedford.net> - 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: Anti-scripting techniques Brian Price
- 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