Quels sont les modèles de conception de programmation utiles au développement de jeux? [fermé]

J'ai quelques livres sur les modèles de conception et j'ai lu quelques articles, mais je ne peux pas comprendre intuitivement quels modèles de conception pourraient être utiles au développement de jeux.

Par exemple, j'ai un livre appelé ActionScript 3 avec des modèles de conception qui détaille plusieurs modèles de conception tels que le contrôleur de vue, Singleton, Factory, Command, etc.

En tant que débutant dans ce domaine, je ne sais pas lequel de ces éléments serait utile ou, en fait, si l'un d'entre eux correspond aux modèles de conception que je devrais apprendre et essayer d'utiliser. Peut-être y a-t-il d'autres modèles, plus spécifiques à la programmation de jeux, dont je ne suis même pas au courant?

Si vous avez déjà utilisé un certain modèle de conception dans le développement de jeux, j'aimerais l'entendre. Raisonner sur l'utilisation, des exemples de code ou des ressources en ligne serait également très utile si vous en avez. Je suis actuellement très intéressé par les implémentations d'ActionScript 3 et C ++, mais je pourrais certainement bénéficier de l'expérience et des exemples de tous les langages.

Merci!

Passons maintenant à une réponse moins désinvolte, avec quelques suggestions. Ne les prenez pas comme des recommandations de mise en œuvre, mais plutôt comme des exemples d’utilisation possible.

