Since the last update I have been making some small content update to the contract system and tweaking the UI. But this isn't what I wanted to discuss today. 

Underneath the hood there has been some significant changes but the main thing I wanted to discuss this time around is I have started toying with a major overhaul of the tile assets. My original plan was to work on mapping out the caravan mechanics for the game but I got sidetracked to work on art. Fortunately, as a sole developer, getting sidetracked is your prerogative. So today I want to discuss the concept I have been developing around overhauling the game to become "2.5D".

Elevation and Tile Art

Right now most of the tile art is consist of mockups that I made rummaging around in Gimp. Going forward I plan to overhaul this. One major draw back of the current art style is that it is difficult to illustrate elevation in the terrain. This leads to vast tracts of the map that looks plain and flatten when in fact the procedural generator in the background created a height map with elevation contours. 

I like to stick with an isometric style so I have spent some time learning about representing height in 2D isometric tiles. An early example I made is illustrated:

As can be seen it's still not perfect. The connecting tile between the lower and higher elevations was drawn by hand and I didn't yet have the transformation mathematically correct as indicated by the gaps between the adjacent tiles. 

The idea is to generate a series of these tiles that can accommodate a variety of orientations. At the run time the engine would read the terrain elevation from the procedural generator and pick the appropriate tile to represent the height of the position and then select the correct "bridge" tile to smoothly connect the low and high points. A variation of this process is already used to define the boundary between terrain types (i.e. the beach tiles have over a dozen orientations to accommodate all the perspectives). 

Turning this into practical reality has turned out to be more challenging than expected. There are broadly speaking three major issues: 

• Tile Generation: developing a script to generate the connecting blocks between elevations at every orientation using a combination of linear transformations of the original image.
• Dynamics and Physics: once this is accomplished, the "3D tiles" are now square (64x64) as opposed to 64x32 despite the fact the art is still illustrated in a 2:1 ratio. Thus all the physics and engine calculations have to be refactored to accommodate this.
• Tile Matching: the tile pattern matching algorithm which I originally wrote to match different tile boundaries on a flat plane now needs to be expanded to handle edge matching at different elevation levels. This also means that new tiles have be created to accommodate for additional permutations.

I will go over each of these points briefly in this post and the solutions I arrived at.

Tile Generation

As a developer I work primarily in two languages, C++ for software development and Python for scripting. Tile generation occurs in the latter, where it is far easier to conduct experimentation. 

The idea is to take a square tile and turn it into tiles that look like these:

You may recall your freshman linear algebra assignment with a similar problem. The basic idea is to take a square tile like this: 

and apply a series of shears, rotations, translations and scaling in order to produce the correct perspective.

The tricky part is to develop a script that automates the process for any base tile and any orientation within the constrains of the isometric perspective. Once this is done it's possible to rapidly convert any existing tiles into this style.

Physics and Mechanics

Once I have created the tiles, they are added to the game atlas as additional tiles. During the procedural terrain generator routine we can now distinguish elevation by the newly created tiles. 

This of course alters the coordinate system of the game as now there is a third dimension, the player and npcs can "move" in the z direction. 

The rendering routine must now appropriately render all the stacked layers in the correct order. Behind the scene a lot of work went into optimizing this component as naively implementing multiple layers of tiles dramatically reduces the FPS.

Additionally, any gameplay mechanics should take this into account. To name a few affected components:

• Line of sight is affected by elevation. One cannot see from low elevation to high elevation. Meanwhile, climbing to high elevation gives an expansive view of the surroundings.
• Roads and paths take into account elevation, snaking through mountains or alternatively around them.
• Elevation is factored into placement of cities, resources and thereby biomes, i.e. settlements may form on lowlands as opposed to highlands. 

Tile Matching

Finally, a major task of the game engine is to place boundary tiles in their appropriate locations. For example, the beach tile on the left matches a water and grass tile but the next two beach tiles match different combinations of adjacent tiles,

all these patterns are encoded into the rendering function for a single plane. Now that there are multiple height planes, things get trickier. I had to make a few design decisions to simplify the process.

1. Fix the number of planar levels ahead of time, i.e. the number of elevation levels is hardcoded into the engine (right now I have 4 height levels).
2. Each elevation level consists of two distinct layers - a base layer and overlay layer. For instance one can have a grassy base layer and populate it with trees sitting on top.
3. Generate and populate the layers one at a time and then connect them at the end (using the sloping tiles generated above).

This isn't idea but sufficient for the time being.

Summary

There won't be a new version of the game with this update as I continue to work out the kinks with this new addition. I expect to deliver this revised version in the following update. After that I should (hopefully) be back to gameplay mechanics.