robotarmyfactorio
robotarmyfactorio copied to clipboard
kyranf
mitigate bot swarming/steamrolling by introducing single squad remote targeting limitation
So, probably my biggest issue with Robot Army as it currently stands is the way that Squads of Terminator bots are basically unstoppable. This is two-fanged issue - 1, the Terminators themselves may be somewhat overpowered. 2, larger squad sizes are strictly better than small ones, and large squads of Terminators are truly, 110% unstoppable.
By themselves, either of these things can be solved relatively simply - Terminators could be nerfed (removing their healing factor to start with), and squad sizes could have a hard cap (or simply be non-adjustable without editing the configs).
What compounds this problem beyond those simple solutions, however, is the nature of the automatic targeting system. When a squad needs a new target, the nearest enemy is located and targeted. Because often the nearest enemy is nearest because it is also nearest to a player outpost/base, this means that any other squad in the vicinity will receive the same enemies as a targeting solution. Once both (or even more!) squads have arrived at that location, further targeting attempts will henceforth always result in the same solution with about 99% certainty. This "grouping" mechanism is so strong that it is very rare to see a squad that 'lives' longer than a few minutes hunting on its own - it almost always hunts in a massive blob with other squads.
Side note: Admittedly, the effectiveness of these tactics is inarguable. Massive show of force is a good military strategy. Unfortunately for the mod, it is also a hard strategy to properly balance. And gameplay that isn't well-balanced isn't fun, even if it's realistic.
So, what solutions present themselves?
One option would be to somehow limit the effectiveness of large swarms. An implementation along these lines might be to reduce bot firing range. If bots in the back of the swarm can't get into a firing position, they aren't accomplishing much. The only problem here is that this ignores the effectiveness of having a significant mass of reinforcements that can 'drop in' and begin firing as soon as a frontline soldier goes down. In fact, bots that can't fire are still quite powerful in that a swarm can maintain its effective firepower until its numbers finally drop below the threshold required to maintain a "full set" of frontline soldiers. And in fact this is exactly the behavior that is observed in the current mod when a critical mass of squads/bots is reached - the swarm travels together, not necessarily ever bringing its full firepower to bear at once, but always maintaining more than enough soldiers to put effectively a full complement of firepower downrange.
Another relatively simple option would be to put a lifespan of sorts on the bots themselves. After a certain number of shots fired (not sure if it is actually possible to count these, or if an approximation would have to be used instead), the bots would go inactive from lack of energy. This would prevent bots from being overly long-lived, and would definitely be a hard counter to overpoweredness in general. But it wouldn't actually affect the swarming behavior at all, making large swarms still the best tactical option under almost all circumstances.
The option that I'd like to explore in more depth (ha - I'm finally getting there!) would be a lore-based approach that would restrain the swarming behavior at the targeting level. It would be stated that it is not possible to remotely coordinate the behavior of squads or bots beyond certain thresholds, and therefore squads that were being assigned a target that was actively being pursued by another squad would instead do one of two things: either find another target, or remain in place, inactive, until such time as they could be assigned their own target.
Of course, it would be far more ideal to be able to find the squad another target. Unfortunately, i seem to recall looking at the options for this, and they were not particularly satisfying. We currently use a find_nearest_enemy method that has no provision for "find a different nearby enemy in a different direction".
Failing that, a 'remain in place' option might still work. The nearby squad in active combat would eventually either defeat their enemy or be defeated. In the latter case, the inactive squad would simply go engage. In the former, it is possible that the nearest enemy to the inactive squad would now be different that the nearest enemy to the active squad. This would lead to the squads at least temporarily heading their separate ways. If and when future targeting solutions would bring them back together again, one squad would remain inactive until a different option presented itself.
A partial solution to finding a different targeting solution for an inactive squad would be to do a search for a target from a point on the map a certain distance in the opposite direction of the squad it was otherwise sharing its target with. This distance could increase a couple of times in successive searches before eventually falling back to the failsafe situation of making the squad inactive.
A final enhancement to all of this would be to allow the squad sizes to be upgraded via expensive research, in order to allow players struggling with extremely powerful biters to make a tradeoff between spending resources on research vs more bots.
None of this would be intended to affect the RTS-style manual squad targeting controls, which should of course always allow the player to command squads directly however he/she pleases.
I wanted to have some form of 'ammo' to cause squads to have to return to base or otherwise 'stop the rampage' as you can see from almost the first version's config file I had an ammo count parameter. The ability to see who killed what is interesting and might be useful, basically once a squad kills x amount of enemies, it 'runs out of ammo'. Squad kill count can be the sum of individual killcounts. The kill count would have to be stored as an additional field in the squad members table. I don't know how much CPU all this would use, probably not the best idea to do it this way.
Another way would be to count how many ticks a squad's unit-group state has been in the "attacking" state (meaning active combat). When the tick-count goes over a certain amount, the squad as a whole is assumed to have expended enough ammo/energy that it's time to go to the nearest supply depot to re-arm.
Issues with all that is extra pathfinding, which we need to avoid at all costs.
And yes we use find_nearest_enemy because it's extremely fast compared to trying to manually do an area filtered search and pull out entities and units/buildings of non-player forces and finding the distances to each and selecting the target.
we could do an area-denial thing where a squad finds a target, accepts the target and we put a bounding box of maybe 100 tiles width and height around the target's location. Any further squads requesting targets must check all the global bounding boxes and ensure the coordinates of their proposed target isn't inside any of these bounding boxes. The usual re-try every x seconds and otherwise stay idle would be fine here.
I like the idea of research based squad size unlocking. Start the default squad size at 10 (remember the clockwork bots really need large groups..) and have increments of 10 with getting very expensive by the time it's up at like 70-80. I think 100+ is best avoided really.. But if you have terminators, 25-30 is more than enough, so squad size really isn't THAT restricting in the late-game, how will this help in that situation? Other than stopping a spam-fest in the early to mid-game.
Yeah, sounds like we have some similar ideas here.
I think the research could actually be per-type. Or at least per tier? (early, mid, late) Or the Terminators could just have their own research, and it could start as low as 5 per squad, and go up from there. We obviously don't want to clutter up the research tree, but having a separate research for Terminators doesn't seem unreasonable.
Squad sizes per type doesn't make sense especially if we want to encourage mixed-squads (which I do!). The next major hurdle is how to logically and within game mechanics make a droid assembler spawn a droid from any inserted droid type (make it a chest type building and simply scan the inventory?) with attached combinator that defines the squad composition, hunt radius, behaviour (guard or assault), and squad size. While doing this we can definitely add caps for squad sizes or just have a hard-cap of 20-30 for example.
GOING WAY OFF TOPIC HERE: So the user-scenario for this new system would be:
User builds new type of droid assembler building which is a simple chest entity with fancy sprite. The chest is scanned on the assembler update tick and the combinator attached with wires nearby is examined for droid ratio settings. each squad is bound permanently to this new type of spawner.
The spawner examines its current squad (if it's nearby and still waiting for new members) composition and works out which types of droids it's still allowed to spawn, and if it can it will spawn one and remove one of those from the chest inventory.
As the spawner loops through it will spawn into the nearby squad until all the ratios/compositions are full according to the combinator nearby. When all is done, it will trigger the squad AI into assault or defend mode. Assault will basically follow hybrid targeting methods, and defend will ONLY keep radius clear around the spawner, moving to engage enemy units that enter the set radius (could be fixed, or set in combinator) - but never going off into the wilderness (and regularly returning to be nearby the spawner when idle).
This is a hugely different system to what we use now, but it fixes a lot of issues and makes everything more intuitive/streamlined - and goes to the 'assembler-centric' logic concept.
Still talking about new assembler logic The squad is monitored by the assembler in the background, and when the squad falls below the default (or overriden) retreat threshold, the squad is ordered to return to the assembler and go back into "needs members" mode which the assembler will then begin spawning more droids into the squad until all the ratios are restored again.
I didn't consider mixed-type squads. But actually, it's still totally possible. Assign each droid type a 'weight,' and then the squad weight (sum of all individual droid weights) can only increase up to a certain threshold as determined by research. Terminators could have a weight of 30, while clockwork riflebots would have a weight of 2.
I still think the Terminators could have their own research that reduced their weight. There's such a gap between them and the next tier down that, by the time you've gotten to the midgame, you've probably already done a fair amount of research into increasing your squad sizes. It doesn't make sense for the Terminators to benefit substantially from this. Unless, I suppose, their starting weight was so high that, without some research accomplished, you've only be able to put them in squads of 2 or 3. :)
Oh shit, nice idea - like in Warhammer 40k your army has a 'points' limit, so instead of a specific arbitrary unit count, it's actually a weighted sum of points cost per unit that limits the army. So if you had 2000 points limit (which can be increased with research) then terminators could be 100 points each so you are limited to 20 or whatever, or up to 400 battle droids (assuming 5 points each or whatever).
There is merit in your idea, for sure. We can make some serious meme-machines and have people build "pylons" to increase the points cap :)
But seriously, some kind of robot control towers with a points capacity, and a global points limit would be good. This is also important for PvP games because each force can be points capped and will assist with balancing significantly. It would become beneficial to have allied forces with their own points cap than to stack all players into one large force, makes it more exciting.
Although one huge force of players could maybe do 'infinite research' to progressively increase their army limit?
and to address the rest, yeah, I agree that an assembler-centric approach could generally be good. One thing we'd need to consider is whether squads that were manually commanded by the player would end up going back to their original assembler's sphere of influence (might feel weird, if they've been taken halfway across the map by the player), or if they'd be auto-reassigned to the nearest assembler once the player stopped giving commands.
Another consideration is what to do with squads that are manually set down by the player. They don't have an assembler, or ratios, or...anything. We could auto-assign them to the nearest assembler, and assume their ratio should stay the same.... but if a given assembler didn't have the appropriate bot types, then the squad would never be able to go hunting again.
I wonder if having an assembler able to be set to 'defend' mode might allow us to also simplify the current system where there are separate "guard" and "targeting" assemblers. It would be nice to do away with that complexity.
You must construct additional pylons. Heck yes. My childhood.
yes the defend mode will remove the guard station, which is nice. can cut back on unique entities in the mod. I might also remove all the flying units as well, seeing as they are not even 100% implemented (the activity module doesnt count them, for example) and they don't work with the patherfinder as i'd hoped to go over walls and belts. No loot chest anymore either. Some streamlining to do!
to remove complexity as well, can just disallow the users from placing droids by hand. The selection tool to select a squad that has been spawned by an assembler can simply tell the assembler to release control until further notified - then the squads will do the player's bidding until told to regroup (hotkey like Control + G) otherwise things like the attack-move clicking (with idling at that location when they arrive) and using Control + F to follow the player will be fine.
to be honest, I'd be sad to see the ability to manually place the droids disappear. I prefer to use droids for self-defense and spot-attacking rather than bother with all of the fancy tech and putting myself in harm's way. So if I had to retreat while out scouting instead of just tossing down a group of bots, that would be unfortunate.
Maybe droids placed by hand (and not into an existing squad) will form a player-centric squad, which will always defer to the player (if ever). Or just sit idle and rely exclusively on RTS style controls?
I was actually thinking that it would be fairly simple to allow the player to manually reassign squads - just shift-left-click on an assembler and the squad would be assigned to it.
But yes, it would definitely work to have player-placed squads sit idle instead of getting automatic targeting info.
Regarding clicking, I think clicking an assembler and clicking on the ground somewhere to place a rally point would be sick