Améliorez votre code avec des modèles de programmation de jeu

Si vous avez de l'expérience avec les langages de programmation orientés objet, vous avez probablement entendu parler des principes SOLID, MVP, singleton, factory et des modèles d'observateur. Notre nouvel e-book met en évidence les meilleures pratiques pour utiliser ces principes et modèles pour créer une architecture de code de jeu évolutive dans votre projet Unity .

Pour chaque problème de conception de logiciel que vous rencontrez, des milliers de développeurs ont déjà été confrontés à cette situation. Même si vous ne pouvez pas toujours leur demander directement conseil, vous pouvez apprendre de leurs décisions grâce à des modèles de conception.

En implémentant des modèles de conception de programmation de jeu courants dans votre projet Unity , vous pouvez créer et maintenir efficacement une base de code propre, organisée et lisible, ce qui, à son tour, crée une base solide pour faire évoluer votre jeu, votre équipe de développement et votre entreprise.

Dans notre communauté, nous entendons souvent qu’il peut être intimidant d’apprendre à intégrer des modèles et des principes de conception, tels que SOLID et KISS, dans le développement quotidien. C'est pourquoi notre livre électronique gratuit, Améliorez votre code avec des modèles de programmation de jeux, explique des modèles de conception bien connus et partage des exemples pratiques pour les utiliser dans votre projet Unity .

Rédigé par des experts internes et externes Unity , le livre électronique est une ressource qui peut vous aider à élargir votre boîte à outils de développeur et à accélérer le succès de votre projet. Lisez la suite pour avoir un aperçu de ce que contient le guide.

Les modèles de conception sont des solutions générales aux problèmes courants rencontrés en ingénierie logicielle. Il ne s'agit pas de solutions complètes que vous pouvez copier et coller dans votre code, mais d'outils supplémentaires qui peuvent vous aider à créer des applications plus grandes et évolutives lorsqu'elles sont utilisées correctement.

En intégrant des modèles de manière cohérente dans votre projet, vous pouvez améliorer la lisibilité du code et rendre votre base de code plus propre. Les modèles de conception réduisent non seulement le refactoring et le temps consacré aux tests, mais ils accélèrent également les processus d'intégration et de développement.

Cependant, chaque modèle de conception comporte des compromis, qu'il s'agisse de structures supplémentaires à maintenir ou de configurations supplémentaires au début. Vous devrez effectuer une évaluation coûts-avantages pour déterminer si l’avantage justifie le travail supplémentaire requis. Bien entendu, cette évaluation variera en fonction de votre projet.

KISS signifie « Keep it simple, stupid » (rester simple, stupide). L’objectif de ce principe est d’éviter une complexité inutile dans un système, car la simplicité contribue à générer des niveaux plus élevés d’acceptation et d’interaction des utilisateurs.

Notez que « simple » n’est pas synonyme de « facile ». Rendre quelque chose simple signifie le rendre ciblé. Bien que vous puissiez créer la même fonctionnalité sans les modèles (et souvent plus rapidement), quelque chose de rapide et facile ne donne pas nécessairement quelque chose de simple.

Si vous n'êtes pas sûr qu'un modèle s'applique à votre problème particulier, vous pouvez attendre qu'il vous semble plus naturel. N'utilisez pas un modèle parce qu'il est nouveau ou inhabituel pour vous. Utilisez-le quand vous en avez besoin.

C’est dans cet esprit que le livre électronique a été créé. Gardez le guide à portée de main comme source d’inspiration pour de nouvelles façons d’organiser votre code – et non comme un ensemble de règles strictes à suivre.

Passons maintenant à certains des principes clés de la conception de logiciels.

SOLID est un acronyme mnémotechnique désignant cinq principes fondamentaux de la conception de logiciels. Vous pouvez les considérer comme cinq règles de base à garder à l’esprit lors du codage, pour garantir que les conceptions orientées objet restent flexibles et maintenables.

Les principes SOLID ont été introduits pour la première fois par Robert C. Martin dans l'article Design Principles and Design Patterns. Publiés pour la première fois en 2000, les principes décrits sont toujours applicables aujourd'hui et aux scripts C# dans Unity:

• La responsabilité unique stipule que chaque module, classe ou fonction est responsable d'une chose et encapsule uniquement cette partie de la logique.
• Les états ouverts-fermés indiquent que les classes doivent être ouvertes à l'extension mais fermées à la modification ; cela signifie structurer vos classes pour créer un nouveau comportement sans modifier le code d'origine.
• La substitution de Liskov stipule que les classes dérivées doivent être substituables à leur classe de base lors de l'utilisation de l'héritage.
• La ségrégation des interfaces stipule qu'aucun client ne doit être obligé de dépendre de méthodes qu'il n'utilise pas. Les clients ne doivent mettre en œuvre que ce dont ils ont besoin.
• L'inversion de dépendance stipule que les modules de haut niveau ne doivent rien importer directement à partir des modules de bas niveau. Les deux devraient dépendre d’abstractions.

