Command and Control

[Mark_Everson]

Hey Gary:

First, a big request! Please don't Do any of this unless you let me know you are going to, and I have sent you my latest econ code. Otherwise we will have one of those code change collisions I will be working most of my day Sunday I hope, and will send you whatever I have Sunday evening, and then you can have several days to rearrange things if you want since I'll be unable to do serious coding for several days at that point.

I don't have any problems with the basic plan. We've discussed much of this before...

I'd say definitely put Regions in at this point. I don'k know for sure if we'll need them or not, but I expect they will be a big help.

I can't think of any obvious objections to the MapSquare being isolated idea. But please think about the yet-to-come ecology model before making this final. Then again if its a problem we can just connect them more directly agian if necessary.

[Gary Thomas]

First, a big request! Please don't Do any of this unless you let me know you are going to, and I have sent you my latest econ code. Otherwise we will have one of those code change collisions I will be working most of my day Sunday I hope, and will send you whatever I have Sunday evening, and then you can have several days to rearrange things if you want since I'll be unable to do serious coding for several days at that point.

I will not be making any changes at all to the D5 code. However, I have been changing D6 code (you understand that both of these are in the ClashD5 game directory, in line with one of my earlier suggestions). At present my code doesn't compile because of the very matter we are discussing here. I hope to have it all tidied up in the next day or so.

I'd say definitely put Regions in at this point. I don'k know for sure if we'll need them or not, but I expect they will be a big help.

See my next post on this thread.

I can't think of any obvious objections to the MapSquare being isolated idea. But please think about the yet-to-come ecology model before making this final. Then again if its a problem we can just connect them more directly agian if necessary.

The ecology model has no direct effect on a map square. A map square is exactly that - a notional area on a map. It has a reference to a TerrainData object which is rather carefully designed to be in line with the ecology model. When the ecology model has components other than purely descriptive, that can be readily incorporated.

I will describe my final suggestions for implementation government control in another post.

Cheers

[Gary Thomas]

Deep cogitation has led me to the conclusion the the Civilization class should not be part of the government chain, but should stand above it, and include a highest level government object in the same way that it includes a highest level military command.

I also think that the number of levels of government (and their names) should be set by the scenarion, in exactly the same way that they will be done in the military. They should also be modifiable as technology and empire size changes. There is not a huge justification for Province and Regional governments when the civilization consists of a single village.

Cheers

[Mark_Everson]

I hope you'll forgive me if I don't accept 'deep cogitation' as a sufficient reason to change around a major class like Civilization... Can you give me some better reasons?

I will hope the change you're going to in the govt area can be done without massive bugs. I guess the econ model will be one test case of how the new sytsem works!

BTW I will send you the current econ code in about seven hours, and then you can go ahead and integrate and shuffle to your heart's content. Do you want to do the game.econ type changes too while you have pretty much the whole code? (Need to hear from Laurent on this).

I will copy the previous para to the D6 planning thread where I guess it really belongs.

I actually have moved all my code to a ClashD6 dir already, but that's a trivial change. I'll just replace it with the new stuff when available.

Let me know what else you need to discuss before the drums crash and the cymbals clang.

[Gary Thomas]

My reasons are that Government is only part of a civilization. All the other aspects of the civilization (culture, religion, military and so forth) are not part of government. Government is just one part of the whole thing, and should, therefore, have its own class. I do not like the way in which the Civilization class, which has a very real and important function, is being contorted. If the Civilization is synonymous with the Government, it is equally synonymous with High Command and should implement the Command interface also.

I am not actually planning to change the Civilization much at all, just add another field referring to an object that implements the GovernmentEntity interface.

The reason for this is that I would prefer that all the government objects have the same structure, since their behaviour is similar. This, incidentally, is what the economics classes do already.

Without a detailed examination, I would think that the only change to Civilization is to make a Government object implement GovernmentEntity, and have lower levels of government link to that object.

The real change will be to Province. It becomes just another Government object with a name determined by the scenario ("Duchy" or "Khanate" or "Colony" for example, or all three). It contains a list, not of squares, but of the lower level of government objects.

