Expansion and Settlement in Clash

[colorrr]

Originally posted by roquijad
within-civ:
For each province you compute a very simple index to define its attractiveness. Something like PCI_per_capita*incentives/land_utilization_ratio. You then find the least attractive and create a settler there composed with a fraction of all EGs present. You teleport it to the most attractive province and distribute the population there with a "smart" mechanism.

I don't think there should be only one migration per provice per turn.

This is my vision of the immigration model:
1. Calculation of each province attractiveness, much like roquijad suggest.

2. For each province a total of people migrating are calculated. This calculation would determine the amount of people leaving the province to seek a better life elsewhere.
Then this number of people are distributed to all the other provinces via a percentage based upon the attractiveness of each one and a dividing factor for distance + any other important issue.
That means each province gets some amount of people from all other provinces each turn.

This is within civs, outside civs I am not sure how to represent this. It could be the same model, and the amount of people to move from one civ to another is calculated in the in-civ calculation by adding another 'logical province' that represents interciv migration with an attractiveness calculation that is based on a little different criteria than the province calculation.

I think that would work very well and it does not seem like a lot of calculations to make.

The distribution of the total immigrated people within each province is another different calculation. Could be done in the same way as with the inter province migration. The people are distributed according to a simple attract factor.

Color

[Lord God Jinnai]

my thing is there should be 1 migration per square per turn...there may be an exception in a mass exodus situation hwhere the population flees in all directions.

I think its best to do it by square since non-forced migrations didn't rtavel very far very fast. There were exceptions, but these were usually massive migrations which would haveto already probably be handled speacially.

[LDiCesare]

I like colorrr's proposal more than rodrigo's. As I said, one mugration per province per turn is too limiting. One per square per turn is acceptable.
We could compute targets as provinces, and inside the provinces, dispatch to the coresponding squares. Foreign provinces should be considered only if known by the civ. I am not sure it is worth complicating the algorithm by making a pseudo-province for foreign civs.

[Mark_Everson]

Hi All:

Color's proposal seems workable in general. I repeat that when we move the economy up to the provincial level there is Really No Point to having migrations done on a square basis. Any differences at the square level within a province would in general be lost in a few turns anyway. If we do things at a province level we can consider many potential target provinces in a reasonable way. At the square level a combinatorial explosion will make distance cutoffs critical. FE at the square level if each of 1000 squares considers 1000 possible targets (crudely meaning targets on the same continent) that is a Million evaluations. The player doesn't get much out of this!

My proposal would be that migrants are shared among cities (if more than one) in the target province. If there are better opportunities out in the rural regions of the province, then the intra-provincial economic-driven migration will take care of it in short order.

The only problem with this is if there is land that isn't partitioned into provinces. IMO there can be a default partition for such land into provinces that is done automatically. But in most cases in the developed Clash game there will already be people there in civs or minor civs, and thus provinces.

[Lord God Jinnai]

Originally posted by Mark_Everson
Hi All:

Color's proposal seems workable in general. I repeat that when we move the economy up to the provincial level there is Really No Point to having migrations done on a square basis. Any differences at the square level within a province would in general be lost in a few turns anyway. If we do things at a province level we can consider many potential target provinces in a reasonable way. At the square level a combinatorial explosion will make distance cutoffs critical. FE at the square level if each of 1000 squares considers 1000 possible targets (crudely meaning targets on the same continent) that is a Million evaluations. The player doesn't get much out of this!

I think here your overcomplicating things...if we make it so that people can only move to ajacent/diagonal or costal squares (if the parent square is also on a coast) within X amount of space, then there are far less possible compuations.

Again this doesn't apply to rare special cases so we can bend the rules in those cases we need to.

Plus this makes for more interesting games for people who want to atleast in some areas or who have small civs get more detailed.

[Gary Thomas]

I rather feel that, historically, there were two kinds of colonization. These could be called "diffusion" and "spot colonization".

In diffusion, the people in a square will occupy any suitable, adjacent, lower population density, squares.

Spot colonization occurs when a power block (usually the government) or a dissident ethnic group (often a religious group) sent a colonizing group to a relatively distant point to set up a colony.

The way in which these operate is different, but I feel that both must be catered for. Both have been very important in world history.

Cheers

[LDiCesare]

Gary, LGJ, you are both right. I believe that LGJ's approach is good for non-supervised migrations. I think it should apply at province levels with repartition in squares if needed. Checking these migrations would be done every turn. The other kind of migrations, leader-endorsed, would just mean adding a distant square/province to the list of available destinations inside one's civ.

[RM]

Hello.

A suggestion: a square could be selected as a colonization center, and then the surrounding area (perhaps a circle?) is settled, more densely around the center, and thinning out the longer away from the center you get. Squares of special economic value and surrounding squares are also a bit more densely settled. Deserts are left almost empty.

Perhaps the effect will not be much different from settling entire provinces, so it might not be worth it to implement this suggestion, but I think economic and geographical circumstances often had a greater impact on where settlers choose to live, than how the government had divided up the land in provinces.

Btw. I liked demo 6. I think it will become a great game.

[Mark_Everson]

Hi RM, and welcome to clash! I am still hoping the provincial layout can be made "reasonable" enough so that things like your suggestion wouldn't be necessary. But we'll see. And thanks so much for the positive feedback on the demo!

Hey LGJ, I just don't think square-by-square is either adequate or efficient. The reasons are still those I mentioned above. I don't think you can do square-by-square using just adjacent squares. That would mean migrations would stop any time you run into a strip of water, mountains, or desert. Basically everything except military combat is geared to the provincial level. I just don't see any strong case for square-level migrations, and at best opinion is divided.

