Sign in to follow this  

Confusion caused by physically impossible environments.

This topic is 3303 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:

image hosted by ImageVenue.com
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.

Share this post


Link to post
Share on other sites
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'.

Share this post


Link to post
Share on other sites
Re: Drigovas

It is strange but it seems that you only read the newest post in the thread. What do you think about Kest's method of allowing inconsistency based on the connective distance?

Paraphrasing Kest:

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


Also, is it relevant to clarify some context of the game environment? For example, is the game first-person or third person? Are the "rooms" actual rooms (with walls) or are we actually talking about nodes (no actual walls) as in Dungeon Siege?


I think Dungeon Siege did well using (9). At the time, it was the first (or among the first) 3D game to feature truly 3D terrain, where the player character could walk under a bridge (as opposed to a 2D terrain with height values). There were many environments (canyons, and caverns) showing interlacing bridges and walkways with no spatial inconsistency. Also, there were game maps while the player is in a dungeon (although the player cannot see the map of the entire dungeon at once), there was never inconsistency within the range that is shown by the map. I think this helped to convince the player that every location was consistent.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I could have said it wrong, but when I read this: "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," my interpretation was this:


Suppose room A is connected to room X, which is also connected to room B, then:

A - x - B

(This diagram does not imply that the rooms line up horizontally)

The minimum number of rooms between A and B is 1 (i.e. n=1). If A and B are overlapping, then the chance that the player would detect the overlap is high (since n is small.) This is the case where "rooms that are adjacent to a single room overlap each other." For the case where "rooms thare are adjacent to adjacent rooms overlap each other":

A - x - y - B, n=2

You said that this is safer, which I agree. So as n increases, the chance that the player would detect the inconsistency decreases. On your digram, the two overlap occured with n=4 and n=4.

I think it is fine if that wasn't what you meant.

Share this post


Link to post
Share on other sites

13) Let m be the minimum travel distance between overlapping rooms A and B, and x be the measure of overlap in the direction of overlap. When m/x is greater than a threshold number t, the player will not detect spatial inconsistency.

Reason: the uncertainty in measuring the distance is proportional to m, when the uncertainty is greater than x, the player cannot tell whether the rooms are overlapping.

On Kest's diagram, the m/x was 2.6/0.3 = 8.7 for the overlap in the middle, and 5.5/0.9 = 6.1 for the overlap on the left. This math was saying that the overlap on the left would be easier for the player to detect than the one in the middle.

Share this post


Link to post
Share on other sites
When I read this I instantly thought of the original 'Adventure' text game, especially that damn maze.

You walk north from Room A to Room B.
You then walk south from Room B ... to Room C!

This was done in such a way though that it became part of the challenge, especially creating accurate maps. It was definately confusing and disorientating at times, but if the gameplay is interesting the average player should be forgiving enough, if they notice at all.

Share this post


Link to post
Share on other sites
Quote:
Original post by Kest
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.
If you construct a polygon A consisting of all the visible space that can be seen from one feature, and a polygon B consisting of all the visible space that can be seen from another feature, then these polygons would not intersect. This sort of thing is enormously expensive to compute accurately, but is actually pretty cheap to compute a conservative approximation. If you consider individual features of rooms instead of whole rooms, this requirement boils down to item 1) of the original post, where a questioned feature is the entirety of a given inconsistency. But perhaps that isn't strict enough, and a larger containing feature need to be considered instead of individual features [ie, a room contains a region that is inconsistent, such as receded shelving, so it isn't enough to say that the shelves can't be visible from another room, but that the containing room shouldn't be visible]. Room-Adjacency isn't quite strong enough unless there is a bound on room size so it can't be the case that a bunch of paper-thin rooms are stacked together to fudge the numbers, so there would be some metric besides room adjacency, but it seems that this is leading in a good direction.
Quote:
Original post by Wai
Re: Drigovas

It is strange but it seems that you only read the newest post in the thread. What do you think about Kest's method of allowing inconsistency based on the connective distance?
Such is not my intention, I assure you. I read every post before I comment, but I am really quite busy, and my posts take quite a while to construct. Kest's post was posted while I was making mine, so I missed it.
Quote:
Original post by Wai
Also, is it relevant to clarify some context of the game environment? For example, is the game first-person or third person? Are the "rooms" actual rooms (with walls) or are we actually talking about nodes (no actual walls) as in Dungeon Siege?
Dungeon siege had walls, and lots of them. They were just part of nodes, and had the characteristic that they faded if something interesting was behind them. They used distance to occlude visibility rather than things in the way.

Share this post


Link to post
Share on other sites
I'm still not convinced that the inconsistencies are necessary, especially if you bring your game world into 3 dimensions and keep the generated maps at a reasonable complexity.

For example, you have a looping hallway (let's say a simple square), and the eastern section of the hallway has a doorway going to the center of the loop. The player then reaches the northern section of the looping hallway and you want to generate another doorway leading into the center of the loop. Instead of generating it at the same level as the first generated room and having them overlap, have a staircase either up or down take you to the new room.

This enables every loop in the map to contain at least 3 rooms after being completely generated. If you use a halfway-decent hallway generation algorithm, with a reasonable minimum distance before a hallway is terminated or redirected, you should end up with few difficulties when generating maps.

This kind of method would eliminate inconsistencies by constructing the maze the way it would be constructed in the physical world. If you can't place a room somewhere, don't. There's no reason a mason couldn't build a perfectly valid maze as he walked through it.

It seems to me that you want to have your algorithm generate an almost completely random environment. In this case, the layout of the maze would turn out unrealistic, regardless of physical impossibilities.

Share this post


Link to post
Share on other sites
The problem with counting rooms in between spacial anomalies is that size and arrangement matters too much. It's possible (albeit unlikely) to look down a 3D hallway and see into fifty rooms at one time.

I was thinking more along the lines of doorway view trajectories. Well, at least if this is 3D. While looking from the perspective of one doorway through another doorway, vision can be converted into two simple 3D vectors that lie on the floor plane. Then for each adjacent doorway to that one, you shrink the vectors to fit, until it eventually collapses, marking the end of possible vision through that door.

I do something similar in my project. It's an extremely quick way to cull objects based on the player's room location, and works with any rectangular viewports (when a viewport isn't rectangular, you can just fit a rectangle around it).

Share this post


Link to post
Share on other sites

This topic is 3303 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this