There will also be a government object attached to a single MapSquare, which will be the part that implements GovernmentEntity.

Again, following the principle of separating control from physical objects.

It also gives much more flexibility in reassigning the geographic component of provinces.

Cheers

[Mark_Everson]

Ok, thanks for the explanation, I'm fine with all the positions in your post. I was picturing a masive wrending of the current Civ class into multiple smaller Classes, which is why I wanted more details!

[Gary Thomas]

All the administration material is now coded into the D7 code. So I thought I would hijack this thread (I suppose I am entitled, since I started it) on a closely related topic.

In the D7 code, every square is in one of two states: unowned (independent if you like) or part of a province.

The handling of squares, in both categories, is pretty much in hand.

The problem arises when some obnoxious general invades and occupies a square in your province (or maybe you do the same to him).

What exactly happens? The square is still in the province, which you own. But it is a bit unreasonable to claim that you control it, if Hannibal has his entire army there, and you have no troops at all. On the other hand, if he controls it, what province does it belong to?

Are there any opinions on this subject? There better be, because until it is resolved, D7 will stall.

Cheers

[Mark_Everson]

Hi Gary,

As far as I can recall we adopted your preferred method. Specifically, of keeping provinces static for long periods of time, and when squares change hands they remain in the same province but get their orders for from a different "chain of command". In this case a different set of provincial orders put in by side A who now controls the square, rather than side B that used to control the square. Control is determined at the square level by some TBD procedure.

Pending further discussion I think it is sufficient to have the last civ that had an uncontested military presence in the square being the one that "controls" it. That is essentially the definition that has been used up until now. This may not be the ultimate solution, but I believe it can take us quite far. The riots model will have the people eventually rebel if there is no military presence, and they don't like who they are under. We need to figure out what geographic scope a garrison can have for suppressing rioting and other important factors. But that's a discussion for the social model...

I have just noticed that in a post above I stated that although simple military control as described immediately above is my preference, you can go ahead and do something more nuanced if you'd like. So if you want, go ahead and use whatever your preferred approach is, just let us know what the details are. And I'm assuming it won't ignore obvious military reality too much

Is this sufficiently detailed, or do you need more?

OK with everyone? Nobody objected to my previous statement that Gary could try what he wanted to...

[Gary Thomas]

As far as I can recall we adopted your preferred method. Specifically, of keeping provinces static for long periods of time, and when squares change hands they remain in the same province but get their orders for from a different "chain of command"

Nope, my preferred method was for provinces to be completely arbitrary and at the control of the player or AI. On the other hand, my map square level administration was more in terms of influence, ranging from zero to a hundred percent, so a map square could have more than one administration. To do that, we had to divide map square economy up, so that there were only government related things in it, since each square could now have more than one economy, or, alternatively, ensure that the map square economy was independent of the administration in question, in which case numerous adminstrations could interact with the same economy.

Making the modifications to MapSquareEconomy turned out to be beyond me, so we now have a situation where MapSquareEconomy controls the square, and a MapSquareAdministration is the contact between governement and MapSquare economy, but each MapSquareEconomy has a single administration link, and hence a single owner.

So it isn't my model! The model I had in mind would have coped with the present situation very easily, but my control model doesn't fit in with the economic model.

One solution we could adopt, now that the administration system is very flexible is to call Hannibal a province, give him an administration, and attach any squares he captures to it, reverting when the Romans re-occupy the square.

But definitely, long lasting provinces was never my idea or preference.

Cheers

[axi]

Occupied squares or squares with riots going on should be "problem areas" and those who share a common owner (civs, tribes)and occupier (civs, rebels, pirates, nomads) should be united under a provisionary "military administration", meaning no public spending except mlitary infrastructure (but no unit creation) and no taxes. All policies should be set by "martial law" by the ruler with the appropriate PAFs however (and a factor for suppression of them via the presence of occupation forces - even in internal problem areas like rebel provinces). Tolerance against the "martial law" should deteriorate as turns pass, leading to the need of attaching the occupied lands into the civ, by negotiating a peace treaty with the owner or by occupying a whole province, in which case you "negotiate with the local authorities" which means that they get attached to your civ, while still remaining a problem area for a few turns. In the later case, if the original civ reoccupies part of the territory, it becomes or remains a problem area, while in the first case it will be normal.

