Fortifications and Sieges

[Mark_Everson]

A crude model for fortification and sieges was called for in the Military Model VI thread. I started a new thread on the subject of fortifications and sieges, because I think it's going to require a lot of discussion that isn't central to the overall progress in the military threads.

I'm going to mostly say higher-level things in this document to get the discussion going. There will be many smaller details that we don't need to do now, or can be determined at a later date. Specific values of parameters will be left for later also, since those will be best determined by playtesting.

Fortifications

It seems to me simplest to have the area enclosed in fortifications be separate from the remaining part of a square. It has already been mentioned that cities should be their own individual hunk of land, so a city with walls encircling it would be handled as its own piece of land anyway. The advantages of having all circular fortresses be treated that way is that you can keep track explicitly of whether military units are inside or outside the fortress, as well as keep track of fortress stores of food and munitions if we decide this is worthwhile. For the remainder of this writeup I will assume that this is the direction we will head in. However, it's of course still up for discussion. There may also turn out to be big problems with it that I don't foresee at this point.

Fortifications have the following characteristics:

Enclosed Area or Capacity - simply the enclosed area within the walls. This will determine (crudely) the perimeter which will affect the cost of the walls, and the military power that can be positioned on the walls. The enclosed area also will give an indication of how much stuff and people can fit inside the enclosure in an emergency. Population density inside the fortress will be an important factor in whether a disease takes off in it.

Style - the style of the fortification. This runs from simple compacted dirt and stone walls, through styles of construction like castles, gunpowder-era fortresses, and whatever else we think is important. The style of a fortification is very significant, because as siege weapon technologies change, the effective strength of the fortification can be very strongly modified by what is attacking it. The most glaring example being castles, which were very difficult to take with middle ages siege weapons, being virtually useless as soon as cannon came on the scene.

Strength - this is essentially the defense rating of the fortress. It includes a number of parameters like wall thickness and materials, quality of design to give defenders as great an advantage as possible, etc.

These are the only three parameters I think we need at the moment. Suggestions for others that are vital? For now, I think we can model the food inside of a city with walls just like we do in detail for a square. (For example, for cities on the coast, if food can be supplied by sea, then starvation could be averted.) We'd handle a fortress as allowing it to hold out for a number of turns proportional to its strength. In essence we're rolling the cost of providing provisions into the initial cost of the fortification. A low-strength fortress might be able to last only a few turns, whereas a very strong fortification would imply the ability to last for something like ten turns.

Cost to build a fortress or city walls will increase in a TBD way depending on Enclosed Area, Style, and Strength.


Fortification effects on combat:

Fortifications give a defender in a combat an additional option. Normally a defender can either fight or retreat from the square. If a fortification is present, if the combat odds for a field battle are not to their liking, the defenders can retreat to within their fortifications, provided the fortifications have sufficient capacity. The attackers have the choice of leaving, remaining in the square without attempting to control the fortification (this is generally not very satisfactory), besiege the fortification, or or attempt to take it by direct assault.

Siege - the defenders generally stay within the fortification aside perhaps from brief raids to the outside ,while the attackers attempt to improve their position for an assault, and/or try to triumph over the garrison through its starvation or reduction by disease. Of course the besieging army can also be troubled by lack of provisions and disease. In coding term sieges justice date variable to describe the interaction of troops inside and outside the fortification.

Attacker Position - keeps track of how well-positioned the attacker is to begin an assault. First of all I don't like the name attacker position, but couldn't come up with anything better on short notice. Essentially Attacker Position covers the myriad cases where things need to be done to put the attacker into a decent position to assault the fortress or city walls. Starting an assault from a good position is pretty much mandatory for a satisfactory out, against any high-strength fortification. This includes factors like building earthen ramps within Arrow-shot of the walls, or working cannon near enough to a star fort to allow a successful assault. Specifications are all TBD for how attacker position influences the starting phases of the assault, what do different levels of attacker position mean, and how rapidly they can be changed by an Army.

Assault - direct attack upon the fortified units. When the fortification has not been breached, everyone in the fortification gets the Strength of the fortress (may be modified due to attacking weaponry) added to their defense. In addition, as has been noted before, the attacker cannot flank the defender. Generally the direct assault will only work with a decent starting Attacker Position, and large numerical odds in favor of the attacker, or after a breach of the walls has occurred.

