Il est parfaitement possible de mélanger les deux styles. Le même GameObject peut avoir certaines de ses fonctionnalités implémentées avec le nouveau système ECS et d'autres fonctionnalités dans les événements MonoBehaviour classiques.
Ce que Unity recommande dans son didacticiel ECS est en fait de commencer par un projet qui utilise l'ancien style, puis de rechercher des fonctionnalités qui, selon vous, pourraient bénéficier d'une refactorisation vers le nouveau modèle ECS:
Qu'est-ce que cela signifie pour mon jeu?
vous pouvez convertir un à un les comportements des méthodes MonoBehaviour.Update en ComponentSystems. Vous pouvez en fait conserver toutes vos données dans un MonoBehaviour, et c'est en fait un moyen très simple de commencer la transition vers le code de style ECS.
Vos données de scène restent donc dans GameObjects & composants. Vous continuez à utiliser GameObject.Instantiate pour créer des instances, etc.
Vous déplacez simplement le contenu de votre MonoBehaviour.Update dans une méthode ComponentSystem.OnUpdate. Les données sont conservées dans le même MonoBehaviour ou d'autres composants.
Bien entendu, cela ne fait pas usage des avantages du nouveau système Jobs et de l'instanciation d'entités via un EntityManager. Mais ces nouvelles fonctionnalités peuvent également être mélangées et assorties aux MonoBehaviours classiques.
Pour plus d'informations sur la façon de convertir un jeu en utilisant le modèle MonoBehaviour classique vers le modèle ECS, je recommande également cette série de vidéos de la chaîne officielle Unity où ils convertissent le bon ancien exemple de jeu de tir spatial au nouveau style, étape par étape. l'utilisation de plus en plus des nouvelles fonctionnalités. Chaque étape entre les deux fonctionne parfaitement. La version finale utilise toujours des objets de jeu classiques, en raison d'une fonctionnalité qui n'est pas encore disponible avec le système ECS (effets de particules).
