6/4/99 : Subject to revision, of course. I'm sure there are inconsistencies. And at least one large hole.. .no individual unit details.

Military/Combat Model v1.1 complete

*Tables for the Military Data*

A couple of changes from the Mil Model - not integrated into the Model Doc yet [8 Jun]:

a) I went w/ Mark's single Combat Value, but added a diff. CV vs each of the domain types. [A unit can be strong vs Air, weak vs ground, etc.]

b) Changed the name from "ZOD" to Recon Zone... sounds more military and RECON is better than ZOD.

Kull is the co-duke of this subject. This means, I hope, that we'll have a chance of doing the remaining 9 million details before August.

I look forward to many comments and suggestions, and I am looking a (sorta complete) list of military units for the various civ-development stages.

The list of army-unit names is coming along. So far, I have:
*SGS - Small Group with Spears
*MTGS - Medium Tougher Guys with Spears
*BBWG - Big Bunch with Guns
*ADWNL - Automated Drones with Nuclear Lasers

So it's just going fine. All suggestions welcome on this, and what the combat statistics could be for these -and perhaps other- units.

[This message has been edited by Druid2 (edited May 31, 1999).]

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

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

I've only had a few moments to look it over, so I can't make any comments on the contents. That said, you've done an Enormous amount of work. Thanks again for taking this on. I'd like to see how good you are with something you're really into! (Note to others, Druid2 isn't into military stuff.) Anyway, we have no detailed unit list. You could steal one from the Civ3 units forum as a start . I'll get back to you on the proposal when I have a chance to look it over tonite.

Thanks again,
Mark

I'm Baaaack...

Ok, I'm just going to put items under either major or minor headings as I run across them.

Major Things:

I am actually hoping for the number of military phases per turn (m) to be 1 at least until WWII-type technology. As you say, playtesting will tell.

Facing is more appropriate IMO for a tactical system if we do one.

Communication depending upon distance from capital should probably be at player option.

Orders Phase is really good, but the interface people are gonna hate you

Minor Points:

Commanders have stats, but they should not necessarily be known to the player.

"[The entire mobilization, movement and combat of WWII was contained in less than 1 Clash "turn".]" - Actually this isn't right. In ancient times the turns will probably be 5-10 years long. But in Civ-ish fashion by the time WWII tech runs around turns will probably be yearly or even seasonal.

One point on orders. I picture support as being an order that isn't incompatible with movement. FE two columns advancing into enemy territory and supporting each other.

-Mark

Hey, I'm not a Java programmer, so I'm not concerned about coding issues

Seriously, I *WOULD* like to hear about practicality issues that the Mil programmer(s) might raise.

Who *are* the Mil programmer(s) anyhow?

-------------
Points noted. I do not anticipate going back to revise anything until I have at least a full write up of all the blank spaces .... so, I guess I'll get to the revisions about Labor Day

I'll pretty much be a 'generic programmer' until that time....

[ Wait until (condition) ]
[ Wait n turns ]
I think that with the Wait until (condition) order should also include the condition of an enemy TF (of a given type) entering itīs ZoD. Also, for both these orders, once the conditions are met (or the number ot turns elapsed) then new orders (maybe termed Alternitive Order) are given the TF. Maybe this was your intention, but I thought best to mention it here.

[ Ambush ]
At first glance this order seems very powerful. It seems players would use this order almost exclusively. Is there some disadvantages to this order I donīt see?

[ Fortify and Defend ]
I feel that building fortifications should cost some money, especially if theyīll be intact after the AG that built it is gone. Fortifications were one of the most expensive military costs and IMO erecting defensive installations should be more costly. Maybe if players donīt pay anything the fortifications are considered field fortifications that will disapear once the AG that built it leaves the square. If players pay a set amount of money (the more the higher the fort level) then the fortifications become permament.

Supply Officers [SO]
I was just thinking that we could include special types of SOs, such as supply ships and fueling planes. Maybe itīs unneccesary, but, anyway, here it is.

MOVE PHASE
Here is one idea on how to handle movement: Each TF has an Initiative Rating, and the movement is performed in Initiative order, with the TF with highest Initiative going first and so on. For TFs with equal Initiative Rating they are moved in random order. The Initiative Rating is mainly based on the ZoD. As I think the ZoD will increase as the tech gets better there should be no need to tie the tech level of the TF into the Initiative Rating, itīs indirectly represented through the ZoD. Other factors that influence the Initiative Rating are: Leadership (Commanders have a Initiative Rating); Mobilization; Supply and perhaps some specific research projects. As AW (and probably NF) usually have higher ZoD than AG they usually go first, which I think is realistic.

Communication:
I personally think this is a brilliant aspect which could make war much more realistic according to era than anything I've seen yet. I do agree that it would be best used as a player option. My interest in it stems from AI defects in other games which allow human players a commanding advantage in deployment methods, which don't always change with the situation. This would level the playing field a bit, I think. Another possible application is to give the AI a minor cheat with it. Example: News of War in Northern Italy reaches AI controlled Rome in 5 turns, but Human controlled Paris (about the same distance from the action) in 6 or 7.

Commanders:
I can see this as a very useful strategic element, used properly. I imagine there would be a need for hundreds of commanders, though, and I'm not sure how individualized each could be. I would suggest, though, that if each has advantages, most should have drawbacks, too, similar to the Manager effects in Railroad Tycoon II or Soc Eng models in SMAC. A possible alternative would be categories for commenders, such as Aggressiveness, Strategic Ability, Loyalty, Decisiveness (all off the top of my head), which effect how his TF responds away from home while out of communication with the capital. If they are rated in any manner, I would suggest the players have a chart in the manual or something, access through the help screen maybe. It seems this might be too important to leave to chance, especially with the number that might be required and possible difficulty in replacing commanders from a distance.

Also, can commanders be killed in combat? If so, are there penalties specific to losing a commander? Perhaps no movement until the Capital gets word and sends a new one or promotes somebody? I actually think this might be a nifty little feature if communication is turned on - inability to replace commanders instantly.

Unit Types:
My only concern here is that most units should be more than window dressing. Civ II in particular had many lovely but useless units available. I know you aren't there yet, but it's always a concern.

More thoughts later, if and as they come. As far as the overall combat and movement goes, it all looks very sound to me. Very well thought out.

Thanks

Mark: Why not have the Commander's stats available to the player? He's going to know the stats of every other element of the TF, and of the TF itself, and he's going to have access to the .txt file where the original data is stored. And it's an AI cheat otherwise, since the AI players will [we hope] make good descisions, not just random ones.

-------------------------------------------
I hope everyone who comes in here also goes to the top to reread the original post. The update info and etc is done up there.

I have the misfortune of being at work, so I'll only answer the immediate question. I'll look over the new stuff as soon as I can.

Thanks to Kull for pitching in here!

The idea on commander stats was that they are not known to Anyone before used in battle. The player (and AI) should know a commander's 'expected' values, but these can be Very different from actual campaign leadership. That's all I meant. So for instance Abe Lincoln pick McClellan (sp?) as his overall general, but finds out he's great at training armies, but can't use them to fight well. (simplification) So finally he picks Grant who turns out to be capable... Before they were actually tested McClellan looks much better on paper than Grant.

However this amount of effort would only be used for the top few commanders.

Hrafnkell: Good suggestions, but why do we need inititative in a simultaneous system?

-Mark

BTW could the MTGS (Medium Tougher Guys with Spears) be equipped with optional tactical nukes? :J

I dont forsee any reason why the player will ever see it or know about it or use it, but the combat resolution logic will use it.

Same thing with "Face" of the defending unit. The Player could use it, but mostly it will get used by the AI, and will make possible some effective sneak attacks by commandos and etc.

