Lets say I have a soldier (the player) that shoots bullets at enemies.
There is one soldier and a maximum of 15 enemies on screen at all time.
The player shoots at high rate, so about 15-30 player’s bullets are “alive” at the same time.
The enemies shoots at the player from time to time. So there is a max of 5 enemies bullets on screen at once.
My question is where’s the smartest place to put the “on hit” event.
If I put the “on hit” event on the bullets, it will mean that at any given time between 20-35 instances of this function will be present in the memory.
If I place it in the player/enemies BP then it will only be present at about 16 instances.
Is it smart? Is my way of thinking have any logic?
It’s not a stupid question at all. It’s good to be aware when you might be optimizing too early or overcomplicating but this is clearly a system that can impact performance a lot depending on how you implement it.
It depends on the amount of realism / accuracy you need. If you are simulating bullet behavior and need actual bullet to surface hit events then you might need to let the bullet itself cause such an event. This can quickly get out of hand if at one point you do have many bullets on screen.
Let’s take an extreme example. Imagine you shoot a minigun which could realistically shoot 4000 times a minute. You might play audio to make it sound like that. You might spawn X amount of decals for bullet holes. You might check (or decide up front) if you hit anything in the line of fire, but you never do this 4000 times a minute. Many games completely fake all the audio and visual effects to make it appear you are shooting and hitting things, while the actual hit check is as simple as possible.
With optimization in mind, you could:
- Simply always hit when an enemy is in the line of fire and not behind cover, (check every X ms) (Would work with arcade style Overwatch type of game).
- Shoot as many bullets as you want but only perform hit tests every X ms. This is actually common in shooters where you die in 3 hits and to prevent dying immediately only the first one causes damage (Stalker series I believe).
- Decide up front if you hit someone or not, if not, make the bullet FX fly innacurate (Fallout New Vegas.). You don’t even need physical bullets or projectile calculations.
Can be both sides.
- You could make an interface and add it to the player / enemies so you can make a bullet (or other system) tell them they get hit.
- You could use an existing event in response to collision / physical hit on your player and enemies and check if it was caused by a bullet, then respond. This is less flexible because you now depend on the former to happen, which doesn’t fit all optimization methods I discussed earlier.
The point is, if you start to optimize using one of the methods I discussed, you might not use actual hit events in response to a realistic / physical hit at all.
Depending on what your end result (game) should look like, you might not even have to use “physical” bullets. You might be able to get away with moving visual effects like particles or a single texture flashing from the rifle, then don’t do any hit results on that. Your hardware might do pretty well on particle FX for “bullets” but that’s just a thought.
Thank you for your lengthy answer.
" It’s good to be aware when you might be optimizing too early or overcomplicating"
That’s took a hefty bag of my back to read this 
That’s the kind of information I am aiming at. Now I may be struck with a question about ammo or grass moving in the wind but it’s the principle that counts.
The game I am making is quit basic one. A top down Shoot Em Up where you have 3 lifes and the bullets are visible and moves up or down the screen at a set speed. Since I am just a beginner I am not aiming at creating something too complicated at the moment.
I am using Interfaces in order to avoid casting, and putting all the functions inside the BP that have the least assets on the screen.
For example, I have 4 walls that “encapsules” the playing field.
Each asset has a different interface depending what action needs to be taken when it hit the wall.
Projectiles will be destroyed. Enemies will change directions (enemies goes Left or right until they hit a wall).
So, projectile will have an interface called “killOnHitWall” this interface has no functions (!) and it’s sole purpose is: when something hit the wall the wall asks "Does implement interface “killOnHitWall”? if True: destroy the actor that hit me (Other actor).
if False: Does implement interface “ChangeDirectionOnHitWall”? if true: Change X value of Other Actor (changing X will change it’s direction. X=-X if it make sense).
My point is that instead of having the functions live in the Projectiles/Enemies BP they live in Wall BP that has only four instances.
I hope I am making sense. If you think I am complicating things too much, please let me know,
BYW it’s a mobile game.
Alright, you might want to do a test run with 10x the amount of bullets you expect to be there at any time on a phone and see if there is a problem or not. If there is, consider the optimization methods I mentioned.
This is not common. I’d rather expect an interface called “SurfaceInteractionInterface” that implements methods like “WillBounce” “WillDestroy” “WillCauseDamage” “WillPenetrate” on your projectile class. This does however push you into that direction for all projectiles and might limit creativity a bit unless you allow it (laser beam, explosions, splitting projectiles etc.)
Next to consider is where to implement what. A wall is just a wall. It has no functions but to stand there so it usually shouldn’t get any. Each class should deal with its own logic. You could argue that projectiles implement everything projectile related in the projectile class. “Will I bounce of an enemy? Will I bounce of a wall?”. If you do decide to implement that logic on the wall side, what if you require the same logic on a different object? Like bouncing off an enemy?
You could consider making a “SurfaceEffect” class which deals with generic actions like bouncing / damaging actors colliding. It could be an ActorComponent. On your wall you would add the component and pick the bounce effect. on a lava floor you would pick the damage effect. This is flexible for a bunch of uses because you can add it to a wall, enemy or projectile.