17 Aug, 2013, Deimos wrote in the 1st comment:
Votes: 0
Has anyone ever explored a movement/positional system that wouldn't qualify as either room- or coordinate-based? If so, what was it and how did it work?
17 Aug, 2013, Idealiad wrote in the 2nd comment:
Votes: 0
You might be interested in this,

http://www.second-contract.com/2013/02/s...

He has other posts on the same blog so look around.
17 Aug, 2013, Scandum wrote in the 3rd comment:
Votes: 0
It's possible to have a system where each object's position is relative to other objects. Distance would be relative as well, something could be nearby or far away. The main advantage is that it would be easy to describe dynamically as unlike with a full coordinate system you don't have to reduce the environment to describable chunks using complex formulas as the system is innately in that state.

You probably would want to add some coordinates to such a system as to allow someone to get lost in a forest, in this case you would compile a spatial system into a positional system. For directional long distances traffic there would be a small deviation for a certain distance, so someone could end up walking in a circle unless they made sure to make corrections from time to time by paying attention to the position of the sun and the time. Of course the concept of time would have to be fuzzy as well. If time and space become precisely defined you would still have a coordinate based system. Such a system would force people to use roads for long distance travel, though a highly skilled person could track through the wilderness.
17 Aug, 2013, Deimos wrote in the 4th comment:
Votes: 0
Idealiad said:
You might be interested in this,

http://www.second-contract.com/2013/02/s...

He has other posts on the same blog so look around.

This was a very interesting read, but I think what's being described is more about relationships between objects than movement or positioning (as I understand it, anyway). It could be implemented in either a room- or coordinate-based game, rather than being mutually exclusive to them.

Scandum said:
It's possible to have a system where each object's position is relative to other objects. Distance would be relative as well, something could be nearby or far away. The main advantage is that it would be easy to describe dynamically as unlike with a full coordinate system you don't have to reduce the environment to describable chunks using complex formulas as the system is innately in that state.

You probably would want to add some coordinates to such a system as to allow someone to get lost in a forest, in this case you would compile a spatial system into a positional system. For directional long distances traffic there would be a small deviation for a certain distance, so someone could end up walking in a circle unless they made sure to make corrections from time to time by paying attention to the position of the sun and the time. Of course the concept of time would have to be fuzzy as well. If time and space become precisely defined you would still have a coordinate based system. Such a system would force people to use roads for long distance travel, though a highly skilled person could track through the wilderness.

To me, this sounds like the textbook definition of a coordinate-based system, but I could be misunderstanding.
17 Aug, 2013, Idealiad wrote in the 5th comment:
Votes: 0
I think there really are only two position systems, coordinates and relations (room-based is really a type of relational system). The problem with relations not using rooms is that for any kind of complex positioning you need some kind of coordinate system backing it up.

Of course you don't need a position system in a mud (though you'd need a very good reason not to have one). But I'm guessing you want some kind of positioning in the first place?
17 Aug, 2013, donky wrote in the 6th comment:
Votes: 0
I'm with Idealiad, there's no alternative. Either you're lumped into arbitrary nodes in a network of localities (rooms) or you're positioned (coordinates).
17 Aug, 2013, Scandum wrote in the 7th comment:
Votes: 0
Deimos said:
To me, this sounds like the textbook definition of a coordinate-based system, but I could be misunderstanding.

It would be a hybrid system. If you have relational and coordinate as the two obvious choices the hybrid system would be a third.

It's possibly to place a relational map into a virtual coordinate grid as well, it's what the tt++ automapper does, so then you have a relational system that emulates a coordinate system.

It's possible to extend the room (node) system where you can not only be inside nodes, but can also give nodes 6 walls and be able to attach yourself to the inside or outside of those. This would allow the ability to crawl your way to a world created in such a manner. I guess you could call it a cube system as there would be six children inward, and 6 children outward. For spatial reasons you could allow a 7th inward child which would be the center of the cube.

This behavior is somewhat similar to that of octrees which has 8 inward children and I guess such an implementation would be fundamentally different from coordinate and room systems.

Another hybrid form would be a structure that divides the cube into a 3x3 grid, for a total of 11 inward children if you include up and down. Outward children could be left at 6.

For clarification, outward children behave like exits and have node-like behavior. Inward children have a spatial behavior similar to that of an octree. And the third form would combine elements of both.

So we got relational/room/node/exit based, coordinate based, and spatial/octree based.
18 Aug, 2013, quixadhal wrote in the 8th comment:
Votes: 0
If you think about it, your only real options are a spatial system, or a containment system.

