Pooling could be a solution, but it could be broken by unforseen events occuring, which is pretty much a guarantee once there’s an actual person at the controls instead of a dev-type fellow. Say you think that it’s unlikely the player gets hit more than 10 times per second, and the widget stays on screen for 3 seconds, a volume of 30 with a safety margin of 10 extra should be sufficient. Make it 50 for good measure.
Well, first you’re walking around with 50 of these at all times which isn’t optimal in itself, but if the player manages to get into a whole mess of trouble (which is very likely), the shortcomings will be painfully obvious once your pool size is no longer able to handle the load it needs. Of course you could adjust stay-time dynamically but… Is that really any better?
As a followup question though: Currently I am using get actor location → Project world to screen to make the widgets face the camera. Now this obviously has the undesired effect that if I hit an enemy, then pan the camera, the widget stays with the camera instead of sticking to the hit enemy, as per project to screen.
Is there any way I can make it always rotate to face the camera, but stay with the hit actor location-wise? I am of course aware of the draw to screen option for widget components, but this isn’t a widget component.
I’ve seen some handle this by putting camera rotation calculations on event tick, but that doesn’t seem like a very efficient option to me.