Première fois depuis bien longtemps que je n’ouvre pas le projet, aujourd’hui, j’espérais jouer à WoW avec mon fils après être allés tirer en famille et puis nous avons finalement vaqué à nos occupations.

J’ai commencé à utiliser Trello, pour l’instant en privé, je rendrai le board public plus tard.

Demain j’attaque le menu des options : raccourcis clavier et résolution d’écran.

Je ne m’attendais pas à ramer autant : quelle galère !
Je suis tombé sur un bug assez incroyable : le controller aurait dû faire référence à deux data tables, une pour les skills de type UO, ceux qui montent avec la pratique et permettent de construire un perso unique, et une autre pour les skills liés au GAS. Le souci c’est que ces deux tables sont des tables de skills et quand j’ai dû ajouter la deuxième table de skills au controller, j’ai vu la première… et je me suis dit qu’en ajouter une ferait double emploi. Et je n’ai rien ajouté du tout.
Conséquence : quand j’initialisais correctement les skills de type UO, je n’avais plus les skills de type GAS, et inversement. Le temps que je me rende compte de l’erreur, j’avais déjà bien pesté, mais, toute chose étant égale par ailleurs, quelques heures ce n’est pas grand-chose comparées aux semaines perdues à la grande époque où j’étais développeur officiel Apple et devais démêler leurs bugs en plus des miens !

C’est vrai que je suis un peu givré de vouloir reproduire dans un seul jeu deux systèmes aussi éloignés que ceux d’UO et de WoW, mais c’est fait.

Je vais probablement enchaîner sur l’écran des options, il faudra bien le faire un jour !

J’ai progressé dans le travail sur le gain de skills par la pratique mais j’ai encore deux problèmes à résoudre : l’appel intempestif à la mise à jour du paperdoll quand l’état d’un skill est modifié et le tableau des skills qui reste à une taille inférieure à la normale après son initialisation par le serveur. Ca tire dans tous les coins entre le client et le serveur, c’est lourd au possible et si je suivais les conseils de l’IA j’aurais très rapidement une soupe inintelligible si je dois revenir au code dans quelques mois, mais en plus une soupe pourrie : la complexité du problème est telle que l’IA marque ses limites. Donc j’y vais à l’ancienne, une bonne journée de travail et ça devrait rentrer dans l’ordre, il n’y a aucun bug rédhibitoire, juste des mauvais enchainements de segments de code qui ne devraient pas intervenir l’un dans l’autre.

On dirait que ça marche, c’était une belle purée car je ne m’étais pas rendu compte que le client avait le droit, tout autant que le serveur, de requérir les données du joueur depuis la base données. Cela ne devrait pas être possible dans un environnement client-serveur car si cela est possible, le client et le serveur ont des versions différentes des données des joueurs ! Je me demande comment je m’en étais sorti jusqu’ici sans avoir d’ennuis, mais là, j’aurai tout eu d’un coup !

Bon, je devrais probablement modifier mon API pour qu’un client n’ait jamais le droit de lire des données dont le serveur est seul à détenir la vérité. Comme j’ai vraiment envie de passer à autre chose, toutes ces difficultés deviennent usantes quand elles s’accumulent, je vais simplement ne rien faire et tâcher de m’en souvenir. Oui, la flemme, mais là c’est dur, neuf mois avec un robot à camper devant deux coffres, ça commence à bien faire !

Prochaine étape : intégrer les mécaniques de gains de skills. Sauter aura une chance d’augmenter la compétence de saut, porter une attaque spéciale une chance d’augmenter la maîtrise de mêlée, etc.

J’espérais boucler les skills assez vite, toute l’interface était terminée, la base de données, le node.js, l’API, l’UI : tout !

Oui, mais voilà, je manquais de précision dans la répartition des tâches entre le character, le player controller, le game instance et le player state. J’avais placé les données du personnage sur le game instance, ce qui m’avait été présenté comme le bon endroit car insensible à la mort du perso et aux changements de carte. Ce qui ne m’avait pas été précisé, c’est que le game instance, par je ne sais quels détours, n’existe qu’en un seul exemplaire sur le serveur et qu’un nouveau joueur qui se connecte écrase forcément les données du précédent. J’ai donc dû transférer les données joueur sur le controller, non sans avoir passé une journée à cuisiner l’IA pour être certain que je faisais le bon choix, avoir dû lire ses contradictions, les lui opposer, recevoir de nouvelles informations, contredites par d’autres sources et après de nombreuses heures épuisantes finalement prendre la décision de rapatrier les données sur le player controller. Un inconvénient : le controller aussi est détruit au changement de map et contrairement au player state ne peut pas être copié avant sa destruction, je suis donc contraint de refaire dans un avenir proche un beginPlay propre pour rechercher les données de la database. Un avantage : le player state ne peut pas faire exécuter du code par le serveur, le controller le peut, donc je gagne des détours.
Tant que j’y étais, j’ai transféré du game instance vers le player controller tout ce qu’il fallait, ça c’est terminé.

J’aurais peut-être pu finir aujourd’hui mais je suis allé de bug en bug pour finalement comprendre (cela a pris 4 minutes 30 à ai.studio pour le déterminer, mais il y est parvenu), que la lecture des infos joueurs se faisaient en local et non par une procédure serveur, ce qui provoquait systématiquement des tables de skills vides car jamais initialisées sur le serveur.

Cela ajouté à des bêtises comme des erreurs d’encodage à la table des skills et j’aurai passé une semaine là-dessus, si seulement j’arrive à terminer demain !

Quand ce sera fini, je ne sais pas trop bien ce que je vais attaquer, d’ailleurs.