• Constructeur: configurez une entité basée sur les composants, un composant à la fois, en fonction des données
• Méthode par défaut: créer des NPC ou des widgets d'interface graphique basés sur une chaîne lue dans un fichier
• Prototype: enregistrez un caractère générique 'Elf' avec les propriétés initiales et créez des instances Elf en le clonant.
• Singleton: cet espace est délibérément laissé vide.
• Adaptateur: incorporez une bibliothèque tierce optionnelle en l'enveloppant dans une couche qui ressemble à votre code existant. Très utile avec les DLL.
• Composite: créer un graphe de scène d'objets à restituer ou créer une interface graphique à partir d'un arbre de widgets
• Façade: simplifiez les bibliothèques tierces complexes en fournissant une interface plus simple pour vous faciliter la vie plus tard.
• Flyweight: stocke les aspects partagés d'un PNJ (par exemple, des modèles, des textures, des animations) séparément des aspects individuels (par exemple, la position, la santé) de manière essentiellement transparente
• Proxy: créez sur un client de petites classes représentant des classes plus grandes et plus complexes sur un serveur, puis transférez les demandes via le réseau.
• Chaîne de responsabilité: gérer les entrées en chaîne, par ex. touches globales (par exemple, pour les captures d'écran), puis l'interface graphique (par exemple, au cas où une zone de texte est activée ou un menu affiché), puis le jeu (par exemple, pour déplacer un personnage)
• Commande: encapsule les fonctionnalités du jeu sous forme de commandes pouvant être saisies dans une console, stockées et rejouées, ou même scriptées pour aider à tester le jeu.
• Médiateur: implémente les entités de jeu en tant que petite classe de médiateur opérant sur différents composants (par exemple, lecture à partir du composant d'intégrité afin de transmettre les données au composant d'intelligence artificielle)
• Observer: permet à la représentation restituée d'un personnage d'écouter les événements de la représentation logique, afin de modifier la présentation visuelle si nécessaire sans que la logique de jeu n'ait besoin de connaître le code de rendu.
• Etat: stocke l'IA NPC dans l'un des états, par exemple. Attaquer, errer, fuir. Chacun peut avoir sa propre méthode update () et toutes les autres données dont il a besoin (par exemple, enregistrer le personnage qu’il attaque ou fuit, la zone dans laquelle il se promène, etc.)
• Stratégie: basculez entre différentes heuristiques pour votre recherche A *, en fonction du type de terrain dans lequel vous vous trouvez, ou peut-être même utilisez le même cadre A * pour effectuer à la fois une recherche de trajectoire et une planification plus générique.
• Méthode de modèle: configurez une routine de «combat» générique, avec diverses fonctions de raccordement pour gérer chaque étape, par exemple. décrémentez les munitions, calculez les chances de toucher, résolvez les coups ou les ratés, calculez les dégâts, et chaque type de compétence d'attaque implémentera les méthodes de manière spécifique

Certains motifs ont été omis par manque d'inspiration.

J'ai écrit un livre sur exactement ce sujet: Pattern Programming Programms . Les chapitres qui y figurent pourraient vous être utiles.

Brandon Eich a eu le bon sens de faire remarquer dans Coders at Work que les motifs sont des piratages et des solutions de contournement: [Les motifs] montrent une sorte de défaut dans le langage. Ces modèles ne sont pas gratuits. Il n'y a pas de repas gratuit. Nous devrions donc rechercher une évolution dans le langage qui ajoute les bons éléments.

En tant que programmeurs de jeux plutôt que de concepteurs de compilateurs, nous avons rarement la possibilité de faire évoluer les langages que nous utilisons, mais nous pouvons apprendre à faire évoluer notre propre style pour mieux correspondre à notre langage et à nos exigences. Les motifs en font partie, mais ne pas utiliser de motifs en est un autre, d'autant plus que, comme le dit Brandon, les motifs sont rarement dépourvus de performances notables, de coûts en mémoire ou en agilité de code. MVC n'est tout simplement pas un bon modèle pour beaucoup de choses dans les jeux. Singleton est une solution de contournement pour les règles d'initialisation statiques C ++ boiteux, et vous ne devriez probablement pas les faire de toute façon. Factory simplifie la création d’objets compliqués - peut-être que vos objets devraient être plus simples au début. Les modèles populaires sont des outils à utiliser lorsque nous en avons besoin pour gérer quelque chose de complexe, pas les outils que nous devrions avoir envie d'utiliser pour construire quelque chose de complexe au début.

Un bon code (de jeu) peut utiliser des modèles, ou non. Si cela utilise des modèles, très bien - ils sont un excellent outil de communication pour expliquer la structure de code aux autres programmeurs à un niveau élevé, indépendant du langage. Si vous pensez que le code est meilleur sans utiliser de modèle, ne vous en faites pas, il l'est probablement.

Bien sûr, comme d’autres l’ont dit, tous les modèles sont utiles dans les bonnes circonstances, et une partie de l’apprentissage de leur utilisation consiste à savoir quand les utiliser. Cependant, l'excellent livre intitulé Techniques et algorithmes de base dans la programmation de jeux de Daniel Sanchez-Crespo Dalmau répertorie six modèles de programmation et six modèles d'utilisation particulièrement utiles dans la programmation de jeux.

Programmation:

• Singleton: Je ne déteste pas celui-ci comme beaucoup de gens; il peut être utilisé pour des choses comme le lecteur solo ou le lecteur de clavier.
• Factory: vous permet de créer et de détruire des objets efficacement.
• Stratégie: vous permet de modifier les stratégies d'IA avec élégance.
• Index spatial: permet d'effectuer des requêtes sur des ensembles de données spatiales.
• Composite: Configure un objet utile dans la hiérarchie.
• Poids mouche: Libère la mémoire en généralisant des choses comme des ennemis identiques.

Convivialité:

• Bouclier: protège de l'activation accidentelle d'actions dramatiques.
• Etat: Indices visuels du monde / statut de l'interface utilisateur.
• Annulation automatique du mode: rend le jeu plus intuitif.
• Magnétisme: Allumage automatique et sélection facile des unités.
• Focus: Éliminer les éléments distrayants de l'interface utilisateur.
• Progrès: universellement utile.

Le livre, bien sûr, va plus en détail sur chacun d'eux.

Les systèmes d'entités sont un bon modèle. Ce n'est pas exactement un modèle de conception, car il ne s'agit pas de la programmation orientée objet. Cependant, vous pouvez le mélanger avec la POO.

Quelques bons liens (commencez par le haut pour l'intro):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

Tous. Sauf Singleton. [/légèreté]

Pas vraiment sur les motifs, mais sur les principes de base derrière eux. Dans "Design Patterns: Elements de logiciel orienté objet réutilisable" (1995) , la bande des quatre (Gamma, Erich, Richard Helm, Ralph Johnson, et John Vlissides) recommande que deux principes de conception orientée objet: (1) programme une interface et non à une implémentation et (2) privilégient la composition d'objets par rapport à l'héritage de classe.

Ces 2 principes sont très utiles dans de nombreuses tâches de développement de jeux. Par exemple, de nombreux programmeurs de jeux ont utilisé une hiérarchie de classes profonde pour représenter les entités de jeu. Il existe une autre approche basée sur la composition : les objets de jeu basés sur des composants. Article sur cette approche. Encore plus de liens . C'est un exemple de motif de décorateur .

Le modèle de modèle curieusement récurrent peut s'avérer très utile pour éviter les méthodes virtuelles et les inconvénients en termes de performances pouvant découler des appels de fonctions virtuelles.

Cela peut être le modèle approprié lorsque vous n'avez pas réellement besoin d'un conteneur du type classe avec l'interface que vous recherchez, mais que vous aimeriez que les comportements et les interfaces portent le même nom.

Par exemple, vous pouvez l'utiliser lors de la compilation de classes pour plusieurs plates-formes ou moteurs (dx ou opengl) où la variance de type est connue au moment de la compilation.

Un modèle de conception que j'ai développé au cours de nombreuses années et qui m'a été spectaculairement utile est ce que je nomme des "ensembles de définitions négociés"; comment le résumer en termes GOF semble être controversé, mais la question que j'ai écrite à ce sujet sur StackOverflow donne quelques détails à ce sujet.

Le concept de base est que certaines propriétés d’un modèle, comme l’espèce d’une créature, sont configurées de manière à ce que chaque valeur possible de la propriété ait un objet de définition correspondant - un seul objet partagé par valeur - qui spécifie son comportement. et ceux-ci sont accessibles via un courtier central (qui, pour GOF, peut être un registre, une usine ou les deux). Dans mon utilisation, ils sont également généralement accessibles via des clés scalaires, afin de faciliter la liaison faible à des fins de morphisme d'exécution.