Phantasie Conquest : considérations pour l'affichage d'une carte

[Yann]

Avec la dernière version (v1.23) désormais disponible, l'essentiel de l'objectif de départ est atteint :
- Le code est redevenu compilable et utilisable
- Les binaires "Noir et Blancs" sont disponibles, en plus des binaires à niveau de gris

Tout ceci permet enfin une exécution sur l'émulateur X48, donc sur Droid48.

Sur la lancée, j'ai essayé d'améliorer quelques autres éléments du jeu.

Tout d'abord le code. Celui-ci reste un mix entre plusieurs générations de langages. L'objectif "sain" serait de tout rendre compilable au sein du même projet Debug4x. C'est ambitieux... trop ambitieux. La quantité de code est terriblement importante, et chaque conversion est douloureuse, avec de longues phases de test et de régression à chaque modification. C'est définitivement trop coûteux.

Après quelques améliorations et conversions malheureusement invisibles au joueur, j'ai souhaité recentrer les efforts vers un objectif plus "concret", avec un bénéfice plus évident pour le joueur.

L'ambition sans cesse repoussée de disposer d'une carte du monde, en mode graphique, et donc revenue sur la table.

Aujourd'hui, malheureusement, il faut choisir sa localité dans la liste, puis les informations correspondantes sont affichées (direction et distance). Mais évidemment, on tombe donc au hasard sur des voyages trop longs, et plus le monde est grand, plus il est difficile de savoir quelles localités sont suffisamment "proches".
La solution prévue à l'époque (1992!), c'est une méthode "offline" : le joueur est sensé fabriquer lui-même sa carte, à la main, sur du papier. C'est évidemment inacceptable aujourd'hui.

Construire une carte est cependant plus compliqué qu'il n'y parait. Tout d'abord, il faut rappeler qu'il s'agit d'un monde généré aléatoirement. On ne peut donc pas le "préparer à l'avance".
Toutefois, une fois le monde généré, il devient possible de fabriquer la carte correspondante. Ce serait une opération qui n'aurait lieu qu'une seule fois, à la création du monde.

Cette méthode semble jouable. Elle a cependant quelques petits défauts.
Tout d'abord, il y a l'empreinte mémoire.
Une carte "petite", c'est une taille de 25x25 cases, soit 625 cases. Au minimum, pour une représentation correcte, il faut que chaque case fasse 4x4 pixels, soit 16 pixels. Mais ça semble trop peu, ne permettant de représenter les localités qu'avec des points.
Même pour des graphismes "pauvres", il faut au moins 8x8., soit 64 pixels, et encore il faut s'attendre à quelques "recouvrements".
On arrive donc à 625*64=40 000 pixels. On est en noir et blanc, donc cela nous fait un GROB (GRaphical OBject) de 5Ko environ. Ça semble peu aux critères actuels, mais c'est plutôt pas mal, voire beaucoup, pour une HP48SX.
Les choses empirent avec les mondes de plus grande taille : on aurait besoin de 10Ko pour un monde de taille "normale", puis 15Ko pour un monde "grand". Ça devient très important.

Pour économiser la mémoire, il serait possible de compresser cette image, typiquement en utilisant la version rapide de LZD. Les gains seront sûrement très importants, de l'ordre d'un facteur 4. A cela il faut ajouter le code du compresseur lui-même, d'environ 500 octets. Ça reste un gain appréciable, et normalement, la vitesse de compression, et surtout de décompression, est suffisamment importante pour ne pas trop nuire à l'expérience du jeu.

OK, admettons que cela soit possible. Je passe sur les difficultés d'affichage si les communes sont trop proches, c'est secondaire. Il devrait également être assez facile de "centrer la carte" sur la position courante du joueur, même s'il reste à voir à quelle vitesse cette opération serait effectuée.
Il reste toutefois un dernier problème, c'est que la liste des destinations possibles est affichée "dans l'ordre du répertoire", c'est à dire sans relation avec la position du joueur. Il faut donc fouiller parmi les destinations possibles pour trouver son bonheur. Sur un monde de grande taille, ça peut devenir assez long.

Ajoutons à cela que la sélection s'effectue grâce à la méthode "INPUT", qui monopolise l'affichage en mode texte, et on est relativement incompatible avec l'affichage d'une carte graphique.

Tout ceci pointe donc vers un second mécanisme complémentaire, dans lequel les destinations proposées sont pré-sélectionnées pour correspondre aux communes les plus proches, et la méthode pour prendre en compte le choix du joueur ne passe plus par "INPUT".
Ce second mécanisme apporte ses propres complexités, qu'il faut résoudre également , mais nous verrons cela dans un second billet.