[Mark_Everson]

Gary:

Sorry I misrepresented your point of view on province fluidity. I either misunderstood it long ago, or achieved misunderstanding through the passage of time.

It appears to me that if for the moment we assume influence is either 0 or 100% in a square then the economy will work fine as is. I am hoping this will work ok with your administration code. If not I would be surprised if it can't be made so fairly easily. Essentially any map square's economy can be pointed to by a Roman and a Carthaginian administrative object, so long as only one of them can give orders, and the other one understands it has no power of taxation etc. there. I'm certainly not going to have the opportunity to redo the map square econ in the next week, and frankly think dividing influence on a square level is just too much realism to be worth the effort. Even Having the map square have an economy is probably too computationally expensive in the long run, and as we have discussed it may need to be bumped up to the provincial level. But we can figure that one out later.

For purposes of the scenario, and given my limited understanding of your admin system, and assuming you can set things up as I just outlined (0 or 100% influence) you could:

1. Do as I did in D4 and just make provinces on the fly. Something like 10-20 contiguous squares max for a province and after that you start a new one. Starting provinces are put in by the scenario, and everything else in terms of province structure is made up as it goes...
or
2. Start with the whole map already divided into Carthaginian and Roman provinces. When Hannibal conquers a Roman square it automatically goes into the pre-configured Carthaginian province, and gets orders that way. This has the advantage of getting names historically correct, but is more work.
or alternatively
3. We could start with limited geographical provincial structure for both sides, but that cover the world between them, and assume for the moment that each side will keep the same provincial structure the other had upon conquest. So the first Gallic square that H conquers you can create a C province of Gaul, and put that square in it. Or a mixture of 1. and 3. is possible. The rules would of course would be further refined in the future.

It seems to me any of the approaches above can work for the interim, and in the meantime we can think on how we want to handle it in general.

Cya,

Mark

[Mark_Everson]

Originally posted by Gary Thomas
...in which case numerous adminstrations could interact with the same economy.

[currently] each MapSquareEconomy has a single administration link, and hence a single owner.

To try and clarify a bit what I said directly above. I believe that it can be worked such that the top of you quote is true by having a many-administrations to one econonomy relationship. However, at least for the forseeable future, one and only one of the administrations is active. The active one's orders are pursued fully by the local economy, the other admin orders are ignored. That would change the "currently" part of the quote, and allow for the provincial system I think you wanted, albeit without the subtle influence effects.

[Gary Thomas]

I think I am following what you propose. Do you mean that we have, in effect, duplicate provincial administrations for provinces that are partly occupied, and swap the squares back and forth?

The problem with that is that so much government stuff is in the MapSquareEconomy class. There will be quite a lot of coding to achieve this. Certainly, if the economy stuff is moved to the provincial level, life will be hugely easier.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
I think I am following what you propose. Do you mean that we have, in effect, duplicate provincial administrations for provinces that are partly occupied, and swap the squares back and forth?

That's one solution. I thought it was what you wanted until recently. Arbitrarily arranged provinces are really fine by me. I do think it is a good feature to have fought-over provinces retain nominal pre-fight borders. Whether this will be great or confusing for the player I really don't know. At this early stage perhaps its simplest just to have provinces other than the starting ones arranged on-the-fly by whomever takes them as in 1 above.

The problem with that is that so much government stuff is in the MapSquareEconomy class. There will be quite a lot of coding to achieve this. Certainly, if the economy stuff is moved to the provincial level, life will be hugely easier.

All I think the Economy needs is a way to find where the chain-of-command that owns it is, and be able to look up territory using it. That should be done Directly thru administration. I do not understand what other than the administration look-up needs to be changed to get this working. Please tell me.

[Gary Thomas]

If the square changes ownership, at the very least the GovtEconOrders in that square will change, as, I expect will PublicSector, which is tied to a square, and possibly other similar things.

Cheers