Framework ou bibliothèque Game Engine [fermé]

Je suis en train de planifier un moteur de jeu interne que je suis sur le point de créer, qui sera utilisé pour tous mes jeux à l'avenir. Mais je me bats un peu avec la façon dont il devrait être construit.

Les choix se résument à: framework ou bibliothèque.

Mon objectif de base est de masquer autant que possible les détails du moteur pour maintenir le développement de jeu de haut niveau sur les scripts et les fichiers de configuration autant que possible. Mais aussi pour réutiliser le moteur principal pour tous les outils que nous pourrions développer à l'avenir.

Les cadres peuvent rendre les choses agréables et faciles à développer, mais vous êtes alors verrouillé. Les bibliothèques sont bonnes si vous n'êtes intéressé que par un sous-système spécifique. Mais nous devons tout coller ensemble dans un jeu par jeu.

Eh bien, il y en a un autre, la construction du moteur comme un exe autonome qui gère toutes les ressources du jeu et tous les sous-systèmes. La logique du jeu (et d'autres éléments dynamiques par jeu) se fait exclusivement sur des scripts avec des fichiers de configuration pour configurer chaque sous-système de moteur interne.

Lequel me donnera plus de flexibilité à l'avenir.

Merci.

Edit: Merci tout le monde, je suppose que je regardais cela dans la mauvaise perspective. Nous ne pouvons pas vraiment planifier quelque chose comme ça sans une connaissance a priori de ce dont les jeux ont besoin, devinez c'est pourquoi il n'existe pas de moteur général pour tous les genres.

Je vais me concentrer d'abord sur le jeu proprement dit puis analyser de manière itérative à la fin de chaque jeu comment faire des abstractions décentes pour les bibliothèques ou les frameworks en fonction de mon flux de travail (ou éventuellement celui d'une future équipe).

Ne vous inquiétez pas encore pour l'avenir. Vous vous inquiétez de votre jeu actuel, maintenant. Sinon, vous n'irez nulle part parce que vous vous inquiétez des détails.

Vous devez vous concentrer d'abord sur la construction du jeu, puis plus tard, si le jeu a réussi, vous pouvez l'extraire en quelque chose de réutilisable pour votre prochain jeu. Cela vous évitera d'être enfermé dans autre chose et vous donnera un contrôle total sur votre projet.

Construisez un cadre.

J'ai de l'expérience avec la construction des deux. Je préfère utiliser des bibliothèques plutôt que des frameworks. Les cadres semblent très restrictifs et "autoritaires" . Donc, quand j'ai construit mon premier jeu, je voulais construire un moteur composé de nombreuses bibliothèques qui pourraient être facilement réutilisées dans d'autres projets.

Ce fut un désastre. J'ai passé la moitié de mon temps à écrire du code de colle entre mes différentes bibliothèques. Mes bibliothèques avaient également tendance à être gonflées d'abstractions supplémentaires, de sorte que c'était devenu une énorme corvée d'ajouter des fonctionnalités aux bibliothèques / composants.

Maintenant, cependant, mes moteurs sont construits avec le jeu que j'écris à l'esprit. Je garde toujours les yeux ouverts pour les abstractions qui me permettront de le réutiliser ou les nouvelles fonctionnalités que j'ajoute dans les jeux ultérieurs. Je suis beaucoup plus heureux et productif.

Pour moi, le tournant a été de décider de ne pas publier mon moteur. Je peux toujours le publier, mais pour l'instant, savoir que je n'ai pas besoin de justifier mes hacks spécifiques à d'autres jeux m'a permis de créer un moteur mieux adapté à mes jeux.

Je le vois trop souvent.
Pourquoi construire un moteur, à utiliser dans les futurs jeux, quand vous ne savez pas de quoi les jeux ont besoin?
Pourquoi ne pas créer le jeu d'abord, puis un autre, et un autre, en le réutilisant aussi souvent que possible.
Ensuite, vous avez une bibliothèque de code, probablement non organisée, mais qui s'est révélée utile.
Ensuite, vous pouvez l'organiser.

Et pour «framework vs bibliothèque», je me baserais sur la fatigue de l'écriture répétée d'une boucle de jeu et d'autres choses. ;)

Un framework n'a pas nécessairement besoin de vous enfermer. Regardez XNA.

Rester simple.

Si vous ne savez pas où aller, faites tout ce dont votre jeu a besoin. Essayez d'écrire de petites bibliothèques de base pour des choses que vous pensez être utilisables à l'avenir. Regardez dans le développement de logiciels basés sur les données. Je suggère d'examiner les systèmes d'entités basés sur les composants. Ne basez pas le code sur des choses uniques comme un joueur. Un joueur n'est qu'un autre objet, comme n'importe quoi d'autre. Une entité a des composants, peut-être une liste de composants.

En écrivant de petites bibliothèques confinées qui interagissent les unes avec les autres, vous pouvez aller de l'avant et déterminer celles à réutiliser pour votre prochain jeu. Personnellement, j'ai des choses comme une bibliothèque "conteneur" pour les types de stockage de données. J'ai une bibliothèque de mathématiques pour de telles choses. Il y a plusieurs choses comme celles-ci que vous pouvez trier et écrire en tant que modules. Caméra, effets, entrée, entité, mouvement, physique, rendu, gestion des ressources, threading, la liste continue.

L'écriture de petits composants autonomes augmente souvent la lisibilité et les possibilités de débogage de votre code.

Mike Acton et insomniac games (www.insomniacgames.com) ont écrit de nombreux sujets et discussions concernant le développement de jeux, en particulier axés sur les données. Recherchez-les et voyez quel type d'information est trop complexe et que vous trouvez intéressant et compréhensible. Ce sont d'excellents développeurs avec une tonne d'expérience.

Je pense que vous faites une généralisation prématurée. Ne restez pas trop coincé sur des questions d'utilisation future en ce moment. Choisissez une réponse et exécutez-la, apprenez-en. Lancez une pièce si vous n'avez pas de préférence.

Commencez par créer un jeu. Lorsque vous construisez votre deuxième jeu, vous aurez une meilleure idée des parties qui sont réutilisables et peuvent être transformées en fonctions de bibliothèque robustes. Lorsque vous construirez votre troisième jeu, vous aurez une meilleure idée de la structure réutilisable et qui peut être transformée en un cadre robuste.

En termes de flexibilité, je pense que vous avez répondu à votre propre question: "Les cadres peuvent rendre les choses agréables et faciles à développer, mais vous êtes alors enfermé ." Cela ne signifie pas que les cadres doivent être rigides; chaque jeu, par exemple, a une boucle de jeu. Le cadre XNA de Microsoft est une bibliothèque de 99%, mais votre jeu étend la classe de jeu qui fournit juste quelques fonctions en blanc pour les choses qui sont garantis dans tous les jeux: LoadContent, Update, Draw. C'est un excellent exemple d'un cadre non restrictif.

On pourrait dire qu'un framework n'est rien de plus qu'une bibliothèque combinée à une ou plusieurs classes de modèles qui sont connectées à la bibliothèque, du moins cela a été mon expérience.

J'ai tendance à préférer les bibliothèques aux frameworks. jMonkeyEngine , par exemple, est génial mais c'est un framework et en conséquence j'ai remarqué qu'il reçoit des tonnes de flak. SDL , d'autre part, est incroyablement populaire; c'est juste une bibliothèque. Il fournit ce dont vous avez besoin mais vous permet de faire ce que vous voulez avec.

Avec une bibliothèque, il n'y a pas nécessairement beaucoup de collage à faire au cas par cas - surtout si vous écrivez des parties de votre bibliothèque pour prendre en charge chaque partie de la boucle du jeu; un chronomètre / compteur d'images par seconde, par exemple, empêcherait la réinvention de cette partie couramment réécrite à chaque partie.

De plus, les bibliothèques peuvent être aussi générales ou spécifiques que vous le souhaitez. Si vous créez un jeu de course et que vous souhaitez que votre bibliothèque ait des fonctionnalités spécifiques à la course, c'est bien. C'est votre création et vous pouvez choisir exactement la flexibilité que vous souhaitez. Ce serait très faisable dans une situation où vous êtes dans un contrat à long terme avec Nascar pour développer de nombreux jeux de course, par exemple. Vous ne voudriez pas nécessairement qu'un cadre vous relie potentiellement à un jeu de course en cercle classique lorsque Nascar arrive et demande un jeu hors route, mais vous voudriez une bibliothèque spécifique au jeu de course puisque vous connaissez Nascar isn vais pas demander un tireur.

Voici également une astuce pour le développement: si vous écrivez la bibliothèque à côté d'un jeu, vous finirez inévitablement par coupler accidentellement la bibliothèque au jeu, ou la rendre trop rigide, quelle que soit la planification que vous faites. Vous le découvrirez dès que vous essayez de faire un jeu différent avec lui, et vous passerez du temps à le séparer; ce n'est pas nécessairement une mauvaise chose et vous pourriez consciemment décider de le faire, car vous aurez plus de temps libre après la sortie de votre premier jeu. Mais si vous visez une bibliothèque stellaire dès le départ, essayez de créer deux jeux totalement différents en même temps et extrayez les pièces similaires dans votre bibliothèque. Vous obtiendrez BEAUCOUP moins de couplage, ce sera beaucoup plus flexible, et votre troisième jeu exposera probablement encore quelques faiblesses mais votre bibliothèque sera bien meilleure à la fin. Cependant, c'est évidemment beaucoup plus difficile et plus long à faire.