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

Maintenant pour 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 dutilisation possible.

• Générateur: configurez une entité basée sur un composant un composant à la fois, en fonction des données
• Méthode dusine: créez des PNJ ou des widgets GUI basés sur une chaîne lue dans un fichier
• Prototype: stockez 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: intégrez une bibliothèque tierce facultative en lenveloppant dans une couche qui ressemble à votre code existant. Très utile avec les DLL.
• Composite: créez un graphe de scène dobjets pouvant être rendus ou créez une interface graphique à partir dune arborescence de widgets
• Façade: simplifiez les bibliothèques tierces complexes en fournissant une interface plus simple pour vous faciliter la vie plus tard.
• Poids volumétrique: stockez les aspects partagés dun PNJ (par exemple, les modèles, les textures, les animations) séparément des aspects individuels (par exemple. position, santé) dans un manière principalement transparente
• Proxy: Créez de petites classes sur un client qui représentent des classes plus grandes et plus complexes sur un serveur, et transférez les requêtes via le réseau.
• Chaîne de responsabilité: gérer les entrées comme une chaîne de manutentionnaires, par exemple. touches globales (par exemple pour les captures décran), puis linterface graphique (par exemple dans le cas où une zone de texte est focalisée ou un menu est en haut), puis le jeu (par exemple pour déplacer un personnage)
• Commande: encapsuler les fonctionnalités du jeu sous forme de commandes qui peuvent être tapées dans une console, stockées et rejouées, ou même scriptées pour aider à tester le jeu
• Médiateur: implémentez les entités de jeu comme une petite classe de médiateur qui opère sur différents composants (par exemple. lecture depuis le composant de santé afin de transmettre les données au composant AI)
• Observateur: faire écouter la représentation rendue dun personnage aux événements de la représentation logique, afin de changer la présentation visuelle si nécessaire sans la logique du jeu ayant besoin de savoir quoi que ce soit sur le rendu du code
• État: stocke lIA du PNJ comme lun 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, stocker le personnage dont il attaque ou fuit, la zone dans laquelle il se promène, etc.)
• Stratégie: basculer entre différentes heuristiques pour votre recherche A *, en fonction du type de terrain dans lequel vous vous trouvez, ou peut-être même dutiliser le même framework A * pour faire à la fois la recherche de chemin et une planification plus générique
• Méthode de modèle: configurer un routine de «combat» générique, avec diverses fonctions de crochet pour gérer chaque étape, par exemple, décrémenter les munitions, calculer les chances de toucher, résoudre les coups ou les manquer, calculer les dégâts, et chaque type de compétence dattaque implémentera les méthodes de sa propre manière spécifique

Quelques modèles laissés de côté faute dinspiration.

Commentaires

• Une discussion très enrichissante sur les singletons peut être trouvée ici: misko.hevery.com / 2008/08/25 / root-cause-of-singletons
• +1 pour le modèle de stratégie. Je ' lai utilisé exactement dans le but indiqué ci-dessus (brancher différentes heuristiques A *).
• merci pour cette réponse, cela ressemble plus à un modèle de conception quà lhabituel " singleton " i ' jentends partout …
• Excellente liste dexemples. Malgré labus chronique du motif singleton (état global déguisé), il y a des utilisations légitimes: quand il représente une ressource dont vous nen avez (ou voulez) quune. Cela peut être quelque chose comme envelopper du matériel (par exemple, clavier / souris) ou envelopper une bibliothèque qui nest pas réentrante (cela arrive, et toutes les langues nont pas de mots-clés de synchronisation magiques).
• Je ne le ferais toujours pas ' t utiliser des singletons pour les ressources matérielles – les éléments que vous pensez ' nauront jamais quun seul sur ont tendance à se multiplier plus tard, tout comme les cartes vidéo et les moniteurs lont fait. des années ont passé. De même, sous certaines API, vous devez lire 2 joysticks pour comprendre 1 gamepad. Donc, je ' d dire, si vous n’avez besoin que d’un élément, instanciez-en un seul, ne ' pas d’appliquer des restrictions arbitraires qui probablement aren ' t nécessaire.

Jai écrit un livre sur exactement ce sujet: Modèles de programmation de jeu . Les chapitres qui sy trouvent pourraient vous être utiles.

Commentaires

• +1 Jespérais que quelquun avait lié à cela et je vois que lauteur a! La description du modèle de composant était assez utile, et jaime que vous essayiez dutiliser des exemples de code complets pour démontrer.
• Ouais – je me souviens avoir lu votre lien il y a quelques années. Vous devriez terminer ces articles!
• Le livre est maintenant terminé 🙂
• Une ressource incroyable qui ma aidé à traduire mes connaissances en programmation existantes en programmation pour les jeux. Merci de lavoir écrit!
• Cette explication des modèles de programmation de jeux ma aidé à comprendre les modèles de conception dune manière quaucun livre de modèles de conception de logiciels ne le faisait vraiment! Cest en partie la puissance du développement de jeux (exemples concrets dans un langage qui me parle et me permet daméliorer mon développement globalement), mais en grande partie parce que lécriture est tellement excellente.

Une chose que Brandon Eich a eu le bon sens dévoquer dans les Codeurs au travail est que les modèles sont des hacks et des solutions de contournement: [Patterns] montrent une sorte de défaut dans la langue. Ces modèles ne sont pas gratuits. Il ny 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 concepteurs de compilateurs, nous avons rarement la possibilité de faire évoluer les langages nous utilisons, mais nous pouvons apprendre à faire évoluer notre propre style pour mieux sadapter à notre langage et à nos exigences. Les modèles en sont une partie, mais ne pas utiliser de modèles en est une autre, dautant plus que, comme le dit Brandon, les modèles disparaissent rarement sans un coût notable en termes de performances, de mémoire ou dagilité du code. MVC nest tout simplement pas un bon modèle pour beaucoup de choses dans les jeux. Singleton est une solution de contournement pour les règles dinitialisation statiques C ++ boiteuses, et vous ne devriez probablement pas le faire de toute façon. Factory simplifie la création dobjets compliqués – vos objets devraient peut-être être plus simples pour commencer. Les modèles populaires sont des outils auxquels recourir lorsque nous en avons besoin pour gérer quelque chose de complexe, et non des outils que nous devrions avoir envie dutiliser pour construire quelque chose de complexe au début.

Un bon code (de jeu) peut utiliser des modèles, ou pas. Sil utilise des modèles, très bien – cest un excellent outil de communication pour expliquer la structure du code à dautres programmeurs à un niveau élevé et indépendant du langage. Si vous pensez que le code est meilleur sans utiliser de modèle, ne vous en faites pas. il – cest probablement le cas.

Commentaires

• Oui, l’une des choses expliquées clairement dans le livre original (mais souvent négligée) est que si elle ont été écrits pour C plutôt que C ++ / Smalltalk, ils auraient peut-être inclus un modèle " Héritage ", et du même coup, certains les langages peuvent contenir certains des modèles GoF déjà intégrés.
• Lautre chose souvent négligée dans le livre original (le livre original dAlexandre, et non du GoF) était que les modèles sont un outil de communication , pas mise en œuvre . Ils permettent aux concepteurs de communiquer sur limplémentation à un niveau supérieur et sont identifiés parce quils sont récurrents, pas nécessairement parce quils devraient être utilisés lorsque cela est possible.
• Cependant, le simple fait davoir 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 eux-mêmes les mêmes modèles sans ces exemples codifiés.
• Je suis daccord pour dire que la terminologie est excellente, et une partie de la définition dun modèle est quil sagit dune bonne solution récurrente pour certains problèmes. Malheureusement, les travailleurs les moins qualifiés ont tendance à trouver principalement Singleton et à lappliquer à chaque problème, même sil ny a pas encore de problème.
• 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 de tout un gros logiciel doit être pensée du début à la fin avant de commencer à coder quoi que ce soit. Vous pouvez ' t toujours implémenter les fonctionnalités une fois à la fois, parfois vous devez penser à chaque fonctionnalité particulière et vérifier si elle a gagné ' t perturber la structure globale du logiciel ou tout simplement gêner la façon dont le logiciel est censé se comporter. Répartir les tâches entre plusieurs programmeurs peut parfois créer des contradictions …

