Présentation générale du modding Skyrim

[xanareld]

Présentation générale du système de modding

A noter, cet article est en cours de rédaction et sera mis à jour jusqu’à finalisation
N’hésitez pas à m’adresser par MP (pour éviter de polluer le fil de discussion) vos remarques et corrections, je les prendrai en compte

 

TES V Skyrim est un jeu développé à l’aide du moteur Creation Engine développé spécifiquement pour ce titre (et qui fera l’objet d’améliorations pour être utilisés au sein de futures licences telles que Fallout 4). Le Creation Engine permet un modding relativement avancé, mais un certain nombre de règles doivent être comprises avant de vous lancer dans une séance de modding intense. Ce billet vous propose de revenir sur le fonctionnement global du Creation Engine, et de vous donner quelques conseils sur les bonnes pratiques et vous permettre de sécuriser votre modding.

Il ne s’agit donc pas d’un tutoriel sur le modding, mais d’une introduction qui permettra de comprendre certains mécanismes du Creation Engine, et donc d’éviter certaines erreurs relativement basiques.

Sommaire :

• 1/ Structure du contenu
• 2/ Gestion du contenu
• 3/ Performances et optimisation (prochainement)
• 4/ Contenu additionnel (hors mods) (prochainement)

1/ Structure du contenu 

Ce nouveau moteur permet aux développeurs et game-designers de créer du contenu (textures, sons, modèles, scripts, effets, animations, etc.) qui sera intégré au jeu à l’aide du logiciel Creation Kit, sous la forme de packages qui seront chargés par le moteur Creation Engine.

Spoiler

On distingue plusieurs types de packages (fichiers qui seront chargés par le moteur Creation Engine) :

• Fichier ESP : Il s’agit de fichiers contenant du code logique, des scripts, qui seront exécutés au sein de la machine virtuelle Papyrus. Ces scripts sont la base du jeu; ils permettent d’étendre les fonctionnalités de base du jeu – dans la limite prévue par le Creation Kit – voire d’en ajouter de nouvelles.
• Fichiers BSA : Il s’agit des ressources du jeu, qui pour des raisons de commodité sont réunies au sein d’un fichier unique (une archive)
• Fichiers ESM : Il s’agit de fichiers dits « Master » qui correspondent généralement aux fichiers de base du jeu. Marquer ces fichiers en tant que « Master » indique que la plupart des mods qui seront intégrés ultérieurement au jeu dépendront de ces « Masters ». Les fichiers ESM réunissent au sein d’un même fichier le contenu de l’ESP, et du BSA. Attention, ils ne sont pas extractibles car ne sont pas des archives (à l’inverse des BSA).
  • Skyrim.esm : contenu de base du jeu (sans le contenu des DLC)
  • Dragonborn.esm : contenu du DLC Dragonborn
  • Dawnguard.esm : contenu de DLC Dawnguard

Creation Engine sait également gérer le chargement de fichiers qui auraient été placés directement au sein du dossier Data du jeu, sans être intégrés à un ESP/BSA. Ces fichiers sont appelés LOOSE.

Autres types de contenu :

• Fichiers PSC : Ils correspondent aux scripts qui seront ensuite interprétés par la machine virtuelle Papyrus. Ces fichiers doivent être compilés afin d’être exécutables par la machine virtuelle. Pour des raisons de performance, le script écrit par l’utilisateur doit être compilé en bytecode afin d’être interprété par la machine virtuelle en un minimum de temps (et ainsi éviter le temps de parsing du fichier).
• Fichiers HKX : Ils correspondent à des animations. La plupart du temps, ces animations doivent être compilées pour être utilisables par le jeu, à l’aide d’un outil développé par la communauté appelé FNIS (Fores New Idle in Skyrim)
• Fichiers SWF : Ils permettent de gérer le système d'interface de Skyrim

Limites du Creation Engine :

• Skyrim (version initiale de 2011) : Le nombre de mods est limité à 255 mods en raison du système de gestion des mods et du moteur Creation Engine fonctionnant en 32 bits. Les ID des mods sont codés sur un octet, soit 2^8 256 valeurs possibles, le premier byte étant réservé à l’ID du plugin.
• Skyrim Special Edition : Bien que le moteur ait été réécrit en 64 bits, la limit de 255 mods est conservée (de toutes façon, sans être méchant, trouver 255 mods utiles et compatibles pour SSE, c’est assez compliqué)

2/ Gestion du contenu

Ainsi, le moteur Creation Engine permet une gestion modulaire du contenu, les packages pouvant être indépendants les uns des autres. Cependant, il est parfois possible, voire nécessaire, que ces packages soient reliés entre deux, principalement par une relation de dépendance. La plupart des mods sont dépendants des fichiers de base du jeu (Skyrim.esm, Dragonborn.esm ou Dawnguard.esm). Mais certains mods peuvent étendre les fonctionnalités d’autre mods.

A/ Exemple d’interaction de deux mods 

Spoiler

A titre d’exemple, imaginons un mod qui modifie le fonctionnement du jeu en permettant d’interagir avec un chien, lui proposer un os, et lui faire jouer une animation. Pour un mod qui réaliserait ceci, il faudrait à minima les fichiers suivants :

• Un fichier ESP qui contient la logique du mod (scripts) :
  • Autoriser l’interaction avec un animal spécifique
  • Ajouter du dialogue à l’animal
  • Ajouter la fonctionnalité permettant de sélectionner dans l’inventaire un objet à lui donner
    • Si l’objet donné est un os, déclencher l’animation
    • Si l’objet n’est pas un os, ne rien faire
• Un fichier BSA qui contient :
  • Un modèle 3D correspondant à l'os
  • Un modèle 2D correspondant à la texture de l'os
