16-09-2001 06:30									#31
	Got spare money?

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

	17-09-2001 00:56									#32
	Help yourself to an AD-FREE life

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

	17-09-2001 05:45									#33
	Support Apolyton, buy Civilization 2

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

	20-09-2001 14:36									#34
	Support Apolyton, buy Call to Power 2

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.

	20-09-2001 22:14									#35
	Support Apolyton, pre-order Civilization IV

quote: - 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.

quote: - 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.

quote: - 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

	21-09-2001 14:22									#36
	Support Apolyton, buy Civilization III: Complete

- 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.

	21-01-2002 06:32									#37
	Browse Apolyton AD-FREE

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.

	21-01-2002 09:52									#38
	Get a bigger avatar today!

There is a rather large ecology thread that considers climate.

Cheers

	21-01-2002 20:49									#39
	Browse Apolyton AD-FREE

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

	21-01-2002 21:35									#40
	Support Apolyton buy from Amazon

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

	21-01-2002 21:57									#41
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

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?

	21-01-2002 22:36									#42
	Support Apolyton, buy Alpha Centauri

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.

	22-01-2002 10:39									#43
	Help yourself to an AD-FREE life

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

	22-01-2002 10:55									#44
	Remove this text

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

Cheers

Attachment: terrain.zip
This has been downloaded 10 time(s).

	22-01-2002 17:21									#45
	Lose 30 kilos (of popups)

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.

	22-01-2002 17:50									#46
	Tired of ads?

