quote:

---

Nice discussion, but I would like to see Mark (who is the 'inventor' of this game) to give some statements about what structures do exist / shall exist.
Will there be road / railroad construction?
Will there be tile improvements?
What parameters will a tile have? Which of these would be essential to display and which optional (and which hidden)?

Even a silly question like "will rivers have a direction they flow?" is of importance.

Don't forget: you will have some layers for a tile to display, but you have to harmonize these. If you don't provide space for a structure you will have trouble to put it in later.

I can tell you the 'layers' of PoM in the order of appearance:
- basic terrain
- farms or city
- pollution
- rivers, roads, railroads, maglev
- trees (forest) or buildings
- units
- resources (if displaying enabled)

---

Tile improvements will (all together now...) be largely handled by the people. The government can subsidize this or pay completely for it if the player desires. For instance the people will typically drain swamps on their own initiative if they need the farmland (and the govt has left them enough after-tax resources to do so)

Tile/square properties are still somewhat TBD. They include land type (visible) economic development in the various econ sectors (alt map? or tooltip?). We might have an elevation number but not show it. (This would facilitate figuring out where you can irrigate.) We'll have rivers and their flow direction.

As to layering in display I'd say (and this is subject to change)

-base terrain
-rivers / canals
-roads
-special resources (rare)
-units

Topic is open for discussion...

Will you have enviroment pollution?

I see no 'external buildings' like mines, fortifications, cities... I remember you wrote something like there will be no explicit cities, a province may contain up to hundreds of cities or so.

Peter

It says right in my post that the player (aka government) can set out and built roads and RRs. Just if you don't, the people will probably do it themselves after a while.

Pollution should be there, I just don't have clear thoughts about it yet. My opinion is it should Not show on the main map, but should be investigated in an alternate map... The people should definitely respond to it though in terms of health etc.

Mines are just a local improvement. I don't think we want to show it on the main map, just on an alternate econ one. A major coal mine for instance would show up as a special.

On all these alternate maps I don't know exactly how to show them. I'm sure it will make Dominique ill if I suggest we just use a color code to show population density or industrial development. So I am open to suggestions on the presentation of alternate information that should be available to the player.

You were right - the idea makes me ill... on the other hand...

You know, the idea of different map modes is not exactly new. Problem is that you often just see one source of information at a time and are forced to switch back and forth. On the other hand, showing too much at the same time clutters the map (which indeed makes me ill ) and makes the map too hard to read. Again, I think "optional" is the keyword here - and your color code could in fact be done:

Let's say our "normal" map is done in all colors needed to represent a nice map, with clearly identifiable terrain etc. Now, when clicking on the "economy button", one could fade out the color from the map (making it greyscale) and overlay this with the color coding. Effectively you'd have tiles tinted in the colors corresponding to certain values while still seeing the greyscale landscape (which should be recognizable, still).

If our coders can manage to extract the grey values and tint any given tile with the appropriate color (filtering again), you can have hundreds of color values if you want.

The only thing I'd like to mention is that (afar from game aspects) a hex map would look much better since you otherwise have differently colored boxes near each other whichs doesn't look too professional (the art of doing good game graphics often lies in hiding the fact that nearly everything consists of rectangle regions, in the end).

A compromise?

By the way, talking of terrain, layers etc., it wouldn't hurt if one could switch every single layer on/off.

Layers on and off would be ok.

On the Gray-map idea. I think it is good, but rather than color-coding the whole thing how about little color-coded symbols on the greyed map. suppose I want to see population and industrial production. We could put a number of "gold" people using a log scale. one means up to 10k, 2 means 10-50k, etc. For industrial production you could do blue smokestacks or whatever, again on a log scale. Anyway, little images in log scale on a grey background lets you look at a few things at once and might give good effects. The log scale means you could use the same thing thruought the whole game, with maybe 10 little figures being the most you'd ever have.

Have I made you ill yet again or no? If not I'm obviously not trying hard enough

If you do a grayscale then you want to make sure that you do the conversion correctly. Green is brightest, red next and blue is dark, they are not all equal. You might want to be able to do an intensity graph with color. Sim City for Super Nintendo had it for things like crime and population density. You could either throw a primary color onto each aspect that you want graphed. Thus the player could drag population into the red box and farmland into the green box. Then the map would be tinted red green and all the yellows between. Since brightness would be based on the actual map you would have to use saturation.

If you go with an icon system where you pile icons onto squares you would need a on/off switch for each layer.

As for colors 256 is extremely strict and hard to deal with. One person might be able to keep himself to 256 with a little effort but Mr.A's 256 colors won't be the same as Mr.B's.

