January 1999
- From DevMud: Database module Greg Connor
- From DevMud: Database module Mik Clarke
- From DevMud: Database module Greg Connor
- From DevMud: Database module J C Lawrence
- From DevMud: Database module Greg Connor
- ADMIN: Resends and possible duplicates J C Lawrence
- Info about different skill systems Emil Eifrem
- Info about different skill systems Nathan F Yospe
- Info about different skill systems Ben Greear
- Info about different skill systems Emil Eifrem
- Info about different skill systems Ben Greear
- Info about different skill systems Emil Eifrem
- Info about different skill systems Nathan F Yospe
- Info about different skill systems Travis S. Casey
- Info about different skill systems Mik Clarke
- New features for ScryMUD (Player-run Shops) Ben Greear
- [OT Humor] Mudder's Rhapsody Jon A. Lambert
- [OT Humor] Mudder's Rhapsody Caliban Tiresias Darklock
- [OT Humor] Mudder's Rhapsody The Wildman
- Guild/skill/spell relation (or "webs") Petri Virkkula
- Guild/skill/spell relation (or "webs") David Bennett
- mobile movement Matthew Mihaly
- mobile movement Adam Wiggins
- mobile movement Koster, Raph
- mobile movement Caliban Tiresias Darklock
- mobile movement David Bennett
- mobile movement Kylotan
- mobile movement quzah [softhome]
- mobile movement Ling
- mobile movement J C Lawrence
- mobile movement Oliver Jowett
- mobile movement Oliver Jowett
- mobile movement Caliban Tiresias Darklock
- mobile movement Richard Woolcock
- mobile movement J C Lawrence
- mobile movement Ling
- mobile movement Marc Hernandez
- mobile movement J C Lawrence
- mobile movement Ling
- mobile movement Holly Sommer
- mobile movement Caliban Tiresias Darklock
- mobile movement Koster, Raph
- mobile movement Chris Gray
- Intelligent WebGlimpse archive searching at Kanga.Nu (was J C Lawrence
- [RRE]MediaMOO annual birthday symposia: 1/20 Bruce Mitchener, Jr.
- [RRE]MediaMOO annual birthday symposia: 1/20 Koster, Raph
- OT: Mike Sellers needs some help load testing J C Lawrence
- Keegan's MUD Tree J C Lawrence
- Intelligent WebGlimpse archive searching at Kanga.Nu Marian Griffith
- Intelligent WebGlimpse archive searching at Kanga.Nu Caliban Tiresias Darklock
- Intelligent WebGlimpse archive searching at Kanga.Nu Dominic J. Eidson
- Intelligent WebGlimpse archive searching at Kanga.Nu J C Lawrence
- Intelligent WebGlimpse archive searching at Kanga.Nu Marian Griffith
- GRASS GIS Web Site Elis Pomales
- Thoughts Caliban Tiresias Darklock
- Thoughts Koster, Raph
- Thoughts Caliban Tiresias Darklock
- Thoughts Koster, Raph
- Thoughts James Wilson
- Thoughts Ling
- Thoughts Caliban Tiresias Darklock
- Thoughts Hal Black
On Wed, Jan 13, 1999 at 04:32:16PM -0800, Caliban Tiresias Darklock wrote:
> I'd be lying if I pretended getting something into Koster's laws isn't one
> of my primary motivations in many of my posts on this list. Raph's list of
> laws lies firmly in an area that I've always given a lot of thought to, but
> I *still* don't have anything in there, which really bothers me. That said,
> I'll fire off my current candidates and then go hide from the flying
> tomatoes and cabbages. ;)
>
> The code is the contract:
> Any usable ability or object is a promise. If your game has a "haggling"
> skill, there is obviously someplace you can haggle. If there is a hammer you
> can carry, there must be a nail you can drive. If you do not deliver a place
> to haggle and a nail to drive, you have broken your contract with the
> player. Even if you only do this once, word will spread.
And if you have a hammer that can drive builder A's 4-inch nail, it should
also be able to drive builder B's 3.5-inch nail. But then we're getting back
to the global vs. specific verbs argument.
I agree with it as a guideline for mud design, but I don't see it fitting
as a "Law" per-se on the canonical Koster list. Those seem to be involved with
some sort of behavior given a condition, where this is more of a design
guideline - but a good one!
> The power of two:
> Twice is always. If a player observes an effect twice, he will expect to see
> it every time. If he doesn't, he will think something is wrong. If you
> assure him that nothing is wrong, he will think *you* are wrong.
I'll argue against this one. I believe there is something from psychology
that says something different. There was an earlier thread by JCL on effects
as rewards and motivating factors for players. Take the situation where
some action produces a reward as an effect only some of the time rather than
all the time, we have a case of partial reinforcement verses total
reinforcement. For some reason, psychology tests tell us that partial
reinforcement is a better training tool than total reinforcement! So, not only
do people not find fault with somewhat inconsistent results, they are more
likely to try it more often given that it works some of the time!
> How benchmarks are built:
> When no measure of quality is readily provided, a measure of quality will be
> invented by a player who performs well under that measure. It will be
> supported by others who perform well under it. If there are enough of those
> people, the rest of the playerbase will conclude that this is the "correct"
> measure of a player's skill. This becomes the de facto object of your game,
> and you will be blamed for its every ill while those who created it will
> take all the credit for its successes.
This certainly is true of the computer industry. 8')
> It's the thought that counts:
> Stupid restrictions are okay if the player discovers them himself, but not
> if you tell him they exist. In Squaresoft's "Parasite Eve", a dead body
> blocks your passage down a forest path. You could, of course, simply step
> over the body were this real life. Upon determining the restriction's
> existence, the player accepts it. Reporting it to another player who has not
> yet observed the restriction, however, meets with indignance and outrage at
> such an unacceptable breach of realism. (This is specifically of interest to
> commercial game authors, since it implies that *telling* potential players
> you don't support something is a Bad Thing, whereas just plain not
> supporting it would probably be fine. Also consider the reactions of your
> public to proposed features; telling someone you're going to give them
> something is very different from actually giving it to them.)
I think a lot of this has to do with the fact that players start to feel
some sense of ownership in the game they're playing. Perhaps they've put
a lot of time into building their character's stats or roleplaying
personality. Perhaps they've carefully weaved their own domain into the
game world. So here's my attempt to hijack 2 minutes of your fame: Players
and Builders who feel a sense of ownership are more apt to accept shortcomings
(in simulation or otherwise) in a game than those with no sense of ownership.
8')
Otherwise, seems like a nice list of laws. I always like to hear the
anecdotes that people tell that taught them some of their lessons in game
design. Do you have any to share that spawned your list of laws?
Here's another attempt at a law I'll throw in:
The more responsive an admin is to user feedback of a given type, the more
the admin will get. Specifically, as an admin implements features from user
suggestions, more ideas for features will be submitted. Likewise, as an
admin coddles whining players, more whining ensues.
- mobile movement (the fault of tracking) quzah [softhome]
- ADMIN Name server problems and upes J C Lawrence
- Adjective Server Christopher Allen
- Reputations, More Mazes Eli Stevens {KiZurich}
- Reputations, More Mazes J C Lawrence
- Reputations, More Mazes Eli Stevens {KiZurich}
- Mules (was something different) Marian Griffith
- Mules (was something different) J C Lawrence
- Mules (was something different) Hans-Henrik Staerfeldt
- Levels versus Skills Marian Griffith
- Levels versus Skills Caliban Tiresias Darklock
- Levels versus Skills J C Lawrence
- Levels versus Skills quzah [softhome]
- Levels versus Skills Vladimir Prelovac
- Levels versus Skills quzah [softhome]
- Levels versus Skills J C Lawrence
- Levels versus Skills Petri Virkkula
- Levels versus Skills J C Lawrence
- Levels versus Skills Caliban Tiresias Darklock
- From Devmud: Database module, draft 3 Greg Connor
- Matrix Game Ling
- Graphic design doc Thinus Barnard
- Graphic design doc Chris Gray
- ADMIN: List server and Kanga.Nu host changes J C Lawrence
- ADMIN: List server and Kanga.Nu host changes Koster, Raph
- Sockets and fibers Caliban Tiresias Darklock
- Sockets and fibers Adam J. Thornton
- Sockets and fibers Caliban Tiresias Darklock
- Sockets and fibers J C Lawrence
- Sockets and fibers Jon A. Lambert
- Sockets and fibers Adam J. Thornton
- Sockets and fibers Dr. Cat
- Sockets and fibers Jo Dillon
- [DevMUD] From Devmud: Database module, draft 3 Greg Connor
- META: list "peerage" Koster, Raph
- META: list "peerage" John Bertoglio
- META: list "peerage" diablo@best.com
- META: list "peerage" Andy Cink
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Quzah [softhome]
- META: list "peerage" Michael.Willey@abnamro.com
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Holly Sommer
- META: list "peerage" Travis S. Casey
- META: list "peerage" Andy Cink
- META: list "peerage" Quzah [softhome]
- META: list "peerage" Matthew D. Fuller
- META: list "peerage" Laurel Fan
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" David Bennett
- META: list "peerage" Bruce Mitchener, Jr.
- META: list "peerage" diablo@best.com
- META: list "peerage" Matthew D. Fuller
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Brandon A Downey
- META: list "peerage" Travis Casey
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Dominic J. Eidson
- META: List "peerage" Marian Griffith
- META: List "peerage" Caliban Tiresias Darklock
- META: list "peerage" Ola Fosheim Grøstad
- META: list "peerage" Sayeed
- Mugu Chris Gray
- META: List peerage and behaviour J C Lawrence
- META: list "peerage" Chris Gray
- ADMIN: We're working again. J C Lawrence
- Java I/O and threads. Elis Pomales
- Java I/O and threads. Jo Dillon
- Java I/O and threads. cynbe@muq.org
- Java I/O and threads. Jo Dillon
- Java I/O and threads. Elis Pomales
- Reset Death Wes Connell
- Reset Death Quzah [softhome]
- Reset Death Wes Connell
- Reset Death Mik Clarke
- Reset Death Andrew C.M. McClintock
- Reset Death Mik Clarke
- PvP and mob capacities (was "List Peerage") Caliban Tiresias Darklock
- combat diablo@best.com
- META: list "peerage" Darrin Hyrup
- META: list "peerage" J C Lawrence
- Telmaron and Mud servers was: META: list "peerage" Elis Pomales
- META: list "peerage" Caliban Tiresias Darklock
- META: list "peerage" Ben Greear
- Who is? (was about level vs skills) Marian Griffith
- Who is? (was about level vs skills) Caliban Tiresias Darklock
- exploration points diablo@best.com
- [MUD-Dev] Juha Lindfors
- Stock Mud Demographics ##Make Nylander
- ADMIN: Off-topic and the ever present reminders on quoting. J C Lawrence
- Mud reviewing Andy Cink
- Mud reviewing Caliban Tiresias Darklock
- Mud reviewing diablo@best.com
- Mud reviewing Andru Luvisi
- Mud reviewing diablo@best.com
- Mud reviewing J C Lawrence
- Mud reviewing Dan Shiovitz
- Mud reviewing diablo@best.com
- Mud reviewing Caliban Tiresias Darklock
- Mud reviewing diablo@best.com
- Mud reviewing Richard Woolcock
- Mud reviewing David Bennett
- Mud reviewing Caliban Tiresias Darklock
- MUD Admin skills Hal Black
- Subdue Holly Sommer
- processors diablo@best.com
- processors John Bertoglio
- processors Wes Connell
- processors Laurel Fan
- processors Mik Clarke
- processors J C Lawrence
- processors diablo@best.com
- processors Quzah [softhome]
- processors Mik Clarke
- processors J C Lawrence
- processors Marc Hernandez
- processors Adam Wiggins
- processors Greg Underwood
- processors Adam Wiggins
- processors Chris Gray
- processors gunderwood@donet.com
- processors Jon A. Lambert
- processors Greg Underwood
- processors Petri Virkkula
- quests involving players diablo@best.com
- quests involving players Darren Henderson
- quests involving players Caliban Tiresias Darklock
- quests involving players Richard Woolcock