Sign in to follow this  

Confusion caused by physically impossible environments.

This topic is 3309 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

The question is pretty simple, but explaining it won't be so easy, unless you're a 'Dr Who' fan. For the 'Dr Who' fans out there, just think of the TARDIS, specifically the relationship between it's exterior and interior space, and skip the next paragraph. For the rest of you: This question involves environments that are representable within a purely logical context, but may not be spatially consistent, and thus not physically possible. For example: You are standing in a hallway, and there are two doors right next to each other that are open. You look in one door to see a huge room that branches out in all directions, and thus would overlap the door next to it. Logically then, this other door must lead to the same room, but when you look through that door, you see an entirely different very large room. This is, of course, impossible [within our current understanding of possible, but I won't touch on that here]. This creates an environment that isn't spatially consistent, and there are two regions of space that are clearly separate, where the existence of each should prove that the other doesn't exist. It is also a very obvious example. For a less obvious example, picture a tiny house that you walk into in an RPG or such. Perhaps you can count off 3 windows from the inside of the house looking out, and see only two from the outside looking in. This is a comparatively benign sort of inconsistency, and would likely go unnoticed, and thus is likely 'okay'. And thus it comes down to my question. Under what conditions is this sort of spatial inconsistency acceptable, and under what conditions is it not acceptable? There is of course a substantial design advantage to allowing such inconsistencies. There is even more an advantage in allowing such things in the case of procedurally generated environments [which is actually what is prompting this question], in that there can be a relaxation on the constant problem of the procedural algorithm designing itself into a corner. It gives freedom in that you can design for artistic purpose with disregard for physical restrictions in many cases. So, I would like to prompt you all for a discussion about the confusion that can be the result of such inconsistencies, and a mechanism with which to measure the impact of these inconsistencies on the player, preferably in a somewhat precise and systematic way. To get things going, I propose the following: To present the illusion of consistency, no single point in any environment should have visible from it a spatial inconsistency. Small inconsistencies are less noticeable than large ones. Inconsistency with respect to features that the player does not interact with are less noticeable than those that are relevant to the game. As distance between points between which a inconsistency can be deduced increases, the chances of a player noticing this inconsistency decreases. "Busy" environments are less noticeable to be inconsistent that "not busy" environments [in that lots of things, and high action, will take the players attention away from the absurdity of the environment]. Got any opinions? Additional constraints? or discussion about how to manage confusion resulting from physically impossible play environments? The primary goal of this thread is to discuss mechanisms for minimizing the impact on the player due to these inconsistencies, as opposed to a discussion of these sorts of things as intentional play mechanisms.

Share this post


Link to post
Share on other sites
It's typically not an issue. The most common indoor situations can be hidden with small hallways. And in all cases, props and decorations can be used to obscure the view angles that would give away the anomaly.

Implementation of a mini-map will obviously be a problem.

You didn't mention why you're doing this, or why you have to put up with it. Why do you need to overlap things? If you're doing it for positive user-friendly design issues (such as having a smaller outside area - which isn't difficult to wander back and forth through - that links through doorways to huge indoor areas), it's totally understandable. Otherwise, space in virtuality is pretty cheap.

Share this post


Link to post
Share on other sites
The reason I'm doing it is because I am attempting to make a procedurally created play environment that is generated at run time from the game's current state. "From the game's current state" pretty much boils down to this generation tool running during game play, and the play environment is likely only partially created at any given time. In other words, if you don't go down a hallway, then there really is nothing at the end of that hallway [nothing meaning literally nothing, not just a dead end, but really just a clean cut in the map]. This opens up a number of potentially interesting options with respect to procedurally generated environments. The problem it presents though is the possibility of the procedurally generating algorithm making loops, and then being forced to string a number of long, goofy, and wholly uninteresting tunnels together to work its way out of strange situations on large maps. This is a problem because the generation algorithm isn't capable of taking back decisions that are made, because the player is already in the region that would be revoked or be able to go back to a region that has already been committed, and is restricted from making decisions too far in advance because the game state may change.

Thus I am left with a few options. One of which is to rigidly restrict the choices of features that the algorithm can create such that it is impossible to result in these situations. The second choice is to permit the use of features specifically designed to escape these loops [like stair cases, and bridges, and little tunnels to let the design alg work out of the trap it has created]. A third option is to make everything line-like [not a straight line, but somehow monotonic], and thus there will never be a loop because the map only proceeds in certain directions. A fourth option that I am considering is to allow for the algorithm to generate physically impossible terrain, and thus make only choices that are most optimal for game play, and not consider the impact of decisions that result in traps or the impact this decision will have on the availability of future decisions. I'm liking the sound of option 4, and so I am coming here to discuss the design implications, and the effect on the player, of these types of play features. Option 3 gives a lot of freedom, and lets me design for the exclusive purpose of player enjoyment rather than having to consider if things actually make any sense when viewed as a whole. I don't want it to allow such strange environments that the player gets confused and disoriented by such things though.

[Edited by - Drigovas on November 25, 2008 7:14:04 PM]

Share this post


Link to post
Share on other sites
If you are procedurally generating these 'traps' then the algorithm would need to recognize them to be able to obscure them visually within the game. That might be difficult for the algorithm to do. If you have a map in the game, something likely requisite to basic navigation of a procedural world, then no amount of disguise within the space to make it unnoticed will help when you can see it so plainly on the map. The solution there is to style the game and visual world such that spatial impossibilities are acceptable and expected.

Share this post


Link to post
Share on other sites
Just an observation, any of those physically impossible environments become possible and even simple to understand if you add in a concept of (invisible/border-less) portals. That way your doorways are simply portals to huge rooms, etc. and everything is 'physically possible'.

Share this post


Link to post
Share on other sites
Is your system consistent in time? In other words, if I travel back the way I came will I always recognise what I have already passed (until I reach my starting point) or will my past have been replaced by dynamically generated content?

Share this post


Link to post
Share on other sites
Re: Drigovas

In your post you didn't mention partition. If you use partition, the entire generated stage could be bounded by a volume. Everytime the player opens a door, the engine cuts a new room from the volume, until there is little room left, then the engine knows that the last room must be the "boss room" where things end.

I suppose the traditional way of doing this is to let all the stages be underground. Everytime the player takes the stairs down, the level is generated. The level could be any width. This is essentially the same as your "linear" concept.

It helps if the player does not have line of slight into a door. If the player cannot look into the door from the outside, then there is no implication that the next room is positioned immediately behind the door. The player would infer that there could be a cooridor or other rooms that were skipped between the two rooms. This is probably easier to do in 2D. In 3D you could restrict the camera angle (in a third-person game) or use L-shaped corridors with zoning.

In 2D, you could also condition the player to understand stages that are "unwarped".

Another way to do this is to have a set of fixed structures, and only randomize their internal layout. Imagine that the game takes place in a castle. There is the moat, the walls, the gate, the stable, the barrack, and the keep. The locations of these structures are randomized but fixed when the game began for the first time. The structure inside the gatehouse, the stable, the barrack, and the keep are randomized as the player go into them (assuming that the player cannot see inside them before going into them). Suppose the keep has 16 windows. Using a loose partition method, the game may only create 4 chambers inside the keep, using only 10 windows. There could be 6 windows where the player can never reach. In the dungeon of the castle, you could use the linear method everytime the player go down one level.


Share this post


Link to post
Share on other sites
Another common spacial inconsistency that nobody has yet mentioned (I think) is, in games with house interiors that don't share a world space with their exteriors, a large size difference between the two. Not to mention the common RPG standard of 'enormous cellar with tiny house.'

Share this post


Link to post
Share on other sites
Quote:
Original post by PKLoki
Is your system consistent in time? In other words, if I travel back the way I came will I always recognise what I have already passed (until I reach my starting point) or will my past have been replaced by dynamically generated content?
I am intending it to be. The decisions that are made will be permanent. The same will not be able to be said in the opposite direction [with respect to time] though, in that if you are playing through a level and save, and play forward, you may experience one map. Upon reloading, you may experience a different one if your actions result in differences that the generating algorithm is observing.
Quote:
Original post by Wai
In your post you didn't mention partition. If you use partition, the entire generated stage could be bounded by a volume. Everytime the player opens a door, the engine cuts a new room from the volume, until there is little room left, then the engine knows that the last room must be the "boss room" where things end.
I'm sorry, I really don't understand this, or rather how partitioning is a design concern here. Clearly it is a technical hurdle, but one that isn't too terribly complicated to overcome. It is more likely the case that I am misinterpreting what you are trying to say. Could you clarify?

