An idea about Flowfields and Stealth

The problem here is you've just invented a switch that says "gain a tactical advantage" sure, you need to know what kind of tactical advantage you are getting to avoid using it when your units aren't fast enough to do it. But it's stupidly fire and forget and forces the enemy to micromanage their units to hell in back just to survive it, it makes long range, high mobility units become practically invincible against anything slower than them when they already have huge tactical uses. So, what you have is a switch that you can turn on and off to force your enemy to micromanage, reinforce, or die. Sure, it's not an end-all-be-all, but does it really add anything, other than frustration for your opponent?

Now I realize, that since I'm siding with Neutrino, that means I'm arguing for essentially the opposite circumstance on the economy side, "All I have to do is send units out to destroy a couple generators to force my enemy to micromanage their base", but the ideas are fundamentally different. For one, you'd have to actually destroy the generators, and for two because you'd have to destroy enough of them to have an effect, and you are going to lose some units along the way no matter what. Auto-kite a group of tanks with a couple long range, glass cannon type units, and you pretty much get to destroy those tanks for free, provided you have enough time. Just from you toggling a little command. Overexaggeration... Probably.

But besides all that, I don't see Auto Kiting as anything other than needlessly taxing, or wildly over-complicated to program with the flow field model of pathfinding.

The enemy got the same "tactical advantage". You might as well balance the game around kiting if you are gonna include it in the game. Even if you don't have Auto kiting in the game players will do it if it is beneficiary to do. I'd rather limit the amount of tedious micro when you are going to fight on several orbital bodies at once. Be it with auto-micro or if there simply isn't much to be gained from kiting by design.
Kiting is however an interesting strategic element. This allows your forward presence to transfer to damage to the enemy by kiting them.

Why would it take a lot of micro to counter kiting? If you cant fight then flee to where the kiters can't reach or lure them into a pincer attack. Select units and send them back with 1 command.
The usual ways I counter kiting units:
1. Run em down. Close the distance by speed. This just requires the right units and the critical amount of them.
2. Flanking. Approach them from several angles so they can't use their full speed to kite my units. When approached from several angles the kiting units can't run straight away from my split forces.
This is both tactical and strategical as I can try to control the map in order to pincer the enemy kiting units.
None of these methods are that micro demanding.

Players will perform kiting with this type of long range glass cannon units regardless if there is auto-kiting or not.
Including Auto-kiting just means that newer players can kite much more easily and that it scales much better across several battlefields as you don't have to do it manually.
Kiters require both space and time. If there is a counter to kiting units like the Raiders in Zero-K which are fast then this means that an overextended kiting force risk being run down by Raiders or flanked.

Taxing on the computer?
The algorithm is quite simple. Move away from closest enemy when it is approaching and in range.
In flowfield pathfinding the kiting unit will just push away whatever friendly unit is in its' way.
Nothing taxing or complex to program there.

Automatically attacking from outside enemy range is a good mechanic - you could sort of do this in SupCom with the alt-attack but Zero-K's method is neat.

I'm gonna ignore the first two points for a little bit, because I know I'm probably wrong in this case, and even if I'm not, I definitely don't have enough ammunition to combat with you over it. I'll just take a token nod to say yes, if you include kiting, balance the game as if it includes kiting, and kiting isn't really an issue.

So now I'll instead, address the third point, since it's the only point that I know I'm right on. What you have to consider in that algorithm is that the cost fields are not unit, nor platoon/squadron/group specific, they are movement type specific. So if you go and change the cost field of a movement type, you change it for every single unit in play that has the same movement type, both friend and foe. So say you want a group of mobile, lightweight (bipedal bot) scouts to kite as they scout your enemy base, so you say, "Okay, I'll just add the positions of all enemy units to their cost field. easy." sounds really simple, and it is really simple, but it's really dumbly glitched and fundamentally flawed. Because the moment you add that hostile unit to the cost field, you've added that unit to the cost field of Every Single Bipedal unit, so suddenly, in your enemy base, all of his moving Bipedal units are avoiding everything in his base like the plague.

