Lemme explain, Kest. As I understand the issue. Take a floor of a building with no elevation changes on our floor. I walk to the end of a hall and into a curved hallway. I walk around the hall only to find it circular. I'm in a torus. What if I find a door on the inside of the torus? Logical space restrictions should mean that the room inside can be no larger than the inner wall of the torus shaped hall I'm in. The OP finds procedurally generating rooms and avoiding problems like this difficult and wants solutions that don't require extensive rules to be coded in to prevent spatial inconsistency or restriction.

Quote:Original post by JasRonq
I walk to the end of a hall and into a curved hallway. I walk around the hall only to find it circular. I'm in a torus.

If the area is being generated on the fly, then by the time you walk all the way around the torus, the area should be done generating. Unless the plan is to regenerate areas that have already been visited. Or to generate rooms when the door is opened, rather than when the door is visible. Just avoid doing that.

Until you've mapped out the entire area, and as long as you're placing things "in front" of the player, there should be no spacial limitations. The only concern would be how long it will take to loop back around. To avoid making the loop larger, just place larger rooms on the outside of the loop.

The large loop problem could also be overcome with a transporter gimmick. Any hallway, spinning door, or other area that can't be seen through in a straight line would work. When the player steps into the transporter area, and when they can no longer see adjacent areas, move the transporter area to another location. Enemies, decals, flying bullets, and everything else inside of the transporter area should be transported with it.

What if the player creates a loop around his starting position by walking that path, generating new rooms as he goes. If he goes into that loop and more rooms are generated, they are restricted in size and shape. That is what we are getting at, the need to avoid having to write special rules to identify how much space is available by disguising when an area overlaps previously created rooms.

Its not simply a matter of only creating things in front of the player. If the player makes a loop, the generated content will follow and restrictions will be created.

Quote:Original post by JasRonq
What if the player creates a loop around his starting position by walking that path, generating new rooms as he goes. If he goes into that loop and more rooms are generated, they are restricted in size and shape. That is what we are getting at, the need to avoid having to write special rules to identify how much space is available by disguising when an area overlaps previously created rooms

Exactly.

If you write the level in a line, or in some fashion such that it is always increasing along some axis, then this becomes a non-issue. It also results in restrictions on the environments that can be made, and levels will just be straight paths [even if 'straight' is actually a physically curved structure, but straight along some function]. This results in restrictions with what can be done, and as a result, design choices that must be made that are known not to be optimal, but are made to meet the requirements in place. Clearly there must be some rules that I follow if I want to present a world to the player that appears to make sense, and following a linear path would certainly meet that requirement, but the looser the constraints that I impose, the more flexible I can be with respect to the decisions that can be made. The result is then that looser constraints would imply greater choice with design, which in turn implies greater possible availability of more optimal choices for enhancing player experience [however that is defined, but since the set of possible choices would then be exclusively larger with each constraint removed, there would be at least as good of choices with looser constraints, or fewer of them]. A monotonic design would certainly fulfill the desire for not generating rooms whose sole purpose is to worm out of an existing trap configuration, but it also results in other restrictions. If I am confronted with the reality that a world is either completely physically representable or else, then a monotonic design will most certainly be my answer. Baring that, I am still searching for solutions that leave me with more freedom.

Thus the search is on for the loosest constraints that I can use to define my world, and I'm convinced that these constraints can actually be looser than those placed on physical representability without adversely effecting player believability. It's just a matter of how to formalize the process of fooling the player. [something easy to do on an instance by instance basis for a human developer, but a machine needs strict rules for meeting this clearly abstract goal, which is why I am here in the design forum rather than the tech forums].

Thanks for the clarification by the way JasRonq

Would it not be far less noticeable to bridge two disconnected areas than to put overlapping areas right next to each other?

Once you travel far enough away, it won't be a problem to overlap areas. It would only be an issue if the areas are close together. For example, this wouldn't be an issue:


Without a mini map, no one would notice that these areas overlap. In other words, you only need to make sure no rooms that are adjacent to a single room overlap each other. To be safe, you could also make sure no rooms that are adjacent to adjacent rooms overlap each other. Or you could use some kind of path finding distance check, or line of sight check. There's probably a very simple mathematical rule to use in order to avoid it, which I don't know.

Quote:Original post by Wai

Quote:Since we are bringing up spatial inconsistency examples: Dungeon Siege had this exact issue, and dealt with it by having really huge maps.

Did you mean that the rooms of Dungeon Siege were spatially incorrect, and to hide the incorrectness, the maps were made to be huge? When I played Dungeon Siege, I didn't notice an spatial inconsistency (if it had), and I didn't think that the maps were too large. I didn't feel anything wrong with its maps.