Breaching - a hole in the walls, or some way around them. Either before or during an assault the fortress may be breached through things like bombardment, counter-mining, or treachery. Determining whether a breach occurs in any given tick will be a function of things like bombardment strength and type, fortress strength, time and effort spent digging under walls or looking for undefended entry points, and money spent on brides for potential turncoats to let the army in.

This is about as far as I've gotten for now. Comments, questions, and elaborations are very welcome. Hopefully Laurent and I can work out a specification over the next few weeks with input from anyone else that's interested. One thing we do need is the code for sub-square and the teas that Gary described in the military VI thread. If Gary stays out of the picture for too much longer, we may need to kludge around the lack of the sub-square hierarchy that he was planning to use for cities, since that capability is critical for the model as I've outlined it.

[Richard Bruns]

This seems like it could become frightfully complex. I like the idea of making cities a seperate chunk of land, but having a lot of siege-specific commands seems like overkill. I want to only worry about modeling strategic combat, and not have to make tactical or operational decisions. Since a turn represents a year, and most sieges were resolved in a year, there isn't any need to get this detailed. I would rather just give an order to attack and let the math run in the background.

[LDiCesare]

Richard,
The level of detail of the model is not related to what the player can see. The military model is already very detailed, so it is supposed to be realistic, but you don't have many options during a fight, so having many details here is not really a problem as you would stay with three options as a player: assault, besiege, move away. Siege may need a "bribe" option, but that would be all. I am not sure such an option is needed, as most of the time, besieged who surrendered or opened their walls did it to avoid or end the siege and were not very well paid in return.

Mark,
Area/Capacity: OK.
Style: Yes, but beware this introduces a non linearity. I think this could work a bit like a unit: You have dirt walls and wood walls ans stone walls and star forts the same you have warriors, legions, knights and riflemen.
Strength: Should probably be a function of style, or topped by the style, or a function like: Strength(style) * sqrt(money spent).

Siege: If both parties "agree" to siege, then almost no fight should take place. I'd limit the fights to scouting/manoeuvering phases of the combat, and have no assault phase, so you can have a few skirmishes but nothing of importance. Damage should be to the morale of the defender, with a chance each turn of surrendering based on food supplies, disease, hope of getting some help.

Attacker position: I'd rather get that as a figure resulting from the manoeuver phase of the combat rather than get into details. The effects of that phase could be increased for a siege, as positionning can be better thought here than in the open.

Assault: OK.

Breaching: OK but what are the effects of breaching? Typically, how many men are able to bypass the wall defense? If they get a "beachhead", is the wall bonus negated for all?

Other points:
Cavalry (and chariots...) should fight with a malus against walls unless a breach has been opened. That is because horses are not very good at climbing ladders.

