The Challenges of Automated Building Construction

I would love to see the genre nail this feature

A few weeks back I was reading this PC Gamer preview of Stormgate’s pre-alpha build. I was intrigued to learn that Frost Giant is experimenting with automated building construction:

I've got "quick macros" that are displayed on the UI—so I never forget—that bring up all the construction and recruitment menus. So I hit Q to bring up my construction list, then S to select a supply-generating building, which I then plonk down.

So I can get on with more important business, I don't need to command workers to construct this building. That's automated. One of the workers mining resources stops what they're doing, saunters over to the blueprint and gets to work.

I’m excited about this. There’s a lot of RTS players that primarily use mouse controls, leveraging the keyboard only in a limited way.* (Many RTS tutorials - including StarCraft II and Age 4 - reinforce this by showcasing few keyboard controls). I think automated building construction - and the broader universal macro mechanics feature set, which decouples macromanagement from worker and building selection - would be a meaningful quality of life improvement for these folks. And the potential to expand this audience is exciting because it enables RTS to scale to more and more casual players.

But I also temper this excitement with caution. Universal macro mechanics are a non-trivial feature to implement. I think the edge cases are challenging and can create situations where a smart feature working non-optimally feels less convenient than a dumb feature working the way you’d expect. And I think when this happens, a quality of life feature can become more annoying than helpful.

One way this manifests is when players need to mix paradigms - someone who relies on automated construction needing to manually micro workers in certain situations. I think it’s jarring to switch back and forth between ways of doing things; it adds cognitive load and, honestly, it’s just tedious. I mentioned the same way back when I reviewed Axiom, which also attempted to implement automated construction, but mostly botched it for this reason.

Today I’ll talk through a few of the challenges I see and different ways I think developers can approach them.

(Disclaimer: I am a participant in the Stormgate Pre-Alpha later this year. This article is general to RTS and is not based on that experience. My thoughts on Stormgate’s gameplay reveal can be found here.)

Line of Sight

I think the first thing worth thinking about is whether the player needs line of sight to queue construction. Grey Goo imposes this requirement, which makes its automated construction implementation quite painful (notably, it doesn’t leverage workers at all, simply constructing stuff out of thin air). Requiring line of sight to place a building nullifies the convenience of not needing to micro an individual worker, because you still need to task someone to saunter over before you can start building.

There’s trade-offs with everything, but I think in this case we can just assume line of sight is not a constraint when placing blueprints.

Worker Selection

The next challenge is worker selection. Tim Campbell actually commented on this one:

"We have a lot of factors which go into determining which worker to pull," says Campbell, "depending on whether they're on kind of an auto repetitive order, whether you've told them to do something specific, how far away they are, yada yada, and this allows you to not have to hunt and find the person and then go into some some subfolder—you can just drop a building down."

I think it can be tricky to be smart here. For example, let’s say I leave a worker near a building to help repair during future attacks. I don’t want that worker to be re-tasked - but from the perspective of the engine, they’re idle and available. How does the game know not to select this worker when I queue up a nearby bunker?

This is a situation that comes up repeatedly in the StarCraft II campaigns (e.g. Zero Hour, The Dig) and in co-op (any of the siege missions). The challenge is that different players will have different priorities and intentions; worse, the same player might want different things at different times. It’s hard for the game to do the right thing because it can’t read my mind; the best it can do is take its best guess and leave it to me to re-shuffle things if I’m not happy with the result.

This is the mixing of paradigms I referred to earlier, and I think it can be frustrating for people to deal with. I think it comes down to expectations - if the game is telling you that it’s smart, but it sometimes acts in a way that’s dumb, it’s going to annoy you more than if the game never made that claim in the first place. And even if it works well most of the time, people - particularly the target audience of this feature - will remember the times that it doesn’t. (The number of emails I’ve gotten over the years about StarCraft II’s pathing…)

I think a simple fix would be to avoid re-tasking workers on patrol - this avoids the complexity of adding a new state or toggle. But, it’s a little unfriendly to new players. It’s not immediately obvious how patrol, auto-repair, and worker selection for building construction interact. And for more advanced players, there are cases where you typically don’t patrol, and workers are intentionally issued commands one at a time while idling in between to avoid dead money, like walling off an expansion with supply depots.

