My new “CaptureAction” object really struck gold in terms of refactoring the capture mechanism, so it was wonderfully easy going and rewarding testing the code. There’s still a glut of untidied code, but the previous version of the code was still progressively destructive — the state necessary for decision making got trampled as the code proceeded.
It also revealed, to me at least, that we no-longer need the icky and confusing concept of ‘control’ in addition to ‘ownership’.
‘Control’ is defined as the side to have last held all of the armybases in the town at once, while ‘Ownership’ is defined as the side to have last held all of the facilities (including armybases) at once.
The purpose of control was to provide a cutoff valve for supply and spawning: take all the town’s ABs and the other guy can no-longer spawn there or get supply.
Brigades makes that moot: take all the armybases and the army brigades get bounced. And the enemy can’t move replacements in across contested links, which is a far more intuitive and tangible implementation of control that requires no sneaky, special, hidden flags.
Control also has a bearing on supply flow, but I think contention is a better control for that: contest a town and it stops serving as a supply node, only a terminus.
Lastly, control affected firebases: defensive firebases open up from rear towns to towns where owner + controller didn’t match. It’s what makes fallback work. However, its also solved more intuitively by the brigade-projected firebases.
What probably makes the most sense is to drop control and the old concept of firebases between towns. If we made all firebases brigade-projected, it all gets simpler and more intuitive to play and in terms of the code.