[Emit]

well, this is my first post here, so be gentle please.
What i'm trying to do is write a function for a mud i'm coding on that will spit out an ascii map of an area.  I thought i could do it using a two dimensional array as a grid type system, and then looping through all the rooms in an area, placing adjacent rooms next to each other.
problems with this i discovered were:
1) running out of bounds on the array
2) trying to fit in rooms that are above or below the current one
has anyone anything like this before? and if so, may i have some advice?  i'm begining to feel like i'm going about it the wrong way.
-Emit

[visko]

A while ago, a good friend of mine decided that he was going to allow for tracking based on a map created in-game of the entire world. This map would basically assign grid points to every room in the game radiating out from recall, and then calculate where a mob/char was in relation to the char trying to track.

Bounds weren't the problem; non-Cartesian rooms were. What you're going to find is that if you have any place in the game where a room goes back to itself, or goes to one room, then another, and back, the game is going to cycle into an infinite loop. I'm actually interested in getting something like this going because track is a nice feature in a mud, so if anyone has suggestions, I'd love to hear them.

-Visko

[cronel]

What you need to do to avoid loops is to remember the rooms you've visited so far. But yes, "non-cartesian" arrangements of rooms will always screw you as they are unmappable.

A basic approach would be to not only remember that you've visited a room, but remember where in the "grid" you found it. So if you find it again in a different position or find a different room for the same position, you have a problem. And when you are about to visit one such room, you add some mark to your ascii map, or such, and move on.

What I wonder is, what would happen if you stop assuming all exits are the same length. For instance an exit east, could mean the next room is not just one unit to the right, but two, three... Making a mapper that does this, however, seems a daunting task. I'm thinking it might be able to digest some non-cartesian areas but might produce maps you'd never expect.

By the way, some clients have automap, like Zmud and Kmud. Kmud is open source... may be worth a look. Also look at the SMAUG "track" code for a related problem.
--cronel

[mhc]

cronel> "non-cartesian" arrangements of rooms will always
cronel> screw you as they are unmappable.

I'm not sure if I understand what you mean here. 'unmappable' in what respect?

[cronel]

In that they can't be mapped to a 2d grid. I thought this was clear from the context of the thread.

[mhc]

Toplogically speaking, everything can be mapped on 2D, especially if it's on a regular grid in N dimensions.

[Emit]

well, i sorta figured it was doable, mhc but i've been racking my brain for the algorithm.  if i was only dealing with 2 dimensions, and all exits were the same length and two way, i think i could work something out.  it might look like this:
1) assign each room coordinates, based on relative location to recall
2) spit each row out into a file, putting spaces and dashes in the appropriate spots

this wouldn't be too hard.  i could probably work out a variation to handle the third dimension too, by printing each level as a 2d map seperately (ideally i could integrate all the levels, but i think i would get a headache just reading it).  but i could probably never develop an algorithm to map some of the maze areas, where all exits are one way.  i guess i'll just have to sucker some poor sap into doing it manually  
thanks anyway guys

[Eddy]

Originally Posted by Toplogically speaking, everything can be mapped on 2D

Even if this is true than it's not an answer to the question. The question is if it can be mapped in an ascii map. As far as i'm concerned this is only possible if the areas are designed with the maps in mind.

The whole problem lies in the fact that rooms have no size (take no space) as such they can be connected in any possible way.

I can agree to the a statement above if you drop the requirement that a west exit means a line to the left and an east exit a line to the right. In that case you simply draw all rooms in a square or so and draw lines between all rooms that have a connection. (not a very readible map!

If you want connections between rooms to point in
the 'logical' directions this problem can't be solved.

Easiest example of this:
room1 (east-> room2, west-> room2)

I would like to draw you a map to make that more visible but had problems making it  

Eddy

[cronel]

I admit I don't fully understand that, mhc... what is "N" if the map is 2D?

The point of the exercise (for me) is to make a map, not a drawing of the nodes. I.e. This node here has two connections to two other nodes, one labelled "east", the other labeled "closet", and sure, it can easily be drawn. But is it a map?

For example, there's a room with the eight standard exits n,ne,e,etc, and they all point to the same room. Or, room A northeast exit points to room B, and its southwest exit points to C. But B's southwest exit also points to C. The nodes aren't hard to visualize. But the maps?

Basically I agree with Eddy's point; the rooms model space, but very weirdly as we all know. Maps can easily be drawn of Real Space, say the plans to a house, for example. Groups of rooms can easily be drawn as nodes, since that's what they are. But as they deviate from a "realistic" model of some piece of space, it will be harder to draw them as a map. Perhaps even impossible in some cases, or at least I don't see how.

What I said above and now Eddy I think concurs is that you can drop some of the assumptions for a map and make it approach a node drawing a little, but still come up with something with some semblance of a map. For instance,some assumptions are:

* All rooms are the same size and shape
* All exits have the same length and shape
* All exit "directions" (east) translate to
 the same map direction (to the right)

--cronel