Military Model VI

[Mark_Everson]

I think one obvious compromise would be to have two nearly-identical scenarios where one uses Richard's approach for the units with the other one using the spec that we've had up until now. Of course that won't close the deal either way since all the gui capabilities that will affect the practicality and feel one way or another aren't there yet. But still it might be instructive.

For the bulk of scenarios I'd still prefer the way Laurent and I are promoting, but at least we could get some feel for how the other way works.

[Richard Bruns]

Ideally, a player would be able to build both combined units and individual elements, allowing both instant armies and customization. But the problem is images. I´ve already used all the images we have for the individual elements. If I get permission to use more images, I´ll gladly throw in some combined units.

[Mark_Everson]

Originally posted by Richard Bruns
Ideally, a player would be able to build both combined units and individual elements, allowing both instant armies and customization.

Hi Richard. I'm not sure this is the ideal anyway, since it might well present most players with too many choices. IMO we need to pick one approach as the default or we'll just have too many unit picks, at least for starting players. We can check out your ideal way and see what everyone thinks if the images problem goes away.

But the problem is images. I´ve already used all the images we have for the individual elements. If I get permission to use more images, I´ll gladly throw in some combined units.

Yeah, if you want to do this you'll need to find someone who's willing to let us use a fairly complete set of civ2 units. I don't think that should be very hard though. If you run dry on Apolyton, I can suggest another civ site or two that have some good stuff.

[Martin the Dane]

This post actually belong in several threads, but since it has mainly to do with military units, I'll post it her.

There are currently two versions of the military.xml. One for Richards unified system, and the older "official" version. I think it's time we decide on one or the other as the standard.

Personally I prefer Richards lower attack-values, to the humongus numbers in the "official", but I would like them to be in the 10-100 range for one unit, not in the 1-10 range. Furthermore I like the addition of anchient ~250 men-units.
The only thing I realy dislike is the name Mob/Mobster for the ancient "wariors". To me it sounds to much like Mafia.

For the long term it might be relevant to have several versions of military.xml and a more complex include system. This would allow easier creation of several scenarioes over a given theme, with shared units, technology, etc.

[Mark_Everson]

Originally posted by Martin the Dane
There are currently two versions of the military.xml. One for Richards unified system, and the older "official" version. I think it's time we decide on one or the other as the standard.

I agree completely! How about it guys? The two areas of disagreement seem to be unit values and whether units should be combined arms or monolithic. . .

Personally I prefer Richards lower attack-values, to the humongus numbers in the "official", but I would like them to be in the 10-100 range for one unit, not in the 1-10 range. Furthermore I like the addition of anchient ~250 men-units.
The only thing I realy dislike is the name Mob/Mobster for the ancient "wariors". To me it sounds to much like Mafia.

I think I'd be happy with the numbers exactly as Richard has them now. Sure, every once in a while a stat will be below 1 at the start of the game. But the alternative is to have things 10x or so larger for the rest of the game. One possible compromize, only the mob or militia type unit could have 1 and even warriors could start with 2 or so. I also dislike the mob name and would rather stick with militia.

As I have already expressed earlier in this thread I think the standard units should be combined-arms for now. We could test Richard's ideas using a single scenario as I've suggested before.

For the long term it might be relevant to have several versions of military.xml and a more complex include system. This would allow easier creation of several scenarioes over a given theme, with shared units, technology, etc.

I agree, but that could be messy to code and buggy. So while I think its a good long-term aim I would like to keep it simple on that score for now. Laurent is in the best position to say how tough or easy he thinks such a change would be. Personally I'd rather have him spending his time on AI . What do you think Laurent?

[Richard Bruns]

Now that I can use more pictures, I will add combined arms units. I may also experiment with the combined army units being composed of a picture of more than one person. But 7.7.1 might take a couple weeks, since I will be gone for a while, starting in a few days.

[Mark_Everson]

Originally posted by Richard Bruns
Now that I can use more pictures, I will add combined arms units.

Well, just to be clear, I don't think we should have both combined and mono-element units as the default for use in all scenarios. It is just too many choices, and will screw up the unit building interface IMO. If you want to have both as standard in the military file, but hide the orders for the mono-element ones in most scenarios I guess that'd work. And you could make all those orders visible in one of the scenarios so we can see how it would work. What does everyone think?

Laurent, what do you think of the scale of unit strength change proposal? One thing we could do is change the outputs to show tenths if a number is between 0 and 1.

[Richard Bruns]

If I read the dataformat document correctly, the econ xml gives me the ability to put orders in sub-categories in the GUI. So I can have combined arms units at the top level of the tree, and elements at a lower level. (or the other way around)

[Mark_Everson]

Originally posted by Richard Bruns
If I read the dataformat document correctly, the econ xml gives me the ability to put orders in sub-categories in the GUI. So I can have combined arms units at the top level of the tree, and elements at a lower level. (or the other way around)

Very Cool idea, but not implemented. And I hadn't forseen going quite that far with it. Certainly combined with Lee's tree stuff on the econ gui, it would take care of my objections to the two basic views of army units. For now you can only use the specific categories and sub-categories in the econ.xml file. That is because those correspond to existing java classes in the code.

But it might not take that much work to get where you want to be. To be specific you would be happy if there were more than one "army unit" sub-class under military? There would be an "army unit C" for combined and an "army unit E" for mono-element units. I will keep this capability in mind as I implement the more-flexible category and sub-category structure. No guarantees but it seems it can be done fairly easily.

Anyone else see any problems with the approach?

[Richard Bruns]

Originally posted by Mark_Everson
To be specific you would be happy if there were more than one "army unit" sub-class under military? There would be an "army unit C" for combined and an "army unit E" for mono-element units.

Well, I don't want to force too many layers. Some units should be in the top layer, so the player doesn't have to drill down too much. I'll respond more fully in the Econ GUI thread.

[LDiCesare]

About figures for the units:
The only value I am concerned about in Richard's mods is the health. I liked the fact that health of 1 = 1 man. Of course you can look at the personnel value, but when looking at elephant units or later at tanks etc. whose health will be very different from manpower, I thought it gave a good quick view of the strength of the units. At least have 10 for a basic unit so it is easier to make the difference between a full-strength and a wounded unit.

About different military files: It shouldn't be very hard to code. There are tags like <all/> that say which files should be used. I can change these from boolean tags to string tags so that <military/> means use the default military file and <military>scenarioname/scenarionamemilitaryfilename.xml</military> means fetch the military file in the specified folder/filename. I'll come up with something cleaner but that's easily done.

[Richard Bruns]

Originally posted by LDiCesare
About different military files: It shouldn't be very hard to code. There are tags like <all/> that say which files should be used. I can change these from boolean tags to string tags so that <military/> means use the default military file and <military>scenarioname/scenarionamemilitaryfilename.xml</military> means fetch the military file in the specified folder/filename. I'll come up with something cleaner but that's easily done.

That would be excellent. It would enable us to have several different sets of files. Would it be possible to have several different military files loaded up, to match different time periods? For example, the resurce folder would have files called ancientmilitary.xml, romanmilitary.xml, medievalmiliitray.xml, and so on, and the scenario designer could call up any or all of the files, as needed. It would keep the xml files smaller and save memory and system resources for scenarios that only cover a smaller time period.

[LDiCesare]

As long as you use one file per scenario you can do all you like. Actually, I coded it and you might even be able to use more than one file of one type if there are no dependencies between them, but that can cause problems if some constants are defined twice. I must test a bit.

[Richard Bruns]

Cross-posting form the tech thread

Originally posted by LDiCesare
I consider making healafterfight a function of techs in two ways: both attacker and defender-related. That way you would have steel weapons deadlier than clubs at Cajamarca (ok I am reading Guns Germs and Steel right now), and an increase in healing rates as the defender gets better medicine.

Interesting proposal. The best way to do that IMO would be to assign a "wound" value to each element. This value would negate healafterfight in the same way that armorpen negates armor, and can of course increase with tech as all element attributes do.

There is the question of what to do if the wound value is bigger than the healing value. Should units suffer additional casualties after the battle is over, or should we keep a floor of zero for the adjusted healing value? I guess this is a tpoic for the military thread, though.

I vote for the former, which would be cool and realistic. If the adjusted wound value of the loser is 0.4 and the adjusted healafterfight value of the winner is 0.3, then an additional 10% of casualties could be removed after the battle is over.

