[MUD-Dev] Games vs. simulations

[Patrick Dughi]

First time posting; I'll just assume y'all can overlook any glaring
ettiquite breaches and my horrid abuse of the english language.

-- Dmitri Zagidulin writes:
> Not to spark a holy war, but can anyone explain to a newcomer why non-room
> systems (read some kind of coordinate systems) are a bad idea?
> They seem like a good holy grail to me...
	
	I can think of one reason.  As a hobbist, I don't have the time to
implement a 3-d system.  That's not to say I can't put it in - that is the
easy part.  The more difficult part would be time and effort costs related
to:

	- modifying existing/additional effort for the 'world'
	- developing understandable & usable interface, in text, for a
relative-position based system in 80x24 screen.
	- implemeting/altering code which enforces this system; land
elevation, correct water flow, weather patterns - or small scale; combat
or any sort of interpersonal interaction, computer-controled actions
(movement, etc), oft-ignored gravity effects (sinking boats, floating
wood, falling people, flying arrows...).

> Does anyone know of any examples of text-based muds with non-room based
> location systems?

	I examined a few in the not-so-distant past.  The majority have
text/ansi-based 'graphics' maps.  The ones that did not were extrememly
difficult to use - though, all these claimed they were still in beta
development.  In most cases, the additional reality aspect was soundly
drowned out by the increase in difficulty for individual actions.  As far
as text-non-map interface goes, a 3-d system makes it easier on a
programmer/world builder to develop a logical system while making it that
much more difficult for the users. 

> Which turns the question around for matt & other avid room-based
> proponents -- how _do_ you handle things like flight, sailing, and, most
> importantly, the question of world scope discussed in that excellent
> article on Gamasutra (don't remember the name).

	Didn't catch the article myself, but in any room-based system I've
been on, the main problem is that of distance.  A desert may be crossed in
3 rooms of arbitrary size.  A town of 20, easily several magnitudes of
size smaller than the desert may span over 100 rooms.  

	This isn't even a problem, unless you actually want your players
to play through the 3 hour real-time walk through a largely
non-interactive desert.  Sure, it's less realistic, but games are usually
for entertainment.  Being bored is usually not entertaining.

	As for other things, like flight/falling, tree climbing, sailing,
party travel formation, spelunking, etc; these things can be quickly
divided into the two categories mentioned above, play-enhancing and
entertaining or useless and boring.  Generally speaking, what would having
a 3-d system for use with flight add to a game where there have been no
additions to the game specifically for flight (such as being outdoors and
being able to fly 3 miles up).  In a room based system, you would generate
a flight-accessable-only room/set of rooms for anything particular you had
in mind.  The two acomplish their goal, the presentation of a
world-builder inspired event to the player, but the 3-d system also
_requires_ that the 'air' includes what would be in a room-based system,
empty unused areas which serve little purpose.  For effort exerted, I'd
guess the payback ratio is bigger for room-based systems.  

	Some things that a 3-d system offer _are_ useful, and play
enhancing (though I cannot summon any to mind at the moment)- but I do not
think that any room-based system is incapable of emulating these benefits. 
I think the trade off is not in functionality, but in programmer time, and
player ease of use. 

> 
> That is, do you agree that having a large, wide-scope world has many
> in-game benefits and is desirable?
> If so, do you think it's really possible to do expansive terrain (lakes,
> fields, wilderness in general, seas, planets) using the myopic room-based
> system?

	I'm unsure of what your 'wide-scope world' includes.  For myself,
I have a poor-man's hybrid.  The main areas of interaction (towns, certain
forest groves, some caves, specific areas on a mountain) all have their
own room-based area.  These do not follow any particular brand of physics
(going east then west will not always land you in the same room - perhaps
in a twisty maze of passages, all alike). However, they all exist on a set
of stacked 2-d maps, which are navigable through an ansi-map interface. 
This allows us a sort of interaction those with experience in nintendo
rpgs, or ultima-clones will find familiar. 

	In actuality, it's just a different way of looking at a room based
system - each tile on my map is, after all, a room.  This allows me to use
the same familiar interfaces, and remove most additional complications.
The only major difference is that the majority of the tiles are generated
by parsing the 'world map' data file, and setting up defaults based on
terrain type.  Of course, being rooms-based, any individual room can
easily be altered to be a unique instance.

	I suppose I could have written a whole new system, instead of
extending the functionality of a simple existing one.  Why bother with the
hassle though?

PjD






_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev