Which might've made a world of difference before you called it a single empty loop, or timing it meaningless. It's not as trivial as you assume.

But let's not dwell, and hear Scandum out for a second…

@Scandum: You talk about a general purpose description engine, but you're light on details. What would it take in your opinion to create a minimal viable description engine? :)

I did not called it a simple loop, I said if coded properly it should compare to a simple loop benchmark wise. I just assume you code it properly in the first place. Move on.
Oh and comparing it to a loop is a worse case scenario. You can multithread the thing easily of course as a light or sound event happening in the 'south' will not collide with one in the 'north', so there would not be to use a lock all the time. Hence easy multhreading scenario here.

As quixadhal pointed out, you can have an infinite* world just as easily with either a room-based or roomless model. The difference is that a roomless world is a seamless whole, rather than many interconnected containers. This difference will have a significant impact on many other aspects of the mud design.

* Or if you want to be pedantic, a world that's just really, really big.

Oh not even, with a world generated from a single seed, all you have to keep is the original seed so if someone wants to go 'back' you can still recreate everything from it.
You can actually provide an infinite virtual world. Maybe slow to compute in some cases, but you can :)

The first step would be to have something to describe, so this means adding actual content, which means you need some kind of physics engine. Objects need shapes and sizes, these can be fairly generic due to the medium. Colors can be determined based on the material / skin, and lighting conditions.

The engine needs to be able to prioritize, a stone may not need be described unless someone specifically looks at the ground. Multiple stones eventually become a pile of stones, so the engine needs to handle grouping.

Skills need to be taken into account, what is a metal sword to a carpenter might be seen as a silver sword to a blacksmith, who in turn wouldn't be able to tell oak from pine. The actual room needs to be described and surrounding rooms need to be described as well. Line of sight becomes important here, a short person may see something different than a tall person.

Dynamic description handling I've seen so far is very basic. They're basically pre-written descriptions with some code to fill in the blanks. So the MUD will have to generate the description layout and fill in the blanks. This will create a markup language that builders in theory could use as well though this is undesirable as the content is pseudo-dynamic. There probably needs to be some way for builders to influence the description layout so they can empathize and de-empathize content.

The most likely way this is going to be accomplished is by using a bare bone implementation where the focus is on game physics and dynamic description handling. The main selling point would be that builders don't need to provide descriptions, the availability of game physics, and a much greater degree of malleability of the game world.

There was a guy claiming to have written such a MUD, called PhysMUD, but apparently the work was lost in a hard disk crash, while others believe it was an imaginary project.

If one insists on a mud universe model that only contains black holes and jump points, I would imagine it's terribly difficult.
If your rooms are nodes/singularities with no shape or size, and the objects and characters also have no shape or size,
and occupy the same infinitely small space as the room node, the physics to dynamically generate descriptions
doesn't work in black holes.

I think the idea of handling volume properly would scare most programmers. I've argued in favor of a furniture model, where objects are positioned in relationship to other objects, it would solve some but not all problems.

Another issue is the up and down exits, ideally all up and down movement would include climbing, but how to properly handle going up a hill? Then again, nobody ever complained about alternatives to stairs when playing Donkey Kong, that I know of.

When going up a hill, you aren't going directly UP. You're also going in a direction that is increasing your altitude. It's pretty easy to manage such things if you have a valid coordinate system, since you can check the slope of the line you're walking when you go "north", and see if it's uphill, downhill, or flat.

If the slope is more than 70 degrees or so, you can probably call it a cliff and require special gear or skills to navigate it. Adjust the number by terrain type and climate, since it's easier to manage a hillside of soft turf, vs. hard rocks or ice. By the same token, you could make the exits be "up" or "down" with a very steep slope, although that doesn't convey the sense that you're still moving in a direction as well.

That only applies to outdoor areas, but indoor areas have descriptions that (hopefully!) inform the player about the way they'll be moving up or down.

The fact that I am reading this here and not in my theoretical physics newsgroup means we have somehow, supra-novaly gone off topic at some point slightly before the cosmic microwave background began to appear.

Pfft, this topic variance didn't even fracture the space time continuum. I call this a good day on MudBytes.

I guess with a room system you could make the slope part of the exit data, though this would create some problems when trying to map this behavior. A 100% slope would translate to going up 4 rooms, with appropriate behavior for slopes of 25% 50% and 75%.

You don't need to do anything with "exit data". You have the coordinates of the room you're in. You can get the coordinates of the room(s) around you. Do the math.

So, if you're moving on the east/west (x coordinate) axis, you want the vertical plane for X/Z. If you're moving on the north/south axis (y coordinate), you want the vertical plane for Y/Z.

What you're really doing is taking the first derivative of the 3D line equation, but effectively you can look at the slope of the 2D plane whose movement you care about.