Dans le livre électronique, nous fournissons des exemples illustrés de chaque principe avec des explications claires pour leur utilisation dans Unity. Dans certains cas, l’adhésion à SOLID peut entraîner un travail supplémentaire en amont. Vous devrez peut-être refactoriser certaines de vos fonctionnalités en abstractions ou en interfaces, mais cela vous rapportera souvent des économies à long terme.

Ces principes dominent la conception de logiciels depuis près de deux décennies au niveau de l'entreprise, car ils sont parfaitement adaptés aux grandes applications évolutives. Si vous n’êtes pas sûr de la manière de les utiliser, reportez-vous au principe KISS. Restez simple et n'essayez pas d'imposer les principes dans vos scripts juste pour le plaisir de le faire. Laissez-les s’installer naturellement par nécessité.

Si vous souhaitez en savoir plus, consultez la présentation SOLID de Unite Austin 2017 par Dan Sagmiller de Productive Edge.

Quelle est la différence entre un principe de conception et un modèle de conception ? Une façon de répondre à cette question est de considérer SOLID comme un cadre ou une approche fondamentale pour l’écriture de code orienté objet. Bien que les modèles de conception soient des solutions ou des outils que vous pouvez mettre en œuvre pour éviter les problèmes logiciels quotidiens, n'oubliez pas qu'il ne s'agit pas de recettes prêtes à l'emploi, ni d'algorithmes comportant des étapes spécifiques pour obtenir des résultats spécifiques.

Un modèle de conception peut être considéré comme un plan. Il s'agit d'un plan général qui vous laisse le soin de réaliser la construction proprement dite. Par exemple, deux programmes peuvent suivre le même modèle mais impliquer un code très différent.

Lorsque les développeurs rencontrent le même problème dans la nature, beaucoup d’entre eux proposeront inévitablement des solutions similaires. Une fois qu’une solution est répétée suffisamment de fois, quelqu’un peut « découvrir » un modèle et lui donner formellement un nom.

De nombreux modèles de conception de logiciels actuels proviennent du travail fondateur, Modèles de conception : Éléments d'un logiciel orienté objet réutilisable par Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides. Ce livre décrypte 23 de ces modèles identifiés dans une variété d’applications quotidiennes.

Les auteurs originaux sont souvent appelés le « Gang of Four » (GoF), et vous entendrez également les modèles originaux surnommés les modèles GoF. Bien que les exemples cités soient principalement en C++ (et Smalltalk), vous pouvez appliquer leurs idées à n'importe quel langage orienté objet, tel que C#.

Depuis que Gang of Four a publié Design Patterns à l'origine en 1994, les développeurs ont depuis établi des dizaines d'autres modèles orientés objet dans divers domaines, y compris le développement de jeux.

Bien que vous puissiez travailler en tant que programmeur de jeux sans étudier les modèles de conception, leur apprentissage vous aidera à devenir un meilleur développeur. Après tout, les modèles de conception sont étiquetés comme tels parce qu’ils constituent des solutions courantes à des problèmes bien connus.

Les ingénieurs logiciels les redécouvrent constamment au cours du développement normal. Vous avez peut-être déjà mis en œuvre certains de ces modèles sans le vouloir.

Entraînez-vous à les chercher. Cela peut vous aider à :

• Apprendre la programmation orientée objet: Les modèles de conception ne sont pas des secrets enfouis dans un article ésotérique de StackOverflow. Il s’agit de moyens courants pour surmonter les obstacles quotidiens au développement. Ils peuvent vous informer du nombre d'autres développeurs qui ont abordé le même problème. N'oubliez pas que même si vous n'utilisez pas de modèles, quelqu'un d'autre le fait.
• Parlez à d'autres développeurs: Les modèles peuvent servir de raccourci lorsque l’on essaie de communiquer en équipe. Mentionnez le « modèle de commande » ou le « pool d’objets » et les développeurs Unity expérimentés sauront ce que vous essayez d’implémenter.
• Explorez de nouveaux frameworks : lorsque vous importez un package intégré ou quelque chose depuis l'Asset Store, vous tomberez inévitablement sur un ou plusieurs modèles décrits ici. Reconnaître les modèles de conception vous aidera à comprendre le fonctionnement d’un nouveau framework, ainsi que le processus de réflexion impliqué dans sa création.

