Apprenez & le développement de Jeu de Maître Cocos2D

Quand la question s'est levée si à la sous-classe CCSprite ou utilisent une classe modèle pour construire votre hiérarchie d'entité de jeu dans le forum cocos2d, j'ai souligné qu'il faudrait essayer de ne pas utiliser l'héritage et garder la hiérarchie d'héritage à comme peu de niveaux que possible. J'ai travaillé avec codebases avec les centaines de milliers de lignes de code et des centaines de types différents d'acteurs dans le monde. Pourtant la hiérarchie d'héritage était 2 classes (parentales) formidables pour presque tous les objets, seulement très peu d'objets de jeu avaient 3 ou 4 classes formidables. Comment pouvez-vous rendre des jeux complexes cette voie ? Yet the inheritance hierarchy was 2 super (parent) classes for almost all objects, only very few game objects had 3 or 4 super classes. How can you make complex games this way?

La réponse est dans la composition, souvent appelée les Composantes de Jeu par les moteurs comme TorqueX et le Moteur de Bouton-poussoir (un moteur de jeu d'Éclat des promoteurs de Moment de torsion originaux). Cette vidéo du Bouton-poussoir mène le promoteur Ben Garney l'explique très bien et illustre aussi le problème avec la surutilisation d'héritage dans les moteurs de jeu. Quelque chose que la plupart des promoteurs inconnues à orienté vers l'objet et/ou la programmation de jeu ont tendance vraiment en fait à surutiliser – j'en attribue la responsabilité aux livres pauvrement écrits et à d'autres sources OOP préliminaires qui accentuent l'héritage sans discuter ses inconvénients. Something that most developers new to object-oriented and/or game programming do in fact tend to over-use – i blame that on poorly written books and other introductory OOP sources which emphasize inheritance without discussing its disadvantages.

Vous pouvez lire plus du système de Composantes de Bouton-poussoir dans leur documentation. Comment ils ont exécuté des Composantes dans TorqueX et ce que les différences sont aux Composantes de Jeu XNA améliore plus loin la compréhension du concept.

Pour la lecture de plus et les arguments lit l'article Wikipedia de la composante a basé l'ingénierie de logiciel. En fait, la langue Objective-C a été inventée pour être capable de créer des composantes de logiciel réutilisables!

La conversation de 2002 GDC de Scott Bila d'Un Système d'Objet de Jeu Guidé par les données (PDF) comme utilisé par le Siège de Cachot contient plus de flèches sur pourquoi l'héritage échoue pour les promoteurs de jeu et ce que les avantages (mais aussi quelques mises en garde) sont avec les moteurs de jeu basés sur la composante. La conversation peut être vieille mais il est valide encore aussi aujourd'hui qu'il est revenu alors. En fait, en 2002 j'ai commencé à travailler sur SpellForce qui a déjà fait introduire un système composant dans son coeur, appelé des Aspects, des Capacités et des Charmes. Il nous a permis d'entrer toutes les données de jeu dans la base de données et les programmeurs avaient besoin d'écrire seulement le code générique qui s'est occupé des données, aussi bien que le cadre de certaines limites et des vérifications de la validité (eg. vous ne pouviez pas utiliser un charme nuisible sur vous, mais si vous vous avez voulu pourrait viser des ennemis avec votre guéris le charme, ou avoir des bâtiments de pousse d'archers … errm). In fact, in 2002 i started working on SpellForce which already had a component system built into its core, called Aspects, Abilities and Spells. It allowed us to enter all the game data in the database and programmers only needed to write the generic code that dealt with the data, as well as setting certain limits and validity checks (eg. you couldn’t use a damaging spell on yourself but if you wanted to you could target enemies with your heal spell, or have archers shoot buildings … errm).

Pendant 2009 GDC Marcin Chady de Divertissement Radical a tenu une présentation semblable. On a appelé la conversation la Théorie et la Pratique d'Architecture de Composante d'Objet de Jeu (PPT).

Mick West a écrit des Entités de Jeu d'article Refactoring avec les Composantes qui décrit les défis et les avantages de changer Tony Hawk codebase d'un modèle d'héritage à un système de composante de jeu.

Un peu plus avancé lu sur l'utilisation composante est un papier en collaboration appelé le Système de Composante d'Objet de Jeu Dynamique pour les Caractères de Comportement Variables qui parle des composantes dans le contexte de machines publiques finies et de comportements NPC avec un système d'activation basé sur la règle.

Le blog d'Architecte de Jeu l'appelle une Anatomie de Désespoir et résume très bon ce que le fait d'escroquer de design de classe basé sur l'héritage est et comment la composition les résout.