Why redo capture in 1.31?

Several people have asked me why we chose to replace the capture system in 1.31: in an already overdue major release, it seems like we could have spent our time on better things.

The real driver behind replacing the Battleground Europe capture system, without going straight over to an area-capture system, came out of something far more important: changes to the client engine for performance, stability and improving graphics capabilities (which enables more eye candy but was done for performance reasons; with today’s graphics cards, eyecandy features tend to be done on the card, so making use of them helps improve performance).

Jaeger made some radical changes to our terrain engine, which required a large artwork overhaul to comply with. It also presented us with one critical dilemma.

The previous terrain system used marker objects that the player had to come into contact with to initiate capture. These are sometimes referred to as “happy monkey heads”. In pre-alpha the original artwork for them was exactly that :) They later became a table with a radio on it, and finally in 1.30 they became crates.

Here’s the scary thing. They are all manually placed. So for every capture building, there are actually two manual objects: the enclosing building and the table. Ick!

The terrain changes would have required us to manually revisit every single capture table! That’s over 5,000 individual objects. That would be nearly 25 weeks of man work …

Fortunately, the way that a table becomes a capture object turned out to be transferable: they could fairly easily transfer it from the table object to the horizontal surfaces of capture buildings.

Ramp, who was leading the client part of this work, came and discussed this change with me. We looked through the code and estimated the work involved in supporting this change in the host code.

Overhauling the capture code to support this change mean’t a lot of work since it mean’t actively modifying the parts of the strat system I had left in-tact.

However: as we looked, we also saw that this presented an opportunity to discard all of the old code sitting under my layers of new code. It came down to a matter of risk.

In the old code, there are multiple-tiers of data to be massaged and manipulated. The capture object – the table – has to have it’s visual state tied to strat data. When a facility is not capturable, the table is hidden; when the facility is on a timer to becoming capturable, the table is visible with no radio, and finally when the facility is capturable, table and radio appear.

In turn, this adds lots of exception cases to everything that massages object states – which are usually related to damage and destruction.

Also – the previous model applied the capture system on a per-building level. That means that every capture-condition clause was applied to ~53,000 entities rather than 5,000…

I realized an opportunity: we could wholly separate the underlying state system (strat) and the rules. This would make the code much, much simpler, far more readable (maintainable) and expose us to far less risk (the more exceptions “if”s and “else”s in your code, the more complex any testing has to be).

  1. Move it to per-facility, reducing the overhead and complexity by a factor of 11.
  2. Given the capture-state it’s own discrete encapsulation (class), which replicated the upper-levels of the old model for easy migration.
  3. Remove the old client-fired capture events in favor of purely host tracking.
  4. Replace the client-fired messaging/network overheads with a simpler, clean interface to our Lua engine so that the rules can be abstracted in Lua.
  5. Create a Lua environment for translating events into capture state changes.

This gives us an awful lot of future proofing. The current “capture system” – by which I mean the C/C++ code – has no idea how stuff gets captured, it just knows what to do when it does get captured :)

All of the rules are implemented in Lua. We sacrifice a little runtime performance for a lot of ease of expression.

It also ensures that the two are implemented discretely. That means the C++ code is no-longer littered with special cases for handling capture, and the capture code is no-longer littered with clauses to ensure we aren’t accidentally looking at objects that we shouldn’t be (I mean, special cases; obviously both systems still have fundamental validation ;-P)

All of which was far easier to get done than it would have been to migrate the old code base to the new system. It would have taken a long time to rewire the old system without tripping mines embedded in special cases where some hard-coded value had special significance to some other system.

So why didn’t we go the whole hog and implement area capture or some other fancier system?

Well, again, see the original reason for doing this work. We got done what needed to be done, and we brought the capture system light years ahead of where it used to be. We also turned it around from a system that was a million years from being area-capture ready to an underlying infrastructure that can support area capture without having to know about it, and a rule system that can implement area capture without needing additional server infrastructure to support it.

