Devlog #3 : Abyss Dungeon – Sauvegarde, interface et… galère?!

Salut à tous, voici enfin le 3ème Devlog sur mon Metroidvania en Haxe.

La dernière fois je vous ai décortiquer comment j’ai codé le premier boss du jeu : Devlog précédent

Et cette fois-ci on va parler du système de sauvegarde et de mes ajouts par rapport à la dernière fois (menu, écran pause, équipement, inventaire).

Allez, c’est parti!

Commençons par les sauvegardes :

Comment le dire plus simplement que : ça à été une galère monumentale d’instaurer cette f**tu sauvegarde (Rhaaa!).

Comme je l’avais déjà expliqué, ce jeu est composé de plusieurs tilemaps interconnectées, ce qui signifie qu’à chaque fois que le héros sors d’un des bords de cette tilemap, on fais générer la suivante (celle qui est supposé être la suite logique par rapport à la map précédente).

Le problème intervient donc ici, ce que je fais dans le code, c’est recharger la state (Game) à chaque fois qu’il sort d’un bord de l’écran, la state en question se charge ensuite toute seule de générer la bonne map car j’ai mis des variables globales qui permettent de savoir avec précision le lieu dans lequel est le héros (ainsi que sa position précédente).

Mais si je recharge la state, ça veut aussi dire que je charge un nouveau hero (new Hero() donc). Et si je fais ça, ça va réinitialiser ses stats (c’est à dire PV au max, MP au max, etc…) mais je ne veux pas de ça justement, il faut qu’il conserve les mêmes statistiques qu’il avait lors de la map précédente. (Si il se prend des dégâts et qu’il change de map, il doit avoir des PV réduit dans la map suivante et non pas revenir à son plein potentiel)

C’est ainsi qu’après des heures de galères, la solution que j’ai trouvé était de mettre toutes les statistiques de mon personnage dans un .JSON! (J’avais rapidement évoqué ça dans le devlog précédent également)

Alors là pour le coup, j’en ai bouffé de l’écriture/lecture dans un fichier. C’est quelque chose que je n’aimais pas faire à là base car j’y comprenais pas grand chose, et bien maintenant… je n’aime toujours pas, mais c’est parce que j’en ai trop fait (Au moins j’ai finalement compris!) 🙂

Vous pensiez que c’était fini ? Haha… ce n’était que le début.

Maintenant que mon personnage conserve ses statistiques lorsqu’il change de map, un nouveau problème est arrivé. En effet, si le héros récupère une relique par exemple (je parle des reliques dans le devlog précédent), et qu’il ferme le jeu, lorsqu’il va redémarrer le jeu, la relique sera en sa possession alors que dans Castlevania (le jeu qui me sert de modèle), on ne sauvegarde son inventaire/équipement uniquement lorsqu’il atteint une salle de sauvegarde.

Je vous épargne les jours et les jours de galère (punaise c’était vachement dur, je n’aurais pas cru, je suis essoufflé rien que d’en parler :p), voici finalement la solution :

Je devais créer 2 fichiers de sauvegarde .JSON, un que j’ai nommé heroTemporary.json et l’autre heroFull.json. Vous l’avez compris, il y en a un qui va stocker les données temporaires du héros (utile pour conserver ses données lorsqu’il change de zone) mais si le joueur quitte le jeu sans faire de sauvegarde totale, ce qu’il aura acquis ne sera pas conserver (c’est ça que je voulais!). Le heroFull.json sert donc à transvaser toutes les données temporaires en données complète, cette action est effectué si le joueur à atteint une véritable zone de sauvegarde (reconnaissable par un feu de camp sur la map).

Point de sauvegarde

Oh et bien évidement le jeu est jouable avec une manette aussi, et lorsqu’on atteint un point de sauvegarde, l’icône affichée sera la bonne en fonction de « si une manette est branchée ou non ».

Manette / Clavier

Je ne sais pas si j’ai été bien clair dans mon explication sur toute cette partie, j’ai vraiment essayé de faire au plus simple (du moins de mon point de vue).

 

