Are there actual draw battles?
-
Wondering for a while now.
The battle calculator shows a draw percentage, sometimes but I haven't figured out when exactly a battle would be considered a draw.
IMO a battle is won if a territory has been conquered, and lost otherwise.
So when exactly is a battle a draw? -
@roiex example age of tribes
has 5 combat rounds of battle if neither side wins it becomes a draw -
@roiex I believe there are 2 cases for draws:
- All attackers and defenders are killed (some might consider this a win for the defenders but its considered a draw right now)
- Limited battle rounds so that both attacker and defender have units left (Civil War, Age of Tribes, etc)
-
@redrum good point
-
@redrum Correct. The "draw" existed many years before anyone even considered adding limited combat rounds.
So, this is a thing that it is not actually right.
Normally, when both sides gets eliminated, that is a win for the defender, and this is also how it works for the sounds, where you get the losing sound in all cases you retreat or lose all your units, no matter the enemy.
However, the battlecalculator incorrectly assumes that the situation in which both the attacker and the destroyer get totally destroyed is a "Draw".
So, if a power 4 unit attacks a power 4 unit you have a 50% draw probability.
That should not be called "draw" but "defender wins with 0 hitpoints total left".
To this tradition it has been added the limited combat round thing, and in that case "Draw" means "Stalemate" + "defender wins with 0 hitpoints total left", which is a sum that doesn't really make that much sense.
p.s.: The limited combat round, last time I checked, is a serious problem for the AI, because, with low combat rounds, it thinks that the battles are worse then they are, if they stop before any sides getting destroyed, as that reduces the "Attacker Wins" probability. That is a case in which "Fast AI" performs much better than "Hard AI" (unless this matter has been addressed).
-
-
@cernel Rather than having Win / Lose / Draw I would suggest having as basics only Win / Lose / Stalemate (stalemate only for limited combat rounds).
Then, it would be good if you can click on "Lose" and have all a list of:"defender wins with 0 hitpoints total left"=...%
"defender wins with 1 hitpoints total left"=...%
"defender wins with 2 hitpoints total left"=...%
"defender wins with 3 hitpoints total left"=...%
...Where the first one would be the current "draw", for not stalematable battles.
-
@roiex @Cernel I don't really have a strong opinion on no units left being a draw or a win for the defender that's just how its always been to my knowledge.
If we did change this though I'd have to look to see if anything in the engine or the AI cares about draws becoming loses in the case of no units left.
@Cernel The AI doesn't really handle limited combat rounds very well. I've never added logic to handle maps like age of tribes or Civil War. Limited combat rounds is a bit of a different game since you'll see more retreats and there is then the concept of enemy units sitting in a friendly territory during other phases.
-
-
@redrum I'm reading the rulebook of the latest re-edition of A&A Anniversary, and, there, there is no mention of "draw", but they say that you win only if you have units left and the other side doesn't. So, following what is said there, both the attacker and the defender losing all units would not be a win for the defender, nor for the attacker, so I guess that is what we call a draw.
In my opinion, it makes more sense to consider it a win for the defender, because eventual ownership changes are impeded and all infrastructures are kept and, moreover, in our case, the defender would also capture all attacking infrastructures.
On the other hand, if we consider that a draw, then I think we should update our sounds to have a "draw" sound, or nothing at all, instead of playing the "battle lost" sound, as it works now.
I think the only thing you need to check are those conditions testing who won battles, in case of any changes. -
@cernel The case in which it would feel a draw the most, when both sides are obliterated, is for sea battles, with no infrastructures, and no territory attachment for the sea zone.
-
@roiex said in Are there actual draw battles?:
I'd even go a step further and say any kind of draw should count as a win for the defender, because it's pointless for an attacker to go for a draw, a lot of units have a higher defense value anyways
I don't agree with this. You can have a totally sensible grindy oriented game in which you are hardly ever supposed to win any battles. For example, I could make a map in which you have 1 round battles only and all units roll at 1 with a 12 sided dice. In that case, stalemate is just how the game normally works, and hardly tells anything about who is winning or losing. In this case, "Hard AI" would think that he can almost never win, and would never attack anything.
-
@cernel he was reffering to the battle calc changes
-
-
Well, anyways, as we all know, the reall matter is if the attacker wins the battle or not. If the defender wins it or not has no immediate effect on anything (even in the case of attacking infrastructures). Knowing if the defender is left with 0 or 1+ hitpoints may be useful and interesting, but most times is closely marginal.
Thinking again about it, I don't feel strongly in any directions, and would be fine with keeping the current "draw". Just it really needs to be split apart from the "stalemate", for the games with limited combat rounds. -
Regarding attacking infrastructures, the last time I checked the behaviour was that sending an attacking infrastructure in an undefended territory conquers the territory; instead, if a battle is done and both attackers and defenders are destroyer, attacking infrastructures are conquered by the defender.
I think this should be harmonized, in that either the attacking infrastructures conquer the territory in both cases or are gifted to the defender in both cases.
I think an attacking infrastructure alone should not conquer a territory, but getting conquered, in doing so.
I've not tested this behaviour recently.