Well that example is definitely exaggerated, because units all have aiming systems, so it would be much less buggy to just go and say, "Alright, instead of that, I'll just add any units that my scouts are targeting to the cost field." not much more difficult to think about, or to program, but still messed up, because when your scouts start targeting a group of bipedal enemies, all of those enemies would get added to the cost field and they'd start avoiding each other like the plague, then no doubt that initially tightly packed group of units is now spread out, all spaced at a distance equal to your unit's range, so initially, even though say 24 were in the range of your scouts, they've rather immediately spread out so that probably only 5 of them are in your range. Which leaves the question of "how do you get rid of that cost, contextually, after the units leave my scout's firing range".

As far as I can tell from the livestream, the answer is that you just don't. Units don't have access to adding to the cost field, and even though it would be easy enough to give them access to Add to it, it's much more difficult to make them subtract from it, or continuously change it. About the simplest way, that wouldn't invite memory leaks, or memory overuse, is to make a unit add and subtract to the cost field beneath their feet, because keeping track of any other locations or movements would quickly lead to trouble with the kind of scale this game is talking about, not to mention that if all units were constantly changing the cost field, the flow fields of all movements would be constantly recalculated, and the primary benefit of a flow-field is that it only has to be calculated 2 or 3 times at max.

But, let's say it were possible for units to create a constant cost footprint, you still run into another problem, in that you'd have to make units send variables to one another to make that work. Your scout, would send his range over to his target, and tell his target to add that range to the cost field beneath their feet, but what tells the target to stop doing that when he leaves that range? The answer is nothing, once he has left your scout's range, your scout HAS to stop talking to him, or there would be no sensible way for them to ever start talking in the first place, if there is no end to their interactions, then their interactions MUST be constant, from the moment they were created.

And well, there is an alternative to that, but it is also taxing on your computer, and weird to code, which would be to have all units constantly checking to see if someone is talking to them, and if they were just talking to another unit, AND they are no longer talking to a unit, then they need to change a few variables, erase their current additions to the cost field, then tell themselves to stop adding to the cost field, or they would only ever add their standard footprint unless that method your scout used to talk to them overrides that. The last option is actually an absolutely minimal effect on computer processing, but it's built upon the bad idea of giving units to move their own cost-based footprint.

And that is only for Defensive kiting, Offensive kiting would also add a drag to the unit you are targeting so that you'd follow them as well, which effects your integration field (the field where your waypoints will go that is used in combination with the cost field and math to make the Flow Field), which actually isn't all that hard to do, that's where the flow field still has some advantages, but since your integration field would be constantly changing, you'd still be constantly calculating your flow field. And then there's the other problem that your unit does not store it's own waypoints, the integration field it is sitting on top of stores them (integration fields are group specific, unlike cost fields), so while your unit is kiting around, it would either lose it's initial waypoint, or the wild movements of the cost and integration fields would leave your flow field a very twisted and inefficient pathfinder. (Oh, and did I mention that if you choose the latter option, then you are looking at really weird, unpredictable glitches and pathfinding bugs while you kite that will likely destroy your units)

So, simply put, if you use the cost field, you will not be going to space today.

Which, alternatively means that you have to make auto kiting a part of the unit's thought process itself. In which case it seems simple at first, and then it immediately becomes ugly. Because basically, by telling it to kite, on top of the flow field, you are now essentially modifying the unit's movement pattern while it kites, you'd be telling it to take brand new things into consideration, like enemy position, and it's own range, and you'd be putting that into the existing movement method inside of your unit, the problem here, is that the only thing that the movement method does, is grab a vector from the flow field, and tell the unit how to turn. And the problem is, that if you modify that vector in any way, you lose all the calculations that went into it to make it a useful vector, your simple "keep distance from the enemy" turns into "take distance into account, and average the vector that tells you to go along, with the vector that you just grabbed from the flow field" And what's to say that the new vector you've produced isn't just one that will lead the unit into walls? Absolutely nothing, because that unit doesn't look at the cost field, and it doesn't look anywhere other than directly beneath it's feet, it has ZERO way of knowing that it's brand new vector is taking it through a wall, or off a cliff, or directly into an inescapable flow field loop. And how do you give it awareness of obstacles like that while kiting? You give it a brand new pathfinding algorithm, because you've invalidated the premise of the old one, so much, that it is not even remotely reliable whilst kiting.

And guess what a new pathfinder that is made explicitly for units that you've switched this little "tactical maneuver" switch on for? Taxing on the computer, especially on the scale that this game is shooting for. So... Yeah. I think I can pretty definitively say that this is NOT a simple "keep your distance" switch, and implementing it would be, a pain in the ***, time consuming, bugged and/or unnecessarily ponderous for the computer running it.


EDIT: Huh, just thought of another way of approaching it, which actually isn't bad (but still has a few, rather heavy fundamental problems), which would be to add a "repulsion" waypoint to the integration field that would essentially work like a cost hill, but could now be calculated per group without glitching random units across the way, wouldn't invalidate the flow field, and with a little tweaking, would be simple enough to program. You'd have your scouts throw out these repulsion waypoints anywhere that they had a target, then suddenly they kite everything pretty awesomely without glitches or random unit effects. The first problem, is that we, once again, run into the fact that units are fundamentally ill-designed to interact with flow fields, and they would have an awkward time deleting any repulsion waypoints that they created, but they would be forced to do so every time their targets moved, next we once again run into the fact that flow fields get their maximum benefit when they are changing with as much finesse as possible, and this system would have these flow fields changing every time the targeted unit positions change, and there could potentially be a lot of targeted units, moving in a lot of different ways all at once, and lastly, we could have loads of different units and different ranges to consider for targets, each requiring their own amount of repulsion, that would have to be referenced pretty repeatedly, which could potentially tax a weaker computer, if it wasn't already utterly choked and hosed over the relentless flow field calculations.

And, so help me god, I will bitchslap anyone who nit-picks me over confusing whether the kiting unit, or the targeted unit needs to give away their range, for missing the point so intensely.

EDIT2: Now I'm just confusing myself because I realized that several times I very succinctly described why moderating unit spacing with flow fields may be impossible... Well it could be done with collision detection that pushes the colliding units apart to a certain distance, arbitrarily, without changing the flow field, just modifying the unit's position, and given the right variables that would probably average out to coherent unit spacing... Though balancing it in terms of fire power, and DPS and splash density and all that stuff seems tedious (not quite difficult, just a lot of playtesting and tiny tweaks).
Okay, confusion over now. I can go to bed.

This is a good idea. I don't think it really counts as automation...depends how far you carry it I suppose. But for the most part having stealth units automatically go around detectors would remove a lot of frustration. And in a game like this where you have a million things to think about at once on different planets not having to babysit a cloaked scout would be a definite boon.

I can't tell you how many times I've had units in other RTSs waltz right over visible land mines without hesitation. Sometimes being a slave to the players exact orders isn't necessarily a good thing.

I think someone could use this argument to argue against unit pathfinding altogether, because when telling units to go from point A to point B they make there own decisions and may choose a path you didn't expect. And you will want your cloaked units to be somewhat automated when you're trying to sneak around on one planet and fight a battle on the other. The automated economy doesn't help you in that situation. I wouldn't even call it automation, it's just smarter unit AI.

Also, I don't think you can quite compare this to the auto-kiting thing. Auto-kiting is a combat behavior and this is more like smarter pathfinding. I don't expect cloaked units to run away when a mobile detector approaches them.

lol I just finished editing my post when I saw your post, and I've gotta say, excellent post. Especially since visible land mines are something that could easily add to the cost field when placed. Though it would probably give them a little more weight if they were only added to the cost field After a few Dumb units blow up by walking over them. And they would be extra balanced if they only added a small amount of cost, so that if they were placed in an open field, units would avoid them every time, but if placed at a choke point, or at the top of a hill that units were forced to climb, the units would blindly march through them if the player didn't notice them. All in all, I think that's an excellent mechanic.

I do believe it is also possible to make stealth ground units path around poorly placed detection towers(?) with ease while still making the same towers a good defense, by giving stealth units their own movement class, and their own cost field, then treating those non-mobile detection devices the same way that I just addressed for regular units avoiding land mines. Poorly placed detection means your stealth unit walks right around it, well placed detection means that the unit is forced to walk right through it if the player didn't take the time to check choke points along it's path for such traps.

the thing about automating ff cost for land mines is that it sucks if you start to think about it.