• Un fichier HKX correspondant à l’animation à faire jouer au chien (si le Creation Kit ne comporte pas d’animation pouvant être réutilisée)

Imaginons ensuite que je souhaite créer un second mod qui au lieu de permettre de donner au chien un os, permettre de lui donner un biscuit pour chien, et lui faire jouer une animation. Il faudrait à minima les fichiers suivants :

• Un fichier ESP qui contient la logique du mod (scripts) :
  • Autoriser l’interaction avec un animal spécifique
  • Ajouter du dialogue à l’animal
  • Ajouter la fonctionnalité permettant de sélectionner dans l’inventaire un objet à lui donner
    • Si l’objet donné est un biscuit, déclencher l’animation
    • Si l’objet n’est pas un biscuit, ne rien faire
• Un fichier BSA qui contient :
  • Un modèle 3D correspondant au biscuit
  • Un modèle 2D correspondant à la texture du biscuit
• Un fichier HKX correspondant à l’animation à faire jouer au chien (si le Creation Kit ne comporte pas d’animation pouvant être réutilisée)

Analyse de l’interaction de ces deux mods 

Fonctionnellement, ces deux mods font la même chose. Ils ont été créés de façon autonome de sorte qu’aucun ne dépende de l’autre.

• Avantages :
  • Ces deux mods fonctionneront de façon autonome
• Inconvénients :
  • Ces deux mods dupliquent des scripts identiques (interaction avec animal, dialogue, logique, animation).
  • Ils exécuteront à tour de rôle les mêmes instructions, ce qui occasionnera une charge plus importante pour la machine virtuelle
  • Ils comportent des ressources identiques (poids du mod)

Quelles solutions :

• Développer le second mod de sorte qu’il nécessite comme « Master » le premier mod, et ne modifie qu’un seul script (celui chargé de gérer le transfert d’objet dans l’inventaire, et d’autoriser en plus de l’os le biscuit).
  • C’est souvent la solution retenue par les moddeurs car seuls certains scripts sont modifiés, évitant autant que possible les double instructions. En revanche, certains mods ne sont pas compatibles entre eux car ils modifient en profondeur le même scripts, sans que l'un intègre les modifications de l'autre. Dans ce cas, aucune solution n'est possible pour rendre compatible ces mods entre eux.
• Développer un framework qui sera chargé de gérer les interactions avec les PNJ et aux mods d’ajouter des fonctionnalités sans avoir à réécrire la logique du code permettant de gérer ces interactions. Les mods qui utilisent ce framework ne modifient plus les éléments de base du jeu mais indiquent au framework quelles modifications effectuer, chargeant ce dernier de le faire à leur place.
  • C’est une solution parfois retenue pour certains gros mods, permettant de sécuriser leur fonctionnement en contrepartir un temps de développement important du framework et une maintenance régulière.
• Ne rien faire.
  • S’il s’agit de fonctionnalités qui ne sont exécutée qu’une seule fois (au chargement du jeu par exemple), bien qu’elles soient exécutées deux fois, leur coût en temps d’exécution est limité. En revanche, certains scripts nécessitent de s’actualiser à chaque frame, chaque seconde ou chaque X période de temps. Dans une telle configuration, le coût de la duplication des instructions est énorme est entraînera probablement une baisse des FPS (voir partie dédiée aux performances).

B/ Chargement des mods

Spoiler

Qui dit chargement dynamique des mods, dit ordre de chargement des mods. De cet ordre de chargement des mods peut dépendre le bon fonctionnement de ces mods.

• Les mods marqués « Master » doivent être chargés en premier
• Les mods dépendants d’un « Master » doivent être chargés après ces derniers

Afin de faciliter la gestion de la priorité de chargement, la communauté Skyrim a développé différents outils (LOOT, BOSS, WRYE Bash, etc.) qui permettent, en analysant le contenu des mods, d’en déterminer l’ordre de chargement (mais il peut y avoir des exceptions). En cas de modding relativement important, l’utilisation de ces outils facilite grandement la gestion de l’ordre de chargement. C’est un indispensable de tout joueur souhaitant modder Skyrim avec des mods qui comportent des scripts (fichiers ESM).

En cas de conflit, le Creation Engine dispose de différents mécanismes pour tenter de résoudre le conflit :

• Deux mods tentent de modifier la même ressource, via un fichier BSA : Dans ce cas, le Creation Engine prendra en compte le dernier mod chargé. Les BSA chargés overrident le contenu des BSA chargés précédemment.
• Deux mods tente de modifier la même ressource, via un fichier ESP : Dans ce cas, c’est potentiellement problématique car des conflits peuvent rendre le jeu instable :
  • Dans le meilleur de cas, les modifications sont appliquées successivement.
  • Dans le pire des cas, les modifications sont conflictuelles et occasionnent un CTD (Crash To Desktop), un plantage quoi !

Exemple : Les mods qui permettent de modifier l'inventaire des PNJ s'appuient la plupart du temps sur des « Leveled Lists ». Le Creation Engine ne permet pas par défaut de gérer plusieurs de ces mods; c’est donc le mod qui sera chargé en dernier qui modifiera définitivement la « Leveled List ». Cependant, des outils (WRYE Bash, etc.) développés par la communauté permettent de palier ce manquement en créant un patch qui contiendra les « Leveled Lists » des mods fusionnées.

Il est excessivement important de lire la description des mods afin de connaître les incompatibilités connues. De façon générale, il vaut mieux éviter d’installer des mods qui modifient plusieurs fois la même chose. La plupart du temps, c’est incompatible.

3/ Performances et optimisations

Spoiler

Prochainement

4/ Contenu additionnel (hors mods)

Spoiler

Prochainement