Good job on getting all this stuff together in record time. Most of it looks good to me, so, as usual, you'll only get to hear the complaints .

quote:

---

Note that a given TF will only be the ATF once/segment, but it may be DTF several times, if attacked by multiple HTF.

---

quote:

---

Mark, we will use initiative, internally, because the combat cannot really be simultaneous. SOMEbody has to shot first. And I'd rather have a reason to pick B instead of A, instead of just a random determination.

---

In a similar vein, you have attack and defensive strength of units in the proposal. Does this mean you intend to go in the direction of a Civ2-type system where sides trade shots in sequence? A's attack vs B's defence, and then vice versa? Or is the offensive vs defensive strength meant in another context. I'm just trying to prevent our having different base assumptions about how the system works before things get too far...

On the Supply modifiers you have. IMO these are kind of arbitrary if I read them correctly. For Example:
"TR3 [Road] is within ZOD and connects to friendly base/city: ESR=110% BSR" That means to me (and that may not have been your intent) that if I have a military unit that connects by road Of Any Length back home I am basically in supply. This is just plain wrong. I really think its better to just let the supply officers handle it, and give the player guidelines on where they can or can't likely send an army depending on the technology. The supply officers will enforce that in anything before the modern age, land-based supply can at best be traced for something like 200miles out of a city/supply depot. Now, for game balance and fun purposes we may decide to curtail part of the realism in the supply system. But that's a decision for the future.

-Mark

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

(for the IX. point)

We can solve a common problem of the Civ games easily.
My problem is: if I have a unit this unit has a fix number for attack and defend. I think if we use a matrix with all the units we can change the system to a more flexible (but maybe a littlebit harder to balance) system. We can fill the tank attack points against different kind of weapons. i.e. the tank is very powerfull against light armored untis but sitting duck against attack helicopters, but is not mean that the helicopter is more powerfull. I think this attack matrix system can help to us to avoid the common problem of the CTP players. (I'm one of them.) In CTP an ancient group of legions ALWAYS win against a tank! They use fix attack point, so they cannot fix this problem. We have a chance now to kill this very anoying problem forever!

It is just an idea,

That's an interesting idea. However, since our system is TF-based, the idiosyncracies of the individual units shouldn't be as important an issue for our Strategic combat system. If we do the tactical one, where the units actually would attack each other, this sort of thing would be more relevant IMO. But don't worry, the musketeers will get massacred in Clash .

If we would like to get a model of a real weapon systems we need to do this or something similar. In the real world there is a kind of circles. The tank can kill the SAM, the SAM can kill the attackcopter, and the attackcopter can kil the tank. Nobody can produce this kind of circles with fix attack and defence values. (How can A > B and B > C and C > A?)

I agree with your general thinking, but this is a Tactical effect. You can't send in an 'army' of Just attack choppers to do anything, because the tanks just Hide. The attack choppers can have the Devastating effect of completely eliminating the Mobility of the tanks, making them ineffective. But if there is no other force to back up the choppers its all for nothing. No militarily significant objective can be achieved (unless the tanks Need to get somewhere else). It is only as a combined force that you can really accomplish Anything militarily IMO. The present case in Serbia does appear to be an exception. In this case, strategic and tactial air attack alone achieving the objective. But we'll have to see how that plays out to be sure.

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,

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.

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.

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.]

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

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.

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...

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.

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

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

Facing: "Strategic Direction has no relationship with Tactical Facing in battle." That's generally a true assumption, especially given the size of the tiles. I still think facing has a role to play, so how about this. Any time two TFs come in contact, strategic direction is meaningless. We assume they move into a facing position. BUT if a second TF arrives, then that SHOULD constitute a flank or rear assault. That would be consistent with history.

TF's in the same Space: Keep in mind, Druid is not assuming a tile-based movement system. Given that, I think I know where he's coming from. Imagine what would happen if two large divisions decide to pass through the same town at the same time. You're almost better off if one of them's the enemy! At least then you can shoot at the SOB's. This actually happened to the Russians during the Battle of Tannenburg in 1914. Two Corps tried to pass through the same crossroads and the result was utter chaos. In a tile based system, there's a few ways to handle this. 1) TF's retain individuality: Assume that chaos effects are countered by the large size of Clash tiles and the represented time scale (long) of each turn. 2) TF's combine: Require them to cease all movement at that moment (a combination/coordination penalty). One final point. Neither suggestion applies to Air or Naval TF's. Air operates in 3 dimensions, so sharing a tile shouldn't be a logistical problem. Naval TF's have much fewer units than land or air, so a tile is plenty big enough to hold many TF's.

1) Crossing Oceans: In a world with continents separated by large oceans ("x" number of tiles, with "x" TBD), should we attempt to follow history? As a reminder, assuming the existence of "decent" ships in Eurasia @1000BC, it took 2000 years before the Vikings made it to the Americas, and another 500 before they were truly exploited. None of the strategy games even attempt to model this. But it could be fun, insofar as some civs could develop in near total isolation from one another.

2) Unit obsolescence: Please. "Tank vs. Phalanx" should be darn near impossible. I refer not to a conflict between civs of vastly different tech level, but rather to the ability (as in Civ and CtP) to retain these ancient units well into modern (even future!) times. There must be a mechanism which gives you the choice to either upgrade them, sell them (see "Arms Bazaar"), or disband them as your technology improves. Kind of a built in "Leonardo's Workshop", except it'll cost ya!

3) Fortifications: Do they degrade over time? (Especially the ones "left in the field" by units who move on?) Do they face in any particular direction? Do they degrade under attack (ie. from level 6 to 5 to 4, etc.)? Maybe only the ones beyond level 5 (ie. built w/engineer) are "permanent". In addition to "beyond 5" capability, what about speed of construction? Should engineers help there?

4) Mercenaries: These were a critical component of almost ALL warfare until relatively recent times. For many nations, they were the rule rather than the exception. There's lots of interesting things we can do here, so to my mind they are a MUST component for the Clash military.

5) Arms Bazaar: A follow-up to a Manurein idea. Yes, this should be available, BUT, only for non-organic units. You can't sell an obsolete phalanx (wouldn't that be slavery!?), but tanks, planes, and ships are fair game. This is also something fairly easy to automate and hand off to your Advisor. FE: We know the build cost of each unit and the maintenance cost. The AI will also know what else is on the market (a supply and demand factor). All a player need do is specify which units are for sale and let the AI take over. Heck, the AI could probably even figure that out for you, and just present a list of candidates. Shouldn't be much different from any other trade good.

6) Upgrading Units: Closely linked to Arms Bazaar (maybe even either/or). If you upgrade your existing phalanx to a legion, it should be much cheaper than building one from scratch since you are re-equiping and training an existing force. But with non-organic units, there are two roads to follow. 1) Sell the hardware on the Arms Market. 2) Upgrade the units at a cheaper price (the rationale is retention of trained troops plus scrap value of old equipment).

On the Fun Factor... Yeah, I thought about this. And worried a bit about it. It depends on the kind of player and what they want. It isn't a problem in modern warfare, because everyone needs to be spread out enough so that front-level decisions can become more important than the size of the bunch-o-guys. In essence any system that allows stacking up to some realistic limit is driven to this. I don't think the Fun Factor Gap is a big difference between what Druid proposed and what I have. That's because you're almost always better concentrating your troops in one square as much as possible in pre-modern warfare.

However, we need to be happy with the Fun Factor of whatever system we use, or we're in trouble. One thing you do still retain are all the important Strategic decisions. If you're fighting A and B, how do you apportion your forces, can you buy A off, all that is still fun. The fun concern is also one of the reasons I think we need the Tactical combat system. It would help those who Really want to get their hands on something.

From those who have played CTP:
Does the big stack'o'guys effect wreck the fun in the military system? I've heard lots of criticism of CTP on different levels, but this hasn't been one of them.

