Military / Combat Model

[Blade Runner]

Mark,

Sure the system quite complicated. If we can solve the problem without my idea it is OK. If not, we can use it.

Thanks for the replay,

Blade Runner

[Kull]

"Phalanx vs. Tanks"

I'll soon post a more detailed commentary under this thread, but IMO we want to severely limit the possibility that such an encounter could ever occur in Clash. Much of our focus has been to create historically accurate models. Clearly that particular unit faceoff has never happened. Yes, it's theoretically possible to send M1 Abrams tanks against naked Yanomami warriors, but that's not the point. The aggravating thing about CtP (and others) is that civilizations are allowed to maintain armed forces whose units range from phalanx to fusion tank. Please! I'm pretty sure we can do better.


[This message has been edited by Kull (edited June 05, 1999).]

[Mark_Everson]

Kull:

I think the main point in real history is that outdated armies are Not Cost Effective. This is not followed in Civ2 particularly strongly, and CTP actually has the Opposite (hahahahaha...) trend. Professionals are Very expensive and to have them sitting around with outdated weapons is just ridiculous. If we get the numbers right the problem of Seriously technologically mixed armies should never happen. We should also give the player ways to automatically upgrade units over some period of time when a new weapons or doctrinal tech is discovered.

[Druid2]

First of all.. Thanks for actually reading the thing. *S*

My comments on today's replies, in no particular order:

----
Phalanx vs tanks: Outdated mix of units. I was thinking to handle this via the TechLevel. The individual elements have one, the TF has one, they have to be +/- 1 or the element cannot join the TF. That would prevent archers in support of panzers, but it would still allow a backward civ to have a huge army of primitive ants and maybe they COULD beat an advanced army of choppers and tanks. It worked for Ethopia vs the Italian armor in the 30's.


-------
BR's combat matrix: I really like this idea, and, as Mark says, if/when we head for the tactical combat method, it makes a LOT of sense. The concept of having combined arms TF would makes this both much harder to implement and hopefully not needed as much.

In this model, we *are* greatly simplifying the combat, in exchange for combined arms TFs and a non-tactical combat. I dont think we can do that and also keep the 'a kills b but not c' paradox you get when just using a single Attack and Defense number.
--------

Supply: the numbers I put in ARE arbitrary and will need to be adjusted. What I have in mind here is that the required $ to support a TF in the field will change if there are nearby transportation [roads, rail, river,etc] AND that there is a line of transport back to somewhere friendly. It is still required to have enuf SO in the group to provide the supply. I do *not* have in mind actually moving supplies over the roads by convoy etc. Just saying that the presence of the transport facilities makes it cheaper [or non-presence makes it more expensive].

---------------
Attack vs Defense. I was thinking of the "A shoots at B's defense" then "B shoots at A's defense if B is still alive and doesnt want to retreat" and etc.

I just cannot think of any other easy-to-understand model that allows some units to have strong defense, weak attack, vice-versa, & etc.

One idea was to avoid a very fast and powerful Attacker being damaged in any serious way by a weak, slow Defender. That might be the case if all TFs act as attackers shoot at all the TF defenders before anything is decided. On the pratcital side, this allows a much simpler combat resolution algorithm: take 'em one at a time, instead of building a giant n-dimensional matrix for every combat round. In that matrix, you'd have to account for every position, every outcome, every damage, every retreat, for every unit, before anything could be resolved.

This is part of the reason that I envisioned an "m"-segment combat resolution turn (with m not =1). I want to let the attacker get some "extra" shots if he has enough excess speed or initiative,etc. and still let each of the parties have a chance to decide to break off and withdraw.

-------------

Mark says, "I had assumed combat takes place between All units in a given square."

Let me clarify what the model suggests as a means of locating the units, first.
1) The TF location (it's central point) cannot (voluntarily) be within the ZOD of any other friendly unit. So they cannot completely stack, tho they can overlap to a very large degree.

2) Each TF is assumed to attack "forward" and to assault the enemy that is closest to 0 degrees straight ahead. This may mean that 2 enemy units may be attacking one of my TF's.
But that MY TF can only attack one of them (the one closest to straight ahead in my desired line of advance).

So, I can be the attacker only once, against one enemy TF, no matter how many are "in front" of me. That will resolve to me as ATF [Attacking TF] and one of them as DTF [Defending TF], when that combat is resolved.

As I advance on my primary target, the other enemy TFs will each have a shot at my TF. For each of those combats, I will be the DTF and in turn each of the other enemy will be the ATF.

From the player's point of view, this will all take place while the program is running thru the combat resolution logic. After each of the 'm'segments of the combat resolution, I may be so damaged from all those attacks that my commander may decide to withdraw, or an enemy may be wiped out, and I'll have a new target, or etc etc.

I hope that helps clarify what I was thinking about. Other methods, of course, could be substituted.
--------------------

Initiative/surprise, etc. By conscious decision, I didnt put this in the model directly. It felt too "tactical". Instead I allowed an attack bonus [or defense unbonus] for being attacked from the side or rear, and included the "Rout" situation in combat where one side overwhelms the other.

As it is now, the ATF [which shoots first] is the faster of the two involved. And that is about it for "initiative". I guess TF "speed" is the initiative factor. It could be changed that if the ATF is MUCH faster, he gets an extra attack round or even 2 of 'em.

Or we could add a parameter to every unit and TF for "initiative." Navy Seal Units, for example, dont move very fast, but almost always attack w/ surprise. My feeling, obviously, is that this wont matter much in the model, but we could do it.

And all that would all be concealed inside the combat resolution without getting tactical.




[This message has been edited by Druid2 (edited June 05, 1999).]

[Hrafnkell]

IMO TFs should actually move Into the square they're attacking, so there are 1 TF from each side in the square before combat is resolved. If we feel they can´t stay in the same square after combat, the loser is simply forced to retreat.
There are basically two points for my opinion (I could probably find more if I dig some deeper into my brain :-))
1) It´s a bit silly to have combat occur in two 100mX100m squares, units supporting either TF would be up to 200 miles from the 'front'! Of course at higher tech there coul be some kind of 'ranged' attacks across squares, but basically I feel the TFs should be in the same square.
2) In order to simulate sieges (which I think we Must do, because of their historical significance) the besieger logically must occupy the square the city is in, it´s a bit silly to siege from 100 miles away.

[Druid2]

Hr:

Basically, I agree with your comment that the TFs need to be close enuf to be "in contact" in the military sense, and not just "in the adjacent square."

Just change your thinking from "tile" or "square". Get rid of the idea that a TF occupies a "square".

The concept in the model is that tiles are used for drawing the map. A TF has a location at a particular x,y coordinate. It has a ZOD, within which it might be able to detect an enemy. If there is an enemy there, it will attack it [depending on its orders, etc.]

In short, the ZODs of the opposing TFs have to overlap, and at least one of them has to actually ~detect~ the other one before there is combat. That way, the size and tech level of a TF determines how far it can be from the enemy before initiating combat.

[Hrafnkell]

OK, how many tiles will there be in each square, 3x3? (Just want to get a little clearer picture of things.)

[Mark_Everson]

I am dead, so will be brief now, but will post more tomorrow.

I understand the ZOD concept a little better now. So for an ancient army should be maybe 10 mi. They can detect further out if they have more scouts, but Nothing Happens until they touch at the desire of at least one of them.

However, the buisiness about two friendly task forces only being able to get within the ZOD of each other doesn't make sense to me. If the TFs are each small they could clearly have been designated a single TF and occupied the same space. What is the magical force that keeps them apart? Why can't they join up? Armies on the same side have always joined forces, in the same location if possible, because not to do so invites being beaten in detail separately.

-Mark

[This message has been edited by Mark_Everson (edited June 05, 1999).]

[Glak]

ZOD is a perfectly acceptable acronym but I don't think is should make it into the final product. Something like "field of vision" or simply "sight radius" would be more user friendly.

[Druid2]

Hraf:

I'm sorry that I'm not saying this clearly. I'm glad that you keep asking, because there are probably several others who also dont understand the ideas in the model.

A tile is the same as a square. Just a different name. I think the map folk are making them 100x100 km.

The military model ignores "squares" completely, except when figuring out what the terrain is.

This is significantly different than the way Civ or most other games work. I think they are all carrying over the board and pieces combat games from years gone bye.

A TF [Task Force] is the basic "unit" on the map. It has a location at a particular set of coordinates... for example:TF "alpha" is at 2250km, 1600km. [Assume that 0,0 is lower left corner]. It does not matter what "map square" that is in, nor how many other TF's are in the same "map square".

What matters is the Zone of Detection (radius from center) and whether a hostile TF is detected.

Lets make "Alpha" modern, large and with a good tech level, so it has a Zone of Detection [ZOD] of 50km. That means it can "see" 50km in any direction from its HQ location at 2250,1600. It has a % chance to detect any enemy TF that comes within that 50km radius.

IF it detects an enemy TF within that zone, it can attack it. The orders might be to Advance in a direction {eg. North, where the enemy unit was found}. Because it detected an enemy within its ZOD and it's orders are to advance in that direction, there is combat.

Further, small & primitive TFs [eg: group of spear carriers] would have a VERY small ZOD, perhaps 1. That could mean that two such groups could pass close to each other and not see each other. But there is very little chance that Rommel's Afrika Corps and Patton's Tank Army would fail to notice each other at much greater distances.

-------------------

Mark,
There is NO valid reason to prohibit actually stacking TFs on top of each other, except the practical, programming one. And also NO other reason to prevent friendly TF's from having 'centerpoint locations' that are within other ZODs.

If multiple TF's are at the same place, I forsee complications movement, orders, combat, detection, etc., IMO. For example, if multiple TFs are at exactly the same location, then how do we decide what % of an attackers damage goes to each TF at that location? That's one of the complications I ran into and could not solve.

But if those issues can be resolved, the restriction can fade away.

As you say, if the player wants that result [more units at the same place], there's no reason ~not~ to join them into a single TF. It would be cheaper, easier to supply, etc.

[Druid2]

Glak

well. *g* I had actually used ZOC, the more "standard" acronym for Zone of Control, but in the first go-round of comments, it got too easily confused with the other games' use of that term...

So I did a global replace and put in ZOD instead...

There must be some actual military term for the area around a given point within which you can detect enemy units.

[Blade Runner]

A few ideas:

1. Upgrade.
When the civ get a new military related advance, it can upgrade the TF elements, which is fit for the upgrade. The upgraded units don't lose the moral, etc levels.
i.e. WWI type tank brigade -> WWII type tank brigade.
Restriction: If a TF reach it's limit of development (like battleship in the WWII. or pikeman sometimes in the middle ages) the only possibility to disband the obsolate unit and train to a higher level unit.
(We can send fighter pilots to use a stealth fighter, but we can not send pikemans to use Tanks.)

2. Attack and defence points:
Ok, I see the matrix is too complicated. I have an IMHO better idea:
We have 4 (or 3) different kind of military theater. What about to include 4 different attack value?
A few example:
Modile SAM (AG): Attack: 5 AG 2 NF 25 AW 0 ST Defence: 10
Mobile sat. attacker (AG): Attack: 5 AG 2 NF 10 AW 30 ST Defence: 5
Tank (AG): Attack: 25 AG 5 NF 10 AW 0 ST Defence: 30
Attack helicopter (AW): Attack: 45 AG 15 NF 5 AW 0 ST Defence: 5
Attack satelite (ST): Attack: 60 AG 60 NF 20 5 ST Defence: 5
If we do it this way, we need only 1 defence value, and we can make "real" models of the military units. If we plan to use satelite and air units this will change the system closer to the reality, and I think this is quite fun. We can easily translate any kind of military unit description to a good model. We can mix the different units to get a TF. The attack points added together to produce the summ AG, NF, AW, ST attack points of the TF. The user can and must mix well the different units to produce a well balanced TF, and the enemy can not erase this forces easily with a special TF.

Blade Runner

[Xuenay]

I have a new idea: If a TF is built in a city thats city radius consists of mainly mountains, it should get a small bonus when fighting in mountain terrain.

[Mark_Everson]

Comments on some Big issues in the Mil system...

On a Tileless movement system:

We're already fairly committed to tiles in the AI department. Its also more difficult (or at least very different from where we already have AI code) to write AI for movement in a continuous space. For those reasons alone I'd like to stick to tiles. To make things a little more fluid in movement we might consider going to a 3x3 sub-tile system.

Another problem if you go to fluid movement not linked to the underlying squares, is that you need to then know Exactly where the roads are. Do they always run through the center... If not does the player then have to tweak on a sub-tile scale where the road go? Personally I think we have too many tiles already to get the squares down to the 60mi (100km) level. That's tens of thousands of tiles. If we go as far as subdividing each tile into nine sub-tiles we will have Hundreds of Thousands of sub-tiles.

Step back for a moment. The Whole Emphasis of Clash is Strategic, rather than tactical. This issue, and some of the other things I comment on here (like facing) are really effects that should go IMO into a tactical mini-game for battles. I realize that square-size effects are somewhat irritating, but I don't think we can solve all the little problems with such games. The point I'd like to raise is that fraction-of-a-square amounts of movement or detection range should virtually Never decide an important issue in Clash. If these effects Do decide important issues then IMO the AI will be Virtually Impossible to write. A system with many units (TFs) cruising around, all of whose detailed actions can have a big effect on the outcome is almost in the realm of a chaotic system. This is especially true of the multiple attacks and defences involving individual units that IMO should all be a single battle. One reason I simplified the system I proposed to be a single battle in each square is it pushes back somewhat from that frightening complexity. The system I proposed also has the Vast AI advantage that it is scalable. It can easily handle in an approximate way the battle of many TFs on a whole front. I don't know how to do that for the system you've proposed.

I Really think this would mess up the game. That's why I'm speaking out so strongly on this and the subsequent issues. Certainly, if a substantial fraction of those in the project have a view contrary to mine after hearing my arguments, I will just have to trust your judgements. This goes for all the comments I'm making in this post.

Dividing up the tiles for things like movement does have some advantages. We'd need to look into the ramifications on the movement AI code that is already written. I would propose that, If We Do It At All, It be on the level of dividing the tile into nine segments. This would change movement rigidness down to the 1/3 tile range which I think is Plenty good enough.

Special Attack and Defence values:

IMO this is an artifact from individual-unit systems like Civ2. I imagine you would have Napoleonic cannon have a poor defence value, and a high attack value. That is true Only If the cannon are caught By Themselves in the open IMO. As part of a TF, Cannon contribute an Enormous amount to the defence. Probably Much More than to an attack! How do your proposed numbers handle that?

Blade Runner: Your idea on attack values vs each 'type' of unit might be ok for cases where units attack 'bare' like a cruise missle attack. But again, I think when you mix them you won't necessarily get sensible results. The attack helicopters don't necessarily get to attack the armor because of fighters, and it ends up in an endless rock-paper-scissors exercise if you arent using bare units. Your Idea might be made to work, but it would take a lot of refinement and potentially confusing details IMO.

My system that uses a single military power number, but includes combined arms effects handles attack/defense power simply. Cannon alone or in a TF with very small amounts of infrantry or mobile troops lose most of their combat effectiveness because there's nobody to protect them. I'm not saying the first stab I took at it is the best way to handle it, but it at least gives a reasonable answer that is relatively consistent with historical combat results.

Combined arms effects table

Add Power x bonus for superiority, for the different types with
Limitations below

Infantry	No limitations
Mobile	Power reduced by terrain, Use horse or tank/mech power x
Ranged	Maximum Ranged power can be at most half the sum of raw power of infantry and mobile
Airpower*	Max airpower value is 1/4 the sum of raw power of infantry and mobile
Naval*	Max seapower value is 1/4 the sum of raw power of infantry and mobile
*	Any excess counts as bombardment

I will continue this in a new post...

-Mark

[This message has been edited by Mark_Everson (edited June 06, 1999).]

[Mark_Everson]

Comments on some Big issues in the Mil system... Continued.

Your comment on every battle reducing to an nxn matrix

I don't get this one. That must have to do with some assumptions in your model. Perhaps the rule you had about TFs not being able to combine? In the model I proposed there is one battle (actually modified to three sub-battles) in each square. When each sub-battle is over someone may retreat, in which case there may be a single other fight if an enemy TF was waiting to spring on them. If you forget the "A shoots at B's defense" then "B shoots at A's defense if B is still alive and doesnt want to retreat" and etc. assumption all these nxn problems go away if I understand what you mean.

