So to map these properties to my Unity game objects I can create a behavior with all of these properties, or just create a separate behavior per property. BUT when you use a behavior just an indication, that game object have such a property, without any data or logic inside, it needs no code.
Is it a good approach, or creating many empty scripts for many objects for such a task makes too many performance impact?
Why not make one Property script which then contains those? Seems to be easier to work with as well. If not all things share the same properties you can also use inheritance. Or properties (the C# ones) to help you get values and handle certain cases, if your properties become more complex than bools in the future.
As for your question about whether it will affect performance…
Define “many”. If we are talking about a couple douzen, likely not. If we talk about a couple (hundred to) thousand and upwards it will affect performance, independant of your empty scripts, since Unitys’ default objects are simply not made for that. Then you will have to use something like entities anyways.
While these empty scripts might add some overhead tho, as long as they dont contain Update() or other managed methods, it should mostly be an initialization and data ovehead. However, when in doubt just create an actual test scenario for what you need and compare performance.
So, your object holds a script with no update, no start, no late update no fixed update. Just holds the identifiers which are considered by another script for different behaviours.
I do it often
There is another method however
by using your Objects Name string to contain key characters which when read apply the same meanings as a bool script. I couldn’t comment on which one is performance better. I doubt anyone could notice a difference.
Use interfaces, especially given the names you’re using for these booleans, they’re just crying out to become interfaces.
public interface ICollectible { void OnCollect(); }
public class Coin : MonoBehaviour, ICollectible
{
public void OnCollect() { Inventory.AddCoins(amount); }
}
public class HealthPotion : MonoBehaviour, ICollectible
{
public void OnCollect() { Player.AddHealth(amount); }
}
// etc. etc.
You can fetch interfaces through GetComponent() as if they were components, and then each object’s logic will be nicely self-contained instead of relying on some global interaction script that defines every single possible interaction by comparing name, tag and boolean states – which will quickly become a complete mess.