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).