So, you're standing at (10,5,1) and the east exit goes to a room at (17,5,3), the slope is (10-17)/(1-3), or 3.5.

But I want the angle! Google reminds me that's the arctangent(rise/run). So, atan(2/7) = 15.95 degrees.

Now, let's say the room to the west is at coordinate (5, 5, -3). atan(-5/4) = -51.34 degrees.

Thus, your room description generator could indicate that the road goes gently up to the east, and falls sharply to the west. Repeat the same procedure for north/south on the Y/Z plane. If you want to have the NE/SE/NW/SW directions, you may need to do a little more math to reconcile the results.

Now, a 52 degree slope is pretty steep. Depending on the terrain, climate, and conditions, you might consider it to require special skills or tools to be passable. A dynamic description system would take the observer's abilities into account and alter the description accordingly. So, perhaps with an icy winter storm, it would be "the road falls away sharply and dangerously to the west". Perhaps the "west" command might also check and prevent the player from going that way (or warn them).

It is, of course, up to YOU to make sure your room coordinates make sense. If all your rooms are the same size, it should be fairly easy. If you're stuck in the mentality that wilderness never goes "up" or "down" except on cliff faces, then that's a different problem and all this stuff will be worthless to you.

Some MUDs may not want to mess with coordinates. Are there other uses for coordinates, besides graphical mappers?

Yes. Line of sight, distance calculations and dynamic descriptions may all be good reasons for using coordinates.

It's slightly problematic if you are in a desert and the next room is a forest 10 spaces away. What is the content of the 10 spaces that have been omitted, desert or forest? I guess you could always cut it in halve, but obviously you wouldn't be able to see a desert through 5 spaces of forest. So perhaps the sector with the best line of sight wins to keep things plausible.

It'd be somewhat immersion breaking however if you see a field with a scarecrow a quarter mile to the east, and you're standing right next to the scarecrow when you type 'e'. To deal with this you'd have to handle virtual space, which further increases the complexity, though not too badly if you simply traverse along an exit in a virtual manner.

It's called designing your game world so it makes sense.

If a scarecrow is 1/4 mile away, and you expect walking 1/4 mile to feel like a fair distance, you can't put it one room away. That's another part of the reason I prefer wilderness grids that are generated from a data source… nobody wants to hand-edit 2,000 "grassland" rooms, but most people want the sense that they're actually moving through (and exploring) a vast world.

If you're trying to compress space by using descriptions to trick the user into thinking they're covering vast distances with a few steps, you probably don't WANT generated descriptions in the first place.

You could have free floating rooms and have the player walk around in a virtual limbo while traveling between rooms. Probably much like how spaceships travel between planets in space games. This would remove the need for exits though they could be assigned by builders to indicate what locations are of priority in a dynamic description, and be of some use when it comes to handling doors. This would subsequently allow the creation of hidden rooms. The trickiest part would be determining the sector while in between rooms.

If you're that hell-bent on NOT having rooms… why not just, not have rooms?

It's rather absurd to try to create an environment which mimics a coordinate based system within a room based system, when you're only using it to SIMULATE having more rooms than you actually have.

I dislike the concept of grids as I view it as a computational nightmare. They're useful for creating maps, but I view that as an evolutionary dead end. A grid system could be used, but I'd envision a precision of blocks of 15x15 feet, while terrain maps would contain 15x15 blocks. So if a tile would be 15x15 blocks that would equal 50625 square feet total. Tiles in turn would contain a collection of rooms.

You're just playing word games here.

A "tile" of 15x15 "blocks", is just another way of saying a "room" with an interior "grid" of coordinates. I see zero value in such a thing.

If you're clinging to the idea of rooms, then the room is your basic unit of encapsulation. The whole idea of rooms is based on the concept that local events should pertain to the contents of a room. That's why combat, communication, inventory… all were designed to work on the contents of the room and the npcs/objects within it. At some point, people got it into their heads that they wanted to make things work across multiple (adjacent) rooms, even though that invalidaes the whole concept of a room.

Once you want things to work on things based on their distance away from you, you are in the coordinate world, and you'd be far better off accepting that and designing your systems to work on coordinate distances, rather than pretending rooms do anything useful for you.

From the user's standpoint, you can easily simulate a room interface by "hanging" descriptions onto ranges of coordinates, and displaying "exits" as descriptions of being able to move in a particular direction. If you only perform a "look" when a player moves into a new "description", you get pretty much the same thing as a set of "rooms", at least from the player's perspective. Observant players might notice that some rooms take more than one "north" to cross, but you could lie and say you have sub-positions in larger rooms and they'd be none the wiser.

As for it being a computational nightmare. I can't see how a simple coordinate -> room mapping is more of a "nightmare" than a coordinate -> tile block -> room nested mapping. Unless, maybe, you're running on a C64 and only have 8-bit integers?