Journal des développeurs #9 - Janvier 2023

Discussion dans 'Annonces' créé par Amras Anárion, 15 Janvier 2023.

  1. Amras Anárion

    Amras Anárion Roi Mythique Membre du personnel Team Phoenix

    Entrée 9

    Trois mois se sont écoulées depuis la dernières entrée. Cela est due à un ralentissement du développement, lui-même dus à plusieurs facteurs. Mais telles les vagues de l’océan, l’avancée se fait par pulsations : peu d’avancée jusqu’à la mi-décembre, mais c’est reparti après avec une grande avancée sur le codage ! Ça sera du coup le thème de ce neuvième journal !


    Des ambitions de codage pharaoniques

    Vers la mi-septembre, je me suis lancé dans un immense chantier : refaire de zéro la base de données de toutes les capacités Pokémon. Cette étape était indispensable si je voulais pouvoir implémenter des nouvelles données (celle native à PSDK ne me le permettant pas). C’était aussi l’occasion parfaite pour rajouter toutes les attaques ajoutées par Sacred Phoenix, jamais codées à part une poignée de type Obscur.

    Avant tout codage, il me fallait d’abord établir le Game design qui gravite autour des attaques Pokémon et me poser toutes les questions adéquates :
    – Comment définir une attaque et sous quel format ?
    – Quelle sont les catégories, types, et effets secondaires possibles ?
    – Vu que j’ai subdivisé en 3 sous-catégories les attaques de Statut (Buff, Débuff et Terrain), lesquelles seront de telle sous-catégorie ?
    – Combien de méthodes faudra-t-il pour définir l’ensemble des capacités existantes ?
    – Quelles sont les portées d’attaque possibles ?
    – Quels sont les tags que je vais utiliser ainsi que leurs effets ?
    – Pour les données rajoutées (Mana, Souffle, dégâts élémentaires sur le terrain…), quelles valeurs attribuer ?
    – Et bien entendu, quels rééquilibrages et modifications apporter à tout ce beau monde ? …chose déjà commencée depuis 3 ans ! Une occasion parfaite pour jeter un œil critique sur l’intégralité des capacités existantes et réviser celles qui ont en besoin, tout en établissant des changements harmonisés vis-à-vis de mes propres mécaniques.

    Ceci sera fait au format Word (et non Excel), car ça me permet une mise en page plus évoluée et l’utilisation d’un code couleur pour marquer mes changements comparés aux mécanismes vanilla de Pokémon :
    – Rouge = capacité dexitée
    – Rouge foncé = élément nerfé
    – Bleu = modification sans impact significatif sur la puissance
    – Vert = élément amélioré
    C’est au final une moitié de toutes les capacités qui seront rééquilibrées. Cela peut aller d’un changement mineur (comme une puissance très légèrement ajustée) à une révision plus profonde en y intégrant par exemple mes Fields Effects (mais ceci est un autre sujet !).

    Le second intérêt majeur d’avoir une telle liste, classée par type puis catégorie, est qu’elle m’offre une vue propre et organisée sur toutes les capacités existantes. Cela m’est d’une grande aide pour établir le movepool de mes Fakemons (ou réviser ceux des créatures déjà existantes), car la liste officielle établie par date d’ajout (et donc par génération) possède un agencement clairement aléatoire… sans compter que ça ne référence pas mes nouvelles attaques, ni n’exclut celles que j’ai décidé de dexiter (environ 160 sur les 900 officielles existantes).


    Un extrait des attaques de type ombre : certaines sont nouvelles, d'autres ont été équilibrées.​


    De l’Idéal à la Réalité

    Reste à concrétiser toutes ces idées par écrit. Je commence donc par établir la liste des attaques et toutes les caractéristiques qui seront appelées par le code (type, puissance, précision, liste des tags…)
    Je m’y lance début octobre et j’arrive à maintenir un rythme de croisière en référençant 40 nouvelle capacités par jour. Mais arrivé vers celles de 4ème génération, ma motivation commence à flancher. Fin octobre, j’étais à 400 attaques référencées ; puis je stagnerai autour de 500-600 jusqu’à début décembre, n’en rajoutant que 10 ou 20 les rares jours où j’avais du courage.

    Autour du 10 décembre a été un point de basculement : Eysselia a pris les devant et a décidé de me mettre une date butoir pour finir cette satanée liste de capacités. Même si la deadline en elle-même n’a pas été respectée (j’aurais fini le game design document avec 3 jours de retard), ça m’a permis de mettre le turbo et de terminer les 300 capacités manquantes en 10 jours, m’offrant même le luxe d’inclure les toutes nouvelles attaques de la 9G !

    Mais fallait-il encore transformer le game design en code concret ! C’est parti pour une longue session de copier-coller du Word vers le script Ruby en abusant du [Ctrl] + [H] et des regex pour semi-automatiser au mieux la mise en forme ! Il ne fallait pas oublier la création des méthodes pour extraire les données désirées puis tester le code pour faire la chasse aux bugs. (Une migration de Class est très délicate à gérer !) Ceci m’aura pris une dizaine de jours supplémentaires.


    La mise en pratique dans le code. La majorité des flags sont gérés par des listes indépendantes.​


    Quand les Field Effects s’invitent à la fête…

    Aujourd’hui, cet étape-clé est quasiment terminé. Je dois juste vérifier que les méthodes d’attaques (le “FunctionCode” dans le jargon d’Essentials) – intégralement renommées – sont toutes existantes dans le nouveau code. Et c’est là où je me suis rendu compte que des mécaniques vanilla n’ont jamais été codées dans le jeu, alors que certaines d’entre elles datent de la 6G.
    Je suis donc reparti pour un tour avec un autre chantier tout aussi important et prévu dans mes Idéaux depuis la naissance du fangame : les Field Effects. Par chance, le game design sur cette fonctionnalité a été écrit en grande partie durant le mois d’octobre, lorsque ma motivation vacillait pour le référencement des capacités. Je n’aurais donc pas perdu mon temps et possède déjà une base sur laquelle commencer mon codage !
    Temps estimé pour coder cette fonctionnalité et atteindre cet objectif supplémentaire : 15 jours.


    Les autres chantiers de codages

    Une fois cet Idéal majeur devenu Réalité, il faudra que je reprenne mes objectifs principaux délaissés au mois de septembre, à savoir coder le système d’artisanat (oui, encore du codage !) et terminer le scénario, l’Event-Making et le mapping de la seconde ville du jeu.
    Il ne faut pas oublier que je suis la seule personne ayant des compétences de codages dans l’équipe. Toutes ces tâches reposent uniquement sur mes épaules, ce qui fait incontestablement de la programmation le goulot d’étranglement du projet.
    Au moins, je me dis que tout le code est déjà prêt et facilitera significativement ma migration sur un autre moteur de jeu tel que Godot ou Essentials. Les données brutes sont déjà formatées, je n’aurais juste à créer les méthodes pour que le jeu utilise les miennes et non celles natives au framework.


    Un mot sur la compatibilité des sauvegardes

    Un changement aussi profond sur la structure des données rend malheureusement incompatible les anciennes sauvegardes, car il y a trop de conflits à résoudre. De plus, coder des « rustines de compatibilité » nuit significativement à la lisibilité du code et au performances du jeu (surtout lorsque ce soit des routines appelées en combat).
    J’ai donc profité de cette remise à zéro pour supprimer toutes les lignes de code qui sont dédiées à de la compatibilité d’anciennes sauvegardes. C’est aussi l’occasion rêvée pour modifier la structure des données des Pokémons. Celle-ci allant se gonfler d’une centaine de nouvelles données (je prévois de gérer un large historique des actions et haut-faits de vos créatures magiques), il est important de couper les branches mortes et de tailler celles trop épaisses. J’espère juste avoir le temps de restructurer tout ce que je veux sur les Pokémons pour qu’il n’y ait plus de futures incompatibilités de sauvegardes (du moins, tant que je resterai sur PSDK).

    Une chose est sûre : on quitte officiellement le cycle “Roots of Yggdrasil” pour se diriger vers “The Branches of Knowledge”, cycle qui se caractérise par des changements significatifs sur les bases de données. La prochaine mise à jour sera donc une 0.4 !


    Le naufrage de Deviantart

    Impossible de ne pas aborder ceci dans notre journal sachant que ça été une des causes de démotivation des dernières semaines.
    Deviantart et sa nouvelle politique “anti-NSFW” aveuglément confiée à une intelligence artificielle a causé une perte significative de visibilité au projet (de 40 à 80% de vues en moins !), et par effet ricochet une perte de moral sur l’équipe. En effet, notre compte Deviantart représentait à lui seul plus de 50% de la visibilité publique de Sacred Phoenix. Ça fait mal au cœur de voir certaines des images de notre portfolio se faire shadow-ban et barrer d’un gros « contenu mature » pour les utilisateurs non enregistrés (autant dire 80% de nos vues), car un robot en a décidé ainsi, alors que notre fangame n’a jamais publié d’œuvre artistique mature.
    Nous sommes donc partis à la recherche d’alternatives et avons décidé de promouvoir Sacred Phoenix en anglais sur deux nouveaux réseaux sociaux : Instagram et Tumblr (en plus de Twitter où la communication est faite en français). Cela évitera d’avoir tous nos œufs dans le même panier.

    C’est aussi l’occasion d’améliorer notre communication en faisant plus de qualité et moins de quantité, à l’instar de ce que je faisais déjà sur PokéCommunity et Relic Castle. Avant, les images brutes étaient publiées une à une sur Deviantart. Aujourd’hui, notre art est révélé avec les couleurs du projet. Ça fait tout de suite plus professionnel.