28 Jan, 2013, Scandum wrote in the 21st comment:
Sure, landmarks are an easy way to get around the issue. The point though, was to develop a description generator which would take an arbitrary (unknown) set of map data and generate correct and useful descriptions from it WITHOUT needing to have builders hand-place things.

Landmarks could be generated. When I talk about landmarks I mean more epic features, like a volcano, a tower, the ocean, a waterfall (sound), etc. The tower itself could be an area, and while it would be possible to parse the tower and determine it's a tower, it would be easier to describe the area. If an island is automatically generated it should be fairly easy to generate a landmark as well.

Ssolvarain said:
I think this thread is a good example of why they made 'graphical muds'.

Most graphical games aren't dynamic. WoW is almost entirely comprised of static images and as far as I know it contains none of the dynamic game elements I mentioned. So this is an area where MUDs can surpass graphical games.
28 Jan, 2013, Telgar wrote in the 22nd comment:
arendjr said:
Personally, I'm gonna try to generate dynamic descriptions using spatial relations. I'm using a room-based system, but for this to work a MUD needs to have a few prerequisites:
1) Rooms need to have a 3D coordinate
2) Items need to have a 3D coordinate relative to the room they're in
3) Characters have a direction vector indicating in what direction they are looking

Well, you don't really need a 3D coordinate. You can infer relative position of other rooms based on the exits of the current room, so even with non-commutative geometry, you still have a sane spatial "view" within the room. To have the descriptions work, you really need to be based on your current perspective.

I thought about doing this, but the generalization fails in two ways. First, the notion of "up", defined as relative to where you are standing, is gravity based. Up is always the direction against gravity, and down is the direction towards it. This doesn't work for either zero gravity environments, or rotating environments used to simulate artificial gravity. In those situations, "up" may be "above you", and travelling "up" might rotate your lateral axis 90 degrees, in which case, movement forward and back would then not have any effect on your planar orientation, but movement right and left would. You've effectively gimbal locked one your planar direction components.

When I thought about how to solve this, I realized I didn't want to have to implement quaternions just to represent spatial orientation, I would prefer to cheat a bit and probably not make "up" rotate your lateral axis in a zero-gravity environment. This isn't quite realistic, as from a first person perspective, one would always expect a view in zero-gravity travel to look towards the direction of motion, but I think it makes game mechanics a wee bit simpler.

A fully implemented 3-D, zero gravity maze with actual orientation vectors and correct first-person perspective rendering would be pretty sweet though.
28 Jan, 2013, Ssolvarain wrote in the 23rd comment:
Scandum said:
Most graphical games aren't dynamic. WoW is almost entirely comprised of static images and as far as I know it contains none of the dynamic game elements I mentioned. So this is an area where MUDs can surpass graphical games.

This is very true, but navigating a 3d environment in a mud pisses just about everyone off. A basic thing like movement becomes a serious hindrance.
29 Jan, 2013, Idealiad wrote in the 24th comment:
I've never played a truly 3D mud, but I've never played WoW either. How 3D is WoW?
29 Jan, 2013, Runter wrote in the 25th comment:
I've never played a truly 3D mud, but I've never played WoW either. How 3D is WoW?

It has 3 dimensions if that's what you mean… you can look in all directions, you can fly around on a mount. Areas can be winding tunnels through mountainsides.

So as long as you don't mean 3d as in 3d glasses, it's as 3d as they come.
29 Jan, 2013, quixadhal wrote in the 26th comment:
Interestingly, WoW is now more 3D than it was at launch. :)

While the game has always supported movement in all directions, the original world map wasn't designed with flight in mind, and as such, there were many places where the terrain wasn't quite right. Either you could fall through it, or it wasn't a seamless transition from one type to another.

When they released their Cataclysm expansion, one of the major features was a total revamp of the original maps to be fully 3D, like the newer content. They also took the opportunity to advance the storyline to explain why parts of the world suddenly changed.
29 Jan, 2013, quixadhal wrote in the 27th comment:
Telgar said:
I thought about doing this, but the generalization fails in two ways. First, the notion of "up", defined as relative to where you are standing, is gravity based. Up is always the direction against gravity, and down is the direction towards it. This doesn't work for either zero gravity environments, or rotating environments used to simulate artificial gravity. In those situations, "up" may be "above you", and travelling "up" might rotate your lateral axis 90 degrees, in which case, movement forward and back would then not have any effect on your planar orientation, but movement right and left would. You've effectively gimbal locked one your planar direction components.

The way some systems handle this is to give you a map which has an origin. Perhaps the sun, perhaps a galactic core. In that case, you have an ecliptic plane which you can use to handle "up" and "down". So, navigation becomes "in" or "out" to mean going towards or away from the origin, "up" or "down" to indicate movement in relation to the ecliptic, and "clockwise" or "counterclockwise" for moving right or left around the origin. I think "right" or "left" would be acceptable for most cases, at least so long as facing doesn't matter.
29 Jan, 2013, Scandum wrote in the 28th comment:
Ssolvarain said:
This is very true, but navigating a 3d environment in a mud pisses just about everyone off. A basic thing like movement becomes a serious hindrance.

It's doable if you add roads and allow a player to traverse along a road until they get to an intersection. Road signs are an option as well, and will make learning to read worth the trouble. The ability to walk towards a landmark helps as well, especially if the MUD is smart enough to walk around basic obstacles. Snappy movement is imo preferable on PK muds as it adds a hunt/chase element. This behavior can be recreated by allowing players to move behind furniture, vanish from sight in a dense forest, and any other possible imaginable way.
30 Jan, 2013, lurker_veteran wrote in the 29th comment:
arendjr said:
Personally, I'm gonna try to generate dynamic descriptions using spatial relations. I'm using a room-based system, but for this to work a MUD needs to have a few prerequisites:
1) Rooms need to have a 3D coordinate
2) Items need to have a 3D coordinate relative to the room they're in
3) Characters have a direction vector indicating in what direction they are looking
4) Character objects remember their last action for at least a few seconds
5) Rooms can have a "type" that provides a little, possibly intelligent description

I believe, Skotos has developed something similar although without 3D part:
proximity system article
30 Jan, 2013, Scandum wrote in the 30th comment:
lurker_veteran said:
I believe, Skotos has developed something similar although without 3D part:
proximity system article

This looks fairly identical to a furniture system I described two years ago:

http://www.mudbytes.net/index.php?a=topi...

This probably is the way to go, though it's just one of several design elements I propose.
30 Jan, 2013, arendjr wrote in the 31st comment:
@Telgar: But if you're using the exits to infer position, you will not know what to do with an exit named "door", "out", "gate", or whatever. You may also lose the ability to have hills (as in, you can walk over the hill with nothing but going "north", but the hill will block line of sight from one side to the other nonetheless). And you will also not know the relative positions of items within a room. You're right that 3D coordinates are not required for some of these features, but the way I use them they're really a requirement.

@lurker_veteran: That looks very interesting indeed! Looks like a nice alternative if you don't want to have coordinates, and it may even be preferred if you want really detailed interiors. On the other hand manually defining "proxes" sounds like a lot of extra work for builders.
31 Jan, 2013, KaVir wrote in the 32nd comment:
Scandum said:
lurker_veteran said:
I believe, Skotos has developed something similar although without 3D part:
proximity system article

This looks fairly identical to a furniture system I described two years ago:

The Skotos article was published in Imaginary Realities nearly 13 years ago, and there were similar discussions on Mud-Dev a few years before that, so I think it's safe to assume the idea has been around for a while.
01 Feb, 2013, Tyche wrote in the 33rd comment:
KaVir said:
…and there were similar discussions on Mud-Dev a few years before that

Hey I'm on that thread and I still agree with me.
I find this discussion interesting. I think I'll write a gargantuan post in a few days. :-)
01 Feb, 2013, arendjr wrote in the 34th comment:
Wow, the discussion on Mud-Dev is a small gold mine :)