Also clash is going to be isometric I suggest using narrower diamonds than civ2. Civ2 just looks uglier and flatter than civ1. Since wider diamonds tip the terrain you notice the lack of elevation more. For example if you make the width three times the height you get the idea that you are looking out across your land. If there is no elevation then it just looks bad. If you do a top down view you can't possibly depict elevation so nothing is missed. So avoid making the diamonds too wide.

Also I was just curious as to the target resolution. It will only look right on one resolution so that should be decided on. I suggest 1024x768

I'm glad I find someone here as concerned with the graphical aspects as I am

The idea with the saturation map showing 2 aspects at once is good (would be even better if the player can decide whether he wants just one or 2 aspects shown at the same time).

Mark:

No, sorry, no sickness this time
But I see the big dilemma arising: While you seem to be an information grabber (wanting as many info on screen as possible), I'm more the "intuitive player", meaning I'm satisfied if I get a rather crude, nevertheless correct FEELING of what's going on. In an epic game, you DON'T want to analyze numbers all the time. That was IMHO one of the biggest mistakes of Activision when doing the interface of CtP: They forfeited Sid's great idea of rows of icons representing resources and showed (wonderfully exact) numbers in the screens. Bah! No more casual glances which tell me "everything's fine here", but instead reading, analyzing, calculating...!

Of course I noticed that you want to include mini-icons instead of numbers on the "economy map" etc. But on this overview type of map it's IMHO essential to give the player a QUICK, not necessarily exact information. While little icons are VERY fine if presented in decent numbers, having, say, 12 x 12 map tiles with icon information in EACH is not easy to read. Again, I'd say "Make it optional". In a long game, most people will prefer the color coding variant, especially the dual-colored version (e.g. production vs. crime on a red / green scale overlaying the greyscale landscape). Fewer is more here, really!

Glak:

The problem you pointed out with the palette can be overcome - e.g. we simply could use the (excellent) AoE palette. But I see the big problem of needing lots of graphics professionals to draw visaully appealing images when confined to 256 fix colors.

As for the diamond width, I fully agree

Screen size: I'd say design it for 800 x 600 +, 800 x 600 giving you the bare minimum (leaving out some eyecandy and reducing the map by 2 tiles in width and height each).

In the first layout attempt for the screen / interface, I came up with the following numbers, based on 800 x 600 flat map:

11 tile rows
11 tile columns
each tile 48 x 48 pixels

I feel that an odd number of tiles is best for centering reasons. Also, 48 x 48 pixels (maximum zoom-in) should be enough for decent graphics.

Do not forget that in 3D-view, units won't be confined to their respective tiles' (diamond's / parallelogram's) area, but will most often overlap some part of the tile above it.

Paint program:

The most modern version of Paintshop Pro (5.01) is able to work with alpha channles. Since I work primarily with Corel PhotoPaint and Adobe Photoshop, I can't be of any assistance as for how to do it with PSP, sorry. I never liked it's interface...

Welcome back! Yeah the different-color maps sound interesting. We'll have to see how it looks. And D has already beaten me up on the 256 color thing ... Some of the more detailed suggestions are good, but we need to figure out the Big things first.

On-off switches for each layer is good.

Dominique:

I had no intention to 'hide' the tiles on the map... Provinces will be, as I see it, a collection of tiles on the map. The economy and some other things only function on the provincial level and up, but that's another aspect of the game.

Neither of them is wrong, it all depends on what really is important in a game. And if I had to say a word in this, micromanagement on a level where you indeed have to study a specific tiles' resources should be unnecessary. Clash is to be a game apout empires through the centuries. Now imagine you are a (immortal) leader - would you say "go hither and dry that exact swamp at the foot of the hills"? Or wouldn't you rather say "go and dry some swampland" and leave the decision to the peasants?

I see several benefits in the latter approach:

a) the spare time you get by NOT having to care for te tile-by-tile optimization can go into other aspects of the game, thus making Clash differ from CIV.

b) if we do not have to stick to a rigid square layout visually, the actual map can simply be nicer. Again, I refer to AoE: It uses a map grid, sure: Do you actually SEE it? No. It looks great, doesn't it?
After all, we want the player have the feeling to rule an empire, not to watch on a computer-generated map.

Personally, I've long pondered the possibilty of a TBS comletely WITHOUT visible squares, especially as far as movement is concerned. It is not that difficult to go down to exact pixel positioning for units, even cities and other things. This would improve movement realism as well as several influence modifiers (e.g. sight range wouldn't be "2 tiles" but a "100 pixel radius").

Sorry to be a wet blanket, but I'm very good at it .

