Rethinking the Build Mechanic - Engineer Swarms

The only argument I can see against having the factory build upgrades is that it really changes how the player would have to use the factory, in that it doesn't just build 'units' anymore. Then you have to make choices like, do I get the scout, the light assault tank, the engineer, or do I spend time upgrading?

If you kept it to 'engineers can slot into a factory' you remove that last question - you don't have to decide between an engineer and an upgrade until the specific time you need it. You would also have the ability to build 'upgrades' (engineers) in another factory to upgrade. This would keep the gameplay very close to what it is now, except it would make your base much cleaner. Personally I prefer a 'permanent' upgrade solution, just because it's a cool decision to have to make - build structures? Make factory faster? Lost all my engineers so I need to dismantle this factory to get the engineers back?

There are the additional balance concerns which affect the issue; how does the game scale over time, what effect does a large swarm of engineers have on the gameplay, do we want to limit the amount of assisting, etc, but I think most of those questions would have to be answered when Uber puts out some more details on what they want to do.

What about the additional complexity of having the same factories with differing amounts of build power? Would you have to mouse over or select the factory to check how fast it is actually building? This is a major problem with upgrades on an individual unit basis, especially when there is no visual indicator of which upgrades are applied to which unit.

A factory, or any structure or unit for that matter, should always function the same, determined by its type. A player should see the unit, and immediately know everything about the unit (assuming adequate player knowledge of the game's parameters). They should not have to click on it to check what upgrades it has.

Honestly i think upgrades for each tier of engineer should determine build speed with only one engineer per building.


Say fifteen upgrades for each tier of engineer, each one increasing build time by one then two then three so on seconds. Eventually each tier with fifteen upgrades could have 109 seconds taken off build time.

Indeed, which is why I like the slots idea - you get a visual representation, remove the clutter, and make it clear which factory is 'faster'. If you have a row of 5 factories being assisted by engineers, you have exactly the same issue - which one is fastest? How many of those engineers in that cluster are actually assigned to this factory? Are there engineers in the mix that are actually idle?

It would also prevent the 'oops I just selected all my engineers and gave them a move order' that I'm quite sure we've all done at least once

It seems you want to change this just because it looks messy. The system works well. Late game when you have swarms of engineers you need to be able to switch build power rapidly so you can respond to threats as you see them. This idea has more implications than just cleaning up units from around factories, or making it "easier" to run an economy.

Of course it has more implications. My point is that E-swarm works, but only up to a point. Like so many other features of Supcom that work up to a point, it's the large scale that breaks the system.

A swarm of engineers has the following issues:
- Player no longer has an accurate estimate of the time required to build a project
- Factory resource usage is not reflected in the UI (each engineer has an individual usage)
- Player has a hard time finding the 2 engineers in a swarm of 30 that are not doing anything
- Player can inadvertently move the engineers
- In order to 'manage' the production, the player must target multiple engineer units rather than a single factory
- Many units clustered around a factory cause pathfinding issues
- Player has no feedback on how efficient his engineers actually are (are they spending all their time just opening & closing their nanolathes?
- Base clutter means that after an attack the player has no way of telling how much his production has been affected apart from 'all gone' or 'some dead'.
- Base clutter makes it harder to identify & select combat units near the factory


Please explain how these things 'work well'.


Requiring a swarm of engineers to switch projects rapidly is a different topic, probably more suited for the '100 engineers' thread.

no way, Im tired of engineer swarms!, there must be a limit per factory

What do you mean project? A unit? I thought you were complaining earlier about instabuilds late game. Doesn't that imply a very short time?

This I agree, should be solved. Not hard for the mouse over to reflect total buildpower instead of just the factory though is it.

Again I agree, However I'd like to see a button to find idle engineers, rather than changing the whole way they work.

Players can also pay for their mistake. Get better at the game. I have no problem with this minor punishment for a mistake.

Drag, select.

This is more of a problem with A* pathfinding.

Yes they do, just look at them, their animations reflect their state.

What about the wreckage, or just judging how many engineers are on the job still.

drag select again, it wont select engineers if there are combat units in the selection area.

I see very little difference between these two threads.

I have to agree with zordon here. Also the TA Demo Recorder added selecting idle engineers with a hot key, so this should not be a hard feature to add.

In this case, yes, a unit. The player has one indicator on the time required to build a unit - the factory interface. Decoupling the build menu from the actual production mechanic means that the player loses this information.

Actually it's harder than you might think when you add things like time to unpack nanolathe, time to bump each other around and get into position, and whether or not the engineer is actually near the factory and ready to assist, as opposed to being just assigned and half way across the map.

I'm not suggesting engineers change how they work at all, just that their relationship with factories is changed. Supcom DID have an idle engineer button - why didn't you use it?

Making the wrong strategic decision and paying for it is good gameplay. Punishing a player for clicking the wrong button is not.

Take a look at this image:

Your 'drag to select combat units' only works sometimes - if the unit happens to be leaving the factory, you end up with the combat unit, and good luck trying to get the engineers. If you drag the box incorrectly, you end up with engineers.

Stopping to zoom in and study unit animations to determine their efficiency is frankly ridiculous. And it's common enough for wreckage to be reclaimed and engineers to move around - it's a lot easier to keep track of 'is this factory dead' than 'is this one sub component of this factory dead'.

What if the engineers all lined up in neat rows to assist?

Sure. Like, if they had slots to fill in the factory you mean?

I don't like the slots idea, I don't want the engineers to be protected from attack, and I want it to be easy for an enemy to notice where an opponents buildpower is focused when they scout.

Slots and vulnerability needn't be mutually exclusive.

Neutrino said he wanted the engine to support units riding other units in one of the naval transport related threads.

So you could extend that concept to engineers sitting on specific, and perhaps a limited amount of, locations on a factory to assist.

Like say the factory has a carpark out front?

Sure, not quite as eloquent a description as I was hoping for, but essentially that.

This idea, while not terribly helpful to the engineer swarm issue, does remove the need for separate 'advanced' factories for high tech units. Why are some units advanced? SupCom had it right by making advanced units simply bigger, but then messed it up by making the factories the same size (which was understandable as they wanted them to be upgradable, and upgrades wouldn't work if the buildings changed size). There is one Generic Factory Block, which you build in grids, and a factory can build any unit large enough to fit inside it. Say units are built on grid intersections, so a 2x2 grid can build a single T1 unit in the middle, while a 3x3 grid can make a T2 unit using the four intersections it contains, or four T1 units at once (and a T2 factory costs 2.25 times as much as a T1 one), although there's no hard division between these 'tech levels'. Due to the need for completed units to drive off the factory floor, different shaped factories are optimal for different construction jobs. T1 spam is optimised by a 2xN line, or a 3xN line with tanks leaving from both sides, for example.

This also has the possibility for units which aren't square. Maybe there's no such thing as an air factory, but all air units are rectangles, so an 'air factory' is actually just a rectangular factory that, due to its rectanglularity, is best at making planes.

Jurgen, that's a pretty cool idea.

There are several issues with this - one, you don't want to be playing tetris to figure out what you can build, two, determining a factory's build menu should be instantly obvious, not a factor of how you built it, and three, higher tech units are not (and should not be) uniformly larger than their lower tech counterparts.

Cool idea, but you'd rapidly identify all the 'ideal' shapes, in which case, why not make those ideal shapes into regular factories anyways.

I've thought of this "modular approach" for a long time and I still find it most elegant.

The idea of a factory as a huge building which produces one unit at a time is totally obsolete if you have an army of mobile engis who can do the same but cheaper. You might as well leave factories out in that case.

The whole purpose of factories is that they are in fact bigger and specialized, so they should instead have more energy and large, efficient machinery at their disposal than little toy robots with tiny zappers.

When you think of a factory as a set of construction lines or modules, you can imagine an early game factory of only 2 modules, or a late game factory of 50 connected modules, each constructing their own product simultaneously. This also makes it easy to view the total expenses of your factory and manage the whole instead of just each production module (which were in former games plain factories).

Maybe bombing a large factory can disable certain modules which which then start flashing emergency lights while auto-repairing f.e. while the others continue.

That's more what a factory looks like in a massive war. Not a big cookie jar with one construction pad...

"B-B-But i want a beehive of 100 engi's hovering around my factory"

If your 100 engi's don't have to bother about units, they can do something useful instead, like building structures and repairing units. It's plain clutter and totally unreasonable. Also, there's no reason to make above-mentioned modules cost as much or produce as slow compared to engis as factories did in previous games.