You could perhaps directly formalize this and solve a couple complexities by adding a “do not re-task me” option on workers. But I’m not sure how great a solution this is - it adds a different kind of complexity in the form of fiddling with a new toggle, and it still forces players to mix paradigms.

A similar issue comes up when building multiple structures. When a player queues up a bunch of buildings, how does the game know the intended number of workers to assign to the task? It can’t, so it’ll take its best guess. This is notably a problem in campaign missions like All In, where the player finds themselves constructing lots of structures at once with a handful of workers. I can also imagine some weird edge cases where you queue up a bunch of far-away defensive structures, say, in Void Launch, and later discover your entire economy just walked halfway across the map.

And this is only half of the equation; you run into a new set of problems when deciding what to do when a building is finished. Returning workers to whatever they were doing previously assumes intentionality; but maybe I didn’t intend for my workers to be idle. Or maybe I did, like with dedicated depot builders or proxied builders. The game doesn’t know, and its best guess might end up shifting things around in a way I don’t want.

Then there’s the fact that the game state has actually changed since construction started - if I pulled a worker off my main to build something, then saturated my main during construction, should the building worker go back to the main and oversaturate it? Or should the game be smart enough to retask them to a separate base? If re-tasking is the approach: how does the game know that a base is taken? Should it interpret a half-built base as being eligible for re-tasking, or only a fully-built base?

I think you could come up with some reasonable policies to handle these edge cases, but it’s a similar issue as initial worker selection: the game can’t read the player’s mind, and its best guess isn’t always going to be correct. When it gets things wrong, it has the potential to create more inconvenience than if it had simply done nothing.

Handling Interruptions

I think one really tricky case is how to handle workers that get interrupted trying to build something.

Let’s say I queue up a bunker. A worker dutifully heads off to build it, but gets killed. How should the game handle this?

One option would be to automatically re-task another worker. But this has its own trade-offs: for example, if you queue a building in a danger zone, you might inadvertently kill off your whole economy as the game blindly sends worker after worker to their demise.

Another option would be to do nothing - if the original worker gets killed or interrupted, the player is responsible for tasking a new worker. Or, maybe the blueprint gets canceled. But this creates a frustrating uncertainty. I think many people won’t be happy that they can’t rely on automated building construction to do what it’s supposed to do - not only is it a smart system acting kind of dumb, but it’s doing it silently. You look over at the building you thought was supposed to be built, see it not built, and think, what the heck?

I see this as part of a broader problem that I’ll label “game state confusion” (there’s probably a better word out there). I think with RTS in particular, since things are happening in real time, players can lose track of the game state, leaving them confused and disoriented. Army management is a good example - over time you can end up with units all over the place, and it’s hard to remember where everything is. Accessibility mechanics like select-all army can act as escape hatches in this situation, allowing players to defragment the game state and get back into the driver’s seat.

Automation mechanics sometimes have the potential to do the opposite - introduce new confusion because the automation isn’t working the way the player expects. I think this introduces a higher bar for implementation, and it also suggests the need for new forms of escape hatches to make sure players feel like they’re in control.

One interesting escape hatch here would be an “idle building” function, similar to the “idle worker” button. Here you can notify the player when something isn’t getting built, and help them to act accordingly. Notably, you could offer an option on un-built buildings to automatically restart construction; you could even have a button to restart construction on all unbuilt buildings to smooth this out even further.

Where this becomes more interesting is competitive play. It’s actually quite challenging to get everything up and running again after an opponent’s attack. As a Terran player, I can’t tell you how many 1v1s I’ve lost where I thought I had a building, but it turns out the relevant worker was killed and the structure is only half-complete. The option to re-queue workers automatically after every attack would meaningfully lower the skill ceiling, which may not be a game’s intended design.

I’m also mindful of cases where queuing a worker to do something is especially high effort, like when you need to bring a new worker across the map during a proxy, or when you’re taking a far away base in the middle of a hectic end game. If this were all streamlined by automated worker assignment, it would also meaningfully lower the skill ceiling, and perhaps not in a good way - I think it’s great that games like StarCraft II or Age of Empires II reward players for prioritizing high-quality macro in the late game by asking them to devote non-trivial attention to it. And I would actually say that the need to look back and forth between your base and your proxy is itself a form of natural defender’s advantage - because the defender only needs to look in one place - that is especially beneficial at lower levels.

One way to solve this would be to simply not offer automation - or offer a more limited version of it - in competitive play. I think that’s actually a good solution, and raises up the assumption that StarCraft II made that the casual and competitive rule sets shouldn’t differ too much. I actually don’t fully agree with that approach, and I think other RTS games should be intentional in setting their own philosophy in this regard.

But if the developers were to keep this feature in ranked play, there may need to be some countervailing mechanic that kept the skill ceiling high. It’s a tricky problem because worker interruption during construction has the potential to be a race-specific issue. For example, in StarCraft II, it only impacts Terran - for Zerg and Protoss, once a building is started, it can only be interrupted by destroying it. If only one race benefited from a UI quality of life feature, that might make the game harder to balance and could even feel unfair to the other races.

The Philosophy

Implementation nuts and bolts aside, I feel it’s worth thinking about the philosophy of this feature, too. I don’t think this train of thought should put the breaks on anything, but I think it’s worth some reflection, even if no action gets taken: why do we need automated building construction in the first place?

After all, many games that involve building structures, from Civilization to Cities Skylines to Tropico to They Are Billions to Factorio, simply auto-magically build stuff when you put down the blueprint. The player doesn’t need to think about workers at all. Why not just do it this way?

I think there are at least two good answers to this question. One is that taking workers out of the equation is incompatible with competitive gameplay, and perhaps the developers don’t want to fork the basic user interface functionality between casual and competitive. OK, fair enough.

I think there’s a more interesting answer, though. The reviewer said it himself - selecting workers is “the more tactile way of doing things”. Tactile. I think that’s important. One of the nice things about playing real-time strategy games is the in-the-moment feeling of directly managing units and structures: selecting a worker, selecting a building, and constructing it somewhere. I would say that the most uniquely “RTS-y” aspect of this interaction is not that it occurs in real-time but that it requires the player to select a worker to begin with; it requires the player to be there, in the action, while other games keep the player at a distance. And being there is a quintessential part of the RTS experience.

And so I think the challenge with a feature like automated building construction is that it somewhat detracts from the core real-time strategy experience. I get how that sounds dramatic - oh no, you’re no longer manually constructing buildings, the game is unplayable - but I genuinely think that a lot of the joy of playing real-time strategy games comes from executing on the moment-to-moment mechanics. And I wonder if enabling this frictionless experience may actually encourage players to play a game in a way that’s less enjoyable for them, even if the players don’t consciously realize it.

There’s a balance here - the moment-to-moment feel of moving units around is a key part of the experience, too, but that doesn’t mean most people want Stalkers to path like they’re Dragoons. The question for me when games pursue features like this is how they plan to pull people into the experience, if the more classic mechanics are streamlined into a universal command bar. For people like me, it’s probably irrelevant - we’ll just keep using the classic control scheme. But for the type of person that prefers the more detached approach, what will the moment-to-moment gameplay feel like? How will it be paced? Will it feel jarring when the player needs to take command and micro stuff manually?

And I think that leads to the more fundamental question: who is automated building construction for? I imagine many folks will handwave away the edge cases raised in this piece and say, well, that’s not a big deal. And that’s true. But tasking workers to construct buildings is also not a big deal. For the audience of people that think it is a big deal, will this mechanic actually satisfy them? Or will the holes and edge cases frustrate them even more?

That’s why I think this is a challenging feature - not only is its implementation full of dragons, but it needs to satisfy people that are hard to please, without annoying any of the existing constituencies. Anytime a developer adds some smarts to a game, they’re gambling that the additional complexity will work well enough that it won’t frustrate players more than the previous dumb simplicity. And one of the things that I learned from Axiom is that this is an easy thing to get wrong. It’s high-risk, high-reward.

The opportunity is nonetheless there, and it’s a significant one. I hope developers can start capitalizing on it - and maybe resolve some of the philosophical quandaries, too.

Until next time,
brownbear

If you’d like, you can follow me on Twitter and Facebook and check out my YouTube and Twitch channels.

* I’ve had a few interesting offline conversations with folks who interpret this partly as a miss on the part of real-time strategy keyboard controls overall. I’ll write more on this soon!