SpriteKit suit-il le modèle MVC?

Je travaille actuellement sur un projet iOS appelé Old Frank que j'ai essayé de suivre un modèle de conception MVC.

L'essentiel est.

GameObjects(model) <- Scene(controller) -> Sprites "SpriteKit" (View)

Maintenant, si je comprends bien MVC, vous ne pouvez pas utiliser beaucoup de fonctionnalités que SpriteKit a à offrir si vous souhaitez suivre MVC. Par exemple, tout SKAction, détection de collision, etc.

N'est-ce pas au modèle où se trouvent les objets du jeu et comment ils doivent réagir lorsqu'ils touchent d'autres objets? N'est-ce pas au modèle de déterminer l'emplacement au fil du temps?

Y a-t-il des parties de SpriteKit qui pourraient être considérées comme utilisables comme "vue" dans MVC autres que le rendu?

— Skyler Lauren
source

«J'ai essayé de suivre un modèle de conception MVC» - pourquoi?

— Paul D. Waite

@ PaulD.Waite J'aime l'idée de garder mon modèle séparé. En théorie, cela facilite le portage ou la recréation sur une autre plate-forme. Cela facilite également la gestion de la persistance, ce qui a été la principale raison jusqu'à présent.

— Skyler Lauren

Je t'ai eu. Pour atteindre l'objectif de persistance, le modèle de souvenir peut être plus applicable que MVC. Vos sprites pourraient être l'initiateur, et ils auraient la responsabilité de produire une représentation sauvegardable de leur état, et de se restaurer à partir de cette représentation plus tard. Votre contrôleur de scène pourrait être la chose qui demande leur représentation.

— Paul D. Waite

Cela pourrait également entraîner l'utilisation de vos sauvegardes sur une autre plate-forme, bien que je soupçonne que cela soit aussi loin que possible en termes de portabilité lorsque vous travaillez avec un framework uniquement Mac / iOS comme SpriteKit.

— Paul D. Waite

@ PaulD.Waite merci pour vos commentaires Je vais examiner le modèle de souvenir comme un autre modèle à considérer à l'avenir. Les deux questions portent sur le même projet oui mais ne sont pas liées. Surpris de voir que l'autre a migré vers stackoverflow et examinera sa réponse un peu plus tard ce soir =)

— Skyler Lauren

Réponses:

Votre question est bonne. J'ai eu exactement la même question concernant SpriteKit et j'ai été très confus quant au manque d'informations sur le Web à ce sujet. SpriteKit semble vous encourager à mettre tout votre code Model-View-Controller dans la même classe (votre sous-classe SKScene), ce qui est vraiment déroutant pour moi. Comment pourriez-vous jamais construire un jeu de toute complexité en utilisant cette technique? Combiner l'état du jeu (score, numLives, etc.), avec du code de contrôleur comme touchesBegan / Ended, et afficher le rendu dans la même classe devient vraiment difficile à gérer au-delà du plus simple des jeux.

Je conviens que l'utilisation du modèle de souvenir pour aider à la persistance est une bonne idée, mais je pense également que le passage à une conception MVC pourrait être bénéfique. Je déplace actuellement mon jeu dans une architecture MVC. Mon approche actuelle consiste à faire gérer par mon modèle (objets de jeu) les corps physiques, la sous-classe SKScene comme contrôleur et une classe distincte pour agir comme vue pour configurer et rendre les aspects visuels des SKNodes dans la scène. Je ne suis qu'à mi-chemin du processus, donc je ne peux pas dire avec certitude si ce sera une bonne conception, mais il semble que ce sera beaucoup mieux que d'avoir une sous-classe de 10000 lignes de SKScene.

— John Cleveland
source

Merci pour votre réponse / commentaire. On dirait que vous pensez que l'utilisation des fonctionnalités de SpriteKit ne suit pas non plus le design MVC. N'hésitez pas à m'envoyer un e-mail à skyler@skymistdevelopment.com si vous avez des questions sur la façon dont "j'utilise MVC ou si vous voulez en savoir plus sur la façon dont" vous "utilisez MVC avec SpriteKit =)

— Skyler Lauren

Rien ne vous oblige à mettre la plupart de votre code dans la classe SKScene. En fait, je trouve qu'en utilisant SpriteKit, la plupart de la logique revient aux nœuds beaucoup plus naturellement que la scène, car les nœuds sont le poids de SpriteKit. La scène est un peu plus que le "contrôleur" pour gérer la mise à jour et la saisie de votre arborescence de nœuds. Bien que le modèle "MVC" ne corresponde toujours pas à SpriteKit, car les nœuds ont tendance à être le "M" et le "V".

— Attackfarm

En termes simples, une conception courante dans les jeux SpriteKit est des scènes, des couches, des nœuds et des nœuds enfants.

Vous pouvez faire de chaque pièce une classe discrète qui encapsule toutes les pièces, propriétés et méthodes.

Par exemple, une classe d'arrière-plan contenant des images en couches, des particules, diverses propriétés telles que la vitesse de déplacement de chaque calque et des méthodes publiques pour démarrer et arrêter le défilement de l'arrière-plan.

Dans cette conception, vous assemblez ces classes discrètes qui font leur propre travail dans la scène qui gère principalement la mise à jour en cours: physique, événements tactiles, etc.

— Jeremy
source