28-11-2004 04:03									#121
	Support Apolyton buy from Amazon

quote: Originally posted by LDiCesare About roads, if you find them ugly, I think we could define the set of overlays that you want shown on the map at any time. (Though thinking of coding the dialogue to show that makes me ill.)

Yes, they are ugly to look at everywhere, but that's secondary, and I don't think we need a filter. The main point is that road graphics are not needed. If all you do is click 'move', click the destination and you're done, why do you need to know where roads are? All you need to know is how long will it take. I'd rather handle them in the same way 'farms' are handled. An increase in 'farms' infrastructure produces an increase in 'farms' output. The same should work for roads. An increase in 'roads' infrastructure produces and increas in 'roads' output (or movement).

	28-11-2004 06:31									#122
	Tired of ads?

IMO you still need to know where major roads are, and be able to place them. All movement is not planned by just clicking on the destination square. Especially for warfare you need to be able to look at the map and estimate routes and travel times well ahead. Making sure there are good internal lines of travel for military purposes is also very important.

For minor roads, I agree that they should be abstracted.

	28-11-2004 07:06									#123
	Support Apolyton buy from Amazon

If you click as though moving the unit, you get an estimate of how long the route will take, and you can cancel it if needed. Whether you do the estimate, or the computer does it, you'll end up with the same result.

	28-11-2004 08:00									#124
	Suffering from ads?

Yes, but I don't want to click on lots of different paths to examine different routes when it is a Lot easier just to See the major roads on a map.

	28-11-2004 14:21									#125
	Avatar Enlargement: We've got the solution

quote: Yes, but I don't want to click on lots of different paths to examine different routes when it is a Lot easier just to See the major roads on a map.

Agreed.

	28-11-2004 18:30									#126
	Increase the size of your Attachments

quote: I’d prefer to have several (5-10) different city graphics of various size, as a single overlay rather than dozens of house graphics overlain to show urbanization. Only the largest (population) ‘cities’ need be shown, so that even in the modern era, there are still some large tracts of rural (or terrain) tiles showing.

I think this is missing an opportunity to try a radical new approach.

When I initially proposed this idea, it was like Vovan suggested: a little house graphic for each set number of population.

On top of that, you could then actually display zones in a rudimentary, but nevertheless simple and effective way - with other little generic building graphics to indicate the population of a given sector: shops, temples, forts etc...

However, I was also thinking of simply shading the area like in an atlas rather than having any icons at all... using varying sizes and ultimately styles of city "icon" is hopelessly unoriginal, and not really in keeping with the nature and complexity of this game IMO.

It makes little sense to insist on loads of detailed graphics when you:
a. don't need them; and
b. can't get them at the rate you want

I think you should go for a simple generic set of small semi-sillhoutted 4 (or few) colour icons, that can easily be tarted up in a scenario editor GUI. (Save a bit of memory to good effect).
You could then conceivably do nice little animations if you wanted.
I also think they'll look better anyway - a minimalist approach can create a great look, and allow easier future customisation.

treat the idea of having the icons displaying their EG as an overlay.

