Précédent FunOrb Central 2e partie : Développement à petit budget (de mémoire) Suivant

FunOrb Central developer diary banner

28 mai 2009 - Développement à petit budget (de mémoire)

Ce journal est consacré à l'un des plus gros problèmes du développement des jeux FunOrb et de FunOrb Central : la consommation de mémoire.

Planche de sprites de Ziren
Un échantillon de la planche de sprites de Ziren pour Shaolin Kombat.
Pour voir la planche entière, cliquez ici.

La mémoire d'un ordinateur forme une sorte de pyramide. Au sommet, il y a une petite quantité de mémoire très rapide intégrée dans le processeur (mémoire cache). La base de la pyramide abrite une mémoire lente mais de très grande capacité (disque dur). Entre les deux, on trouve le type de mémoire qui nous occupe ici, qu'on appelle généralement mémoire centrale. Une partie importante du processus de développement est consacrée à la gestion du transfert de données entre ces différents types de mémoire, car elle est directement liée aux performances.

Lorsqu'un applet Java (par ex. un jeu FunOrb) est exécuté, c'est dans cette mémoire centrale qu'il est stocké. Toutes les ressources d'un applet (graphismes, musique, etc.) doivent être contenues dans la mémoire avant de pouvoir être utilisées. Malheureusement, les versions les plus courantes de Java limitent la quantité de mémoire que nous pouvons utiliser à 64 Mo (c'est ce qu'on appelle le « tas »). Cette limite est facilement dépassée par un simple jeu FunOrb. Un papier peint de la taille d'un écran moyen occupe environ 1 Mo, et les grands arrière-plans (comme le fond d'une carte d'Arcanistes) ou les planches de sprites (pour les animations de Shaolin Kombat par exemple) peuvent prendre encore plus de place.

Les restrictions sont encore plus serrées pour FunOrb Central, puisque la limite de 64 Mo s'applique à la fois au jeu et à FunOrb Central. Pour résoudre ce problème, nous avons prévu de réserver 10 Mo de mémoire à FunOrb Central et de laisser 54 Mo pour le jeu. À l'heure actuelle, beaucoup de jeux FunOrb nécessitent plus de mémoire que ça. Nous allons donc devoir les revisiter et les modifier, ce qui donnera pas mal de travail technique à toute l'équipe des développeurs de FunOrb.

Voici deux des techniques que nous allons utiliser :

  1. Suppression de contenus qui ne sont plus utilisés (par ex. : une séquence d'introduction, une fois terminée)
    Ça paraît simple, mais il y a des complications. Nous ne pouvons pas prédire quand les données seront à nouveau nécessaires, alors nous préférons tout garder en mémoire pour une vitesse optimale. Quand c'est impossible, nous avons parfois recours à une copie compressée. Ce n'est pas aussi rapide, mais ça économise de la place.
  2. Changement du format des données en mémoire
    Le choix de la méthode de stockage des contenus dans la mémoire et pour le téléchargement implique toujours des compromis entre performance, qualité et taille. En général, pour maximiser la vitesse de nos jeux, nous optons pour la version la moins comprimée. Les contraintes de mémoire peuvent cependant nous forcer à utiliser d'autres options, comme par exemple la compression d'images*. Le secret, c'est de s'assurer que les joueurs ne remarquent aucune perte de qualité ou de performance.
Concept de FunOrb Central
Un concept très anticipé de l'aspect et des fonctions de FunOrb Central (susceptible d'être modifié).
Cliquez ici pour voir l'image en plus grand.

Même avec ces techniques, FunOrb Central ne pourra jamais fonctionner avec seulement 10 Mo de mémoire. C'est pourquoi, après en avoir parlé à Andrew, nous avons décidé de recourir à un stratagème... Il y a environ deux ans, un ensemble de technologies a été ajouté à Java sous le nom mystérieux de « NIO » (qui signifie en anglais « new input/output » ou « non-blocking input/output »). Leur objectif principal était de permettre aux applications Java d'accéder très rapidement à des fichiers et périphériques réseau. Mais elles ont une fonctionnalité secondaire particulièrement intéressante, car elles allouent aux applets un peu de mémoire supplémentaire en dehors de la limite de 64 Mo. En utilisant cette technique, nous espérons pouvoir stocker la majorité des données de FunOrb Central dans cet « espace fantôme ». Nous en extrairons uniquement les éléments dont nous avons besoin pour les mettre dans la mémoire centrale, et seulement pendant le temps nécessaire.

La gestion de la mémoire dans FunOrb Central pose une autre question, à savoir : que faire lorsque nous disposons de mémoire supplémentaire. Avec les versions les plus récentes de Java (pour les joueurs ayant réglé leurs paramètres mémoire en conséquence), les applets ont accès à plus de 64 Mo. Nous voulons nous assurer d'utiliser au mieux cette mémoire supplémentaire, lorsqu'elle est disponible. Certains de nos jeux le font déjà, grâce à une technique Java intitulée « soft references ». C'est une façon de demander à Java de garder des données en mémoire, tout en lui permettant de s'en débarrasser si la place vient à manquer. Par exemple, vous devriez bénéficier de performances améliorées dans Dungeon Assault avec une meilleure allocation mémoire, car le jeu n'a pas besoin de décompresser constamment ses animations. De la même façon, nous aimerions que FunOrb Central conserve des jeux entiers chargés en mémoire (à condition d'en avoir assez), car cela devrait réduire les temps de chargement lorsque des versions plus récentes de Java sont utilisées.

Alors qu'est-ce que ça signifie pour vous ? En bref, FunOrb Central nécessitera une configuration similaire à tous les jeux FunOrb existants. Si vous pouvez déjà jouer, vous n'aurez aucun problème. Mais FunOrb Central pourra également bénéficier des ressources des ordinateurs exécutant les dernières versions de Java. Nous vous donnerons plus d'informations sur la configuration requise et autres recommandations lorsque nous approcherons de la date de sortie. En attendant, je vous donne rendez-vous au prochain épisode.

Mod Artifice
Développeur FunOrb

* Par exemple, les photos sont souvent compressées au format JPEG (ou JPG), qui permet d'obtenir des images détaillées avec une taille de fichier très inférieure à leur taille d'origine et des pertes de qualité minimes. Malheureusement, la décompression de ces images à des fins de rendu prend beaucoup de temps. Nous ne pouvons donc pas comprimer chacune des images de nos jeu.

Haut de la page