Aller au contenu
← Retour au wikiMis à jour le
Comprendre les fichiers de son jeu

Moteurs de jeux
et traduction

Illustration des moteurs de jeux traduits

Reconnaître un moteur, retrouver ses textes et comprendre comment une traduction s’intègre au jeu.

Avant de commencer

Un moteur, plusieurs façons de ranger les textes

Voici les moteurs et technologies que l’on peut rencontrer dans mes projets de traduction. Les extensions sont des indices : elles ne disent pas, à elles seules, où se trouvent tous les dialogues ni si un jeu est déjà pris en charge par un outil.

Le moteur

Il fait fonctionner le jeu et ses scènes. Exemples : Ren’Py, Unity ou GameMaker.

L’environnement

Il permet de lancer une application. Electron et NW.js peuvent héberger différents jeux web.

Le conteneur

Il regroupe des fichiers. Une archive .rpa, .xp3 ou .asar n’est pas un simple texte à traduire.

Un même jeu peut combiner plusieurs de ces éléments. Pour l’identifier, on croise les noms de dossiers, les fichiers et le contenu des ressources.

Trouver son moteur

Les fiches détaillées

14 fiches

Visual novel

Ren’Py

Moteur open source spécialisé dans les romans visuels. Il associe un langage de scénario à Python pour gérer les dialogues, les choix, les personnages et l’interface.

Comment le reconnaître

Un dossier game, des scripts .rpy ou .rpyc, parfois des archives .rpa. Le dossier renpy est un autre indice fréquent.

Scripts
.rpy : source lisible ; .rpyc : version compilée utilisée par le moteur.
Archives
.rpa : regroupent des scripts, images, sons ou autres ressources.
Langues
Les traductions du système intégré sont généralement placées dans game/tl/<langue>/.

Pour la traduction

Le système intégré peut traduire les dialogues, les choix, les menus et les ressources propres à une langue. Les noms de fichiers et les identifiants de dialogue servent à relier la traduction à sa source.

Particularités et documentation

Lors d’une mise à jour du jeu, conserver la traduction existante et vérifier les nouvelles lignes. Les variables, les balises et les identifiants ne doivent pas être traduits comme des phrases.

RPG en 2D · RPGM

RPG Maker MV / MZ

Ces versions de RPG Maker servent à créer des jeux de rôle, d’aventure et des histoires interactives en 2D. Leur fonctionnement et leurs plugins reposent sur JavaScript.

Comment le reconnaître

Des dossiers data et js, avec des fichiers comme Map001.json, Actors.json ou System.json. Sous MV, ils sont souvent dans www.

Données
.json : cartes, événements, personnages, objets, compétences et termes du système.
Scripts
.js : fonctionnement du moteur et plugins, qui peuvent aussi contenir des textes affichés.
Images
Certains boutons, titres et menus sont dessinés dans les ressources graphiques.

Pour la traduction

Les dialogues se trouvent notamment dans les événements. Les descriptions et les noms figurent aussi dans la base de données ; les plugins peuvent ajouter leurs propres messages.

Particularités et documentation

Cette fiche concerne MV et MZ. Les anciennes versions XP, VX et VX Ace utilisent d’autres formats et le système RGSS : une méthode destinée à MV/MZ ne s’applique pas automatiquement à ces jeux. Les codes de contrôle des messages doivent être conservés.

2D / 3D

Unity

Moteur polyvalent utilisé pour des jeux en 2D et en 3D. Son nom ne désigne pas un format de traduction : chaque projet peut organiser ses textes différemment.

Comment le reconnaître

Sous Windows, un dossier portant souvent le nom du jeu suivi de _Data, et des fichiers comme UnityPlayer.dll ou globalgamemanagers.

Ressources
.assets et AssetBundles : contiennent des objets, textes, images et autres données. L’extension des bundles peut varier.
Textes
.json, .xml, .csv, .txt ou TextAssets intégrés aux ressources, selon le projet.
Systèmes de langue
Unity Localization ou des bibliothèques ajoutées par le jeu. Les scripts et les interfaces peuvent aussi fournir des textes.

Pour la traduction

Il faut repérer les dialogues, les menus et les tables de langue réellement utilisés. Une bibliothèque détectée aide à choisir la méthode, mais ne prouve pas que tous les textes passent par elle.

Particularités et documentation

Un lecteur de traduction au lancement peut éviter de redistribuer de gros fichiers modifiés, lorsqu’il est compatible. Mono et IL2CPP n’offrent pas les mêmes possibilités. Les textes des images nécessitent un traitement séparé.