Passons donc à autre chose, l’écran de pause :

 

Le joueur peut se mettre en pause à tout moment en appuyant sur ENTRER ou START selon si vous utilisez une manette ou non.
Comme dans Castlevania, ceci va ouvrir en réalité le menu ou le joueur pourra effectuer toutes les actions importantes comme changer d’équipement, utiliser un objet, voir ses reliques et ses statistiques ou revenir à l’écran titre.
Bien entendu, lorsque le menu est ouvert, le jeu en arrière-plan est figé et reprendra bien ou on en était une fois le menu quitté.

Ecran Pause

Vous voyez il y a beaucoup d’actions possible dans ce menu et à l’heure actuelle je n’ai toujours pas terminé de tout implémenter : Il y a uniquement la partie équipement qui fonctionne à 50%. En effet, je peux changer d’équipement visuellement seulement, ça n’affecte pas encore ses statistiques et son inventaire n’est même pas sauvegardé! (Ce sont juste des objets que j’ai mis de force en random pour pouvoir effectuer mes tests). Et en + c’est pas beau…

Section Equipement

C’est une partie que je trouve un peu ennuyante à mon gout (moi ce que je préfère c’est de coder du gameplay!, je m’éclate beaucoup plus à faire bouger, attaquer, exploser des trucs à l’écran :D) et c’est ce qui me retarde beaucoup sur ma progression car c’est vraiment quelque chose que je n’aime pas faire! Et pire encore je ne sais pas encore comment bien gérer l’inventaire, j’ai essayé de bricoler quelque chose, mais je pense faire un petit détour sur l’atelier inventaire en C# avant de reprendre cette partie.

On arrive donc au terme de ce 3ème devlog à propos de Abyss Dungeon, je vais vous laisser sur une petite vidéo où je vous montre rapidement l’écran titre du jeu fonctionnel que j’ai codé entre deux galères du système de sauvegarde ^^

(oh et j’ai fais toutes les musiques du jeu aussi cela dit en passant, c’est une deuxième branche que j’aimerais bien avoir à côté de la partie programmation) 🙂

Merci de m’avoir lu jusqu’ici (et de m’avoir écouter me plaindre de mes galères de développement)!

je veux être honnête jusqu’au bout et ne pas faire croire que tout est beau et merveilleux et parfait lorsque je code ce jeu, je me plante très régulièrement, et ce coup-ci j’ai vraiment eu beaucoup de mal sur certains aspects, mais je sens que je progresse en surmontant toutes ces difficultés, et c’est le principal je présume (et ça ne m’empêche pas de toujours aimer ce que je fais)!

Je vous dire à très vite pour le prochain devlog, bon code à tous! 🙂

15 réflexions au sujet de “Devlog #3 : Abyss Dungeon – Sauvegarde, interface et… galère?!”

  1. J’ai encore pas mal de boulot à faire avant de pouvoir enfin offrir une version jouable et je veux vraiment qu’il y a de la matière à jouer avant de montrer une démo du jeu 🙂

  2. Merci beaucoup! Et oui la question avait déjà été posée, mais je le redis encore, si j’ai pu m’améliorer dans la programmation de manière générale, c’est à 80% des enseignements de Gamecodeur que j’ai réussi à appliquer en dehors des jeux-vidéo (notamment pour mes cours à la fac, je parle de la méthodologie, de l’esprit de raisonnement etc).

    Bien sur vous pouvez en reparler, ça me fait vraiment plaisir, Merci! 🙂

  3. Terrible !!! ça me tarde de tester !

    Petite question bête : Y a t il une raison particulière pour avoir choisi Haxe ?
    (car je me pose des questions Haxe vs Monogame)

  4. Merci beaucoup ça fait plaisir!

    Ce n’est absolument pas une question bête, j’ai choisi Haxe (et Haxeflixel) tout simplement pour pouvoir aller + vite sur certains aspects. Haxeflixel est un moteur extrêmement complet qui mâche très souvent une grosse partie du travail (comme la gestion de caméra, d’animations, scènes, et j’en passe). J’avais une idée précise du jeu que je voulais faire et d’autant plus que je suis très à l’aise avec lui et qu’il n’est pas très connu, je me suis dit « Allez sortons de l’ordinaire, faisons-le en Haxe! »

    Mais Haxeflixel VS MonoGame je ne sais même pas si c’est débattable en réalité. Monogame nous laisse vraiment plus de liberté car c’est à nous de tout coder entièrement, et cette liberté est juste incroyable car on à la main sur 100% de notre code tandis que de l’autre côté avec Haxeflixel, il possède déjà énormément de choses inclus qui peuvent nous faire gagner pas mal de temps mais nous rend un peu « utilisateur d’outil » plutôt que « concepteur » de ces outils. Personnellement je ne me casse pas la tête à vouloir réutiliser absolument tout ce que Haxeflixel propose, je me sert du strict minimum (scène, caméra et animations notamment), et pour les autres choses (particules etc) je le fais moi même, ce qui fais qu’au final j’ai toujours la main sur quasiment tout mon code.

    Si je peux donner un petit conseil malgré ma maigre expérience dans le domaine, j’incite vraiment tout le monde à commencer avec Monogame pour, au moins, apprendre la conception objet grâce au C#, créer ses propres outils, apprendre à savoir tout faire seul, et uniquement après cela, aller essayer Haxeflixel car cela enlèvera le doute sur le « Comment ça marche ce truc là », et si jamais on n’arrive pas à « utiliser » un des outil de Haxeflixel, on peut toujours le « créer » !

    C’est une grosse réponse que je t’ai apporté, je n’ai pas non plus la science infuse, loin de là, c’est avant tout mon point de vue personnel, je ne sais pas si d’autres personnes pensent comme moi, mais étant donné que j’ai déjà mener à terme 1 projet dans chacun de ces 2 framework, je pense pouvoir apporter mon petit grain de sel. J’espère que tu as obtenu la réponse que tu attendais 🙂

  5. Merci pour la réponse 🙂

    En fait je me posais cette question par rapport à la finalité d’un jeux.

    Si j’ai bien compris, avec Haxe on compile en natif à la fin alors que ce n’est pas le cas de c# sur windows en tout cas car il faut le framework .net (je n’ai pas encore vu ce que ça donnait avec Xamarin pour mac et pour une compilation sur console ps4/switch). Ce qui pourrait (je pense) amener à une différence de performance.
    En ce qui concerne les outils, c’est pas forcement la chose que je regarde car pour le coup, ce qui existe sur Haxeflixel pourrait être refait en c# si ce n’est pas déjà le cas.

    J’avais en têtre de m’atteler à un « gros projet » une fois que je serai plus à l’aise : un brawler inspiré de TowerFall avec du multi en ligne et crossplatform

    Mais je m’égare… Encore une fois bravo et si à un moment tu cherches des testeurs, y a pas de problèmes.

    Bonne continuation

  6. Ton gros projet semble palpitant, j’espère que tu nous partageras ton retour via des devlogs une fois que tu seras prêt!
    Merci encore de ton retour ça fait plaisir, c’est noté (pour être testeur !)

  7. Salut Hydrogne.
    Je découvre ton projet (je ne viens pas très souvent !!) et c’est juste bluffant.
    Je vois que tu deviens un pro de haxe. Ton jeu à l’air bien sympathique avec déjà une bonne ambiance.
    Je vais suivre ça de près.

    Bonne continuation

  8. Salut Stormbringer!

    Merci beaucoup pour ton commentaire, ça fait très plaisir et c’est motivant !
    Efectivement, Haxeflixel n’a quasiment plus aucun secrets pour moi haha ^^

    Merci encore.

Laisser un commentaire

Dialoguez avec les autres membres de la gamecodeur school.

Accédez maintenant à notre serveur Discord privé : Entraide, Game Jams, Partage de projets, etc.

Vous devez être membre de la Gamecodeur School Premium pour être autorisé à accéder au serveur.