You could have a more detailed map generated from the strategic map easily: The map in my examples would be the strategic map. It shows the general details (forest, some type of grassland, and mountains). Lets say you pick the uppermost tile on the right edge - a mountain. You could create another probability table for the features of a mountain (or mountainous area if you want more than just a single mountain) and do the process of creating a random terrain again, but instead of choosing the type of terrain you choose details, like maybe put a small crevice in one spot, a boulder somewhere, a steep dropoff between some tiles, etc.

You use the same basic idea for both maps, except for one you''re choosing what type of terrain randomly and on the other you''re choosing the details randomly. The actual specifics of your implementation depend on what type of map you''re using. If your game is going to use a tile-based map, you can do exactly as the images show. If you''re using a 3D mesh for terrain, it becomes more difficult but not impossible. You could even take the tile map and turn it into 3D by putting several trees where a forest tile is, a large mountain object where the mountain tile is, and using a different texture in each place (green grassy for forest, rocky-loocking for mountain, etc)

Extrarius beat me to it, but here''s another explanation.

Here''s how it might work (may differ slightly from Extrarius'' system, but the same basic concept):
There are multiple zoom levels. You may prefer to have just the two; strategic and tactical, but you would still have extra levels behind the scenes. Let''s assume for the moment that you''ll display them all, and for the sake of simplicity we''ll say that this is all in 2D.
Assume for the sake of this discussion that your top-level map is 1000*1000 pixels, which you draw by hand. You''d probably want two different versions of that map, one pretty version that the player sees, and one that represents the terrain types. That second one is the one I''ll be referring to. Divide that top level map into 100 blocks of 100*100, and that is map level 1. If you want to zoom in one level and display one of those blocks at 1000*1000, it''s going to look like a bunch of 10*10 tiles of uniform color, right? So, the question is "how do I use that uniform color to generate extra detail?" Easy. Remember that the base color of those tiles represents the type of terrain in that area. For each of the pixels in that tile, you enter the pixel''s coordinates (relative to the whole block) into your PRNG, which returns a number. The way that number is interpreted depends on the terrain type. Now, you''ll probably want extra zoom levels beyond this one, so the number returned won''t be used to generate actual terrain detail, but to refine the terrain type. Further zoom levels refine it still further, until you get down to a scale where individual details like trees or buildings are visible, at which point the generated number is used to create those.

Here''s an example:
Your top level map is 1000*1000, with a scale of 1 pixel = 1 square km. The map is composed of indices into a list of terrain types that are appropriate to that scale, e.g "light woodland", "industrial", "swamp", etc.
The next zoom level consists of square blocks 100km to a side, where each pixel represents an area 100m to a side. This scale is still too coarse to generate detail, so we have to refine the terrain type further, e.g. "industrial" might be refined to "warehouses", "refineries", etc.
In the next zoom level, each pixel represents a 10m*10m area, where you could refine the terrain type further.
The next level is 1 pixel = 1 square meter. You could generate detail at that level, or you could go one level further and generate detail at the 10cm scale.

I hope that all made sense. The biggest problem with a system like this is that any changes to the environment (like bomb craters, demolished buildings, etc) have to be stored seperately in a change list. That list might get quite large.

ahhh, I think I get it now. You simply subdivide the map into smaller and smaller tiles with finer grained level of detail. I''m assuming that in Plasma''s example, the terrain doesn''t have to be randomn;y generated at all, since it is merely the interpolation of going from a more abstract terrain type (woods) to a more refined type (swamp, jungle, thick forest, etc). Each pixel on the map is then rendered according to what kind of terrain type it is.

While that seems to work pretty well for a 2d map, what about 3d? I guess you could simply include height maps but I''m not too familiar with how terrain engines work.

quote: ...the terrain doesn''t have to be randomly generated at all, since it is merely the interpolation of going from a more abstract terrain type (woods) to a more refined type (swamp, jungle, thick forest, etc). Each pixel on the map is then rendered according to what kind of terrain type it is.

Well sort of. It''s not really interpolation as such, since you really are creating new detail as you zoom in.

