Framework ou bibliothèque Game Engine [fermé]

8

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).

Daemoniorum
la source
3
Ni. Vous devez construire le jeu, pas le moteur.
5
Je suis d'accord. `` Les cadres peuvent rendre les choses agréables et faciles à développer, mais vous êtes alors enfermé. '' Je pense que vous vous enfermez. :) Créez des jeux, pas des moteurs. Les moteurs suivront, plus tard - beaucoup plus tard. Il développe plusieurs projets.
jacmoe
@Jacmoe: Soit cela, soit vous essayez de construire votre prochain jeu sur votre jeu précédent et la source est remplie de code non structuré qui est incroyablement difficile à travailler. Au fil du temps, vous pourriez accumuler une énorme dette technique qui conduira éventuellement à un certain point où vous ne pourrez plus rien développer avec ce code. Je ne dis pas que cela arrivera, mais cela pourrait :)
Simon
Je n'ai pas recommandé que vous créiez du code non structuré. :) Créer un jeu au lieu d'un moteur n'est pas synonyme de gâchis - pas toujours ..
jacmoe

Réponses:

15

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.

Bryan Denny
la source
10

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.

deft_code
la source
5
+1 à ce sujet. En fait, je pense que l'on devrait se concentrer sur l'écriture de votre jeu, plutôt que sur un moteur pour écrire un jeu. Un moteur va émerger après plusieurs jeux réussis. Lisez ceci: scientificninja.com/blog/write-games-not-engines Trop de projets meurent tôt car ils ont essayé d'écrire une mère générique de tous les moteurs ..
jacmoe
4

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.

Le canard communiste
la source
Voulez-vous dire que XNA ne vous enferme pas? C'est à peu près exactement ce qu'il fait.
jsimmons
Je ne vois pas comment ça vous enferme vraiment. Vous voulez bien expliquer?
The Communist Duck
4

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.

Simon
la source
Yay Insomniac Games! L'un de leurs bureaux est près de moi, à Durham, en Caroline du Nord, et certains employés ont donné de GRANDES conférences lors de la Triangle Game Conference au printemps dernier.
Ricket
J'ai regardé un peu le développement basé sur les données et c'est certainement quelque chose que j'utiliserai. Quant aux composants, je vais les vérifier, surtout parce que je ne suis pas très satisfait de l'approche "fonctionnelle" que je fais en ce moment.
Daemoniorum
@Daemoniorum: Sonne bien, lancez-moi un autre commentaire si vous avez d'autres questions ou si vous voulez de l'aide / des idées pour les implémentations.
Simon
3

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.

gris
la source
2

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.

Ricket
la source