Map Generator Model

[Richard Bruns]

Originally posted by Gary Thomas
Richard, I don't know if you saw my post (which caused Mark to have a fit and start talking about version 50) about micro terrain. The idea is that the terrain actually goes down to some minimum size (my suggestion is 100 m²). However, this terrain is not stored. It is generated as needed using a repeatable pseudo-random number sequence. Thus, going back to the same location has the same landscape. So, in effect, the whole map becomes a grid of 1 hectare plots.

....

As an example, suppose that, instead of having a "forest tile", you have individual trees which are then ramdomly scattered (using the same repeatable pseudo random nymber system so they alway reappear in the same place) over the polygon. This adds several factors not presently available:

I'm a bit confused about this. How does the pseudo-random number sequence remember what changes have been made in the terrain? Wouldn't you have to generate a new sequence every time the terrain attributes change?

But the extreme zoom sounds very intersting. It would be really cool to give the option to have the map zoom in for fights and allow the player to manage individual elements wargame-style. I am envisioning something like the Master of Magic system, which was truly excellent, and if you show how your terrain system allows us to do that seamlessly I think yuo could pick up a few converts. Obviously this is way in the future, but if we have a good foundation iyt shouldn't be too hard to add.

So far I have refrained from mentioning the step after continuous maps. This is three dimensional spline based polygonal surfaces, so a unit will know if it is moving uphill...

It would be great for the aforementioned battles, but I'm not sure if going this far would really be a good time investment. We also have to consider the mod makers; we don't want to make them learnd a 3-D modeling system just to draw a map.

[Gary Thomas]

I'm a bit confused about this. How does the pseudo-random number sequence remember what changes have been made in the terrain? Wouldn't you have to generate a new sequence every time the terrain attributes change?

What changes did you have in mind? I cannot see any likelihood of changing the terrain in a 100 km² area. As far as forest clearance is concerned, there are just fewer trees at every level. The system doesn't "remember" anything, but in its progression to ever lower levels, it does know the settings for the next level up.

Wouldn't you have to generate a new sequence every time the terrain attributes change?

No, you use the same sequence, but the square level parameters change.

It would be great for the aforementioned battles, but I'm not sure if going this far would really be a good time investment. We also have to consider the mod makers; we don't want to make them learnd a 3-D modeling system just to draw a map.

I was at least partially joking, though I did want to register the fact that it is possible.

Map designers do not need to know anything about the coding. If the system were adopted it would need a map editor in which you could, for example, grab a bit of land and pull it upward to form a hill, or push it down to form a lake. All these things are fairly easy to program if you build on the work that has already been done.

Cheers

[Simon Loverix]

