Question One script for many objects, or objects having their own scripts?

I'm working on a project and in this game it is very important for the player to be able to see all of their own footprints hand prints etc. Furthermore I want their foot/hand prints to be very abstract and visually appealing. My plan is to instantiate a low-poly foot/hand everywhere the player touches and then have a PBR shader to give it an outlined glowing forcefield appearance, then to also add some minor transform adjustments for a throbbing effect. Lastly to simulate the player losing their awareness over time, these foot/hand prints will start shifting and changing location overtime. Throughout each level these foot/hand prints are really going to add up and there will be a lot of them. My question is for performance purposes, what is better. To have one master script that is constantly finding and adding the prints to it's functions. or to save a script attached to game object in the prefabs so that each of them have their own attached script?

 

Considering that you have used the word "constantly", i suppose that the "master script" is somehow going to be constantly updated. Assuming that it's updated via Update() (which is called every frame), the "master script" is going to be far more taxing on the hardware than something that is assigned to a GameObject and is only called when necessary (though you can get the same "only when necessary" functionality with a "master script" but from what i got from your description, it's quite the opposite). Again, while this is essentially a non-advice, the description that you have provided does not allow me to draw a better conclusion.

A good Unity practice (if common sense and acclaimed Unity YouTubers are anything to go by) regardless of your intent, is to break as much functionality as possible into their own interchangable scripts that you attach to GameObjects, avoiding monolithic code. That way you have a more flexible project, which means that changing things is also going to be much easier in the future. Thing is, you can have a monolithic code that is going to be easier on the hardware than something that was built with a flexible intent just like you can have a flexible code that is going to be performing better than a monolithic one.