Just a bit of musing

[S001GMU at nova.wright.edu]

>:						  As far as distant objects
>:are concerned, you could report "there's a building to the west" only when
>:the user does a scan or some such. No reason the level of detail can't be
>:configurable.

>That requires the user to consciously ask for more detail, whether they
>are getting less because the system gives less, or because they have
>turned down the detail level. That's the big advantage of using a graphical
>display - you display all the detail that you have pixels/horsepower for,
>and if the user misses something, then they have no excuse at all. 

what's wrong with making them consciously ask for more detail?  even in a
visual situation, you have to consciously focus on specific areas in order to
see anything beyond a general shape.  Granted, a graphical client does allow
for large amounts of information to be displayed with less interpretation time
for the user, but again there is still only so much info you can put on a
screen.  I think it's not at all unreasonable for designers to require some
level of interaction with the player to determine what specifically their
character is looking at.

>I think
>there are uses for grids and co-ordinates in a text system, but it seems
>to me that the flexibility of a text system lets you add stuff that is
>more interesting (to me, anyway!), without all the effort needed to make
>it consistent within a system with more rules. I guess this sort of thing
>is a lot like the discussions of combat detail - some folks really like it,
>others just find it to be a bother. Perhaps I'm just not experienced
>enough in playing MUDs to have become jaded with the usual stuff!

I have been playing MUDs for quite some time, and I guess I am jaded a bit, but
I do still like the abstract quality of some muds.  I'm hoping there's a happy
median between pure number crunching, absolutely modeled systems and the free
flowing system of standard MUDs.  I really like the Quadtree ideas that have
floating around for world represntation, and I'm currently brainstorming on how
to combine them with a free flowing system...  :)

>[more snippage]
>:		     While all of this is required for a graphical mud, I
>:see no reason to limit the techniques to graphical muds.
>
>True enough. I guess I should embrace all possibilities. Its just that I
>*want* to have a good graphical system, and my thoughts tend in that
>direction!

I've been leaning towards an open system, where the user interface is not tied
to the game mechanics of the MUD.  This does present several problems to be
overcome, but it allows for a client that is specialized (to some degree) for
the system it is running on.  Why limit it to plain, 2-d Graphics?  :)  If I
forked out the PILES of $$$ for an SGI Onyx Reality engine with VR Galore, I
wanna be able to play some games with it!! :)  Granted, I don't plan on writing
the client for that particular system, but hey, why not build a system that at
least makes it easier to do it for that (obviously rich) bum to do it?  :)

>:							  While endless spam
>:can be confusing, going east a dozen times and ending up west (because your
>:builder put the zone in a stupid place) makes navigation both unusual and
>:difficult.
>
>Well, bad building is bad building. Whatever systems are present in a
>MUD setup, they should be as easy as possible to use for building. As
>usual, nothing can replace good administrators. At least with a
>co-ordinate system, it can be pretty obvious when something is wrong!

*grin*  we don' need no stiiinkin admiin here maan.  :)

seriously though, I agree.  A building system should be as easy to use as
possible, with as few ways of fudging things up as possible.

-Greg