I agree with Laurent's short summary of how it should work. Although I think checking every turn may be overkill. But that is just a detail that we can work out later. I certainly support Gary's statement that we should have available to the player Both the people diffusing on their own (with or without inducements), and also the grandiose generalisimo being able to tell people Exactly where to go .

[Lord God Jinnai]

Well imo migration via province will ultimatly cause more problems than it solves. When you redistibute province size, however you do so, you need to know how many people are in each square. Also when transfering via province in the beggining might not make much of a differance, but later on you may have super-provinces which could span virtually entire continents. It also complicates things as we have EGs linked to the squares. If they are in multiple squares and some move to another provinces, you then need to make calculations to see which ones moved from where and by how much.

There are plenty of other reasons for using it, such as maybe deviding a province by enthnicity for revolts or whatnot, the fact there may be multiple cities and the migration of the population toward them and away from them in rare cases, etc.

Really i don't think we should skimp here and put it at the province level. The comp time, is less than what would probably be used for military and there are many people like me who would feel jipped at seeing the military area get the heaviest focus of detail when it comes to comp time and detail level.

[Mark_Everson]

Hi LGJ:

Originally posted by Lord God Jinnai
When you redistibute province size, however you do so, you need to know how many people are in each square.

I don't understand where you're coming from. We ARE keeping track of the people by square! Just about every issue you raise in your post is not an issue because of this false premise.

Really i don't think we should skimp here and put it at the province level. The comp time, is less than what would probably be used for military and there are many people like me who would feel jipped at seeing the military area get the heaviest focus of detail when it comes to comp time and detail level.

I don't see why we can't enable players to micromanage migrations at the square level. All I was talking about was the Default method for handling migrations, which I still firmly believe should be handled at the provincial level. Then, following migration, the people will redistribute themselves to squares within the province as they find them attractive. A player might gain some small transient advantage from doing it at the square level, but I'm hard-put to understand why it would be worth it. But one person's micromanagement can be another's fun .


A side note:
I am assuming that members of a given EG will prefer to be togther for intra-provincial migrations since it is both a real-world effect, and can also keep down the number of EGs that an average square will need to have. What do people think?

[Lord God Jinnai]

Sorry, but it seemed you were saying that with very few exceptions all calculations would be done on the province level.

well if the default is the province level for keeping track that is fine, but that shouldn't disclude intra-province or square-to-square migrations, just the display of them for the player. Intra-province migration is in fact the key to the creation of many cities. I just think only calculating them at the provincial level will cause to many irregularities for the computational time you think it will save.

As to EGs tending to live together, i think that's a good idea, so long as encomic and social conditions allow legally and have descent oppurtunities. IE it shouldn't restrict some of them from moving because the grass is greener on the other side.

[Gary Thomas]

The actual implementation of this is getting quite close. This puts requirements on the model. The first thing to be decided is "How does the game start". CivX (menaing Civ1, Civ2, Civ3...) has a settler unit wandering around. If we take that approach, then it follows that we have to have a settler unit. The alternative is to have some people living in a fixed square, and start from there.

Some pros and cons:

1. Settler unit.

In favour is the fact that the player has extra choices, and can decide to start the civilization in the preferred terrain or position. It also gives the possibility, later in the game, of creating settler units and having a directed migration or colonization. Also the system does not exclude the method of colonization by diffusion.

Against is the fact that we have a rather odd unit added to the game.

In passing, I do not think that the settler unit should be militarily helpless. If you attacked 5000 migrating huns, you wouldn't expect them to just lie down and die.

2. Fixed possition.

In favour is the fact that the mechanism is simple.

Against is the reduction of options.

Personally I prefer option 1.

Settler units should have the option of being mono-ethnic, and have the possibility of being spontaneously created, and not necessarily under the control of the originating civilization.

As far as diffusion is concerned, any empty or sparsely populated square which is not owned, and which is adjacent to a square owned by a civilization is fair game, and will be colonized, if there is surplus population to do it, and added to the province of the adjacent square. If there is a choice of provinces, add to the province whose centre of gravity is nearest to the capital.

Cheers

[Mark_Everson]

Hi Gary:

Either 1 or 2 is fine by me. Just so long as doing the settler unit doesn't turn into a weeks-long project that is...

Originally posted by Gary Thomas
As far as diffusion is concerned, any empty or sparsely populated square which is not owned, and which is adjacent to a square owned by a civilization is fair game, and will be colonized, if there is surplus population to do it, and added to the province of the adjacent square. If there is a choice of provinces, add to the province whose centre of gravity is nearest to the capital.

How do you define surplus population? There is no such thing in the econ model at present. People can always be used in economically useful ways. There will need to be a (simple for now) evaluation of the economic drivers for migration. Your approach is also guaranteed to result in enormous provinces quite quickly if we start with an empty map. I guess some simple rules could handle that.

I still think its more satisfying overall to do province-based migration with automatically-generated provinces if needed. Requiring an adjacency to allow migration will result in the people missing too many opportunities IMO.

Cya,

Mark

[Gary Thomas]

I still think its more satisfying overall to do province-based migration with automatically-generated provinces if needed.

I cannot imagine code to generate provinces being any easier than my old favourite of randomly generated terrain. At a guess, I would suspect several weeks coding and an unsatisfactory result.

Requiring an adjacency to allow migration will result in the people missing too many opportunities IMO.

What sort of opportunities?

Cheers