---

Currently, all elements have the following tags:

category
Attack
Defense
Movement
Distance
Armor
Health
Morale
Mobility
FlankerEffectivity

as well as orders and costs.

And they can also have the following:

BoardSpace
Breach

We already proposed above to add two more tags:

healafterfight
wound

And now I´d like to propose another change:

I would like to alter the Build order in order to give more flexibility, work with the new siege model, and make more sense. Currently, there seems to be no way to alter the effectiveness of the field fortifications that get built, and these fortifications have nothing ot do with the siege model. I would like to change this, so that anything with a build order constructs a temporary wall before the battle that works exactly like a normal wall. So the tag would change to look something like this:

<Build>
  <Defense><Value>0.01</Value></Defense>
  <Armor><Value>1</Value></Armor>
  <Health><Value>0.01</Value></Health>
</Build>

The defense and health of the wall would then be multiplied by the number of elements that build it.

I also have a question about FlankerEffectivity. Is it a direct value, or is it added ot one? If that value is one, does that mean that the maximum outnumbering is 2:1 or 1:1? And is there any plan for a Formation value that reduces the enemy´s flanking?

[jbl18]

Hi,

I'm new to Clash forum. I first wanted to congratulate you guys on some good work. I know how much dedication it takes to get a project off the ground.

I wanted to make the following suggestions (if they have already been discussed, please tell me, these threads are large for 33KBPS connection):

As far as playability I would highly recommend looking into an old game called “The Ancient Art of War”. It was fun and highly realistic. Its real-time and point to point grid but added a lot of concepts that games since have missed out, such as fatigue, armies, march orders, and supply lines. I always thought the Piece concept in Civ-like games made it it too much like chess on steroids.

Regarding this, I wanted to recommend the following changes:
a) Sightings should be 2 squares away, (makes more sense in this simultaneous movement system) after all you can see further than you can walk. Obviously on open ground only.
b) Combat engagement can occur when any unit is adjacent any other unit, rather than once they enter the same square.
c) A combat “half-turn” should occur as the battle is resolving; the army may retreat at any stage while giving a free shot to the opposition.

Additionally, I learned the following equation from Colonization, which I thought was realistic:

Military Unit = Manpower (Civilian population unit) +Armaments (Muskets or Muskets and Horses)

Have two types of units: Militia and Professional
Militia units are simply locals of a province with Armament to repulse invaders. During peacetime turns you build up the local stock of armament of each province or a general level of armament (i.e. 10,000 bows and 10,000 spears or 1 musket for every 10 population). When an enemy is sighted the local Militia will mobilize and alert. These are poorly trained and coordinated but are fighting on home turf.

Professionals need Barracks or a Garrison (replaces or supports local Militias) and must be recruited. The rate of recruitment is relative to the salary you offer vs. the average salary of the general populace.

A social issue is posed about having citizens walking around with their own weapons. It may give them the right to a vote or just to kill one another.

The armed forces need a manager. For each army you simply dictate what size and what percentage of each army should be dedicated to what kind of unit, i.e. You want 100,000 soldiers in TF#1 to have 50,000 infantry, 20,000 bowmen, 5,000 men for siege weapons and 25,000 cavalry. On the battlefield the local militia would as already in Clash support the battle and fill the ranks.

Supplies produced and population recruited during a campaign will gather at local garrisons or are automatically sent to the army (timescale issues).

Let’s say you need the militia to join your army on a long campaign, you must conscript them. This puts an economic toll on the populace in the form of temporarily lost population (while the man was away the farm can function, but growth of the population will be stunted). Extended campaigns cause this loss to be extended equally. Any loses on the battlefield then make the lose permanent. Plus it means the populace will not appreciate a long campaign.

One last suggestion:
Terrain should also include a Danger factor. It could be directly related to the terrain bonus. It represents the difficulties that come with crossing any terrain from both accidents (which occur in both the mountains and desert) and from wild animals (which occur in the forests and plains). Two things reduce the Danger factor, Roads (and other structures) and Settlement. When there are more people in a square; you are less likely to face a lion. A road means you’re also less likely to lead you’re force through a dangerous gorge. The Danger Factor reduces the effectiveness of Exploration by Military units and the effectiveness of taking a army over long distances.