Yeah the target selection is the easy part, it’s more getting the list of targets and iterating through them as quickly as possible. The easiest way I can think of that’s more optimized than a collision cone is a massive array that stores all of the ‘GameObject’ actor components. My only worry is that that array itself can grow to a huge size, probably over 1K in some circumstances. Iterating through all of those and getting the closest ones within the cone would be slow, so I landed on the Octree idea. Problem is, I’m not really sure of how to go about implementing those things, still fairly new to programming.
I don’t do any checks as such, but the cone itself is huge, up to 8K units long by 4K units wide, so that it has enough time to hit the target (they also travel pretty quickly, since they’re at a vehicle-scale, not a character-scale). The code quite literally get’s all overlapping actors and iterates through them to find the best target, but there are casts and for loops and just ugh. Too much codez, I don’t really want to stick with the physics / overlap route since it just seems like such a bad way to go about it.
The cone itself is indeed a mesh, with one triangle but a cone-shaped collision. I just set it’s 3D scale to match the missiles cone settings. The sphere/angle approach is interesting, I always thought that reducing the area-of-effect for the collision would make it somewhat cheaper.
Almost every actor in the world that I can interact with in some way will have the ActorComponent. Things like pickups, vehicles, characters, buildings etc, maybe even other pieces or ordnance in some cases. Manually iterating over the actors definitely seems like the best way to go about it since it avoids using the collision system altogether, but to make it uber efficient so I can simulate hundreds (maybe thousands!) of them at a time, it would also be good to cull out the ones that can never be considered targets since they’re just so far away. With an Octree I might be able to do something like that maybe… if I can figure out how on earth to implement one. The advantage is that I can use that Octree for other future endeavours too, like AI stuff etc.
The manager approach is also interesting, I think a combination of those things could make this work. Guess I’ll pester the tech manager at work about setting up octrees later down the line 
By the way just to help explain the situation, this is the game in question (from 1999), and essentially what I’d like to be able to do. I couldn’t find a good way to show you the missiles dynamically changing targets as closer / hotter objects moved into their field of view (imagine a flare / countermeasure or something). I have however switched off the smoke to keep the framerate up, and I’m spawning 500 everytime I hit the mouse button. I even added some random movement to each missle as well. Stays way above 60 FPS. Obviously this game has the advantage of being programmed to do it’s own specific task so it doesn’t have any engine overhead, but it is surely possible to achieve.
It DOES however, run at 10 TPS (turns-per-second), and smoothing is done in-between the turns. I imagine this is how it got away with doing this kind of stuff in 1999 when the hardware wasn’t up to the par it is today. Picture this + 100’s of units with their own AI, and ten players all shooting hundreds of bits of ordnance at each other all the time. Pretty hectic.
I’m already hitting latency issues with just 30-40 straight-flying bullets in UE4 (using the default replication method), so if anything this project of mine is going to teach me a lot about netcode and optimization…
