A 'Nod' to the Construction Yard

You can read this at its original location at https://waywardstrategy.com/2020/07/01/an-ode-to-the-construction-yard/ 

Writing about conventions specific to a particular strategy game franchise sometimes fills me with a little bit of dread. Longtime fans of the particular franchise of my focus possibly or probably have a fine degree of specialized knowledge about it that I might lack, and the topic is unlikely to interest the broader population of strategy game fans or gamers who don't share a major interest in the specific mechanics of whatever game or franchise I'm concerned with at the time.

And regardless, that's not going to stop me. At the very least, I am happy to learn from players and designers who know more than I do, and at the very least I enjoy getting people talking about RTS design.

In this case, I've been playing and watching more than my fair share (what my wife might call an 'unhealthy amount' whatever that's supposed to mean) of Command and Conquer games. There's the remaster, of course, which has actually captivated me in a way that I confess I wasn't expecting of a 25 year old game. But also I've made my way back to Command and Conquer 3 and Red Alert 3 (only skirmish at this point: I'm nowhere near skilled enough to engage with those games' current competitive communities) and it's made me fall in love with the franchise all over again.

The Command and Conquer is built around a number of systems that I absolutely love, from its resource harvesting system to how it handles base building. And it's that I want to talk about right now: base building. In particular, the Construction Yard/MCV.

The Humble ConYard

It's quite common in RTS games to have a generic worker unit responsible for gathering resources and producing structures. Age of Empires games do this, as of course to Blizzard games and even Command and Conquer: Generals. Total Annihilation style games utilize 'engineer' units that are specialized builders, et cetera. You get it. The vast preponderance of RTS games use builder units anyway.

But not, of course, Command and Conquer style games. They are relatively rare in the genre in that they have a structure that produces other structures.

Let's get this out of the way up front: in terms of a visual metaphor for construction and production, a building that can magically construct another building at long range is... a little strange, a little ridiculous. But in all honesty, a guy in a robot suit building a giant vehicle factory all by himself is a similarly unrealistic truncation of how buildings are constructed in reality. So, I'll call that a wash.

SCVs aren't substantially more 'realistic' than ConYards, in my humble opinion. Not that 'realism' tends to be a good indication of quality in RTS by itself anyway. We'll get to the mechanics in a bit.

I'm not going to go too much further down that particular rabbit hole though. Suffice to say, the method by which structures are produced in what I call, loosely, the "Command & Conquer model" differs from worker-based construction seen in a variety of other gameplay systems, like the ones mentioned above.

What's more interesting to me personally is all of the various implications that come from such a system.

We're going to look at a number of those implications in depth, including: how the ConYard production model changes how players are able to harass each others' economy, how the ConYard impacts economic and tech tree progression, what 'build radius' means for RTS games, and how base expansion works in Command and Conquer games thanks to the (mostly) single point of failure that is the ConYard.

Single Threading

C&C games restrict you, at least in the beginning, to building one structure at a time. Is that a bad thing?

RTS games demand a lot of their player: you're constantly producing new units and structures and trying to get information on what your opponent is up to, trying to expand and ensure the safety of your infrastructure, et cetera, et cetera, until the game is over.

Additionally, the beginning of a match in any game tends to be kind of fraught with tough decisions that are made even tougher by the fact that whatever you choose to do might not adequately prepare you for, or otherwise appropriately address, whatever it is that your opponent is up to.

Command and Conquer games have an interesting take on this. First off, they provide the player with a lot of resources right out of the gate, something again that a lot of strategy games don't do (for various reasons). Another thing they do is to restrict the player to building one structure at a time.

And that's a bad thing? Right?

Many players might think so, and it definitely is a trade-off. Most RTS allow the player to build as many structures at once as they have the money to support. It's not uncommon in StarCraft or Age of Empires, for example, to have 3 or more buildings in production at any one time, and obviously this is the case in Total Annihilation or Supreme Commander as well.

Command and Conquer though tends to favor a somewhat smaller number of structures, for one thing. Comparing C&C games to something like StarCraft: players, even in the newer games, seldom have more than 1 or 2 production structures at a time and no more than a handful of refineries. Compare this to the dozen or so Barracks a Terran players needs in StarCraft 2 by the end game, to say nothing of all of the Supply Depots or Pylons you're going to be building.

But with ConYards in Command and Conquer games, you don't have to worry about being supply blocked or having a 9th production structure (this might be less true for Tiberian Sun or Red Alert 2). The nature of that single thread design is that each structure is a major building block of your strategy. It provides a remarkable amount of choice and clarity that might be lacking from a game with a lot more production going on. Deciding when to put out your first Refinery versus your first Barracks is a significant decision.

This also allows for any building kill to be effective harass: with a limited opportunity to rebuild lost structures, a single Power Plant that needs to be re-made is a major impact to a player's strategy. Or a single Refinery, or any other single structure for that matter.

In a game of the scale of Supreme Commander, a small army being lost, or a single firebase consisting of a series of defensive structures, isn't necessarily enough to put you on the back foot. But because of the economy scaling in Command and Conquer, things are very different. Add to this how quickly some buildings can die or change hands (being captured by an Engineer, for instance) and, on either side of the equation, you have a lot of room to punish your opponent or to make a comeback.

