October 2001
- (no subject) J C Lawrence
- Lum the Mad is closing--sort of Koster, Raph
- Questing (was: Request for ideas) Eli Stevens
- Questing (was: Request for ideas) Joe Andrieu
- Questing (was: Request for ideas) Matt Mihaly
- Questing (was: Request for ideas) Sellers, Mike
- Questing (was: Request for ideas) Vincent Archer
- contract games/markets (was: Request for ideas) Bruce Mitchener
- DEV: Peer-to-Peer MUD Phil O'Donnell
- DEV: Peer-to-Peer MUD Dan MacDonald
- DEV: Peer-to-Peer MUD Robin Lee Powell
- DEV: Peer-to-Peer MUD Justin Rogers
- DEV: Peer-to-Peer MUD Adam Martin
- DEV: Peer-to-Peer MUD Frank Crowell
- Psychology and game design (Was Geometric content generation) John Hopson
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) Dave Rickey
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) Matt Mihaly
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) rayzam
- in-game vs web-based boards (was: Geometric content generation) Freeman, Jeff
- State of the RP: Verant's attempt at a RP Server Eric Rhea
- New MMP Networking Architecture Lee Sheldon
- New MMP Networking Architecture Adam Martin
- New MMP Networking Architecture Bruce Mitchener
- New MMP Networking Architecture Ling Lo
- New MMP Networking Architecture Norman Nunley, Jr.
- Mucking about in time Eli Stevens
- Mucking about in time Travis Casey
- Mucking about in time Adam Martin
- Mucking about in time John Robert Arras
- Many MUDs in one? (was: Geometric content generation) Ian Collyer
- Many MUDs in one? (was: Geometric content generation) Matt Mihaly
- Many MUDs in one? (was: Geometric content generation) Robin Lee Powell
- Pueblo still kicking Jon Lambert
- FWD: Call for papers: AAAI symposium on AI and Interactive Entertainment Robert Zubek
- Game Theory Introduction Ling Lo
- MUD-Dev digest, Vol 1 #438 - 22 msgs Phil O'Donnell
- Uniqueness of Games Adam Martin
- Uniqueness of Games Ling Lo
- Psychology & Player Motivation (was Geometric Content Generation) Sasha Hart
- Simulation, just how much? (was: Uniqueness of Games) Derek Licciardi
- Laws of Competition Matt Mihaly
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Brian Hook
- UDP Revisted Bobby Martin
- UDP Revisted Brian Hook
- UDP Revisted Dave Rickey
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Dave Rickey
- UDP Revisted Travis Nixon
- UDP Revisted Amanda Walker
- UDP Revisted Brian Hook
- UDP Revisted Ben Greear
- UDP Revisted amanda@alfar.com
- UDP Revisted Brian Hook
- UDP Revisted Travis Nixon
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Travis Nixon
- UDP Revisted David H. Loeser Jr.
- UDP Revisted Adam Martin
- UDP Revisted Bobby Martin
- UDP Revisted Bobby Martin
- UDP Revisted Kwon Ekstrom
- UDP Revisted Bruce Mitchener
- UDP Revisted Bobby Martin
- UDP Revisted Bruce Mitchener
- UDP Revisted Daniel.Harman@barclayscapital.com
- Procedural content generation Brian Hook
- Procedural content generation John Buehler
- Procedural content generation Brian Hook
- Procedural content generation John Buehler
- Procedural content generation Hans-Henrik Staerfeldt
- Procedural content generation lhulbert@hotmail.com
- Procedural content generation Travis Nixon
- Procedural content generation Ola Fosheim Grøstad
- Procedural content generation Daniel.Harman@barclayscapital.com
- Procedural content generation Daniel.Harman@barclayscapital.com
- Procedural content generation Freeman, Jeff
- Procedural content generation Matt Mihaly
- Procedural content generation Ola Fosheim Grøstad
- Simulation, Christopher Allen
- Simulation, Travis Casey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Kennerly
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Robin Lee Powell
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Brian Hook
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Daniel.Harman@barclayscapital.com
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Vincent Archer
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Derek Licciardi
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dan Burke
- Simulation, Adam Martin
- UDP Revisited Daniel.Harman@barclayscapital.com
- UDP Revisited Brian Hook
- UDP Revisited Mats Lidstrom
- UDP Revisited Jeremy Gaffney
- Simulation Revisited Dave Rickey
- TCP Vegas Adam Martin
- Procedural content generation, randomness Adam Martin
- Procedural content generation, randomness Brian Hook
- Content authorship Adam Martin
- Content authorship Ola Fosheim Grøstad
- Content authorship Travis Casey
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Eli Stevens
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Dave Rickey
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Ola Fosheim Grøstad
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Robin Lee Powell
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Brian Hook
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Daniel.Harman@barclayscapital.com
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Neufeld, Don
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Brian Hook
- DAoC dev team Dave Rickey
- SSL vs. SASL (was: UDP Revisted) Bruce Mitchener
- MUD-Dev digest, Vol 1 #445 - 27 msgs Paul Schwanz
- MUD-Dev digest, Vol 1 #445 - 27 msgs Travis Nixon
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Freeman, Jeff
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law Koster, Raph
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Koster, Raph
- Proposed Law Ola Fosheim Grøstad
- Proposed Law Jon Lambert
- Proposed Law Paul Schwanz
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Proposed Law Paul Schwanz
- Proposed Law Madman Across the Water
- Proposed Law Travis Nixon
- Proposed Law Mark Eaton
- Proposed Law Sami Kosonen
- Proposed Law Madman Across the Water
- Proposed Law Andrew Hefford {Coregen}
- Proposed Law Dan Burke
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Proposed Law Ian Collyer
- Proposed Law Matthew Estes
- Proposed Law Matt Mihaly
- Proposed Law Ola Fosheim Grøstad
- Proposed Law John Buehler
- Proposed Law Ola Fosheim Grøstad
- Proposed Law John Buehler
- Proposed Law Adam Martin
- Proposed Law Matt Mihaly
- Proposed Law Adam Martin
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Quality Testing Michael Tresca
- Quality Testing John Buehler
- Quality Testing Michael Tresca
- Quality Testing Dave Rickey
- Quality Testing Nathan F. Yospe
- Quality Testing Michael Tresca
- Quality Testing Koster, Raph
- Quality Testing Dave Rickey
- Quality Testing Dave Rickey
- Quality Testing Derek Licciardi
- Quality Testing Dave Rickey
- Quality Testing Michael Tresca
- Quality Testing Dave Rickey
- Quality Testing Jeff Cole
- Quality Testing Robin Lee Powell
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing J C Lawrence
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Dave Rickey
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Michael Tresca
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Paul Dahlke
- Quality Testing Dave Rickey
- Players Controlling Monsters rayzam
- High Level Architecture Adam Martin
- Networking architecture overview Brian Hook
- Networking architecture overview Dave Rickey
- Networking architecture overview Brian Hook
- Networking architecture overview Amanda Walker
- Networking architecture overview Brian Hook
- Networking architecture overview Bobby Martin
- Networking architecture overview Daniel.Harman@barclayscapital.com
- Connection Stats Ben Tolputt
- MUD-Dev digest, Vol 1 #443 - 12 msgs Dr. Cat
- Fourteen forms of fun Ola Fosheim Grøstad
- Fourteen forms of fun rayzam
- Fourteen forms of fun Sasha Hart
- Fourteen forms of fun Jon Lambert
- Fourteen forms of fun David H. Loeser Jr.
- Fourteen forms of fun Matt Mihaly
- Fourteen forms of fun Ola Fosheim Grøstad
- Incorporating Plot/Backstory/Scenario Design Tools Nathan F. Yospe
- Extreme Programing Ling Lo
- DAoC dev team Lars Duening
- Documentation Adam Martin
- Documentation Brian Hook
- English grammar thoughts Par Winzell
- English grammar thoughts Kylotan
- English grammar thoughts Travis Casey
- English grammar thoughts Jasper McChesney
- English grammar thoughts Marian Griffith
- English grammar thoughts Travis Casey
- English grammar thoughts Jasper McChesney
- English grammar thoughts bruce@puremagic.com
- English grammar thoughts Marian Griffith
- English grammar thoughts Travis Casey
- English grammar thoughts Robert Zubek
- English grammar thoughts Robert Zubek
- English grammar thoughts Travis Casey
- English grammar thoughts Chris Gray
- English grammar thoughts Jon Leonard
- ADMIN: The code documenting/commenting thread J C Lawrence
- Players Controlling Monsters David H. Loeser Jr.
- Players Controlling Monsters Brian Hook
- Players Controlling Monsters John Buehler
- Expectations of in-game reality Matt Mihaly
- Expectations of in-game reality Freeman, Jeff
- Expectations of in-game reality J C Lawrence
- Expectations of in-game reality Freeman, Jeff
- Expectations of in-game reality Travis Casey
- Expectations of in-game reality Lars Duening
- Expectations of in-game reality Marian Griffith
- Expectations of in-game reality Derek Licciardi
- Expectations of in-game reality Lars Duening
- Expectations of in-game reality Paul Schwanz
- Expectations of in-game reality Nip
- Expectations of in-game reality Ian Collyer
- Expectations of in-game reality Adam Martin
- Expectations of in-game reality Michael Tresca
- Expectations of in-game reality J C Lawrence
- Expectations of in-game reality Matt Mihaly
- Expectations of in-game reality Daniel.Harman@barclayscapital.com
- Expectations of in-game reality Eli Stevens
- Expectations of in-game reality Marian Griffith
- Expectations of in-game reality Travis Casey
- Expectations of in-game reality Sami Kosonen
- Respecting NPCs Lee Sheldon
- Respecting NPCs J C Lawrence
- Respecting NPCs Lee Sheldon
- Respecting NPCs J C Lawrence
- Respecting NPCs Sami Kosonen
- Respecting NPCs Travis Nixon
- Respecting NPCs Matthew Estes
- Respecting NPCs Chris Gray
- Respecting NPCs Michael Tresca
- Respecting NPCs Freeman, Jeff
- Respecting NPCs Michael Tresca
- Respecting NPCs Freeman, Jeff
- Respecting NPCs Travis Nixon
- Respecting NPCs Michael Tresca
- Respecting NPCs Adam Martin
- Respecting NPCs Michael Tresca
- Respecting NPCs Daniel.Harman@barclayscapital.com
- Respecting NPCs rayzam
- Respecting NPCs Joe Andrieu
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Joe Andrieu
- Respecting NPCs Michael Tresca
- Respecting NPCs Adam Martin
- Respecting NPCs Lee Sheldon
- Respecting NPCs T.A.J.BARTON
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Adam Martin
- Respecting NPCs Madman Across the Water
- Respecting NPCs Travis Nixon
- Respecting NPCs J C Lawrence
- Respecting NPCs John Buehler
- Respecting NPCs lazarus@ourplace.org
- Respecting NPCs Colin Coghill
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs J C Lawrence
- Respecting NPCs Phillip Lenhardt
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs J C Lawrence
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Norman Nunley, Jr.
- Respecting NPCs J C Lawrence
- Respecting NPCs Brian Hook
- Respecting NPCs J C Lawrence
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs Matthew D. Fuller
- Respecting NPCs Timothy Dang
- Respecting NPCs gamaiun@yahoo.com
- TECH : RMI (was UDP Revisted) Daniel.Harman@barclayscapital.com
- TECH : RMI (was UDP Revisted) Bobby Martin
- Chatbots Adam Martin
- TECH: UDP Revisted Bobby Martin
- The function of NPCs in novels versus MUDs Ola Fosheim Grøstad
- RE: Koster, Raph
- RE: Joe Andrieu
- RE: Marian Griffith
- RE: gamaiun@yahoo.com
- RE: Daniel.Harman@barclayscapital.com
- Violence Matt Mihaly
- Quality Testing (and community) Ola Fosheim Grøstad
- ADMIN: Recent outages J C Lawrence
- [ECOSYSTEMS] Fishing in the real world Adam Martin
- [ECOSYSTEMS] Fishing in the real world Daniel.Harman@barclayscapital.com
- [ECOSYSTEMS] Fishing in the real world Hans-Henrik Staerfeldt
- [ECOSYSTEMS] Fishing in the real world Ian Collyer
- [ECOSYSTEMS] Fishing in the real world Dave Rickey
- Statistics Ben Chambers
- Statistics Eli Stevens
- Statistics Adam Martin
----- Original Message -----
From: "Ben Chambers" <bjchamb@bellsouth.net>
> What statistics do you consider necessary to define a character?
> I am planning on using a 100% skill based system, with no levels,
> where the more you do something the better you get at it. The
> problem is I was hopping that the skills would be defined by the
> host. The set of skills that seem most logical to me are:
> Strength - How capable of physical feats this character is
> Constitution - How resistant to physical damage he is
> Intelligence - How quickly he learns new skills
> Wisdom - How well he retains learnt skills
> The problem is I can't figure out where spells and stuff would
> come in. So I came up with this:
> If you reduce the system down to JUST the capability to learn and
> the retention of what is learned, Strength is no longer a
> statistic, but rather a skill. The problem is too many things
> would be dependent upon this one skill. The obvious solution (in
> my mind) is to define a basic skill for each item, and than any
> skill that you perform (attack) uses a modifier for how proficient
> you are with this weapon. This however becomes to complex again.
> What would happen if we defined TWO types of skills? I could have
> skills that describe the proficiency with different things, and
> than skills which describe what you can do. The key is that I
> can't do a jump kick with a magical attack, even if I am
> proficient in magic.
At the risk of repeating what many other people are likely to reply
with, I'd suggest you have tricked yourself by saying you want a
100% skill-based system; I'm pretty sure you don't. What you do want
is a mainly skill-based system. You seem headed in the direction of
a fairly standard approach - to have skills as "things you do" and
separately have attributes "things you have/are".
Its generally a false economy to try and wrap them both up as
skills, since the two are like chalk and cheese:
(-) Skills (+) Attributes (note that the following makes
assumptions that you use a %-based rating for the sake of
argument, please bear with this even if you intend to use a very
different form of rating):
- provide you with at least one new command
+ do not *on their own* allow you to *do* anything new
- normally most people start without many skills, or have 0% in them
+ most attributes are innate measures, and for most attributes other
than in exceptional cases you *must* have non-zero percent in them -
e.g. Strength. Most attributes are attributes that everyone
possesses without having ever *learned* them
- Skills must be learned and can be improved by practicing them +
Attributes are non-learnable, and can be improved, but only by
performing some skill which has a side-effect of increasing the
attribute
- When writing algorithms to determine success/failure and extent
thereof for a skill, you very very often find yourself wanting to do
things like "[Jump] - attempt to jump over X succeeds only if
maximum-run-speed > height of X, and if check against jump-skill is
successful", where maximum-run-speed is an attribute - because it is
used here in a way that it is different from how a skill would be
used semantically (although I seem to have explained that very
poorly, and even confused myself!) + attributes usually affect many
many many skills and their success/failure in complex interacting
ways. However you cannot "succeed" at an attribute, as a side effect
of the way they are defined as things "you have" rather than that
"you do".
Adam M - Statistics Hans-Henrik Staerfeldt
- Statistics John Buehler
- Statistics Ben Chambers
- Statistics Ben Chambers
- Statistics Travis Casey