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.


With brigades owning their own FB’s to the town the Brigade is… well… “owning” (whether ‘controlled’ or not) means you must decide:

1) FB’s are *always* up (nondestructible)

2) FB’s can be blown down (but how does a brigade get its own FB back up?) <–assumes both FB’s can be open at the same time.

Assuming 1) is an option: I believe this is more fun, more likely to have meeting engagements between towns and brings ALL fb’s in the disputed town sector into play. VERY 360* and will result in lots of “lost” towns being saved. This would also reward more stacking in a sector, and require less surgical skill in moving brigades…a flattening of talent factor.

Erh, Joker, I’m talking about the existing system of brigade firebases minus static frontline FBs.

errghggh…I get it…now. *skulks away in the night*

The messiness of modifying the existing AB/FB code relationships has long been the key response to suggestions regarding elimination of the FB concept and significant densification of the AB mesh. The point of such densification would be to devalue camping by assuring availability of multiple alternate spawn points within tactical-movement distance, and by indicating in the spawn UI the enemy ground/sea force level near each such friendly spawn point.

Any chance that as an alternative to Brigade-projected FBs, densification of the AB mesh toward ABs located at roughly the present FB-to-AB spacing could be considered?

Personally I think the entire mechanism of the FB *can* be disposed of, with the implementation of mobile spawns now tried, tested, & mature code.
What is an FB except a glorified MSP? Add something more substantial, like the ability to either combine MSPs or some other deployable entity into a FB-like creature able to spawn the entire breadth of the brigade’s spawnlist, albeit not an infinite (nor even large) quantity.

This solves handfuls of problems with the current FB & capture paradigms, gets rid of the whole idea of ‘camping’ FBs because their location is no longer predictable, and then provides brigades with a great deal more tactical flexibility either on attack (to place their FB in creative locations) or defense. Finally, the removal of static FBs restores a real-world level of emphasis on recon, patrol, and tactical intel.

You’re both a little divorced from reality. The messiness fo the FB code has always made us wary of small changes to FB code, a one line FB change could mean weeks and months of debugging and FBs are anything but glorified MSPs, and any time someone says “real-world” and “recon” or “patrol”, what they are saying is “boring”, “tedious”, “mind numbing” and “unsustainable” as adjectives to “gameplay”. Requiring an infantry in every AB bunker along the frontline would restore a real-world level of security and guard duty. Giving HCs friendly fire ability or allowing them to toss your account in the brig, those would restore a real-world emphasis on obedience and discipline.

Our terrain editor and terrain systems simply don’t allow us to place large objects in the game world except by hand. AB densification would take 2-3 years of continuous terrain editing and the ability to deploy something like an FB into the gameworld from the host is just not feasible with our current systems.

Also, you really haven’t thought your own idea through in full, styopa. Your description is that of someone imagining being able to relocate his FB in a gameworld that still has FBs.

In your game world, everything works differently than it used to. There are no static FBs. So now before you can begin your attack, before the HCs will give you an AO, you have to drive your FB upto 110km to where you’re going to deploy it. On arrival, you have to hope that the enemy hasn’t deployed one behind you. They did? Ok, now you have to find that. Guess you might as well despawn. Now, the enemy isn’t spawning, and there’s a 4km x 4km radius around the town that you have to search for this FB. Once you’ve found it and destroyed it, time to spawn your own FB again.

And, of course, there’s the fact that your vehicle can be killed by any unit, not just sappers.

Or maybe you’re talking about stepping-stone FB advancement, you drive an FB 2.5km from town and deploy it. Then you despawn and respawn it, and drive another 2.5km away from town. All the same problems apply.

And whatever version you take, you introduce some seriously terrible issues of your own. Static FBs have a 2km distance to engagement limit, which doesn’t take too long to travel. When you take them away, now you have the full distance between towns to re-engage. You have a great attack going, the FB goes down. Now you have a 45 minute wait before that fight can pick up again. That’ll be fun, right?

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: