# Indoor Map Exterior Hiding

Home --> Programming Projects --> Block Engine --> Indoor Map Exterior Hiding

# Making Outside Surface of Map Invisible

If we have an indoor map such that players are unable to escape to the outside, there is no need to render the outside surface of the map. That is, we want it so a spectator outside the walls of the map looking in sees something like the above picture. We can accomplish this by coating the outside walls of the map with "invisible" colored textures (see the section on this page about changing an individual side of a block).

Since what we are dealing with is a world of blocks, it is not hard to write an algorithm that given a single side on the outside wall of the map, will find all other outside walls to which that is connected. That is, the invisibility will "spread" like King Midas's Golden Touch. Of course, if there is a hole in the map, then the invisibility will "leak" inside turning everything invisible!

# Adding In vs. Carving Out

The paradigm we have been using is that blocks are added to an otherwise empty world. That is, originally we are storing no information about the world, and as blocks are added, we store more and more. We could, however, go about things the other way around. We could image a world where originally every position is occupied by a block of the same default texture. No information needs to be stored yet. Blocks could then be "carved out" of the world, and the more blocks we carve out, the more information we need to store. We could also add blocks of different textures to the world, and this information would need to be stored. If we choose this approach, then there is no need to make the "outside" of the map invisible becase there is no outside! Using this technique, one could easily make a map where the player can dig and dig forever. How cool is that?

The holy grail would be to have a completely procedural representation of the block world. Here is a neat way to represent a block world: we store the block world in terms of layers. Layer 0 holds three dimensional rectangles of blocks that are added to the world, layer 1 holds rectanges of blocks that are subtracted from the first layer, layer 2 holds rectangles that are added on top of this, etc. When a player adds or digs blocks from the world, this modifies layer 2n (where n is some high enough number). At any point it time, when the program needs to determine what is occupying position (x,y,z) of the world, it goes through the layers from highest to lowest until it finds something. This method would combine the best of both worlds: efficient representation of both above and below ground maps.

Suppose we want to make a game where the player is almost always under ground. We certainly want to use the approach were blocks are carved out of an originally full world. We might want there to be lots of (efficiently stored) caves underground that are originally not connected to the player. That is, the player would have to dig in order to reach these caves. We might not want to bother rendering these unreachable caves. This could be accomplished by keeping track of the part of the world connected to the player, and expand this whenever the player digs into a new cave. That is, when the player digs into a new cave, this causes a long sequence of "AddSquare" or "RemoveSquare" calls to the Quad Algorithm. We might also want to try, at runtime, to partition the cave system into chucks and determine which chunks are visible from which other ones. Obviously, this is a very difficult problem and there is no easy way to do it (even for block worlds).