Ben ça dépend du niveau de rigueur que tu veux mettre dans ton code. Pour le coup c'est juste une question de confort : Si tu dois être amené à revoir entièrement ton système de GUI, tu gagneras du temps si tu as tout séparé que si t'as tout mélangé.

De base ce que je conseille de faire, c'est de toujours travailler en mode Manager/Controller. C'est à dire que tu as un script qui est le manager, par exemple HUDManager, qui est l'UI principale de ton jeu. Ben donc tu fais un script HUDManager qui a en variable tout cela, les sprites, les textes, tous les machins d'affichage. Ce manager est unique, c'est un singleton.

Et ensuite tu fais un HUDController, un pti script que tu peux foutre partout ou t'as besoin de récupérer des infos, c'est lui va chercher l'info nécessaire et qui l'envoie au manager. Tu peux faire plusieurs déclinaisons en faisant de l'héritage (HUDControllerLifebar, HUDControllerItem, etc).

De cette manière la classe MonHeros par exemple ne fait jamais d'appel à la GUI. Et quand y a un event spécial à faire et que ça doit être appelé par le héros, je passe par les event C# :

https://msdn.microsoft.com/en-us/librar … s.71).aspx

Ca me permet de faire des appels sans en avoir rien à foutre de ce qui va se passer derrière, si aucune classe ne s'est inscrit à l'evenement, il ne se passe rien. Si je dois changer toute ma GUI, j'ai juste besoin de changer la méthode que cet évènement va appeler.

C'est ma façon perso de fonctionner, tu peux aussi très bien simplement vérifier que ta GUI existe grâce à un simple "== null" à chaque fois que tu fais appel à ton manager d'UI. A chacun ces petites habitudes, sa façon d'organiser son code et voir jusqu'à ou t'es prêt à aller pour simplifier un truc qui n'arrivera ptet jamais (aka "merde, je dois refaire toute l'UI")

Binouz (26 Nov 2015)