2D / 3D

Godot

Moteur open source de création de jeux en 2D et en 3D. Il utilise notamment GDScript et C# et possède un système intégré de traduction.

Comment le reconnaître

Un fichier .pck à côté de l’exécutable est un indice fréquent. Le paquet de ressources peut aussi être incorporé à l’exécutable : l’absence de fichier PCK séparé n’exclut pas Godot.

Paquet
.pck : regroupe les ressources du jeu.
Projet
.tscn et .tres pour des scènes et ressources textuelles ; .gd pour GDScript. Des formes binaires peuvent être présentes après export.
Langues
.csv, .po et ressources .translation, selon le système et l’export utilisés.

Pour la traduction

Les textes peuvent être stockés dans les scènes, les scripts ou des tables de traduction. Si le jeu utilise des clés de langue, il faut préserver ces clés et traduire leurs valeurs.

Particularités et documentation

Un fichier de langue ajouté n’est utile que si le jeu le charge. Un patch PCK peut être employé lorsque le chargement et la structure du jeu le permettent ; renommer un fichier ne suffit pas à le faire reconnaître.

Visual novel

TyranoBuilder / TyranoScript

TyranoBuilder fournit un éditeur visuel pour créer des romans visuels avec TyranoScript. Le jeu s’appuie sur des technologies web et des scénarios organisés en scènes.

Comment le reconnaître

Des scénarios .ks, souvent dans data/scenario, accompagnés des fichiers du moteur Tyrano et d’une page de lancement HTML.

Scénarios
.ks : dialogues, choix, commandes et mise en scène.
Scripts et réglages
JavaScript et fichiers de configuration, dont la forme dépend du projet.
Interface
Textes, éléments HTML et images peuvent participer aux menus et aux boutons.

Pour la traduction

Les textes du scénario sont mélangés aux commandes. Il faut traduire les dialogues et les libellés tout en conservant les balises, les variables et les chemins vers les ressources.

Particularités et documentation

TyranoScript et KAG emploient tous deux des fichiers .ks, mais ce sont des systèmes différents. L’extension seule ne suffit pas à choisir le bon outil.

Visual novel

KiriKiri / KAG

KiriKiri est un moteur japonais utilisé notamment pour les romans visuels. KAG, pour KiriKiri Adventure Game, est un système de scénarios fonctionnant avec ce moteur.

Comment le reconnaître

Des archives .xp3 ou, lorsque les fichiers sont accessibles, des scénarios .ks et un script de démarrage startup.tjs.

Archives
.xp3 : regroupent les ressources du jeu.
Scénarios
.ks : texte de l’histoire et commandes KAG.
Logique
.tjs : scripts TJS, utilisés pour le fonctionnement et la personnalisation.

Pour la traduction

Les dialogues peuvent être dans les scénarios, tandis que des messages et des éléments de menu se trouvent dans les scripts ou dans les images.

Particularités et documentation

La structure, l’encodage et les éventuelles variantes d’archives dépendent du jeu. Les commandes KAG et les expressions TJS doivent garder leur sens et leur syntaxe.

Visual novel · VNM

Visual Novel Maker

Outil dédié aux romans visuels, avec un éditeur de scènes, de personnages et de choix. Il peut être personnalisé par des scripts et des extensions JavaScript ou CoffeeScript.

Comment le reconnaître

Dans les projets et certaines distributions, des dossiers data et resources. Le fichier Game.vnproject identifie un projet source, mais n’est pas nécessairement fourni avec le jeu.

Données
Données de scènes, de personnages et d’interface, notamment structurées en JSON.
Scripts
JavaScript ; CoffeeScript peut être utilisé pendant le développement puis compilé en JavaScript.
Langues
Le moteur propose une gestion des langues pour les textes du jeu.

Pour la traduction

Les dialogues et les menus peuvent être liés à la configuration des langues. Les interfaces personnalisées et les textes dessinés dans les images demandent parfois un traitement complémentaire.

Particularités et documentation

Il faut distinguer les fichiers du projet de ceux du jeu exporté. Le fichier .vnproject ne contient pas à lui seul les dialogues ; il sert à ouvrir et identifier le projet.

RPG / aventure en 2D

WOLF RPG Editor

Moteur japonais permettant de créer des RPG et des jeux d’aventure en 2D. Son système d’événements et ses bases de données permettent de personnaliser les interactions du jeu.

