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).

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 ».

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é.

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…

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! 🙂