It is essentially automatic the order to go around them instead of through them. What if you want to go through them, send in some quick disposable units to clear them out? ops you can't do that because there is a cost field in the way, not unless you want to send a guy to each individual mine.

What will the point of building mines be anyway? all units with any form of detection will just walk around them effectively turning them into expensive walls. Or if you try to use them as expensive walls they might not have detection and they walk straight through.

This devastatingly cheeky trap becomes unreliable in any of its possible functions and has to be balanced for all of them.

Any form of automation that comes from the use of flow fields HAS to be optional, after that it HAS to be something that can't be done easier by just shift clicking around the target you were going to do anyway. Automating micro for things like auto explore and auto flee is something that's cool to debate but they need to each be their own buttons and not restrict the players ability to give units orders.

It's worth pointing out that path-finding is deterministic - you can tell before you issue the order what path they will take by looking. However there is all sorts of unknowns with the style of automation proposed - which direction is best to kite in, for example (can be different in every battle), or how far should a unit go to avoid a minefield - if you build a long line of them, units would take the very long way around, because you have to have it binary (avoid all or avoid none) or it becomes too unpredictable to use. If a mine is visible, units should just shoot them, and if you are attack-moving, your units will stop outside the mine's range anyway. Stealth avoidance has similar issues.

Edit: Ninja'd on the mine argument.

Then you just send the disposables to the mines. Why not? A hill has more cost than flat land for unit pathfinding, but you can still command units to go onto them. cost doesn't make terrain unpathable.

Even if units are programmed to not walk into a detector's range there would be a limit. The detection wouldn't be a wall. But the unit would prefer not to. It would probably go through anyway if avoiding the detection meant walking halfway around the planet.

Also, you have to know the detection is there, otherwise you can't avoid it. If you don't see the detector tower you won't avoid the area right?

I figure mines will be really cheap (if they're even in-game; I don't expect them to be and only used that as an example from other RTSs) and mobile detectors will be more costly, so it should be fine. Besides, I think you answered my question when you said "they might not have detection and walk straight through." Isn't that exactly what you want?

Kiting inside the enemy base? That sounds really complex, it might rarely happen and if you want to do it manually you can. Auto-kiting doesn't have to be perfect.

If your kiting units run into a wall you haven't given them enough space to kite. When units kite the enemy they should go straight away from to enemy to maximize their speed which is very important if the enemy got similar or faster speed than the kiting units.
Putting enemy kiting units against the wall or obstacles is part of strategy and tactics. If the player controlling the kiting units want to avoid that he have to make sure his units have enough room to kite. This is true whether or not kiting is automated.

Auto-kiting doesn't have to do any pathfinding.

Here is Zero-K auto-kiting, auto-jinxing and auto-swarming gadget. It is 644 lines of code. I don't see why it can't be similar in PA.
http://zero-k.googlecode.com/svn/trunk/mods/zk/LuaRules/Gadgets/unit_tactical_ai.lua
In the flow field pathfinding I have seen in SupCom 2 or Starcraft 2 units typically push away friendly units without any effort. I don't know how it will work in PA but if mobile units can push eachother without any serious slowdown then mobile units wont have to take eachother into account.

First point, I wasn't talking about Kiting inside their base, I was talking about a design flaw that would automatically cause all of their units to kite inside their base, it would be an unintentional flaw of trying to kite with the cost field, and it would be the kind of flaw that would persist in new and awful ways in spite of the ways you could use to change or "fix" that flaw.

Second point and third point, I think I'm starting to work on a possible flaw in my own thinking at this point, where your side may have more validity than I am recognizing. Where I'm working under the assumption that all movement is done through the flow field, in which case, there is no need for obstacle detection beyond that cost field, because there is zero possible chance that the flow field would guide any unit into a wall. Which says to me, that if you open up the possibility of movement that is not based on the flow field, you get the potential possibility of units ignoring walls, then running through walls that don't exist to them, then glitching out the rendering or other aspects. So if you add movement that ignores the flow field, then you need brand new object detection to avoid outright glitches, not to mention simple gameplay details like low cost areas that units can path through, but generally don't, like wreckage, meaning that units who normally walk around wreckage would walk right through it while kiting and not realize it, and they'd need some form of detection to tell them how it slows them down, which is why I said that adding kiting that ignores the flow field would require new pathfinding, or at the very minimum, new obstacle detection that doesn't seem to be previously supported.
However your point about unit repulsion is one that I can say absolutely nothing about. You're probably right, I just don't quite understand how it will work. Mentioned my confusion in my edit, and realistically, that confusion still persists, so you've got a damn good point.