Comment le reconnaître

Un dossier Data avec notamment BasicData et des cartes, ou des ressources regroupées dans des fichiers .wolf.

Archives
.wolf : ressources regroupées ; leur présentation peut varier selon la version et le jeu.
Cartes
.mps : cartes et événements associés.
Données
.dat : événements communs, paramètres et bases de données, selon le fichier.

Pour la traduction

Les dialogues, les choix, les noms et les descriptions peuvent être répartis dans les cartes, les événements communs et les bases de données. Le contenu des images doit être traité à part.

Particularités et documentation

Après traduction, vérifier les accents, la police et la largeur des fenêtres, notamment pour les choix. Une phrase correcte peut devenir illisible si le moteur ne possède pas les glyphes nécessaires ou si le texte déborde.

Moteur 3D

Unreal Engine

Moteur utilisé pour de nombreux jeux en 3D. Il propose un système de localisation des textes et des ressources, mais chaque projet choisit ce qu’il y intègre.

Comment le reconnaître

Un dossier Content/Paks et des fichiers .pak, ou des ensembles .utoc / .ucas, constituent des indices courants.

Archives
.pak ; avec IoStore, conteneurs .utoc / .ucas.
Langues
.locres : traductions compilées. Les fichiers .po servent notamment aux échanges pendant le développement.
Autres ressources
Des textes ou interfaces peuvent se trouver dans d’autres ressources, dont les assets .uasset.

Pour la traduction

Quand le système de localisation est utilisé, les ressources de langue permettent de relier les textes à leurs identifiants. Il faut aussi vérifier les menus, les sous-titres et les interfaces personnalisées.

Particularités et documentation

Tous les textes ne sont pas forcément dans les .locres. La création d’un patch séparé dépend de la version, du format des ressources et de la façon dont le jeu charge ses paquets.

Jeux en 2D

GameMaker / GameMaker Studio

Moteur principalement destiné aux jeux en 2D : plateformes, aventure, RPG ou gestion. Il utilise notamment son propre langage, GML, pour programmer le jeu.

Comment le reconnaître

Sous Windows, la présence de data.win à côté de l’exécutable est un indice fréquent. Le nom et l’organisation des données peuvent varier selon la distribution.

Jeu exporté
data.win ou autre fichier .win : données et ressources utilisées par le jeu sous Windows.
Fichiers externes
Selon le projet, des fichiers .json, .csv, .txt ou d’autres ressources peuvent être chargés séparément.
Textes
Les messages peuvent être intégrés aux données du jeu ou produits par sa logique d’affichage.

Pour la traduction

Il faut des outils adaptés au jeu exporté. Certaines phrases sont assemblées à partir de plusieurs morceaux ou accompagnées d’une valeur : nom, heure, nombre d’objets…

Particularités et documentation

data.win n’est pas un document texte ordinaire. Modifier seulement un mot ne résout pas nécessairement les questions de retours à la ligne, de police ou de format de l’heure ; ces comportements peuvent être définis par le code.

2D / 3D · exports web et natifs

Cocos Creator

Moteur de création de jeux en 2D et en 3D, avec un éditeur de scènes et de composants. Un jeu peut être exporté pour le Web ou une plateforme native. Certains jeux PC hébergent leur version web dans Electron.

Comment le reconnaître

Dans certains exports web Creator 2.x : un script cocos2d-js…js, un dossier assets et des sous-dossiers import et native, accompagnés de fichiers config…json et index…js. Les noms et l’organisation varient selon la version et les options d’export.

Ressources
Fichiers JSON et paquets de ressources (Asset Bundles) : scènes, composants, données et références aux images.
Textes
Tables de langue, chaînes JavaScript et libellés des composants d’interface, comme Label ou RichText.
Images
Textures, atlas et animations : des boutons ou messages peuvent être dessinés directement dans une image.

Pour la traduction

Il faut retrouver les dialogues, choix et menus, puis préserver les identifiants et les liens entre ressources. Les textes français peuvent demander un ajustement des cadres, des retours à la ligne ou de la taille de police. La langue traduite doit aussi être chargée par le jeu.

Particularités et documentation

Le format des ressources dépend de la version de Creator et de la compilation. Des données compactées ou encodées demandent un lecteur compatible. Les textes peints dans les images nécessitent une retouche séparée, en conservant les dimensions, la transparence et les positions dans les atlas.

Si le jeu utilise Electron, Cocos Creator reste le moteur et Electron son environnement d’exécution sur PC.

Technologies web

HTML5 / jeux web

Cette catégorie regroupe les jeux construits avec les technologies du Web. HTML5 n’est pas un moteur unique : le jeu peut utiliser une bibliothèque, un moteur spécialisé ou du code propre.

Comment le reconnaître

Une page telle que index.html, des scripts JavaScript et des ressources web. Un jeu peut fonctionner dans un navigateur ou être distribué comme une application de bureau.

Structure
.html : page et éléments de l’interface.
Logique et données
.js pour les scripts ; .json et autres fichiers pour les données, selon le projet.
Présentation
.css : styles, dimensions et mise en page, plutôt que stockage principal des dialogues.

Pour la traduction

Les textes peuvent être présents dans les pages, les scripts ou des fichiers de langue. Il faut préserver les balises HTML, les variables et le fonctionnement des interactions.

Particularités et documentation

Tous les jeux web ne rangent pas leurs textes de la même manière. Une extension .html ou .js ne permet pas, seule, d’identifier le moteur ni de choisir une méthode universelle.

Environnement d’exécution

Electron

Framework open source qui permet de créer des applications de bureau avec HTML, CSS et JavaScript. Il embarque Chromium et Node.js ; certains jeux l’utilisent pour fonctionner dans leur propre fenêtre.

Comment le reconnaître

Un fichier resources/app.asar ou un dossier resources/app contenant l’application sont des indices fréquents.

Paquet
.asar : archive regroupant les fichiers de l’application.
Contenu
.html, .js, .json, .css et ressources graphiques.
Organisation
Certains fichiers peuvent rester en dehors de l’archive, selon la façon dont l’application est distribuée.

Pour la traduction

Il faut identifier le système de jeu présent dans l’application, puis les dialogues et l’interface qu’il charge. Electron décrit l’environnement d’exécution, pas l’organisation des textes. Un jeu peut par exemple utiliser Cocos Creator comme moteur et Electron pour sa fenêtre sur PC.

Particularités et documentation

Une archive .asar n’est pas un moteur ni un fichier de traduction. Son contenu doit conserver une structure compatible avec l’application après modification.

Environnement d’exécution

NW.js / Node-Webkit

Environnement associant Chromium et Node.js pour exécuter des applications web dans une fenêtre autonome. Node-Webkit est son ancien nom.

Comment le reconnaître

Des fichiers web avec un manifeste package.json, parfois dans un paquet package.nw. Le paquet peut aussi être incorporé à l’exécutable.

Manifeste
package.json : décrit notamment le point de lancement de l’application.
Paquet
.nw : peut être une archive ZIP contenant l’application ; des distributions utilisent aussi un dossier.
Contenu
Pages HTML, scripts JavaScript, données JSON et autres ressources du jeu.

Pour la traduction

Comme pour Electron, les textes se trouvent dans l’application exécutée. Un même jeu peut donc être identifié à la fois par son moteur et par NW.js.

Particularités et documentation

La présence de package.json seule ne confirme pas NW.js, car d’autres applications l’utilisent aussi. Croiser plusieurs indices évite de confondre le moteur, son environnement et le format de ses archives.

Du fichier au texte affiché

Ce qu’une traduction doit prendre en compte

  1. Identifier le jeu et ses langues

    Repérer le moteur, la version du jeu et les systèmes de langue utilisés. La présence d’un « localizer » indique un mécanisme de localisation, pas forcément plusieurs traductions complètes.

  2. Retrouver tous les textes utiles

    Dialogues, choix, menus, inventaire, historique, sauvegardes et messages de confirmation peuvent venir de sources différentes. Un texte classé « code du jeu » peut être une vraie phrase affichée : ce classement indique son origine.

  3. Préserver le fonctionnement

    Les identifiants, chemins, variables et balises restent intacts. Par exemple, dans Bonjour {player}, le nom de la variable doit être conservé. Une chaîne ambiguë doit être examinée dans son contexte avant d’être traduite.

  4. Contrôler le résultat en jeu

    Vérifier les accents, les retours à la ligne, les boutons et les textes dynamiques. Une heure en 24 h, une date en français ou une phrase révélée lettre par lettre peuvent demander une adaptation de l’affichage.

Fichiers de langue

Quand le jeu possède des tables de localisation, leurs clés permettent de relier les traductions aux bons textes. Ajouter le français demande aussi que le jeu charge la nouvelle langue et sache la sélectionner.

