Salut les gens !
C'est parti pour la partie 2 de cette suite de tutoriaux.
Dans cette partie (qui sera courte) on va apprendre un truc tout con qui va peut-être changer votre vie puis on verra comment et pourquoi lancer une fonction d'un objet directement depuis l'éditeur, alors que le jeu ne tourne pas. Ça ira assez vite, il s'agit littéralement de deux lignes de code^^.
Organiser ses scripts
La première commande c'est @script AddComponentMenu ("Chemin du script")
Ça fait quoi ?
Ça vous permet d'ajouter un script à un objet sans forcément passer par le menu "Component/Scripts" qui peut vite devenir bordélique quand vous avez pleins de scripts différents.
Comment ça fonctionne ?
Il suffit de la placer dans votre script (avant les déclarations de fonctions par exemple). Concernant le chemin, il s'agit du chemin que vous suivrez pour atteindre le script, par exemple: "Scripts Triés/Vehicules"
A notez que vous devez aussi ajouter un nom, le nom de l'onglet final. Autrement dit, le nom sur lequel vous cliquerez pour ajouter votre script à l'objet. Le plus clair, pour moi, reste de ré-écrire le nom de votre script, tout simplement. Ça donnera donc, par exemple: @script AddComponentMenu ("Scripts Triés/PNJ/Dialogue Base")
Ça peux paraître bête mais l'air de rien, sur un script que vous ajoutez souvent à des objets, le fait de gagner 3-4 secondes parce qu'on ne doit pas chercher son script dans une grosse liste finit par vous faire gagner pas mal de temps sur la durée.
C'est aussi un bon moyen de ne pas oublier d'ajouter tel ou tel script quand vous créez un nouvel objet complexe.
A propos des commandes commençants par un @ je vous conseille vraiment de vous y intéresser, on y trouve quelques petites fonctions qui peuvent être très utiles. Comme @HideInInspector par exemple qui permet de ne pas afficher une variable publique dans l'inspector.
Heu, bah t'as qu'à mettre ta variable en private, espèce de gros noob.
Parfois un script externe doit accéder à cette variable et elle doit donc être publique, ce qui "pollue" votre inspector si vous n'ajoutez pas cette petite ligne au dessus du nom de la variable..
Jetez aussi un oeil à @ExecuteInEditMode.
Lancer une fonction d'un script hors runtime
On va maintenant s’intéresser à la ligne de code @ContextMenu("Nom")
Ça fait quoi ?
Cette commande permet de lancer une fonction depuis l'inspector.
Un exemple bien concret puisque je l'utilise dans mes jeux, c'est celui d'une porte. La porte peut être ouverte ou fermée. Concrètement ça va influencer son skin, diverses variables: "open", "locked" (parce qu'une porte ouverte ne sera pas fermée à clé en principe) et dans le cas d'un jeu en 2D, sa collisionBox.
Imaginons donc que je veuille placer en jeu une porte déjà ouverte. Si je le fais à la main je vais devoir modifier son skin, les variables (ce qui m'oblige à les afficher dans l'inspector alors que je pourrais l'éviter, voir les mettre en private) et la collisionBox. Lourd, pas vrai ?
Comment ça fonctionne alors ?
J'ai déjà codé les fonctions Open() et Close() que le jeu utilise durant le runtime quand le joueur "actionne" une porte. Pourquoi ne pas en tirer parti dans l'inspector pour m'éviter de perdre du temps. Pour ça j'ajoute simplement la ligne de code susmentionnée juste avant la déclaration de ma fonction.
Bien entendu vous n'êtes pas obligé de donner à votre ContextMenu le même nom qu'à votre fonction.
Et voilà le résultat:
Comme vous le voyez avec le "SetAsChangeZone", ça peut avoir pas mal d'usages. Par exemple vous pourriez ajouter les fonctions "SetFactionEnemi", "SetFactionNPC", "SetFactionEvilCreaturesOfTheDarkestNightSWAG" à votre classe de PNJ.
Conclusion
Voilà, ce sont toutes des petites astuces qui ne mangent pas de pain et qui peuvent vraiment vous faire gagner un temps précieux à force de vous faire économiser 2 secondes par-ci par-là.
Dans la prochaine partie, on verra comment vraiment modifier Unity en lui ajoutant des fenêtres et comment interagir avec votre scène depuis des scripts Editor.
