December 1998
- Hex-grid mapping Matthew R. Sheahan
- Hex-grid mapping Jon Leonard
- Hex-grid mapping James Wilson
- Hex-grid mapping Jon Leonard
- Hex-grid mapping James Wilson
- Hex-grid mapping Par Winzell
- Hex-grid mapping quzah [sotfhome]
- Hex-grid mapping Nathan F Yospe
- Hex-grid mapping Ling
- Hex-grid mapping Jon A. Lambert
- Hex-grid mapping Nathan F Yospe
- Hex-grid mapping Alberto Barsella
- Hex-grid mapping (example from PSL empire) Pericolo DiMorte
- Hex-grid mapping (example from PSL empire) Nathan F Yospe
- Hex-grid mapping (example from PSL empire) quzah [sotfhome]
- Hex-grid mapping (example from PSL empire) Pericolo DiMorte
- Hex-grid mapping (example from PSL empire) James Wilson
- ADMIN: Personalities... J C Lawrence
- Hex-grid mapping (fwd) Nathan F Yospe
- Hex-grid mapping (fwd) J C Lawrence
- Electric Communities' E Ola Fosheim Grøstad
- Electric Communities' E Ola Fosheim Grøstad
- mud client development systems Sunny Gulati
- mud client development systems Caliban Tiresias Darklock
- mud client development systems Chris Gray
- mud client development systems greear@cyberhighway.net
- mud client development systems Sunny Gulati
- mud client development systems Benjamin D. Wiechel
- mud client development systems Sunny Gulati
- mud client development systems J C Lawrence
- mud client development systems Per Vognsen
- mud client development systems Sunny Gulati
- mud client development systems Scatter
- mud client development systems Per Vognsen
- mud client development systems Chris Gray
- mud client development systems Jon Leonard
- mud client development systems Bruce Mitchener, Jr.
- mud client development systems Sunny Gulati
- mud client development systems Chris Gray
- Stack-Based NPC AI Eli Stevens {KiZurich}
- Stack-Based NPC AI Mark Gritter
- Stack-Based NPC AI Marc Hernandez
- Stack-Based NPC AI Richard Woolcock
- Stack-Based NPC AI Par Winzell
- Stack-Based NPC AI David Bennett
- Stack-Based NPC AI Mik Clarke
- Stack-Based NPC AI Felix A. Croes
- Introduction Mik Clarke
- Introduction Adam J. Thornton
- Introduction Mik Clarke
- Introduction ApplePiMan@aol.com
- Introduction Mik Clarke
- Thought Treasure Adam Wiggins
- Netscape's "Gecko" Browsing Engine (fwd) Nathan F Yospe
- Netscape's "Gecko" Browsing Engine (fwd) Adam Wiggins
- Netscape's "Gecko" Browsing Engine (fwd) Bruce Mitchener, Jr.
- Netscape's "Gecko" Browsing Engine (fwd) greear@cyberhighway.net
- Error tolerant UDP data streams J C Lawrence
- Error tolerant UDP data streams James Wilson
- Error tolerant UDP data streams J C Lawrence
- Error tolerant UDP data streams Ola Fosheim Grøstad
- ADMIN: (IMPORTNANT) Server down time and possible service interruption J C Lawrence
- [DevMUD] Error tolerant UDP data streams Darren Henderson
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) Benjamin D. Wiechel
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) Michael Willey
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Caliban Tiresias Darklock
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Ling
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis S. Casey
- MUD Design doc (long) Caliban Tiresias Darklock
- MUD Design doc (long) Marian Griffith
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Sunny Gulati
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Benjamin D. Wiechel
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Caliban Tiresias Darklock
- Hex grids. quzah [softhome]
- small dev-mud invite Chris Gray
- small dev-mud invite J C Lawrence
- mud client development systems Sunny Gulati
- mud client development systems Jay Carlson
- mud client development systems J C Lawrence
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Jon Leonard
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Mik Clarke
- AFAP: As fast as possible, non linear... Alex Oren
- AFAP: As fast as possible, non linear... Dan Shiovitz
- AFAP: As fast as possible, non linear... Mik Clarke
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Greg Connor
- AFAP: As fast as possible, non linear... quzah [softhome]
- Graphic design, client questions Thinus Barnard
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions Jo Dillon
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions Jo Dillon
- Graphic design, client questions Thinus Barnard
- Graphic design, client questions Sunny Gulati
- Graphic design, client questions J C Lawrence
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions J C Lawrence
- Graphic design, client questions J C Lawrence
- Graphic design, client questions Jay Carlson
- Graphic design, client questions Ben Greear
- More Laws, was DIS: Client-Server vs Peer-to-Peer Koster, Raph
- More Laws, was DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- More Laws, was DIS: Client-Server vs Peer-t o-Peer Koster, Raph
- More Laws, was DIS: Client-Server vs Peer-t o-Peer J C Lawrence
- More Laws Niklas Elmqvist
- More Laws J C Lawrence
- Re[2]:MUD Design doc (long) Michael Willey
- Re[2]:MUD Design doc (long) Adam Wiggins
- Re[2]:MUD Design doc (long) Caliban Tiresias Darklock
- Re[2]:MUD Design doc (long) J C Lawrence
- Re[2]:MUD Design doc (long) Sunny Gulati
- Re[2]:MUD Design doc (long) quzah [softhome]
- Re[2]:MUD Design doc (long) David Bennett
- Re[2]:MUD Design doc (long) quzah [softhome]
- Some useful links Niklas Elmqvist
- Response (Was MUD Design doc (long)) Ola Fosheim Grøstad
- Response (Was MUD Design doc (long)) Chris Gray
- Response (Was MUD Design doc (long)) J C Lawrence
- example custom protocol and its uses Chris Gray
- client stuff... Andrew Wilson
- Developing a MUD for the first time? Alex Oren
- Re[2]:MUD Design doc (long) J C Lawrence
- [DevMUD] Database module J C Lawrence
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module J C Lawrence
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module T. Alexander Popiel
- [DevMUD] Database module Jay Carlson
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module Felix A. Croes
- Re[2]:MUD Design doc (long) Caliban Tiresias Darklock
- [RRE]AAAI 1999 Fall Symposium: Narrative Intelligence Bruce Mitchener, Jr.
- (fwd) DESIGN: Proposed topic of Discussion (Injecting Pure Signal) J C Lawrence
- Terragen Vadim Tkachenko
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Bobby Bailey
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Robin Carey
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Bobby Bailey
- META: 1998 Topic Summary Jon A. Lambert
- [RELEASE] Insanity To Infinity (I:I_OS) v.02a Bobby Bailey
- ADMIN: New text formatting rule for MUD-Dev J C Lawrence
- More Laws Jon A. Lambert
- More Laws Travis Casey
- MUD Design doc - Combat Jon A. Lambert
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat cynbe@muq.org
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat quzah [softhome]
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat T. Alexander Popiel
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Adam Wiggins
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat quzah [softhome]
- MUD Design doc - Combat Dr. Cat
- MUD Design doc - Combat T. Alexander Popiel
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat James Wilson
- MUD Design doc - Combat Nathan F Yospe
- MUD Design doc - Combat James Wilson
- MUD Design doc - Combat Nathan F Yospe
- MUD Design doc - Combat diablo@best.com
- MUD Design doc - Combat Kristen Koster
- MUD Design doc - Combat Chris Gray
- MUD Design doc - Combat Scatter
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Kristen Koster
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat T. Alexander Popiel
- Levels versus Skills, who uses them and when. Till Eulenspiegel
- Levels versus Skills, who uses them and when. Travis Casey
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Ling
- Levels versus Skills, who uses them and when. Till Eulenspiegel
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Justin Robinson
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
> -----Original Message-----
> From: J C Lawrence [mailto:claw@under.engr.sgi.com]
> Sent: Wednesday, January 13, 1999 5:04 PM
> To: mud-dev@kanga.nu
> Subject: [MUD-Dev] Re: Levels versus Skills, who uses them and when.
>
>
> On Wed, 13 Jan 1999 09:58:36 -0600
> Koster, Raph<rkoster@origin.ea.com> wrote:
>
> > Quite aside from whether it is, I have become convinced that the
> > secrets to a really long-lived, widely appealing online game *in
> > the gaming sense* are multiple paths to advancement, ease of
> > switching between paths of advancement, clear milestones in said
> > advancement, and ideally, no sense of running out of significant
> > milestones (eg the ladder does not feel finite).
>
> <nod> <ponder>
>
> I quibble with that slightly. Clear, or at least apparent
> advancement paths to known goals are important. However I also see
> significant value in sideline growth opoortunities that are
> "advancement" per se (the player/character can now do things he
> could not do before), but which don't necessarily relate to known
> longer term goals (eg "learn to whittle chess pieces from
> driftwood").
"Side ladders," sure. Though my experience has been that players
promptly ask that said ladders be full ladders of their own. :)
> The reason for this quibble is that I see these philips as the key
> to expressive fertility,
Hmm, wasn't it you with whom I traded emails about "baited breath"? I'll
have to let Phil know you said that. ;) (The pedant in me mentally
corrects to "fillips.")
> and, by the simple means of watching your
> players use of them, of finding new areas/goals/activities to
> expand/build_on as you increase the depth of the game (eg notice
> that people are playing chess with the whittled pieces, so add a
> chess AI and other explicit game supports).
Definitely. We have followed this path often in UO's ongoing
development. Players advertise " exceptional bows crafted by Iolo" for
high prices? OK, let's make it so that exceptional bows automatically
get a maker's mark, and watch the player economy improve.
> Without such side-items
> there is a reduced stock of raw bits for players to start building
> with to *show* you want they really want (cf the old rule about
> satisfying player wants destroying the game). Yes, flexible game
> mechanics can do a lot of this (cf the monster farms for sparring in
> UO), but adding abilities-to-do seems the real key to providing the
> seeds of later outgrowths.
Yes; I didn't mean to denigrate the importance of plain old rich feature
set, in stating my premises. The richer the feature set, the more
players will make use of it and they longer they will be retained, no
question. The points were really about advancement models.
> Perfect if minor example: The fishermsn in one of the LPC libs.
> Reese has commented several times that they were a throw-away
> feature that got ad hocly dropped in, and yet significant numbers of
> players like playing fishermen and swapping stories about the
> virtual big one that got away.
Something we experienced in UO as well. However, consider how much more
longevity this could have had for more people, if at first you could
only catch minnows and tires, and could eventually get to be good enough
to catch Moby Dick. We took the same route as Reese, and simply
randomized the fish received. In retrospect, there was a prime chance
for a ladder there. Not a ladder that will necessarily appeal to tons of
people, and not a ladder that has a lot of depth to it, but a ladder
nonetheless that can serve as a replacement for the advancement model of
the guy who got bored fighting.
> I'm not certain on this, but I suspect that actively ensuring that
> there are no uber-characters or otherwise stereotypic characters
> (even if only as a presumed logical ideal to attempt to approach
> with a real character) is key to this.
Unfortunately, that's a holy grail of balance that classless systems
rarely find. :( Class systems by definition are about striving for the
ubercharacter, of course.
> As soon as you get
> characters being gradated variations of the same definition you've
> lost, as you then have a battle for nearest approximate to a single,
> and thus known, goal, and that instantly reduces the player-apparent
> complexity of the game down to a selection of which particular
> uber-target to go for next.
In UO terms, the "tank-mage." A common problem to most classless
systems, however. If you'll take a leap of faith with me and visualize
classless systems as a rubber sheet... :) Time for a physics
experiment...
Usually there's a single intersection point at which the rubber sheet is
distorted (tankmage, for example). Characterballs rolled on the sheet
will tend to fall into that depression. Secondary depressions will also
be formed, but one of the depressions will probably be more powerful.
Even if you strengthen the secondary depressions, you're never going to
get a flat sheet. A chessmaster/fisherman is simply never going to be
regarded as being as valuable as a warrior/mage, any more than a
grandmaster buggy whip manufacturer is regarded as being as valuable as
a computer programmer today. Certain skills and skill sets are not in
common everyday demand, and thus are not as well-regarded.
> If instead all characters are *really*
> unique (largely guaranteed significant functional difference from
> all others), then even if you have a limited set of presumed
> uber-target characters, the path that any given character has to
> take to get there will be different and *none* of them will arrive
> at the same or similar locations but will instead create wildly
> variant approximations of the uber-target. I suspect that once you
> reach that point that the deviance from the uber-target will then be
> more interesting than the uber-target, thus actively working to
> devolve the perceived value of the uber-target.
Now this is interesting. The question arises, how large a rubber sheet
do you need to accomplish this? In other words, how many truly
interesting and useful "secondary" skills can you provide?
In addition, I'd note that on the face of it, it seems somewhat
incompatible with the atrophy-and-learn-something-new model that Marian
described in her post. Thoughts on merging the two?
> <<Does this make any sense?>>
It did to me, at any rate. :) The list can warn us, hopefully, if we get
to overly rarefied discussion. :)
BTW, one factor that is overlooked here is the "mule" phenomenon--it's
rampant on UO, perhaps because of this very design concept. I had never
heard the term before Meridian 59, but I am sure it must have existed
before. This is where players simply make alternate characters to make
use of the lesser-used skills. Your "main" character fits a
stereotypical ubercharacter ideal, but you make alternates for those
occasions when you want the secondary skills. In UO, that is generally
for the crafting skills.
> Without digging up the archives, I'm reminded of a post I wrote to
> Marian on controlling/influencing player actions where I drew the
> analogy that controlling player actions is much like attempting to
> control a torrential river rushing (and cutting a channel) across a
> soft plain (King Knut?). In that model putting up dams is doomed to
> failure as the torrent will perceive them as targets and
> aggressively undermine them. In the above character development
> model, the goal is to create an evenly distributed mesh of minor
> tributaries (one stream per player), which wander, cross, and
> fragment the plain. The problem being to prevent larger stream
> formation.
I assert that some streams will always be better than others. You'll get
interesting watersheds with multiple major streams and great variance in
the small creeks. But (to push the analogy into absurdity) some fishin'
holes are always going to be better than others. Some images of
ubercharacters will always serve as greater attractors.
-Raph - Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Alex Oren
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Matt Wallace
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Holly Sommer
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Matt Wallace
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. D. B. Brown
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Vladimir Prelovac
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Nathan F Yospe
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Jon A. Lambert
- Levels versus Skills, who uses them and when. Travis S. Casey
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Petri Virkkula