I'm aware of the fact that "real" tileless programming isn't feasable. Tiles are necessary at least to define parameters like type of terrain etc. Even if one would do this on pixel level, this wouldn't be any change, since pixel aren't anything different from tiles - just smaller.

No, I suggest "tileless" methods for two things only:

- movement
- ranges (as in viewing range, distance bombards, or e.g. range between 2 cities).

In effect, this would lessen the very crude effect on realism tiling has. The only thing one has to keep in mind is to have ranges for most actions, e.g. two units battle not when they enter the same tile but when the get into each others' combat radius (this would be a fabulous playground for adjusting combat values, giving units with a longer range - not bombardment, mind you - a combat advantage).

Coding shouldn't be influenced too much by "tileless" rules: Most things will refer to the (still existing) tiles anyway, e.g. the terrain type. Exact unit coordinates could be done by micro-grids, i.e. the position of a unit within a tile (or simply by using a larger coordinates system, deriving the tile coordinate by simply diving by the tile size).

Visually, this would certainly improve the game, especially if you think of units moving along given paths (NOT just sliding tile by tile).

One more point comes to mind: Using the tiles in every aspect of the game is the reason for some very unsatisfying "big steps" where finer steps would be more realistic and would have a very balancing effect on the game - consider e.g. movement: I always thoght that giving a unit movement points for a tile system was highly unrealistic because of the limited size of the map. Minimum movement even of a slow unit must be one tile, maximum movement of a fast unit clearly must be much more... but using tiles you only have the option of 2,3, etc.

Now let's say a pikeman unit could move 48 pixels / turn (if we say 1 map tile is 48 x 48), then a heavy cavalry could move e.g. 72 pixels, which is clearly more but not 2 full tiles. Much finer (and more realistic) steps would be possible.

