aoe2 and hero3-why they are so smooth?

Started by
16 comments, last by LEET_developer 18 years, 9 months ago
lanceking, no, no no! You store the tileset graphics on disk, certainly. And in the map data, you store the terrain type for each tile. But you don't store /which/ transition to use in the map data; which transition to render gets chosen at run-time.

Separate the two in your head; the graphics are pre-drawn. The basic shape of the map is authored. The edges between tiles are NOT rendered or generated at run-time! WHICH edge graphic to DRAW is chosen at run time.
RIP GameDev.net: launched 2 unusably-broken forum engines in as many years, and now has ceased operating as a forum at all, happy to remain naught but an advertising platform with an attached social media presense, headed by a staff who by their own admission have no idea what their userbase wants or expects.Here's to the good times; shame they exist in the past.
Advertisement
Wyrframe, one more question.
Why we only store terrain type in map data, not the tileset index?
If we store tileset index in map data, then we need not to detemine
which tile to use at run-time, right? Seems many map editors are
exporting this kind of map data.
Tileset index is the same as terrain type. Generally you have a tileset, which contains a certain number of terrain types (tiles), numbered starting from 0 (to give each one a unique identifier). Then tileset index 4 refers to the 5th terrain type in the tileset (we're counting from 0, remember?)
Hi Raveler, if tileset index is the same as terrain type, then why do
we need to "pick which edge to use at run-time"?
To wyrframe, I still think we should store which tile to use in the map
data, not to "pick which tile to use at run-time", this should be a pre-process
done by the map editor. Am I right?
Okay, let me back up one step. I'm not describing all tile-based systems; I'm describing for you the Heroes of Might and Magic map system. Let me simplify the system to see if I can explain it better.

Say you have three terrain types. Forest, Grass, and Water. Forest and Water are impassable. Forest can border on grass, and grass can border on water, but forest and water cannot border on eachother. This means more specifically that you can have forest and water adjacent in the map, but that there is only artwork for forest alone, grass alone, water alone, forest to grass, and grass to water.

Each tile has a terrain type, which is one of these three. This is all the information the map need store on disk.

When we render, we pick which tile from the artwork to draw. This will be one of dozens of different tiles, based on the tile we are looking to draw and the 8 which surround it. Let's assume that we're only looking at a straight edge of terrain, with one type on the left and one type on the right.

Grass | Water

There are two tiles here; a grass tile on the left, and a water tile on the right. When rendering the grass tile, we just draw a plain grass tile as if the water wasn't there. When rendering the water tile, however, we are going to choose a water-to-grass transition, with the "land" on the left side of the tile.

Now imagine this situation...

Forest | Water

We don't have a forest-to-water transition, but we do have forest-to-grass and grass-to-water. so that's what we render; pick a forest-to-grass transition for the left tile, and a grass-to-water transition for the right tile. Instant happiness.

What I'm telling you is that for this style of terrain system, all that needs be stored is the base terrain type. Tile index is not the same as terrain type, but the terrain type tells you what part of your tileset you'll be rendering, just not specifically which tile. Which was your original questions.

Now, for other tile-based systems, yes, you will often want to store the exact tile index in the map. But the HM&M3 system you don't need to. For the Age of Empires system, I suspect something very similar comes into play.
RIP GameDev.net: launched 2 unusably-broken forum engines in as many years, and now has ceased operating as a forum at all, happy to remain naught but an advertising platform with an attached social media presense, headed by a staff who by their own admission have no idea what their userbase wants or expects.Here's to the good times; shame they exist in the past.
Here is an article on Gamedev about tile transitions. Hopefully it will help explain in a little more detail what the above posters have been talking about.
Evillive2
When i made a map editor system in gamemaker, i put a check system in the game loop. It checks to see what kind of tile is placed to the left, right top bottom and corners and changed itself to fit that.

it was very teadeous though.
If it's possible for us to conceive it, than it must be possible.
Another way to do it is to load your different tiles (say you have 3xgrass, 3xtrees, 3xwater for now) into an array.

then each tile in your game can just have a couple layers (depending on how you allow tiles to be layed out, Im going to assume for simplicity sakes only two different types are touching at any one time).

then you have a blend mask, simple alpha texture to blend from the top layer to the bottom layer, this way you can have any transition you want, without having to prebuild transition textures.

so now where you would have 9 different Grass -> water tiles, you now have just 3 different blend textures, giving you 27 possibilities ( 1 - 3 grass, 1 - 3 blend, 1 - 3 water).

this gives the added advantage of getting things like Mud -> grass, and swamp -> grass for free :) because you can use the same blend textures for most liquids to most types of land... you will of course need a new one for something like trees.

this method can also be extended to take into account all 4 neighboring tiles, you just need to have 4 layers per tile and a few more blend textures.

hope this helped.

Edit: Sorry I guess thats what you were talking about in your second method. I've done this system before and it worked fine, no problems with framerates.

This topic is closed to new replies.

Advertisement