Command and Control

[Gary Thomas]

This thread is a continuation of some issues discussed in Countdown to D5. Since I feel that a full resolution of the issues will not involve D5 I thought it better to have a separate thread.

From Mark:

1. The econ hierarchy now works Directly using the govt hierarchy. I made those changes a few weeks ago with the GovernmentEntity change we went over. I may be missing your meaning here... since at present the only linkage is that each GovernementEntity has an Economy object associated with it. It may be done poorly in the new fashion, but I agree the old econ parallel hierarchy should be history, and from now on economy objects should attached directly to, and derived from the Civilization, Province, or MapSquare they're associated with

In general I agree with the simplified structure that Mark proposed. On the other hand, it doesn't answer the main problem I had. This is that there is no mechanism for a province (or even any part of it) to change hands permanently.

2. I don't have time or brainpower to work on the code tonite, so I will just ship it off to you. I brought back Civ.addTerritory for my own uses, and also modified Province.setControllingCiv and MapSquare.setControllingCiv. It seemed to work, but I think its probably best to just refactor the ownership hierarchy. One thing I am sure of, is that adding a square should be done at the civ level, because the civ will need to choose which province (or a new one) it wants to put the square in. This will become important when we go to a fully-populated map as opposed to the cities-in-a-void we have now.

It is my view that, for D5, we leave it the way it is now.

I have modified the AI so that a conquering army will always leave a garrison, no production will take place, and the mini scenarios we have provided do not really need anything more complicated. This, in turn, means that we don't need to fix it just yet.

