Phantasie Conquest v1.21, et la suite

View previous topic View next topic Go down

Phantasie Conquest v1.21, et la suite

Post  Yann on Sun 24 Aug - 16:11

Petite mise à jour pour Phantasie conquest, qui se voit débarassé de son code mort, et autres petites améliorations mineures. La nouvelle version v1.21 est donc surtout plus économe, passant ainsi de façon très nette sous la barre des 50Ko, pour se stabiliser aux alentours de 46Ko.

J'avais un instant pensé à ajouter des modifications pour augmenter la vitesse des batailles, mais en fait, c'est suffisamment rapide comme ça, et ce n'est donc pas nécessaire.

En fait depuis la mise en ligne de la première version, les progrès en performance et en occupation mémoire sont très importants, sans parler de la stabilité et des nouvelles fonctionalités. On s'achemine petit à petit vers une version plus respectable.

Désormais, lorsque je joue à Phantasie Conquest sur une calculatrice HP48SX, il n'y a plus qu'une seule chose qui me dérange : la mise à jour décennaire du monde.
En effet, tous les 10 jours, les décisions des royaumes PNJ sont affectées, et celles-ci dépendent d'une mise à jour plus ou moins complète des données du monde. On assiste donc à un "Freeze" du jeux pendant une durée variable, d'environ 1 à 4 secondes sur HP48SX, la plate-forme la moins puissante.

Si cette durée semblait acceptable autrefois, quand l'ensemble du jeux se montrait très lent, elle ne l'est plus aujourd'hui. Ce serait donc pas mal d'éliminer ce délais ou de le rendre plus fluide.

Il y a pour cela plusieurs pistes possibles, toutes compliquées, et assez complémentaires.

Tout d'abord, au coeur du problème se trouve l'algorithme de mise à jour des localités.
Mon premier réflexe a été de recycler mes compétences nouvelles en assembleur pour refaire le programme chargé de cette tâche. Mais je me rends compte que c'est un peu prématuré, et qu'il serait préférable de s'intéresser en premier lieu à l'algorithme lui-même.
Il est basé sur un principe de "tour de jeu", la notion de tour étant elle-même variable pour chaque localité. En conséquence, lorsqu'une localité n'a pas été mise à jour depuis longtemps (ce qui peut être le cas, l'algorithme décennaire ne mettant à jour que le strict nécessaire, certaines localités peuvent être "skippées" plusieurs fois), elle peut nécessiter une "grosse" mise à jour, passant plusieurs fois dans la boucle.
On peut probablement refaire l'algorithme pour "moyenner" tout ça. C'est plus compliqué qu'il n'y parait. Mal faites, les nouvelles formules pourraient déstabiliser l'équilibre du jeux. Mais bon, ce serait sans doute un premier pas.

Une fois les nouvelles formules mises en place et testées, il sera alors temps de songer à une version Assembleur. Ce sera assez long et compliqué à mettre en place.
Le programme actuel, en SysRPL, pèse déjà 2Ko. Du plus, il s'appuie sur de nombreux sous-programmes de recherche de variable. En Assembleur, ça va donc faire très lourd, et il faudra remplacer les sous-programmes par des routines assembleur, ce qui veut dire que toute modification future entrainera des complexités dans le code assembleur. Il y a donc un travail préliminaire à effectuer pour assurer ces futures transitions.

Il y a aussi une autre piste à travailler : s'attaquer au principe de mise à jour décennaire lui-même.
Ce principe est en fait la conséquence d'une lacune : il n'y a pas de gestionnaire d'évènement dans le jeux. De ce fait, à chaque "tour" de jeu (chaque jour en fait), l'algorithme teste toutes les possibilités.
Pour éviter d'alourdir le jeux, certaines décisions ne sont pas testées tous les jours. D'où la mise à jour décennaire pour les décisions des PNJ.

Un gestionnaire d'évènement rendrait ce principe obsolète.
Chaque PNJ pourrait avoir son propre "calendrier", et prendrait ses décisions quand bon lui semble. On évite alors une mise à jour "générale", au profit de plusieurs petites mises à jour distribuées, ce qui fluidifie un peu le process.
Le gestionnaire d'évènements permettra aussi d'ouvrir de nouvelles possibilités, qui vont au-delà du sujet de ce billet. Cela semble donc un bon investissement, mais remet en cause une partie "coeur" du jeux, aux ramifications importantes.
Cette modification devra donc être abordée de façon prudente, afin de valider proprement toutes les conséquences qu'elle entraine.

Yann
Admin

Number of posts : 174
Registration date : 2008-05-01

http://phantasie.tonempire.net

Back to top Go down

View previous topic View next topic Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum