[Feature] Terrain-aware attacks with gradual frontier consolidation #6229

Summary

hi, i'm an old contributor coming back after a while. i previously worked on a few things here, mainly the PseudoRandom fixes (#2046) and the singleplayer bot slider / FluentSlider changes (#2148, #2682, #2778).

i've been looking through the attack logic recently and got interested in how territory actually expands.

i was watching some mapping videos and started thinking about a different kind of territorial growth.

right now attacks tend to expand fairly evenly wherever the border allows it. sometimes a front moves ahead and wraps around another player very quickly, but overall it feels like pushing an entire border at once.

what i had in mind was something closer to slime moving through terrain. a narrow connection might form between two places first, then gradually widen until the territory becomes a more continuous shape.

i think the existing attack system already does the second part pretty well. what interests me is whether we could change how an advance initially develops without throwing away the current mechanics.

Problem

land attacks currently send a target player and troop count, but not the tile the player clicked.

AttackExecution then collects eligible tiles along the shared border and uses a priority queue based on terrain, adjacent friendly tiles, randomness and time.

the existing system is already terrain-sensitive and tends to fill gaps naturally. that's useful, and i don't think it should be replaced entirely. but it doesn't really distinguish between advancing towards something and consolidating territory already reached.

we also have the previous directed attack work in #112 and #2262, which got fairly far. it added click-based direction, BFS proximity and time decay. #2855 separately explored starting an attack from the closest border.

i'd rather build from that than reinvent it. the part i'm interested in changing is what happens between advancing towards a location and filling the territory behind it.

Proposed solution

i'd like to experiment with a terrain-weighted expansion model where advancing and consolidating are related, but don't necessarily happen at the same rate.

roughly:

click somewhere in enemy territory
             |
  terrain-aware preference
             |
  narrow connected advances
             |
  expansion along the sides
             |
  gradually smoother territory

the clicked location would be a soft target, not a mandatory destination.

a front could move through relatively cheap terrain, avoid a mountain, split around an obstacle, or even pass around the clicked location if the surrounding route is preferable.

the territory behind that advance would still be expanding at the same time. i'm not proposing that the whole army moves as a thin line and then suddenly starts filling everything afterward.

A rough mathematical model

i think this could be expressed without an actual fluid simulation.

first, use a terrain-weighted distance from the clicked location:

D(x) = minimum sum of terrain costs from x to the target

then for a candidate tile v, reached from friendly tile u:

progress(u, v) = (D(u) - D(v)) / terrain_cost(u, v)
border_change(v) = 4 - 2 * friendly_neighbors(v)

the second expression is simply the change in perimeter from adding a tile on a regular four-neighbor grid. extending a thin tip increases the border, while filling a gap tends to reduce it.

a possible priority function would be:

priority(v) ≈ adjusted_existing_priority(v)
              - a * progress(u, v)
              + b * local_age(u) * border_change(v)

lower priority gets conquered first, just like the current min-heap.

local_age here means how long that part of the advance has been established, not how long the player has owned the territory in general. it could be a bounded increasing function of time.

the idea is that recently formed fronts are freer to advance, while older parts gradually favor filling gaps and widening existing connections.

the existing priority already rewards tiles with more friendly neighbors, so i'd want to reweight that term rather than blindly add another smoothing bonus on top of it.

this is just the proposed model, not a finalized formula. we'd need to see whether it actually produces the intended behavior before deciding how much complexity is justified.

What i'd reuse from the older PRs

#2262 would be the main starting point.

it already has the click-tile plumbing, directional preference, topology-aware BFS proximity, time decay and tests for directed attacks.

i'd keep the click propagation and use its implementation as the comparison baseline. the main experiments would be replacing the unweighted BFS preference with terrain-weighted traversal costs, and making consolidation depend on local frontier development instead of only fading the directional effect globally.

the difference isn't just making #2262 more directional. i'd actually like the advance to remain somewhat free to move away from the target when the terrain makes that preferable.

#2855 is also relevant, particularly its nearest-border selection. i wouldn't bring back the hold-key requirement or the fixed 1.2x attack loss penalty as part of this proposal. the mobile control concerns raised on that PR are worth avoiding altogether.

both PRs predate the current engine package split, so i'd expect to reuse their ideas and relevant logic rather than directly merge their old branches.

Balance

i actually think this could work reasonably well for balance, provided we keep the overall attack budget and troop costs comparable.

a more concentrated advance would let you reach a location earlier, but it would also leave a longer, thinner and more exposed border behind.

if someone clicks far into enemy territory and tries to push all the way towards a city or missile silo, the connection could be cut by another player before the territory behind it catches up.

that's kinda the point of the thin connections.

you're trading a more evenly distributed front for a potentially faster but less secure advance. reaching somewhere and being able to hold it would become two different problems.

i wouldn't want this to become a free shortcut to surrounding an opponent, though. the current attack speed also depends on border size, and thin advances could interact with that in unexpected ways.

if the new model captures more territory with the same troops, or makes annexation significantly easier without a reasonable counterplay, then it's a buff rather than a tradeoff.

the recent annexation work (#6191) is also a reason to test narrow corridors and severed territory carefully.

Initial scope

i'd start with existing terrain types and the existing land attack system.

no new army units, supply lines, roads or building mechanics.

cities, factories, SAMs and missile silos might eventually be useful as strategic attractors for attacks, but i'd keep that as a later experiment. there's already enough to figure out just from terrain and frontier behavior.

i'd also keep the first implementation deterministic and compare it against the current attack algorithm and #2262. the previous PR already ran into BFS performance concerns, and adding a weighted search shouldn't get a free pass there.

the important comparisons would be how far an advance reaches, how narrow and exposed the connection becomes, how quickly it fills out afterward, and whether any of that changes troop efficiency or simulation performance.

also worth checking how priority updates would work with the current heap, since local frontier age changes over time while queued priorities don't automatically update.

Why this seems to fit OpenFront

i don't think this needs to become a separate combat or movement system.

OpenFront already has much of the machinery for it. the priority queue, terrain costs, border ownership, attack budgets and annexation logic are all there.

the missing part is mostly how those systems influence where the next tile gets conquered.

i also like that this could add some tactical choice without adding another control to the UI.

the player still clicks somewhere to attack. the difference is that the click has a spatial meaning, and the resulting territory might grow in a way that reflects the terrain rather than simply expanding across the available border.

not trying to turn OpenFront into a historical wargame. i just think territory could grow in a more interesting way while still feeling like OpenFront.

Alternatives considered

just revive #2262

probably the most reasonable baseline.

it already solves much of the click-direction problem and includes the topology-aware proximity work i'd otherwise need to write.

but its main behavior is still directing an attack towards a clicked location and gradually reverting to the old expansion priority.

i'm interested in what happens after the initial advance, and whether that could depend on the age and shape of the local front instead.

use shortest-path routing towards the clicked tile

calculate the cheapest path and expand along it.

simpler to reason about, but probably too rigid.

i don't want the army to draw a route and then obediently follow it. i'd rather have the terrain influence several competing advances without forcing any one path.

use #2855's localized starting point only

this would help the player select which border to attack from, and might be enough for some of the current directional attack problems.

but it doesn't really address the growth shape or what happens to the territory behind the advancing front.

the previous mobile UI concerns also make me reluctant to introduce a separate attack input just for this.

implement actual fluid dynamics or separate armies

probably unnecessary.

a proper fluid simulation sounds fun until we're debugging it inside a deterministic multiplayer game. i think a relatively small change to frontier priority would be a much better first experiment.

Additional context

there's some existing mathematical work that seems relevant here. i'm treating these as models to borrow ideas from, not as proof that this would improve balance or accurately recreate historical military expansion.

• Wilkinson & Willemsen (1983), Invasion percolation: a new form of percolation theory. Growth along paths of lower resistance, rather than uniform expansion. https://doi.org/10.1088/0305-4470/16/14/028

• Auffinger, Damron & Hanson, 50 Years of First-Passage Percolation. Weighted traversal times and the geometry of spatial growth. https://arxiv.org/abs/1511.03262

• Evans, Soner & Souganidis (1992), Phase transitions and generalized motion by mean curvature. Mostly a reference for boundary smoothing. a discrete perimeter penalty would be much simpler than implementing curvature flow. https://doi.org/10.1002/cpa.3160450903

• Saffman & Taylor (1958), The penetration of a fluid into a porous medium or Hele-Shaw cell containing a more viscous liquid. A physical analogy for narrow advancing fronts, not a direct model of territory capture. https://doi.org/10.1098/rspa.1958.0085

related OpenFront work:

• Directed attack #112: Directed attack
• Feature/directed attacks (Need Design Feedback) #2262: Feature/directed attacks
• feat: Add localized attack hold key #2855: Localized attack
• fix: unified bounded annexation and revert severed clusters pass #6191: Unified bounded annexation

mostly putting this up before touching the code because #112 is already assigned, and i'd rather coordinate than accidentally start another version of the same work.

i think there's room to experiment beyond what #2262 did, but whether it's actually a better game mechanic is something i'd want to demonstrate rather than assume.

i'd start with a small, reproducible comparison using the existing algorithm and #2262 as baselines, then see whether the terrain and consolidation model gives us anything useful.

Assignment

• i'd like to work on this myself, provided the scope is approved and doesn't conflict with the existing assignment on Directed attack #112.