Dois-je sous-classr CCSprite, CCNode ou NSObject?

Votre question a vraiment du sens.

C'est fondamentalement une question d'architecture. Si votre jeu est principalement basé sur "l'animation", j'irais sous-classr CCSprite. Si votre jeu est principalement basé sur une certaine logique, peut-être un RPG ou quoi que ce soit d'autre, alors la représentation de l'écran est en fait juste une des vues possibles de l'état du jeu. Par conséquent, il devrait être, à mon avis, partie d'un object dans l'tree des objects qui représente votre état de jeu.

En d'autres termes: si votre état de jeu est essentiellement une scène, alors sous-class CCSprite, car Cocos2D est probablement bien meilleur que vous pour la gestion des scènes. Si votre état de jeu est "quelque chose d'autre", vous devriez probablement envisager de build votre propre représentation de cet état, et faire de votre sprite une partie de votre object de jeu. Cela vous permettra également de "changer" de moteurs charts si vous décidez de changer de rendu. Par exemple, vous pourriez faire un RPG avec une représentation 2D dans Cocos2D. Au bout d'un moment, vous montrez votre démo à Ubisoft et ils en tombent amoureux et vous donnent 20 millions de dollars pour la terminer, mais ils requestnt un rendu 3D. Si vous êtes allé sous-classr CCSprite, vous devez refaire tout le jeu. Si vous avez choisi d'intégrer CCSprite / CCNode dans une class dérivée de NSObject, vous pouvez y aller.

Bien sûr, cet exemple est légèrement exagéré dans le but de … exemple: D

Ma preference est de sous-classr CCNode presque exclusivement .

Je ne ferais que sous-classr CCSprite, CCLabel et d'autres classs Cocos2D internes si j'avais besoin que l'image-object, l'label ou quoi que ce soit se comporte légèrement différemment de l'implémentation de base. Et le sous-classment serait une mesure de dernier recours si une catégorie est insuffisante. Ce que la plupart des développeurs de Cocos2D ne include apparemment pas, c'est que CCSprite est en soi une class complète qui n'a pas besoin d'être étendue (sous-classée) pour représenter les objects du jeu. Mais il est trop facile de tomber dans cette habitude parce qu'en créant une sous-class CCSprite, vous obtenez les visuels et vous avez un conteneur pour votre code de logique de jeu. Ce n'est tout simplement pas très OOP de le faire.

Si vous y réfléchissez, dès que vous ajoutez un code de jeu à CCSprite, ce n'est plus seulement un CCSprite, n'est-ce pas? Une bonne façon d'y penser est la suivante: si vous sous-classz une class (nommez-la MyClass) et y ajoutez du code personnalisé, est-ce que cela aurait aussi beaucoup de sens de sous-classr MyClass à d'autres fins? Si non, alors vous ne devriez pas sous-class.

Pour aller avec l'analogie OOP largement utilisée de la class "Car": vous sous-class "Car" pour faire des classs plus spécialisées mais toujours generics comme "SportsCar", "Truck", "Van" mais vous ne sous-classz pas "Car" à créer une "Porsche 911 V-Turbo Model 6". Pourquoi pas? Parce que la class "SportsCar" a tous les aspects pour créer une instance de SportsCar qui devient alors une "Porsche 911 V-Turbo Model 6".

L'autre chose que vous devez considérer est qu'une "Porsche 911 V-Turbo Model 6" serait une class hautement spécialisée qui n'a d'autre but que de définir ce qu'est cette voiture très spécifique. Cela n'aurait aucun sens de sous-classr la class "Porsche 911" car elle a essentiellement perdu ses attributes generics et les a remplacés par des détails d'implémentation très spécifiques. Si vous avez une class que vous ne pouvez pas raisonnablement sous-classr, vous avez créé une impasse dans votre hiérarchie de class et vous écrivez essentiellement du code fonctionnel, pas du code orienté object. Pourtant, c'est bon pour les jeux simples mais ça reviendra vous hanter si vous osez en faire plus.

Pour résumer: vous ne sous-classz CCSprite que si vous avez l'intention de créer un type de CCSprite plus spécialisé mais toujours utilisable. Un exemple pour cela serait CCLabelTTF, qui sous-class de CCSprite. Il ajoute uniquement la possibilité de créer la texture CCSprite à l'exécution à partir d'une police et d'une string. Un autre exemple de sous-class CCSprite serait si vous aviez besoin d'un CCSprite qui mettrait à jour sa texture à partir de Google Maps pour ressembler à une mosaïque de maps basée sur les coordonnées de longitude et de latitude et le niveau de zoom. Ce serait encore essentiellement un object stupide dont le seul but est d'afficher une image rectangular à une certaine position. C'est ce qu'est un CCSprite. Un object stupide qui affiche une texture à une certaine position.

La question est vraiment à propos de ceci: est ("est un") votre object de jeu un sprite, ou at-il ("a un") un sprite pour sa représentation visuelle? La réponse devrait toujours être la dernière. La règle commune pour le sous-classment est la relation "est un", dans le cas de "a", il est time pour le model composite . En cas de doute, et les deux semblent s'appliquer, toujours errer sur le "a un" côté parce que cela fonctionne toujours.

Pourquoi dirais-je qu'un object de jeu n'est pas un sprite, mais qu'il a un sprite? Clairement les deux sont applicables. La réponse: l'object de jeu "est un" sprite seulement tant qu'il peut être représenté par un seul sprite et rien d'autre. En fait, il se peut que votre object de jeu doive être représenté par plusieurs sprites, ou une image-object, une label et des effets de particules. Cela signifie que la relation "est un" est beaucoup plus susceptible de se rompre au fur et à mesure que l'application est en cours de développement, ce qui signifie un travail de refactoring supplémentaire.

En utilisant un CCNode comme class de base pour vos objects de jeu et en ajoutant les nœuds visuels sur ce nœud de base, vous pouvez également utiliser le nœud de base comme object controller pour les vues de l'object de jeu. Ce qui signifie qu'il sera mieux conforme au model Model-View-Controller (MVC).

Finalement je ne sous-classrais pas NSObject pour quoi que ce soit qui devrait être dans la hiérarchie de vue de cocos2d, ou garderais une reference à quelque chose qui est dans la hiérarchie de vue de cocos2d. Pour la simple raison que les sous-classs NSObject n'offrent aucune des fonctionnalités standard d'un CCNode (planification, ajout de nœuds enfants, positionnement relatif des nœuds enfants) et surtout, il est difficile d'utiliser les sous-classs NSObject avec la gestion plutôt automatique de la memory de Cocos2D. classs de noeud.

Sans entrer dans les détails, la règle simple est que si une sous-class a une variable d'instance qui est un nœud Cocos2D, elle devrait être elle-même un nœud Cocos2D afin que la memory management et tous les autres aspects soient faciles et infaillibles. En ce qui concerne Cocos2D, la class CCNode est la class racine de la hiérarchie des vues, elle ressemble donc à la class UIResponder avec la possibilité d'assumer le rôle des classs UIView et / ou UIViewController (les deux sous-classs de UIResponder d'ailleurs) à l'occasion.

En bref: sous-class CCNode, puis utilisez le model de composition / agrégation pour les aspects visuels de la class.

Si vous avez cette question à cette entreprise de votre voyage Cocos2D, sous-class CCSprite et être fait avec elle. Vous ne créerez rien en ce moment qui nécessitera des techniques avancées de classs affinées. Je dis cela non pas comme une insulte à vos capacités, mais comme une personne qui avait une fois cette question.

Quand vous commencez à vous requestr si vous avez besoin de réécrire les appels de méthode OpenGL de CCNode, alors vous serez à un point où vous devrez examiner attentivement vos options de sous-classs. Sous-class CCSprite vous accorde toutes les methods et les propriétés de tout ce qui est inférieur, vous donnant la possibilité de découvrir, d'apprendre et d'aller de l'avant.

En bref: sous-class CCSprite.

à mon avis, l'object dans le jeu n'est pas sprite. Sprite est la représentation de l'object, c'est-à-dire que vous devez créer la sous-class GameObject NSObject (peut-être CCNode).

Pour récapituler: sous-class NSObject ou CCSprite est la structure de class, vous avez besoin d'utiliser votre style de code.