Un visual novel peut être exigeant même lorsque peu de choses bougent à l'écran. Les grands portraits de personnages, les décors, les clips et l'audio contribuent tous au temps de téléchargement, à l'espace de stockage, au décodage et à l'utilisation de la mémoire. Les scènes en temps réel ajoutent du travail d'animation, d'éclairage et de rendu. Une scène fixe mérite elle aussi un budget.
Partez de l'apparence approuvée et d'un budget pour les appareils cibles. L'émulation dans un navigateur peut révéler des problèmes de mise en page, mais les performances sur un appareil physique doivent être testées sur un appareil physique. Pour chaque affirmation concernant les performances, consignez l'appareil, le navigateur ou l'environnement d'exécution, la version du jeu et les conditions de test afin de pouvoir reproduire le résultat.
Choisir des scènes et des appareils représentatifs
Choisissez une scène calme, une scène comportant plusieurs ressources volumineuses, une séquence avec des transitions fréquentes et tout passage vidéo ou en temps réel. Précisez l'appareil correspondant à la configuration minimale prise en charge et un appareil courant. Incluez le plus petit écran sur lequel les joueurs doivent pouvoir lire le texte et faire des choix.
Mesurez le démarrage à froid, les lancements suivants, les transitions entre les scènes et les interactions prolongées. Distinguez le premier téléchargement des ressources des essais utilisant le cache. Consignez les textures manquantes, le décodage lent, les retards de réponse aux commandes et les rechargements comme des défaillances à part entière ; une fréquence d'images moyenne peut masquer ces problèmes.
Mesurer le budget des ressources livrées
Pour chaque ressource livrée, consignez les dimensions à l'export, la taille du fichier et le nombre de ressources susceptibles de coexister en mémoire. La taille du téléchargement ne vous indique pas la quantité de mémoire qu'occupera une image décodée : la compression peut rendre le fichier bien plus petit. Gardez les fichiers sources modifiables séparés des fichiers exportés livrés aux joueurs.
Adaptez les dimensions à l'export à la façon dont la ressource apparaît réellement à l'écran. Comparez les formats envisagés dans l'environnement d'exécution cible avant de convertir toute la bibliothèque, et vérifiez les contours transparents, les dégradés, le texte et les visages par rapport aux illustrations approuvées. Un fichier plus petit est une maigre consolation si la compression gâche le gros plan d'un personnage.
Traiter la vidéo comme une charge distincte
Attribuez à la vidéo une ligne distincte dans le budget. Consignez la résolution, la durée, l'encodage, le débit, l'audio et le préchargement éventuel de chaque clip. Sur l'appareil cible, testez le démarrage, la lecture en boucle, la mise en pause et la solution de repli. La lecture dans un éditeur de bureau ne permet pas d'établir le comportement du clip dans un navigateur ou dans une version mobile empaquetée.
Chargez les variantes nécessaires à la scène au lieu de toutes les charger en même temps. Lorsque la conception le permet, proposez une image d'aperçu ou une image fixe de repli et donnez au joueur des commandes de lecture. Mesurez la transition complète, y compris le décodage et les illustrations présentes simultanément ; la taille du fichier du clip exporté ne couvre qu'une partie de la charge.
Préserver la réactivité des interactions
Rendez le texte lisible et les commandes assez grandes pour être utilisées. Testez la navigation rapide, le redimensionnement ou les changements d'orientation, la modification des paramètres pendant la lecture et le retour depuis l'arrière-plan. Lorsqu'une opération est en cours, vérifiez que chaque commande n'est prise en compte qu'une seule fois, sans déclencher d'actions en double.
Pour les jeux sur navigateur, vérifiez le comportement du clavier, du tactile et du focus partout où ils interviennent. Même une scène fluide semble défaillante si une surcouche masque le choix suivant ou si une transition bloque les commandes sans le signaler. Considérez les retours visibles et l'accessibilité des commandes comme des composantes de la réactivité.
Tester les pistes d'optimisation séparément
Modifiez une seule ressource ou condition de rendu pertinente à la fois et comparez-la à la référence. Consignez la validation visuelle avec la mesure des performances. Pour le travail en 3D, comparez les modifications de LOD, de textures et d'éclairage dans la même scène, avec la même caméra.
Gardez l'original disponible pour une comparaison directe. Une réduction du volume de données livré ne suffit pas à démontrer une amélioration des performances. La compression peut modifier le coût du décodage ou du téléversement, et les changements du moteur de rendu peuvent altérer l'apparence. Mesurez l'indicateur lié au défaut que vous cherchez à corriger.
Définir et faire respecter le budget de publication
Utilisez les observations tirées du segment jouable pour fixer des limites réalistes à la taille livrée, aux délais de transition, aux défaillances liées à la mémoire et à la réactivité des commandes sur les appareils cibles. Vérifiez-les à nouveau lorsqu'un nouveau chapitre ou type de ressource ajoute de la charge. Le budget doit refléter ce que la version du jeu et les appareils peuvent supporter.
Archivez le rapport sur les appareils avec la version candidate et indiquez que les appareils non testés ne sont pas vérifiés. Acceptez une optimisation lorsqu'elle préserve la présentation approuvée et améliore l'expérience visée dans des conditions reproductibles.
Décisions clés
- Suivez séparément la taille des téléchargements, la mémoire occupée après décodage et le coût du rendu.
- Mesurez des scènes représentatives sur les appareils physiques cibles.
- Comparez une seule modification candidate à la référence approuvée.
- Utilisez l'émulation pour vérifier la mise en page et les tests sur appareil pour étayer les affirmations concernant les performances.
Fichiers du guide
Registre des ressources ↓Matrice de tests des appareils ↓Les communautés externes consacrées aux modèles et les sites de publication externes peuvent contenir du contenu explicite. Les liens vers les sources s’ouvrent dans un nouvel onglet ; ce guide ne charge pas leurs aperçus.
Sources et lectures complémentaires +
- Documentation Android de Ren'Py ↗
- Documentation web de Ren'Py ↗
- Conseils de Godot sur les performances ↗
Dernière vérification 5 octobre 2026.