I wanted to mention a further fact that's relevant to my post above. I have thought that it would be useful for the player and AI to have an intermediate level between province and the whole civ. Such Regions would be groups of provinces, and would allow for management of economic and governmental concerns at a level more detailed than the civ, but not down to the province level. One quick example would be to divide your civ's provinces into the core of the civilization, and the marches. Or core, border, and recent conquests could be a three-way division. (Border being long-held provinces but that were on the border with a likely enemy. This could allow higher levels of defense spending in the border region without needing to change commands for all the provinces in it.

Personally, I would add the extra command level between Province and map square and call it "District". These districts could change hands quite readily, and I can easily imagine a method of doing so.

One of the difficulties we have is a more general one of command structure versus physical existence which I will comment on in a later post, since it has wider implpications.

The possible future inclusion of such a feature is IMO a further reason to try and use the GovernmentEntity hierarchy more in refactoring the code. That way if we do go the regions route it would be trivial to stick in another layer in the future. Yes, Gary, I know you hate coding with 'futures' in mind .

I would add the other layer now, so it wouldn't be a future.

Cheers

[Gary Thomas]

This post is my real reason for starting this thread.

Command and control appears in two areas of Clash. There is the command and control of the land itself, and there is command and control of military units (and other possible future non-military units).

The way the system is stuctured at present, there is no distinction between actual physical objects and the control structure. Thus the control structure for a map square is a province that is also treated as a physical object (and actually is). However, the command and physical object are in no way separated.

Similary, the present structure for military units (which, to my everlasting grief are also task forces!) which have a physical existence (and hence, importantly, a location) is that they can be grouped into task forces. A task force is also treated as a physical unit, causing quite a bit of confusion in the requirement to make sure things like location match up. Although the code allows task forces to contain task forces (other than units) there is absolutely no provision in the ai or gui for this to ever happen. Also, task forces are restricted to a single map square, so the multi-level task forces have no utility at all. There is no provision for an overall command, or any command structure greater than about the army level (provided the army is all in one square).

The governement system is not as bad, in that the physical nature of a province is much vaguer. Its only impact at present is that there is a province economy object. The only thing this does is accumulate resources over the individual map squares, in order to build things too large for a single square. In effect, this is a command function, and does not imply a physical existence for the province, though presumably it needs a capital at which the new unit (or whatever) is built. Similar remarks apply to the civilization level economy (which also has a treasury).

The comments above are just a summary of the present position.

My personal preference would be to keep physical things apart from command structures.

In the government case, I would allow two civilizations to "own" the same province. The amount of actual control they have will depend entirely on the number of squares they control. As the preponderance shifts, so does real ownership, until one civilization controls all of the province, in which case the other civilization's province object is deleted. This mechanism provides a good basis for partisan warfare, and insurrection or civil war.

A civilization has things unrelated to geography, which are properly part of its nature. I would also give it a command object which consists, essentially, a list of provincial commands as described above. The civilization would have no physical, territory related existence, except perhaps a capital, which could be changed at will.

At the map square level, I would have a command object which includes such factors as loyalty to a civilization, probability of a particular civilization being able to levy taxes or raise troops. There would be no no specific "ownership", primarily because I have difficulty in understanding exactly what ownership, in this context, means.

Occupation of a square by units of a civilization will obviously have a considerable effect on the command object for that square.

Turning to the military side.

The way the code is structured at present is designed to use extension (a Java mechanism) to provide similar services for essentially different entities. This mainly involves the combat related vales (attack strength, etc) and aggregation issues (addArmy, etc). A unit (a physical object) needs to be able to produce an attack strength when required. But so does a command (brigade, division, army, etc), which is merely a paper aggregation of physical units - something which can be radically altered by a written order which changes nothing at all on the ground.

A consequence of this approach is that a lot of effort is spent making sure that things match up - that a task force is in the same square as its components. Also, units and task forces are treated in the same way (as I said before, units are task forces). Unfortunately, units are NOT task forces, as you find out if you try and add another unit to one. So the code is full of things like "if (army instanceof Unit)" which is a Java idiom to find out what we are dealing with. Such things are completely unnecessary.

I would restructure this system in a number of ways. First, I would use interfaces. I would have a CombatData interface to provide things like attackStrength. The CombatData interface would have two implementations (not using extension). One of the implementations (ElementCombatData) would actually list the values of the attackStrength. The other implementation (ForceCombatData) would have a Collection (excuse the Java jargon) as a parameter in its constructor, and would add up, average, or take a maximum or minimum over the collection as appropriate.

I didn't mention that Units are actually aggregations of Elements (which is why they are task forces...). They use the same list for their elements which the task forces use for their units. This causes untold grief when trying to work with military units.

The structure I would have is to do away with task forces entirely, and have Units as the only visible physical representation of a military. Elements are not visible to the player, but are there, and would include a field ElementCombatData. The units would have a field ForceCombatData. Only units would ever have a location, thus removing the burden of making sure locations match up.

I would completely separate the command structure from the physical units. However, each command structure would also have a ForceCombatData field which does the accumulations over whatever level is the next lower.

At the bottom level I would have a special type of command object which has command of a single unit. This would include the unit's orders, if any. Each unit would traverse up the command tree and carry the first set of orders it found. Thus a command could tell all the controlled units to move together (and not get scattered).

It may be that these command objects implement other interfaces. Refactoring will reveal what is required here. In any case, extension should be avoided.

There may be, for the sake of easier player understanding, an argument for giving each command level a name (Brigade for the lowest level, then Division, Army, Army Group, Front, General Staff, whatever).

[Mark_Everson]

Hi Gary:

I agree with a lot of what you say above, and have some disagreements that I'll note when I get the chance. The reason I'm writing now is that it looks like you're putting two pretty much distinct topics together, and each of them is going to involve a fair amount of discussion. While things are still relatively simple I propose that you start two new distinct threads on "Military Forces Command and Control" and "Governmental Command and control" or whatever you want to name 'em. If like the idea enough to do that, then we can have more focused discussions in each, and I can just delete this one.

-Mark

[Gary Thomas]

What they have in common is the notion of separating the command structure from the physical object.

Another characteristic that they have in common is the notion of orders. We already have an orders interface which could be used for governmental orders as well as for military orders (it might need a slight amount of tidy up, but it would be minor).

However, I have no objection to splitting the thread.

Cheers.

[LDiCesare]

I'll precise a little how I envision(ned) the mil model when starting coding it:
There is a General interface (name may not be good) which is a Command interface, all the rest being Physical stuff.
What you say is basically TaskForce mustn't be physical but Command. That would reduce the number of tests in the mil model.
I also envisionned Army as an interface at the beginning but decided to make it an abstract class later on, probably out of laziness.
I can refactor things a bit, (though when is another question).
The General interface could be renamed into Command. Its sole method currently was to give orders to the armies. It is quite unused by now.
Mostly, all abstract methods of Army could go into one or more interfaces. Additionnally, some methods there are pointless. I will look at the code sometime soon and make a proposal as to how to refactor things.

[Mark_Everson]

OK, first my comments on the geographic command and control issues. I will post on the military stuff later.

I guess we can separate physical and control features in the model. I agree with Gary's statement that the Province and Civilization really are mostly control items at the moment anyway. So the only place where the physical and control elements seriously collide is in a MapSquare. I would like to see an architecture plan for what you (Gary) plan to do before I give a final agreement, but I don't have any real problem with the current MapSquare being split into two objects, one representing terrain, and the other control. I'm not sure which one would handle the economy though... The means of production are a physical thing, and so are the people, but there are certainly economic orders associated with it.

However, I disagree strongly with the contention that there should be no civ the ownership of a square. Here is the relevant quote from Gary:

At the map square level, I would have a command object which includes such factors as loyalty to a civilization, probability of a particular civilization being able to levy taxes or raise troops. There would be no no specific "ownership", primarily because I have difficulty in understanding exactly what ownership, in this context, means.

Occupation of a square by units of a civilization will obviously have a considerable effect on the command object for that square.

IMO ownership simply means that a given civilization has de facto physical control of the MapSquare, whether the people approve of it or not. The physical control can come from troops directly on the square, nearby enough that the people, if inclined to do so, would not revolt, or other factors. Ownership does not mean that the square won't erupt into revolt the very next turn, only that the civilization holds the balance of control their on this very turn. Ownership also implies that there is some authority that has at least nominal local control and derives in some way from the central (civ) government. (Although this might not be rigorously true for a feudal civilization.)

Without an ownership designation, complicated calculations would have to take place every single time we want to know "what civ does that square belong to?" The calculations would have to involve troops immediately present, troops nearby, capability of the central government to project power (and the will to use it to crush opposition), adjacency of nearby similar ethnic groups, and the list goes on and on. So I simply cannot accept the lack of an ownership identification for each square without very good reasons that have addressed the problems I bring up. (And any I can come up with in the future )

Gary and I also had some e-mail correspondence on these issues, which I will reproduce here so others can see what we said.

[Mark] I don't much see the advantage in your "Districts"
[Gary] I have reconsidered this and agree with you.


[Mark] Two civs being able to 'own' bits of one province -- interesting, need to discuss pros and cons.

[Gary] I think it will actually tidy up a lot of things. It is also in line with my "separate the command and physical" crusade.

[Mark] Well, I don't much care about that but what sways me is that provinces can be more permanent on the map. So Germany and France can keep fighting over Alsace-Lorraine and the Rhineland and the names and shapes are constant. The way I did it, you would naturally want to absorb a few squares into and existing prov and the shapes in wartime would be forever morphing. More constancy -> more player feel of connection to the world -> more immersion -> more Fun! (IMO) That's why I"m coming around to your idea.

And I like this last idea more the more I think about it! There are some complications, but I think they are well worth it IMO for the reasons I cited above.

[Gary Thomas]

The first point I would like to make is that it wouldn't be a bad idea to restrict this thread to Government command and control (rather than military). Apart from the "separate physical and control" they don't have much in common. So I will continue my comments on military command and control in the military thread.

My comments on Mark's post:

I guess we can separate physical and control features in the model. I agree with Gary's statement that the Province and Civilization really are mostly control items at the moment anyway. So the only place where the physical and control elements seriously collide is in a MapSquare. I would like to see an architecture plan for what you (Gary) plan to do before I give a final agreement, but I don't have any real problem with the current MapSquare being split into two objects, one representing terrain, and the other control. I'm not sure which one would handle the economy though... The means of production are a physical thing, and so are the people, but there are certainly economic orders associated with it.

The control object is the de facto ownership object. The only divergence I have with the present system is that two civilization can have a control object for the same square, depending on the influence involved. I have no difficulty with the concept that one civilization has economic control of a square, another has military control, and a third has religious control. That level of complexity is unlikely to occur, but it could.

However, I disagree strongly with the contention that
there should be no civ the ownership of a square.
... edited out ...
IMO ownership simply means that a given civilization has de facto physical control of the MapSquare, whether the people approve of it or not. The physical control can come from troops directly on the square, nearby enough that the people, if inclined to do so, would not revolt, or other factors. Ownership does not mean that the square won't erupt into revolt the very next turn, only that the civilization holds the balance of control their on this very turn. Ownership also implies that there is some authority that has at least nominal local control and derives in some way from the central (civ) government. (Although this might not be rigorously true for a feudal civilization.)

If this is the case, the ownership object merely has a boolean which is true if the civilization "owns" the square. false otherwise. It should still be an object, not a field.

Without an ownership designation, complicated calculations would have to take place every single time we want to know "what civ does that square belong to?" The calculations would have to involve troops immediately present, troops nearby, capability of the central government to project power (and the will to use it to crush opposition), adjacency of nearby similar ethnic groups, and the list goes on and on.

How does having a field recording the result of these calculations make the calculations unnecessary? It is very much my experience that this field will have to be updated every time something changes. It is far, far better to do the calculation when it is needed, rather than every time something changes.

On the other hand, if there is simple a yes/no ownership, then its mechanics will need to be very carefully specified. What makes it change?

So I simply cannot accept the lack of an ownership identification for each square without very good reasons that have addressed the problems I bring up. (And any I can come up with in the future )

I have not suggested that there should be no concept of ownership, simply that it is a much more comlex matter than a simple "this civilization owns this square - maybe - if the wind is in the west and Mars is in aquarius, and the coder remembered to change things".

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
The control object is the de facto ownership object. The only divergence I have with the present system is that two civilization can have a control object for the same square, depending on the influence involved. I have no difficulty with the concept that one civilization has economic control of a square, another has military control, and a third has religious control. That level of complexity is unlikely to occur, but it could.

This just seems going too far to me. If as you say ownership needs to be an object then I guess I can live with that. But when exactly is there going to be the case that one civ has military control of a square but lets another civ build its military there? A case of allied troops doesnt' count, because control would be retained by the original civ.

How does having a field recording the result of these calculations make the calculations unnecessary? It is very much my experience that this field will have to be updated every time something changes. It is far, far better to do the calculation when it is needed, rather than every time something changes.

Obviously if there is calculation involved the calculations must be done sometime. I don't understand how you thought I was implying that my way would eliminate the need to ever calculate anything . What I want to avoid is those calculations having to be done potentially 10 times or more in a single turn for the same square. Control would change from two possible sources: 1. Military Conquest, and, 2. Revolt. (The calculations for change of ownership for #1 are fairly trivial) Calculations would be done at most once per turn (for #2) under specified circumstances -- like the populace revolts or is near it. It would be done during the Govt/Riots phase. Your way, every single tick of the movement system the military potential influencing the square could drive a recalculation. Your way will better reflect reality in some circumstances, but I think you are wasting a lot of clocks to do it that way.

I just can't see the advantage of calculating ownership for every square in view every time the map is updated! Which is what your way seems to require if I understand it.

I have not suggested that there should be no concept of ownership, simply that it is a much more comlex matter than a simple "this civilization owns this square - maybe - if the wind is in the west and Mars is in aquarius, and the coder remembered to change things".

A square just isn't much territory, and I'd prefer having my complexity elsewhere. Clash is already 5x more complicated than anything out there . I think between military conquest and the Riots model, square ownership is already complicated enough.

Cya, Mark

[Mark_Everson]

I've reconsidered on the square ownership thing. I believe in triage, and I don't think this is a vital issue we must get right the first time, and of course yours could be the right way anyway . Just go ahead and handle the square ownership in the manner you like. We will work out the specs you need for how to do it when we need to. I'd say we should just start with a crude version and then work up from that is something more nuanced becomes needed.

[Gary Thomas]

Actually, the discussion drifted a bit from what I originally had in mind. All I was really pushing for was a "degree of influence value" ranging from 0 (no connection) to 1 (absolute control) for each civilization for each square. In fact it is unlikely that more than two, or at most three, civilizations will be competing for a square.

The value of the index will depend on history, culture, and military presence, and maybe other factors. However, merely plonking a phalanx in a square would not give ownership. On the other hand, doing that will play havoc with the previous owner's control.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
However, merely plonking a phalanx in a square would not give ownership.

why not? it is a long and honored tradition. While it is the sole military there (a big proviso) it can force the people to do whatever it wants, at least whatever they are willing to do to avoid being slaughtered or taking to the hills if those are available. The economy will be adversely affected if the people are working under duress. Is that what what your 'influence' value does? But the civ that owns the phalanx can IMO make demands of the economy, and is likely to get something like what they demand.

[Gary Thomas]

My real point is that the influence of the previous owner does not go to zero. A single unit, for example, trying to exert control over 100 km x 100 km is going to have their work cut out.

More to the point, can the phalanx immediately start building units there?

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
More to the point, can the phalanx immediately start building units there?

Yes! But of course taking people who may well not agree with you, and outfitting them with armor and long very-pointy sticks can have its disadvantages...

Anyway, I think we're enough in agreement to table this for now. I will, as I said above, let you try it your way, and we'll just see how it works. Hopefully I'll have to eat my words .

[Gary Thomas]

That is a sneaky way of saying: "if you care about it so much, do the work, then we will see".

Cheers

[Gary Thomas]

I am now really happy about the command and control system in the military model. Time to have a crack at the governmental side!

I tend to start from the basic rule that there should be no duplication of information, and that entities should not have to know anything about things that they don't need to know about.

At least the military stuff is now completely removed from the geography - map squares no longer know what military units are there.

The present system for government and economics is something like this:

Map square knows about

• a map square economy
• a controlling civ
• a controlling province

Province knows about

• All its map squares
• Its owning civ
• A province economy

Civilization knows about

• All its provinces
• A civ economy

Each of the corresponding economy objects knows only about the corresponding governmental object.

The immediate anomaly is that a map square can get its controlling civilization by two routes, and they may not match!

The main change I would make is to remove the govermental aspect of a map square into (for sake of a better term) a District, leaving the strictly geographic elements in the map square.

This is exactly analogous from the way the command structure has been removed from the physical units in the military model.

I would not think, however, that it is necessary for the map square to know about the District object.

Also, and again on analogy from the military model, the levels could be called GovernmentLevel1, etc and there could be more than three of them (Region?) with different names, depending on the historical civilization being modelled.

It also allows the possibility of a civilization having no map squares.

Only the government structure would know about the economics (though, of course, the economics would know about the map squares).

Each government object would know its immediate superior and its immediate subordinates only.

I am edging toward the concept of a map square as a completely inert object - things are done to it to change its state, but it does nothing itself (except to pass back information).

Cheers