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.