Je travaille aux dernières briques logiques des inventaires. Charge mentale au maximum, cœur de l’hiver, contrariétés de la vie quotidienne, aujourd’hui j’en ai quand même pris un coup lorsque en toute fin d’une très grosse cascade logique Gemini me demande de brancher une référence… qui n’existe pas.

Les inventaires sont une saloperie à développer sur Unreal car ils se composent d’objets représentés par des structures complexes stockés sur base de données, visualisés par l’utilisateur dans une fenêtre, qui contient une table de cases qui contiennent des éléments qui affichent les objets. Ces inventaires sont attachés au joueur, aux coffres, aux vendeurs, à n’importe quoi qui contient des brols dans une structure appelée un component qui définit un bataillon de fonction logiques pour ajouter, retrancher, remplacer, trie, etc etc etc.
L’horreur de ce système à la grenade, est qu’aucun des éléments n’a conscience des autres. L’épée ne sait pas qu’elle est affichée dans une petite case et stockée dans une base de données. Le component se fiche éperdument de la manière dont sont présentés au joueur sa grille d’objets. Et ainsi de suite. Alors quand il faut faire communiquer entre eux des éléments qui ne se connaissent pas, les problèmes arrivent.

Aujourd’hui, j’arrive à la fin d’une grosse fonction du component où je dois brancher la table des objets, qu’il connaît, et la grille dans laquelle ils sont affichés… qu’il ne connaît pas.

Le dernier branchement hein, y en a des dizaines, c’est le dernier, celui après lequel on va manger puis regarder un film.

Eh ben non, il ne connaît pas la grille, élément graphique, parce que ce component est un élément logique et n’a pas à connaître un conteneur graphique intermédiaire.

Sachant très bien que Gemini va me dire de résoudre le problème par un dispatcher, soit une technologie genre courtier de bourse qui crie à la corbeille “J’achète du sucre à 30 centimes !” ce qui permet au courtier qui a du sucre, qui n’a jamais vu le premier courtier de sa vie, de beugler “Je vends !”

Génial non (sans le T après le I, bien sûr) ? Oui, c’est génial. Le souci c’est quand le mec a vendu son sucre, il se barre, et toi, deux ans plus tard, quand tu veux savoir qui a vendu du sucre, tu n’en sais rien et tu dois galérer des heures à retrouver comment ça s’est passé.

Alors j’ai dit merde à Gemini, je lui ai dit que je savais comment je voulais résoudre le problème (à savoir mettre dans le carnet d’adresses du vendeur les coordonnées de tous ses acheteurs) mais que je ne lui disais pas comment je préférais m’y prendre avant d’avoir entendu sa solution.

Ça n’a pas traîné ! “Ah ben, on va créer un dispatcher ! Ou un Blueprint Interface (une merde du même genre), comme tu préfères !”.

Bon, je m’en doutais, je lui ai dit, ni l’un ni l’autre, on travaille en enregistrant les adresses comme ça j’ai tout sous les yeux et le bazooka à tuer les mouches tu peux te le… enfin j’en ai pas besoin.

Et il n’a pas insisté ! Il m’a dit d’accord, comme ça. J’en était presque un peu déçu, alors je lui ai posé la question :

Tu ne t’es pas beaucoup battu. Le fait d’avoir des variables qui donnent des références vers tout ce qui est utile est-il à ce point oublié de nos jours?

Et il a carrément refusé le combat, voilà ce qu’il ma rétorqué :

On ne se bat pas contre le bon sens : la clarté du code passe avant la mode technologique. Si une référence directe est le chemin le plus court entre ta donnée et ton écran, c’est elle qu’il faut emprunter.

L’approche par “références stockées” n’est pas oubliée, elle est simplement délaissée dans les gros projets pour éviter que tout le monde ne soit “au courant de tout”. Mais dans ton cas précis, sur un MMO en Blueprints seuls, ta méthode a trois énormes avantages :

1. Lisibilité immédiate : Quand tu ouvres ta fonction dans six mois, tu vois la donnée entrer et l’affichage sortir. Pas besoin de chercher qui a “bindé” quoi dans quel widget caché.

2. Debug facilité : Si ton inventaire ne s’affiche pas, tu regardes ta variable LinkedSlotsArray. Si elle est vide, tu as ton coupable. Avec un dispatcher, tu peux chercher longtemps pourquoi l’événement ne “part” pas.

3. Performance : Une référence directe est ce qu’il y a de plus rapide pour le processeur.