Comme indiqué précédemment, tous les modèles de conception ne s’appliquent pas à toutes les applications de jeu. Ne les cherchez pas avec le marteau de Maslow; sinon, vous risquez de ne trouver que des clous.

Comme tout autre outil, l’utilité d’un modèle de conception dépend du contexte. Chacun d’entre eux offre un avantage dans certaines situations et comporte également son lot d’inconvénients. Chaque décision dans le développement de logiciels comporte des compromis.

Générez-vous beaucoup de GameObjects à la volée ? Cela a-t-il un impact sur vos performances ? La restructuration de votre code peut-elle résoudre ce problème ? Soyez conscient de ces modèles de conception et, lorsque le moment est venu, sortez-les de votre sac d’astuces de développement de jeu pour résoudre le problème en question.

En plus des modèles de conception de Gang of Four, Game Programming Patterns de Robert Nystrom est une autre ressource remarquable, actuellement disponible gratuitement sous forme d'édition Web. L'auteur détaille une variété de modèles de logiciels de manière pragmatique.

Dans notre nouvel e-book, vous pouvez vous plonger dans les sections qui expliquent les modèles de conception courants, tels que les modèles d'usine, de pool d'objets, de singleton, de commande, d'état et d'observateur, ainsi que le Model View Presenter (MVP), entre autres. Chaque section explique le modèle ainsi que ses avantages et ses inconvénients, et fournit un exemple de la manière de l'implémenter dans Unity afin que vous puissiez optimiser son utilisation dans votre projet.

Unity implémente déjà plusieurs modèles de développement de jeu établis, vous évitant ainsi la peine de les écrire vous-même. Il s’agit notamment de :

• Boucle de jeu: Au cœur de tous les jeux se trouve une boucle infinie qui doit fonctionner indépendamment de la vitesse d’horloge, car le matériel qui alimente une application de jeu peut varier considérablement. Pour tenir compte des différentes vitesses des ordinateurs, les développeurs de jeux doivent souvent utiliser un pas de temps fixe (avec un nombre d'images par seconde défini) et un pas de temps variable où le moteur mesure le temps écoulé depuis l'image précédente.
  
  Unity s'en charge, vous n'avez donc pas besoin de l'implémenter vous-même. Vous n'avez besoin de gérer le gameplay qu'à l'aide des méthodes MonoBehaviour telles que Update, LateUpdate et FixedUpdate.
  
• Mise à jour: Dans votre application de jeu, vous mettrez souvent à jour le comportement de chaque objet une image à la fois. Bien que vous puissiez recréer cela manuellement dans Unity, la classe MonoBehaviour le fait automatiquement. Utilisez les méthodes Update, LateUpdate ou FixedUpdate appropriées pour modifier vos GameObjects et composants à un tic-tac de l'horloge de jeu.

• Prototype: Souvent, vous devez copier des objets sans affecter l'original. Ce modèle de création résout le problème de la duplication et du clonage d'un objet pour créer d'autres objets similaires à lui-même. De cette façon, vous évitez de définir une classe distincte pour générer chaque type d’objet dans votre jeu.
  
  Le système Prefab d'Unity implémente une forme de prototypage pour GameObjects. Cela vous permet de dupliquer un objet modèle complet avec ses composants. Remplacez des propriétés spécifiques pour créer des variantes préfabriquées ou imbriquer des préfabriqués dans d'autres préfabriqués pour créer des hiérarchies. Utilisez un mode d'édition de préfabriqué spécial pour modifier les préfabriqués de manière isolée ou en contexte.
  
• Composant : La plupart des personnes travaillant dans Unity connaissent ce modèle. Au lieu de créer de grandes classes avec plusieurs responsabilités, créez des composants plus petits qui font chacun une chose.
  
  Si vous utilisez la composition pour sélectionner des composants, vous pouvez les combiner pour obtenir un comportement complexe. Ajoutez des composants Rigidbody et Collider pour la physique, ou un MeshFilter et un MeshRenderer pour la géométrie 3D . Chaque GameObject est aussi riche et unique que sa collection de composants.

Le livre électronique ainsi qu'un exemple de projet sur l'utilisation des modèles de conception sont désormais disponibles en téléchargement gratuit. Passez en revue les exemples et décidez quel modèle de conception convient le mieux à votre projet. Au fur et à mesure que vous gagnerez en expérience avec eux, vous reconnaîtrez comment et quand ils peuvent améliorer votre processus de développement. Comme toujours, nous vous encourageons à visiter le fil de discussion du forum et à nous faire savoir ce que vous pensez du livre électronique et de l'échantillon.