Terrain

[Gary Thomas]

I imagine that the real constraint will be "how do we show this on the screen?"

It is unlikely that we will have the resources to have a hundred different tiles for this gradation.

But all things are possible...

Cheers

[Simon Loverix]

You can still use four tiles: just assign ranges to them 0.0 to 0.2 = flat, etc.

[Gary Thomas]

Unfortunately the tile combinations are far greater than just four. We have to provide for the combination of conformation (your 4 categories) and surface appearance. Every combination will require a tile.

However, the point that the actual terrain can be continuous while using discrete tile representations is well taken.

On the other hand, subtle differences that the player cannot see, but which have an effect on how things work should be avoided. Troops moving slower than expected because the land isn't quite flat (though the fact isn't visible) will just lead to player frustration, then irritation, the rejection.

Cheers

[Simon Loverix]

I understand your concern. But..
- It might be easier for the pathfinding AI to compare a single value than several terrain types with qualitative difference.
- It's easier to balance things like movement allowances etc. later on.
- It avoids discontiuous jumps (in terrain modifications/infra like roads). You can also have passes that way (a 70% steep mountain square in a 90% steep mountain range, f e).

The reason I proposed this was the fact I noticed that using flat-roll.-hill-mount. would give clear borders in vegetation, like: at square X, the army camps in the forest. After marching half a day (at square Y), the trees suddenly disappear, and from there only low herbs can grow.

The standard behind that value would be: % usable terrain, with 0 being totally steep and rocky (no buildings or agriculture possible), and 1 totally flat (perfect for crops and buildings).
This still is an abstraction, but it allows for nuancing.

[Gary Thomas]

- It might be easier for the pathfinding AI to compare a single value than several terrain types with qualitative difference.

There is absolutely no problem here. The code is already done and working.

- It's easier to balance things like movement allowances etc. later on.

Not quite sure what you mean here. Are you talking about hand-crafted maps? If so, I suspect that they will play a very small part in the game. In playing the various incarnations of Civ, I always used a random map.

- It avoids discontiuous jumps (in terrain modifications/infra like roads). You can also have passes that way (a 70% steep mountain square in a 90% steep mountain range, f e).

Hey! the real world is discontinuous!

Cheers

[Simon Loverix]

- I mean, in the real world there aren't four terrain types, let alone a clear distinction between them.
- Being a piece of code really finished, it's surely better to leave the pathfinding alone for now.
- I'll leave my reservations about sudden edges in vegetation until we have a more complete map generator.

[star mouse]

I've noticed that not a lot of thought has gone into climate, and I feel this is actually fairly important. Its major role is to define where terrain features go on a map, but can also help define the terrain.

IMO, the major climatological attributes are Temperature and Rainfall. Low temperatures produce tundra, low rainfall produces Deserts, high rainfall and high temperatures produce Jungles. Combining temperature and rainfall with elevation can produce all the terrain features needed without complexities such as water tables.

Vegetation also needs to be considered. I feel it is best to keep vegetation separate from terrain because this allows more variety and makes it easier to model. Clearing a forest or planting crops should not change the underlying terrain and climate.

As an example, we can define three types of mountains and hills: Frozen (low temperature), Arid (high temperature low rainfall), and Green (high temperature and rainfall). Although it is not necessary to have these different hills and mountains, it will make the map as a whole more pleasing to the eye because the mountains and hills will match the surrounding terrain better.

[Gary Thomas]

There is a rather large ecology thread that considers climate.

Cheers

[Gary Thomas]

More thoughts about terrain.

The existing terrain coding is complex, hard to maintain, inflexible, and generally a pain. I can say this because I wrote it.

The present constraint on terrain is the availability of tiles to depict the terrain. Providing for landform and landcover combinations, as the code presently does, allows swampy mountains and mountainous oceans, for which we have little use, and no tiles.

So I propose the following:

1. Do away with the landform and landcover classes.

2. Replace them with totally data-driven Terrain class (which I have been working on from the point of view of movement and road-building, calling it TerrainEffects). Each landform/landcover combination that is actually used will have a terrain object defined in the terrain.xml file. The data will include the image reference as well. Each terrain type will have a symbolic name used for references in scenarios.

