Système customisé de composants pour items [MY - AL]

[Deceleris]

Bonjour bonsoir !

J'ai déjà eu souvent besoin de créer système d'item pour mes jeux, et le problème qui s'est souvent posé c'est lorsque le jeu bien avancé, j'ai eu envie de rajoutée une fonctionnalité mais qui nécessitait implicitement de revoir toute la structure du système...

Donc il y a longtemps j'avais tenté de faire un système de composants pour les items, l'idée c'était que l'on pouvait customiser au mieux l'item sans avoir à créer un script par items. Mais le problème était que l'on pouvait pas sérialisée une liste de classe de base (ItemComponent) tout en conservant les données, du moins je n'y suis pas arrivé . Alors j'ai gardé quelque chose de classique et mon éditeur ressemblait à ça :



Voyez, on est pas sur quelque chose de très pratique et cela me pose toujours un gros problème, ça me permettrait de gagner tellement de temps...

Voilà donc je m'en remet à vous :

Q1 : Connaissez vous un moyen de sérialiser une classe enfant, à partir d'une liste de classe de base ? :

Q2 : Avez vous déjà créer un système d'item, et comment avez vous procéder ? Blueprint ? Un item = un script ?

Merci à vous

[Liven]

Une solution à ce problème m’intéresserait aussi.

Sur mon projet actuel, j'ai opté pour l'imbrication de scriptables objects.
Par exemple (en simplifiant car j'ai 4 niveaux d'imbrication) j'ai un scriptable "maitre" qui concerne les paramètres de la scène dont un scriptable object "enfant" qui contient la liste des objets à spawn.

L'inconvénient est que cela ne résous en rien le fait que l'on ne peut pas voir les objets que contient la liste du scriptable enfant lorsque l'on sélectionne le scriptable maitre,

Cependant en nommant bien les différents scriptable objects et en organisant bien les répertoires (et en n'hesitant pas à les adapter lorsqu'on en a besoin) j'arrive à m'y retrouver et à perdre un peu moins de temps. Le truc c'est qu'au lieu de naviguer entre la hierarchie et l'inspector, on navigue de l'onglet projet à l'inspector pour visualiser les données.

Sinon, une piste qui pourrait être creusée c'est du coté de l'asset odin (https://assetstore.unity.com/packages/t ... izer-89041) bon c'est pas donné, mais c'est bientôt le black friday, c'est je genre d'asset à avoir si on peu le choper pas chère et lui pour le coup il est censé multiplier les possibilités de serialisation.

[Deceleris]

Salut à toi, pardonne moi du temps de réponse...

Personnellement pour chaque scriptable object je met une fonction "DrawInpsector" public qui lui permet d'être affiché dans les scriptable objects parents. Je ne pense pas que ça soit très sécurisé mais vu les jeux que je fait actuellement ça m'est un peut égal

En gros actuellement tout mes SO ressemblent à ça :

Code : Tout sélectionner

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

#if UNITY_EDITOR
using UnityEditor;
#endif

[System.Serializable]
[CreateAssetMenu(menuName = "Item/Item", fileName = "Item")]
public class Item : ScriptableObject {

#if UNITY_EDITOR
    public virtual void DrawInspector ()
    {
    }
#endif
}

#if UNITY_EDITOR
    [CustomEditor(typeof(Item))]
class ItemEditor : Editor
{
    public override void OnInspectorGUI()
    {
        serializedObject.Update();

        Item audio = target as Item;
        audio.DrawInspector();
        EditorUtility.SetDirty(audio);

        serializedObject.ApplyModifiedProperties();
    }
}
#endif

Il à l'air vraiment bien comme asset Odin, Il pourrait être un très bon investissement en effet. Notamment pour toutes les fonctionnalités d'affichages de l’inspector qui permettrait de gagner tellement de temps !

J'ai fait quelques recherches aussi de mon côté et j'ai trouvé Jacob Dufault qui à créer un github pour son projet, il l'a appelé full serializer. Il se pourrait qu'il permette de régler ce problème de sérialisation mais je n'ai pas le temps de me pencher dessus, au vu de mon niveau actuel ça me demanderais beaucoup de temps et sans réelle assurance de réussite...

Au pire je vais essayer de créer un système de composants avec une base de données qui sauvegarderas les propriétés des composants, et ensuite à l'initialisation, les composants seront créer et reliés à leurs bases de données, c'est peut être un peut cheap comme solution mais bon

[Liven]

ça a l'air intéressant par contre je vois pas comment tu utilises ton exemple (je suis pas très au point sur ces sujets)

[Deceleris]

Alors par exemple je vais avoir un Scriptable Object (SO) parent qui va être disons "item", et un SO "audio". Ce sont deux scripts indépendants mais qui contiennent tout les deux un éditeur customisé et une fonction publique "DrawInspector" pour que ce soit plus simple de les éditer.

Donc ensuite l'item va contenir plusieurs audios, comme par exemple le la prise en main, le jeté au sol ou l'utilisation, et à l'intérieur de l'édition de l'item on va dire par exemple :

Code : Tout sélectionner

DrawInspector () {
      si (afficher use_audio && use_audio n'est pas nul) alors {
            use_audio.DrawInspector ();
      }
}

ce qui va permettre de ne pas avoir à switch entre les éléments que contient l'item et de les éditer directement depuis son inspector, c'est assez pratique je trouve quand on commence à avoir beaucoup d'items