[Traer]

I was just wondering why nearly all mud designs that I know about use the following logic:
Area6332 east goes to Area78873
for example
Isn't it easier just to make it so that 0 0 0 is central
and that 0+1 0 0 is east one spot or that
0 0 0-1 is up one from centre of the realm and to build from there?

If you want to see a MUD design that is based on this functionality come visit City of Ages at

coa.servegame.com
p23 or p4000

[KaVir]

Originally Posted by I was just wondering why nearly all mud designs that I know about use the following logic: Area6332 east goes to Area78873 for example Isn't it easier just to make it so that 0 0 0 is central and that 0+1 0 0 is east one spot or that 0 0 0-1 is up one from centre of the realm and to build from there?

Easier, yes, but less flexible.  Most muds utilise the first approach, which then leaves it up to the builder to decide whether or not they want to lay the rooms out in a grid shape (the X/Y/Z you mentioned).  This follows the development route that is commonly accepted as being part of a good, generic codebase design; it doesn't force a particular approach on the mud developer.

However the design itself also allows the builder to create rooms of a more abstract design if they wish - such as large or strangely-shaped rooms (eg, go north, east, south, south, west, and you end up in the same room you started in) or 'impossible' mazes (such as a magic forest where walking in the same direction will result in you ending up back where you started).  This can be particularly useful when designing locations which have very differently sized rooms (such as being able to enter the house on a street, then walk into the different rooms in the house), as using a truly grid-based approach would require a lot of additional rooms - indeed this was one of the major problems I ran into when designing a grid-based mud several years ago, and was part of the reason I scrapped the idea of rooms entirely and moved on to a true coordinate-based system.

Of course for certain gameplay options it may be worth sacrificing the flexibility of the traditional exit-based room design in order to have a coordinate-based grid.  I'm not sure that I'd consider 'ease of implementation' to be such a reason, but you'll often see the grid approach used for wilderness systems, particularly ones in which the terrain can be modified by players or by in-game events.

To use an analogy: It is easier to build vehicles that only move forwards, but there are many benefits to having the ability to reverse, and so most vehicles are designed with that option in mind.  The same is true of muds, which is most likely why most of them have been designed in such a way that they can support either approach.

I hope this goes some way towards answering your question.

[Traer]

I just use teleport portals for that then you can trick their mapping a bit for some howls.

telnet://coa.servegame.com
p23 p4000

[Lanthum]

Originally Posted by (KaVir @ Nov. 14 2005,14:07) This can be particularly useful when designing locations which have very differently sized rooms (such as being able to enter the house on a street, then walk into the different rooms in the house), as using a truly grid-based approach would require a lot of additional rooms - indeed this was one of the major problems I ran into when designing a grid-based mud several years ago, and was part of the reason I scrapped the idea of rooms entirely and moved on to a true coordinate-based system.

A few questions KaVir:

Unless I am misreading this, isn't a grid-based system the same as a coordinate-based system? Basically, where each "square" (in the grid) or point in space (coordinate) in the system is a location that objects can be "at" or "in"?

If you use a coordinate system for the WHOLE world, how do you handle spaces where objects "can't" be ... like walls and empty spaces? Do you use a sparce array and check if anything "exists" there before something can be there?

Do you use one "grid" or array for the whole world? Or do you use different ones to create different zones? I was thinking this might make it easier to control loading and memory. If you use one array (or whatever), how did you decide what would be the center of the grid? Did you create a map first to do that?

Thanks for the ideas. I've been trying to answer these (and a few other questions) myself as I design my own movement/location system for my game.

[KaVir]

Originally Posted by Unless I am misreading this, isn't a grid-based system the same as a coordinate-based system? Basically, where each "square" (in the grid) or point in space (coordinate) in the system is a location that objects can be "at" or "in"?

Well I guess the terminology I used is a bit ambigious, but I by 'grid-based' I was referring to a style of room-based mud in which each specific X/Y/Z position is represented by a room. From what I understood of Traer's post, that is the style of world he's gone for; room-based like most muds, but with the rooms laid out at specific X/Y/Z positions like a traditional wilderness system.

Originally Posted by If you use a coordinate system for the WHOLE world, how do you handle spaces where objects "can't" be ... like walls and empty spaces?

If your rooms are laid out on X/Y/Z coordinate points, you can just assign certain rooms to be solid matter, or give them walls. This can be quite an advantage for certain styles of mud, as it removes much of the limitation of traditional exits. For example in a stock Diku, if you want to walk 'north' in a forest where no north exit exists, it's not possible because there's no way to know what should be there. But with this approach you always know what's there, and could easily give players the commands to hack their way through thick foliage, fly over the edge of a cliff, or even smash their way through the wall of a building.

Originally Posted by Do you use one "grid" or array for the whole world? Or do you use different ones to create different zones? I was thinking this might make it easier to control loading and memory. If you use one array (or whatever), how did you decide what would be the center of the grid? Did you create a map first to do that?

My old room-based approach used a 512x512 2D array of pointers to 10x10 grids, each stored in two bumped double-linked lists (one for the Z plane, the other representing the total list of grids), and consisted of slightly over a billion rooms. Grids were initialised based on a second 2D array of default templates (which fit together like a jigsaw to create a map), with altered grids saved to disk (so if you chopped down a chunk of forest, or build a house, it would be persistant). There was no real 'centre', I just picked a good point and assigned it as the starting location.

However, as I pointed out previously, it didn't work out that well in practice. Movement became a pain, as you'd have to type 'north' 4 or 5 times just to get past one building, and with players adding their own houses daily it become increasingly frustrating to navigate through the starting city. Combine that with the combat/movement limitations of room boundries, and it ended up with an almost claustrophobic feel. This was a big part of my motivation for scrapping rooms entirely, and moving to a true coordinate-based system.