Again, that's a bit of a trade-off. Single-threading can lead to situations that force a player to pump out structures as fast as possible or fall behind: a couple of seconds gap between one building being finished and another one starting up can put one player behind in ways that can leave them vulnerable to being attacked or falling behind economically or militarily. This is something that can happen in a game with more stuff to build but with the C&C model there's a lot less room to mess up which means each mistake or delay is felt more keenly.

For this reason, newer Command and Conquer games have opened up the 'single threading' restriction: adding a unique build queue for each production structure (you still almost never need more than 1 or 2, of each, but it can help and does allow for a wide variety of strategies based on mass production), unique build queues for each ConYard, and in C&C3 and Red Alert 3, cranes which have their own limited build queue. But, unlike in most other RTS, whether or not the player wants or needs the extra production potential is a strategic choice and not mandated by mechanics.

Additionally, and importantly, moving defensive structures into a separate build queue from other structures allows players to react defensively while still focusing on their economy.

The ability to have defensive options in their own build queue does offset the downside of single threading I mention above (regarding falling behind) by allowing players to protect themselves from early game harassment with the tactical deployment of a turret or wall, which creates a harassment system that I feel is both more obvious and has more counter-play since it doesn't rely on vulnerable workers to move to and place the reactive defensive options.

To summarize this section before moving on:

Build Radius

Some RTS restrict where you can place structures. The Zerg in StarCraft 2, for instance, can only build on Creep (with the exception of the Hatchery and their Extractor structures of course). And of course, if you know anything about Command and Conquer, you know about build radius.

It changes function based on which title you're playing, but basically you're restricted to build structures in a certain proximity either to the ConYard itself or to other structures. The newer generation of C&C titles: Red Alert 3 and Command and Conquer 3 in particular, have specific units which can deploy to produce their own build radius, as a way to expand to another area of the map.

As I said above, this is kind of a tradeoff from how some other other RTS handle base design. Proxies aren't really possible in Command and Conquer games the way they're thought of in other RTS, and hiding tech is difficult too.

This also makes 'expanding' to a new area of the map non-trivial, requiring the player to produce an expensive build-radius producing unit, or to physically move their MCV somewhere else and slow down their tech progression, since they can't build anything while the MCV is moving and re-deploying (this is mostly true in Red Alert 3 and Command and Conquer 3).

In older C&C games, players often 'chain' their structures across the map to move build radius toward new resource patches, sometimes selling off unneeded buildings after they've got their Refinery into optimal harvesting positions in order to recoup resources and limit the vulnerable surface area of their base.

To me, though, this is an endlessly interesting series of tradeoffs and decisions. And, to boot, it's a lot easier to understand the implications of packing up your production potential and walking it across the map than it is to allocate some percentage of your early income to a different worker ratio or to produce a new town center or command center instead of a some more barracks. It's a clear and dramatic decision to pack up your building into a unit, pausing all of your production potential, and move it across the map somewhere else.

I have come to really love the dynamic of players moving their MCV around the map, particularly in Red Alert 3 and Command and Conquer 3, in order to support their strategy. It's one of the easiest ways to acquire new resources, expand production to a new area, and there's even a precedent in Red Alert 3 for using the MCV offensively since it can crush smaller vehicles.

I want to keep going on about how much I love the ability to move an MCV around the map, with all its attendant complications and limitations and tactical and strategic uses, but I find it difficult. It's really easier to see and do than it is to describe in an effective way.

I love systems that provide both clarity and depth, and the MCV is one of my favorites (especially as in the later Command and Conquer titles).

Single point of failure?

Hands down, the most fascinating part of the design of Command and Conquer games is how players are able to continue to compete, and even to succeed, with almost nothing. C&C Remastered games often come down to one player selling off almost all of their structures in an attempt to kill or capture the enemy base. I've seen Tiberium Wars matches won by a single ranked-up air unit. Routinely, players compete and win after their ConYard is killed off.

Partially, this is due to the limited number of structures required in order to play. A single vehicle factory, a couple of functional Harvesters and Refineries, you might have a chance. This is, of course, not guaranteed, and is not totally dependent on the design of the MCV or Construction Yard. A lot of it has to do with how the economy scales in C&C games.

Worker-Based Construction

In games with worker-based construction, killing a player's workers is one of the baseline considerations. Killing and protecting workers is a huge part of the game, and is a granular one. Meaning, the player will typically have a large number of workers proportional to the number of their total assets, so the loss of each worker is relatively minor.

The trouble with this, in my mind, is due to 2 main factors. First, when a player loses a worker, they seldom lose only one at a time. This has a cascading impact on player economy because the workers themselves require resources to purchase, which delays economic growth due to the lost workers and also puts an additional economic burden on the player due to the cost of the new workers. Secondly, the replacement of these workers takes time, which further hampers the player's ability to catch up to their opponent.

In this way, what seems to be a granular and binary way to gain a slight advantage has a tendency to snowball into a larger problem. With Command and Conquer's approach, losing a power plant or production structure is a single choice from being in a competitive place again.

Also, with the ability to sell off assets, the player can refine their strategy by getting rid of other buildings (or units in some cases) in order to shore up their economy.

Conclusion

Thanks for coming on this ride with me. I know every RTS system has a lot of tradeoffs, and that there's a lot more that could be said about the MCV and Construction Yard. I hope this little look into my favorite bits of its design has been interesting. Please share your thoughts with me on the topic of C&C, worker-based RTS design, or any other strategy game topic that comes to mind when reading.

You can read this at its original location at https://waywardstrategy.com/2020/07/01/an-ode-to-the-construction-yard/