Pour poser le contexte, je faits des essais divers autour d'un projet basique de TPS tel qu'on pouvait en voir tout début 2000.
je me suis attelé à la mise en place du système régissant les interactions entre le joueur et le groupe d'objets utilisables. L'idée c'est que quand on trouve un de ces objets, on peut choisir quoi en faire/ne rien faire via un menu dédié. Donc je m'approche de l'objet, le menu surgit, je choisi quoi faire et... et c'est là que je me gratte la tête pour dire "vas y objet déroule ton code":
> Ma première idée était de positionner une variable publique dans le script du joueur selon l'action choisie à travers le menu surgissant et d'autre part, dans le script de l'objet, lire cette variable et agir selon la valeur (en gros 0=rien faire, 1=faire action1; 2=faire action alternative). Mais j'ai revu ma copie de peur de vite finir en mode spaghetti code avec des variables de partout.
> Ensuite je suis parti sur des unityevents pour transmettre les ordres. C'est plus propre, plus limpide, on regarde l'inspecteur et on sait déjà qui affecte quoi. Mais voilà, c'était trop beau. Les unityevents ne permettent pas d'aller chercher une info. Juste de déclarer à qui veut l'entendre... un événement. En gros ça fait ce que c'est sensé faire et ça fonctionne pour 90% des cas (ici, ouvrir/fermer une porte, faire péter du C4, switcher un appareil, en gros tout ce qui marche sans feedback entre objet et joueur).
> Finalement je me suis dit que je pourrait envoyer les infos nécessaire si besoin à l'objet via unityevent en même temps que je demande à l'objet d'agir, en le passant en paramètre. Soit techniquement AVANT que l'objet n'en ai besoin et ça me paraît pas super logique et ça m'embrouille un peu.
Donc retour case départ avec la lecture d'une variable publique...
PS: en plus j'arrive pas à me contenter d'une solution que je considère bancale même si c'est temporaire en attendant de trouver mieux du coup j'avance pas ^^