Question: I've read a bunch of discussions and write ups now about positional systems, but most only discuss what they want, rarely what they have done. If I understand correctly the proxes system is real, but other than that, how many of such systems have actually been successfully developed for room-based MUDs?

I'm actually quite far advanced now implementing my own 3D coordinate-based positional descriptions, and hope to unveil it on my demo server shortly. I've explicitly left out "proxes" and the possibility of having characters being anywhere else than the center of the room, but the surroundings have already been greatly enhanced by the positional descriptions. Still there's plenty of room for improvements of course.

PS.: @Tyche: Are you Jon Lambert? Either way, please do a write up, I'm definitely interested! :)
01 Feb, 2013, KaVir wrote in the 35th comment:
arendjr said:
Question: I've read a bunch of discussions and write ups now about positional systems, but most only discuss what they want, rarely what they have done. If I understand correctly the proxes system is real, but other than that, how many of such systems have actually been successfully developed for room-based MUDs?

I once implemented something similar, as I briefly described on Mud-Dev, and it worked okay.
04 Feb, 2013, Telgar wrote in the 36th comment:
KaVir said:
arendjr said:
Question: I've read a bunch of discussions and write ups now about positional systems, but most only discuss what they want, rarely what they have done. If I understand correctly the proxes system is real, but other than that, how many of such systems have actually been successfully developed for room-based MUDs?

I once implemented something similar, as I briefly described on Mud-Dev, and it worked okay.

Speaking as to positional systems, there are actually two very important distinctions. First, there are absolute, global coordinates and orientations, and then, there are local orientations. Even in relatively simple settings, the distinction becomes important.

You are on a vehicle. The vehicle turns right. Your local orientation has not changed, but your absolute orientation most definitely has.

If this vehicle has multiple rooms, you also need a new way to describe relative directions.

For this purpose, I would use shipboard directions, fore, aft, port, and starboard.
04 Feb, 2013, KaVir wrote in the 37th comment:
Telgar said:
Speaking as to positional systems, there are actually two very important distinctions. First, there are absolute, global coordinates and orientations, and then, there are local orientations. Even in relatively simple settings, the distinction becomes important.

You are on a vehicle. The vehicle turns right. Your local orientation has not changed, but your absolute orientation most definitely has.

If this vehicle has multiple rooms, you also need a new way to describe relative directions.

For this purpose, I would use shipboard directions, fore, aft, port, and starboard.

So your command set changes when you enter a vehicle? That might be realistic, but it's not very pleasant from a usability perspective, particularly as 's' for south becomes 's' for starboard. My preference would be either:

1) You continue using 'n', 's', 'e' and 'w'; in this case the commands are relative to the head of the vehicle (unless you're at the wheel, in which case you'd perceive the world as if you were the ship). While walking around the ship, any ASCII/graphical map would always show the ship pointing towards the top of the screen.

Or:

2) The directions are named (TinyMUD style) - in a room-based model, you might literally have exits called "prow", "stern", etc. In a coordinate-based mud, you would target and approach different parts of the ship by name.
04 Feb, 2013, quixadhal wrote in the 38th comment:
You could also just implement two set of movement verbs that are always active.

"north, south, east, west" for movement in an absolute direction, and "forward, back, left, right" for movement relative to your facing. Most of the time, you'd likely just assume your facing was northward, so they'd be the same… but in cases of vehicles, mazes, or other situations, the facing might make a difference.

It would be kindof fun to be lost in the woods and have the "north" command tell you "You don't know which way north is, would you like to go forward, back, left or right?" :)
04 Feb, 2013, KaVir wrote in the 39th comment:
It would be kindof fun to be lost in the woods and have the "north" command tell you "You don't know which way north is, would you like to go forward, back, left or right?" :)

It's been suggested before, but I suspect the novelty would very quickly be replaced with frustration.
04 Feb, 2013, Rarva.Riendf wrote in the 40th comment: