• [^] # Re: Système à entité

    Posté par (Mastodon) . En réponse à la dépêche Je crée mon jeu vidéo E13 : un an, premier bilan. Évalué à 3.

    Justement j'ai une question sur les systèmes à entité. Je pense avoir bien compris le découpage système/entité/composants, mais je me demande comment faire des systèmes multi-entités. Pour du jeu vidéo c'est par exemple comment limiter le nombre d'unités ou gérer des collisions. Est-ce qu'il faut créer des composants qui pointent sur des entités (par exemple une entité stat qui connaît la liste des entités unités) ?

    Alors, je ne suis pas sûr de bien comprendre la question, mais je vais essayer de répondre.

    Si la question est : est-ce qu'une entité peut «pointer» vers d'autres entités, la réponse est oui. Comme exemple, on peut imaginer une entité «Besace du guerrier» qui a un composant Container qui contient un tableau d'entités (le contenu de la besace). C'est comme avec des pointeurs sauf qu'on utilise ici les entités qui ne sont que de simples identifiants. L'avantage, c'est que ça se sérialise très bien.

    Après, pour les collisions par exemple, c'est un peu plus complexe, et ça ramène à la discussion du dessus. Dans l'idéal, le système qui gère les collisions n'a pas besoin de pointer sur les entités directement, il peut être assez autonome. Pourquoi ? Parce que l'état d'une entité par rapport aux collisions, c'est sa position et sa vitesse. En particulier, toutes les données physiques (formes, caractéristiques) sont des données statiques. Quand on modifie la vitesse (ou la position), on prévient le moteur physique, puis au moment où le système qui contient le moteur physique se met à jour, il fait sa petite simulation. Et à la fin, on met à jour les positions et les vitesses de toutes les entités. C'est une vision simplifiée mais ça donne une idée. Le moteur physique fait ses simulations dans son coin et le système se charge de faire la passerelle entre les entités et le moteur physique.