With respect to the 'cutting rooms out of some volume' idea though, that is effectively the mechanism that would preserve spatial consistency. There is a problem with this though, in that if I wanted the level to proceed for X rooms, and my algorithm backs itself into a corner somewhere where it isn't possible to actually create X room within the volume provided [or ignore the volume entirely, and just consider the case where my algorithm runs rooms in a loop, and at the point where the loop would join, turns inward instead of outward]. This is pretty much the core of the issue. In this case, something must be done. I either restrict the choices that the algorithm could have made up to this point, or allow it to make whatever choice it deems appropriate, and allow for contingencies in the event that it circles in on itself. The question then is how the player should experience this event.
Quote:
Original post by Wai
I suppose the traditional way of doing this is to let all the stages be underground. Everytime the player takes the stairs down, the level is generated. The level could be any width. This is essentially the same as your "linear" concept.
Exactly. So long as the environment is generated linearly along some axis, then this issue is solved immediately, and the conversation becomes a rather moot point. The issue of dealing with inconsistencies becomes irrelevant because any time in which an action would have been taken that would result in such state, a different action could be taken along this designated axis [down, in this case] that would solve the problem. If bizarre and impossible spatial configurations cannot be tolerated, this is likely the route I will end up taking.
Quote:
Original post by Wai
It helps if the player does not have line of slight into a door. If the player cannot look into the door from the outside, then there is no implication that the next room is positioned immediately behind the door. The player would infer that there could be a cooridor or other rooms that were skipped between the two rooms. This is probably easier to do in 2D. In 3D you could restrict the camera angle (in a third-person game) or use L-shaped corridors with zoning.
Line-of-sight, or rather continuous playability of levels [no fade-to-black, followed by resurfacing in a new room] in any fashion, is really where this problem comes from. "Line of sight" isn't so much the issue so much as having some situation that results in the player stopping suddenly and saying to themselves "Something's not right here!", which is the effect that I am attempting to avoid. The fixed structure point [not quoted] is actually how many procedural maps are generated, in that they are placing pre-fabricated chunks in a non-predetermined way, and is an option if I can't iron out the details of my current plan.

Since we are bringing up spatial inconsistency examples: Dungeon Siege had this exact issue, and dealt with it by having really huge maps. It created a big problem for strategy guide artists though who were left trying to make world maps that made absolutely no sense.

[Edited by - Drigovas on November 22, 2008 2:04:56 AM]

Share this post


Link to post
Share on other sites
I mentioned partitioning just as a method to eliminate the overlap problem altogether. "Partitioning" is the "cutting rooms out of some volume" method. If you know rough how many rooms should be cut inside the volume, then you set the volume to be large beforehand to be large enough to easily accommodate the run-time need. The method itself does not generate loops or overlaped rooms.

I suppose the linear method is the simplest. The environment could be
o a dungeon (such that no one can ever see the levels from the outside)
o a tower (where the width of each level is bounded by the width of the tower)
o a maze starting from the center (where new room tend to extend radially outward, such as in this fashion of fibonacci squares)

It always help if you could obscure the exterior view of the structure. But it seems what helps the most is to have obscure the transistion from one room to the next. Suppose you could prevent the player from looking directly into the next room through a door, then you can design the two interiors to be dissimilar enough such that the player would imagine that the designs of the rooms did not change abruptly, but the passage was skipped. The game time could also skip forward during the transision to tell the player that the character didn't teleport to the next region, but walked for an hour to reach the next region, the sky changes from bright to dark.

I think the player would only demand so much that the designer suggest them to demand. If none of the physics in the game is realistic, the player wouldn't mind the inconsistencies of overlapping physical volumes of the rooms. You get the problem when everything else is realistic except the physical placement of the rooms. When that happens the player would feel that somehow the room-generation algorithm is lousy and is the weakest link of the game design.

Suppose you cannot, or don't want to, obscure the line of sight into a room, but you still want to mitigate the chance that a player would complain about overlapping rooms, what could you do? Some ideas:

o have angled connective corridors and use more stairs. It is harder for the player to construct a mental map when the environment is not flat. (Breaking the 2D)

o have connective corridors that spin on an axis or have a rotation about an axis. People usually cannot keep track of the angles in their mind. (Breaking orthogonality)

o have rooms with irregular shapes (especially, irregular long shapes , snake shape, octopus shape, or star shapes, have 7 sides instead of 4 sides, or have the room be round and use curves). When the shapes are irregular, people may not even be able to tell which side is North, so that they cannot suspect whether two other irregular shaped rooms that are connected to the current room could collide. To do this, you could use the alignment of the floor tiles to destroy the player's sense of absolute direction (The player could still recognize that the next room is at the end of the hallway, but cannot tell whether that room is facing north or south).