Fourth point, just because it was easy to do in another game, doesn't mean it will be easy to do in this game, Zero-K was not built on a flow finding system (as far as I know), so units all would already have built in obstacle detection to use for this AI type.

Personally, I just don't see what the point of having both a flow field and separate obstacle detection would be in a system without this Auto Kiting feature. So it is absolutely unreasonable to think that they would add obstacle detection just to add a small feature, that they would also have to worry about balancing in the near future. IF and only IF there is separate obstacle detection for units, does Auto Kiting even become a possibility. And it is a possibility that balancing such a thing would mean throwing away unit designs that they already have in mind. Not to mention that the idea of a toggleable auto kiting feature is most on the wrong side of the automation line that Neutrino doesn't want to cross.

Secret point, I can see auto kiting done with a flow field and no extra detection, but it would really immediately run into issues of scale, and I foresee the possibility of even one unit kiting one other turning into a difficult issue.

Like a gatdam ninja assassin. But, no, this pathfinding style is NOT deterministic AT ALL (at least not for your units, the flow field itself is deterministic). Individual units have absolutely no idea where they are going until they get there, they just react to the little vector beneath their feet. If mines represent an obstacle, then they would avoid that obstacle absolutely. AI on top of that may tell them to shoot the mines if there was a line of them, or micromanagement may give you that option as well. But the pathfinding itself is more than a little random from the perspective of the units, and little differences in their initial position could cause one unit to go the long way around a choke point that happens to be blocked by mines, and the other to blindly plow through that same minefield and be destroyed.... (the debugging that was shown might be intended to cut down on that... But I've forgotten about it... So.. Shame on me.)

The details of how much they would avoid the minefield would be determined by how much cost a mine represents. If the mines represent a low cost, but there is a long long wall of them, then going around will almost absolutely cost more than going through, so if your enemy has taken the time to make a really wide minefield, and you ignored it, they'd just walk through. UNLESS the AI, or the Player, told those units to shoot those mines when they got there.

EDIT: However, the more I think about this, the more multiplex it becomes, because units DID, strafe the edges of those high cost blobs close enough that it was hard to tell if they were going over no green at all, or were just avoiding 99% of the green. But flow fields aren't perfect, they don't consider ALL possible paths... I think of it like water, water will never go through rocks, but it will occasionally push through something like sand or pebbles, and will strafe as closely as possible to rocks. It depends on how much of a scale they've included between no obstruction, and rock, and how quickly a cost number starts to represent a rock.

So these flow fields will have to be refreshed every time any unit moves and recreate the flow field for every type of unit behavior on top of every type of movement?

Even if this idea didn't mutilate 50% of the commands you try to give your units, automatically circumvent my base defense, make some units automatically unbeatable (auto-kiting), mean no matter how well i sweep for stealth units i can never actually be sure an area is empty (as it would need permanent and complete omnidar coverage) and probably end up getting my troops killed with unnecessary maneuvers i didn't tell them to do... it would chew up all the CPU that using flow fields saved in the first place.

units aren't automatically unbeatable, you just have to surround units that out range you or god forbid use terrain. Zero-K has it right.

sorry you are right. I have to carefully prethink my battle and surround the group of artillery in a very attention heavy and time costly maneuver to defeat a group of guys my opponent has forgotten even exist.

Well. LOL If you follow every single suggestion on this thread and then implement them using the cost field. Then yes.

But, Stealth units Auto Dodging mobile detection is never gonna happen for a dozen reasons, and mine/static detection avoidance could potentially be implemented in a fair and balanced way that would make it stealth more useful, and would make detection towers less "so you put a tower, in the middle of a field, for no reason, and my unit thought it was a great idea to run right by it." At which point, both sides should feel dumb and frustrated. XD XD XD

Auto kiting however is the only idea here that really potentially introduces any CPU chewing aspects, and those aspects may be invalid, if those aspects are already a part of the more optimized game. I just can't see any other reason to implement those CPU chewing aspects other than Auto Kiting and similar commands, which I personally believe won't be there. But if there is another, really vital reason to implement such aspects, then Auto Kiting is a simple calculation.

However, it does create a balancing problem, and as you scathingly pointed out, it's almost insultingly fire and forget.

tanks are faster than artillery

I don't think that auto-kiting needs to change the flow fields.

Units that auto-kite just use the regular pathfinding. The script is oblivious to how the pathfinding works and just give the units a move command in the opposite direction of the enemy.

You don't need any additional obstacle detection to implement auto-kiting.
This is how auto-kiting works in Zero-K:
When the closest enemy is enclosing and in range, the kiting unit will be given a Move command in the opposite direction of the enemy. Will you be able to give Move commands in PA? I bet you will.
If you give a move command on top of an unpassable wreck. What happens?
Well according to the livestream the unit will try to go there but the auto-kiting script will give the unit a new Move command behind the wreck before it reaches the wreck and it will therefore go around the wreck.
But what if the auto-kiting script is ordering the unit to into a huge mountain? The Move commands will be set where the unit can't go. The unit will try to go there but be stopped by the mountain.
Could you do this manually in PA? I think it is most likely that you could. Why wouldn't a script be able to do it?

If you want units to avoid large obstacles you have to make sure of that yourself. Auto-kiting is a simple unit behavior much like patrol or Attack-Move commands.

Kiting units create a balancing problem because they put a high micro demand on the player in order to use kiting effectively which means that when the player have the time to micro those kiting units, they will be highly effective while the time that the player doesn't have time to manually kite with them, they will be highly inefficient.
Auto-kiting bridges this gap and makes kiting, as a mechanic, scale much better to a planetary RTS where battles can take place on several different planets at the same time.

There needs to be a way to quickly turn off the unit avoidance behaviour for stealthed units (I doubt there will be any by default but that is the topic of this thread). I cannot stress how important this is and most people seem to ignore this point entirely. Adding enforced unit AI will just create different annoying situations in which the unit AI fails and many people are very quick to point this out. Also for many things state toggles are too slow, we need commands.



I'm probably going off topic now but it's a unit AI thread, they all go the same way. I have come up with an example of the importance of control over AI.

Imagine we had a game with only two very simple commands; Move and Target. Move will simply tell a unit to move to a location and Target will tell the units weapons to shoot at the chosen unit.

The first thing anyone would do is to make a unit automatically acquire a Target command if it doesn't already have one and there are units in range. But it will still take a lot of micromanagement to shell an opposing force because if the force moves away you will have to manually move your artillery back into range.

Now someone comes up with the bright idea of the Attack command. This command can be expressed in terms of Move and Target commands and helps with the preceding situation. Placing an Attack command on an enemy unit will do a few things. Firstly your units will receive a Target command at that unit. Additionally your units will now use a little AI which gives a Move command sufficient to put them in range of the enemy unit whenever they are not in range.

Now at this point many people will become annoyed. The simple unit AI behind Attack is extremely easy to bait and kill. If someone Attacks one of your units with artillery you can simply Move backwards and bring the artillery out of safety. It now becomes impossible to use artillery because they will always be baited. This argument is wrong for two reasons:

• Attack command should not be fire-and-forget. The player who uses it should pay as much attention to it as always, they just don't have to click as fast.
• Attack does not remove Move. Players can still use Move when they want greater control over their placement. These commands should be very easy for players to switch between.

To bring us back to stealthed units avoiding detection. If they avoid detection at all there should be a command to do so. There needs to be a command (like Move) which I can activate with a hotkey and play on the map to force them to move with no care for their safety. If there isn't such a command then the unit AI will get in the way.

In short extra unit AI should not make units stupider. Units which will refuse to walk into an area which decloaks them are stupid.


@apocatequil
In short the kiting behaviour is doing the same things as a player who gives a move command. It is simply giving move commands. No special flowfield routines need to be called. It is just as simple as giving a move command.

Thank you, Googlefrog. Although it's somewhat off topic, that expresses the unit-ai concept quite well.