April 1998
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Chris Gray
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. J C Lawrence
- OT: This is a test of a system config change. coder@ibm.net
- MUD Development Digest Dr. Cat
- MUD Development Digest Justin McKinnerney
- MUD Development Digest Nathan F Yospe
- MUD Development Digest Justin McKinnerney
- MUD Development Digest J C Lawrence
- MUD Development Digest J C Lawrence
- MUD Development Digest Jon A. Lambert
- MUD Development Digest Chris Gray
- MUD Development Digest J C Lawrence
- MUD Development Digest J C Lawrence
- MUD Development Digest J C Lawrence
- MUD Development Digest Ben Greear
- MUD Development Digest Jon A. Lambert
- MUD Development Digest Chris Gray
- MUD Development Digest Ben Greear
- MUD Development Digest Dr. Cat
- MUD Development Digest Ben Greear
- MUD Development Digest Justin McKinnerney
- MUD Development Digest Dr. Cat
- MUD Development Digest Justin McKinnerney
- MUD Development Digest Dr. Cat
- MUD Development Digest J C Lawrence
- MUD Development Digest Matt Chatterley
- MUD Development Digest J C Lawrence
- GRUMPS maddog@best.com
- caved in: Algorithms for for storing free space. Ben Greear
- internet connections Chris Gray
- GRUPMS? Vadim Tkachenko
- [Fwd: MUD-Dev] Richard Woolcock
- [Fwd: MUD-Dev] Nathan F Yospe
- [Fwd: MUD-Dev] coder@ibm.net
- [Fwd: MUD-Dev] Katrina McClelan
- [Fwd: MUD-Dev] Richard Woolcock
- [Fwd: MUD-Dev] J C Lawrence
- [Fwd: MUD-Dev] Travis S. Casey
- [Fwd: MUD-Dev] maddog@best.com
- [Fwd: MUD-Dev] J C Lawrence
- [Fwd: MUD-Dev] J C Lawrence
- [Fwd: MUD-Dev] Jon A. Lambert
- [Fwd: MUD-Dev] Richard Woolcock
- Meta: who dat guy, wot dat web? coder@ibm.net
- Meta: who dat guy, wot dat web? Katrina McClelan
- Meta: who dat guy, wot dat web? s001gmu@nova.wright.edu
- Meta: who dat guy, wot dat web? J C Lawrence
- Meta: who dat guy, wot dat web? Jon A. Lambert
- Meta: who dat guy, wot dat web? J C Lawrence
- [META] Mailing lists Katrina McClelan
- [META] Mailing lists Travis S. Casey
- META: The web presence and wot it ain't gonna be J C Lawrence
- META: The web presence and wot it ain't gonna be Shawn Halpenny
- META: The web presence and wot it ain't gonna be J C Lawrence
- META: The web presence and wot it ain't gonna be J C Lawrence
- (fwd) code for teleport coder@ibm.net
- (fwd) code for teleport Ben Greear
- (fwd) code for teleport s001gmu@nova.wright.edu
- (fwd) code for teleport J C Lawrence
- META: Archive of Megami/Wout's list's traffic? Archive of the CC: list? J C Lawrence
- Resisting Charm or you're cute and nice, but not to die for. Jon A. Lambert
- Resisting Charm or you're cute and nice, but not to die for. s001gmu@nova.wright.edu
- Resisting Charm or you're cute and nice, but not to die for. Katrina McClelan
- Resisting Charm or you're cute and nice, but not to die for. J C Lawrence
- Genetic Algorithms Jon A. Lambert
- MUD Development Digest J C Lawrence
- MUD Development Digest Alex Oren
- MUD Development Digest Chris Gray
- MUD Development Digest Jon Leonard
- MUD Development Digest Jon A. Lambert
- Resisting Charm or you're cute and nice, but not Jon A. Lambert
- Unreal J C Lawrence
- META: The web archives are up for review (alpha 1) J C Lawrence
- META: Archive of Megami/Wout's list's traffic? Archive of Alex Oren
- RGMA Alex Oren
- META: That bloke Yaltec. Khan one
- META: That bloke Yaltec. J C Lawrence
- a fruitful exchange on classlessness in r.g.m.admin Cimri
- MAGE 2 MAGE v. 0.88 J C Lawrence
- META: membership (was a fruitful exchange on classlessness in r.g.m.admin) coder@ibm.net
- META: Archive of Megami/Wout's list's traffic? Archive of Wout Mertens
- (fwd) Development of new code base coder@ibm.net
- Seductions of Sim: Policy as a Simulation Jon A. Lambert
- Seductions of Sim: Policy as a Simulation J C Lawrence
- META: membership (was a fruitful exchange on clas Jon A. Lambert
- Resisting Charm or you're cute and nice, but not t Jon A. Lambert
- META: Web futures and the demise of MUD civilisation as we know it. coder@ibm.net
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! Caliban Tiresias Darklock
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Richard Woolcock
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Vadim Tkachenko
- There can be.. only ONE! Jon A. Lambert
- There can be.. only ONE! Vadim Tkachenko
- There can be.. only ONE! Jon A. Lambert
- There can be.. only ONE! Richard Woolcock
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Ling
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! Matt Chatterley
- There can be.. only ONE! J C Lawrence
- There can be.. only ONE! J C Lawrence
- OT: Caballah [was Character development] Alex Oren
- OT: Caballah [was Character development] Caliban Tiresias Darklock
- OT: Caballah [was Character development] Vadim Tkachenko
- OT: Caballah [was Character development] Vadim Tkachenko
- OT: Caballah [was Character development] Marian Griffith
- OT: Caballah [was Character development] Jon A. Lambert
- Personality modelling Oliver Jowett
- Personality modelling J C Lawrence
- Personality modelling J C Lawrence
- META: membership Holly Sommer
- META: membership Cimri
- META: membership s001gmu@nova.wright.edu
- META: membership Katrina McClelan
- META: Other mailing lists Alex Oren
- META: Other mailing lists J C Lawrence
- META: Web site backgrounds and readability J C Lawrence
- META: Web site backgrounds and readability Cimri
- META: Web site backgrounds and readability Holly Sommer
- META: Web site backgrounds and readability plateau
- META: Web site backgrounds and readability Vadim Tkachenko
- META: Web site backgrounds and readability Caliban Tiresias Darklock
- META: Web site backgrounds and readability Vadim Tkachenko
- META: Web site backgrounds and readability Greg Munt
- META: Web site backgrounds and readability J C Lawrence
- META: Web site backgrounds and readability Caliban Tiresias Darklock
- META: Web site backgrounds and readability Matt Chatterley
- META: Web site backgrounds and readability Holly Sommer
- META: Web site backgrounds and readability Jon A. Lambert
- META: Web site backgrounds and readability Caliban Tiresias Darklock
- META: Web site backgrounds and readability Jon A. Lambert
- META: Web site backgrounds and readability J C Lawrence
- META: Archive message format J C Lawrence
- (fwd) equipment J C Lawrence
- 3D evaluation? J C Lawrence
- META: Archive searching now works... J C Lawrence
- META: Archive searching now works... Bruce Mitchener
- META: Archive searching now works... J C Lawrence
- Fw: [DESIGN] Combat system Richard Woolcock
- [Fwd: Grids and curvature of a sphere] Richard Woolcock
- [Fwd: Grids and curvature of a sphere] Caliban Tiresias Darklock
- [Fwd: Grids and curvature of a sphere] J C Lawrence
- [Fwd: Grids and curvature of a sphere] J C Lawrence
- SfD: AI and muds; several approaches Nathan F Yospe
- META: We have moved. J C Lawrence
- (fwd) Mudlib Design J C Lawrence
- (fwd) SERVER: New Code Base in VB Started J C Lawrence
- (fwd) SERVER: New Code Base in VB Started Jon A. Lambert
- Graphical MUD project (Sea Of Blood) J C Lawrence
- (fwd) Sea of Blood Graphical MUD J C Lawrence
- MAPPING: Creating a bitmaped graphic from map coordinates John Bertoglio
- MAPPING: Creating a bitmaped graphic from map coordinates Nathan F Yospe
- MAPPING: Creating a bitmaped graphic from map coordinates John Bertoglio
- MAPPING: Creating a bitmaped graphic from map coordinates s001gmu@nova.wright.edu
- MAPPING: Creating a bitmaped graphic from map coordinates Jon Leonard
- MAPPING: Creating a bitmaped graphic from map coordinates Caliban Tiresias Darklock
- MAPPING: Creating a bitmaped graphic from map coordinates J C Lawrence
- MAPPING: Creating a bitmaped graphic from map coordinates Vadim Tkachenko
- Gentle Reminder J C Lawrence
- Systems you use Ling
- Systems you use Caliban Tiresias Darklock
- Systems you use J C Lawrence
- Systems you use Adam Wiggins
- Systems you use Jon A. Lambert
- Systems you use Katrina McClelan
- Systems you use J C Lawrence
- Systems you use Katrina McClelan
- (fwd) CODE RELEASE: [client] Jcrossclient - java client to "crossfire" J C Lawrence
- Teamwork Ling
- Teamwork J C Lawrence
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- MAPPING: Creating a bitmaped graphic from map J C Lawrence
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- MAPPING: Creating a bitmaped graphic from map John Bertoglio
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- MAPPING: Creating a bitmaped graphic from map Caliban Tiresias Darklock
- MAPPING: Creating a bitmaped graphic from map Jon A. Lambert
- (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Ben Greear
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Matt Chatterley
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Chris Gray
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
- (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Jay Sax
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Dr. Cat
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Caliban Tiresias Darklock
- (fwd) AD: [custom graphical] whitestar Crossfire MUD J C Lawrence
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Matt Chatterley
- (fwd) AD: [custom graphical] whitestar Crossfire MUD Chris Gray
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) Adam Wiggins
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- There can be.. only ONE! (fwd) Jon A. Lambert
- There can be.. only ONE! (fwd) J C Lawrence
- There can be.. only ONE! (fwd) Matt Chatterley
- How to represent a 3d object... Ben Greear
- How to represent a 3d object... Oliver Jowett
- How to represent a 3d object... Ben Greear
- How to represent a 3d object... Justin McKinnerney
- How to represent a 3d object... J C Lawrence
- fwd Room descriptions, was Roleplaying John Bertoglio
- fwd Room descriptions, was Roleplaying Chris Gray
- fwd Room descriptions, was Roleplaying Ling
- fwd Room descriptions, was Roleplaying J C Lawrence
- Room descriptions, was Roleplaying Richard Woolcock
- Room descriptions, was Roleplaying John Bertoglio
- Java for Mud Client (Crossfire MUD topic) Justin McKinnerney
- Java for Mud Client (Crossfire MUD topic) Joel Dillon
- Java for Mud Client (Crossfire MUD topic) Justin McKinnerney
- Java for Mud Client (Crossfire MUD topic) Joel Dillon
- Java for Mud Client (Crossfire MUD topic) s001gmu@nova.wright.edu
- Java for Mud Client (Crossfire MUD topic) J C Lawrence
- Java for Mud Client (Crossfire MUD topic) J C Lawrence
- Java for Mud Client (Crossfire MUD topic) Ben Greear
- Java for Mud Client (Crossfire MUD topic) J C Lawrence
- META: mud-dev@null.net is now decommissioned. J C Lawrence
- META: mud-dev@null.net is now decommissioned. John Bertoglio
- META: mud-dev@null.net is now decommissioned. J C Lawrence
- Group mechanics/Leadership [was: Room descriptions] Shawn Halpenny
- Group mechanics/Leadership [was: Room descriptions] John Bertoglio
- (fwd) [DESIGN] Macro semi-language J C Lawrence
- (fwd) [DESIGN] Macro semi-language J C Lawrence
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Dr. Cat
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Marian Griffith
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Chris Gray
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Koster, Raph
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) Adam Wiggins
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- OT: Birth announcement Koster, Raph
- OT: Birth announcement Nathan F Yospe
- OT: Birth announcement J C Lawrence
- OT: Birth announcement J C Lawrence
- OT: Birth announcement John Bertoglio
- OT: Birth announcement J C Lawrence
- OT: Birth announcement Jon A. Lambert
- OT: Birth announcement Koster, Raph
- (fwd) POLL: Games ruined by bad players (Playe Jon A. Lambert
- (fwd) POLL: Games ruined by bad players (Playe Dr. Cat
- (fwd) POLL: Games ruined by bad players (Playe J C Lawrence
- (fwd) POLL: Games ruined by bad players (Playe Dr. Cat
- (fwd) POLL: Games ruined by bad players (Playe J C Lawrence
- (fwd) POLL: Games ruined by bad players (Playe Richard Woolcock
- Some thoughts on languages and users - was: Macro semi Jon A. Lambert
- PK's: A solution? John Bertoglio
- PK's: A solution? Shawn Halpenny
- PK's: A solution? Michael Hohensee
- PK's: A solution? s001gmu@nova.wright.edu
- PK's: A solution? J C Lawrence
- PK's: A solution? Katrina McClelan
- PK's: A solution? John Bertoglio
- PK's: A solution? Holly Sommer
- PK's: A solution? J C Lawrence
- PK's: A solution? John Bertoglio
- META: Membership authentication J C Lawrence
- (fwd) MOB or player? Global Communications on Muds J C Lawrence
- (fwd) MOB or player? Global Communications on Muds John Bertoglio
- (fwd) Confusing? J C Lawrence
- (fwd) Confusing? Chris Gray
- (fwd) POLL: Games ruined by bad players (Player killers, tank rushers etc) J C Lawrence
- PK and my "Mobless MUD" idea Jay Sax
- PK and my "Mobless MUD" idea Caliban Tiresias Darklock
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Chris Gray
- PK and my "Mobless MUD" idea Ling
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Koster, Raph
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Jon A. Lambert
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Koster, Raph
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Alex Oren
- PK and my "Mobless MUD" idea Jon A. Lambert
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Dr. Cat
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea s001gmu@nova.wright.edu
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea Koster, Raph
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Caliban Tiresias Darklock
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea Caliban Tiresias Darklock
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea John Bertoglio
- PK and my "Mobless MUD" idea J C Lawrence
- PK and my "Mobless MUD" idea Adam Wiggins
- PK and my "Mobless MUD" idea Marian Griffith
- PK and my "Mobless MUD" idea John Bertoglio
- META: Mail archives and MIME attachments J C Lawrence
- META: Mail archives and MIME attachments Jon A. Lambert
- Bio of John Bertoglio J C Lawrence
- Reuters: Cheaters Never Prosper J C Lawrence
- Correction s001gmu@nova.wright.edu
- Supporting articles found for UOL play style J C Lawrence
- Supporting articles found for UOL play style John Bertoglio
- Supporting articles found for UOL play style J C Lawrence
- Supporting articles found for UOL play style John Bertoglio
- Supporting articles found for UOL play style Koster, Raph
- Supporting articles found for UOL play style J C Lawrence
- Supporting articles found for UOL play style Koster, Raph
- Mud-Client, and specifically, COOLMud and SFWhite Jay Sax
- regulating player-created objects Dan Shiovitz
- regulating player-created objects Adam Wiggins
- regulating player-created objects Dan Shiovitz
- regulating player-created objects Adam Wiggins
- regulating player-created objects s001gmu@nova.wright.edu
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Marian Griffith
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
- regulating player-created objects Brandon J. Rickman
- regulating player-created objects Adam Wiggins
- regulating player-created objects Nathan F Yospe
- regulating player-created objects Nathan F Yospe
- regulating player-created objects Nathan F Yospe
- regulating player-created objects Dan Shiovitz
- regulating player-created objects Shawn Halpenny
- regulating player-created objects J C Lawrence
- regulating player-created objects J C Lawrence
- regulating player-created objects John Bertoglio
- atomic functions Felix A. Croes
- atomic functions Shawn Halpenny
- atomic functions Felix A. Croes
- atomic functions Shawn Halpenny
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions J C Lawrence
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions Felix A. Croes
- atomic functions Joel Dillon
- atomic functions Jon A. Lambert
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions J C Lawrence
- atomic functions Chris Gray
- atomic functions Jon A. Lambert
- atomic functions Shawn Halpenny
- atomic functions Adam Wiggins
- atomic functions Adam Wiggins
- atomic functions Shawn Halpenny
- atomic functions J C Lawrence
- atomic functions Jon A. Lambert
- atomic functions Chris Gray
- atomic functions J C Lawrence
- atomic functions Felix A. Croes
- atomic functions Shawn Halpenny
- atomic functions Felix A. Croes
- atomic functions Jon A. Lambert
- atomic functions Shawn Halpenny
- atomic functions Jon A. Lambert
- atomic functions J C Lawrence
- Atomic functions Par Winzell
- Atomic Functions Ben
- Atomic functions Felix A. Croes
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- (fwd) AD: [custom graphical] whitestar Caliban Tiresias Darklock
- (fwd) AD: [custom graphical] whitestar Dr. Cat
> On 12:12 PM 4/30/98 -0500, I personally witnessed Dr. Cat jumping up to say:
> >
> >Well, I don't know if many people do, given the "not much interest" you
> >cite from prior attempts.
>
> I've always suspected it was because nobody knew who I was and therefore
> couldn't take me seriously, but I also had this nagging feeling that I
> wasn't giving people enough credit. ;)
Occam's Razor still says to me "hey, if not many people are acting
interested, probably not many people here ARE interested". Just a hunch.
> How do you feel about 'modes' of operation, like a novice/expert toggle? I
> always detested them, myself, since it always seemed like neither of them
> ever quite fit the way I interacted with the game. Have you ever seen one
> done well?
I feel a strong need as a designer to have novice/expert toggles some
places, maybe three levels other places. For the one specific
instance of the DragonSpeak editor (that's the scripting language) I
could easily envision 5 or 6 levels, but that's something of a special case.
I have seen very few of these types of things, and I don't know whether
one exists out there that I'd feel to be "done well". I really don't
know that I have enough experience with the prior art to comment
meaningfully on what's been done before in this area.
Generally I think this sort of thing is most appropriate where you are
targeting (as with Furcadia) a very broad audience, and the more narrowly
targeted your game is, the more likely it is that a single interface for
everybody is appropriate. Indeed, I think multi-modes is something of a
special case that's only appropriate for mass media. If you have
millions of players, catering to a niche could still cover a pretty large
group of people. If you have ten players... Hey maybe some of them have
radically different tastes in interface than the others... I say tough,
let 'em live with it!
Regardless of whether you provide one interface "mode" or several, you
should make the game client as customizable as you can get away with,
while maintaining consistency with your other goals (which may or may not
require things like fixes window sizes and positions rather than
configurable ones - it just depends on what the goals are). There should
be template files that store all the configurable options about
appearance, layout, keyboard definitions, etc. And you should default to
a template that's reasonably comfortable to use, but provide several
others with descriptions of what they're good for (good for Laptops with
no numberic keypad - good for maximizing text chat space - good for
keeping all combat-related functions quickly and easily accessible, etc.)
Let players make their own templates and share them with each other.
Basically, most people at this stage in evolution are stuck being
monoperspectivists, which means that for any issue, they feel, act, and
think like there's only one attitude that people have (or should have,
anyway) about that issue. Of course the fact of the matter is, if you
have 1000 people, on any particular issue they're likely to have at LEAST
2 different opinions, preferences, etc. Possibly 3 or more. Sometimes,
239. And occasionally 1008.
One step up from the monoperspectivist is the person who knows
intellectually that other perspectives exist on issues, in the minds of
other people - but still can't grasp what it feels like to have that
different perspective, can't understand why anyone would think that, just
can't grok that other viewpoint. And it makes their head hurt to try to
think about it too much. So they end up designing and coding interfaces
(and game designs, etc.) the same way a monoperspectivist would. Which
is generally to code things exclusively to cater to "people with tastes
like me".
Well that works ok if you're a person who has tastes that match a lot of
other people's tastes reasonably well. (Or if you match only a modest
number, but you don't really care whether many people play your game or
not anyway.)
But I try to take one step past that. For broadest appeal, I try to
evaluate every interface decision by estimating the diversity of tastes
on that issue. If it's 99% option A, and 1% option B, you can probably
hardcode option A into your game - unless you have resources to spare and
can be a purrfectionist! If it's 92% A, and 8% B, that might be a good
candidate for saying "The game defaults to A, a pulldown menu option or a
checkbox in an 'options' dialog allows the selection of B." The idea is
to keep the knowledge that it's even possible to switch to option B from
bothering the 92% of the players who, most of them, don't even want to
know that. Out of sight, out of mind. Then you decide whether the game
stores the setting, so people that pick option B will get it again on
their next gaming session, or whether it always starts up in A and makes
you switch. This depends on the nature of the option, the reasons for
wanting to switch it, and the nature of the people in that 8% group.
(This scenario is an oversimplification, too - you might get 85% "always
A" people, 6% "always B" people, and 9% "use both sometimes, switch
depending on which I want/need at the moment". In that case, the reasons
and behavior patterns of the switchers play a significant role in
determining whether to make the switches persist to the next session or not.)
If you get a case where tastes are something like 70% A and 30% B, things
start to get a little more interesting. Here you may well want to make
the choice "in your face", so everyone knows that both A and B are available.
The penalty of not doing so, that as many as 30% of the players may fail
to choose the option that would make the game most enjoyable for them, is
getting pretty steep at this point. Exactly how you do this depends on
various details. Is it something people would want to switch back and
forth a lot? Button on the main game display, always visible. Is it
something where they probably want to pick the best choice of their tastes,
and then leave it that way forever? Several criteria. If it has a major
impact on how much people enjoy the game, you may want to make it a
one-time configuration question during setup, the first time they play
the game. Display very clear, well written text (and illustrations too
if appropriate) to make sure they understand the choice, force them to
say yes or no, and make the default button that's selected if they just
press Enter option A, since A is the 70% choice. Couple this with the
obscure pull-down menu or options dialog choice to change it later. This
works well for something people are fairly certain to A) know what they
really want in regards to, and B) accurately select that. If it's
something they might look at and go "gee I don't realy know what I'd
prefer in that regard, I was never offered such a choice in any previous
life-experience and haven't played this type of game before either", you
might consider sticking with the always visible toggle button. Or doing
the configuation step, but forcing a "did that work out for you or do you
want to switch from A to B right now" dialog to appear a couple days
later, for the people who will never hunt through pull-down menus and
options dialogs. Or you might want to strongly encourage older players
of the game to help newer players out with this decision, in some way.
If you have a 70/30 split on a question that's of more minor impact to
game enjoyment, you can do things like pop up a dialog two weeks after
they've been around and say "Now that you're more experienced you may
wish to refine you game settings to increase your conveniene and
enjoyment. Would you like A or B?" The real brilliance will come in
spacing these messages and dialogs out appropriately, even coming up with
complex triggering conditions based on user behavior rather than just time.
> This sounds a little like the MS Office Assistant. In my experience, most
> people seem to hate it. I for one like it, but not because of the help... I
> like that the little paperclip dances around and acts suave and
> sophisticated in the corner of the screen. In other words, I like the
> degree of levity it introduces to the process of boring memo writing. When
> it pops up help messages, I tend to be a little irritated. Are you familiar
> with this feature of MS Office, and if so, what's your immediate impression
> of it?
The danger with time based unsolicited offers of assistance is that
you're being an immense pest. I in fact spent one session running a
program last year that had the dancing paperclip. I found it amusing,
but think it rapidly would have become annoying had I used the program
regularly. The vast majority of designers/programmers seem to put these
things in so they happen WAY too often. You should be interrupted
seldom, and generally only for the things that are mostly likely to add
to the experience for you, rather than making you frown and say "The
choice between A and B is irrelevant, that's trivial and I would enjoy
the game equally either way and besides it's asking me how to fine tune
the interface to one of the game features that I NEVER USE ANYWAY! Go
away and get lost!"
Frankly it's not like we HAVE to be operating in the blind, with regard
to online applications. They connect to our servers all the time, we
could be having them tell us millions of little details about user
behavior, all the way down to how many inches per hour do they roll their
mouseball around on the little rubber mat? We could be, but we're not.
I ran a roundtable at the 1997 CGDC (being a believer in not obscuring my
meaning with jargon unknown to a significant percentage of the audience,
I'll clarify that that stands for Computer Game Developer's Conference)
on the subject of gathering player and activity data in online games, and
I got the lowest attendance of any roundtable I ever moderated. (Sex in
Computer Entertainment was highest for some reason - go figure! Though
when I ran the first roundtable on MUDs at the conference turnout was
also pretty good).
I think most of the development community isn't quite ready to get this
sophisticated yet.
Consider, though. Let's say 70% of our users will want to have the left
mouse button activate the flomgisticulator. And 30% of them would enjoy
the game much more if the left mouse button defaults to turning on the
phlogamzitronic shields. But let's assume further that most of our users
will have NO clue which of these things they'd prefer while they're
reading the opening text or going through the setup screens - they'll
need to play the game for days or weeks before they know it well enough
to make that choice. (Indeed, it takes 2-5 hours of play before the user
even finds out what a flomgisticulator is!)
So let's say we want Beekin the Help Dragon (who has somehow wandered out
of Furcadia and found his way into the weird science fiction game of this
example in some incomprehensible fashion) to pop up after an "appropriate
period". Problem is, we have NO idea what an appropriate period is,
because we have ZERO prior experiene with how long it takes players to
learn this game, which we only finished and released to the net five
minutes ago!
Data Collection Man to the rescue! Let's say we put that option in the
pulldown menu, the options box, or maybe even the "so obvious you can't
miss it" big button on the screen. Let people play. Record all the
times anyone changes that option setting... Now analyze that data!
We might want to look at when they make a LASTING change to the setting.
If they switch it back and forth a bit, maybe they went and fiddled with
it when they didn't reeeeeally know the game well enough to pick what
they would want. If they put it on setting B and leave it there for six
months, you can probably assume at the moment in time when they set it
they probably had some idea what they wanted. (Though there's always the
few oddball exceptions.)
Let's say 99% of the users are going and making their final, permanent
choice on their 17th day of play. Simple! We could have Beekin pop up
on day 17 and offer them the choice. But let's say the choice was buried
in a deep obscure settings dialog, and we think the average person might
be finding that a week later than they really woulda been ready for it,
just because it's in such an obscure spot. But that "one week" is a seat
of the pants guess, not something we've measured! No problem. Set
Beekin for ten days, have him ask "pick A now", "pick B now", "ask me
again in a few days", or "Go away Beekin, I'm smart enough to know that
it's under the Fleeble menu option if I need it". Now measure the
frequency of the different responses with Beekin set at 10 days! You can
very easily determine if Beekin is asking too early, by tracking how
people respond. If you ARE to soon, bump him back a few days and measure
again. (You DID keep your Beekin settings controlled on the server end,
rather than making it so people would need a new client to change those
intervals, RIGHT?)
Let's say we DON'T have 99% of the users all making the choice in the
same brief window. Let's say there's a big standard deviation on the
distribution, the day people choose their setting varies from day 10 to
day 42. Now we don't want to just split the difference and ask on day
26. Some people aren't asked until way later than they would have been
ready to answer and start enjoying the game yet. Other people would be
asked way before they're ready.
Let's presume "readiness to be asked this" relates to proficiency in some
particular areas of the game. Let's theorize that some other measurable
factors also relate to proficiency in those same areas. If we can find
one or more of those, maybe we can make a good personalized guess about
when to have Beekin ask you. Let's say we measure the number of times
per day you use the flomgisticulator, the number of times per minute you
click any mouse button anywhere on the game screen, and a dozen other
factors. Calculate correlation indexes to determine which of them have a
strong correlation between them and whether or not the player's made his
final choice of setting or not. Maybe it turns out that most people that
click more than 6.2 times per minute have made the choice, and most
people that click less than that haven't, and that clicks per minute
tends to rise over the first few weeks as people learn the game. Ok,
bingo, pop up Beekin's dialog box when they cross 6.2 clicks per minute.
If there's a good correlation between flomgisticulator uses per day also,
maybe you can improve your odds of making a good call by factoring that
value in too, and weighting the two criteria.
> Bringing into this
> the idea of pop-up help, after a person reaches some particular milestone
> you might want to pop up a request that they join the newbie helper team. A
> lot more people would treat that as an honor instead of a duty, as opposed
> to requesting that people specifically volunteer to join the team without
> prompting. You might ask at two or three different milestones, if they
> don't 'jine up', to see if they've had a change of heart.
I have grave doubts that good criteria can ever be found for automated
determination of good candidates. You could measure something like
percentage of time spent talking while in hearing range of one or more
newbies (players with less than N hours of playing time logged). But
this would catch a professional newbie-taunter as readily as a dedicated
newbie helper. It wouldn't distinguish a really good newbie helper from
a well-meaning but bumbling one. And it'd scoop up some people in the
net who just happen to hang around the starting areas a lot with their
friends, and don't happen to have much of any interest in newbies at all.
Besides, an invitation from a robot doesn't convey a fraction of the
surge of warmth through your body that you feel when being invited to an
honored post by a real person, especially a person of rank and signifiance.
One of our first four assistants told me he was all misty-eyed when I
told him how helpful he was and how he was practically the ideal example
of how we'd like people to be in our game.
The key to things like this is developing heirarchies, so that when you
have 100 times as many players you don't have a few staffers scrambling
to talk to thousands of people a day to keep up with this stuff.
Climbing up through the heirarchies and growing in social status becomes
the major focus of the game for some people. We're seriously considering
making it a major focus for most people. That and getting attention
(number of player-hours spent on your maps and stuff), which is the basis
of the currency system. The more diversion you're providing for your
fellow players, the more spending money you'll have.
Attention IS the currency of the future.
*-------------------------------------------**-----------------------------*
Dr. Cat / Dragon's Eye Productions || Free alpha test:
*-------------------------------------------** http://www.bga.com/furcadia
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------*
--
MUD-Dev: Advancing an unrealised future. - (fwd) AD: [custom graphical] whitestar J C Lawrence
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- DOOM Gets a Storyline? Holly Sommer
- DOOM Gets a Storyline? Koster, Raph
- META: Filtering suggestions J C Lawrence
- (fwd) AD: [custom graphical] whitestar s001gmu@nova.wright.edu
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- (fwd) AD: [custom graphical] whitestar J C Lawrence
- UO in Wired, was OT: Birth announcement Koster, Raph