I would disagree with overlays hiding underlying tiles (they probably do, but they wouldn't have to), and my proposal also solves the movement problem (since the effects/stats of the tile are set per "terrain type", and the overlays are merely a way of generating the tiles, not determining their effects).

However, without artists to actually draw the overlays (which I believe would actually reduce maintenance, but they do have a high overhead cost in creating them in the first place, thus being a bit of a deal-breaker) it's rendered rather moot.


Perhaps later on when the project is much nearer to a "fully playable product" a switch would be possible, or preferable, but I must agree that for now the overlay system seems to be an ill-fitting choice.


EDIT: Btw, the terrain.xml file looks good. One thing though, you have 3 errors:

On Broken, Mountain, and Ocean, the image tag ends up being closed with /broken, /mountain, and /ocean (respectively). Note: The bracketd aren't put here, because they won't be displayed.

Seems IE 6 validates .xml and is helpful enough to actually give you understandable debug data...wow.

Other than that,

Last edited by Plutarck on 22-01-2002 at 18:09

	23-01-2002 11:26									#47
	Support Apolyton or Terrorists Win

Thanks for the correction on terrain.xml - done late at night...

You can have < and >, but it is irritating. Ampersand lt and ampersand gt do it. Forgive me if you already knew that!

Cheers

	30-01-2002 03:27									#48
	Support Apolyton, buy Civilization: The Boardgame

Hi !

The overlay system is a good idea. But as Mark points out the number of artists isnt exactly numerous. In fact i'm the only one currently. I agree with Mark that single tiles will work out better for the time being.

The amount of work needed to make a satisfactory overlay system is something that needs some serious amount of work. I'm not saying it cant be done, but you will have to give me some time....

	30-01-2002 22:06									#49
	Support Apolyton, buy GURPS/ Alpha Centauri

The code no longer supports overlays except for roads and cities (though actually I haven't built in the overlaid cities yet). I will soon (when the tiles are available) add coasts, and their evil twin, rivers.

I do think that the time has come, if we can find someone to do it, that we have an image manager. This is someone whose responsibility is to pick up all the nice images around and assemble them in one place, and add the images.xml file which currently looks like

code:

<xml>
<image>
  <name>logobase</name>
  <gif>logo_base.jpg</gif>
</image>

<image>
  <name>flat</name>
  <gif>plains.gif</gif>
  <tile/>
</image>
<image>
  <name>rolling</name>
  <gif>hills1.gif</gif>
  <tile/>
</image>
<image>
  <name>broken</name>
  <gif>roughhills2.gif</gif>
  <tile/>
</image>
<image>
  <name>mountain</name>
  <gif>mountain2.gif</gif>
  <tile/>
</image>
<image>
  <name>swamp</name>
  <gif>swamp.gif</gif>
  <tile/>
</image>
<image>
  <name>dunes</name>
  <gif>desert2.gif</gif>
  <tile/>
</image>
<image>
  <name>forest</name>
  <gif>forest1.gif</gif>
  <tile/>
</image>
<image>
  <name>jungle</name>
  <gif>jungle.gif</gif>
  <tile/>
</image>
<image>
  <name>tundra</name>
  <gif>tundra.gif</gif>
  <tile/>
</image>
<image>
  <name>ocean</name>
  <gif>water.gif</gif>
  <tile/>
</image>

<image>
  <name>cityRoman</name>
  <gif>city_roman1.gif</gif>
  <tile/>
</image>
<image>
  <name>earlyCity1</name>
  <gif>town1.gif</gif>
  <tile/>
</image>
<image>
  <name>earlyCity2</name>
  <gif>town2.gif</gif>
  <tile/>
</image>

<image>
  <name>roadN</name>
  <gif>roadN.gif</gif>
  <tile/>
</image>
<image>
  <name>roadNE</name>
  <gif>roadNE.gif</gif>
  <tile/>
</image>
<image>
  <name>roadE</name>
  <gif>roadE.gif</gif>
  <tile/>
</image>
<image>
  <name>roadSE</name>
  <gif>roadSE.gif</gif>
  <tile/>
</image>
<image>
  <name>roadS</name>
  <gif>roadS.gif</gif>
  <tile/>
</image>
<image>
  <name>roadSW</name>
  <gif>roadSW.gif</gif>
  <tile/>
</image>
<image>
  <name>roadW</name>
  <gif>roadW.gif</gif>
  <tile/>
</image>
<image>
  <name>roadNW</name>
  <gif>roadNW.gif</gif>
  <tile/>
</image>

<image>
  <name>WarriorBand</name>
  <gif>warband.gif</gif>
  <military/>
</image>
<image>
  <name>Phalanx</name>
  <gif>phalanx.gif</gif>
  <military/>
</image>
<image>
  <name>Archer</name>
  <gif>archer.gif</gif>
  <military/>
</image>
<image>
  <name>Horde</name>
  <gif>horde.gif</gif>
  <military/>
</image>
<image>
  <name>Light Cavalry</name>
  <gif>horse.gif</gif>
  <military/>
</image>
<image>
  <name>Skirmisher</name>
  <gif>archer.gif</gif>
  <military/>
</image>
<image>
  <name>Chariot</name>
  <gif>chariot.gif</gif>
  <military/>
</image>
<image>
  <name>Trireme</name>
  <gif>trireme.gif</gif>
  <military/>
</image>
<image>
  <name>Longboat</name>
  <gif>longboat.gif</gif>
  <military/>
</image>
</xml>

	31-01-2002 03:41									#50
	Support Apolyton buy from Amazon

What about overlays for areas with abundant material of some sort like oil or good cotton-growing areas?

	13-08-2002 04:12									#51
	Support Apolyton, buy Civilization III: Complete

When playing Dawn 1, I get very irritated by having to specify all 20 road segments in the original square and the squares surrounding it. This is more micro-management than Civilization has.

I am increasingly inclined to go for a road system in which a square "has roads" and thus has an implied road to every adjacent square that has a road.

Mark has said that the roads are intended to be long distance strategic roads, along the lines of the Roman military roads. If that is the intent, then the game model should be modified to reflect that, and a lot of local roads made, in some way, unprofitable. One rather realistic way would be to have each road segement in a variable state of repair, and charge upkeep to make it stay in top condition.

Cheers

	29-02-2004 19:55									#52
	Support Apolyton buy from Amazon

I shall be taking the mantle of urban overlays and roads and waterways, once i've done enough wooden ships to keep Gary happy.
I'll refer my thoughts and gifs to an overlays (that includes roads, rivers and other comms - i dunno about coasts) thread (or should I say, stocks!)

As for roads, well, I can see the sense in both ideas - polygons should have an assigned level of "roadage", and more significant arteries - roman roads, railways, motorways, (and dare I say it, canals) can demand a slightly different set of gfx.

(i mention motorways and railways, as i can't help but imagine the game as it would be in more contemporary scenarios, rather than just contemplating it as an ancient era only thing.)

	27-09-2004 07:41									#53
	Support Apolyton buy from Amazon

Below I’ve attached an example template for terrain graphic sets that I have designed. It contains every possible tile transition needed for each individual terrain type (it also includes a bunch of extra room for additional graphical ‘varieties’ of the same tile – five more varieties to be exact). For purposes of this discussion, a ‘terrain type’ is defined as a unique combination of Landform, Moisture and Climate Zone (check ecology model). I don’t include Biomass and temperature in this definition because biomass is so interrelated with moisture and temperature with climate zone that it would be redundant to use all four variables (plus landform) when only two are needed IMO. These are just the base terrains, not roads or any other overlay such as that. (Gary, I know how to fix the rivers without having to separate mountains from the base terrain, it does involve creating a separate set of “mountain” rivers though – but it’s the best approach IMO – at least far better than having overlaid mountains and hills. Let me know if you want to go over it before I post it, as there is always the possibility that there are holes in my logic.)

The tiles are drawn in 128x96 blocks to allow room for extending beyond the north point of the tile. The chosen size is equal to those used in Civ3, allows for a greater degree of detail, and should be displayed at actual size on the closest zoom level (for most playing conditions you will be looking at them at three-quarter (75%) to half size (50%). This template was made for ease of use by me, as the “artist.” It can be broken down into its constituent parts (even resized), if needed, though the number of individual tile graphics would be huge. Also, if we use the idea of having multiple varieties of each tile type, it will be exceedingly cumbersome not to use the templates as they are.

The example template is ugly. It includes “monochrome” terrain, black tile outlines, green guide lines, it’s blocky, and other general ‘ugly’ things. Under ‘normal’ circumstances there will only be the tiles, as would be visible in the game, over a magenta background. Keep this in mind while critiquing the template.

The following tiles are going to be produced unless someone objects or has anything to add/change:

Land Tile Types
Flat
Flat, Wooded (Forests & Jungle)
Plain
Plain, Wooded (Forests & Jungle)
Tundra
Tundra, Wooded
Rolling Hills (Desert & Arctic versions also)
Rolling Hills, Wooded (Forests & Jungle)
Rugged Hills (Desert & Arctic versions also)
Rugged Hills, Wooded (Forests & Jungle)
Rolling Mountains (Desert & Arctic versions also)
Rolling Mountains, Wooded (Forests & Jungle)
Rugged Mountains (Desert & Arctic versions also)
Rugged Mountains, Wooded (Forests & Jungle)
Volcano
Volcano, Wooded (Forests & Jungle)
Dunes
Desert
Swamp
Glacier

Water Tile Types
Lake (freshwater)
Coastal (always adjacent to land)
Sea
Ocean

That’s a total of 39 terrain types (35 land, 4 water). By having a separate ‘unique’ coastal tile we are able to avoid having to draw coastal transitions for every one of the other land tile types. It features a transparent area which, when the coastal tile is drawn over the "coastal transition" from the terrain set, allows it to appear as though the adjacent tile is bleeding through. I’ll also assume that coastline (land) transitions into coastal tiles (land extends into water). I won’t have anything to do with it going the other way (coastal water going onto land). It’s much too difficult to make the tiles look good when doing it that way.

As you can see in the template, there is enough room for six of the ‘block groups” that define a tile, or six varieties of the tile set. This should not be a set number. It should be coded to allow for indefinite expansion of tile varieties (by getting the height and width of the template and dividing by known tile sizes*).
*How to know the tile size is probably best left to a variable in a ‘settings.xml’ file or some such mechanism, thus allowing for larger or smaller tiles, as an artist sees fit.

Also, as can be seen in the template, each block group has 2 empty spaces. I’m not sure what to use these for, if anything. Any suggestions would be welcome, as I’d hate to waste the space, and I really don’t want to change the layout.

I thought of using them as ‘random bonuses’ sort of like the bonus grassland in civ, though without any ‘in-game’ effect. On a desert tile you might put a cactus, or bleached skull. On a glacier tile you could put crevasses. Plains could have small lakes or copses. It could add a little more uniqueness to various tiles on the map.

*Edit - one of the empty spaces will contain the "coastal transition" tile. This tile is colored at the edges with a transparent hole in the center. It is drawn first, then the coastal tile to give the effect of the adjacent tile extending or bleeding into the coastal tile.



Since this post is all about adding variety to Clash:
Adding variety to terrain in non-graphical ways:

For each type of terrain, add a range of values, rather than a fixed number, for farm, production & service sites. For example:

Tundra = Farm 1-2, Production 2-4, etc.

The same can be done with specials:

Iron = 5,000-35,000, 0 renew*
*the renew value is added in each turn to represent renewable resources.

Last edited by alms66 on 27-09-2004 at 19:23

	27-09-2004 07:44									#54
	Browse Apolyton AD-FREE

The Example Template (at half size):

Attachment: example template_half.gif
This has been downloaded 42 time(s).

	27-09-2004 21:35									#55
	Support Apolyton, buy GURPS/ Alpha Centauri

I know some of you (Gary) oppose coastline extending into the water, but I’m of the opinion that it is the only way to do it right, and I’ll give an example here, showing why I know it will work, and how you can ‘live’ with it, and like it as well.

In the first tile we can see a unit in the northernmost quadrant of the tile (magenta dots represent the center of the quadrant – or tile). The reason for using such ‘small’ units (and this stickman mock-up is a bit smaller than it really should be) is due to the fact that Clash can have multiple combatants fighting over multiple turns in a single tile. As you can see from the second tile, you can have a maximum of nine combatants (each centered on a magenta dot) in a single tile (I suggest we artificially limit it for aesthetic reasons as well as the fact that 9+ combatants in a single battle is a bit much). This works for all tiles – land and water. It will appear a bit ‘weird’ to see 3 out of 9 combatants “beached” graphically in coastal battles, but it’s a small price to pay, considering the rarity of such massive battles occurring in these specific squares, for such aesthetic quality.

The good news is that we can use this graphical “problem” that appears with 9 naval combatants in coastal tiles to great effect when naval combatants join in land battles, by extending the 9 combatant limit to 12 (and graphically using the 3 innermost points of the coastal tile). Thus in a coastal battle, you could have up to 9 land armies and 3 supporting naval fleets. When these three supporting naval units join the battle, they will appear “beached” to the player.

I mention a hard limit (9 and 12) on units involved in battles, but this isn’t entirely correct. What that limit should be is 9 in the actual ‘battle’ tile, and one for each point adjacent to this battle tile, which would be 1 for each of the 4 cardinal (N,S,E,W) directions of the battle tile, and 3 for the other four directions (NE,NW,SE,SW), giving a grand total limit of 25 participating combatants in any given battle. This limit of 25 should apply to land and water battles equally, allowing support to come from outside the actual battle site itself.

Comments, questions and/or opinions, anyone?

	27-09-2004 21:39									#56
	Full PM-box? Change here!

Here's the image discussed in the previous post (at 200% actual size):

Attachment: coastal_example.gif
This has been downloaded 37 time(s).

	02-10-2004 17:31									#57
	Support Apolyton, buy Civilization III: Complete

I don't get your point about units in tile. There is only ever one unit per civ shown in a tile. Having battles with 9 or 12 civilizations in the same coastal square is probably uncommon indeed. Since there is no limitation on the number of civs present in one square, there might by 48 of them and, as you say, we should limit the number shown to something reasonable. Without using a details panel, anything more than 5 is probably too much for a human to apprehend in a single glance. So I'd probably limit that to 5 anyway for everyone.
I don't car about lands going into sea or the contrary, but I wonder how you make rivers.
In order to extract the in-game images from the template, we'll have to do some coding. I think we'll need a small program to transform the original template into a set of individual tile images which are used internally by the program. The individual files wouldn't be seen by the player but put in a temporary directory used by the software. Do you need magenta and another color for alphablending of the coasts, or can the blending be done by using magenta too?
The guidelines are for use only by the artist, I think their width should be specified too, so the xml format file would be something like:
width of a tile, height of a tile, width between tiles, height between tiles.
I'd rather have a name for the indiviual tiles in the resources file too.

	02-10-2004 21:48									#58
	Put an end to popups!

quote: Originally posted by LDiCesare I don't get your point about units in tile. There is only ever one unit per civ shown in a tile. Having battles with 9 or 12 civilizations in the same coastal square is probably uncommon indeed. Since there is no limitation on the number of civs present in one square, there might by 48 of them and, as you say, we should limit the number shown to something reasonable. Without using a details panel, anything more than 5 is probably too much for a human to apprehend in a single glance. So I'd probably limit that to 5 anyway for everyone.

I was suggesting that we put an artificial limit of 9 civs on the primary tile, with the possible addition of 16 'supporting' units from adjacent tiles joining the battle. A five unit limit would work just as well for me.

I have a secret desire (shhhh!) of wanting to get rid of that 'unit detai'l panel altogether. I'd also rather move 'armies' around the map, rather than 'unit groups,' but that's a whole other discussion.

quote: Originally posted by LDiCesare I don't car about lands going into sea or the contrary, but I wonder how you make rivers.

What do you mean here, about rivers?

quote: Originally posted by LDiCesare In order to extract the in-game images from the template, we'll have to do some coding. I think we'll need a small program to transform the original template into a set of individual tile images which are used internally by the program. The individual files wouldn't be seen by the player but put in a temporary directory used by the software.

I'm sorry if my post wasn't clear on this, but these templates are for my use only (as well as any other artist that follows) - unless - everyone agrees it would be better to use them for the game. I can extract the individual tiles easily enough by hand (in fact, I think there are programs available that automate the process for you - so we don't have to write one), if we prefer to keep using the individual tiles. My intention wasn't to pile on more coding jobs, but to make it easier to draw the tiles, by making all components visible in one file.

Also, if Clash isn't ready for the larger tile size, I'll simply resize them to the current size while extracting the individual tiles.

quote: Originally posted by LDiCesare Do you need magenta and another color for alphablending of the coasts, or can the blending be done by using magenta too?

I believe the correct term is 'dithering' not 'alphablending'. I'll use magenta to create 'holes' in the land portion of the coastal tile. I'll also create a 'coastal transition' tile. The coastal transition will be drawn first, then the coastal tile. The effect will be that the coastal transition will appear through the 'holes' in the land portion of the coastal tile.

*suggestions for a more efficent way are welcome.

quote: Originally posted by LDiCesare The guidelines are for use only by the artist, I think their width should be specified too, so the xml format file would be something like: width of a tile, height of a tile, width between tiles, height between tiles.

Yes. Unit and Terrain tiles should be specified in some xml file (I believe I mentioned that somewhere). BTW, I left no distance between the tiles. The empty space (seemingly) above the tiles is for extending mountains, trees and such above the northern point of the tile.

quote: Originally posted by LDiCesare I'd rather have a name for the indiviual tiles in the resources file too.

So that's a vote for keeping tiles in their individual files, correct?

	02-10-2004 21:56									#59
	Lose 30 kilos (of popups)

quote: What do you mean here, about rivers?

I mean currently we could reuse the coast tiles for rivers, we'll definitely need different graphics for rivers.

quote: I believe the correct term is 'dithering' not 'alphablending'. I'll use magenta to create 'holes' in the land portion of the coastal tile. I'll also create a 'coastal transition' tile. The coastal transition will be drawn first, then the coastal tile. The effect will be that the coastal transition will appear through the 'holes' in the land portion of the coastal tile.

I thought of using semitransparent tiles to make transitions, but thinking more about it, it just doesn't make sense for coasts, though it could for transitions between e.g. deserts and plains.

quote: So that's a vote for keeping tiles in their individual files, correct?

Yes. But then I am not adamant about it either.

	02-10-2004 22:14									#60
	Support Apolyton buy from Amazon

quote: Originally posted by LDiCesare I mean currently we could reuse the coast tiles for rivers, we'll definitely need different graphics for rivers.

I'll draw a new set of rivers. I had created a set, and sent it to Gary, I don't know if you ever saw it. I hadn't finished them because I needed to be able to see what they looked like in-game to do so. The new template will allow me to rely on in-game looks less than working with individual tiles.

quote: Originally posted by LDiCesare I thought of using semitransparent tiles to make transitions, but thinking more about it, it just doesn't make sense for coasts, though it could for transitions between e.g. deserts and plains.

By semitransparent, do you mean alpha channels or dithering? As far as I know, apha channels aren't supported by gifs, so I was planning on drawing the transitions for each tile with a little dithering, as you can see in the template.