I hope I am misunderstanding what you're talking about for the Combat AI element. Cause what I think you said sounds very very complicated -- both to implement [programming] and to understand for the eventual player.

What I think you said -- and remember that I'm not an AI-type -- is that you're suggesting letting the AI run do the combat resolution. For every TF on the map, ... vs all it's current opponents, ... for all Civ's, ... multiple times, ... for the first pass... and then doing ALL THAT multi-times.... in the time frame when the player is looking at "Now resolving combat"

That's what I think you said.

All that so you dont have to have an attack # and a defense # ? I'm REALLY not trying to be a wiseA**, but this does not look like "handling it simply", to me. This looks like several minutes on a moderate-power PC, when the game gets to the "several large civs involved in a war" stage.

But even all that aside... how much does it gain?

I'd rather have a complex and sophisticated AI do things like put the right set of units into a TF, put it in the right place, with the right direction, and the roll the dice for an outcome. IMO, the problem has never been that the outcomes are way out of line [some obvious exceptions: phlanx vs battleship, but we can deal with those easily]... it is that the AI in these games has been doing the wrong thing.

Your hope was realized, it appears you're misunderstaning
and I'm mis-communicating

I think you're talking about the part
"Some notes on the AI issues I discussed above:"
All the complicated stuff was to do AI right IMO. It has
nothing to do with combat Resolution for battles the player
participates in. Battle resolution will be quick in either of
the proposed systems. The problem is when you have to do it
hundreds of times to evaluate different strategies in the AI I
envision. If the combat system is complicated to model in a
simple way, it will be Very Difficult to get the AI decent
(And of course this all has to be done within Kull's context
of it being Fun too).

A good result for the Military AI has Everything to do with
assembling the right TFs to achieve the required missions, and
adapting the plan to unforseen changes in circumstances. I
think we agree on that. The first step is to give the Mil AI
good rules-of-thumb. Civ2 clearly fails miserably even on
this limited goal. I agree with what I think you're saying,
in that getting the basic rules right is the most important
step. I think we can achieve this with some simple rules, the
Map AI and some other stuff. But Any set of simple rules
inevitably has problems with it in practice.

What I described above with the 100s of permutations is the
next step. Essentially its using the AI to 'wargame' the
strategies that come out of the rules and see how they do. I
think people do some of this when considering strategies, "If
I do x he could do y"...

When the set of simple rules we come up with has problems this
second layer of AI is to weed out some of them. It should
also sometimes produce really good strategies. People with
slow systems can skip this step, but it will be at the expense
of worse AI.

Now, what I had in mind for the AI may be misguided for a
number of reasons. But I think if we make the combat system
simpler (while still fun) it will pay off in good AI in the
end whether my specific ideas turn out to be right or not.

So my main problem with your proposed system is that it has,
in what I would call one 'battle' a cascade of potentially
many attacks, attackers, and defenders. The result can depend
on small details like facing...(If I understand it, and I may
be off here...) For two big stacks fighting each other I
think there's not much difference between the two proposed
systems. Its only when you get to a number of smaller TFs
that I think yours gets more complicated. The problem with
this IMO is that it complicates the AIs job without giving the
player clear benefits in terms of fun or realism. (I might be
wrong on this too) So, once we understand what each other are
saying, i think my suggestion for the combat model will be the
simpler one. Of course its possible I don't understand your
point(s) either.

On attack # vs defense #, that is a completely separate issue
than the simplicity thing. On that issue we just need to pick
the way that works best and go with it. I don't agree with
the general idea of separate
A and D #s as I explained, but the biggest problem IMO is the
implication that one side should shoot first, then another.

I realize the one issue you focused on bothered you so much
you had to see what was going on with it. If possible I'd
like to hear soo what you have to say about the other points I
raised.

Sorry to put you through all this, but we just need to thrash
through all these things. I think that active discussion will
result in our having a better game.

