Military / Combat Model

[Kull]

Comments on the Marks comments:

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.

Druid's Model vs. Mark's: IMO the "Real Issue" involves Tactical vs. Strategic combat. We can argue relative merits till the cows come home, but here's the bottom line. Is strategic military combat "FUN". If it is, then "drive on drill sergeant, drive on"! If not then it won't matter how good the AI is, or how realistic all the models are. We'll have a party, but no one will come. On the one hand, we're developing some HIGHLY detailed models for the economy, research, culture, & government. But on the military side, it looks a lot like "my big buncha guys against your big buncha guys". Is the basic assumption in Clash that doing a good job with the first four will let you build a "bigger buncha guys", and thus win the wars? Historically that WAS usually true. But we'll have to ensure that it's fun.

[Kull]

Military Model Comments:

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

There's a lot more I should add, but I have to catch some "Z"s and shortly after that, a plane. See y'all in a few days!

[Mark_Everson]

Kull:

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.

-Mark

[Druid2]

Mark,

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.

SO, I'm suggesting we adopt a fairly simple logic paradigm for the Combat Resolution, and focus on getting the PC to do the right thing in building and ordering units.

[Mark_Everson]

Druid2:

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.

-Mark

[Dominique]

Wow! Excellent work, Druid2 - and a long thread with many (good) ideas.

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


[This message has been edited by Dominique (edited June 07, 1999).]

[Druid2]

Mark,

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.

---

1. Resolving all the combats on the map.


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

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

[Mark_Everson]

My brains are Mush, so I will burble briefly...

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

-Mark

[Druid2]

Mark

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.

Not if you're just moving from here to there, and the opp. has outmaneuvered you and got there first .. Now you *are* attacking them with 2 indiv. units, instead of Coordinated Attack.

[JimC]

Well, I'll post a brief reply now, since I'm in a rush....

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.

Jim

[Druid2]

Tileless-ness

JimC & Mark,

I think this is another of those discussions that would resolve very quickly if we were in the same room, instead of communicating via terse msgs.

Am I right in thinking that the main issue is NOT placing the unit on the map without regard to tile, but figuring out the movement? Those are the n^2 to n^4 more loops that you have to run thru while figuring the AI? Using something like the "intensity demo" that is posted elsewhere?

The rest of this post is based on that assumption.

1) I re-looked at the "intensity demo" and made some comments over in that thread. I'm sure that the suggestions about pruning, are either already in your app, or already in your plans for the next generation. But they do cut down on the number of loops that need to be calculated between turns.

2) For movement, I have some ideas for further cutting down the iterations.

2a) First off, if the unit has had it's path calculated recently, and there have been no terrain changes, and there is no change in orders, there is no need to recalculate it. I'd suggest we save the list of squares that a unit will pass thru, up to 3x its base movement [some other multiple? dunno]

2b) We can make some simplifying concessions regarding use of roads, rivers, etc. For example: If the TF is in a tile with a transport feature, it's considered to be ON the transport feature for purposes of movement, or if it's within x km of the feature.

2c) Calculate the path using full squares, as you'd be doing now, which presumably moves "center-of-square to center-of-square". Then just do a quick "partial move" of the unit [figure distance only] to put the TF on that already calculated path. This would not be a perfect representation of the "actual desired move" but it would be about 2 calculations longer than the square-to-square method, and still allow all the other benefits of 'tileless-ness' (I think).

[Diodorus Sicilus]

-First Post This Thread-

Some semi-random thoughts from a non-programming computer, board and miniatures game playing ex-professional soldier and current military historian...

