Oh, for sure. To be a bit more clear, I've been thinking of essentially the following three states for ships:
1. Sitting still and bored
2. Traveling, may or may not be shooting.
3. Squad is stationary and shooting, but ships are not stationary.
In the case of #1, I'd see the human units as being more disciplined and kind of chilling. The AI units should probably lazily swarm, sure.
For #2, I'd like to see the humans moving around a bit in a cool formation that looks like they're actually on the move, but not going around in a nuts-o fashion. For the AI units, I guess it should be lazy swarm normally, or angry swarm if have shot recently.
For #3, the AI does the angry swarm (along the lines of now), and the human side would do more organized-looking evasive maneuvers, I think. These things aren't hard to create, and today I think I came up with a way of efficiently blending between the states of multiple swarms without eating your CPU, so I'm happy about that.
---
Fun sidebar:
- Basically instead of having individual paths for ships and them following them as they do now, instead I'd just have a few centralized paths that are calculated on an ongoing basis all the time. This is more efficient anyhow, because one of the biggest expenses of these flight paths is calculating the local coordinate space (space relative to the squad) position and orientation of the ships.
- I would be running those simulations with invisible dummy objects, and since I'm running something like "humans sitting there #5" and "human aggressive swarm #5" at the same time, any ship can "query" the rotation and position of those at any time. That has massive parallelization gains, for one thing -- assuming that there are a certain volume of swarming objects, which we can assume there will be from a baseline standpoint here.
- At any rate, since I can query both of those states at all times in local coordinate spaces (relative to any parent squad), this will then mean that I can do linear interpolation between two states over a period of time that I define. Thus basically having two separate spline paths that I do a lerp between over the span of time that is based on the distance between their starting offsets, potentially. Then just committing to mirroring the new spline point or the new offset point.
This won't make for too much visual repetition, since I can easily have a large number of splines being simulated centrally (dozens), and ships can query them without worry. I can also put in further improvements to have those only turn on on an as-needed basis if that is really required, although that runs the risk of premature optimization at this stage of things. And anyhow, right now there are only 10 patterns that are being repeated identically for all ships, and folks have not seemed to notice, although there's often an offset on individual ships with them at the present time.
But what I can do instead of offsets along the path (as happens now) is instead add in arbitrary path rotations around the center, which would inherently make things look far more varied than they even do now. If that's even an issue.
Depending on performance profiling, there's a variety of ways I can handle that stuff in the small details to get the best variance-to-performance ratio. I can also gain performance by not updating stuff that's off screen but on the current planet (I already was planning on that), and I can tie this gracefully into the LOD system as well.
Anyhow: with that sort of flexibility, a lot of stuff becomes possible.
