Mais bon sang ! Pourquoi je n'y ai pas pensé avant !

 

    Cela fait 20 jours que je n'ai rien posté sur ce blog, cela fait angoisser le chef de projet qui s'affole en voyant les indicateurs dégringoler dans JIRA ! ;) 

    Trève de plaisanterie, le projet avance, comme toujours à son rythme ! Mais tout comme LZamu mon graphiste peut parfois retoucher des écrans déjà terminés car il finit par y voir des petites améliorations, des petits défauts etc, il peut m'arriver aussi de me dire que je dois corriger et améliorer un bout de code pourtant déjà terminé !

    C'est un cauchemar pour les gestionnaires de projets car comment faire des statistiques d'avancement avec des éléments qui passent de la colonne terminés à la colonne à faire, alors que du temps a déjà été passé dessus ! Et c'est exactement ce à quoi je suis en train de réfléchir depuis hier.

    J'avais lors de la conception du moteur, fait le choix de rendre celui-ci extensible. Il s'agissait pour moi, de permettre de rajouter ponctuellement des traitements particuliers propres à un certain tableau, plutôt que de l'intégrer au code du moteur et l'allourdir pour une fonction qui ne servira qu'une fois. Cela m'avait paru utile, mais j'avais considéré que pour cela, il était nécessaire de produire un fichier basic supplémentaire ne contenant par défaut que 2 lignes, pour charger les données du tableaux et déclencher le moteur sur ces nouvelles données. Ce fichier basic pouvait donc ensuite être modifié par le développeur pour ajouter des fonctions supplémentaires sur le tableau (chronomètre pour faire un semblant de QTE, ou déclencher des animations, des sons, des changements de palette...).

    L'idée en soit, n'est pas mauvaise, mais je n'ai pas poussé suffisamment ma réflexion à l'époque. J'avais conclu trop rapidement que la génération de ce fichier basic était nécessaire à chaque fois, même si on ne faisait aucune personnalisation pour ce tableau !

    C'est dommage, car cela génère un fichier de plus par tableau, donc avec 3 fichiers produits par tableau, en comptant la limite de 64 fichiers AMSDOS, on ne pourrait mettre qu'au maximum 21 tableaux par face ! Il y en aurait même moins, étant donné que je vais sur chaque face, dupliquer les fichiers nécessaires à savoir 5 fichiers images au moins et possiblement quelques autres.

    Me passer de ce fichier basic, ferait passer ce maximum théorique à presque une trentaine en tenant compte des 5 fichiers images. Mais j'ai toujours dit, que les disquettes virtuelles ne coutant rien, qu'il ne s'agissait pas pour moi d'un problème. Si le jeu a besoin de six faces de disquettes, il les prendra ! Mais j'ai tout de même trouvé une autre raison de ne plus imposer systématiquement le chargement par chain merge de ce petit fichier basic. C'est le temps de chargement ! J'ai pu voir que ce chain merge ajoutait tout de même un temps non négligeable entre les écrans. Au temps s'en passer quand c'est possible !

    Je dois faire une petite correction sur mon éditeur pour rendre la génération de ce fichier basic désactivée par défaut, et je dois ajouter une donnée de plus dans mes fichiers produit pour indiquer s'il faut charger ou pas un fichier basic customisé. Le générateur produira toujours un fichier basic de deux lignes comme avant qui sera le point de départ pour la personnalisation. Il sera même vraisemblablement plus court, vu que les données qu'il était censé faire charger, le sont déjà. 

    Cela implique donc aussi quelques modifications du moteur, pour gérer cette mise à jour du format des fichiers de données. Donc bon, le projet avance, même si on retouche certaines choses déjà faites...

    De son coté, LZamu termine la dernière image du premier arc du scénario de 13 tableaux. Il a déjà terminé deux images sur l'arc suivant, donc cela avance malgré tout et le projet peut bien se payer ce luxe de cette évolution. Dans le monde professionnel, on parle parfois de dette technique. C'est une notion très intéressante permettant justement d'expliquer aux gestionnaires de projet, l'intérêt de justement corriger, améliorer, réécrire du code pourtant déjà terminé. Les entreprises et les administrations gérant de vieux programmes en COBOL datant d'il y a 40 ans, sont souvent confrontées à ce genre de problèmes.

    Et même si mon jeu, n'est pas forcément appelé à être maintenu pendant des années, le fait d'avoir un moteur plus propre et plus performant reste un investissement dès plus utiles.