As typical for my input in the previous weeks, I'll stress the "atmosphere & fun" aspect again:

1) I agree with Mark that in a game of this level e.g. facing has no use. Clash is even above strategic level, so tactical issue shouldn't appera - i.e. IF there isn't a special "game within a game" on tactical level. Beware, though: There better be some good guys dedicated to a tactical combat system exclusively, otherwise we should simply forget about it. I'm still abhorred by the unbelievably silly "tactical" screen of Civ:CtP. IF the is a tactical option, two things must be given:

a) The tactical combat must be optional, so a player can deliberately go into the details of a decisive beattle while he can leave this to his commanders where not that important.

b) If handled on strat level only (option "tactical OFF"), the result must be close to the one that can be expected when the player takes over tactically. I played some games of good ol' Master of Magic lately and saw that battles in which I got defeated without exception when the tactics option was switched off were ALL won by me when I resolved them on tactical level. Not good - this kinda forces the player to be busy commanding the individual units and effectively make the "optional" tactics a must.

2) On tileless movement: As before, I second it - strongly. Mark, I don't see the real advanteges of sub-tiles, really. Why not instead really do it on pixel level? Where's the difference in having a 3x3 or a 32x32 or 64x64 grid? For the algorithm - none. But a finer grid "feels" more realistic. The only true difference between tilebound and tileless movement is that the coordinates of a unit look different, and even that is no necessity. Maybe the best way to go is to simply give a unit, say coordinates X16545, Y7856 and calculate the actual tile by dividing by the tile size. This would even allow to reflect the actual size of any military body in the gfx (a unit icon and a shaded circle around it describing the actual area occupied by the unit or task force). So, a unit would be defined by it's type and various "circles", showing actual occupied terrain, "controlled" terrain (i.e. terrain within the unit's weapon range, weapon range meaning not only ranged weapons but e.g. an enlarged zone of control for mounted / mobile forces), and viewed / monitored terrain.

