Tile attack limit

keldath

LivE LonG AnD PrOsPeR
Joined
Dec 20, 2005
Messages
7,362
Location
israel
Hi fellow modders,

lately,
I have been thinking about unit limit per tile,
Or unit stack limitations to mitigate giant stacks. After being taken out in my game in a swift decimation to ai stacks of doom...

There has been some cool features done, vip mod for instance, realism invictus and more.

So,
Trying to be unique, and something that will be innovative in that area.

My current idea,
Have each tile, an attack limit .
For exmple, atile will aloow to be attacked from, 10 times.
Each turn the usage will be reset.
Each tile will allow EAch player to attack 10 times.
Ill cache tge number of attacks done on the terrain cpp? /Map cpp?
On every attack check, ill check for the limit.

Furthur tweaks, can be that some units cost 2 points of the attack count of a tile , some 1.
This will add some Verity to types if units and maybe promotions.
I can do also improvements that can reduce the counters as well.

I know this maybe out of real world logics .
But,i think it could be a good gameplay feature to provide a refresh stratigic thinking to gameplay.

Id love for some insights and feedback on the matter.

Cheers
 
In Unit:CanAttack or CanMoveInto make a loop checking all Players which checks array of plots attacked.
It is going to be heavy on the CPU, and slow things down considerably (I think). Also the AI will... well you know the AI ;)
 
Well,
If the limit will be without per player,
A loop wont be needed.
Just a check of the current count of attacks made from a tile.
Note the the limit on self tile , not all available tiles around a unit.
Every addition sometines take a toll on cpu.
I usually try the least.

Ai should handle it ok,
As it wont harm the stack sizes.
 
Last edited:
Three years ago, @devolution (tentatively) implemented an attack limit based on AdvCiv: Git commit
This keeps a separate count for every direction. I had posted a few comments on that idea back then at the start of this post. Well, most of that won't apply when a single count is used for all directions.
 
Hey f1rpo,

Interesting.
Ill have a look.

In my idea,i dont have do loops,
Just keep cache per plot.
Add +1 when an attack is made from a plot.
Max it at some number.
Upon an pre attack,canattack,camoveinto or such check for the current tile attacks val and allow or not .

Its easier on cpu , cause no loops over multiple areas are made.
Later on i can add some values for tiles in terms of path according to the attack value,meaning, dont move into tiles that was used much during this turn.

Ai should be fine with this method i assume.

The caching the count per player.
Assuming a situation where 10 unit stack attacked, and died off.
Where the limit is 10.
It will create an empty tile that the player,cannot attack again from this turn.
I think i can live with that.
Maybe add the unit count per tile and also checking if the number is 0,reset it .
The counter should be updated on unit kill
Or move. But thats more loops.
So going with empty tile mazed out per player for the turn,shoulnd be too bad.
I can color the tiles ,like i did with units blockade and my city states.
 
Last edited:
Oh, your limit would apply to attacks made from a tile. In that case, my (linked) comment about Mounted (and other fast) units becoming more valuable as attackers – also against cities – does apply (because they can fan out to attack from tiles whose limit isn't yet exhausted). And Roads will become more potent too.

Regarding the AI: Let's consider the standard situation of a large AI stack, say, 20 units moving toward an enemy (AI) city with strong defenders, say, 10 defenders, among them 5 fully fortified Longbowmen. Since there isn't much of a risk of a counterattack, a human player would split the attacking stack into 2 times 10 to work around the attack limit. I don't see the AI do that without code additions. (If the attackers are all 2-movers and have both moves available when the attack begins, then I guess the AI will continue attacking via an adjacent tile once the attack limit is reached.)

When the 20-unit stack is affected by the combat limit, meaning that only 10 units will be able to attack right away and further attacks won't happen until next turn, then the AI will probably be too willing to attack unless adjustments are made to the stack-vs-stack combat evaluation functions. Because the first 5 attacks will be suicide missions that merely damage the entrenched Longbows. May well not be worth it when only 5 more attacks are allowed, i.e. when the damaged Longbows will get a chance to retreat or heal/ be promoted.
 
Yes, faster units gets the advantage indeed.

20 stack, human,
So yeah the hunan will split.
They ai gotta get code to split the stack as well.
More code in the relevent functions .

In general, its not easy to take down a city in the game.
That lead s me to think, in regards to this tike limit,
Maybe heal should be denied if in war with adjacent enemy units.
Im just exploring ways to mitigate snow ball stacks.

Perhaps adding some code to the descition on spliting stacks shouldn't be that conplicated.
 
Perhaps adding some code to the descition on spliting stacks shouldn't be that conplicated.
I think AI stacks generally move to target tiles that they may want to attack from. So in some CvUnitAI routine that most AI stacks go through, one would have to check whether the stack will reach its destination on the next turn, identify a tile that the AI will then likely wish to attack, figure out whether that tile could also be attacked from a different direction and evaluate whether it's safe (wrt. counterattacks) to split up. Would also have to make sure that the AI doesn't merge stacks again or turns around because each individual 10-unit stack seems to small for starting an attack. Don't know to what extent the AI is already tallying its combat power across nearby stacks.
 
I see your point.
You can look broadly then i am.
I woulnd want to hurt ai code toake bad mistakes due to limitations.

Seems ill have to rereview this.
Another thought is to add some immobile unit that can attack nor defend, but with greater strength to act like city hp or something.
Tge goal is to stop,
Stack of doom that will wipe you out once it comes for your cities.
I tried to use the ranged attack i made.
But it cant stop a full frontal stack.
I wanna buy some time before a city falls and there is nothing we can do about it.
 
In my book, limiting attacks in a way that encourages stacks to be split up would be more about giving combat more tactical depth. That goal may justify challenging AI changes, but, yeah, just for slowing down wars of conquest, it's perhaps a disproportionate effort.

A per-turn limit on the number of attacks against a tile would have fewer tactical implications; can't really work around that. AI stack combat evaluation functions would arguably still have to be adjusted. And it's a pretty big advantage for defenders whenever large stacks square off, perhaps to the point of creating standoffs where neither side has an incentive to strike first.

Restrictions on healing have a potential for slowing an invading stack down. This could also tie in with your ranged attacks dealing (non-lethal) damage to the invaders. One could also let bombarding siege units take some damage (representing wear or spent ammunition) – though big stacks don't necessarily bombard before attacking.

AdvCiv already treats cities under occupation as friendly non-city tiles when it comes to healing. Could double down on this by treating them as neutral(?) tiles. And possibly treat cities culturally owned by a war enemy as friendly non-cities once occupation has ended? AdvCiv also shortens the occupation duration to just 3 turns (if the occupying force is large enough) rather than 1 turn per population; you might want to revert that or cap the AdvCiv probability of reducing the occupation timer.
Another thought is to add some immobile unit that can attack nor defend, but with greater strength to act like city hp or something.
Perhaps you could simply change some unit stats to make a Machine-Gun-like unit available earlier. Or an earlier Draft ability that yields defensive units?
 
i see eye yo eye with most of your consulting usually.

i wouldn't wanna go in to another tough adventure of coding . preferred some easier way out...
against a tile
that would alsobog down game speed i guess, per tiles checks.

healing, maybe interesting take, but i dunno if thats something that should be a part of the solution. could also get complicated and un natural.

rather than 1 turn per population
i remember some of this from when i got you the bug of occupation no zero'ing :)

Machine-Gun-like
defense early units, interesting.
or just 1, immobile with higher strength, upgradable for free .
to act as a city final strength , much higher then any other available unit.
that cannot inflict damage, only get.
maybe generated with city build .
i had thought once about a siege unit that will be like that for ranged city attack like in civ5+.
 
or just 1, immobile with higher strength, upgradable for free .
to act as a city final strength , much higher then any other available unit.
that cannot inflict damage, only get.
So it would take multiple attacks to destroy it? Not really how the combat system works unless you already have a mechanism like defender withdrawal. Maybe the unit could, technically, replace itself a few times after getting destroyed, but, if one goes down this road, it might be cleaner to draft (automatically?) weak "militia" units from the city population.
 
How about a different approach:
Just UPT but there is no hard limit, instead when going above the limit, units start to take damage per turn (just like from terrain features).
E.g. there is a UPT limit of 10 , and there are 11 units on the tile, they all take 5% damage/turn. If it's 12 units, damage goes up to 10%, and so on, until reaching the cap of 50% damage/turn.

I don't know if it's a good idea or not, just brainstorming :)
 
Hello, my mod does what you say, you can only attack from the same square 3 times.


You have the source code in the thread.
 
Top Bottom