The maps weren't 'too large', but were large enough to obfuscate the tricks they were playing. The guys behind dungeon siege themselves said it best: Source [at the very bottom], in reference to the map architecture... [truly required reading for programmers interested in continuous environments]

Quote:In addition, the node-relative nature of the world meant that those distances and orientations may not make sense anyway because the world doesn’t necessary follow traditional Euclidian notions of space! The world can, and often does, intersect itself, and end up bent like a pretzel. Two regions can completely overlap, where one is faded out and the other is visible. The designers took full advantage of this in the multiplayer map, creating an “endless desert”, which is literally endless in one of the directions because it is stitched back on itself like a loop. In more practical terms, this ability gave the designers a lot of flexibility in layout out their worlds, because they didn’t have to worry about making distances match up, or even make sense. The player would never notice, but it does make building overview maps (say for a strategy guide) a little difficult.

And you didn't notice! Which is precisely the effect I am after in my project. Those worlds were created by human hands though, and I would like to develop a systematic way of tricking the player in this fashion.

Quote:Original post by Wai
6) Non-static environment subpresses inconsistency detection
7) Non-planar environment subpresses inconsistency detection
8) Non-orthogonal environment subpresses inconsistency detection
9) Good first impression of spatial consistency subpresses inconsistency detection

What do you think of the constraints so far yourself? I assume that the set of constraints are incorporated in the room generation algorithm, such that in the event that an inconsistent room is to be generated, it would not violate at least some of the suggestions listed.

Or at the very least it would have some sort of quantification of the risk that it is running, and could compensate by making choices that would weight the heuristic in the opposite direction. For example, if red rooms were discovered to have the trait that players don't notice inconsistencies if the room were red as opposed to blue, then if I am going to place a room that is going to be *really* inconsistent [boarder-line failure], I'm at least going to make sure it's a red room. 6-8 are really good ideas. Bends and twists will make it more difficult to maintain a coherent sense of direction, and thus make inconsistencies with respect to features witnessed some time ago less obvious. Especially angles and patterns that are not repetitive, or not 'common' angles or features [like a 70* turn instead of the much more familiar 90* turn at a hallway], which falls nicely under 7). Throwing the sense of direction and space would likely be very important to pulling this off properly. Ideally, 9 will be implied by everything else, in perception of consistent environments would be maintained throughout. A correctly constructed algorithm would hopefully present a world that the player won't even question, but it may come into play a bit if there are a series of little inconsistencies in a row, or some other weird stuff.

Quote:Original post by Wai
How do you know whether you would rather deal with these constraints than the constraint of generating only spatially consistent rooms? I am questioning (4), (1), and (2) in particular. Those seem to be the most difficult to apply. The other "guidelines" are easier to follow in comparison. To apply (3), (5-9), the algorithm itself doesn't even need to consider whether the rooms could be inconsistent.

Well, if I can assert that this looser set of constraints is sufficient, then I would utterly abandon the intention of maintaining consistency. Thus it wouldn't be "Make everything consistent until it can't be done, then make choices based on these constraints", instead would be just throwing out physical representability all together, and considering these constraints as the only rules to live by.

1) Would just be stating that there should be no point at which a player can stand and blatantly observe a problem. Thus this is really the absolute bare minimum for correctness. An example of such a thing would be a player standing in a room, looking through a door way at a mirror in the room on the other side, that shows a reflection of a feature in the other room that should then also be present in the first room [like a second door in the second room, where there is only one door in the first room]. Checking for such a thing is actually not terribly hard if done in a conservative fashion, and would assert that there is at the very least no position that the player can sit there and stare at something that is clearly wrong.

2) was just saying that little problems are less noticable than big ones. If a room of size 10x10 is the largest that can fit in a certain area, a room of size 10.5x10.5 is less noticably 'wrong' than a room 1000x1000. In the same sense, receded shelving that would pierce into the room on the other side, loops in the map that actually don't line up by 5 feet off-center, or other minor changes, are not so noticable. Consider this the 'fudge factor', or the measure of how much the rules can be broken in the immediate sense.

4) is attempting to say that the longer the player is forced to retain precise knowledge of previously seen state to detect an inconsistency, the less precise that knowledge becomes, and thus the larger inconsistency I can make look consistent.

It is entirely possible that 4 is really meaningless if I don't include your proposed 6/7/8, and that those three are really required to make 4 really 'work'.

Quote:Original post by Wai
Paraphrasing Kest:

11) Let n be the minimal number of rooms between Room A and B that overlaps, increasing n suppresses inconsistency detection

That's uh, not at all what I meant. I meant that there's probably a simple mathematical detection/avoidance scheme, when placing the doors to rooms, to prevent the rooms from being visibly overlapped.

I was thinking it might be to just prevent the doors from sharing the same line of sight. But I'm not so sure. That would definitely do it, but there may be a less dramatic solution.