|
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.
|