Another thing (just to show what's possible with this): In one thread in the CIV3 ideas forum someone sugested cities should occupy more tiles when growing. Hm. Certainly realistic, but hard to do if you have tiles representing hundreds of square miles. Using pixels as measurement, however, a city's radius of influence could grow for, say, 1 pixel per 100.000 inhabitants (or whatever).

I thaught I could get you realism freak with that one...

First, I neglected to respond to an important point in your previous post. It is indeed our object to have the player virtually never have to deal with a single tile. Main roads, canals and such, when done by the player, should be drawn on the map by the player and assigned a priority. The main areas where this principle needs to be violated are:

Military tactical-level manuvering when the player want's to do it.
City placement
Fortresses, in the age when they are quite expensive (eg "star forts")

Unless I'm missed something these will probably be the only areas that involve direct player attention at the single-square level.

D & M:

On the movement on a sub-tile basis...

But the Whole Emphasis of Clash is Strategic, rather than tactical. The things that you talk about are really effects that should go into a tactical mini-game for battles. I realize that square-size effects are somewhat irritating, but I don't think we can solve all the little problems with such games. The point I'd like to raise is that fraction-of-a-square amounts of movement should virtually Never decide an important issue in Clash.

On the graphical richness question, We can have varying size urban images with respect to tile size already. IMO this has nothing to do with sub-tiles. I agree that movement is more attractive and fluid when done at a smaller scale. Maybe we can use some 'trick' on this issue to make things more visually appealing.

I Really don't think we need this, but if everyone else in the project has a view contrary to mine, I think I'd have to trust all of your judgements. Dividing up the tiles for things like movement does have some advantages. We'd need to look into the ramifications on the movement AI code that is already written. I would propose that, If We Do It At All, It be on the level of dividing the tile into nine segments. This would change movement rigidness down to the 1/3 tile range which I think is Plenty good enough.

maybe I didb't exactly express what I mean - let me try it from a different angle.

I definitely see why you resist the idea of breaking up the tiles - it could (from your point of view) indeed result in some problems. Now, let's turn the baby around:

Let's say the basic distance unit for the game is ONE PIXEL ON THE MAXIMUM ZOOM MAP (manurein, the thing with zooming out is just a matter of rounding the numbers). Then "terrain tiles" are not more or less than a simplified model for a group of e.g. 48x48 world pixels.

In effect, movement and ranges can be determined via the pixel measurements (being the most exact thing the screen can offer), while things like statistical values, amounts of resources etc. are done on tile level, the tile graphics showing the predominant terrain type (which is rather realistic, I think).

Btw. one thing YOU mentioned, nameley the player being able to "draw" roads etc. would be necessarily depending on the "crude tile raster", otherwise the graphics would need too much processing power, I'm afraid. So it would end up in connecting defined points (centers of tiles) again. Since you assume (invisible) minor road systems being built by the peasants anyway, this degree of abstraction is certainly acceptable, meaning the player only expressively builds the "highways".

My primary concern with tiles is the world size: Let's take a typical large CIV2 map (50 x 80 tiles). Doing everythinh based on tiles here means a unit can move a minimum of 500 km/turn. Not only that: Each decision you make concerns 250.500 kmē at once. Would you call this realistic? Well, it MIGHT be acceptable as a rule to simplyfy the game and speed up gameplay, but it has the sad effect that as soon as you need to implement some quantitative improvement on any distance value, you have to go up to e.g. 1000 km/turn at least. There's no "slight speed advantage" or the like.

Sure you are right that many of these points are true even more in a tactical simulation. On the other hand, what is the engagement of two enemy unit on the map else than an abstraction of numerous tactical battles? So, even if longer ranging guns are of tactical concern, this IS an advantage which definitely should be reckoned with on the strategic level, as well.

Hey, you're Supposed to meddle, your name will go "on the box" too! Right now I'm thinking of 100km tiles (about 320x200 map), so the lumpiness is not as bad as you suggest. Whether we can cope with this map scale and still have the game playable is of course another issue. So you may be right in that it could end up more like you say.

For example 320x200 =64k tiles. So to paint the full map, you'll need to process 64k * n tile overlays. Over in another thread, I saw 20 terrain features. That would be 1.23 *MILLION* decisions about what to put on the display. That is a lot to do just to display the map.

If you go to a pixel level map, you'll need an entirely new way of deciding what color to make the particular pixel. Part of road? canal? mountain? all 3? If you can store that data in just one byte per pixel (@32x32 / tile). That is 65 MEG pixels. So, 65MEG of data storage just for the terrain info.

Also you'll need a way to address each pixel. It's ok to say draw a road from 'here' to 'there'.. but give the program a way of addressing each pixel. Maybe a 4 dim array would work (320x200x32x32).

Better decide on the "how" before you dip down to the "what" on this issue, I think.

---------------
All that said, I *love* the idea of non-tiles. Maybe we just change the pixels on the map graphic when it changes, and rely on it never getting screwed up. How to keep track, tho, of what terrain features are where on the graphic map?

Good points. Like I said the targeted map size may just not be feasible.

But the plan was never to sub-divide the tiles into pieces graphically. As Dominique says below (and I think was stated above) he was just talking about a fine scale for movement.

-Mark

Assuming you get 15x15 tiles on one screen, this would be 225 calculations. As far as terrain graphics are concerned, this number would stay the same (and, yes, add 225 for each layer of roads, improvements...).

The only additional thing would be the exact position of units.

Well, mostly you're right, of course. the majority of the time it would be some window on the map 15x15 map x 36 possible terrain features [allowing for future "inventions"] is only 8100 decisions to make when drawing the map.. Should be fast enuf.

Even doing the largest map.. 1 meg of decisions or so, would be doable. It would be noticably slow, tho. Just letting your PC do a million of ANYthing --or nothing-- is slow enuf to be boring. But that's only for the whole map, so maybe not a playability issue.

Mostly, I was v. concerned about the enormous amount of data if we go to the pixel level. I would *LOVE* to figure out a way. Even if we 'only' deal with the 15x15 tile display * 1024 pixels/tile you get 230k decisions to have the progam do.

I tinkered with a "mostly"-static method of defining features. Instead of defining for each pixel, instead to define that "feature x goes from point A to B to C". Sort of like vector graphic drawing that the CAD prorams do. My tinkering led to a mess of nothing.

Anybody know anything about this? I do not.

1) "Fade to Greyscale" - Neat

2) Single Hue Color coding - Here's a thought. Rather than use a mix of colors, why not assign each element it's own hue. For example, population would be green (light tones are low density, dark are heavily populated), production blue, happiness yellow, etc. One click of the button and you know instantly what's going on. The advantage of the single hue is that it becomes intuitive. If you see green, you know it's the population map. It's especially conducive to the quick identification of problem areas. To indicate a population-related problem (famine, for example), that square could appear black. Same thing with happiness. Imagine a single glance telling you which cities/provinces are in revolt or on the verge? It sure beats parsing that long list of cities in Civ2 or CtP! Downside: Need to view multiple maps to get the status of your whole empire.

3) Combo Maps: Some subjects may naturally go together on a single map. Example: Population and military units. While most of this map would be varying shades of green, military units could appear as small red boxes, perhaps with a number indicating how many are in the stack (and a different color border if a leader is present). And there are probably other natural combination candidates. (But I'm too darn ignorant to identify 'em!)