Fortifications and Sieges
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.
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.
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.
Hey Richard,
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.Originally posted by Richard Bruns
This seems like it could become frightfully complex.
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.Since a turn represents a year, and most sieges were resolved in a year, there isn't any need to get this detailed.
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?
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.
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?
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).
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.
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.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.
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.
Hey Richard:
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.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.
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... YMMVIf 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.
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
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
Jews have the Torah, Zionists have a State
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.
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.
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
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)
Last edited by LDiCesare; October 29, 2002 at 03:25.
Thanks for the example Laurent! It looks basically reasonable to me, although I'm not as with it tonight as I might be
I'm embarassed to ask, but is a round a tick, a turn? If a round is a tick then these times may be too fast, if a turn, maybe too slow... I'll await the definition, and more brain-power, before I comment further.
A round is somewhat abstract here, as are the figures. In the code, there are several rounds of fight in a tick, so the figures are really bad here. I don't recall the max number of rounds in a tick, must be around 30. The round stuff is there mainly to allow fight to be staged at different distances (long range, then the enemies move to medium, short range and melee, each move taking a number of rounds depending on the mobility of the units and their desire to move closer).
If the model sounds OK, I will code the stuff that is still missing, and then change my batch test to tune the figures. Hopefully I will have an e-mail working to send the code when I am done.
Hey Laurent, I agree its good enough for you to take a shot at it. If something doesn't work I'm sure we can get around it with a few rules tweaks. Looking forward to checking it out!
I have a first funtional code, but I have a few issues.
First, I had to add a variable to tell the economic model to shut up because I cannot model a siege if the square isn't owned, and the economy doesn't allow me to own a square with no population, or I need to create an economy in order to run a batch military test, which I don't want to (fixing it everytime the econ changes - arglll, no, htank you). I had to touch a few classes here and there, also about the City class which holds some Wall information. I am not yet clear as to where the wall info will be stored, but I think the xml will add forts to a location the way a city is added to a location.
Now my balancing problems:
I have made a test where a phalanx is in a wooden fort, and is attacked by legions. To make things even, I can test with legion inside instead of phalanx. I assume legions have engineers who can sap the walls. Now, what should be the ratio number of legions needed in order to win the fight? In the open 2 vs 1 is enough, and 1 vs 1 provides roughly 50% (slightly less because of terrain advantage for defender). What if it was warrior vs. warrior (i.e. no wall-breaching)?
These questions are very important as it will decide the value of defense (warriors) and health (legion with engineers) of the wall.
Right now, I decided that it should be at least 3 vs. 1 before the attacker would decide an assault, but maybe 2 is enough? What ratios should we have? If you have no idea about engineers/sappers. opinions about rams/trebuchets/whatever are welcome too.
Hi Laurent!
Ok with me, we can figure how to do it right when the city stuff is done properly.Originally posted by LDiCesare
I have a first funtional code, but I have a few issues.
First, I had to add a variable to tell the economic model to shut up because I cannot model a siege if the square isn't owned, (snip)
I wouldn't fine-tune too much up front. For your case with equivalent units with one side behind wooden walls something like 3:1 for success sounds ok provisionally. I would expect the attackers to lose between 1/3 and 2/3 of the attacking force at 3:1. Of course wooden walls would be relatively easy to breach, and that would make the attack less expensive.Now my balancing problems:
I have made a test where a phalanx is in a wooden fort, and is attacked by legions. To make things even, I can test with legion inside instead of phalanx. I assume legions have engineers who can sap the walls. Now, what should be the ratio number of legions needed in order to win the fight? In the open 2 vs 1 is enough, and 1 vs 1 provides roughly 50% (slightly less because of terrain advantage for defender). What if it was warrior vs. warrior (i.e. no wall-breaching)?
These questions are very important as it will decide the value of defense (warriors) and health (legion with engineers) of the wall.
Right now, I decided that it should be at least 3 vs. 1 before the attacker would decide an assault, but maybe 2 is enough? What ratios should we have? If you have no idea about engineers/sappers. opinions about rams/trebuchets/whatever are welcome too.
On the issue of rams etc, in my mind we should just have a "siege weapons" element. It would be costly, and move slowly, and have primarily a 'breaching' attack. I don't see the point of modelling in detail lots of obscure siege weapons. What do you think? If you agree, I'd just set the cost and breaching capability together so that the unit is cost-effective compared with 'normal' military units.
I agree we can have few siege weapons. I thought about having one engineer to encompass all mining/sapping/light catapult(scorpion) stuff, and other elements more detailed.
I agree that having a single element could be a good thing, but it has to be very tech-dependent, as there were real evolutions in siege warfare, from ballistas to trebuchets. Calling the thing "catapult" would be nicer than "siege weapon". One important difference between various siege weapons is range: sap, mine, rams, are all close-range, whereas catapults are long range. So engineer would be the short-range, and catapult the long-range breaching element. Later in the game we would have engineer and cannon.
Note that the tuning I do is not really "fine". I have to check the model so that it doesn't behave in too chaotic a way. Adding a single unit can make lots of changes right now.
A last point on engineer elements. I think they should be able to repair their walls a bit during the siege, not much, but a bit (it was typical to counter-sap by adding a second stone wall behind the first, or to build a wooden wall behind a weakened stone wall in order to delay the breach more. I won't code it right now, though, as I have to balance things out before.
Hey Laurent, everything you say sounds fine to me. I had indeed expected there to be changes of siege weapon effectiveness with tech. Your two-element approach (engineers and catapult or whatever) seems quite good to me.
Can you check out the discussion in the D7 thread? Pierre is finding Clash to run really slow for him, and it would be good to figure out if its a garbage collection issue with the mac java implementation, or just plain the game takes up that much memory and his system can't handle it. If you're up it, it would be good for you to work together on it since you can work directly without the web!
I have wondered how to do in order to be able to build fortresses. Walls look like units, but you want to place them manually on the map, a bit like roads.
So I think we need a button to place forts as we have one to place roads. There would be a button for selection of the square, a special section in the econ orders for the various fort types (wood, stone...) and when funds are allocated and a square is clicked, the fort starts being built. Note that ideally, the button should spawn a dialogue asking for the kind of wall asked for, and how much income is to be spent on it, at the province and at the civ levels. Otherwise there is no telling whether fort1 is to be a stone fort and stone2 a wood fort or vice versa.
Also, how does that translate into econ orders? I checked the road-building stuff, and it is quite hard-coded. I don't want to do the same for forts. I need a way to be able to give a build infrastructure order to a square, or to precise a target square to a buildable, which may not be the capital of the province (contrary to what happens with units). Ideas are welcome.
Bonjour Laurent, sorry I missed this a while ago. . .
Sounds good to me. Priority for building forts will be arranged the same way they were ordered in time.Originally posted by LDiCesare
I have wondered how to do in order to be able to build fortresses. Walls look like units, but you want to place them manually on the map, a bit like roads.
So I think we need a button to place forts as we have one to place roads. (snip)
I would do this the same as roads for the near future. Specifically there would be just a "fort-building" class, analagous to the road-building one. The class would build up points, and when you get to the point cost for the first things on the list, it'd be done. So as to make it not be completely unrealistic, we could determine the max rate of building locally so you can't flash-build forts. In terms of programming, a fort could not be built until a number of turns passes such that it could have been built locally. But to keep it simple there would just be one civ-wide pool of fort and wall-building points. Sound ok to you?Also, how does that translate into econ orders? I checked the road-building stuff, and it is quite hard-coded. I don't want to do the same for forts. I need a way to be able to give a build infrastructure order to a square, or to precise a target square to a buildable, which may not be the capital of the province (contrary to what happens with units). Ideas are welcome.
The difference between road and fort-building is that there are different kinds of forts. This means I need a class which can build different kinds of infrastructure. I'd rather build a new one which would also specify what kind of UI it wants, so I could fold the roads into its framework. There are differences since one needs path, the other doesn't need it, but I think it can be done, and it would allow for roads, railroads, etc.
Hey Laurent:
IMO fort construction is relatively similar whether it be a wooden palisade or a stone fort. Local materials are used, and the most difficult input is labor. I think we should spec out a fort as to exactly what the player wants, and then calculate the cost. The cost would simply be the number of fort infrastructure points needed to build it. It is a simplification, but I personally don't think its worthwhile to have many different classes of fort infra. Maybe one or two over all of history should do. Perhaps rather than calling the wooden one wooden, we should call it a "light wall" or some such. That could cover thin walls made of mud bricks and such which are roughly equivalent to wooden ones. Then we wouldn't get people complaining about building wooden walls in a desert.Originally posted by LDiCesare
The difference between road and fort-building is that there are different kinds of forts. This means I need a class which can build different kinds of infrastructure.
Sounds reasonable to me. Certainly building walls like the Great Wall have something in common with road building. But it might overcomplicate things in the short run to put these two together.I'd rather build a new one which would also specify what kind of UI it wants, so I could fold the roads into its framework. There are differences since one needs path, the other doesn't need it, but I think it can be done, and it would allow for roads, railroads, etc.
Sorry I used the word infrastructure incorrectly. I ment different results, walls being of different kinds the same way units are of different kinds. Overall I think we are in agreement.
Hi Mark just asked me to post my comment from the Demo 7.2 Proposal! thread here.
(Please note that I have not yet read the discussion here, so I appologice if some of my comments might seem out of place)
Well, since Mark invites comments, I'd just as well vent one of my main frustrations as to walls in civ-type games.
As far as I have been able to determine there has been two versions of the same model as to implementing them:
1. Give the defender a fixed defencive bonus (CTP)
2. Give the defender a persentage bonus (CIV)
And to tell the truth non of them makes much sence.
In reality a single troop of archers - with sufficient supply arrows that is - could hold of a substantial force of non-ranged attackers indefinately and slowly wear them down, by picking off anyone stupid enough to enter their range.
What I'm saying is that no force, no mater how large, should be able to defeat a garison in combat if the garrison is protected by walls, unless they have some form of wall (or gate) breaching equipment. They can of cause besiege the defenders and wait for them to starve.
So in order to add reality to walls only certain units, or units with certain abilities should be able to attack walls and the units within.
Weaponds for wall breaching could be:
Ancient:
- Balistas
- Catapults
Middle age:
- Explosives
- Canons
Modern age
- Any artilery or heavy guns
Weaponds for attacking units within walls could be:
Ancient:
- Balistas with fire arrows
- Catapults with burning shots (tar)
- Catapults with "buckshots"
Middle age:
- Canons with axploding amo
Modern age
- Any artilery
Visit my CTP-page and get TileEdit and a few other CTP related programs.
Download and test SpriteEdit development build.
Good points Martin, except they apply mostly for stone forts. There are examples of wooden forts which have been burnt down by a single man (like a man removing leather hides from a part of the wall, allowing to burn it down), also, there are examples of entering a walled city by outwitting the defenders (think Troy, also Bertrand du Guesclin in the 100 year war).
Note that Age Of Wonder had a siege model like what you suggest, but they changed it in AoW2 so you wouldn't need breachers.
The current model gives a fixed defense bonus but also prevents flanking. That means hand-to-hand units can't attack at more than one on one. Plus it allows for siege weapons.
The use of siege weapons can make a big difference, however, the defense bonus needed to mlake it so is very big. You will see that in the next demo, as I made a scenario specific to test sieges. In it, you can take a walled city without siege engines, but it will take lots of casualties and lots of time. Too much time, in fact.
The question is what defense value should the walls provide? You say infinite against close-weapons, and limited against siege weapons. I reached a very big value in the siege scenario. Playtest will tell.
Well Laurent, you do have a point, and I agree that most cases can be modeled by giving the defenders a wery high defence bonus.
After having read some of the thread, I see that you plan to include provision, morale, helth etc. in the siege model. That is enocuraging so I look forward to play your scenario.
Visit my CTP-page and get TileEdit and a few other CTP related programs.
Download and test SpriteEdit development build.
Posting Permissions
Reply With Quote
Bookmarks