RPG Boucle de jeu et structure de classe (cocos2D pour iPhone)

Question

Je cherche à faire un RPG avec Cocos2D sur l'iPhone. J'ai fait pas mal de recherches, et j'aime beaucoup le modèle que Cocos2D utilise pour les scènes. Je peux instancier une scène, mettre en place mes personnages etc. et tout fonctionne très bien ... ce qui me pose problème, c'est de structurer une boucle de jeu et de séparer le code des scènes. Par exemple, où est-ce que je mets mon code qui maintiendra l'état du jeu à travers plusieurs scènes? et est-ce que je mets le code pour les événements qui se déclenchent dans une scène de la classe de cette scène? ou ai-je une autre classe qui sépare le code init de la logique? De plus, j'ai lu beaucoup de tutoriels qui parlent de changer de scène, mais je n'en ai lu aucun qui parle de la mise à jour d'une scène - en prenant l'entrée de l'utilisateur et en mettant à jour l'affichage. Cela se produit-il dans l'objet de scène ou dans une classe de type de moteur d'affichage distincte.

Merci d'avance!

Answer 1

Il semble que vous fassiez bien de lire le modèle Model-View-Controller. Vous n'avez pas besoin d'y adhérer servilement (par exemple, dans certains contextes, il est logique d'autoriser un certain chevauchement entre Model et View), mais une bonne compréhension de celui-ci vous aidera à construire un programme comportant beaucoup d'objets graphiques et la logique les contrôlant, et la nécessité de diffuser l'état ou le conserver sur disque (sauvegarde de jeu), etc.

Vous devez également réaliser que cocos2d fournit un bon système pour structurer le graphe de scène graphique et le rendre efficacement, mais il ne fournit pas une infrastructure complète pour les jeux de programmation. En ce sens, il s'agit plus d'un moteur graphique que d'un moteur de jeu. Si vous essayez d'adapter l'architecture de votre jeu à la structure de cocos2d, vous risquez de ne pas obtenir le résultat le plus exploitable. Au lieu de cela, vous devriez considérer cocos2d comme ce qu'il est: un excellent outil pour prendre soin de vos besoins d'affichage et d'animation.

Vous devez absolument avoir un objet autre que les scènes qui maintiennent l'état du jeu, car sinon, où ira tout l'état lorsque vous passerez d'une scène à l'autre? Et dans les scènes/niveaux, vous devriez simplement essayer d'utiliser un bon design orienté objet pour avoir l'état réparti sur les objets de différentes classes. Chaque objet personnage se souvient de son propre état etc. Ici, vous pouvez voir où MVC devient utile: lorsque vous sauvegardez le jeu sur un disque, vous voulez vous souvenir du niveau de santé de chaque personnage, mais probablement pas de l'index exact de l'animation. Vous devez donc faire la distinction entre le sprite et le caractère (modèle) lui-même. Cela dit, comme je l'ai déjà mentionné, pour les objets de jeu qui n'ont pas beaucoup de logique ou qui n'ont pas besoin d'être sauvegardés, il serait peut-être bon de fusionner le modèle et la vue en une seule classe (fondamentalement en sous-classant CCSprite).

Pour extraire MVC comme il est censé être, vous devez également apprendre les bases de Key-Value Observing. (Et vous feriez bien d'utiliser this replacement pour l'interface d'Apple.) Dans les jeux intensément en temps réel, des techniques comme celle-ci peuvent être trop lentes, mais puisque vous faites un RPG (un bon choix pour débuter) vous pourriez probablement sacrifier performance pour une architecture plus maintenable.

La scène de jeu (qui est juste un autre sprite cocos2d) joue le rôle de contrôleur, en termes de modèle MVC. Il ne dessine rien lui-même, mais dit à tout le reste de se dessiner sur la base des entrées et de l'état. Il est tentant de mettre toutes sortes de logique et de fonctionnalité dans la scène du jeu, mais quand vous remarquez qu'il gonfle, vous devriez vous demander comment vous pourriez séparer cette fonctionnalité dans d'autres classes. Analysez le type de fonctionnalité que vous implémentez. Est-ce à voir avec les données et l'état (modèle)? Ou s'agit-il d'animation et de rendu (View)?Ou s'agit-il de connecter la logique avec le rendu (auquel cas vous devriez essayer de faire observer directement le modèle par la vue)? La scène de jeu/contrôleur est essentiellement un centre de répartition, qui prend des événements d'entrée (de l'utilisateur ou des sprites signalant qu'ils ont touché quelque chose, par exemple) et décide quoi faire avec eux: il pourrait en dire un ou plusieurs des objets Model pour se mettre à jour d'une certaine manière, ou cela pourrait simplement déclencher une animation dans d'autres sprites, par exemple. Dans une partie en temps réel, vous auriez une méthode "tick" ou "step" dans la scène qui indique à tous les objets de se mettre à jour eux-mêmes. Cette méthode (la boucle de jeu) est le cœur du programme et est exécutée chaque fois qu'une nouvelle image est dessinée. (Dans les moteurs de jeu modernes, il y a beaucoup de multi-threading mais ne pensons pas à cela.) Mais dans votre cas, vous pourriez vouloir créer un module qui peut "jouer le jeu" complètement séparé de la scène du jeu. Imaginez créer un programme capable de jouer aux échecs via le terminal, en utilisant uniquement la saisie de texte. Si vous créez le système de jeu entier de cette manière, puis que vous le connectez au moteur graphique via une interface petite et propre, vous aurez une application vraiment maintenable avec beaucoup de code réutilisable pour les futurs projets!

Quelques bonnes règles: le modèle (données) ne doit pas connaître quoi que ce soit sur les sprites ou les états d'affichage; la vue (sprites) ne devrait contenir aucune logique réelle du jeu (les règles du jeu) mais seulement savoir faire des choses simples comme se déplacer et rebondir et rapporter à la scène si quelque chose de compliqué se produit. Dans la mesure du possible, la vue doit réagir directement aux modifications du modèle, sans que le contrôleur ne doive interférer.