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

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.

  • DrakenDraken Membre
    août 2018 modifié #3

    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

      • aller au supermarché
      • aller au rayon oeufs et laits
      • choisir les oeufs
      • mettre les oeufs dans le sac
      • aller à la caisse
      • dire bonjours à la caissière
      • sortir les achats du sac pour les poser sur le tapis
      • utiliser une carte bleue pour payer
      • remettre les oeufs dans le sac
      • revenir à la cuisine (pas forcément le plus simple)
      • stocker les oeufs au frigo

        • Acheter l'huile (même procédure que les oeufs)
        • Acheter une poêle (tout aussi compliqué - attention à bien l'assortir à la plaque de cuisson, ne pas utiliser d'aluminium sur une plaque à induction)
        • Acheter une spatule
        • Acheter une fourchette
        • Acheter un bol
        • Acheter un fouet de cuisine (pour battre les oeufs)
        • Acheter une assiette
        • Acheter du poivre et du sel
        • 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)

        • ajouter du poivre, du sel, une pincée de gingembre et du piment (dans quelles quantités ?)
        • battre les oeufs avec le fouet (combien de temps ?)
        • Sortir la poêle
        • Poser la poêle sur la plaque de cuisson
        • Faire chauffer la poêle (à quel réglage et combien de temps ?)
        • Verser de l'huile (quelle quantité ?)
        • Attendre un peu (combien de temps ?)
        • Verser les oeufs dans la poêle
        • Attendre quelques minutes que la cuisson commence (comment le détecter ?)
        • Utiliser une spatule pour décoller le fond de l'omelette de la poêle (combien de temps ?)
        • A mi-cuisson (comment le savoir ?) utiliser la spatule pour retourner l'omelette.
        • Etc ...

    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 :smile:
    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 :smile:

    Un grand merci,

    Alexandre

  • Joanna CarterJoanna Carter Membre, Modérateur

    @Draken a dit :
    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

    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.

    Draken, je l'adore. Amusant mais, en même temps pertinent :)

  • DrakenDraken Membre
    août 2018 modifié #6

    @Joanna Carter a dit :
    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 :D

  • 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,

Connectez-vous ou Inscrivez-vous pour répondre.