3. Make the image mapping totally data driven as well (this is a small job), using images.xml. This file will map a symbolic image name ("swamp" for example) to a gif name. The images will then read this in, and then read all the gif files. Then, to change the image for, say, "romancity", we just change the gif name in this file.

4. Military units (as they already do) will reference the symbolic name, so, if the gifs are changed, the military data doesn't need to change.

5. Scenario data (which shortly be transferred to data files, rather than hard coded) will, in the map, refer to the terrain symbolic values (see 2, above).

This system will allow percentage deforestation to be added when we actually implement that aspect.

The effect of all this will be to completely remove from the hard coded data all references to image and terrain specifics, and hugely simplify the movement, road building and map square code.

A further step that makes sense is to do the same for military categories. The above process will take out to data all the effects of particular military categories (foot, horse, etc). Because I have recently been of the opinion that unit categories really come in two shades (tactical and strategic), I now feel it should be data as well.

In particular, the defensive effect for close order foot (phalanx) on broken ground should be negative (it disrupts the formation), but for modern open order infantry it should be positive (they can hide). So these facts should be data-driven, not hard coded.

We are actually getting perceptibly closer to allowing general users to design scenarios.

Cheers

[Mark_Everson]

Sounds Outstanding!

Could you copy the terrain-related part of your post over to the ecology thread so that there is a record of it there also?

Thanks,

Mark

[Plutarck]

I'm going to take a crack at proposing a simplified terrain system.

Here's is what I propose, in a layer format:

Level 1: Base terrain.

Level 2: Base terrain modifier (explanation comes later). There can be more than one of these for each terrain.

Levels 3+: Overlays for everything else such as tile improvements (roads, rails, etc), rivers, citys, units, et al.


Only levels 1 and 2 concern us here. The "stats" of a tile are not determined by these rendering levels, but by what the "tile" actually is (unaffected by how it is rendered).

Explanations:

Level 1: The following are the types of base terrain, named for what they look like:

• Plain
• Hill
• Mountain

Layer 2: The "terrain modifier" is a layer placed on top of the base terrain, and thus decides what the final tile will "be". There are also multiple densitys of some forms (such as light-forest and dense-forest).

They are:

• Sand.
• Savanah. (golden color fields, named to be different than the base terrain "Plain")
• Grass.
• Ice, low density.
• Ice, high density.
• Rock, low density.
• Rock, high density.
• Trees, low density.
• Trees, high density.
• Light Water.
• Medium Water.
• Dark Water.

Now, this is how a "terrain tile" would be made for each type, ordered by base terrain type, and overlays listed from bottom to top. This is just an example of all the possibilitys, and most likely not a definitive list.

Tile types:

• Sand Desert: Plain base, Sand overlay.
• Rocky Desert: Plain base, Sand overlay, low-density Rock overlay.
• Rocklands: Plain base, Sand overlay, high-density Rock overlay.
• Tundra: Plain base, possible Sand or Savanah overlay, low-density Ice overlay.
• Permafrost: Plain base, high-density Ice overlay.
• Plains: Plain base, Savanah overlay.
• Grassland: Plain base, Grass overlay.
• Sparse Forest: Plain base, Savanah overlay, low-density Trees overlay.
• Thick Forest: Plain base, high-density Trees overlay.
• Sparse Jungle: Plain base, Grass overlay, low-density Trees overlay.
• Thick Jungle: Plane base, Grass overlay, high-density Trees overlay.
• Grassy Hill: Hill base, Grass overlay.
• Rocky Hill: Hill base, Plains overlay.
• Mountain: Mountain base, no overlay.
• Snow-capped Mountain: Mountain base, low-density Ice overlay.
• Glacier: Mountain base, high-density Ice overlay.
• Shallow water (Lake, Coast, etc): Plain base, Light Water overlay.
• Sea: Plain base, Medium Water overlay.
• Ocean: Plane base, Dark Water overlay.

That's 19 tiles, and I'm going to stop now, because I think you can get the idea. With just 3 base tiles and 12 overlays, you can create 36 different tile types, which is 3X more than Civ3 has (it contains only 12, and "flood plains" have the same graphic as desserts do, though there are 2 types of jungle, forests, and mountains - however they serve no gameplay purpose). In Civ3 they also made a whole different tile for quite a few types so they would blend better with the tiles around them, and that could be done with Clash or Blending could simply be used (article linked later in the thread).