We also were able to migrate the capture system from a layer wedged brutally into various other layers, to a discrete system that is well integrated with the client etc, that I think will be alot easier for new players to understand. (I suspect it will confuse established players for a while).


Nice post !

Always interesting to hear you discuss the system on the code / design level.

Good stuff.

Thanks for sharing that Oli.

A question for my own curiosity; would this new system make it easier, harder or about the same to make any other terrain object than a capture building a capture point?

I’m specifically thinking of bridges; the bridge itself plus the “embedded ramps” on each side. Historically bridge battles were incredibly important and vicious; if they could somehow be capture-able and part of the supply network… ka-wow.

I don’t know that it really does anything for bridges; a fraction easier, I guess, since we’d just need one artist to visit each bridge model and mark the up. But the real issue is that bridges aren’t part of the supply system. They’re supposed to be, but the subsystem all of that depends upon was never properly made functional and, at some point in the very distant past (like – 2001) quietly removed.

They’d wind up needing to be visited manually, since there are odd cases like Antwerp/Lux where there are multiple bridges /inside/ a city.

And we don’t have an option to modify the terrain editor without completely rewriting it =(

Very Informative! Thanks for the post.

Lovely. Now I understand why what was done was done. And the fact that “an underlying infrastructure that can support area capture” is now it place is, hopefully, a good thing.

But it does beg the question: Just what the hell is ‘Area Capture’ anyway? I see ‘Area Capture’ being bandied about like some mystical bit of sorcery to placate the masses. I’ve seen people (myself included) discussing ‘Area Capture’ on the forums, trying to define it. But nothing has ever really been said about what ‘Area Capture is going to be. Far as I can tell ‘Area Capture’ is just two words that hint at something, but, behind the smoke and mirrors there doesn’t appear to be anything there.

Area capture is the opposite of table humping. There’s no more definition than that from us because we haven’t sat down and decided what kind of area capture we want to implement in BE, and one of those reasons was the daunting amount of work there seemed to be in converting our servers over to it.

Your implication that we use “area capture” as some kind of nefarious key-jangle for the kiddies is somewhat off, though. It’s simply not on the table yet, as far as we’re concerned. And most of the time I’ve seen folks like Gophur or Motor mention area capture it comes prefixed with those words “some kind of”.

“Area Capture” is an abstract label just like “PvP”. I’ve seen some folks say that our new capture system is “a kind of area capture”, because you can be anywhere in the building. But really you’re still capturing a point on the map, and your location is still limited to within a few feet of a single point.

What we have now, and still in 1.31, is “point capture”, which has very little reflection on the battle raging around that point (c.f. when there was no capture timer and if one guy could make it into a cap building, poof it changed hands).

My only reference point is SWG but I used to like their equivalent capture mechanic – to blow an enemy military installation, you had to have a team of 5 individuals, each with seperate skills. So you needed the equivalent of a locksmith to pick the doors, an engineer set the fuses, a demolitions guy to set the charges etc, a Leader to press the plunger etc

Could this kind of team approach work within wwiiol? To capture an enemy bunker you need 5 guys, with 5 tasks to be undertaken within a time window or layout boundary meaning you needed the 5 to do the job and the base couldnt be solo’d?

That kind of approach indirectly encourages area (or more like ‘point’) control, as your team of 5 is unable to defend itself while the capture mini-game is underway.

I think we all can agree that a more ‘Team’ orientated approach to Capture in WWIIOL would be a good thing. Unfortunately, Silky, I don’t think the way SWG did things would be the best way to go about it. The problem is that the SWG system suffers from the same pitfalls the present system does because essentially, what SWG did is what is being done right now in WWIIOL. The only ‘difference’ is rather then just one (pre-1.31) or one or more (1.31+) Players directly interacting with a single capture Object in order to trigger the capture timer, the SWG system requires multiple Players directly interact with multiple capture Objects to accomplish the same task. While such an approach would require some teamwork, the focus is still on Player interaction with inanimate Objects rather then on Player interacting with other Players.

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:

WordPress.com Logo

You are commenting using your WordPress.com 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=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: