Old vs. New Tile Map Systems

After some thought experiments and pen-and-paper prototypes, I'm ready to commit to the new tile map data design for MHFramework 3. I'm content that I've found a solution that satisfies the goals of functionality, usability, performance, and supportability. Plus it will allow me to maintain the qualities that I didn't want to lose from the previous versions of LIME, and in fact, will improve upon some of them.

Differences From Previous Versions

Other than having a whole new set of layers, there are quite a few differences in the new design, involving the data structures and algorithms both.

Reversed Relationships in the Data Structure

The old system consisted of a matrix of MHMapCell objects. A map cell held an array of actors such that there was zero or one actor for each layer. So, technically, the map wasn't layered, but the map cells were.

Conceptually, the new tile map consists of two coarsely-plotted pairs of layers (a pair for floors and a pair for walls), each with a sparsely populated, semi-transparent overlay layer for adding decorations and other composite effects. The benefits to this change are countless -- performance, memory efficiency, flexibility, more intuitive optimizations, and more.

So the old system was essentially a matrix of arrays while the new system is an array of matrices.

Actors Are Not Tiles

Unlike the previous iterations, actors are not actually stored in the tile grid, but the class will still keep a list of them for rendering, collision detection, and persistence purposes.

Furthermore, although actors are no longer treated as tiles, tiles can still be actors. We can still have floor switches, teleporter pads, flowing water, blinking runway lights, and so on. The difference is that now they're stored in the actor list rather than a tile grid.  To load these things from map data files, I'll be renaming MHObjectFactory to the more specific name MHActorFactory to better reflect its true purpose.

More Sophisticated Rendering Algorithm

The new rendering process will go something like this.

1. Lay down the section of the floor layer that is visible to the camera.
2. If a layer of floor decals is present, apply them in a separate pass.
3. Put all visible actors and wall tiles in a list and sort them on the y values of their base anchor points.
4. Draw every element in the sorted list.  For each wall tile encountered, check for a decal and render it if present.

New Collision Rules and Terrain Height Variations

In the old system, collision detection was straightforward.  If the wall layer in a given map cell was occupied, then it was an obstacle. Though admirably simple and adequate for rectangular tile maps, it's insufficient for representing 2.5D phenomena like projectiles flying over tables or variations in the height of terrains. Therefore, the new collision detection logic for isometric maps needed to be much more sophisticated.

First, the relevant values are either initialized or calculated.

• Actor climb = the maximum difference in terrain height between map cells that an actor can traverse.
• Actor altitude = the actor's height from the ground when falling, jumping, flying, etc.
• Actor elevation = map cell height + actor's altitude.
• Obstacle height = height of image - base tile height.

Then, for all potential obstacles, a collision occurs when:

1. The obstacle is a wall and the actor's short-range look-ahead vector entered its map cell OR
2. The actor's and the obstacle's collision geometries intersect AND
3. The actor's elevation plus its climbing ability is below the obstacle's height.

Table of Tile Map Layer Properties

One of the major goals I had for this redesign was to keep the reusability of the tile grid for essentially all tile map types, be they isometric or rectangular, top-down or side-scrolling, diamond or staggered. To this end, the layer ID constants have synonyms to help keep it simple for developers using the engine.

Layer	Synonym	Collidable	Interlaced
FLOOR	BACKGROUND	No	No
FLOOR_DECALS	BACKGROUND_DECALS	No	No
WALLS	FOREGROUND	Yes	Yes
WALL_DECALS	FOREGROUND_DECALS	No

The History (and Future) of MHFramework's Layered Tile Maps

The original version of the MHFramework tile map system (circa 2004) consisted of the following layers:

• Floors
• Items
• Walls
• Ceilings

The overwhelming task of creating assets for the Beltzhian Marauders world led me to redesign the map structure to cut down on the number of raw assets that need to be created (and also reduce memory consumption in the process).  The evolved version (circa 2008) contained these layers:

• Floors
• Floor Decals
• Items
• Walls
• Wall Decals
• Ceilings

The lessons learned through creating various games and prototypes in the meantime has made me realize that by aggregating things together and using more sophisticated rendering and collision detection algorithms, the default layers for MHF3 might look something like this:

• Floors
• Floor Decals
• Walls
• Wall Decals
• Actors