Images à traduire

Un mot dessiné dans une image n’est pas une chaîne de texte. Il faut conserver sa correspondance avec l’original, ses dimensions, sa transparence et ses différents états : normal, survol ou sélection.

Comprendre le patch fourni

Copie directe

Les fichiers préparés sont copiés dans le jeu, à l’emplacement indiqué. Le paquet peut contenir de nouveaux fichiers ou remplacer certaines ressources.

Patch compact

Il contient surtout les différences à appliquer. Un outil ou un exécutable peut reconstruire les fichiers traduits à partir de la version originale attendue.

Lecteur autonome

Il charge des traductions externes pendant l’exécution. Selon son intégration, il peut limiter la redistribution de gros fichiers, mais sa compatibilité dépend du moteur et du jeu.

La méthode d’installation est celle indiquée dans la traduction téléchargée. Le nom du moteur ne permet pas de décider seul où copier les fichiers.

Les cas que l’on rencontre souvent

Questions fréquentes

Pourquoi reste-t-il de l’anglais alors que les dialogues sont traduits ?

Le menu, l’historique ou une boîte de confirmation peuvent utiliser d’autres fichiers. Le texte peut aussi être assemblé pendant le jeu ou intégré à une image. Il faut d’abord retrouver sa source pour choisir la bonne correction.

Renommer « English » en « Français » ajoute-t-il une langue ?

Non. Cela modifie uniquement le libellé visible. Une vraie langue française suppose que ses ressources soient chargées et sélectionnées. Un patch peut aussi traduire le contenu de la langue anglaise existante ; ce fonctionnement doit être distingué d’un ajout de langue.

Pourquoi une traduction peut-elle peser plusieurs gigaoctets ?

Quelques textes modifiés peuvent se trouver dans une grosse archive qui contient aussi des images et des sons. Redistribuer toute cette archive augmente fortement la taille du patch. Un fichier de langue séparé, un patch différentiel ou un lecteur compatible peuvent parfois réduire ce volume.

« Incertain » veut-il dire que le texte ne doit pas être traduit ?

Non. Cela signifie que l’outil manque de contexte pour distinguer un texte visible d’un identifiant technique. Un nom de lieu ou un libellé court peut être traduisible. L’inclusion de ces chaînes dépend des réglages de l’outil ; il faut vérifier le résumé de préparation.

Pourquoi la même image apparaît-elle comme Sprite et Texture2D ?

Dans Unity, une texture fournit l’image et un sprite peut désigner une zone de cette texture. Les deux extractions peuvent donc se ressembler ou être identiques, mais un sprite peut aussi n’être qu’un morceau d’un atlas. Il faut garder une correspondance fiable, plutôt que se fier uniquement au nom du PNG.

Une mise à jour du jeu conserve-t-elle forcément la traduction ?

Les dialogues, les identifiants et les ressources peuvent changer. Une mémoire de traduction aide à réutiliser les textes connus, mais un patch préparé pour une version donnée doit être vérifié avant d’être appliqué à une autre.

Une police correcte suffit-elle à éviter les mots coupés ?

Elle permet d’afficher les caractères, mais les coupures peuvent aussi venir de la largeur d’une fenêtre, d’une limite de lignes ou d’un effet d’apparition progressive. Il faut contrôler la mise en page avec les textes traduits, souvent plus longs.

Les mots utiles

Petit lexique

Localisation
Adaptation d’un jeu à une langue : textes, formats de date et d’heure, polices et parfois images.
Asset / ressource
Élément utilisé par le jeu : image, son, police, scène, texte ou données.
Archive / conteneur
Fichier regroupant plusieurs ressources, parfois compressées. Son extension n’indique pas directement où se trouvent les phrases.
Chaîne de texte
Suite de caractères stockée par le jeu. Elle peut représenter un dialogue, mais aussi un chemin ou un identifiant technique.
Clé / identifiant
Repère stable utilisé pour retrouver un texte ou une ressource. On traduit généralement la valeur associée, pas la clé.
Variable / balise
Élément remplacé ou interprété par le jeu : nom du personnage, valeur numérique, couleur, pause… Sa syntaxe doit être conservée.
Atlas / sprite
Un atlas rassemble plusieurs images sur une texture. Un sprite peut utiliser une portion de cette texture.
Mémoire de traduction
Ensemble de textes déjà traduits, réutilisables lors d’une reprise ou d’une mise à jour. Le contexte peut nécessiter une relecture.