One point that I forgot to mention is that whenever you zoom in to a sub-block you must reseed the PRNG with a number unique to that block (perhaps generated by entering the coords of one of the block''s corners). Otherwise every block will have the same patterns in it. Of course you must also maintain a stack containing the seeds used in previous zoom levels, so that you can zoom back out again.

The same concept will work for pretty much anything, 2D or 3D. It just takes some ingenuity to adapt the system to what you want to do with it. I once used a system like this to model an entire universe that probably had more star systems than the real one, and every one of them had planets.

quote: Original post by Plasmadog
...Otherwise every block will have the same patterns in it. Of course you must also maintain a stack containing the seeds used in previous zoom levels, so that you can zoom back out again.

Ahh, I was wondering about that. I was trying to think that if you zoomed back out and then re-entered that area if the terrain would look the same as it did before. Why a stack though? If you cover some new area...say you focused on a different area of the map, wouldn''t you NOT want the last item you placed on the stack? I''d have thought the opposite...like a Queue would be better.

Hmm, now that I think about it, that wouldn''t work either. So wouldn''t you need to create some kind of N-ary tree to partition out the map? then when you zoom back in at that same level, you have to search for that area again through the tree?

OK, so if you want to fight in the woods and I want to take the city in that province, what exactly is the incentive for my going into the woods again? Enjoy your bark soup.

My point being that combat occurs in one of 3 locations usually.

1) A location of opportunity on the path to an objective (city/mine/whatever). This usually means that the defender gets to fight largely where he wants to, so long as it is on the path to that objective.

2) At a resource that the defender can''t afford to lose. The Russians weren''t defending the tank factory because they didn''t care about it. They couldn''t afford to lose it.

3) At the point of contact. If I''m running from point a to point b, you''re running from point c to point d and we run into each-other, we''re still gonna fight.

Sometimes a force will go out with the objective of destroying another force (many of the renassaince period battles were like this), whereby the defender could choose where he wanted to fight. It''s a relatively rare situation though.

Think about that before implementing anything.

quote: Original post by Dauntless
Ahh, I was wondering about that. I was trying to think that if you zoomed back out and then re-entered that area if the terrain would look the same as it did before. Why a stack though? If you cover some new area...say you focused on a different area of the map, wouldn''t you NOT want the last item you placed on the stack? I''d have thought the opposite...like a Queue would be better.

Hmm, now that I think about it, that wouldn''t work either. So wouldn''t you need to create some kind of N-ary tree to partition out the map? then when you zoom back in at that same level, you have to search for that area again through the tree?

This is another aspect that has to be tailored to your particular application. In my universe model I was able to get away with a stack, simply because very little information was transferred between levels. I was able to go directly to the previous zoom level. But you''re right, a queue might be more appropriate for your app. If you push the current seed and block coords into a queue before you zoom in, then zooming out would be a matter of starting at the top level and working all the way down again.

solinear-
There''s lots of factors involved in determining where you''re going to fight. Defenses don''t have to be a static location like a city or resource center. Sometimes the object is the armed force itself.

Let''s say I duck off into the woods...where did I go? For all you know, I''m heading towards one of your cities or making a wide sweep to come around and hit you on your back.

And how do you know that my infantry force is the only force out there? Yes, maybe that city out in the wide open is a tempting target, but how do you know I don''t have other defenses out there?

While all of your points are valid, they are not exclusive as I have just shown above. Terrain advantages do usually go to the defender, especially in static positions, which is why the attacking force almost always has to outnumber a static defensive position.

Just because you see an enemy force in a terrain that is disadvantageous to you doesn''t always mean you can neglect that force. Either they may be on track to hit one of your cities or resources, or they may maneuver around to hit you somewhere else.

That''s the problem with current RTS...they have ingrained a way of thinking in players today that doesn''t really model how militaries fight. In the real world, you wouldn''t group your main attack force in one monolithic lump and use that to attack. Instead, you split your forces into groups...some covering center, some covering left or right flanks, some reserves, and very often another whole set of armed forces laid out the same way If you assume that the main attack force is heading off into the woods, there''s the possibility that there are others lurking out there too. Of course more than likely the other guys side is also split into groups, which makes the dynamic more complicated.