Expansion and Settlement in Clash

[Mark_Everson]

Hi Gary:

Well, I can't see how it could possibly take several weeks to autogenerate provinces. We are not sending Actual people to those provinces, just pretend ones, and their standards for the attractiveness of a place to move into are a bit lower.

For dividing a map into provinces I would think a simple approach would work fairly well. Start at a point that is on a coast or on the border with an existing province. Everything within X ticks of movement by infantry is in province 1. (Picking X so you typically get 10-25 squares.) Rinse and repeat till done. There are of course a few details, like working out around a given province completely before continuing so that you don't get a lot of little few-square provinces. Estimated coding time 3 hours max. If you wanted to get cuter, you could take any annoying bitty provinces that ended up at the edges and have adjacent larger provinces donate 5 or so squares to make the appearance better. I'm not saying that this would be the final way to do it, but it would IMO be sufficient for a good long time.

However, there is a big flaw in the autogenerated provinces idea that I thought of shortly after my previous post. It would work fine for a single civ, but one could easily imagine collisions between two civs trying to populate the same hunk 'o' real estate. And having a minute number of settlers of the first civ to get there being able to have a lock on a big hunk of territory is just too silly to contemplate. (If troops are 'holding the fort' then it seems reasonable.) For now anyway your idea seems a good way to proceed since I've shot down my own favorite . I do think that once a province gets past a certain size that migrating people should start a new one. The size could be of order 20 squares or so for now.

I had always assumed that there would be certain limitations on province size based on transportation and communication technologies and infrastructure. But I suspect implementing those restrictions, provided there's sufficient agreement that they're the way to go, are best left for another day. I will provide a reference to where it's discussed if there's interest.

My statement about missing opportunities with square-by-square migration was meant to echo what I said to LGJ on the topic like six posts above. Specifically, I don't think you can do square-by-square migrations using just adjacent squares, and get anything like real-life behavior. By-square would mean migrations would stop any time you run into a strip of water, mountains, or desert. People are not that easily deterred. If migrations were handled by province-sized areas, then small intervening patches of "dead" area wouldn't shut things down.

[Lord God Jinnai]

By-square would mean migrations would stop any time you run into a strip of water, mountains, or desert.

Well i should have expressed that mountains and deserts, etc would not be counted as far as moving speed in the sence they are 'barriers'. They might not have as many people living there, but that would be true even in a province-based approach.

Rivers i forgot about, but istead of acting as barriers, they should act as highways (they traditionally have) so in that case i'd say the population can move up/down river 2 squares.

I already explainded about oceans and seas.

[Gary Thomas]

In general I agree with LGJ's approach (mainly because it is the same as mine).

There seems to be a difference of opinion on the place of provinces. I know, Mark, that you are busy hard coding the economics model with provinces as a specific kind of ecomony. The administration system is general, and doesn't give any special values to the second level up (the one above map-square) because I always had the notion that a player (or AI) might find it useful to add districts, below provinces, or vice-royalties, above provinces. So I tried to make it general. I sort of assumed that the same approach would follow in the economics.

Anyway, I still regard provinces as an administrative decision, made by each civilization, not as enduring entities outside the control of the player or the AI. So, if a player chooses to have a single province for their whole civilization, they can do so. Alternatively, if they want each province to be a single square, they can do so.

As far as the colonization by diffusion is concerned, I would suggest that newly colonized squares are in a position where they have no actual administration (they can be called, collectively, the Marches), until the owning civilization assigns them to a province. Such squares are notionally "owned" bu do not contribute in any way to the economy of the civilization, until claimed.

I have been consistently against the notion of hard-wired provinces.

Another factor is that there should be migration within a civilization also. If some people from a square leave to colonize the next square, some of the loss would be compensated by movement from deeper in the civilization.

It is pretty important to realize that the population don't give a damn about what province they are in, and their movements will not be influenced by that. Since population is recorded at the square level, all this kind of migration is very easily handled.

As far as crossing rivers, mountains, deserts or seas, one must interpret the expression "adjacent square" in a relaxed fashion. It will be extremely easy to develop an algorithm to cover this.

Cheers

[Mark_Everson]

Hi Gary:

Well, we do seem to get ourselves into quite a variety of interesting circumstances between our respective assumptions and preferences...

Originally posted by Gary Thomas
In general I agree with LGJ's approach (mainly because it is the same as mine).

And I disagree with him for similar reasons. And LGJ, I can just wonder who you'll side with!

There seems to be a difference of opinion on the place of provinces. I know, Mark, that you are busy hard coding the economics model with provinces as a specific kind of ecomony. The administration system is general, and doesn't give any special values to the second level up (the one above map-square) because I always had the notion that a player (or AI) might find it useful to add districts, below provinces, or vice-royalties, above provinces. So I tried to make it general. I sort of assumed that the same approach would follow in the economics.

