On Monday, October 13, 1997 2:28 PM, Daniel Koepke
[SMTP:dkoepke@CALIFORNIA.COM] wrote:
> On Mon, 13 Oct 1997, Gary Barnett wrote:
>
> -+1) Create a 3d array of ints to represent a zone. Each room will plug
> into
> -+the array
> -+ in whatever spot it is in relation to the other rooms. (sparse array)
>
> There is, of course, some problems. It requies everything to be
> physically possible. That is, you can't make west take you from
> roomA to roomB, and east to take from roomB to roomC. The rooms,
> and zones, cannot overlap.
Hmm. Why exactly does it prevent this? Remember that the room exit
system is still being retained. This routine is only required to give a best
effort location for resolution of distance and other locational computations.
It's easier to prevent this with rooms
> (unless you have a reason for doing it, then you should avoid it).
> The main problem lies in mapping where zones are in relation to
> each other. Remember when Rome was north of Midgaard? It was about
> 7 or 8 steps from the north exit of Midgaard (Behind the Altar?),
> but the western forest was a few steps west, and going north you'd
> never connect with Rome. The same problem exists with other zones.
> Where they would *logically* connect, they do not, because no-one
> ever bothered to check. As it is, the zones are free-floating
> masses of rooms that can "magically" connect with one another. If
> you stapled them down to the ground in a limited space, several
> would likely overlap...:\
>
This is exactly why I have my system setup in the way it is. One big
cube to handle the world. Scale is one zone per grid location. Inside of
the zone grid is the room grid. Inside of that is the terrain map of the
room.
Solves some of the problems. You can still have your overlap in rooms, as
they are abstracted at the zone level, yet you still get your positional
information. The use of a sparse array keeps memory usage tolerable,
but does add a few lines of code.
> The only way I can see to remedy this situation is to have the
> program (or you can do it manually) find where two zones intersect
> by in an illogical way by building the array and reporting the
> two intersecting zones. This is why, though, I am moving away from
> free-floating, unlimited zones and placing them in a three-dimensional
> cube. It has its own limitations, but it's very neat for tracking,
> flying, etc. (e.g., you don't have to *fake* flying or make it just
> a hovering thing).
>
I am having my builders use an OLC to enter this data. That way they
can create their map as they want things to appear, making the corrections
to fit it into the system in the most appropriate fashion.
Agreed as to the flying. I am going to give people a top down view of the
zone's with sight distance (and screen limitations) that way they can choose
to land in a room that is capable of accepting them. Fuel usage becomes
a worry when you are flying to an airport you haven't been to before. :-)
Flight and water travel don't really require much in the way of a room desc.
Most builders wouldn't be willing to write 100 different sea descs, so just
have the game generate descs in a virtual 'room' while they travel. If the
boat gets sunk do some processing and move them to the closest room
or not.. depending on the outcome.
--Mallory
I can picture in my mind a world without war, a world without hate.
And I can picture us attacking that world, because they'd never
expect it. - Jack Handey
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST