[MUD-Dev] Clients

[Matt Chatterley]

On Sat, 21 Feb 1998, Greg Munt wrote:
> On Fri, 13 Feb 1998, Stephen Zepp wrote:
> 
> [Pueblo interface]
> 
> > I found the execution of mudding as a player using this interface to be much
> > more realistic...when someone walked into the room they appeared in the Visible
> > window.  When the sun went down, the room description updated itself.  When I
> > left clicked on an object on the ground, by inventory and equipped window popped
> > up, allowing me to manipulate items with point-click until I closed them.  All
> > in all, I felt it was a much stronger interface then any general "one window per
> > mud" client.
> > 
> > Players hated it.  I think that out of about 20 people that saw it, one person
> > actually wanted to use it continuously, and was begging to see the code to
> > support it on his mud ( another ack ).  I just found that your generic "text
> > mudder" is pretty set in their ways, and aren't interested in too much change.
> 
> Am I alone in thinking that player demand should not drive new mud
> development? On this list, I don't think I am. (On Usenet... Hrmm.)

While I would say it is sensible to listen to players (obviously), I
wouldn't say its a good thing to be driven strictly by player demand. The
general opinion in usenet can come accross that way, but I think you'll
find most experienced admin/designers agreeing with you; those who throw
up a mud because its "k001!" tend to be the ones who pander to everything
players want (not always; and sometimes it works if done to the right
extent, of course!)
 
> Generalising, I should say that players are dumb and stupid, and will
> follow you so long as there is a clear path from the past to the present
> to the future. 

Plus, a lot of the things which players would like in a game are not
feasible, or are NOT really things they want. Eg 'Itd be cool if you could
do X..' but it transpires that X makes the game too easy, which makes it
boring, and so on. This is one sequence I *have* seen in action.
 
> Obviously, there is no path to what we must consider as the future of UIs.
> In this and similar situations, you should ignore what the players say
> they want (generalising again, what players say they want is not usually
> what they want - most of the time, they don't know they want it until they
> see it, and even then, some period of acclimitisation is warranted), and
> go ahead and do your thing. I remember the uproar when Infocom started
> using graphics in their interactive fiction. A while later, and no-one was
> interested in a text-only interface. Look at Sierra's "Space Quest" series
> - originally graphics and text, it is now wholly a GUI. 

Yup. I'm going down the 'text with optional pretty looky atty bitties'
route, much like the latter infocom stuff. Players running our customized
client will be able to see graphics, hear sounds and so forth in some
places, while the game should remain entirely playable without these
add-ons.
 
> You can't make decisions based on the current demands of the players -
> but, rather, on their future demands. And their future UI demands are
> definitely graphical. 

Graphical user interfaces are already commonplace and even expected by the
windows users and so forth, while UNIX users do not expect and sometimes
prefer not to have one (although, I wouldn't go back to using Linux
console now I use X11 and xterms - still, I rarely touch the mouse, I live
by keyboard shortcuts). Part of this is also in designing the UI which
presents your game best.

[Snip]

--
Regards,
	-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html