Bien sûr, comme dautres lont dit , tous les modèles sont utiles dans les bonnes circonstances, et une partie de lapprentissage de leur utilisation consiste à apprendre quand les utiliser. Cependant, lexcellent livre 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 dutilisabilité comme particulièrement utile dans la programmation de jeux.

Programmation:

• Singleton: Je ne déteste pas celui-ci comme beaucoup de gens le font; il peut être utilisé pour des choses comme le single- joueur ou le lecteur de clavier.
• Usine: vous permet de créer et de détruire des objets efficacement.
• Stratégie: vous permet de modifier les stratégies dIA avec élégance.
• Index Spatial : Permet deffectuer des requêtes sur des ensembles de données spatiales.
• Composite: configure une hiérarchie dobjets utile.
• Flyweight: libère de la mémoire en généralisant des choses comme des ennemis identiques.

Facilité dutilisation:

• Bouclier: protège de lactivation accidentelle dactions dramatiques.
• État: Indices visuels du monde / état de linterface utilisateur
• Annulation automatique du mode: rend le jeu plus intuitif.
• Aimant ism: Autoaiming et sélection dunité facile.
• Focus: Éliminer les éléments dinterface utilisateur distrayants.
• Progrès: universellement utile.

Le livre, bien sûr , entre plus en détail sur chacun de ces éléments.

Commentaires

• Merci pour votre contribution! Je nétais pas au courant de ce livre, mais je vais lexaminer maintenant à la suite de votre message. Merci encore!
• 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à instancié accidentellement deux lecteurs de clavier?
• Sil vous plaît, détestez le singleton. Il fait mal deux choses. Accès global et arité. Les développeurs pensent souvent que laccès global == singleton. Il y a très quelques problèmes qui nécessitent un vrai singleton, et peut-être quelques autres qui sont plus élégants lorsquils sont résolus avec un singleton.

Les systèmes dentités sont une belle sorte de modèle. Ce nest pas exactement un modèle de conception car ce nest pas strictement de la POO. Cependant, vous pouvez le mélanger avec la POO.

Quelques bons liens (commencer par le haut pour lintro):

• 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

Commentaires

• " Ce ' nest pas exactement un modèle de conception car il ' nest pas strictement [sic] POO. " Les modèles de conception nont rien à voir avec la POO; le cas échéant, la POO elle-même est un modèle de conception. Les modèles de conception napparaissent pas seulement en dehors de la POO, mais entièrement en dehors du développement logiciel.
• Il existe des OOP design patterns qui montrent généralement les relations et les interactions entre les classes / objets. Et il existe de nombreux autres modèles de conception. La POO est un ensemble de concepts, pas vraiment un modèle. Design pattern est aussi un concept.
• Au lieu de parler de sémantique, ' t vous évaluez l’utilité de la réponse que jai donnée?

Tous. Sauf Singleton. [/ flippancy]

Commentaires

• Pourriez-vous nommer un ou deux modèles de conception que vous ' avez été fréquemment utilisé 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 " nest pas une réponse particulièrement utile. Merci davoir répondu.
• Demander à " quels modèles avez-vous utilisés? ", cest comme demander " quels noms de variables avez-vous utilisés? " Cela se résume au style personnel, aux exigences et au domaine. À un moment donné, vous utiliserez probablement nimporte quel modèle que ' a déjà été nommé. Vous en utiliserez probablement beaucoup dautres qui nont pas été nommés, et peut-être même en inventerez-vous de nouveaux.
• @ jcurrie33: désolé, je nai pas pu ' résister à avoir une fouille chez les singletons dabord. 😉

Pas vraiment sur les modèles, mais sur les principes de base derrière eux. Dans « Design Patterns: Elements of Reusable Object-Oriented Software » (1995) , le gang des quatre (Gamma, Erich; Richard Helm, Ralph Johnson et John Vlissides) recommande seulement deux principes pour la conception orientée objet: (1) programme vers une interface et non vers une implémentation et (2) privilégier la composition des objets à lhéritage de classe.

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

Commentaires

• Composants utilisés dans la conception de jeux ressemble plus à un modèle de stratégie avec état – qui est naturellement exprimé comme des fermetures en dehors de C / C ++ / Java / C #, et comme des objets composants à lintérieur. Le motif 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, apportant des modèles tels que Mediator, Observer et Composer. " Le jeu basé sur des composants " est un modèle de conception composite à lui seul.
• @CodexArcanum, Observateur, définitivement , mais pas toujours Mediator (la chaîne de responsabilité peut être utilisée à la place). Ce nest Composer que si GameObject (composé de GameObjectComponent) est GameObjectComponent lui-même (pas nécessaire).

Le modèle de modèle curieusement récurrent peut être vraiment utile pour éviter les méthodes virtuelles et la pénalité de performance qui peut provenir des appels de fonction virtuelle.

Ceci peut être le modèle approprié lorsque vous n’avez pas réellement besoin d’un conteneur du type de classe de base qui a l’interface que vous recherchez, mais que vous aimeriez avoir des comportements et des interfaces portant le même nom.

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

Commentaires

• Jai toujours détesté que la couche dabstraction du système dexploitation soit virtuelle. ' nest pas comme vous ' Jaurai besoin de deux abstractions de système dexploitation couches. Il est préférable d’utiliser le CRTP.
• M aybe je ' je suis juste vieux, mais je ' t même utiliser CRTP pour DX / OpenGL ou les interfaces de plate-forme. Il ' est trop lent à compiler – Je ' d utiliser juste des typedefs. Le CRTP est bon lorsque vous souhaitez partager des interfaces et des implémentations entre des classes mais que vous navez pas dautre relation, pas lorsque vous voulez simplement choisir une structure ou une autre.

Un modèle de conception que jai développé au cours de nombreuses années, et qui ma été dune utilité spectaculaire, est quelque chose que jappelle des « ensembles de définitions négociés »; comment le résumer en termes GOF semble être controversé, mais cette question que jai écrite à ce sujet sur StackOverflow donne quelques détails à ce sujet.

Le concept de base est quune propriété dun modèle, comme lespèce dune créature, est configurée de sorte que chaque valeur possible pour 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, du point de vue 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, pour faciliter la liaison faible à des fins de morphisme dexécution.

Commentaires

• Je ne ' ne vois pas en quoi il s’agit d’un singleton et lorsque je discute du modèle de poids mouche le mot " registre " est redondant. Cest juste un poids plume.
• Daprès le fil SO, les gens identifiaient Singleton comme faisant partie de celui-ci en raison des définitions configurées en tant que classes. En ce qui concerne Registry, je ne ' pas voir comment il peut être redondant quand il peut être remplacé ou combiné avec Factory.
• -1, dans la mesure les modèles sont sur le point de communiquer rapidement, cest probablement le plus gros échec que jai ' vu. Je ne peux vraiment ' t prendre cette description au sérieux.
• Jésus, pardonnez-moi de ne pas être assez emporte-pièce pour vous. Allez-vous voter contre la réponse " Entity systems " car elle nest pas ' t instantanément résumable en termes GOF?
• Une certaine quantité de " emporte-pièce, " ou au moins clarté sémantique , est exactement ce que les modèles doivent être pour être utiles. Des termes tels que " flyweight " et " singleton " tels quils sont généralement compris sont mutuellement exclusifs. 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 bourrer " assez près " confondent tout le monde davantage. (Merci de ne pas ' retirer personnellement les votes négatifs, surtout sur CW.)