Target selection of Swarms

Request new features or present your ideas.
Post Reply
User avatar
Caldazar
Posts: 6
Joined: Sun Feb 15, 2015 10:33 pm UTC

Target selection of Swarms

Post by Caldazar »

When a hive finds a valid target (= a human in range), it launches a swarm to attack that target. The think() function of the swarm, however, completely ignores its current target and just makes the closest human the new target. That happens every 0.5 seconds.

I see a few problems with that:

  • Whatever fancy target selection algorithm is used by the hive, it has very little influence.

  • The property target->numTrackedBy is not consistent with the actual events in the game and therefore useless. (The swarm doesn't adjust these numbers whent changing targets. Bug?)

In short, I think this behaviour should be changed and I'm willing to implement it. The important question is: When should a swarm change targets? Possible approaches:

  1. Only when the current target is no longer valid. (dead, out of range, ...)

  2. When it finds a considerably closer target.

  3. When it finds a closer target. (current solution)

  4. When it finds a better target - for more complex definitions of 'better'.

In any case, it's important to keep numTrackedBy consistent.

I'd go with version 1. Any suggestions, ideas, complaints or objections?

User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Re: Target selection of Swarms

Post by Viech »

Hey, the hive logic was pretty much maintained from Tremulous from what I know. With the new hive, we also got a tiny insect model ready (with a flying animation) that wasn't yet implemented. My plan was to spawn about eight individual insects (270 tris each) with a mind of their own. For example, the remaining insects of an attack could target another player, the swarm could roam around and deal damage over time or the amount of returning insects could affect the hive's cooldown, etc. If you want you can implement this and figure out a cool swarm logic on your own! We do have support for iqm models on missiles now as used by spiker and rocket pod (though I think that normal mapping doesn't work yet and I also haven't checked if there is animation support - you may need to add the latter, the former I plan to delegate at some point). Does this sound like a fun project for you?

Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

User avatar
Caldazar
Posts: 6
Joined: Sun Feb 15, 2015 10:33 pm UTC

Re: Target selection of Swarms

Post by Caldazar »

Swarmlogic sounds interesting. I'll give the it a try. On Amsterdam Unlimited, a trem server, we had a mad that made hives actively track their target. Made them pretty dangerous. I'm tempted to implement something like that. But I'll see.

I'll let you know when I have a general outline for the swarm behaviour.

User avatar
Caldazar
Posts: 6
Joined: Sun Feb 15, 2015 10:33 pm UTC

Re: Target selection of Swarms

Post by Caldazar »

After a bit of consideration and a very constructive discussion with Xedoh on the topic, I now feel confident to present a gameplay concept for hives. I'm looking forward to feedback on the basic idea. Please don't get lost in details like precise numbers for now. There will be enough time for that later.

The Purpose of Hives
Acid Tubes and Spikers both have a short range and attack basically everything in that range. My idea is to give hives the opposite role: Attack a specific target and pursue it relentlessly. This distinguishes hives from other possible defenses.
From a lore perspective it's worth noting that swarms primarily defend their hive. That they defend the alien base is a useful side effect.

One Swarm vs. Individuals
Splitting the swarm from one entity into several individual insects sounds cool, no question about that. But from a practical point of view, there is only one real advantage of simulating each insect individually: The swarm can split up and each insect can act independently from the others. Having a swarm split up is really only useful if you want to attack several humans at once. That does not really fit with my concept of using hives to pursue a specific enemy. You pay for that little advantage with a large number of gentities. That implies a higher computational cost for the simulation, a larger memory footprint and more required bandwidth. In addition it is harder to program. In short, I think that simulating each insect individually is not worth the cost.
Instead I suggest to simply have the size (in insects) as an attribute of the swarm. This is sufficient for the concept that I will explain below.

The Current Hive/Swarm Behaviour
A hive regularly checks for valid targets nearby. Then it launches a swarm to attack the best available target. The problem is that hives almost completely ignore that target and just go for the closest human instead. As a result, the target selection algorithm, that is used by hives, has hardly any impact on the game. Swarms will also stop to follow a human when they lose sight of it. A swarm that attacks an enemy dies immediately after that. A hive can only have one active swarm at a time. That means it has to wait for its current swarm to either return or die, before a new one can be launched.

The Proposed Hive/Swarm Behaviour
The first change I propose is that swarms don't change their target easily. Instead, they chase their chose victim until it is dead, far away from the hive (which the swarm wants to protect), or absolutely unreachable. In this case the swarm will either choose and chase a new target, if available, or return to its hive. This is the first point where the swarmsize comes into play: Each insect (instead of the whole swarm) can only attack once and then dies. When, say, only half of the swarm is required to kill the target, the other half can keep fighting.
The higher persistence of swarms has one significant disadvantage: The average DPS of hives will decrease when swarms spend more time tracking targets. To counter that, a hive will have several swarms at the same time. Instead of the binary "I have a swarm or not", the hive will have a number of insects available. New insects are produced at at specific rate. When that number of currently available insects is >= the default swarm size, the hive can launch a new swarm. One hive will not attack the same human with two swarms at the same time, but it can attack two humans at the same time. Also, when a swarm kills its target, it can then attack the human that is targeted by its brother swarm.
A newly constructed hive will have one full swarm. The total number of insects a hive can support (at the hive or in flight) is 3 times the standard swarmsize, so it can have three full swarms at the same time.
Moreover, only two swarms can be inside the hive at the same time. When a hive reaches that limit (and has no swarm currently outside), it will send on of these two swarms to patrol the area. The current idea is for that swarm to randomly choose structures in the vicinity of its parent hive and fly around between them. Should it detect a valid human target, it will chase it. Then it will either attack a new target or return to the hive - just like described above. There are two reasons to introduce that patrol behaviour: The patrolling swarm can the same target is its parent hive at the same time (which increases the burst damage) and having swarms fly around the base might contribute to the atmosphere of a living alien base.

I have one more special rule to confuse those of you that have prevailed until now: A hive that is directly attacked will immediately launch a swarm to defend, even if it doesn't have a full swarm available. In that case, the launched swarm will simply be smaller.

An Example
Currently, a swarm causes 80 damage. The obvious equivalent is to have insects that cause 10 damage and a standard swarmsize of 8 insects.
Assume that at t=0s, a granger builds a new hive. Initially that hive has 8 insects - one full swarm. Then it produces new insects at a rate of one per second. At t=8s the hive contains the maximum of 16 insects, so it sends one swarm on a patrol around the base. At t=16s, the hive contains 16 insects again and has 8 insects on patrol. With three swarms of 8 insects each (8+16=24), the hive has reached its maximum capacity and stops producing insects.
A few seconds later, a naked human attacks the base. The hive is the first to spot it, and launches a swarm to attack. A moment later, the patrolling swarm also spots the intruder and attacks. That newly launched swarm hits the target first and causes 10*8 = 80 damage. After that, the patrolling swarm hits the human. Two insects deal enough damage to kill the attacker, so six remain. In the absence of another target, he remaining insects return to the hive. In the meantime, the hive has regenerated 4 insects and is at 8+4=12 residents. The 6 returning insects are added to that. The hive population increases to 18, so it immediately launches a new patrol.
I hope that this example is somewhat helpful. I think it covers most of my proposals.

Gameplay Implications and Balance
My proposal boils down to a complete overhaul of hives. With the suggested attributes, a full hive will cause a very high burst damage (160 almost immediately and an additional 80 soon after that), but require some time to regenerate. After that, they require 10 seconds to produce a new swarm. In comparison, current hives produce a swarm every 3 seconds. Not counting the initial burst, my proposal reduces the DPS from 80/3 = 26.7 to 10.
This damage characteristic (high burst, low dps) further distinguishes hives from acid tubes. It should make suicide rush against alien bases much less effective and promote sustained assaults. An attacking group that can weather the first wave of swarms, will have a much easier time staying put.
They will not, however, have an easy time escaping. The new swarms will be very persistent and quite difficult to shake off. On small maps, they swarms might follow their targets halfway back to the human base. All put togeher, the new system should make high level alien bases stronger, which I think is a good thing.
One might argue that the relatively long distance violates the principle of aliens being close range fighters and humans using ranged weapons. I disagree for the following reasons: The distinction is not a hard limit and we already have goon barbs and painsaws. Also, the sensor range of hives would not be (much) bigger than it is currently, so aliens wouldn't just get a rockedpot equivalent. When you comp close to the hives, however, you have a problem - and that's how I think it should be.

Open Issues
I think there should be some way to see how many insects are roughly available to a hive, but I don't know how to present that information. Any ideas?

User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Re: Target selection of Swarms

Post by Viech »

Caldazar wrote:

there is only one real advantage of simulating each insect individually: The swarm can split up and each insect can act independently from the others.

That and you get a swarm that really looks like one, indivudal insects that can die if they are shot or caught in the flamer, etc. You don't need to have the swarm split but still I'd like to move away from the particle system cloud that doesn't feel remotely like an actual swarm.

Caldazar wrote:

You pay for that little advantage with a large number of gentities. That implies a higher computational cost for the simulation, a larger memory footprint and more required bandwidth. In addition it is harder to program. In short, I think that simulating each insect individually is not worth the cost.

Not really true. Due to the tris count of the insect model we have we can't go much higher than eight or ten individual insects anyway (whether in a particle swarm or as individual missiles). A spiker fires a barrage of 26 entities per shot and a flamer produces maybe ten entities a second. If I remember correctly even bullet holes and footsteps are entities. A handful of insects per hive doesn't make a vast difference.

The computation cost isn't that high either, except if you need to iterate over entities and do traces nearly every frame (which the rocket does for tracking targets, anyway). This will only get less expensive when we move the gamelogic to CBSE, as iterating will be much cheaper and traces will be done without trap calls eventually. As with all performance questions, an economical design is good but before you over-optimize, launch a profiler and see if the function in question even shows up.

For network performance, it's important to keep the number of direction changes relatively low. No matter if you create a single swarm or individual insect missiles you'll also notice that trajectory changes aren't interpolated on the client (yet), which is for example why the rocket creates visible jerks when playing online but flies really smooth when playing locally. Ideally this is something to be improved in the gamelogic backend.

With regards to your idea, it sounds really cool. Be aware that it's entirely impossible to predict balace impact at all. Therefor, never design around damage values or anything like that, you will change those later. What counts is the quality of the design, not the quantity. (For example, having nearly unlimited range is a quality of a rocket pod that makes it the distinct defense buildable that it is. How much damage an individual rocket does is irrelevant to the design.)

The quality of the hive seems to be to deal burst damage against single attackers and rare rushes (that's also one core idea behind the Spiker) and I really like that the insect population in the base is a visual indicator of a base's strength in that regards. I have only two kinds of feedback so far: Try to not overdo it to the point where it gets frustrating and also think about how you can make the role more distinct from the spiker. The range difference is obvious (and means that it should probably deal less burst damage then getting cosy with a spiker, because why even build the latter then) but in addition to that, you could consider making the insects deal damage over time to their target (and die after certain damage was dealt). To also distinguish from the acid tube, which does just that, the hive could be most efficient against enemies that stand still, so that attackers are forced to keep moving (and therefor get in reach of spikers and trappers). This leaves the acid tube as the weak but inexpensive and reliable defense and the spiker and hive as more specialized but less reliable tools.

Caldazar wrote:

I think there should be some way to see how many insects are roughly available to a hive, but I don't know how to present that information. Any ideas?

The solution is to redesign the way how information about the base are represented to players, especiall to builders, by making use of the new dynamic HUD elements to build rich buildable/beacon status displays. You may have noticed that the current buildable status displays lack text, which was a regression when we introduced libRocket. I would postpone this and don't display anything for now.

Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

User avatar
Caldazar
Posts: 6
Joined: Sun Feb 15, 2015 10:33 pm UTC

Re: Target selection of Swarms

Post by Caldazar »

Viech wrote:
Caldazar wrote:

there is only one real advantage of simulating each insect individually: The swarm can split up and each insect can act independently from the others.

That and you get a swarm that really looks like one, indivudal insects that can die if they are shot or caught in the flamer, etc. You don't need to have the swarm split but still I'd like to move away from the particle system cloud that doesn't feel remotely like an actual swarm.

You've got a point. I'm not quite sure how to implement that, but I'll think about it.

Viech wrote:
Caldazar wrote:

You pay for that little advantage with a large number of gentities. That implies a higher computational cost for the simulation, a larger memory footprint and more required bandwidth. In addition it is harder to program. In short, I think that simulating each insect individually is not worth the cost.

Not really true. [...] As with all performance questions, an economical design is good but before you over-optimize, launch a profiler and see if the function in question even shows up.

Even little overhead is too much for no gain. But since there is a point in simulatingindividual insects, I agree with you.

Viech wrote:

With regards to your idea, it sounds really cool. Be aware that it's entirely impossible to predict balace impact at all. Therefor, never design around damage values or anything like that, you will change those later. What counts is the quality of the design, not the quantity.

The first sentence is what I wanted to hear. I fully agree with what you say about balancing. The numbers in my post are just an example to make the whole thing less abstract.

Other than that, a few very good points about the roles of structures. Food for thought.

Post Reply