Je suis en train de développer un jeu basé sur des sprites 2D pour Windows 7 Phone, en utilisant XNA. La formation et les didacticiels disponibles sont assez utiles, mais le problème auquel je suis confronté est que chacun d'eux aborde la conception de sa classe différemment, et le code n'est pas particulièrement bien factorisé. Par conséquent, il m'a été difficile d'acquérir une bonne compréhension des responsabilités que je devrais confier à une classe particulière.
Par exemple, je pourrais avoir une classe de sprite de base BaseSpritequi sait se dessiner, vérifier les collisions, etc. Je pourrais alors avoir une AnimatedSpriteclasse qui saurait naviguer dans sa feuille de sprite, une ExplodingSpriteclasse, etc. Cette technique est illustrée dans l'exemple Space Invaders dans les documents de la session 2 de Windows 7 Phone Jumpstart .
Alternativement, je pourrais plutôt placer l'essentiel du rendu et de l'exécution de la responsabilité du jeu dans une GameScreenclasse; cette classe et ses classes dérivées se comportent davantage comme des formulaires ou des pages Web en termes de responsabilités. Les classes de sprites sont des conteneurs plus simples avec beaucoup moins de logique.
Il s'agit de la technique utilisée dans le jeu Alien Sprite du Kit de formation Windows 7 Phone et d'autres exemples de gestionnaire d'état du jeu.
Quelle est l'approche orientée objet correcte pour la conception de classes dans le développement de jeux?
Dans les jeux, le modèle de composant est une solution courante.
la source
Les principes SOLID s'appliquent autant à la conception de code de jeu qu'à toute autre profession - au moins jusqu'à ce que vous arriviez à l'optimisation, donc j'utiliserais votre premier exemple comme point de départ.
J'irais plus loin, car BaseSprite semble avoir tendance à devenir une mégaclasse. Le principe de responsabilité unique impose que la collision, le rendu et la navigation soient tous gérés par des composants, plutôt que par des entrées individuelles dans une hiérarchie de classes. La classe de détention de tous ces composants ne devrait gérer que les positions du monde entre eux.
la source
Pour les derniers projets, je me suis davantage penché vers une approche de style MVC.
Au début, nous ne savions pas si cela fonctionnerait, mais cela a parfaitement fonctionné.
Modèle
Les objets de données. Juste les données pures. Aucun comportement, aucun rendu.
Manager de données. Il suffit de gérer des "listes" d'objets de données. (Peut également être amélioré pour prendre en charge la mise en commun.)
Vue
Nous les appelons des moteurs de rendu. Pour chaque type d'objet de données, il existe un rendu. Lorsqu'il est appelé avec un gestionnaire, il rendra tous les objets de cette liste.
Manette
Identique aux rendus, mais contrôle le comportement.
Exemple
Le ShipManager a une liste de navires. Le ShipController déplacera les navires en fonction de leur état. Le ShipRenderer rendra les navires en fonction de leur état.
Pourquoi
De cette façon, la vue et la logique sont strictement séparées. Cela rend le portage vers une nouvelle plate-forme assez facile. L'optimisation de la disposition des données à l'intérieur du XxxManager est également très simple.
la source