ScriptableObjects Unity : définitions partagées et état d'exécution propre à chaque instance

Commencer par déterminer à qui appartient la donnée

Une définition d'arme et une arme actuellement portée par un personnage sont deux types de données différents. Les confondre peut faire en sorte que la modification des munitions d'un personnage affecte tous les personnages qui utilisent le même asset. Avant de choisir un conteneur Unity, déterminez si une valeur relève d'une définition réutilisable, d'une instance donnée créée en jeu ou d'un profil de joueur sauvegardé. Attribuez à chaque catégorie un propriétaire identifiable.

Ce que partage un asset

Un ScriptableObject peut contenir des données indépendamment des composants de scène. Plusieurs objets peuvent référencer le même asset et partagent donc ses valeurs, au lieu de stocker chacun leur propre copie. C'est utile pour une configuration définie par les designers, mais cela ne rend pas l'objet référencé immuable. Le manuel d'Unity 6.0 décrit ce rôle de partage de données. [1]

Établir une frontière explicite

Exposez les valeurs définies par les designers derrière une interface orientée lecture et initialisez séparément l'état propre à chaque instance. Une classe d'exécution ordinaire suffit souvent pour les munitions, les minuteurs de recharge et les dégâts cumulés. Si un objet d'exécution a précisément besoin de l'identité d'un ScriptableObject, CreateInstance crée une nouvelle instance ; Object.Instantiate clone un objet existant. [2][3] Déterminez quelle voie correspond à vos règles d'initialisation, plutôt que de les considérer comme deux manières interchangeables de charger un asset.

Exemple : deux lanceurs de fusées éclairantes

Imaginons une définition de fusée éclairante contenant une capacité de 4, une durée de rechargement de 2 secondes et une référence à un projectile. Deux lanceurs instanciés lisent tous deux cette définition. Chacun démarre avec sa propre valeur de munitions (4) et son propre minuteur de rechargement. Un tir du lanceur A fait passer ses munitions à 3 ; le lanceur B reste à 4. Une modification d'équilibrage de la durée de rechargement partagée peut affecter volontairement les deux lanceurs dès leur prochaine lecture de la configuration. Cet exemple distingue les lectures en direct de la configuration des valeurs copiées au moment de l'instanciation : choisissez une politique par champ et documentez-la. Sauvegardez l'identifiant de définition du lanceur et son état changeant, puis reconstruisez-le par un chemin de chargement explicite.

Limites et vérifications

Un clone ne garantit pas que chaque asset référencé soit devenu la propriété indépendante de la copie. Examinez les références imbriquées avant d'autoriser l'écriture dans leur contenu. Établissez qui détruit les objets Unity temporaires et qui réinitialise l'état entre deux sessions de jeu. Traitez la sauvegarde comme une fonctionnalité distincte de l'application : modifier un objet en mémoire ne constitue pas un format de sauvegarde durable. Un test utile crée deux instances, n'en modifie qu'une seule, puis vérifie l'état des deux ainsi que la définition d'origine. Répétez-le après un rechargement de scène et après un nouveau démarrage de l'application, afin de révéler toute dépendance accidentelle à l'état de l'Editor.

Sources

1. ScriptableObject data assets — Unity Technologies.
2. ScriptableObject.CreateInstance — Unity Technologies.
3. Object.Instantiate — Unity Technologies.