3) On the phalanx / tank issue and attack / defense values: Maybe we should introduce a new combat value, called "protective value", i.e. an amount of power a unit "lends" to other units in it's task force. E.g. a Napoleonic battery on it's own would be absolutely defenseless, since there's no one it can lend it's power, but would be a formidable foe indeed if it strengthens the defense value of an accompanying bataillon (in which case Mark's thoughts are absolutely true). This would reflect the proven superiority of combined arms warfare in a realistic way.

Last not least: PLEASE don't get carried away with warfare and it's details. A game like CLASH only can be successful with a good amound of abstraction! I really can't say it often enough: AVOID ANY NUMBERS! AT ALL COSTS!

I'll go even further with this: There should no real numers for e.g. attack / defense values anywhere in the game - not even in the editable (scenario / mod) files. Keep this a secret - let the player get his experience, give him hints, but don't uncover the naked numbers. It's really more fun to build "a unit of strong, fast knights" than a body of "ATT 12, DEF 6, MOV 3 mounted warriors".

Players love the feeling to have accomplished / learned something - let them have it! Don't show off with impressive statistics screens, which in the end only impress those people calculating a game instead of playing it. And, ah, yes... this can be used as a bit of a help for the AI, which, of course DOES know the exact values...

Yes, you're right... I got lost among the levels of AI in your other messg.

Looking back, I see 2 major issues:

1. Resolving all the combats on the map.
2. Units / square vs. Tileless location.

Separate Attack & Defense values vs a Single number. I dont really care, I think the sep.values are more useful in defining different units, but ..(*shrug*)

Unit Facing. I dont really care. Again, I think it adds something without much cost [programming cost or playability cost]. But I'd drop it in a minute if the consensus view is it's not worth it.

The real issue is "all at once" or "one at a time". I suggest the one at a time for programming simplicity. The ComRes module *IS* going to resolve them one at a time, no other choice [*No Java Multi-threading, please! ]. So the question resolves to what to do with the result of each resolution, once it is determined.

- In the "one at a time" method, we update the tables that contain the TF status information, and go on to the next combat situation.

- In the "all at once" method, we have to create temporary tables to store the modified data, because we need the *original* data to use for the next combat resolution.

.......Let me give you an example......

TF A vs (TF 1 & TF 2) :: All 3 are moving and so will "Attack" whatever hostiles they find.

* one at a time: TF A vs TF1.. TF A takes some damage and that new, damaged number is used in the TF A vs TF 2 resolution.

* all at once: The initial combat values for TF A are used when resolving vs TF 1 and vs TF 2. This, to me is less desirable.

* NOTE: that this situation is NOT the TF 1 & TF 2 do a coordinated attack on TF A. The play HAS the option to give that order. If he does, it is a simple procedure: A vs (combined 1&2).

***So, to me, there is a reality issue as well as a programming issue. TF A should not be allowed to use its full, undamaged strength vs more than the first opponent. Plus, there is a programming complexity issue, as noted above.

If you want to, we could *ALWAYS* assume that all units of a 'side' are *ALWAYS* using the combined combat option. But it does get more complex, making that assumption, when there are multiples on each side.

I freely admit that the results might (*WOULD* !!) depend on which combat is resolved first. But, in real life, sometimes the tank shoots BEFORE it runs over the land mine and is destroyed, and sometimes it is destroyed by the mine BEFORE it shoots.

*SOME* thing really does happen before something else.

2. Units / square vs. Tileless location.

I think the tileless location issue is, really, a much more important issue, for making this game unique, and setting a standard for "the big boys" to attempt to live up to.

Locating the unit and determining what it's ZOD is without referring to an artificial map grid is a revolutionary change in the way this type of games is done.

There *are* programming problems challenges raised by this approach: the biggest problems, as you say, are transportation feature [road/river/etc.] location. I have a couple of ideas on doing this with some low-level help from the Alpha Geeks Programming Team.

But IMO, the advantages are enormous:

1) It PERMANENTLY puts to rest the "die-cut counter on game board" approach to the game.

2) It will also PERMANENTLY get rid of "phalanx in NYC attacks phalanx in Boston", just because the squares are size so that they are adjacent.

3) It adds the idea that units can pass "near" but not be in contact, without the seemingly strange result that they are both "in the same place"

Basically it divorces the unit placement and movement logic from the artificial oversimplification of "tiles".

Dominique:

1b) Yes the optional tactical and 'strategic' battles must be 'docked' to give approximately the same results. We will do this one way or another.

2) Will think a little more on the details

Numbers) I've put up a poll to gauge the sentiment among the team.

Druid2:

1) On your big issue... I agree one at a time is the way to go for both practical and realism reasons. I didn't know this was your big issue since in the way I'd had in mind, that situation couldn't happen anyway. (the joys of communication) However, I don't think this will happen too often... Usually the TF1/2 side should team up on A or they're asking to lose IMO.

2) Like I told Dominique, I will think a little more on the details

I'll be back when I have a brain

yes, the two TFs -should always- join forces when fighting an opponent.

Problem is: the Cooordinated Combat Advance is slower than normal movement. SO you'd prob. only do it if you expect to find an opponent there.

The biggest problem isn't really coding, since even a 'tileless' environment is still divided into arbitrary small tiles.

The main problem will be complexity and hence time constraints. For a square map, if you multiply the dimensions by n, the area is increased by a factor of n^2.

Time complexity of algorithms such as map intensity will be increased by n^4, A* by AT LEAST n^2, and with the sophisticated AI routines we will be aiming at, I hate to think....

So, if we remove tiles (or reduce them to tiny ones, since we can't escape the discrete nature of computers) then.... well, you work it out.

I agree with Mark totally on this one - we're designing a STRATEGIC level game, so there's no real need for us to attempt to create a non-discrete model of the world.

Attempting to do so will be a waste of programming time, and a waste of user time unless they have the latest supercomputer available to them.