Cherchez Unity

3 méthodes simples pour bâtir votre jeu avec les objets programmables

Last updated: December 2018

Ce que vous trouverez sur cette page : des instructions prêtes à l'emploi pour vous aider à conserver un code qui soit facile à gérer, modifier, et déboguer en employant les objets programmables.

C'est Ryan Hipple, ingénieur en chef chez Schell Games, qui nous a donné ces astuces. Il a une longue expérience de l'utilisation de objets programmables au sein de l'architecture des jeux. Vous pouvez regarder sa conférence Unite sur les objets programmables ici ; nous vous recommandons également la session de l'ingénieur Unity Richard Fine pour vous familiariser avec les objets programmables. Merci Ryan !

En bref : que sont les objets programmables ?

ScriptableObject est une classe Unity sérialisable qui vous permet de stocker une grande quantité de données partagées indépendamment des instances de scripts. L'utilisation des objets programmables simplifie la gestion des modifications et des corrections.Vous pouvez créer dans un niveau de communication flexible entre les différents systèmes de votre jeu pour que la modification et l'adaptation soit encore plus simple, comme la réutilisation des composants.

Trois piliers de la conception de jeux intelligente

Garder des contenus modulables...

  • Évitez de créer des systèmes qui dépendent directement les uns des autres. Par exemple, un système d'inventaire doit pouvoir communiquer avec d'autres systèmes dans votre jeu, mais sans référence profonde entre eux, car cela compliquerait le ré assemblage de systèmes avec des configurations et des relations différentes.
  • Créez des scènes à partir d'une ardoise vierge : évitez les données transitoires entre vos scènes. Chaque fois que vous commencez une scène, vous devez faire table rase. Vous obtiendrez ainsi des scènes au comportement unique non présent dans d'autres scènes.
  • Paramétrez vos prefabs de manière à ce qu'ils fonctionnent indépendamment. Dans la mesure du possible, chaque prefab que vous utilisez dans une scène doit contenir sa propre fonctionnalité. Cela optimise significativement le contrôle de source pour les grandes équipes,avec des listes de prefabs pour scènes et une fonctionnalité individuelle renfermée dans le prefab. EN travaillant au niveau du prefab, le nombre de conflits potentiels dans la scène est réduit.
  • Chacun de vos composants doit être axé sur la résolution d'un problème. Vous pourrez ainsi assembler plus facilement des composants pour créer un nouvel élément.

...Modifiables

  • Vous devez faire en sorte que la majeure partie de votre jeu soit orientée données : lorsque vous avec conçu les systèmes de votre jeu comme des machines qui traitent les données comme si elle étaient des instructions, vous pourrez apporter des modifications au jeu pus efficacement, même pendant son exécution.
  • Si vos systèmes sont majoritairement paramétrés comme des systèmes modulaires et basés sur les composants, ils seront plus faciles à modifier, y compris pour vos artistes et vos concepteurs. Si les concepteurs sont en mesure d'assembler des éléments dans le jeu sans avoir recours à une fonctionnalité explicite, grâce à l'implémentation de petits éléments ayant chacun une action unique, alors ils pourront combiner ces composants de différentes manières pour trouver un nouveau gameplay/de nouvelles mécaniques. Ryan explique que certaines des meilleures fonctionnalités qu'a imaginé son équipe pour le jeu viennent de ce processus, qu'il appelle « design émergent ».
  • Il est essentiel que votre équipe puisse modifier le jeu lorsque celui-ci est exécuté. Plus vous modifiez le jeu pendant son exécution, plus il sera facile de trouver un équilibre et des valeurs et, si vous pouvez agir sur l'état d'exécution comme le font les objets programmables alors vous avez toutes les cartes en main.

... et faciles à corriger

Il s'agit plus d'un sous-pilier que les deux éléments précédents. Plus votre jeu est modulaire, plus il est simple de tester chacun de ses éléments. Plus il est éditable -plus il a de fonctionnalités avec leur propre affichage via l'inspecteur- plus il est facile à corriger. Assurez-vous que vous pouvez consulter l'état de débogage dans l'inspecteur et ne considérez jamais qu'une fonctionnalité est terminée avant d'avoir prévu comment la corriger.

Les trois choses les plus géniales à créer avec les objets programmables selon Ryan

Variables

L'une des choses les plus simples à créer avec un objet programmable est une variable indépendante basée sur une ressource. Voici l'exemple d'un élément FloatVariable, mais cela s'applqiue à tous les autres types sérialisables.

Variable flottante pour les objets programmables Unity

Chaque membre de votre équipe, quel que soit son niveau technique, peut définir une nouvelle variable de jeu en créant une nouvelle ressource FloatVariable. Les éléments MonoBehaviour ou ScriptableObject peuvent utiliser une ressource publique FloatVariable au lieu d'un float publicpour référencer cette nouvelle valeur partagée.

Il y a mieux ! Si un MonoBehaviour change la valeur d'une variable flottante, les autres MonoBehaviour peuvent voir ce changement. Cela crée une sorte de couche de communication entre des systèmes qui n'ont pas besoin de références les uns par rapport aux autres.

L'illustration parfaite est le HP d'un joueur. Dans un jeu avec un joueur local unique, le HP du joueur peut être un élément FloatVariable nommé PlayerHP. Quand le joueur subit des dommages, PlayerHP diminue, et quand il guérit, PlayerHP augmente.

