What's next ?

Bon, et maintenant ?

Tout d'abord, il ne faut pas se leurrer : la version actuelle est loin d'être satisfaisante, et mérite à peine le titre de "Release Alpha".
Certes, il est possible de gagner en mode "facile", mais pas en mode "normal". De plus, même en brigand, il reste des options avancées, certes peu fréquentes, mais qui n'ont pas été re-travaillées, et qui sont donc potentiellement (sûrement même) bugguées.
Le travail "de base" de déboggage n'est donc pas terminé.

Pourtant je souhaiterais présenter dans ce billet les idées qui me trottent dans la tête pour la suite. Ce sont des projets long termes, et aucun d'entre eux n'est garanti d'être exécuté. Je les trouve intéressants à aborder, ne serait-ce que pour concrétiser quelques concepts intéressants et compliqués (du moins pour moi).

La première idée, et de loin, c'est de disposer d'une carte graphique, permettant de représenter le monde dans lequel le joueur évolue. C'est un "must", souhaité depuis le premier jour, et jamais réalisé, par manque de talent en programmation. Il suffit de constater le niveau anémique des animations des scènes de combat pour comprendre l'énorme écart qui me sépare d'une réalisation potable. C'est par crainte d'un résultat lourd, ultra-lent (au point d'être inutilisable) et super-moche que je n'ai jamais commencé.
Seulement voilà, mon niveau s'améliore, au point même de manier aujourd'hui des concepts dont je ne soupçonnais meme pas l'existence à l'époque. Il se pourrait donc que, à un moment, cette idée devienne réalité. Cela reste toutefois un projet long termes, à travailler calmement.

La seconde idée, ce sont les performances. Certes, sur un émulateur et un PC récent, il n'y a pas de problème, toutefois, sur une véritable calculatrice, le résultat actuel est plutôt lent.
Il y a pourtant eu des progrès depuis les premières version en UserRPL, utilisant de très nombreuses variables globales. Toutefois, ce n'est pas du tout suffisant, et mon propre niveau d'exigence a fortement augmenté. En effet, je trouve, moi aussi, insupportable d'attendre une seconde et demi l'initialisation d'un écran, et encore pire, plusieurs secondes, voire plusieurs dizaines, lors de la mise à jour d'une ville ou du monde.
Il y a donc là matière à amélioration.
Plusieurs idées viennent se greffer sur ce thème.
Tout d'abord l'usage des "Linked Array", dont j'ai découvert l'existence récemment. Il n'y a pas vraiment photo, ce mécanismes n'a que des avantages par rapport au système de registres mappés actuellement en place. Mais il va falloir changer du code, pas mal de code en fait, donc cette transition devra se faire doucement. De plus, le gain sera limité (20% au mieux).
La seconde étape sera de diminuer drastiquement le nombre de variables du répertoire du monde. Il y a là aussi plusieurs sous-étapes. D'abord, le plus gros consommateur est la procédure de combat, qui utilise lourdement les variables globales pour les échanges entre ses procédure. Il y a probablement moyen de réduire ça fortement en utilisant des variables locales, puisqu'en SysRPL, celles-ci restent valables sur plusieurs programmes imbriquées. La vitesse d'exécution des combats devrait également être revues à la hausse, probablement de façon remarquable.
Puis il y a l'usage du Linked Array pour la plupart des informations restantes, du moins celles-qui pourraient se traduire par des nombres ou des indices. Là, cette opération est moins intéressante. Il faudra construire des traducteurs, qui coûteront de l'espace et des performances. Donc cette opération, isolément, ne rapporte rien.
En fait, il sera probablement plus intéressant de passer à la troisième étape d'abord. Il s'agit de passer en mode Librairies. En effet, actuellement, tous les appels entre les procédures se font en utilisant le principe des variables globales. Le problème, c'est qu'à chaque appel, on génère une procédure de recherche. Et celle-ci coûte du temps. En fait, on pourrait même dire plus que ça : celle-ci coûte la majorité du temps !!
Il semble donc clair pour moi que le passage en librairie, qui se traduirait par des appels de référence dans des Hashtables, aurait pour effet secondaire des démultiplier les performances d'un facteur important. Très important en fait, probablement entre 50 et 100%.
L'unique problème, c'est que je ne connais rien aux librairies. Cela prendre donc du temps de découvrir le sujet, choisir les bons outils et les utiliser.
L'idée serait alors de séparer le code et les ressources, qui resteraient des variables accessibles, et librement éditables. Bien réalisée, cette idée permettrait de réaliser des "mod packs", supportant des textes et des graphismes différents, en fonction du besoin.

La dernière étape serait donc une généralisation du concept de Linked Array, avec une seule table pour tout un monde (au lieu d'une par ville et par joueur). La plupart des informations pourraient s'y trouver. J'attends, là aussi, des résultats très importants en matière de performance et de gain de place mémoire. Probablement 50% pour l'un, et 20% pour l'autre. Ce serait donc très important.
L'unique problème, c'est que cela nécessitera une ré-écriture complète du code, qui aujourd'hui s'appuie fortement sur la notion de "contexte répertoire". Tout ceci pourrait être remplacé par un simple offset de contexte, mais malheureusement, tout le code devra être revisité. De même, pour être intéressante, cette idée nécessiterait de conserver la table dans la pile, du début à la fin, pour y être modifiée et lue sans effet "d'appel de variable globale" (ceci dit, avec des délais bien diminués compte tenu de la diminution drastique du nombre de variables). Donc là aussi, une ré-écriture complète du code.

Je suppose qu'une fois tous ces points réalisés, les utilisateur sur calculatrice ressentiront une énorme différence de performance, probablement au moins 3x, mais peut être bien davantage.


Il y a d'autres idées dont je voudrais vous parler, comme le principe d'évènements scriptés, de personnages uniques, de parcours à étape éditable, et de mod-packs complets permettant de changer radicalement le jeux, mais bon, je me rends compte que ce billet est déjà très long, alors ce sera pour une autre fois...