[MUD-Dev] Re: MUD Design doc - Combat
J C Lawrence
claw at under.engr.sgi.com
Wed Jan 13 15:16:04 CET 1999
On Wed, 13 Jan 1999 09:46:37 -0600
Koster, Raph<rkoster at origin.ea.com> wrote:
>> From: J C Lawrence
>> A curious observation along that line is that for many people
>> having to type is actively considered as part of the cost of a
>> command. Thus a "say" command, which typically contains a fair
>> bit of user text, is subjectively considered an expensive command
>> as it requires more typing than, "kill bubba".
> This is absolutely true; else we would not have the proliferation
> of fancy autocompletion systems in mud parsers. Note that the most
> basic abbreviations on a mud are those for "say" and "emote".
Ditto for "u" == "you" and other similar contractions. (Yes, I used
to use those heavily back in my CIX days).
> It would be worth debating whether speech should need a command at
> all; just typing talks, and all other commands require a prefixed
> symbol instead. Graphical muds seem to be following this
> path--EverQuest for example requires a slash / in front of its
> commands, as in /who, /con, etc. It would be interesting to see
> how this would manifest in a text mud, and what environments it
> would be suited for. I considered once adding a "converse" mode to
> Legend, wherein whatever you typed was assumed to just be speech
> until you changed modes back to normal (possibly a "locked tell",
> since tell conversations entail typing "tell bubba" over and
> over--and you can only abbreviate names so far in a populated
> playerbase before you run into conflicts).
Instant thought:
Each SAY/TELL/PAGE/etc command creates a new floating GUI window
which lists (in abbreviated form) the targets of the communication.
Any text entered into the window is then communicated as per, and
returning IO on that channel is displayed inline.
By default one (or more) windows would be locked to the base client
and would map to "say to local room" or other generic types, and
would follow the player about as he moves. This would result in one
pane being for communication with players, another pane for
non-communicative game commands and results, etc.
Very modal of course, which is an old UI no-no. The impact could be
reduced however by having any communication command entered in the
command pane be echoed in the appropriate communication pane (which
is opened/created as necessary).
>> I've often seen comments by players along the line of, "I'm sick
>> of typing (chatting), I'm off to kill something."
> Which is probably why many see real-time voice as the "killer app"
> for online games.
Aye, FireTeam (?).
> The effort is reduced to a bare minimum.
There is a certain pacing and deliberacy which comes with textual
entry which can add value to the communication (and is why I've
silently resisted efforts for translate MUD-Dev to IRC/ICQ/Talker's
etc). It also adds effort.
>> Ease of use is the big hidden cost.
> Isn't it always? :)
Yeah, I just tend to forget about it in the joy of new interface
toys.
--
J C Lawrence Internet: claw at kanga.nu
(Contractor) Internet: coder at kanga.nu
---------(*) Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
More information about the mud-dev-archive
mailing list