What a TF or Army can do to another and who can do it first is based on a military quality called Agility (by the US Army today) or "Aktivnost" (by the Soviet Army). What it amounts to is the ability to act faster than the enemy can react: that is, get inside his 'decision loop'.
This ability is not based entirely on mobility. Some major factors are:
Commander's ability to make fast, accurate assessments and decisions- this in turn is based partly on the Scouting capability, recon or 'size of ZOD'
Speed of dissiminating those decisions: the staff and chain of command of the army - if any
Speed of movement - which includes not only how fast the individual can physically move, but how fast the Units (battalons, regiments, etc) can move. As a rule of thumb, big units move lots slower than small units.
If all of the factors are better than the enemy's you get Armies (TFs) that have seemingly awesome capabilities: the French armies under Napoleon 1796-1806, the Panzer Divisions 1939-41, the Mongolian Tumans under Genghis' and company.
And yes, they include the ability to meet, attack, and destroy more than one enemy TF (Army) within the same 100x100km area: "central position" was one of Napoleon's favorite tricks, and smashing one opponent fast enough to smash another before he knows he's now alone was done by Nappy, the Mongols, and the Panzers...
This Agility composite is a major Force Multiplier.
Another is the old concept of Combined Arms, which changes with the technology of the force. To use an example cited in earlier Posts here, the Smooth Bore Artillery was a great multiplier for gunpowder armies. It added more to the attack when the rest of the army had smooth-bore muskets, because the guns could be massed to literally blast a hole through the musketeers. When the infantry had rifles, guns could not be massed as easily, but they retained a big multiplier on defense: George Thomas taught that no infantry properly supported by artillery could be driven from a position, and as a Civil War general, he proved it several times. When the guns became modern Artillery, able to hid behind hills and fire at distant targets, the multiplier became extremely high on both attack and defense again.
There have been armies with extreme Tech level differences that have fought each other: Zulu Spearmen versus Rifles at Isandhlwana in 1879, mounted archers versus rifles at the Little Big Horn, Ethiopian spearmen versus rifles and artillery at Adowa. I use all those examples because in every case the Lower Tech force won by annihilating the Higher Tech force to the last man!
BUT - no armies/nations in contact with higher military tech stayed without it very long. There has to be a mechanism in the game for 'diffusion' of weapons technology and the steady deterioration of units stuck with older weapons: a phalanx kept around for centuries when better weapons are known to them to be available, will be so demoralized as to be worthless.
Finally, a comment on the Fun Factor. The Civ games' success is based on four things:
Exploring the map
Advancing the technology of civilization
Growing an Empire
Conquering other empires.

Every one of those four threads has to provide a mix of 'automatic' (AI) procedures and 'hands-on' - because one man's micromanagement is another's Fun Thing To Do. In the Combat Model as with all others, provide the Option of 'managing' the battle taking place, with all the factors of an Operational Level Battle:
Flanking/facing
Initiative - getting your attack in first
Scouting/Recon - knowing more about the enem than he knows about you
Leadership - Charismatic General takes charge, with a higher chance of getting Heroically Dead in the process.

And, for the Economists and Explorers among us, the Option to have the AI do all this and just provide a Neat Summary of the results: a message from the battlefield with a suitably grimy Cavalryman in the background, grinnng hugely or morose as the situation warrants, or a communique from the general:
"The enemy has been beaten. I am tired. More later."
There are lots of historical examples that could be woven into the Game: that one above is a near-exact quote from Turenne in the 17th century...

[Mark_Everson]

Diodorus Sicilus:

I think we'll get at the Agility stuff other than ZOD thru a combination of tech differentials (operational/organizational techs), infrastructure (training and war colleges), culture (do The Best go into military or other paths), and characters(great generals, more likely in a society that values military highly). As you point out, when one side has many of these factors on their side the difference in combat results should be enormous.

Tech diffusion: Definitely

On your four points for a fun game, I think we've got 'em, and several more, but we'll see . Although there will be less exploration than in civ because the world will start out populated, there will be a Lot of Interesting stuff happening right at the start. You'll generally begin with neighbors, civilized or otherwise, and have to sink or swim in a multi-faceted world right from the start.


Druid:

How about we shoot for getting the by-square Combat/Movement thing going for the first alpha? Meanwhile we keep in mind all the things we need for your 2b/c comments above. They could be done in the second alpha round. That way things will be a little more solid on the other issues and I think we could do it with relatively little trouble then. If we try to 'forget' about these features you can keep us honest.

-Mark

[Druid2]

alpha 2? *LOL* OK...

I'm thinking that, alpha 1 is gonna have a big red X and a big blue X and they will each attack 1 square away, and die with little announcement, moving 1 square at a time..

[Mark_Everson]

Druid:

Speaking of resolved v. quickly... Netscape communicator's internet phone thing has a whiteboard that you can draw on. Maybe that'd be a way to work on this.

I'd been thinking a little along the lines of your 2b and 2c points. They appear to me to make the problem at least tractable. Essentially with this modification we'd get a somewhat more fluid movement and detection advantage, whithout making the AIs job impossible. I need to think about it some more, but it may be a reasonable compromise.

-Mark