Attacking by forward facing

The front-facing-attacks thing assumes that strategic movement direction has something to do with Tactical movement direction in battle. IMO they are unrelated, at least for most of history, up to say the Franco-Prussian war. And facing is an important parameter for later battles. But its use seems to drive the whole model in a lot of undesirable directions, for instance the trading of attack and defense stuff. I'd have no objection to facing in and of itself. It clearly is important even on a strategic scale for modern battles.

ZOD

This is a good concept. I have only a relatively minor comment. From the writeup it seems that once the attacker finds another in ZOD the attack commences. The other unit has a say in this. It might try to flee as soon as it realizes the situation. I might just be quibbling over something you haven't had a chance to write up in detail yet...


Anyway, we need serious discussion involving others in the group on the IMO big issues I raised in this and the previous post. Others, lets hear what you think either way... We need to put this thing to bed soon.


Finally,
Some notes on the AI issues I discussed above:

For the military AI for a front in modern warfare, we will be looking at a Coupled system of Parallel Populations of Genetic Algorithm (GA) -generated solutions Fighting It Out. What I mean by parallel populations needs to be explained.  Say we (A) are at war with B.  One population of the GA will represent our strategies and the other population the strategies for B.  These populations are started using the ideas I'll describe later.  Basically some members of the population are generated by heuristic (basically, rules of thumb), and some "from the ground up" by GA.  To get the fitness for each individual in A (how good a strategy it is) we play it against x individuals in B's strategies.  The number of individuals to play against, x, will be determined by experimentation and how many clocks are available.


So we have set of first-generation strategies for A and B that we test against each other. For the strategies for B we make our best guesses based on A's knowledge of Bs forces and general aims.  Just to give a specific example; one strategy in A, call it A1 might be strike at North part of the front with half of the forces and hold elsewhere with the remainder spread thinly.  This is one of many strategies in the population A.  It will be played against x B strategies.  If we take x=3 we might have: B1 is defense-in-depth; B2 is attack in N; B3 Attack in S.  Now we go to a simulated way of fighting out the battles quickly to get a fitness measurement. You might also do several (y) tries on each battle so one bizarre result doesn't screw it up.


Lets say A's army is twice the size of B's and we award success point to be positive for a Good result for A.  So we fight out the three simulated combats and get the results: A1B1 gives +3; A1B2 gives +1; and
A1B3 gives -2 (since they hit us where we're weak and can seriously hurt A even though we'll probably still win the war)  So we now have a fitness for A1 (and part of the fitness of B1-3).  After going through
one generation we have evaluated p strategies for each of A and B where p is the population size.  To get estimated fitnesses for these populations we have had to evaluate p*x*y mock battles.  For the next generation we use the fitnesses of the previous generation in the usual way, and generate new populations A' and B'.  When we run out of available time we use the best one, or pick randomly among fairly good ones using some metric.

What I'm Getting At:
To do a decent job we need to evaluate p*x*y mock battles at the whole-front level for each generation of the GA. My guess is that p*x*y will be some number of order >100. This needs to be done for each front for each AI. So the 100+ evaluations need to be Quick and Relatively Accurate. This is where I'm worried about the detailed model that has multiple attackers and defenders shooting back and forth. In that way the final outcome could IMO easily rest on a few minor details that are not available at the start. So you either have to go through 100+ of these whole-front exercises in detail (too time consuming) or come up with a way you think will give approximately the right answer (tough IMO because of the near-chaotic nature of the system). The system I proposed, because it is scalable to an entire front with relative ease should make these 100+ calculations relatively fast and accurate compared to your proposed model. The scalability in the model I'm using comes from the observation that you can lump a whole front's worth of military power together, as if it were in the same square, and get an answer that approximates what the result over the whole front might be.

Don't get me wrong, the system I proposed has properties that will make it tend to chaotic behavior also , But my judgement is they are not near so strong as the same tendencies in your model. That's because there are simply a lot more 'twitches' capable of changing things drastically in your model than in mine.

-Mark

[This message has been edited by Mark_Everson (edited June 06, 1999).]