Tile map/terrain implementation with differing heights of neighbouring tiles

Question

Ahoy!

I'm looking for some information about tile maps, or rather, what a specific type of tile map is called.

I'm interested in the kind of implementation used in rollercoaster tycoon, or the transport tycoon series of games and have been looking into vector field terrain and height map terrain but i'm not sure they're suitable for what i'm looking to develop.

It's been a struggle to find any decent info as most people refer to it as an isometric tile map, but I'm looking to create something in 3D with a fixed orthographic perspective. I understand that the underlying storage of the tile map has nothing to do with how it is rendered but i'm not looking to create a 2D tile map like old school pokemon/zelda games, more along the lines of diablo with the capability to include overhanging cliffs and sloping terrain.

I'm just trying to find the right terms to search google and stackoverflow for resources to help me decide which path to proceed.

So far i've managed to flesh out a basic tile map without using the height/y component stored in a VBO and rendered as a wireframe. This looks fine so far but I envisage that I will encounter problems when trying to manipulate a single vertex to create cliffs and slopes without affecting a neighbouring tile.

Is there a specific type of implementation I should be looking into? I thought i'd cracked it when I found a fair amount if info on vector field terrain but i'm not sure this would yield the correct results either.

If anyone can shed some light on this for me please, the help would be greatly appreciated :)

Update

I've included an image for further clarification as to what i'd like to achieve:

Image borrowed from How to create tilted (height) isometric tiles

This image shows the type of terrain i'd like to generate but doesn't include the "cliffs" or overhanging terrain types i'm interested in modelling. It does however raise a few other questions I hadn't considered, namely;

• How would 'layers' such as the water (top left of the image) be handled to include the visible ground underneath the water?
• How would the "edges" of the map be catered for so that the earth/mud is rendered to depict the world as a non-flat entity?
• Could the underlying storage for this kind of terrain be used to model physics such as a ball rolling down a hill or movement speeds of a player traversing a slope?

I had an idea in that each tile of the terrain could be modelled with 8 vertices where the 4 main vertices cover the actual tile itself and the remaining 4 vertices are used to model the sides/walls of each tile. The two problems I see with this implementation is that a) the world map is essentially doubled in size and b) given that not all tiles will include "walls", some tiles will end up with redundant vertices which are not used.

I'd like to create a terrain editor which allows for each tile to be deformed as well as including the ability to change the terrain during game play. This in itself poses additional questions such as; Can a VBO be used to store and render the terrain whilst being modified on the fly and also, is it possible to modify vertices without affecting neighbouring tiles?

I'm under the impression that i'm either over-complicating things or running into analysis-paralysis in that i'm neglecting to write any code to solve the problem without having a clear idea of how I would achieve what I want.

Again, i'm really just looking for a shove in the right direction with this. Is there a specific type of tilemap/terrain implementation that would cater for a 3D map to be deformed by both a map editor as well as during gameplay or do I have to roll my own, so to speak? I'm not trying to reinvent the wheel here but I am struggling to find any resources given that I'm not sure what to be searching for.

If anyone can provide any info, resources or snippets of code, that would be hugely appreciated as i'm eager to get my hands dirty and start producing something other than the flat wireframe I currently have.

Thanks for reading!

Answer 1

If I were you I'd look into voxels, more specifically Minecraft-type cube rendering. Unlike heightmaps, they can handle overhangs, caverns, buildings with multiple floors, etc.

You'd store your terrain in a 3D array of integers, where numbers are mapped to a certain type of terrain: 0=air, 1=dirt, 2=water, etc. Then, to create the mesh to render, you'd create the faces of a cube for each non-empty voxel.

This tutorial is a great explanation of how to do this in C++ using Ogre3D. I presume you'd have to go a little more low-level in OpenGL.

After creating the cubes, you'd want to smooth the edges to create the kind of fluid terrain shown in your image. I believe PolyVox (also in C++) does this; you could take a look at their code. I think you basically do in 3D what the image shows in 2D: average the surrounding cube positions to know where to place each vertex.

EDIT:

• Generate the faces for the cubes adjacent to water as if the water tile was empty, and render the water faces transparently.
• Faces on the "edge" can be generated just like regular faces, if you consider voxels outside the world to be empty.
• Physics: You can probably feed the rendered mesh to your physics engine as a static object.
• Map editor: You'd want to edit the underlying voxel data, not the mesh itself! (The mesh should mirror the data, so editing the voxels should produce changes in your mesh.) You might want to look up Model, View, Controller (MVC) if you're not familiar with it.

If you have more questions, feel free to leave a comment. Welcome to gamedev.SE!

Answer 2

This: http://30.media.tumblr.com/tumblr_m06qv6OREt1r2qjpao1_500.png is an example of a map I've done some time ago.

I had a XML representing the map and different types of tiles. Each type would have a few attributes:

• Height
• Position
• Merge Type: Which kind of merging this tile would do, ALL (if it should merge to any tile around it), EQUAL (only merge with tiles of the same type), NONE (never merge).
• Merge Height: The max height for slopes (good for overhangs), let's say you want a tile to merge only with tiles on the same height or a difference of 1, the value would be one.

I would then read all the tiles and create them in the scene. First only taking in account the position. Each tile had to know it's neighbour so I had to go through the map twice, once to create everything, and once more to move each vertex to the right position.

Though my models are hexes, the concept is the same, you would need a cube to represent your tile, you would then move the base vertices to the lowest level and 'smooth' the top of the cube with the cubes around it. You would also check if two sides of the cubes were merged so you can just remove that side from the cube (if they are not merged it's probably a cliff or something).

About physics, depends on your goal. If you're doing something like rollercoaster tycoon you don't really need them. You could just check the player height between each tile and decide the walking speed. You could do the same for a object that moves by itself (like the ball), you could check the tiles around (or the current tile angle) and decide a direction/speed. If you need realistic physics (like gravity, friction, etc) you would have to use a physics engine, and you could use the cube 3D representation in the engine.

Layers are also possible, but you would need something like minecraft (with smoothing on the cubes in the highest layer). If you only need layers for water, you can have a "water spring" on a tile and have your code fill every space around it that is at the same height or lower (a recursive solution would fit here nicely).

A terrain editor would also be simple, if your code is flexible enough, you can apply the transformations to a single tile (the one you're changing), or to a list of tiles (if you're using a 'brush' to select and move them). The same code can be used to modify the terrain on the game. And yes, you can change the vertices on the VBO, it's also possible to change vertices without affecting other (it also depends on you coding like that).