There are four fundamental components to any area: the backdrop, occlusion map, solidity map, and lightmap. We will illustrate each of these with an actual, in-game example of a small, modest home.

• It must be a PNG or JPEG.
• It lives in the IMAGE namespace.
• Its X and Y dimensions must both be evenly divisible by 64. (Simply pad out the area with black around the edges to attain this result. The engine automatically optimizes certain all-black regions to save memory.) The example images on this page have been reduced in size 25% for layout purposes, the originals were 768x704.
• If the area has any doors or door-like objects (switches, etc.) these should be rendered in the "open" position on the backdrop.
• If the area has any area animations, these should not be rendered into the backdrop. (Don't have the fire in the fireplace lit yet, etc.)
  

The backdrop for this area, reduced to 75% its true size for Web layout purposes

Occlusion map: Occlusion maps provide information to the game about the location of objects which should occlude sprites. When a sprite is occluded, it means that an object in the gameworld is seen to be "in front" of the player, partially obscuring the sprite behind it. Occlusion maps must be two-color, black on white PNGs (BMP will also work.) The occlusion map is not used directly by the engine, but rather used by a special tool called "bmp2polylist"* which generates a series of polygon coordinate data from the maps. Occlusion maps are generally obtained by executing a special render of the area in 3D software which produces a simple silhouette of the objects, with no lighting, shadow, or texture effects.

One of two wall occlusion maps

The other wall occlusion map.

The object occlusion map. Data from these three maps will be merged into a single XML file.

One special category of occlusion map is the overhead occlusion. Standard occlusions are used for walls and objects--things which only obscure a sprite when the sprite should be "behind" them, from the player's point of view. Overhead occlusion is needed for objects and obstructions which will always be perceived as between the player and any sprites on the backdrop, and so should always provide occlusion--not just when a sprite's foot circle is behind the object, but whenever any part of the sprite is behind the object. Typically this is used for objects which are taller than standard humanoid height--door archways, treetops, etc. Overhead occlusion is a separate entry in the area data, and should not be combined with the regular occlusion maps.

The overhead occlusion map. The overhead beams should always block any sprite from view, as they are always closer to the viewer than the sprite.

Doors (a topic for another time) also have their own occlusion data, so that a closed door obscures sprites standing behind it.

To summarize occlusion maps:

• They must be PNGs or BMPs.
• The images are never used directly by the engine, so they should not be placed in the game's module filespace.
• They must be two-color silhouettes, white on black.
• They must match the dimensions of the backdrop.
• They must not contain any shapes which resemble greater-than or less-than symbols. All such shapes should be broken up into separate maps.
• The overhead occlusion map, if any, should be kept separate from the regular occlusion data.

Solidity map: This map provides information about surface type and solidity--in short, it governs where sprites can walk, how far they can see, and what their footsteps sound like. It is a special, color-coded PNG.

Unlike occlusions and sprite positioning, solidity is computed in 12x16 pixel "solidity blocks", although the solidity map itself is delivered at the same size as the backdrop. But it means that single-pixel changes to the solidity map are unlikely to affect the solidity of an area.

There are two types of solidity recognized by the engine. The first is "solid and opaque." Color-coded in black, solid-and-opaque objects are those which completely block both movement and vision (and, not coincidentally, missile attacks). Typically interior walls and doors are solid and opaque. Exterior buildings will usually have a "framework" of solid-and-opaque black lines as well, so that you cannot shoot through a building.

The second type of solidity is "solid, but not opaque." Color-coded in gray, solid-but-not-opaque objects block movement, but not vision (and you can shoot over them.) Furniture, countertops, and tables are examples of solid-but-not-opaque objects. An open trapdoor in the floor might also be solid but not opaque.

The solidity map. Note that red indicates a wood surface.

Any other color-coded region is walkable. There are seven color-coded regions. Each has a unique footstep sound associated with it, and those footstep sounds can be overridden at the area level--meaning a "wood floor" interior can sound different from a "wood floor" exterior.

To summarize solidity maps:

• They must be PNGs, or index-colored BMPs.
• They live in DATA namespace.
• They should be delivered with solid colors only--no antialiasing, fringing, blurring, etc.
• They are used to generate an in-game solidity map which uses 12x16 pixel blocks of precision.
• Area solidity maps do not contain door solidity information--like the backdrop, an area's solidity map should be provided as though all doors are open. We will explain door solidity in a later article.

Lightmaps: Although strictly speaking not a requirement of a new area, lightmaps deliver a tremendous deal of flavor and authenticity to the in-game appearance. The lightmap is used to skew the coloration of a sprite based on the lighting information provided for the solidity block the sprite stands in. With a lightmap, characters can fade into obscurity as they walk into a dark corner, or become reddish as they walk near a giant glowing magic ruby.

The lightmap is actually just an extension of the solidity map concept, and data from the two are stored together. You do not specify an area's lightmap directly in its area definition file. If you specify foo.png to be the area's solidity map, the engine automatically looks for lightmap-foo.png and will use it as a lightmap if provided.

One method of creating lightmaps follows. First you need to delete everything in your scene that won’t cast a large enough shadow to cover a character, which is usually everything other than walls.  Set all remaining objects except for the floor to cast shadows but not show up in the render.  Set the floor's surface to a matte grey color, and render with your lights turned on.  Take this render, and "screen" it over a color that represents the ambient light in the area. Adjust colors and brightness to taste, and add a little Gaussian blur to soften any harsh edges. 

This area's lightmap.

To summarize lightmaps:

• They must be PNGs.
• They must be the same size as the backdrop and solidity map.
• They live in DATA namespace.
• If the area's solidity map is filename.png, its lightmap must be named lightmap-filename.png.

The resulting area from our examples would be defined as follows:

<<<<<<<< area/peasant_house_5
<xml>
<Name value=~Somebody's House~/> // Areas should always have a "name in English", which is displayed in saved game information and journal entries.
<backdrop value="peasanthouse5-base"/> // The name of the backdrop image. Note that the file extension is not needed.
<Solid_Opaque   value="peasanthouse5-solidity"/> // The name of the backdrop's solidity map. Note that we do not specify the name of the lightmap--it is assumed.
<occlusions     value="peasanthouse5-occlusion"/> // The name of the resulting occlusion map, which we generated by combining the bmp2polylist results of the walls1, walls2, and objects occlusion images
<occlusions_overhead     value="peasanthouse5-overhead"/> // The name of the overhead occlusion map used for the overhead beams
<x        value="768"/> // The width of the backdrop, must be divisible by 64
<y        value="704"/> // The height of the backdrop, must be divisible by 64
</xml>

(Thanks to Broken Hourglass environment artist Ezra Schwartz for his assistance with this article.)

* - PWG's bmp2polylist process is based in part on the Triangle utility.