Well, I don't know of a good solution for this. But I am now seriously thinking of just keeping the economy at the MapSquare level. By the time we have all the infrastructure kept track of at the square level the advantages of handling things by province are less than I originally thought. The only thing I might do at a higher level (according to my thinking of this moment) might be merchants. Perhaps to handle the general problem of administrations not knowing what things are handled at what level, one could have a set of globals that say what levels which things are handled at. These could be read in from xml. I have to admit that having the models being able to do what they need to do takes precedence in my mind over keeping the administration stuff super-flexible.

Anyway, I still regard provinces as an administrative decision, made by each civilization, not as enduring entities outside the control of the player or the AI. So, if a player chooses to have a single province for their whole civilization, they can do so. Alternatively, if they want each province to be a single square, they can do so.

Yep, and I still regard them otherwise. I think the "a single province for their whole civilization" idea that you want is undesirable for the following reasons:

1. If the economy is at province level then in the case of the old British Empire the productive capacity of a globe-spanning power could be used to flash-build tons of military units in, say, Auckland. This is also true if we have a square-level economy and military unit production is pooled at the province level as it is now.

2. The government model has embedded in it the assumption that there will be my sort of province AFAIK. All this talk of distance of provinces from the capital in the main govt doc, section VIII. "Administrating the Empire". If there is one whole-civ province that won't work. I think there are other issues for the govt model, but I'm running out of time, so I'll let Rodrigo speak for himself.

3. I think that unless Nothing in the game is actually done at the province level, there will be varying game results by size of the province that we would need special rules to work around with your approach. Whereas at least with a defined lid on province size (that could change with technology and infrastructure) there would be a limit on the damage that needed to be controlled.

The single-square limit on the small side for provinces doesn't bother me. Its the single-province Mongol Empire that makes me shudder. All the above said, to reduce micro-management I wouldn't have the province size cut-off be too sharp. But past the limit I think small negative effects (the governor is 300km away) should start to accumulate, meaning the player would probably Eventually want to split a province that "too big" (too big by my definition of course).

As far as the colonization by diffusion is concerned, I would suggest that newly colonized squares are in a position where they have no actual administration (they can be called, collectively, the Marches), until the owning civilization assigns them to a province. Such squares are notionally "owned" bu do not contribute in any way to the economy of the civilization, until claimed.

Thanks for trying to be accomodating, but I liked your earlier suggestion better. Seems to me this approach just will require moderately large amounts of micro-management. But I'm not against trying it, since it wouldn't take much to give it a test run and see what everyone including me thinks. And the micro-management wouldn't be too bad for anything we're likely to do in the future.

I have been consistently against the notion of hard-wired provinces.

Well, I don't have much desire for them either... I was just trying to save a pet idea!

It is pretty important to realize that the population don't give a damn about what province they are in, and their movements will not be influenced by that. Since population is recorded at the square level, all this kind of migration is very easily handled.

I agree with this at a theoretical level. But am worried about clock cycles etc. But plenty of time for that later.

As far as crossing rivers, mountains, deserts or seas, one must interpret the expression "adjacent square" in a relaxed fashion. It will be extremely easy to develop an algorithm to cover this.

Agreed, but that is where a combinatorial explosion can begin... But since you're doing the work, go ahead and give it a shot. We can always change it later if it doesn't work out.

[Lord God Jinnai]

Um i'm not aware that we ever fully decided what a 'province' stands for other than groups of squares, ie simple adminstrative tools to reduce clockcycles or actual political devisions that compete wiith each other.

[Mark_Everson]

Hi LGJ:

Yep, looks like we need to have a detailed discussion on what provinces are and aren't at some point. I'll start a dedicated thread that can give the topic the discussion it needs sometime soon. IMO we don't need the detailed spec until after D7 though.

I don't understand what you're saying about provinces competing with each other. In what sense? Like in a feudal civ the different provinces in a civ could be hostile to one another or what?

[Gary Thomas]

Well, I don't know of a good solution for this. But I am now seriously thinking of just keeping the economy at the MapSquare level. By the time we have all the infrastructure kept track of at the square level the advantages of handling things by province are less than I originally thought.

I agree with this approach, provided micromanagement is minimized. In particular, I do not feel that government orders are properly part of the economic model. Implementing them may be, but issuing them is a government matter, imposed on the economy.

I think the "a single province for their whole civilization" idea that you want is undesirable

I don't want that, but it should be an available option. There ought, however, to be a parameter indicating the dispersion of every province, with crippling handicaps if it gets too big. If you say "no, you cannot have your whole civilization in one province" you invite the reply "but I only have one square, how do I split it?".