To sum up:
Defenders chose Siege or Open fight.
If open fight is chosen, fight goes on as normal.
If siege is chosen, attackers chose Siege or Assault.
If Siege is chosen, fight is limited to scouting/manoeuvering, morale of the besieged (and besiegers) must be checked based on disease, available food etc.
If Assault is chosen, in addition to the above, fight occurs normally except that:
-no flanking can occur,
-defenders get a wall strength bonus to their defense,
-mounted units get a malus to their offense (e.g. 50%),
-all ranged weapons fight at their optimal range (as they can't be cornered)
-damage is dealt to walls in order to check whether a breach is opened. I suggest forgetting bribes for now. Mining/Sapping and catapult/cannon fire can all be modelled the same way. Damage dealt to walls should not be dealt to personnel (so you use catapults to breach walls or to kill people behind but not both, at least until walls are breached).

If a breach is opened, then cavalry penalty and wall bonus for close combat are removed. Ranged fire will still be hampered by the walls. That may be too much of an advantage as only a portion of the attackers will in fact go through the breach, but I don't think we want to pay the cost of a more detailed model.

[Mark_Everson]

Hey Richard,

Originally posted by Richard Bruns
This seems like it could become frightfully complex.

In addition to the things Laurent said, two points. Like everything else, you can put the AI in charge. I expect "Auto-Besiege" will be one of our most common options. I don't expect many players will want to micromanage siege orders. I sure don't want to.

Since a turn represents a year, and most sieges were resolved in a year, there isn't any need to get this detailed.

A military turn is a month... remember that one? And since the primary function of sieges is military, I expect we want to use the military time scale for sieges. That is why I mentioned sieges lasting up to about 10 of turns.


Laurent, I pretty much agree with your suggested modifications. :b I think the simplifications are mostly good.

The only exception is on Attacker Position. This is meant to be a slow painstaking approach to the fortified position, and in many cases in history takes many months for a decently fortified position. Therefore I think it is incorrect to handle it as a phase of combat which lasts only a few days at most. Although the starting value of Attacker Position certainly could be some function of what happens at the beginning of the first tick of combat. Have I changed your mind?

[LDiCesare]

I confess simplifying Attacker Position simplified the code a lot too, which may have been a reason behind my simplification. And it is probably a bad reason.
I think that we could accumulate the results of the manoeuvre phases over succeeding months(turns) to get the final position bonus. When the assault is finally launched, this manoeuvre value would no longer change. That means the AI should decide to attack only if it managed to get XX value out of manoeuvering, which means it will automatically delay the assault until it gets a positive manoeuvre bonus for instance. I am not sure I want to show that much detail to a player, even a micromanager would find it boring though, so I'd probably make it always determined by the AI, though maybe the minimum manoeuvre output could be changed by the player somewhere some day.

[Mark_Everson]

I agree with everything you said Laurent!

At this point, I'll assume you have enough to go forward with. Just let me know if you want me to make any further model suggestions, or to look over proposals of yours. After you make moderate progress, I don't know what we do about the lack of sub-square entities. For testing purposes, until Gary can get that going, here's one idea I had: Just make entire squares be the "inside" of a fortified area. It seems to me that should allow testing to go quite far forward with the current handling of squares. What do you think?

[LDiCesare]

I have enough to start, but I will have some trouble with the morale/disease/starving stuff, so I will have to leave it for later. This depends on the enclosed area, and, as I cannot really do otherwise now, this area will be the whole square, which provides enough food for everyone therein...
I won't be able to exchange mail or source right now as I am changing ISPs (finally got the *** previous ones to acknowledge my decision to get rid of them).

[Richard Bruns]

Ok, I understand now. One question, though:
First you say

The advantages of having all circular fortresses be treated that way is that you can keep track explicitly of whether military units are inside or outside the fortress, as well as keep track of fortress stores of food and munitions if we decide this is worthwhile.

and then you say

We'd handle a fortress as allowing it to hold out for a number of turns proportional to its strength. In essence we're rolling the cost of providing provisions into the initial cost of the fortification.

I think it is good to keep track of food seperately. But it seems like Stregth is a constant in this model, and that it includes provisions.

If an army takes over a fort after 10 turns of siege, do they get the full benefit of the fortification when the original owners come back? I don't think they should, but it looks like they will in this model if Strength is a constant. One could even interpret the model as saying that an army gets a full set of provisions for free when they take over the fortress.

[LDiCesare]

I think it is good to keep track of food seperately. But it seems like Stregth is a constant in this model, and that it includes provisions.

No, as I understanc it, Strength is a constant but only involves the defense value of the walls. Food is kept track of separately, and should influence morale.

As I said, however, I am not able to implement the food part right now because it should be kept track of at the city/square level, and I don't want to mess with that code right now. Thus I am going to implement a siege where only assault is worth anything (not totally as I may be able to get the besieged to surrender if the opposing force is overwhelming). We'll see food afterwards, depending on whether a city is a square-within-a-square or not, and depending on how a square or city tracks food.

Right now, I am wondering how to track down the breaching stuff. The only element I have currently available to breach walls is the engineer, who can sap or mine its way under the wall, but clearly its attack values against men and buildings must be different (which might not be the case for catapults). That means I want a whole new set of data for breaching elements (engineers, catapults, cannons...) like attack and armor-piercing, and specific defense/armor/health for walls. I have to think a bit about how to model that before I code stuff I would regret.

[Mark_Everson]

Hey Richard:

Originally posted by Richard Bruns
I think it is good to keep track of food seperately. But it seems like Stregth is a constant in this model, and that it includes provisions.

Its like Laurent says, my prose was just muddied. In brief if its a case of city walls, the city's food should just be kept track of in the normal economy. The wall strength shouldn't enter into it. Forts (which wouldn't have an economy) can either have an arbitrary timer that says when the food runs out. Or they could have an explicit food supply, whose starting value depends on strength and possibly other things like Capacity. This would be consumed by whatever people ar in the fort.

If an army takes over a fort after 10 turns of siege, do they get the full benefit of the fortification when the original owners come back? I don't think they should, but it looks like they will in this model if Strength is a constant. One could even interpret the model as saying that an army gets a full set of provisions for free when they take over the fortress.

I see your point. It doesn't bother me that much though. Seems to me the new owner, if they expected counter-attack would provision it right away... YMMV


Laurent: As you say, food isn't essential to handle on the first pass. On elements that can breach, I think even standard army elements would have some small breaching capability, since soldiers can dig too... Like you say, this one needs a bit of thought before coding. Let me know if you need any input on it once you get your ideas roughed out.

Cya,

Mark

[S. Kroeze]

Though military history is still not my subject matter, I will try to make some useful comments.
In general I very much agree with Mark's original ideas.

It is almost impossible to exaggerate the importance of food supply, both for the defender AND for the attacker. To make a siege even possible the attacker has to be sure about regular provisions.
This was an important reason why many sieges were raised when winter began.

It is not true that all sieges lasted less than a year.
Just two rather famous examples: Athens during the Peloponnesian War, which was almost one continous siege, and Constantinople that withstood several long sieges.

Another point: to make a siege succesful it is very important to cut off all food supply to the city/fortress.
This can be a true problem when the circumvallated area is rather larger, because this requires more soldiers to guard all access roads.
On the other hand a large area can be a drawback for the defenders: when defending a large area with a small number of soldiers it becomes impossible to cover all weak points.

I hope my remarks are of some benefit.

Sincere regards,

S.Kroeze

[LDiCesare]

UI/gameplay questions

I now have a few questions about walls themselves and units that are to be used in a siege, mostly from a gameplay/ UI point of view.

Walls:
How do we build them, and how do we decide what kind of available fort we build?
By kind of fort, there are variations: kind (wood and motte -motte is a small , often artificial, hill, I am not sure of the English word-, wood and stone, square stone, round stone, start fort....), size (enclosed area) and width/strength (or mass, that which gives better defense bonus and harder to breach).
Providing a build fort econ order seems awkward. It is OK for provisionning money, but it doesn't say where the fort will be built.
Using an engineer unit to do the job is feasible, but inside one's territory, it is a bit awkward. A menu like "add settlers" couls be done, with a popup with type of wall, estimated construction cost and time...
Alternately, use a button like we have for roads. That has the drawback of cluttering the interface with more buttons.

For now, I will only add walls to cities in the scenarios before allowing build orders in order to test them. Another option is to automatically fortify cities, but since we don't currently spawn cities, this is not a short term solution either.

[LDiCesare]

Units and Walls stats

Units:
I don't think every unit should have a breach capacity, because there are only a small proportion of men who actually try to breach walls, and it is easier for me to have all breachers breach, all support fire and all meleers assault. Also, although we could allow some scouts/skirmishers such an ability, it would work only against low grade forts, as an unequipped scout will have trouble breaching a stone wall. Also, needing specific units (elements) would encourage people to use mixed arms, and make the presence of engineer elements in units worthwhile.

I think the following units were used to breach walls:
(Most archaic): Ballistas and giant crossbows. Rams.
(Middle ages): Catapults. Trebuchets
(Later): Couleuvrines, cannons...
And, always, engineers/sappers/miners.
I would like to limit the number of units to get engineer as the main breacher. That is because sapping/mining requires little equipment, and catapults like scorpions were built on the siege, only the metal parts being carried along.
This means I would like to have, roughly, the following walls and units (stats are relative to each other, not the final ones):

Walls (Defense is the base bonus to defender, armor and hits allow to compute resistence to breaching):

Motte + wood Defense 1 Armor 1 Hits 1 Cost 1
Wood + Stone Defense 2 Armor 2 Hits 2 Cost 3
Square stone Defense 3 Armor 2 Hits 3 Cost 7
Round Stone Defense 3 Armor 3 Hits 3 Cost 8
Star fort Defense 4 Armor 4 Hits 4 Cost 15

Units (Attack is against personnel, in the open, breach is damage dealt to walls, armor piercing negates armor of walls and personnel):
Engineer Attack 0 Breach 1* ArmorPen 0*
Ballista Attack 10 Breach 2 ArmorPen 0
Siege crossbow Attack 15 Breach 1 ArmorPen 0
Ram Attack 0 Breach 3 ArmorPen 0
Trebuchet Attack 30 Breach 3 ArmorPen 1
Early Cannon Attack 40 Breach 5 ArmorPen 2

Note that trebuchets evolved into even better weapons, but I think this can be modelled by a ballistics,siege tactics or military tactics tech making them more effective. I don't know if ballistics tech would be useful or too much of a detail.

Armor divides hits taken, but you remove armor pen before. This typically means that for a modern weapon/fort combination, (armor - armorpen) should be 1 or 2: A trebuchet reduces the square stone armor to 1, but round walls have a better protection against incoming missiles, still, cannons reduce that advantage to nothing.
* Means this is highly variable due to techs: Gunpowder gives a boost to sapping and mining, tactics or ballistics allow to build better scorpions, etc.

[Mark_Everson]

Thanks Sander, for the remarks. I had indeed meant that we should keep track of food for both attackers and defenders.

Laurent, I like your basic approach, but am not sure about exactly how these things work. I think this would be useful for both me, and the others reading this thread. Could you put together a simple example? Maybe a case where an immediate assault would be suicide, but after developing a breach (however the details work) the attack can go forward?

Hope that's not too much effort!

-Mark

[LDiCesare]

OK Mark, I try. All figures are tentative:

Consider one defender unit against three attackers. Each unit stats are attack = 1, defense = 10, health = 1. To make things simple, I suppose that leads to an average of attack/defense damage dealt each round of fight.
So in the open, the defender would suffer 0.3 hits per round, one attacker 0.1, and the defender would be out by round 4, with only 0.4 damage dealt to the attacker.

Now with a wall to defend the defender, suppose the wall provides an additional 10 defense, and prevents flanking.
Thus the attackers will be able to fight only one vs one (there is an assumption here, which is the fortifications are not undermanned), thus attackers would deal 1/20 damage instead of 3/10 in the open. That means they would win the fight in the end but lose two units to the defender before winning.
Opening a breach would reduce the 10 bonus to 0, so the attacker would still be unable to flank but deals 1/10 instead of 1/20 damage, and thus they would lose only 1 unit to the defender if the wall was breached.


In terms of time needed to make a breach, this depends on wall type and attack type. For instance, with the stats given above a size 10 (20 hits) wood and stone wall attacked by a ram would take 1.5 hit per round thus fall in 14 rounds, whereas attacked by a trebuchet it would take twice that damage and fall in 7 rounds. If the wall was a wood wall (no armor), both weapons would get rid of it in the same time (4 rounds for a 10 hits wall).
In the above example, considering you get rid of the wall in 7 rounds, and if fighters are as effective at long range as they are at close range (which actually changes lots of things but I try to be simple), there would be 7 rounds of 0.05 damage dealt, then 6 rounds of 0.1 damage to the defender, and the attacker would win in 13 rounds with 1.3 damage taken.

Here is a small table to sum it up:

	Open fight	Breached walls	Breaching with trebuchet	Breaching with ram	Unbreached wall
Damage taken by attacker	0.4	1.0	1.3	1.7	2.0
Rounds needed	4	10	13	17	20

Note that a better defense for the wall (>20) would mean direct assault fails utterly. Also, morale and such are not considered in the above example, nor is support fire...

I assume that assault and breaching take place at the same time, with one subtlety: Troops won't get into close combat until the wall is breached (or they are outstandingly superior). Defenders should target breaching weapons first, and attackers try to get rid of the defenders who attack the rams and catapults, etc. That probably means I need to detail the firepower at various ranges, instead of just close/distance as right now (I can easily get close/short/medium/long). That would allow to avoid arrows destroying catapults, make crossbows more useful in a siege than in the open due to better range/armor piercing only.

Coding mining/sapping is a bit difficult, as the attackers are protected by a lot of earth, so they cannot be targetted unless there arecounter-mine galleries... That makes things very complicated, so I'll probably just drop out details there, and just have miners fight from a given range (mine entrance).

(Edited table to get it fit)