Terrain and Improvements to it

[Dominique]

Mark,

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.

(sigh) But in the end, I already have commented too much on aspects of the game engine when I definitely wanted to restrict my input on purely visual aspects. Please forgive my meddling

[Mark_Everson]

Dominique:

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.

Another point is that the movement distinctions between units shouldn't make much difference! Remember, we are basing the game on Armies which will mostly have the same infantry or siege train or whatever as the slowest element. Probably the only ones that would have 'pure' non-infantry armies are early-expansion-phase pastoralists like the Mongols. So the fine distinctions you talk about will generally not matter until battle is joined IMO.

[Druid2]

A practical issue: The more tiles on the map that need to be defined, the more data we will need to deal with.

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?

[This message has been edited by Druid2 (edited May 26, 1999).]

[Mark_Everson]

That's it Druid2, try to keep me honest and on target. But its a thankless task

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

[This message has been edited by Mark_Everson (edited May 26, 1999).]

[Dominique]

Druid2: When, in Heaven's name, does the WHOLE map have to be drawn?

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.

I wonder if this would be a performance issue if it was feasable even on an Amiga 500 using GFA-BASIC...

[Mark_Everson]

I think drawing the whole map does need to be done at some points. But we would have a set of simple pixel/few pixel representations for the different terrain types or whatever you're looking at. So the penalty would be 64k x plotting < 10 pixels per tile. This should be relatively fast, and frankly won't happen all that often on player demand anyway IMO. Zooming the main map waaay out in Civ2 always took substantial time too, but that was probably due to scaling all the tiles on the fly (as you (Dominique) pointed out before).

[Druid2]

Dominique...

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.

Maybe some limited combination:
major map features are defined at the tile level... sea/land/mountain etc.
Others are defined vector-wise.. river/canal/road.

[Kull]

I like Dominique's idea of using the "map view" to see what's going on. A few comments:

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!)

4) Mini-map - Speaking of ignorant, maybe this is already included in the interface, but if not could be another place to accomodate the "Single Hue" maps. I refer here to a small "whole world" map akin to the radar map in CtP. Downside: It may be difficult to distinguish the shadings at this resolution. Combo's could be even worse.

[Dominique]

Maybe here's a good idea (not mine) to be considered. Some years ago, there was a game "Ultimate Military Simulator 2". The game really sucked, but they DID have a very interesting technique of stuffing the world into the memory of an Amiga 500: The programmers used a geographic system in which the resolution was different in areas of interest and in uninteresting areas. E.g. Europe was very detailed, while the African desrert was relatively crude, which reduced the overall memory need to about 1/4.

But, again: I do NOT think that a per-pixel map is useful at all for most considerations. After all, a pixel is exactly the same as a tile, just smaller. The ONLY aspect where I really would like to see a tileless is placement / movement of units. All other things could still be based on tiles.

[Kull]

Hmmmm. This was supposed to appear under "Logos" (and it does, now!)

[This message has been edited by Kull (edited May 30, 1999).]