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

129

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!

— jcurrie33
source

"Peut-être qu'il y a d'autres modèles de conception, plus spécifiques à la programmation de jeux, dont je ne suis même pas conscient?" - non, ces modèles sont génériques et s'appliquent davantage à l'extension des capacités du langage que vous utilisez. Ils n'ont rien à voir avec l'objet de votre demande.

— Kylotan

3

@Kylotan Il me semble, de mon point de vue limité, que chaque modèle de conception étant censé résoudre efficacement un problème particulier, certains modèles de conception seraient, par nature, plus utiles que d’autres, compte tenu de l’ensemble des problèmes, en l’occurrence, ces problèmes uniques au développement de jeux. Certes, il existe certaines lignes directrices ou, selon votre expérience, des modèles de conception particuliers que vous vous retrouvez à utiliser plus fréquemment que d'autres.

— jcurrie33

Avant que quelqu'un ne découvre 1000 modèles différents, lisez ceci et cela

— BlueRaja - Danny Pflughoeft Le

@ BlueRaja-DannyPflughoeft Secon lien est invalide. Pouvez-vous le renvoyer

— Emadpres

163

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.

— Kylotan
source

Une discussion très enrichissante

— Andrew Wang

+1 pour le modèle de stratégie. Je l'ai utilisé dans le but précis indiqué ci-dessus (en branchant différentes heuristiques A *).

— Mike Strobel le

1

merci pour cette réponse, ceux-ci sonnent plus comme des motifs que le "singleton" habituel que j'entends partout ...

— jokoon

Grande liste d'exemples. Malgré l’abus chronique du modèle de singleton (état global déguisé), il existe des utilisations légitimes: il s’agit d’une ressource dont vous ne possédez (ou désirez) qu’une. Cela peut être quelque chose comme du matériel d'encapsulation (clavier / souris, par exemple) ou une bibliothèque non réentrante (cela arrive, et toutes les langues ne disposent pas de mots-clés de synchronisation magiques).

— Charstar

11

Je n'utiliserais toujours pas les singletons pour les ressources matérielles - les éléments que vous pensez ne jamais en avoir qu'un ont tendance à se multiplier plus tard, tout comme les cartes vidéo et les moniteurs l'ont fait au fil des ans. De même, sous certaines API, vous devez lire 2 manettes de jeu pour comprendre 1 gamepad. Je dirais donc que si vous n'avez besoin que de l'un de ces éléments, instanciez-en un seul, n'appliquez pas de restrictions arbitraires qui ne sont probablement pas nécessaires.

— Kylotan

59

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

— généreux
source

2

+1 J'espérais que quelqu'un avait un lien avec cela et je vois que l'auteur l'a! La description du modèle de composant y était très utile, et j'aime bien que vous essayiez d'utiliser des exemples de code complets pour illustrer.

— CodexArcanum

2

Oui, je me souviens d'avoir lu votre lien il y a quelques années. Vous devriez finir ces articles!

— onedayitwill faire

2

Maintenant, le livre est terminé :)

— Dusan

1

Une ressource incroyable qui m'a aidé à traduire mes connaissances en programmation existantes en programmation pour jeux. Merci de l'avoir écrit!

Cette explication des modèles de programmation de jeux m'a en fait aidée à comprendre les modèles de conception, comme aucun livre de modèles de conception de logiciels ne le faisait réellement! C'est en partie le pouvoir du développement de jeux (exemples concrets dans un langage qui me parle et me permet d'améliorer mon développement dans son ensemble), mais dans une plus grande mesure parce que l'écriture est excellente.

— Kzqai

19

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.

— utilisateur744
source

4

Oui, l’une des choses clairement énoncées dans le livre original (mais souvent oubliée) est que s’il avait été écrit pour C plutôt que pour C ++ / Smalltalk, ils auraient peut-être inclus un motif "Héritage" et, du même coup, certaines langues. pourrait contenir certains des modèles GoF déjà intégrés.

— Kylotan

13

L'autre aspect souvent négligé dans le livre original (le livre original d'Alexander, pas de GoF) était que les motifs sont un outil de communication , pas de mise en œuvre . Ils permettent aux concepteurs de communiquer sur la mise en œuvre à un niveau supérieur et sont identifiés parce qu'ils sont récurrents, pas nécessairement parce qu'ils doivent être utilisés lorsque cela est possible.

1

Cependant, le simple fait de disposer de la terminologie peut vous aider à raisonner sur le problème et à reconnaître quand une telle approche est une bonne solution. Les meilleurs modèles ont généralement été affinés au fil du temps par des travailleurs qualifiés et expérimentés, et les travailleurs moins qualifiés ne découvriraient pas les mêmes modèles sans ces exemples codifiés.

— Kylotan

Je suis d'accord pour dire que la terminologie est excellente et que la définition d'un motif est en partie une bonne solution récurrente pour certains problèmes. Malheureusement, les travailleurs les moins qualifiés ont tendance à trouver principalement Singleton et à l'appliquer à tous les problèmes, même s'il n'y en a pas encore.

Merci pour cette réponse Je me sens soulagé de lire que les modèles de conception sont conçus pour résoudre les problèmes créés par la conception du logiciel. Je pense que la structure d'un gros logiciel doit être pensée du début à la fin avant de commencer à coder quoi que ce soit. Vous ne pouvez pas toujours implémenter les fonctionnalités une à une fois, vous devez parfois réfléchir à chaque fonctionnalité en particulier et vérifier si elle ne dérange pas la structure globale du logiciel ou ne vous empêchez pas de comprendre comment le logiciel est proposé. se comporter. Diviser les tâches entre plusieurs programmeurs peut parfois créer des contradictions ...

— jokoon

7

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.

— Gregory Avery-Weir
source

Merci pour la contribution! Je n'étais pas au courant de ce livre, mais je vais l'examiner maintenant à la suite de votre message. Merci encore!

— jcurrie33

2

Singleton pour le lecteur de clavier est exactement la situation où je dois demander - Pouvez-vous vraiment ne pas en faire un pointeur global défini au début de votre fonction principale? Avez-vous déjà réellement accidentellement instancié deux lecteurs de clavier?

S'il vous plaît, détestez le singleton. Il fait deux choses mal. Accès global et arité. Les développeurs pensent souvent à un accès global == singleton. Il y a très peu de problèmes qui nécessitent un vrai singleton, et peut-être quelques autres qui sont plus élégants lorsqu'ils sont résolus avec un singleton.

— deft_code

7

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):

— Wernight
source

3

"Ce n'est pas exactement un modèle de conception car il ne s'agit pas d'un problème de POO." Les modèles de conception n'ont rien à voir avec la POO; en réalité, la programmation orientée objet est un modèle de conception. Les modèles de conception apparaissent non seulement en dehors de la POO, mais également en dehors du développement de logiciels.

Il y en a OOP design patternsqui montrent généralement les relations et les interactions entre les classes / objets. Et il y a beaucoup d'autres modèles de conception. La POO est un ensemble de concepts, pas un modèle en réalité. Design patternest un concept aussi.

— topright

6

Au lieu de parler de sémantique, ne devriez-vous pas évaluer l'utilité de la réponse que j'ai donnée?

— Wernight

6

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

— Kylotan
source

Pourriez-vous nommer un ou deux modèles de conception que vous avez utilisés fréquemment dans le développement de votre jeu, et pour quelle raison? En tant que débutant en ce qui concerne les modèles de conception, "tous" n'est pas une réponse particulièrement utile. Merci d'avoir répondu, cependant.

— jcurrie33

5

Demander "quels modèles avez-vous utilisés?" est comme demander "quels noms de variables avez-vous utilisés?" Cela dépend du style personnel, des exigences et du domaine. À un moment donné, vous utiliserez probablement n'importe quel motif jamais nommé. Vous en utiliserez probablement beaucoup d'autres qui n'ont pas encore été nommés, et peut-être même en inventez de nouveaux.

@ jcurrie33: désolé, je ne pouvais tout simplement pas résister à l'idée de creuser d'abord chez les singletons. ;)

— Kylotan le

6

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 .

— droite
source

Les composants utilisés dans la conception de jeux ressemblent davantage à un modèle de stratégie avec état, ce qui se traduit naturellement par des fermetures en dehors de C / C ++ / Java / C # et par des objets de composants à l'intérieur de celles-ci. Le motif de décorateur ressemble plus à un proxy; sa propriété et son flux de données sont opposés à ceux que nous entendons normalement lorsque nous parlons de systèmes de composants dans les jeux.

Les composants doivent également se parler, en intégrant des modèles tels que Mediator, Observer et Composer. "Jeu à base de composants" est un modèle de conception composite.

— CodexArcanum

@ CodexArcanum, observateur, définitivement, mais pas toujours médiateur (la chaîne de responsabilité peut être utilisée à la place). Il est compositeur seulement si GameObject (composé de GameObjectComponent) est GameObjectComponent lui-même (non nécessaire).

— 2010

6

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.

— Meule
source

J'ai toujours détesté que la couche d'abstraction os soit virtuelle. Ce n'est pas comme si vous aviez besoin de deux couches d'abtraction en os. Bien mieux d'utiliser le CRTP.

— deft_code

Peut-être que je suis juste vieux, mais je n'utiliserais même pas CRTP pour DX / OpenGL ou les interfaces de plate-forme. C'est trop lent à compiler - je n'utiliserais que des typedefs. Le protocole CRTP est utile lorsque vous souhaitez partager des interfaces et des implémentations entre des classes sans avoir aucune autre relation, pas lorsque vous souhaitez simplement choisir une structure ou une autre.

4

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.

— chaos
source

Je ne vois pas du tout en quoi il s’agit d’un singleton et lorsque nous discutons du modèle de poids mouche, le mot "registre" est redondant. Ceci est juste flyweight.

D'après ce que j'ai compris du fil SO, les gens ont identifié Singleton comme faisant partie de celui-ci en raison de la définition des définitions en tant que classes. En ce qui concerne le registre, je ne vois pas comment il peut être redondant de le remplacer ou de le combiner avec Factory.

— Chaos

-1, dans la mesure où les modèles concernent la communication rapide, c'est probablement le plus gros échec que j'ai vu. Je ne peux vraiment pas prendre cette description au sérieux.

Jésus, pardonnez-moi de ne pas être un emporte-pièce suffisant pour vous. Allez-vous voter contre la réponse "Entity systems" également parce qu'elle n'est pas résumable instantanément en termes de GOF?

— chaos

1

Une certaine quantité de "cookie-cutter", ou au moins de clarté sémantique, est exactement ce que les modèles doivent être pour être utiles. Des termes tels que "poids mouche" et "singleton", tels qu'ils sont communément compris, s'excluent mutuellement. Le premier concerne le partage automatique des données entre plusieurs instances; la seconde consiste à avoir exactement une instance. Je ne dis pas que votre choix de conception est inutile ou même mauvais, mais regrouper des noms de motifs "assez proches" ensemble ne fait que dérouter tout le monde. (Merci de ne pas prendre les votes négatifs personnellement, surtout en CW.)