o Destroy the player's sense of dimension: have rooms where the player simply cannot see from one end to the other end, so that the player cannot easily/unintentionally perceive the size of the current room.

o Have physically convoluted but consistent rooms to impress the player, so that the player would assume that the rest of the rooms are also physically consistent.

[Edited by - Wai on November 22, 2008 1:46:17 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Drigovas
The reason I'm doing it is because I am attempting to make a procedurally created play environment that is generated at run time from the game's current state. "From the game's current state" pretty much boils down to this generation tool running during game play, and the play environment is likely only partially created at any given time.


Does that mean the map can change DURING play time? Thats quite cool. Surely if that is the case, inconsistent environments could make sense, in this quantum-physics-gone-mad dimension then these rooms can exist in parallel - that could almost be the basis of the game, that things don't need to obey all the rules of physics.

For those who don't know what Quantum physics is, neither do I, but it basically means that unless someone is there to see something (flatten the wave) the thing only exists in a world of probability, there is a 1% chance that it has wandered off to the other side of the universe. It doesn't make any sense, and I don't claim to fully understand it, but it would nicely explain things like that.

Share this post


Link to post
Share on other sites
Quote:
Original post by thk123
Does that mean the map can change DURING play time? Thats quite cool. Surely if that is the case, inconsistent environments could make sense, in this quantum-physics-gone-mad dimension then these rooms can exist in parallel - that could almost be the basis of the game, that things don't need to obey all the rules of physics.
It won't change, it will just be incomplete. Once the map is discovered, it is fixed and unchanging. I would just be putting off the decision of what is where until it is actually observed. Thus there wouldn't be an expectation of inconsistency unless I actually tell the player 'this map isn't going to make sense'. The hope is to avoid that.

Anyway, back to the primary question that I am still puzzled with, which is a formalization of the process of fooling the player into believing that a spatially inconsistent environment is in fact perfectly normal. The idea is to come up with a number of constraints that are looser than true physical accuracy, that can simulate correctness to players who are not looking for such artifacts. I'm hoping for a discussion of slight-of-hand of sorts. Thus why I am here seeking the advice of people who are more proficient with design than myself.

Share this post


Link to post
Share on other sites
Well, I don't think there's anything inherently wrong with it if you recognize and compensate for side effects.

For example, any player with even the slightest sense of direction is going to wind up feeling disoriented. But, you could address this thematically, handwave the inconstancies away by explaining that the tunnels are "magic", use the 'lost' and 'disoriented' feelings as thematic elements in your game. Instead of allowing them to detract from your atmosphere, build them into it.

Once you've done that, the player will accept and even benefit from the disorientation ... ultimately adding to the immersion.

Share this post


Link to post
Share on other sites
Well, I am still wondering how you will hide anything at all when a player looks at a map. And some of these solutions will need one badly just to get around.

Share this post


Link to post
Share on other sites
Sorry if you said this straight out, but I'm not clear - do you *want* to have inconsistencies, or do you feel like you'll have to live with them? Cause I don't think preventing them in the first place is an impossible task. You just might need to generate one step further (e.g. reserve at least a little space for all the doors off of the hallway you just generated, even if those doors are never opened). If you do open one of the doors, you can generate a full room, though it might end up being a closet because other rooms/halls got generated around it.

Share this post


Link to post
Share on other sites
Want inconsistencies? no.
Quote:
Original post by snak
If you do open one of the doors, you can generate a full room, though it might end up being a closet because other rooms/halls got generated around it.
Which actually precisely encapsulates what I want to avoid. The idea is to not end up with a bunch of closets. If my algorithm says to itself 'boy it sure would be neat if I could put an armory room that is 13x12 feet here, and fill it with all kinds of goodies, but I only have a 10x10 foot block..' I would like it to be able to say 'looks like I can get away with it anyway without the player noticing, so I'll just put a 13X12 foot room here anyway!' instead of 'guess I'll have to put another broom closet'. The idea is to find design-optimal configurations, and discover a looser set of constraints than total physical correctness around which I can place design-optimal configurations. There will be plenty of design-optimal configurations that I place without violating physical correctness, but in the cases where physical constraints would force me to make decisions that are not design optimal, I would like to know to what extent I can sort of fudge the rules, and get away with it. [Getting away with it being the main goal]. To look for instances in which the constraints that are imposed by physical correctness can be replaced by a looser set of restrictions that would allow me to generate interesting stuff that would not have other wise been generated, while still not totally killing the feel that the world is something that is reasonably real.

The goal that originally prompted the starting of this thread was to discover these looser constraints, and to formalize them in such a way that I can implement my algorithms with them, rather than with strict consideration of 'correct' environments.

To answer the 'map' question, I am not entirely sure about how this would work. Not every game needs a map, and some maps may be limited in the distance they let you see [which would then impose an additional constraint that an inconsistency cannot occur within X distance from an observable point, thus resulting in a map that always looks consistent, with the limited portion of it that you can see at any given time]. This is still very much a nebulous idea in my head, and I haven't started coding at all. I just want to hammer out the details, since it seems like there are some pretty exciting prospects here that I would like to explore if I can figure out how everything should piece together.

Sorry that this whole thread so far has pretty much turned into me repeatedly clarifying my question. Maybe I am just not explaining it correctly. My brain must be stuck in the technical forums....

Share this post


Link to post
Share on other sites
What about, to avoid them, making sure that doors are X distance away from each other... Would that not be the easiest solution. As for the map, just have a halo style motion sensor which only shows enemies.

Share this post


Link to post
Share on other sites
Re: Drigovas

Suppose you don't want polygon shaped rooms or rooms with angled entrances. You want the rooms to be smallish 13x12 feet and rectangular. You want sleight-of-hand tricks:

o Place the doors of the rooms such that there is no position in the room where the player could see both doors at once.

Ex:
Suppose you are in room A and you are creating a new room B that will be inconsistent, position the A-to-B door such that a player standing at A-to-B door cannot see any physically inconsistent sections of room B, and there is no position in room B where the player can see the A-to-B door and the inconsistent section at the same time.

You could do this using walls inside the room, bookcases, shelves. Use a different shade/color or dimmer of light before a door to suggest that the doors are far from one another and to draw the attention away from the door itself.


Another idea:

o just make all the rooms darker and make the items brighter, so that whenever a player goes into a room, the attention is on the items.

o Have doors that automatically close themselves

Share this post


Link to post
Share on other sites
(I think I've gone off on a tangent from your original idea but...)

Haven't we all come accross some story where the hero in some maze eventually discovers that the maze continually changes configuration? Who needs spatial consistancy if the gameplay is strong? If I found myself in a world that changes its spatial configuration with changes in my line of site (let alone just being generally inconsistant) then I will likely come to the conclusion that I'm in a dream world of some kind or on some sort of etheral plane of existance. I say, reality is highly overrated. Make the player feel as though he's falling deeper and deeper into the rabbit hole and is less and less likely to ever find his way out again.

One thought about maps. If you want to provide a way for a player to return to a "room" and you're good with the whole dream world explanation, allow the player (or do it for him) to make a mental note of a room (like the armory you mentioned) and if the player wishes to return to that room maybe it could be selected as a destination which is either reached immediatly or in the X number of steps that the player traveled away from the room. When you reach the destination, the room may or may not have the same configuration and contents as when the player was in it the first time.

Share this post


Link to post
Share on other sites
I don't understand why you can't just push it forward. If you're generating this stuff as the game is being played, then the parts you're generating are straight ahead of the player's path. If you need a 13x12 area, then isn't it as easy as pushing it forward enough to fit? Or in other words, there should be nothing "in front" of what you're currently generating. Only "behind".

I haven't entirely been following along, so ignore anything that's already been addressed.

Share this post


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

Share this post


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

Share this post


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

Share this post


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

Share this post


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





Initially, you proposed the constraints:

1) no single point in any environment should have visible from it a spatial inconsistency
2) Small inconsistencies are less noticeable than large ones.
3) (Attention) Inconsistency with respect to features that the player does not interact with are less noticeable than those that are relevant to the game.
4) As distance between points between which an inconsistency can be deduced increases, the chances of a player noticing this inconsistency decreases.
5) (Noise/decoration) "Busy" environments suppresses inconsistency detection

Compared to your original list, I had these suggestion:

6) Non-static environment suppresses inconsistency detection
7) Non-planar environment suppresses inconsistency detection
8) Non-orthogonal environment suppresses inconsistency detection
9) Good first impression of spatial consistency suppresses 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.

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.

A simplified version of (1) and (4):

10) Thick walls and deepset passages suppresses inconsistency detection.

Share this post


Link to post
Share on other sites

This topic is 3309 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