Maintenant, imaginez un prefab de barre de santé dans la scène. La barre de santé contrôle la variable PlayerHP pour actualiser son affichage. Sans aucun changement dans le code, elle identifie facilement les différences, par exemple une variable PlayerMP. La barre de santé ne sait rien de joueur dans a scène, elle lit simplement la variable que le joueur écrit.

Objet programmable Unity gérant la mort du joueur

Une fois que nous avons mis les choses en place ainsi, il est facile d'ajouter des choses qui surveillent les points de vie du joueur. La musique peut changer à mesure que sa vie baisse, les ennemis peuvent changer leurs attaques quand ils savent que le joueur est affaibli, les effets à l'écran peuvent souligner le danger que présente la prochaine attaque. La clé, c'est que la programmation joueur n'envoie pas de message à ces systèmes, et qu'ils n'ont pas besoin de savoir l'état de l'objet joueur dans le jeu. Vous pouvez également aller dans l'inspecteur pendant que le jeu tourne et changer le nombre de points de vie pour tester ces fonctions.

Pour éditer la valeur d'un élément FloatVariable, mieux vaut copier vos données dans une valeur d'exécution afin de ne pas modifier la valeur enregistrée sur le disque pour l'objet programmable. Si vous procédez ainsi, MonoBehaviours pourra accéder à RuntimeValue pour empêcher la modification de la ressource InitialValue enregistrée sur le disque.

Variable flottante pour les objets programmables Unity

Évènements

L'une de mes fonctionnalités préférées possible grâce aux objets programmables est le système d'évènements. Les architectures d'évènements vous aident à modulariser votre code en envoyant des messages entre les systèmes qui ne communiquent pas directement entre eux. Ils permettent aux éléments de répondre à un changement d'état sans contrôler l'état en permanence dans une boucle d'actualisation.

Le système d'évènement comprend deux parties : un ScriptableObject GameEvent et un MonoBehaviour GameEventListener. Les concepteurs peuvent créer le nombre d'éléments GameEvents de leur choix dans le projet pour représenter els messages importants qui peuvent être envoyés. Un élément GameEventListener attend l'activation d'un GameEvent et répond en invoquant un UnityEvent (qui n'est pas un évènement réel mais une fonction d'appel sérialisée).

Objet programmable Unity écouteur d'évènement de jeu

Objet programmable Unity écouteur d'évènement de jeu

Objet programmable Unity écouteur d'évènement de jeu

La gestion de la mort du joueur est un exemple. Elle peut modifier l'exécution du tout au tout, mais il peut être complexe de définir où programmer la logique. Le script de joueur doit-il déclencher le jeu via l'IU, via un changement sonore ? Les ennemis doivent-ils vérifier chaque frame si le jouer est toujours vivant ? Un système d'évènement permet d'éviter de telles dépendances problématiques.

Quand le joueur meurt, le script joueur appelle Raise pour l'évènement OnPlayerDied. Le script joueur n'a pas besoin de savoir quels systèmes sont liés, puisqu'il s'agit simplement d'une diffusion. L'IU Game Over suit l'évènement OnPlayerDied et s'active, un script de caméra peut suivre également et afficher du noir, et un système musical peut répondre avec un changement sonore. Chaque ennemi peut également suivre OnPlayerDied, déclenchant une animation de raillerie ou un changement d'état pour revenir à un comportement moins actif.

Ces processus permettent d'ajouter facilement de nouvelles réponses à la mort du joueur. En plus, il est plus simple de tester la réponse à la mort du joueur en appelant Raise pour l'évènement via un code de test ou un bouton dans l'inspecteur.

Objet programmable Unity gérant la mort du joueur

Le système d'évènement que j'ai conçu avec Schell Games est devenu bien plus complexe et comprend des fonctionnalités autorisant le transfert de données et les types à génération automatique. Je ne peux pas expliquer tous les détails ici, mais cet exemple était, en gros, le point de départ du système que nous utilisons actuellement.

Systèmes

Les objets programmables ne se limitent pas aux données. Prenez n'importe lequel des systèmes que vous implantez dans un élément MonoBehaviour et voyez si vous pouvez déplacer l'implémentation dans une ressource ScriptableObject. Au lieu d'avoir un InventoryManager sur un MonoBehaviour DontDestroyOnLoad, essayez de le mettre dans un ScriptableObject.

Étant donné qu'il n'est pas lié à la scène, il n'a pas de Transform et ne dispose pas des fonctions Update, mais il conservera son état entre les chargements de scènes sans initialisation spéciale. Au lieu dun système unique, utilisez une référence publique à l'objet de votre système d'inventaire lorsque vous avez un script qui a besoin d'accéder à votre inventaire. Il est ainsi plus facile de le remplacer par un inventaire de test ou de tutoriel que si vous utilisiez un système unique.

Imaginez un script joueur lié au système d'inventaire. Quand le joueur avance, le script interroge l'inventaire pour connaître les objets possédés et faire suivre les équipements. L'IU d'équipe peut également être liée à l'inventaire et créer une boucle tenant compte des objets pour savoir quels éléments appeler.

Plus de ressources

Dites-nous si vous avez aimé ce contenu !

Oui, continuez comme ça Ça pourrait être mieux

Unity Buffbot vous simplifie la tâche

Inscrivez-vous pour recevoir chaque semaine des conseils techniques et créatifs de la part d'experts Unity.

Subscribe
Compris

Ce site utilise des cookies dans le but de vous offrir la meilleure expérience possible. Consultez la page de politique des cookies pour en savoir plus.