SpriteKit - Organisation des fichiers et du code
Bonsoir tout le monde,
Je suis actuellement occupé de tester SpriteKit pour créer des jeux mobiles, mais je me pose une question à laquelle je ne trouve pas de réponses.
Comment organiser mes différents fichiers et mon code ?
Je m’explique:
Pour le moment, dans tous les tutos que j’ai suivi, ils mettaient tout leur code dans un seul fichier (le GameScene), mais donc, la taille du code grandit rapidement, et je ne trouve pas cela maintenable dans le temps, surtout pour des plus gros projets.
J’ai essayé de faire du MVC, mais je me retrouve toujours avec les mêmes soucis: des éléments graphiques dans mes classes, et si je fais une classe Game, qui gère le jeu de manière globale (score, etc), j’ai l’impression de transférer tout le code du GameScene vers ma classe Game, ce qui, au final, n’a plus de sens...
Bref, j’ai des soucis de structure...
Est-ce que vous avez des conseils à me donner ? Une manière de faire peut-être ?
Je suis preneur de tous vos conseils 🙂
Un grand merci,
Bonne soirée,
Alexandre
Je suis actuellement occupé de tester SpriteKit pour créer des jeux mobiles, mais je me pose une question à laquelle je ne trouve pas de réponses.
Comment organiser mes différents fichiers et mon code ?
Je m’explique:
Pour le moment, dans tous les tutos que j’ai suivi, ils mettaient tout leur code dans un seul fichier (le GameScene), mais donc, la taille du code grandit rapidement, et je ne trouve pas cela maintenable dans le temps, surtout pour des plus gros projets.
J’ai essayé de faire du MVC, mais je me retrouve toujours avec les mêmes soucis: des éléments graphiques dans mes classes, et si je fais une classe Game, qui gère le jeu de manière globale (score, etc), j’ai l’impression de transférer tout le code du GameScene vers ma classe Game, ce qui, au final, n’a plus de sens...
Bref, j’ai des soucis de structure...
Est-ce que vous avez des conseils à me donner ? Une manière de faire peut-être ?
Je suis preneur de tous vos conseils 🙂
Un grand merci,
Bonne soirée,
Alexandre
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je ne sais pas de quels tutos tu parles exactement, mais oui, en général le principe du tutoriel est d'expliquer un concept, une approche, et donc ce n'est pas trop grave si tout est dans le même fichier sachant que c'est en général un truc assez court.
Je ne connais pas ton expérience, mais regarde déjà si tu n'a pas des sous-classes que tu pourrais mettre dans d'autres fichiers, ou juste des classes à créer. Par exemple, éviter d'utiliser toujours des dictionnaires, créer des enums pour les bit masks, etc.
Regarder si tu ne peux pas séparer ton gros fichiers par fonctionnalités, soit via une extension qui se charge du delegate de tel type, etc.
Tu peux commencer par le faire au sein même du fichier, c'est ce que je fais en général : je regroupe les trucs qui vont ensemble ou qui logiquement vont ensembles, et après je regarde comment scinder ça.
Dernier point :
MVC ou MVVM c'est bien, mais comme toute méthode, il ne faut pas forcément l'appliquer à la règle.
Cela ne sert à rien à se retrouver parfois à créer 56 fichiers pour 3 lignes juste pour le plaisir d'avoir tout bien séparer. Mais c'est l'expérience et la connaissance du produit (et de ses futures évolutions) qui prévalent là-dedans, savoir si on met ces 4 lignes ailleurs parce qu'elles risquent de grossir à un moment donné ou non.
A mon avis, tu penses trop "lignes de code" et pas assez "programmation objet". Tu devrais essayer de considérer ta classe Game comme une "communauté d'objets interagissant les uns avec les autres".
C'est difficile d'expliquer cela sans exemple, aussi je vais parler de .. cuisine ! La préparation d'une omelette est une longue série d'opérations a exécuter séquentiellement.
Acheter les oeufs
stocker les oeufs au frigo
Acheter du piment et du gingembre en poudre (ouais, j'en met dans mes omelettes)
Laver les instruments de cuisine après les avoir achetés
Huiler la poêle avant sa première utilisation (c'est expliqué sur la notice d'utilisation)
Casser les oeufs dans le bol (sans en mettre la moitié par terre)
C'est compliqué de faire une omelette, pourtant l'un des plats de base de la cuisine de survie. Si on devais coder tout ça, le viewControler ou la classe Game serait interminablement long.
Pour s'en sortir il faut penser "Objets".
Toute la complexité des opérations d'achats peut se trouver encapsulé dans un objet Acheteur. Il sait comment se procurer les ingrédients et les ustensile de cuisine par simple demande. Tu le crée au début de ton application pour l'utiliser quand c'est nécessaire.
La gestion du dosage des ingrédients peut se faire avec un objet Dosages (quelles quantités de sel, de poivre, de piment et gingembre pour 4 oeufs, 6 oeufs, 12 oeufs ?).
Le "cassage" des oeufs peut se faire avec un objet CasseurOeufs, encapsulant toute la subtilité nécessaire pour ne pas tomber la moitié par terre.
Le mélange des oeufs avec un objet Fouettage, la cuisson avec un objet Cuiseur, etc ..
Avec ce système, la classe principale de ton jeu est beaucoup plus courte. Elle s'occupe essentiellement de créer les objets, d'établir des liens entre eux et de les avertir qu'il vient de passer quelque chose.
Merci pour vos réponses
Je vais essayer de repenser le fonctionnement de mon jeu et voir comment je peux séparer les différentes tâches de manière à les regrouper par fonctionnalités.
Je vous tiens au jus si il y a certains trucs plus particulier que je n'arrive pas à gérer
Un grand merci,
Alexandre
Draken, je l'adore. Amusant mais, en même temps pertinent
C'est rien, ça.. Quand je suis en forme, j'explique la programmation objet en détaillant la manière de préparer les sushis. 🍣
Je m'essayes également sur SpriteKit depuis plusieurs mois également (à titre perso pour le fun et ma culture) mais je remarque comme toi que contrairement à une application utilitaire c'est plus compliqué d'architecturer le code, probablement car mes connaissances sur le sujet restent limitées.
Depuis, j'ai acquis plus d'expériences avec SpriteKit et je suis en mesure de trouver plus facilement une structure à mon code (malheureusement j'ai beaucoup de code maintenant donc c'est long à refactoring)
Je pense donc que l'architecture pour un jeu est bien plus unique et complexe qu'une application utilitaire à même échelle et c'est pourquoi Apple apporte des outils qui aident à mieux architecturer notre code. Je peux citer GamePlayKit qui groupe un ensemble de méthodes tel que Entity Component, Rules, State Machine (que j'ai d'ailleurs ré-implémenter dans une application classique et ça fait son effet !) et autres.
Il faut se tourner sur ces outils si ils répondent à tes besoins et essayer d'avoir une vision globale de ce que tu souhaite faire comme jeu ce qui selon moi est toujours le plus complexe mais aussi le plus passionnant à faire quand on développe.
J'espère avoir un jeu en 2019 à présenter à @Draken où il n'y aura pas masse de bugs
Hello @Magiic,
Merci pour ta réponse, je vais jeter un oeil à ces outils (GamePlayKit, etc).
Si tu sais m'en dire plus sur ce genre de choses, je suis ultra preneur :-)
Merci,
Bonne journée,