However, that's if you add only 1 overlay. With tile types that use 2 layers the limit is well over 200, and that's not counting what could be done with blending or modifying effects in the rendering code itself! And there is the possibility of terrains using 4+ overlays, so even with limited resources an incredible amount of variety can be created!


To make the tiles flow together so they don't look so "tiled", please refer to this gamasutra article I just saw yesterday on the subject: http://gamasutra.com/features/20011024/peasley_03.htm

But that's window-dressing. Just wanted to make sure we all know it's perfectly possible, so we're all on the same page.



In summation, my proposal is simply the following:

1) Terrain should be composed of a base type and 0-3+ overlays, rather than making an dividual tile for each type.

2) Base terrain should be opaque.

3) Overlays should be transparent in places something isn't drawn. So if the overlay contains 1 tree, everything but the tree should be transparent. This is accomplished, I would propose, by including the color "Fuscia" (HTML #FF00FF) and "Neon Green" (HTML #38FE35) in the color pallette. Both colors are obviously so ugly as never to be used, but when rendering those colors would be set to be replaced by a transparent color. Fuscia would be used as a background, and Neon Green would best be used to contrast with Fuscia to create grids.

The reason for using an actual color for this is that very few file types actually support transparency, while nearly all types support fuscia and neon green (almost unfortunately...).

4) There should be no "mixed terrain" tiles. Either it's a mountain, or it isn't. Thus tiles will be determined by what the area it represents predominately contains. So if it's more mountain than anything else, it will be considered as Mountain.

With this proposed system there is simply no reason to add such complexity, which both complicates the code and makes understanding how to play the game a whole heck of a lot more difficult. This, the idea should discarded.

5) Some tile types will all be of the same "terrain type" for purposes such as terrain stats (movement and things like that), but the differentiation of types would just be to make the map look more interesting and realistic.

So Snow-capped Mountains, Glaciers, and Mountains could all have the same stats, but they would be displayed in different areas of the game where they fit better. Having a plane rock-Mountain in the middle of Antartica would make about as much sense as a Glacier in the middle of Africa

The rules for what is displayed where would be based upon climate (temperature and rainfall, to be exact), and would allow great customizability in the future.

6) Elevation should be discarded as "measurements in meters", whether rounded to a nice big number or not. There can be a Low Mountain and a High Mountain base terrain type, used for termining line of sight and other such things related to elevation, but anything more than "Low, Medium, and High" will add unneccessary complexity. And with a game like this, the last thing needed is unneeded complexity.

But that would not prevent the customization of adding any amount of elevation base terrain types, such as 10+ different height of mountains, but I propose that it would do more to contract from the "default" game than it could possibly add to it in terms of gameplay and learning curve. Not to mention any difficulty it would add to the rendering/programming...

7) Adding base terrain types and overlays is completely possible in this system so as to allow for gradual increase/decrease in relative "elevation" and foliage, but I reccommend that the amount of actual terrain types which have different stats be kept to a happy minimum. Anything over 16-20 tile-types with their own stats would further add unneeded complexity - and I HATE unneeded comlexity, thus I did not propose so much "gradient" in terrain types.


I believe this proposal would allow Clash to do the most graphically with the least amount of work (graphically and programmatically), as well as allowing maximum levels of low-overhead customizability and maximum robustness, and most of all I believe it has extremely little - if any - unneeded complexity.

"Make things as simple as possible," Einstein reccommended, "but no more." Words I live by.

And by the way, in approaching these game concepts might I reccommend the application of a modified Occam's Razor, if everyone does not do so already.



I think I said everything I meant to say, but I might of forgotten some point so be sure to ask if you have any questions. I'd be happy to answer them


Thoughts on this proposal?

[Plutarck]

I just noticed Gary Thomas' post above, and I think the best solution would be a combination of our two models (as they are not entirely mutually exclusive).

I believe the concepts of "broken" and "open" could simply be assigned to the terrain types themself. Here's how I would propose it be done (will probably need to propose by belief on how terrain bonuses for units should be handled, as well as units as a whole, to make this make total sense, but I'll put that aside for now):

There are broad Terrain types which are given base stats for any effects they would have (in a configuration file, of course). One of these, I propose, would be movement numbers for the different kinds of possible movement. I'll demonstrate with a "model" entry for a the "Grassland" tile:

Grassland
Type: Land, Open
Base Movement (just incase some special form of movement is added, otherwise unused): 1 (neither speeds up nor slows down anything, and allows movement over this square. 0 would mean impassible, 2+ would mean slower movement, -1 and lower would mean faster movement)
Foot: 1
Wheeled: 1
Mounted: 1
Fast Movement (perhaps an option for units that can "Fast March", in recognition that you can't exactly Fast March in a Jungle, but you can on a Grassland): 1
Hover: 1
Low Altitude (flight): 1
Medium Atltitude: 1
High Altitude: 1
Shallows (water): 0
Sea: 0
Ocean: 0

And for perhaps a Tall Mountain:

Tall Mountain
Type: Land, Heavy Cover (better name? guarded?)
Base Movement: 3
Foot: 3
Wheeled: 0
Mounted: 4
Fast Movement: 0 (not allowed)
Hover: 0
Low Altitude: 0
Medium Altitude: 0
High Altitude: 1
Shallows: 0
Sea: 0
Ocean: 0


Now then, units would be given move stats for the types of movement they can use (if more than one the game would select whatever movement was best and use that). The reason for allowing more than 1 is, for instance, sailing vessels. They could move in shallows (near the coast) but probably couldn't move very fast, but they can reach top speeds on the seas. But they aren't suited to ocean movement...either they just can't go into the ocean, or they'd have the chance for sinking alla Civ; for now I'd just reccomend the movement not be possible, for simplicity, but the feature could be added later.

Also consider the possibility of mounted troops being able to dismount and march on foot. Not all could walk their horses on foot effectively (knits and heavy cavalry), but I think some would be able to (such as mounted scouts or light cavalry).

This would allow for the greatest possible breadth of possibility, but wouldn't add much to space - remember, this information would be stored only once for each terrain and unit type, not for each individual one.


Also, regarding units, they should be given a base movement score in addition to how fast they can move on the aforementioned kinds of squares.

One more thing that should be stored is attack and defense bonuses (in %s, I would think) if on certain kinds of terrain (not as in Grassland or Mountain, but as in Open/Clear or Heavy Cover, etc). For instance Chariots would get a positive bonus in open terrain, but they'd get a negative bonus if in closed in terrain (like a valley).


Though the unit comments probably go best in the units thread...


Hopefully this made sense and I didn't leave something out.

[Gary Thomas]

There is a huge amount of discussion in the ecology thread on these very matters.

There have been a number of factors that have slowly been simplified out. Water table, for example. My focus is entirely on map display and the related movement and defense costs.

The problem with the overlay system (which we have been using) is threefold - the overlay effectively hides the underlying landform, calculating movement effects becomes horribly difficult, and we don't have the overlay tiles anyway.

Effectively the system you are proposing is the one we have been using, or rather trying to use without success. So we are going back to a single terrain type which includes all the overlays and the movement and defense effects.

The overlay system just did not work.

Cheers

[Gary Thomas]

The terrain.xml file we will be using is attached (zipped).

Cheers

[Mark_Everson]

I have a somewhat different view from Gary's of why the overlay system isn't the way to go for us. The main reason I have evolved to being against it is the practiality of the system in the context of the project's artist resources. The overlay approach is great for a commercial shop where you will have most of the same people working on the graphics full-time for at least six months or so. We, OTOH, have had almost all our artist team members working for a month or two, obviously part-time, and then they tend to disappear. I'm hoping Stian will be the exception.

Essentially the overlay system is IMO too high-maintenance for us. It requires a lot of coordination and attention to low-level detail to get all the layers to work right together. And as Gary said, one mask per overlay won't wash, since you need the forest to not hide the hills for the forested hills... So its more like one overlay per base type per type of overlay, reducing the apparent combinatorial advantages of overlays.

But my main point is that with what is likely to be a series of artists, each on the team for a modest amount of time, I think single tiles will work out better. There will be some sort of overlay approach for a few things like forest so we can do deforestation etc. And of course roads, cities and the like will be overlays. As the project matures, we might be fortunate enough to have long-term artistic team members, but I think counting on it at this point is inappropriate.

There are other advantages and disadvantages for tiles vs layers, but I think the artist tenure one is the killer.