So a polygonal system is just a thing to manage *very* much terrain units- I don't think anyone does not want a bigger playground/battlefield. But more squares was discredited before already due to possible lack of computer capacity..
A problem can be when the polygons split too often, you would still have a map of tiny little squares. Or they don't split often enough, and you get a boring map.
The models will also need to be more detailed and less of an abstraction, thus more complicated. Every model will have to be extended.
Micro-terrain would be a good idea, polygons or not. (a pity that it didn't have more tactical consequenses in MoM like in Heroes of Might and Magic)

Generally, I also think it would make the game better and more outstanding. If the necessary adaptions can be done, why not?

[Gary Thomas]

So a polygonal system is just a thing to manage *very* much terrain units- I don't think anyone does not want a bigger playground/battlefield. But more squares was discredited before already due to possible lack of computer capacity..

No, it is the opposite. Where there are a bunch of squares (like an ocean) which are identical, a single polygon covers them all. So you use less computer capacity, not more.

A problem can be when the polygons split too often, you would still have a map of tiny little squares. Or they don't split often enough, and you get a boring map.

I have yet to see a convincing reason why polygons should split much at all. Even if they do, you put a lower limit on size (say 100 km², equal to the area of the current squares).

In any case, squares are already polygons, just awkward ones.

The models will also need to be more detailed and less of an abstraction, thus more complicated. Every model will have to be extended.

This is not at all correct. The models will become less complicated. Instead of having an economy for every square in the Sahara desert there will be one per civilization only. All that is required is a scaling factor (some things will need to multiplies by the area of the polygon).

Cheers

[Mark_Everson]

Gary:

One correction. There will probably Not be one economy per civ no matter how you do the map. The problem is that one economy means that local goods plentiful in one place can go anywhere in the economy. The importance of distance and transport technology is a big effect of real-world economies I want to simulate correctly. England, the States and Australia Never formed a coherent economy even when they were all in the same civ. The distances involved were too large for the transportation capabilities of the day.

However, with some limitations on province size we can get close enough to the real world importance of unevenly distributed goods and resources.

[Gary Thomas]

One correction. There will probably Not be one economy per civ no matter how you do the map.

I did not say that there would be one economy per civilization. I said that the only way the Sahara would be split up would be by ownership rather than terrain. Hence, for the Sahara alone, one polygon per civilization. However, I would expect that there would be overlapping polygons - an overall polygon specifying the terrain, and overlying ones indicating political ownership (or lack of it).

Cheers

[Simon Loverix]

The complexity of any model depends on the size of the smallest unit of data you're trying to model. If the smallest possible polygon is smaller, you need more complicated models.

And for ocean squares, ok. They're the most homogenous area you can find. But for all the inhabited squares, with all the subtle differences that are possible in the models any two squares will almost always differ in several ways; how can you apply polygons to them?

The real world is neatly split up between a few hundred countries. But that's a very arbitrary, artificial difference. Look at the nation-building in Europe: England: natural boundaries. Germany: realpolitik and industry. France: language, tradition. The Netherlands: decision by the Great Powers, etc..

So a polygonal model would most likely end up puzzling the relevant data for a square together from lots of polygons. Now it's more like: apply the effects in the appropriate area to all pieces therein. And if you need information for one piece, look at it. Wouldn't that be simpler?

Finally, instead of having a change of fundamentals again I'd say go for some model-testing and demo-spawning instead. From the information you give it shouldn't be that difficult to switch to polygons from squares. Well, let's wait just a little longer thn and show some progress. Ever since I've been lurking the forums for the first time (about a year ago), demo 5 has only been a few weeks from release..

[Gary Thomas]

The complexity of any model depends on the size of the smallest unit of data you're trying to model. If the smallest possible polygon is smaller, you need more complicated models.

I have repeatedly stated that the minimum size of the polygons will be no smaller than the size of the present map square. Hence, the average size will be greater, and hence the models simpler.

But for all the inhabited squares, with all the subtle differences that are possible in the models any two squares will almost always differ in several ways; how can you apply polygons to them?

This is equivalent to stating that no two adjacent squares will ever be the same in any single characteristic. I do not accept that as a reasonable statement.

Ever since I've been lurking the forums for the first time (about a year ago), ), demo 5 has only been a few weeks from release..

I did not say that I intended to code this soon. I have merely been trying to point out that the objections raised generally come from a misunderstanding of the proposal.

Finally, and again saying what I have repeatedly stressed, squares are polygons. They are just a special and very limited case of the polygon model.

D5 is going through its final pre-testing. It is written and substantially working.

Cheers

[Simon Loverix]

If the minimum size will be no smaller, then a polygon is just a group of terrain units, with the only difference being the shape of the edges?

You will need to scale the calculations of the models for the different sizes of the polygons. Won't that add complexity and calculations?
The models are now assuming as working unit a more or less compact area. The polygons undoubtly won't always be compact. Won't this give problems?

Take population, for example. I'm very sure that any two squares will only coincidentally have the same population in the course of the game.

Looking forward to the demo, hopefully it will make things clearer.

[Gary Thomas]

If the minimum size will be no smaller, then a polygon is just a group of terrain units, with the only difference being the shape of the edges?

More or less correct. However, in most cases the polygons will be considerably larger than map squares. On average, I would guess, about 6 - 10 times as large.

You will need to scale the calculations of the models for the different sizes of the polygons. Won't that add complexity and calculations?

Yes but only in the most minor fashion - instead of having the fact that every polygon is 10,000 km², the area will need to be explicit. Since this is only a scaling factor, the added complexity is extremely minor.

The models are now assuming as working unit a more or less compact area. The polygons undoubtly won't always be compact. Won't this give problems?

I don't see why they should. Anyway, I don't see 10,000 km² as compact. For example Mesopotamia would be only about 8 - 10 squares to cover its 15 or so civilizations, city states in this case.

I have not fully worked out the details of the polygon system. I suggested it so that we could get rid of the grid on the map, so the terrain could be more realistic, so that units could have there position specified to closer than 100km, and to facilitate the micro-terrain idea.

Hovever, I imagine that each model will have its own overlapping polygon system. For example, the terrain of a mountain range doesn't care who owns it. It remains mountainous land.

Take population, for example. I'm very sure that any two squares will only coincidentally have the same population in the course of the game.

This is the heart of the matter. You can equally say that the possible subdivisions of the square will not have exactly the same population, so the square should be subdivided, presumably indefinitely.

My answer is that if we combine two (or more) otherwise similar squares into a single polygon with a population density, and hence a total population, what does it matter how the population is distributed inside the polygon? Any more than it matters how population is distributed within a square? Remember that squares are polygons.

Looking forward to the demo, hopefully it will make things clearer.

D5 has none of this in it. It operates entirely on squares.

Unfortunately...

Cheers.

[Simon Loverix]

My main concern is that, with so many factor influencing each other, with evenso many area's of effect, after a while the polygons will still be split up to their minimum size, in the interesting areas on the map. The difference would then only be shape of units..
A polygonal system is indeed superior for describing static space (like terrain or a map of nations on any given momen).
But in a game like Clash, with many complex evolutions, I fear it would still break down to the minimum units, if they are square-sized. If they had a smaller size it might work, but you'll have calculation problems again then I think..

And with smaller units there can also be changes in the models. For example, I now assume in ecology that a square is capable of maintaining and regrowing its own biomass. With smaller areas this might not be the case.

Gary, have you an example (game) of this somewhere, or an article of something available?

[Gary Thomas]

I haven't yet had anyone give me a good reason for ever subdividing a polygon. If the ai and gui do not give a means of doing so, then there is no subdivision problem. After all, the present system doesn't allow subdivision of squares.

Risk and Diplomancy use polygonal areas in a primitive fashion (with no subdivision).

Interestingly, so did the original Civilization board game, probably one of the best board games ever created.

I do not know of any modern strategy computer games which use the polygon system, That is why I am so keen to use it. Being first is always nice.

Unless you are buying the very first copy of a new Microsoft product...

Cheers

[Simon Loverix]

By subdividing a polygon I mean splitting it when something happens to a part of it, say a flood killing half the population in the east part. When these splittings happen often, and it seems they will, many polygon layers can revert to their smallest parts, and we're back to squares then.
I think a polygon version of civ 3 would work..but as you say, civ was originally a boardgame and still has many such characteristics.

[Lord God Jinnai]

If a flood killed half the people in a polygon (which a square is also btw ) then it would be the same thing as if we were doing it for a square. We'd simply calculate it for the entire square for the next turn.

[Gary Thomas]

As LGJ says, what do you do when something happens to part of a square? Split it?

Cheers