On the other hand, I feel that too small a province should also be handicapped by a lack of scale advantage, as well as the cost of multiple administrations.

You note here that I use the word "handicap", not "forbidden".

But am worried about clock cycles etc.

Wow, is that out of character!

On another tack (the implementation approaches) we have to decide on what creates a city, as opposed to an inhabited square.

Cheers

[Mark_Everson]

Hi Gary:

Looks like we're more in agreement than it appeared. How do we always manage to do this to ourselves?

I have sent you an email on the economic orders issue.

I will defer discussion of cities until I launch a "provinces and cities" thread sometime this weekend. More fun issues... what makes a city is a tough one.

[Lord God Jinnai]

Originally posted by Mark_Everson
I don't understand what you're saying about provinces competing with each other. In what sense? Like in a feudal civ the different provinces in a civ could be hostile to one another or what?

Well that is one sense and one of the most extreme competitions, but there can be more subtle types for ecomics that are used today. Generally these aren't veiwed as bad as ecomic competition with other nations though.

[Gary Thomas]

We have a minor problem with settler units. The system only allows military units which are part of the command structure. So a settler unit will have to have a command as part of the military structure all the way up to the high command.

Unfortunately this will be required of all units. There is no provision in the code for any mobile units to exist outside the military model.

This leads to a situation where a choice must be made among the following options:

1. Make the settler a military unit.

2. Provide the infrastructure in the program for non-military mobile units (a lot of work).

3. Teleport the settler.

As they say, choose your pick.

Cheers

[Mark_Everson]

1, which was the way I wanted to go in the first place

Settlers, since they would be mil units could have defense and even small attack value. Certainly settlers in the US had non-neglibile attack strength. Also settlers being a mil unit has other benefits. To escort settlers, you'd just make 'em part of a TF with one or more 'normal' mil units.

If you feel strongly that 1 is bad long-term, then 3 is my next choice. The diffusion stuff will be doing that anyway.

[Lord God Jinnai]

Unless only nomads are allowed them, definatly not A.

What do you mean by #3?

[Gary Thomas]

Settlers, since they would be mil units could have defense and even small attack value. Certainly settlers in the US had non-neglibile attack strength. Also settlers being a mil unit has other benefits. To escort settlers, you'd just make 'em part of a TF with one or more 'normal' mil units.

I assumed that the settler units would be armed. The settlers in the US were hugely smaller than a Clash unit of around 5000 people. For our purposes they are better simulated by option 3, since the settlement took place as a very large number of quite small units, this, in effect, is diffusion.

I do not know of any case where a unit sized (5000) settling effort was ever intercepted or destroyed en route, so providing for that possibility is pointless.

My preference is for option 3, on the grounds of reducing non-productive micromanagement.

Unless only nomads are allowed them, definatly not A.

What do you mean by A?

What do you mean by #3?

The teleport option just plants the settlers in the target square at some point after the decision to build the colony is made. There is no actual unit to move.

On another related topic, as far as I am aware, every directed colonization of this type involved founding a city at the site of the colony. I propose that we do that also.

Cheers

[Mark_Everson]

Hi Gary:

Originally posted by Gary Thomas
My preference is for option 3, on the grounds of reducing non-productive micromanagement.

But didn't you Need a settler unit for your preferred kind of start? And also, on keeping things Simpler, I think a Settler approach (just for initial settling of a province) will be both more gratifying for the player, and more intuitive. I think this is the sort of micromanagement that people actually Like (provided it doesn't need to be done more than a score of times in a given game). But since you're doing the work if 3 is where you really want to go, I've got no problem with it.

On another related topic, as far as I am aware, every directed colonization of this type involved founding a city at the site of the colony. I propose that we do that also.

Well, there are cities and there are Cities. As I put forward in the other thread, only big cities should count on the Clash scale, or every square on the Italian peninsula would be a city... But I have no objection with trying it your way and seeing how it turns out. Certainly gives us a way to create cities with minimal overhead.

[Gary Thomas]

But didn't you Need a settler unit for your preferred kind of start?

I had forgotten that. However, thinking about it, the only reason for having the settler at the start is to explore a few squares before deciding where to plant the colony. This could be done in other ways, but then we get other problems (delayed colonization will have to be provided).

I have been working on an extension to the Order system, called a SpecialAbility interface. This will allow a unit which has special abilities to do things like colonize. This is pretty much in operation, so I will go with option 1.

Laurent: I would like to use this system with engineers too. This will enable a gui to give "build" or "fortify" orders. It will also allow some elements (like those in Roman legions) to have the ability to build a camp.

Cheers