Open ended question:

In a game where you're dealing with space ships and laser cannons, what would you attach the audio to? The gun, the ammo projectile prefab, the target collider, or all 3? 

I'd connect each audio source to the object that should be making the sound. Shooting could be on the gun or the ship, but explosions should be on the projectile and/or the enemy.

The reason is that if you implement any kind of stereo or surround sound, you'll easily be able to pull the x,y data from the audio object to fade left/right, etc.

Ah! Thanks! Obvious next question...

9 hours ago, LoneStranger said:

but explosions should be on the projectile and/or the enemy.

Does it matter which one? Either the explosion event trigger is on the ammo, and it triggers the sound when ammo collides with the target. (That way the ammo decides if it hits)

-or-

The explosion even trigger is on the target, (thus the target decides if has BEEN hit.)

Its an implementation question obviously...how do you best prioritize factors when deciding? For example, does ease of implementation take priority over resource efficiency?

Are there general rules to go by? Or is this a situation where its so open ended, its almost impossible to give meaningful advice on without seeing the GDD and full context?

Thanks.

In short, it's up to your design and what you plan on doing later with weapon/enemy options.

I think projectiles should check for collision and tell the object they collide with that they have been hit. That way, the object can decide what to do. You can have the projectile call a method on the target and have the target return a value that suggests to the projectile what it should do (blow up, disappear, pass on through, etc). 

For example, if I hit a peon, the projectile will tell the peon "I just hit you." The peon will tell the projectile to blow up and initiate it's own blow up sound/image. If it's a stronger enemy, then it might tell the projectile to blow up but then only take hit points away from itself. If it's a boss with a special "absorption shield" then perhaps it tells the projectile to just disappear without an explosion and then it displays a "getting more powerful" animation/sound.

As far as resources, they are something you need to be aware of, but don't let efficiency stunt your programming. Your first job is to get it done. If it's slow, then go back to rethink and refactor it. You never know; you might find that your bottlenecks are elsewhere. If you do go back and refactor it, then you've learned something (at the very least, you probably learned what not to do). The next time you have to implement something similar you can take a little time making it more efficient from the beginning, using what you learned.

(Something like a fast-paced bullet-hell top-down shooter with dozens of projectiles and dozens of enemies would need object pooling to minimize the overhead of instantiating/destroying so many objects per second, but something with only a couple bullets alive at any one time wouldn't benefit greatly from that. But like I said, this is something you could learn along the way and not something I'd expect a new coder to do from scratch. Don't get bogged down with complexity before the complexity is needed. I've killed momentum on many projects doing that.)