I mean overlaying graphics seems to be the way it's heading - such as with displaying roads (Roads ON/Roads OFF) and stuff - it's a sensible option providing the game-players with the control they want - and adhering to espoused game principles (not to mention good online design principles - if it's going to be an online game at some point).

But on the subject of roads... is the issue not really knowing how long it takes for a unit to get from A to B, but whether it can take other longer ways as part of some kind of strategy?
Like you might want to block a route - like a coastal road along the Ligurian coast to force enemies to go by ship of over the alps?
I mean once you say you don't need to see the roads, you could just as well say that you don't need to see the terrain - the computer just calculating relative the difficulty of crossing it!

	07-12-2004 20:23									#127
	Support Apolyton

Edit-
snip...

Just to make Gary happy , I'll do them all in 80x60 for now, since transitions aren't currently supported anyhow, I figure I'm pretty much wasting my time drawing the set I started on until I'm ready to code it myself. So I'll do an 80x60 set of all the tiles I listed before, in the Terrain thread.

Last edited by alms66 on 19-12-2004 at 10:20

	19-12-2004 11:04									#128
	Transitions Put an end to popups!

Clash should have 3 types of transitions, normal, cluster and coastal. Normal transitions are those which extend from the tile into an adjacent tile (about 1/4 of the tile), and are the most widely used and known.

Cluster transitions, rather than extending out into an adjacent tile, occur within the last tile itself, leaving about 1/4 of the tile as “flat”. These flat areas can be transitioned into by normal transitions. Cluster transitions are the type used by woods (forests and jungle), hills and mountains in the Civilizations series, and should be used for the same purpose in Clash.

Civilization (2 & 3) did something which was absolutely unnecessary though. They separated woods, hills and mountains from the base tile (grassland, plains, and tundra). Gary and I once talked about using this option, though not much, and the last thing I mentioned to him was that it was unnecessary, but then he went on vacation . The reason Gary and I were discussing the possibility of separating the tiles into base layer and “height” layer was to make rivers look good in hills and mountains (they were obscuring the mountains (etc.)). The better solution, as I mentioned then, is to use a different set of river graphics in hills and mountains (since that route would be quicker and easier than separating the tiles into two layers). This alone would prevent the river from appearing on top of the mountains (etc.), as you could simply leave transparent places where the river would fall behind the mountain (etc.). I think we can do one better though. We can create valleys for the rivers in mountains (etc.), by marking the tiles next to rivers as a transition even if the tile on the opposite side is of the same type. This would give us the extra room needed to make the entire river visible (since cluster transitions take up only 3/4 of the tile), thus eliminating the need for several different river tile sets in the process.

Coastal transitions are basically normal transitions that apply only when land meets water. The only major difference is that the coastal transition is self-contained. It does not transition into anything, nor does anything transition into it.

The way Clash currently handles coastal transitions is just plain wrong. There are graphical errors caused by the coastal transitions extending into land rather than land extending out into water, as I assume everyone has noticed by now. You can fix these by separating tiles into a base layer and “height” layer (in addition to using cluster transitions at the coast), though as I said, it’s really not worth the amount of work that requires. The only viable solution is to have land extend into water, as every other (similar) tile-based game has done before us.

Though I hope everyone can understand this post (by looking at examples from civ 2 & 3 as well as Call to Power I & II) without them, I'll elaborate with example images if required.

	19-12-2004 15:47									#129
	Support Apolyton, buy Civilization 2

quote: Though I hope everyone can understand this post (by looking at examples from civ 2 & 3 as well as Call to Power I & II) without them, I'll elaborate with example images if required.

Well, I ubderstand the words and all that but... I remember very well how transitions work in CtP2, with dedicated tiles for various transitions. I'm mostly wondering how the code should be done to handle that. You would have terrain tile drawn in the middle, transitions on the borders, but I don't know how corners were handled.
Civ2 transitions were handled quite differently from CtP2 if I'm not mistaken. So if you show a few examples, that'd be great.

	19-12-2004 23:49									#130
	Support Apolyton, buy GURPS/ Alpha Centauri

Civilization 3 isn’t the best game to take screenshots from for this (they use a different sort of graphic system which produces some anomalies in what I describe above), but it’s all I’ve got at the moment, so I’ll try with this. Here you see a ‘normal’ transition on the plains (that is grassland is transitioning into plains).

The mountains and the hills show a ‘cluster’ transition. And now you’ll have to use your imagination a bit. Imagine that the hills did not extend beyond the red line. Thus the transition doesn’t occur in an adjacent tile, but occurs within the final hill tile itself, leaving about 1/4 of the tile flat (enough room for an adjacent tile to transition into the hill tile). Now, look at the bottom left and imagine that the green dots were hills as well, and the blue line was a river. If those green dots were transitions, then the area between the red lines would be the “valley” where the river tiles were drawn.

Coastal transitions are sort-of self-explanatory. The light blue water + the land extending into it make up a coastal transition tile. It’s self-contained and does not interact with adjacent tiles, except to do a normal transition into sea (the darker blue tile adjacent to it).

Has this been of any help at all?

Attachment: transitions.jpg
This has been downloaded 20 time(s).

	20-12-2004 01:16									#131
	Tired of ads?

What bothers me is it's asymmetrical. How do you decide prairie extends into plains rather than plains into prairies for instance?
Also how are borders managed?
For instance I have 4 tiles with 3 terrains A, B anc C:
AB
BC
If you give borders to the A tile, it's about like this:
123 AAA
456 AAA
789 AAA
But you replace 3,6,9 zones by transition to B, and the same for 7,8,9 so you have:
AAb
AAb
bbb
Or is 9 a transition A-C? Or if the lower terrain was C, you need a specific corner transition?

	20-12-2004 02:30									#132
	Put an end to popups!

It's decided by what's referred to as the 'transition order' (aka. 'Z-order'). I've mentioned elsewhere that it will probably look something like (Mountains --> Hills --> Forests --> Flat) that. I haven't nailed it down completely yet, though. It's a bit difficult to do with the massive number of tile types we're going to have, but once it's done, it's done.

For your example, let's assume that this is the entire map, and that the transition order is A, B, then C.

On the first tile on the first row, you draw 'A', then check if transitions are needed here (since A is the highest transition order and thus nothing transitions into it, no transitions are needed). Draw 'A' and that tile is done. Move to the second tile on this row.

The second tile is a 'B', so we draw B and check for transitions. Here we need to draw the 'A' tile's transition into this tile. A has a higher transition order than B. That's all for here, now we move to row 2.

The first tile on row two needs the transition from the 'A' tile, and nothing more. The second tile needs the corner transition from 'A' after the transition from 'B' is drawn. Thus we draw tile 'C' then the 'B' transition, then the 'A' corner.

We have this (lowercase indicates a transition tile):
A's transitions:
Aa
aa

B's transitions:
-B
Bb

C's transitions:
--
-C

-Edit-

If I were forced to call the transition order and types, right now, for the current tiles we have (mountain, broken, rolling, flat, plain, forest, water, tundra, jungle, swamp, and dunes), I'd place it like so:

Mountain, broken, rolling, forest, jungle (cluster)
swamp (normal, 4)
tundra (normal, 3)
plain (normal, 2)
flat (normal, 1)
water (normal, 0)

Cluster-type transitions don't need a transition order because they do not transition out to adjacent tiles, and can be transitioned into by any tile.

Last edited by alms66 on 20-12-2004 at 02:54

	20-12-2004 10:51									#133
	Get a bigger avatar today!

Just a few quick questions:

1. What's the difference between Mountain and broken?
   
2. Will all terrain types be able to border each other? Eg. mountain - water, mountain - swamp, tundra - jungle, etc.
   
3. Where is the desert?
   
4. Can hills, montains, etc. be forested?
   

	20-12-2004 13:28									#134
	Help yourself to an AD-FREE life

1. Broken and Rolling are two possible degrees of roughness. Currently Broken is actually Broken Hills, and Rolling is actually Rolling Hills. Later, there will be Broken Mountain and Rolling Mountain, rather than the single Mountain we have now, just as there is a broken and rolling hill currently.
   
2. We won't include any artificial limits (as far as I know) though there will be certain combinations which will be impossible, such as jungle and tundra. Jungle implies a hot, humid and densely vegetated area, while tundra implies a very cold, arid and sparsely vegetated area. In the real world, such land types don't exist side-by-side, and so it shall be in Clash, though it will be due to a multitude of variables, not an artificial limit we implement.
   
3. Sorry, I missed it. It was really just an example though, and rather than rework it, I'll just leave it as is.
   
4. Yes, eventually they will, though currently we don't have a tile for it, so the answer at this moment is no.
   

Moisture is one variable that the map generator will use amongst many others. You should take a look at the map generation threads (do a search for it here at Apolyton - sorry, I'd do it for you, but I'm too tired) for detailed info.

As for terrain varying in different parts of the world, I agree completely. A forest in one part of the world is not equal to a forest in another part of the world. It makes perfect sense and, if I get my way , we won't have concrete definitions for tiles, but rather a minimum and maximum value. So, for example, flat currently has 12 food sites and 2 resource sites, in a future version of Clash I hope that might be 10-14 food sites and 1-3 resource sites.