Spring RTS Engine

I have strayed from the sworm path, to bring you another unfinished work:
aggressive guard widget!
I tend to guard construction units that are moving out into the scary wastes with combat units, which is an act of faith, or stupidity, take your pick. The combat units just follow behind the construction unit, turning the "guarded" unit into their early warning system / body shield. This behavior is great for construction units assisting other construction units, but not so great for guarding them. So i wrote a widget that uses combat units to guard in a way that guards rather than follows. The code needs some cleaning (some redundancy), and the differentiation between aggressive/nonaggressive guarders could probably use some polishing.

guarding a moving unit


guarding a stationary unit

OMG - I have waited for this so long - thank you!!

The default behavior was for maps like CCR useless.
Ofc the 1v1-micro-pros will hate it, but to me it means more strategy and less jeffy-micro :)
Will test it tonight and report.

dansen, if you haven't tried it yet, attached is an improved and more optimized version. warning: in 87 with BA 7.65 it barely works because whenever the guarding units run into any structure they just stop dead in their tracks. sigh.

If you're working on guard, my big *want* feature is the ability to guard multiple targets. So I can select cons, tell them to guard *everybody* in the group, and they'll follow along and heal/assist *anybody* in that group that needs healing/assisting.

Pxtl wrote:If you're working on guard, my big *want* feature is the ability to guard multiple targets. So I can select cons, tell them to guard *everybody* in the group, and they'll follow along and heal/assist *anybody* in that group that needs healing/assisting.

This, definitely this.

Also, from your screenshot, it looks like they are still lagging behind the moving unit a bit. Would it be possible to have them patroling more evenly around a moving unit?

The guarding units are moving around in front of the moving units.

Google_Frog wrote:The guarding units are moving around in front of the moving units.

I can't tell if this meant to assure luckywaldo7 that they do in fact move in front of and not behind, or a complaint that they get in the moving guarded unit's way. (The latter would be bad, and something I've obviously been trying to avoid.)

luckywaldo7 wrote: it looks like they are still lagging behind the moving unit a bit.

They aren't, but it does happen because the guarding units don't update their fight orders until they get to the old fight order's target. This happens because the widget doesn't register that they're guarding unless their current order is in fact a guard order. I need a better way of keeping track of this.

Area/group guard would be handy. I may or may not be up to writing such a thing.

works for me :)
only problem I had were guarding units getting stuck behind freshly build mex - but that's not a problem of your widget but of the general "stuckiness" of the current spring units :)
What's the value to play with to raise the "aggressiveness" (when to attack a detected enemy unit)?

at the moment they don't really detect enemies. nothing that intelligent. the guards just have fight commands, so they'll attack anything in their range, I think (?). the number you might change is forwardDistance, which is 200 by default (and the actual distance is dependent upon how fast the guarded unit is moving) but you don't want to set it too high--then they might become too far away, and lose their value as guards entirely.

This happens because the widget doesn't register that they're guarding unless their current order is in fact a guard order. I need a better way of keeping track of this.

You could use a trick I used for auto-skirm. Have the widget remember the coordinates of the command it gave and let it override a fight command with those coordinates.

Google_Frog wrote:You could use a trick I used for auto-skirm. Have the widget remember the coordinates of the command it gave and let it override a fight command with those coordinates.

genius. at the moment the number of guards (used to determine whether they circle-patrol or go to the side opposite your base) is found using the last local maximum, because it fluctuates so much.

for anyone who wants to use it, this version should have significantly less dumb behavior. guards are evenly distributed across the possible positions, and dynamically redistribute if units leave or join. the guarded unit only doubles back to wait for the guards to catch up if the guards are within a speed tolerace (1/2 to 1.1 times the guarded unit's speed), and not too far away. the guards are not given fight orders unless they're within a certain range of the guarded unit. how far ahead to move guards when the guarded unit is moving scales with speed much less drastically. it is also far more responsive because of google frog's trick.

still definitely needs to be optimized...

Only problem I had with it was that my tanks went all over the place, and when going up a hill or something, they would get stuck with fight orders on the edges of cliffs.

Imo, an almost better way to do this would be for the guards to arrange themselves in a circle around the guarded unit.

Will check out this version.

Edit: Checked it out. It's an improvement, but for the love of god, stop making them move around. Just have them do a formation around the guarded unit. The moving around results in unit getting stuck on cliff edges and then the builder gets orders to turn around and go back and the unit unsticks itself but now gets and order to move in the opposite direction while the builder receives another 180 degree order causing the unit that unstuck itself to get stuck again, rinse repeat for 30 seconds till the entire thing unfucks itself...

Seriously, the moving around stuff does more harm than good. Circle formation around the guarded unit ftw, you could then set the guarding unit's movestate to roam, negating the need for a fight command in the first place.

By "move around" do you mean the ring-around-the-rosy thing the units do when the guarded unit is stationary? I agree, it would be better for the guards to simply find a place around the circle and stay there until the guarded unit moves again.

I'm also uncertain the doubling back to let the guards catch up is necessary (and it causes problems). I did that because I wanted this guard behavior to value safety over speed, but really, when does anyone guard a moving unit with something slower than it and expect everything to work out?

They still move around all over the place sort of when the guarded unit is moving (but not much), and yeah, ring around the rosy would be fine, but instead it's just kinda moving all over the place crazily. Imo, it would be far more efficient if the guarded unit were simply surrounded at all times (as much as possible).

Con units generally cost less than the unit guarding them, so by default spring's targeting will target the escorts first (in many cases).

Cool idea. Keep in mind that often there will only be 1 guard-unit. Because that is often enough vs the lonely scout or two.

Iirc, unless there are 3 or more guarding units, this widget does nothing (could be changed easily I expect).

Forboding Angel wrote:Iirc, unless there are 3 or more guarding units, this widget does nothing (could be changed easily I expect).

false. what it won't do is try to make a circle when stationary with less than four units.

First of all, awesome idea, nice widget.

It seems that second version is better than last one. Last one makes my cons go back every time and loose too much time.

Complete rewrite of ancient widget!

Places guards in a circle unless there are only one or two guards, who go in front and (the second goes) in back of a moving unit. Only takes effect if the guarding units are faster than the unit they're guarding, can attack, can't assist, and can't fly. edit: a few improvements to what happens when guards or their guard target are attacked