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
> If I might interject, I have the same sort of issues with most other MUD
> developers. Unfortunately, I don't have the time to seriously develop an
> active project; however, interface design and mass marketability are key
> issues I would dearly love to discuss. Some time back, I tried to start
> such a thread. It crops up peripherally now and again, but I've never
> really seen as much interest in it here as I'd like to.
[snip]
> Basically, I'm hearing you say that you want to talk about the same things
> *I* want to talk about, and postulating that no one wants to hear it. I do.
[mild flattery snipped]
Well, I don't know if many people do, given the "not much interest" you
cite from prior attempts. Anyway despite my earlier cranky remarks (I
suppose I forgot to take my geritol that morning and the nurse didn't
bring me my walker either so I couldn't cross the room to turn on the TV)
the main reason I don't talk about my work too much is because I have
hundreds of things to implement, most of which I thought up years ago,
and only one programmer (me) working on them. And talking about the
stuff doesn't get it done, adds only a small amount to my pool of ideas
for what to do through the ensuing discussion - and with hundreds of
things to do already that will make my product better, I really don't
need ANY new things tossed in there, do I? With the tiny subset of my
plans that's currently implemented, and usage levels that only reach
around 150 players at peak times, it's really "put up or shut up" time,
and I'd rather go "put up" and talk later.
Still, flattery is flattery, and I can toss out a few more comments here
- even though I sense you're asking somewhat different sorts of questions
about user interface design than the ones I'm thinkg about.
> Let me open this up with a few observations I've made about command
> interfaces. I don't talk about this much, because command interfaces don't
> seem to be of much concern in discussions here. By command interface, I
> don't necessarily mean a command line, but whatever method the user employs
> to communicate with the server; in most cases here, that means a command
> line, but most people have at least some interest in going partially or
> fully point-and-click. It's not much of a secret that I tend to prefer text
> to graphical, based on certain economies of bandwidth and disk which come
> from that, but I have to admit that when push comes to shove graphical will
> pull more users.
This is a non-issue to me. All functions wherever possible must be
executable using either mouse-only or keyboard only. This just seems
intuitively obvious to me. Generally the "easy for novices" way of doing
a thing (usually, but not always, the mouse interface) should be the
easiest to notice (or have shoved in your face by the documentation),
while the "power user" interface should be not too hard to find out
about, but not "in your face" if you don't desire it and don't go looking
for it.
Bandwidth isn't a big issue either. Right now the traffic for Furcadia
with 100 users online is usually small enough that it could fit through a
single 56K modem. Of course the server's going through a T-1, as well it
should be - a maxed out modem would be giving people lots more latency,
not to mention choking on the occasional bursts of higher bandwidth
utilization. But the point is, bandwidth usage on a well designed
graphic mud doesn't necessarily have to be high. Indeed, the current
bandwidth usage on Furcadia can be (and will be) further reduced with
some additional optimizations.
> To a degree, this can be remedied with natural
> language processing, like shorthand:
>
>
> "Look." [There is a blue box here.] "Examine it." [You pick up the blue box
> and examine it; there is a button on the side.] "Press it." [You press the
> button on the box; the box makes a loud noise and begins to vibrate.] "Drop
> it." [You drop the blue box; it vibrates more urgently.] "Hide." [You duck
> behind something; the box explodes, but you are shielded from the blast.]
This, to me, is a false grail. As I mentioned earlier with regard to my
scripting language, I'm a strong believer in mapping the tools tightly to
the expected solution space. Regretably most software developers seem to
feel that the solution space is (or should be) "as many different things
that are possible to do as I can possible enable the users to do". This
is the correct solution space to shoot for if you're developing a C
compiler. If I wanted my players to have the maximal power to interact,
maybe I should just give them Unix shell accounts and a C compiler and
say "Ok, go to it! Play, have fun! If you want to play in some
particular specific way, go code it!"
In software aimed at consumers, particularly non-programming consumers
(the majority of the human species, even now), I think the value your
software has is directly related to how well you figure out "what is the
set of things most users of this category of software most want to do",
and build the capabilities of your software to be tightly coupled to that
set of desires. Where you provide more power or flexibility, you should
do interface design such that the most desired options are obvious and
easy to figure out, and the extra stuff is findable but not "in your
face" to the users with simpler wants/needs - who will only become
distressed if you throw up some screen with 173 options, buttons,
sliders, and commands.
Print Shop was a good example of this, back in the 80s. When it came out
us power-users and developers-of-tools-for-other-power-users looked down
our noses at it. Things like paint programs, desktop publishing
software, etc. etc. was FAR more powerful than this wussie little toy.
Why would anyone even want it? Well, it did a few things, but it turned
out it did the few things that a LOT of people wanted to do, and it made
it so quick and EASY to figure out how to do them! They sold that thing
so fast that everyone at Broderbund had to pitch in to help duplicate
disks and stuff boxes in order to ship all the orders to distributors -
from the secretaries right on up to the president!
Natural language doesn't fit well with this, for me. Not only are you
suggesting, by providing it, that "any English sentence you can type is a
valid command string", thus offering the poor person trying to learn your
game the hugest possible solution space, but it's not even a case of
covering all that solution space for the power-users at the expense of
the novice. Your game is always going to be stuck understanding only a
tiny percentage of the potential command strings, and even the power
users will have to learn which things really work. My senior apprentice
calls this kind of thing "fighting the interface", and it's very bad.
"Look. [There is a blue box here.] Turn it over and read the writing to
see if it was made in Taiwan. [I see no writing on the blue box.] Listen,
jamoke, I wanna know if it was made in Taiwan! [I see no player named
"jamoke" here.] Whassa matter with you, you stupid computer, don't you
understand plain english? [I'm not sure what you're trying to do. Type
'help' for more instructions.] Aw nuts to you, just nuke that blue box
and tell me where I can go in this game to find some lasagna to eat or
meet some cool people to talk to that like the same TV shows I do. [I'm
sorry, Dave, I'm afraid I can't do that.]"
By contrast, if you had SimpleGraphicMud where you had four compass
arrows to click on to move, a text input box labelled "type messages here
to talk to other players on your screen", and buttons labelled "get"
"drop" and "use" for dealing with objects you see on the ground, it's
unlikely that anyone would waste much time trying to do things that
aren't doable in your game. Players not feeling like they're wasting
time is a good thing. Tightly map your interface to what's actually
doable. And try to map what's actually doable to what players will want
to do and what will generate large amounts of the mystic quantity known
as "fun".
> Graphical interfaces offer a great way to avoid ambiguity.
Precisely. They also generate simple, immediate "rewards" in the form of
easy to digest feedback. You see the little blue box move from the
ground at your feet to the inventory box that shows "item currently in
your hands". There's a percentage of the human race that will feel that
same sort of satisfaction at "seeing" it move out of the text paragraph
that describes your current location, and "into" the paragraph of text
that comes up whenever you type "inventory". But they're a minority, one
that just happens to have been a majority of the early adopters of
computers. While that minority is important and more intelligent on
average and should be catered to forever (and I'm even a member of it
probably), my job is to cater to the majority that really requires
graphical feedback in order to maximize their fun.
> What gets overlooked in a lot of games I've played is whether a given
> interface is confusing or not. Every time a user has to go use your help,
> no matter how good that help is, his frustration level builds.
The real issues here, and the solutions they suggest, seem to me to be
territory that most user interface designers aren't even aware of yet.
For one - the "help file" concept, which Windows has gone so far as to
define a bunch of fancy tools and standards for, is very static. But the
fact is, learning is an ongoing, dynamic process, and the help a users
wants/needs in their first hour of using your product is very different
from what they need in their second day, which is different from what
they need after three months. But pressing F1 for help in any Windows
app is likely to pop up the exact SAME help menu with the same sub-menus
and documents every time, forever. Context-sensitive help is a small
step in the right direction. But considering learning the game to be an
ongoing process, unfolding along the time axis, lets us immediately think
of alternative solutions. Consider that you, as creator of a game, feel
that most people will want to learn about the "buddy list" feature after
a certain amount of usage. You could monitor every player, see if
they've already found/used it on their own, and if not, say that 5 days
after they first play, or 12 playing-sessions after they first play, or
20 usage-hours after they first play, or the first time they get past the
Palace of Gralfalnibar, you have "Beekin the Help Dragon" pop up and
suggest "Say, now that you've gotten this far in the game, I think you
might want to learn how to be told automatically when your friends are in
the game. Click [Here] to find out or [Here] if you're not interested."
The ultimate solution to the "help" problem, though, comes from the
unique nature of the online medium, and wasn't even available as an
option in the old days of single-user applications running on
non-networked computers. Consider "RTFM syndrome" or "my dad's
navigation method". Why do so many people ask "stupid questions" that we
needed to even invent a half-joking acronym to tell people to try reading
the documentation? You could say it's because much documentation is so
difficult to get the answers from for a novice user that they avoid it
for that reason. You could say it's because much software is so
difficult and loaded with complex features that it's not bad writing that
makes manuals so, it's almost inevitable that they will be unless maybe
you had unusually brilliantly GOOD writing. These may have truth to
them, but they're only the tip of the iceberg. You could say it's because
most people don't come from a culture where "reading big long
instructions things or browsing through them to get to some particular
part that answer my question" is part of the life experience they're
used to, acculturated to from experience with other things besides
computers, accustomed to, conditioned to, trained to expect. There
you're getting a little close to the key underlying truth. Why is it,
though, that most people don't have to read even the simplest
instructions about how to turn on a TV and change channels, how to run
the microwave oven, the washing machine? Why doesn't a farmer's son ever
have to read an instruction manual on how and when to plow the fields,
harvest the crop, feed the chickens and collect the eggs?
It's because people learn how to do all the basic things in life from
other people. That's what people are used to, what they want, and what
they're conditioned to do to seek out knowledge when they perceive that
they're missing something. My partner and I have put out games with not
many commands, and a little summary of the key ones permanently displayed
in the lower left-hand corner of the main game screen. It's ALWAYS
there, and it says how to move, talk, whisper, and pick up items.
Doesn't matter. You'll still see newcomers ask how to do those things,
and older players tell them how. (Or whine about the newbies, but we try
to do social engineering to minimize that!) In the first few seconds, a
typical person's eyes will register static text and think subconciously
"more work to do", and see scrolling text that is people talking to each
other and think "Aha, people!" And immediately they will want to be
talking to those people. It's the most natural reaction in the world.
My other example is how my dad gets directions to places. We can be in
some city we're travelling to, ask someone for directions to the art
museum, and find out it's three and a half blocks away, and here's five
obvious landmarks on the way there. Doesn't matter. We'll have walked
one block, spotted the first two of the five landmarks, and come to the
street sign with the name of the street to turn left on... I'm thinking
we're well on course with no worries. But if dad sees a fellow human on
the sidewalk - he's asking for directions again. It's an excuse to talk
to people! How could you ever pass up a chance to talk to people? My
dad can't, because it's the most pleasurable thing he could possibly do.
Compare this with the stress of reading through manuals or helpfiles.
Most of which are static, don't understand natural language queries, and
aren't flexible enough to figure out a response to questions they never
expected or encountered before. Even if it's just "Gee I dunno, but I
think Bernie might know that." That beats the hell out of what happens
with manuals, which is usually that you spend extra time browsing even
every vaguely-related topic to make sure the info you want isn't buried
in there somewhere obscure, before you finally give up in disgust.
The ideal help interface to me is a big button that says "help", and when
you press it a dialog pops up that says "Do you want to A) ask for help
from another user, or B) browse through the game documentation?" When
people (most of them) pick A, in an ideal world there'll be enough
volunteer player-helpers that most or all of the time a little chat
window can pop up instantly, with someone typing "Hi, what can I help you
with?" and you can type right back and you're off and running with the
questions.
There's various enginery of thought about how you encourage players to be
the volunteers for this, and whether or not you can really get enough and
what to do if you don't, but I won't go into all of that here. Back to
work, or something.
*-------------------------------------------**-----------------------------*
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 Caliban Tiresias Darklock
- (fwd) AD: [custom graphical] whitestar Dr. Cat
- (fwd) AD: [custom graphical] whitestar J C Lawrence
- 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