Existe-t-il des cadres basés sur les composants FOSS? [fermé]

25

Le paradigme de programmation de jeux basé sur les composants devient de plus en plus populaire. Je me demandais, y a-t-il des projets qui offrent un cadre de composants réutilisable? Dans n'importe quelle langue, je suppose que je m'en fous. Ce n'est pas pour mon propre projet, je suis juste curieux.

Plus précisément, je veux dire qu'il existe des projets qui incluent une Entityclasse de base , une Componentclasse de base et peut-être certains composants standard? Il serait alors beaucoup plus facile de démarrer un jeu si vous ne vouliez pas réinventer la roue, ou peut-être que vous voulez un GraphicsComponentqui fait des sprites avec Direct3D, mais vous pensez que cela a déjà été fait une douzaine de fois.

Une recherche rapide sur Google révèle Rusher . Est-ce que quelqu'un en a entendu parler / est-ce que quelqu'un l'utilise? S'il n'y en a pas, alors pourquoi pas? Est-il trop difficile de rendre quelque chose comme ça réutilisable, et ils ont besoin d'une forte personnalisation? Dans ma propre implémentation, j'ai trouvé beaucoup de passe-partout qui pourraient être insérés dans un framework.

component-based Tesserex
la source
4
Vous devriez être le premier à en écrire un! :)
Ricket
1
Eh bien, j'en ai écrit un en C # pour mon propre projet. Peut-être pourrions-nous tous contribuer?
Tesserex
Je serais totalement prêt à travailler sur ce projet C #. Oui, il n'y a pas un énorme consensus sur la façon dont un standard devrait fonctionner, mais peut-être pourrions-nous nous concentrer sur XNA (tout ce qui flotte votre bateau). Ce n'est pas parce qu'un groupe de géants n'a pas déclaré la meilleure façon de le faire que nous ne pouvons pas essayer / expérimenter.
Michael Coleman
Peut-être parce que la conception basée sur les composants attire plus les chefs de projet que les programmeurs
M. Utku ALTINKAYA

Réponses:

45

S'il n'y en a pas, alors pourquoi pas?

Parce qu'il n'y a rien qui ressemble à un consensus sur la façon dont un tel cadre fonctionnerait.

Sur un fil sur Gamedev.net, j'ai déterminé que lorsque les gens parlent de systèmes de jeu basés sur des composants, il y a en fait au moins 8 permutations possibles de la façon dont ils s'attendent à ce qu'ils fonctionnent, en fonction de 3 facteurs différents:

Inboard vs outboard - les composants doivent-ils être agrégés en une entité, ou doivent-ils faire partie d'un sous-système et être uniquement associés par un ID d'entité?

Composition statique vs composition dynamique - si les entités sont constituées d'un ensemble connu de composants (par exemple, 1 physique, 1 animation, 1 IA, etc.) qui peuvent communiquer en code via des interfaces bien connues, ou les entités peuvent-elles avoir des quantités arbitraires de composants ajoutées à eux (avec des stratégies associées pour localiser d'autres composants d'intérêt)

Données sur le composant vs données sur l'entité - Les données doivent-elles être détenues par le composant qui les exploite principalement? Ou les données doivent-elles être stockées sur l'entité dans un espace partagé, accessible par tous les composants?

Au-delà de cela, il y a d'autres questions sur la façon dont les composants doivent communiquer (via les données partagées? Via des pointeurs de fonction? Via des signaux / emplacements? Ou pas du tout?), Comment ils doivent être mis à jour (dans un ordre fixe en fonction du type de composant? Un par d'ordre des entités défini au moment de la création? basé sur une sorte topologique d'interdépendances de composants?), etc.

Chacun de ces choix est complètement arbitraire, et tout ce que vous pouvez faire avec un système peut être fait avec l'autre. Mais la façon dont vous devez le coder est très différente dans chaque cas. Et les gens semblent avoir des opinions bien arrêtées sur la voie qui leur convient le mieux.

À l'heure actuelle, les gens sont encore trop pris dans l'idée que les composants remplacent en quelque sorte l'orientation des objets (ce qu'ils ne sont pas) et s'imaginent également qu'ils constituent un changement radical par rapport à la façon dont les jeux étaient traditionnellement fabriqués (ce qui, encore une fois, ils n'étaient pas - les gens ont pris en compte les différents sous-systèmes dans leurs entités pendant des âges), donc il y a beaucoup d'hyperbole et pas beaucoup d'accord. Peut-être que dans quelques années les choses se seront calmées et que les gens adopteront une ou deux approches assez standard.

Kylotan
la source
1
J'apprécie que cette réponse soit ancienne, mais elle est maintenant fausse: il existe des cadres populaires et il y a très peu de débat sur le sujet. Lors de l'écriture de jeux, la plupart des questions ci-dessus n'ont pas d'importance: soit elles n'ont aucun effet sur la conception du code, soit une approche est rapide et réutilisable là où les autres ne le sont pas. Dans la pratique, il existe un tas de Frameworks populaires - le wiki lié à l'une des autres réponses est un bon point de départ (un groupe d'entre nous le maintient pour faciliter la recherche de jeux et de frameworks livrés)
Adam
1
@Adam: Je voudrais un lien sur les détails de l'approche qui a alors remporté le match darwin evolution. quand je dis des détails, je ne veux pas entendre parler de l'intérieur et de l'extérieur, je veux entendre des cartes de hachage, des vecteurs, des allocateurs, privés, publics, des boucles, des const ... Détails de bas niveau.
v.oddou
@ v.oddou quelqu'un a déjà publié un lien vers le wiki comme réponse (voir ci-dessous). Tu veux des détails? Il est plein de code source .
Adam
10

Il y a un wiki qui rassemble des exemples de tout cela:

http://entity-systems.wikidot.com/

... ainsi que des explications sur les différences entre les différentes approches.


la source
Ash et Artemis (tous deux sur le wiki) se sont révélés très populaires, tous deux utilisés pour le développement de jeux commerciaux, ainsi que le développement de jeux de passe-temps.
Adam
4

Vérifiez ces cadres que j'ai découvert concernant cette architecture ...

www.burgerengine.com

PushButtonEngine

Cadre Arthemis - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

Jetez un œil à Unity Api. Vous pouvez trouver beaucoup de choses concernant l'architecture basée sur les composants. (Mettra à jour la liste dès que je trouverai plus ...)

Mise à jour:

      https://code.google.com/p/spartanframework/

Cela explique les systèmes d'entités dans le bon sens ... http://piemaster.net/2011/07/entity-component-primer/

Ayyappa
la source
2

Il existe un moteur à bouton-poussoir pour Flash: http://pushbuttonengine.com/

Et il y a Panda3D pour c ++ / python: panda3d dot com (désolé, je n'ai droit qu'à 1 URL par message en tant que n00b)

Je suis sûr qu'il y en a des tonnes de plus :)

CJ Hanson
la source