A spatial system has some area in which things are placed. Their location is given as a reference from either a global origin, or in relation to another object. The particular coordinate system you use is irrelevant.

I could use the traditional X,Y,Z system, or I could adopt polar coordinates. I could say "the orc is at 12, 300, -2." or I could say "the orc is 12 meters, at 37-degrees north, away from the oak tree, which is 30 meters, at 40 degrees west, of your location."

In all cases, things occupy a position. Multiple things might be at a single position. A thing might occupy a range of positions.

The other option is a containment system. In this case, coordinates might not exist, and indeed space might not exist. All things are inside other things. You are in "room 12". There is an orc in "room 83". Room 12 is inside area 3, and room 83 is inside area 5. Area 3 and 5 are inside realm 1. There is some connected graph which describes how to get from room 12 to room 83 that might include an arbitrary number of other nodes.

This is the traditional "room" system. The labels of "north", "east", etc are just that… labels. Unless you impose organization onto them, there's no inherent ordering or spatial relationship between them.

The two kinds of systems are not incompatible, but they are distinct.

If you want an alternative, you'll need to think one up and then make sure it isn't a specific case of one or both of those. I can't think of anything off the top of my head.
18 Aug, 2013, Deimos wrote in the 9th comment:
Votes: 0
quixadhal said:
If you want an alternative, you'll need to think one up and then make sure it isn't a specific case of one or both of those. I can't think of anything off the top of my head.

I don't want an alternative; I was just curious if anyone had come across one. Nothing came to mind for me either, but it struck me as odd that these would be the only two options.
18 Aug, 2013, Idealiad wrote in the 10th comment:
Votes: 0
Coordinates, and relations in particular, are very general ideas. I suppose not many position systems place an explicit focus on time?

> Focus
You float in the aetheric firmament. You sense a Tentacled Dweomerd in the netheric depths five minutes away.

> Focus planes
You sense the netheric depths twenty seconds away, the clarific mists five seconds away, and the verdant encomium thirty seconds away.

> Shift netheric
Dark thoughts fill your mind…
Shifting in 20 seconds…

You sense the netheric depths take shape around you.
18 Aug, 2013, Scandum wrote in the 11th comment:
Votes: 0
That reminds me of something Idealiad. There's the concept of plane shifting as described in the Chronicles of Amber. You'd probably have to read the first book to get a good grasp of the concept, but it would classify as a distinct alternative to proposed systems.

In the system you imagine a particular reality, and by an act of will you can shift between realities until you arrive at the desired reality. If you'd picture two moons for example you'd shift to a reality with two moons, and subsequently you can also shift between planes with different technological capabilities and different physical laws. In the book one such a notable difference is a plane where there are no explosives.
18 Aug, 2013, donky wrote in the 12th comment:
Votes: 0
Scandum said:
That reminds me of something Idealiad. There's the concept of plane shifting as described in the Chronicles of Amber. You'd probably have to read the first book to get a good grasp of the concept, but it would classify as a distinct alternative to proposed systems.

In the system you imagine a particular reality, and by an act of will you can shift between realities until you arrive at the desired reality. If you'd picture two moons for example you'd shift to a reality with two moons, and subsequently you can also shift between planes with different technological capabilities and different physical laws. In the book one such a notable difference is a plane where there are no explosives.
On the MUD-Dev mailing list, the administrator talks about an area he created for a MUD. It was called the blue path or something similar. Basically anywhere there was mention of blue, you could do the command blue. This would take you to the blue path. There you had three movement options, forward, backward and blue. blue would then take you out of the path, but no guarantee where. At the end of the path was a castle, where you had to take the queen through a maze that changed shape each time you moved, while she lost focus and drifted off and other players tried to poach her to complete the same quest themselves, ..

There's an implementation of plane shifting, which was stated as actually having been implemented.
18 Aug, 2013, Scandum wrote in the 13th comment:
Votes: 0
quixadhal said:
This is the traditional "room" system. The labels of "north", "east", etc are just that… labels. Unless you impose organization onto them, there's no inherent ordering or spatial relationship between them.

The two kinds of systems are not incompatible, but they are distinct.

Many MUDs do not allow rooms to contain other rooms, so I would argue that the ability to nest is a distinct system. This because you can use an octree and use nesting exclusively, where as you can not allow nesting of rooms (Diku) and exclusively use a node based model.


donky said:
There's an implementation of plane shifting, which was stated as actually having been implemented.


Diablo does this to some extend as it can add thematical elements to its dungeon creation. One thing to consider for plane shifting is to make the path between planes unique to each player, which can be achieved by seeding a random number generator with a value unique to the player. This would add an element of exploration, and a particularly pragmatic developer would allow players to use 'shift <number>' and the player would have to shift to planes, explore them, and remember the ones that are useful for trade, gaining experience, treasure, etc.
19 Aug, 2013, quixadhal wrote in the 14th comment:
Votes: 0
A DikuMUD does allow nesting, because there is no concept of a room being inside, outside, or adjacent to any other room, OTHER than having an exit linking them.

I could very easily create a room, and create an exit called "rabbithole". I could then create another room that describes being inside the previous room with an exit called "outside". Once these two are linked, the player would perceive going "into" a smaller space that's inside the main room, or leaving it to emerge back into the main room.

To the game, you simply moved from room vnum #3000 to room vnum #3001.

The only thing special about exit directions is that the basic 6 (n,s,e,w,u,d) are hard-coded to always have slots in the room code for them, and there is code to auto-find the reverse versions of each.

So no, I don't think nesting is anything special. It's just a graph relationship. If you impose nesting as a thing that's distinct from the edges of the graph (IE: exits), then you've created a coordinate system.
19 Aug, 2013, Scandum wrote in the 15th comment:
Votes: 0
The typical software wouldn't be able to distinguish between an exit that leads inside and an exit that leads outside. It's a distinctly different relationship and a properly designed game would exhibit different behavior for nested locations.
19 Aug, 2013, KaVir wrote in the 16th comment:
Votes: 0
Gladiator Pits had a system that I'd probably describe as 'state based'. Although the locations were referred to as rooms (and one might argue it was just an extremely simple room system), there was no real concept of space or location, instead it worked like the Diku connection state (where you can be at the login screen, reading the MOTD, in the game, in OLC, etc).
19 Aug, 2013, Scandum wrote in the 17th comment:
Votes: 0
KaVir said:
Gladiator Pits had a system that I'd probably describe as 'state based'. Although the locations were referred to as rooms (and one might argue it was just an extremely simple room system), there was no real concept of space or location, instead it worked like the Diku connection state (where you can be at the login screen, reading the MOTD, in the game, in OLC, etc).

I guess that would classify as a form of plane shifting?
19 Aug, 2013, quixadhal wrote in the 18th comment:
Votes: 0
You guys are trying to make distinctions in things that are all just directed graphs.

You can call them "rooms", "planes", or "states"… they're still just nodes on a graph which has edges controlling which nodes you can freely travel between.

Also, Scandum, I have no idea what you mean by "The typical software wouldn't be able to distinguish between an exit that leads inside and an exit that leads outside." The software doesn't have to do anything. It's entirely a human perception issue. If the room description makes it sound like you're inside somewhere and using the exit sounds like you're going outside the place you were… then that's what the player perceives. The game engine doesn't care, because it's just a pair of nodes with an edge connecting them.

The alternative to a directed graph is a coordinate plane (or sphere, or however many dimensions you want). There, instead of a graph of nodes, you have positions in each dimension, which you can change.
19 Aug, 2013, Scandum wrote in the 19th comment:
Votes: 0
If I destroy a room that contains another room, both rooms would get destroyed if the system recognizes that room as a child. If the system views the room as a distinct room and only the player perceives it as contained because the exit says 'under the bed' it would leave that room in existence.

If you have a world with little or no physics it's no big deal, but there will be situations where it'll matter whether a room is nested or linked.

The movement system I described in the plane shifting thread is distinctly different from traditional movement systems between nodes, and as such it qualifies as being an alternative movement system. So while a plane is a node the distinction is in the method of transportation between nodes.
19 Aug, 2013, KaVir wrote in the 20th comment:
Votes: 0
quixadhal said:
You guys are trying to make distinctions in things that are all just directed graphs.

You can call them "rooms", "planes", or "states"… they're still just nodes on a graph which has edges controlling which nodes you can freely travel between.

Really? You consider the "Connected state" in Diku to be a room-based system? CON_READ_MOTD -> CON_PLAYING = room-based movement?

Scandum said:
If I destroy a room that contains another room, both rooms would get destroyed if the system recognizes that room as a child.

Unless you choose to move it out before destroying the parent, which can often make sense. I had a few bugs with players 'vanishing' after being eaten by a creature that then died, or being inside a building while it burnt down.
0.0/34