[MUD-Dev] Re: BUILDERS: Ferries

[Vadim Tkachenko]

This is a multi-part message in MIME format.
--------------4F09A2BF8256748B3D34F94F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Marian Griffith wrote:
> 
> On Tue 09 Dec, Derrick Jones wrote:
> 
> > On Sun, 7 Dec 1997, Marian Griffith wrote:
> > > On Sat 06 Dec, s001gmu at nova.wright.edu wrote:
> > > > On Fri, 5 Dec 1997, Sauron wrote:
> > > > Amen.  :)  I think having a full world map also makes solving the problem
> > > > of long distance travel a little easier.. at least it's easier to keep it
> > > > a realistic solution.
> 
> > > Having a map is not the critical issue. You need to have a lot of back-
> > > ground information of  how areas look,  how they interact  and how they
> > > came to be to be able to create a consistent world.

Agreed absolutely. Also, there's a possibility to create additional
information source in the maps - for example (I assume the kind of maps
you're getting by walking through, and as the more area is covered, the
representation of that area appears on your map, or, you can find it as
an IC element), the very picture of the certain area may help you to
solve the quest.

> > > You also run into a problem of scale.

(see below)

> Finally there is the issue of **relative sizes**.  Inside, rooms reasonably
> match  the actual locations in size  (ignoring for now  the special cases).
> Planes,  at the other extreme,  but this really is true  for just about any
> outdoor region,  have rooms sized in kilometers or more.  Fixed size rooms,
> as have been proposed,  would lead to deserts of tens of thousands of rooms
> across.  All with identical descriptions.  Clearly this would be tedious to
> create and even more tedious to travel.

So what? There are two aspects - RP and implementation.

>From implementation point of view, if you just blindly create the
identical description for thousands of identical rooms, it's going to
make you bankrupt because of ISPs charging for a disk space, and you're
likely to run out of memory, too :-)

So, what I'm going to use is just to have a vertical structure of
areas/subareas/sub-subareas and so on.
Thus, it's enough to create a description for the whole desert and then
you'll see only this description unless there are some details you want
the user to notice about some specific zone (room) in the desert (btw, I
hate the concept of 'room' as such, but after detailed consideration I
see that this is a must for a SIMPLE implementation, and I suspect
that's why the rooms are still out there - or else you're doomed to
track too many changes and drain the CPU power, later about that).

>From the RP point of view, tell me please, isn't it as boring as walking
through the real desert? And, provided the correct navigation/movement
tools/skills/whatever it becomes a valuable addition to the game itself
- yes, it's big, I mean BIG, it's boring, I mean BORING, but! the desert
can reveal unimaginable treasures upon a close examination.

> The problem as I see it is that there simply is no convenient way to create
> the richness of a natural environment in a way that is both simple to build
> and pleasant to play.  A region 2000 rooms across is impossible to write.

Unless you automate and generalize it.

> Clearly that would majorly change the nature of a game set in such a world.
> Travelling across the plain would indeed be a major expedition  and players
> could be expected to prepare carefully for the undertaking.

This is right,

> Also there can
> be no more quick equipment or experience runs in remote areas.

Disagree here (maybe I just don't understand? Can you please rephrase,
because I don't quite understand what is an equipment or experience
run?), because

> Simply since
> getting there itself is taking too much time.

Just to get to the hearth of a desert will require significant amount of
courage, resources and survival skills, so I believe that the desert
traveling (especially if it's a part of a larger picture) should be
rewarded accordingly. Provided the player[s] don't die on their way, of
course :-)

> Marian

--
Still alive and smile stays on,
Vadim Tkachenko <VadimT at 4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are
--------------4F09A2BF8256748B3D34F94F
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vadim Tkachenko
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Vadim Tkachenko
n:              Tkachenko;Vadim
org:            4C Solutions, Inc.
email;internet: vadimt at 4cs.com
title:          Web Developer
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------4F09A2BF8256748B3D34F94F--