Quelle est la différence entre un framework de jeu et un moteur de jeu?

Quelle est la différence entre un framework de jeu (par exemple, XNA avec C #, SDL pour c ++) et un moteur de jeu?

Les frameworks de jeu utilisent-ils des moteurs? Un moteur de jeu encapsule-t-il des sous-moteurs comme les moteurs physiques, les moteurs à particules, etc.? Doivent-ils être utilisés ensemble, ou sont-ils mutuellement exclusifs?

Je suppose qu'il existe des moteurs distincts pour la 2D et la 3D?

Il n'y a vraiment pas de définitions strictes pour "moteur" ou "framework".

De manière générale, un moteur est considéré comme «en faire plus» ou avoir plus d'outils et de support associé qu'un framework, qui n'est lui-même souvent qu'une collection lâche de fonctionnalités connexes exposées via une API unifiée.

À cette fin, les choses qui prétendent être des moteurs peuvent utiliser des choses qui prétendent être des cadres pour atteindre la fonctionnalité, mais ce n'est pas toujours le cas. De même, une chose prétendant être un moteur de jeu peut prétendre que ses éléments constitutifs (la physique et le rendu, et cetera) sont implémentés avec un moteur physique ou un cadre physique. Les types de technologie mentionnés par les deux termes peuvent être utilisés de manière interchangeable ou non.

Il peut y avoir des «moteurs» ou des «cadres» pour à peu près n'importe quoi - physique, son, et oui, même des graphiques 2D ou 3D.

C'est vraiment juste un problème de terminologie, et cela n'a généralement pas beaucoup d'importance. Du point de vue des fonctionnalités, une perspective axée sur la création de votre jeu, ce qui devrait être important est de savoir si la technologie en question fournit ou non ce dont vous avez besoin pour créer votre jeu. Qu'il s'appelle lui-même un moteur ou un framework n'aura aucune incidence sur cela.

Définition simple que j'utilise: vous pouvez construire un moteur sur un framework mais vous ne construirez jamais un framework sur un moteur. L'un est le squelette qui détermine l'architecture et le déroulement du programme, l'autre est le muscle qui fait le travail.

Pour un exemple concret, Artemis est un petit cadre soigné pour la construction de systèmes de composants, mais vous ne l'appelleriez jamais un moteur. Vous pouvez créer des systèmes Artemis et des composants standard pour en créer un moteur.

Un framework est une collection de bibliothèques (généralement) de niveau inférieur et de trucs d'aide que vous pouvez utiliser pour faire ce que vous voulez (graphiques, sons, etc.). Il n'y a rien de lié au jeu dans un framework, sauf qu'il est généralement optimisé ou conçu pour faire des choses courantes dans les jeux.

Exemple: un moteur vous permet d'avoir une liste d'entités, chacune avec une position sur la carte. Un cadre vous permet de rendre un objet 3D à une certaine position.

Vous les connectez donc en donnant à chacune de vos entités un objet 3D et les restituez si nécessaire.

Et ta-da, tu as un jeu.

Pour une explication vraiment détaillée, je vous recommande de lire la seule et unique Bible Game Engine Architecture de Jason Gregory. Je suppose que c'est le travail le plus complet sur ce sujet depuis sa publication. Il ne gère pas seulement la partie C ++ mais aussi et important pour chaque programmeur de moteur de jeu la théorie / l'architecture derrière. C'est un bon point de départ indépendant de la langue. Pour avoir un aperçu de ce dont nous parlons est cette image du livre

Permettez-moi de tenter de répondre à la question.

Quoi que vous écriviez, ce sera du code :-) après des années d'expérience, écrivez ce dont vous avez besoin et comment vous en avez besoin ou utilisez ce qui vous fournit ce dont vous avez besoin.

Le moteur et le cadre des termes proviennent de l'architecture logicielle et d'autres termes. Commençons donc avec les termes de base et remontons.

Bibliothèque

Exemples typiques: une bibliothèque mathématique fournissant tous les types et fonctions de base pour les calculs mathématiques (vecteur, matrice, ...) ou une bibliothèque d'images (jpeg ou png) fournissant la fonctionnalité pour écrire des images jpeg ou png

In Unity 3D Math est une bibliothèque de mathématiques.

Théorie: un libray fournit des fonctionnalités dédiées autour d'un sujet (par exemple les mathématiques) ET est appelé par le programmeur à la demande .

Quelques aperçus: il peut y avoir des bibliothèques contenant des frameworks alias étant une bibliothèque de frameworks.

Cadre

Théorie: Un cadre introduit une inversion de contrôle . Cela signifie que le développeur n'appelle pas la plupart du temps les méthodes du framework mais le framework appelle le code du développeur. Les exceptions sont lorsque vous devez intégrer la bibliothèque de framework dans votre code et démarrer le framework. Une bibliothèque de framework fournit toutes les méthodes et fonctions et interfaces pour un framework avec une utilisation dédiée. Les frameworks peuvent donc être dans une bibliothèque.

Exemple typique: Le MonoBehaviour Unity 3D fournit des méthodes comme Awake, Start, OnUpdate. Le développeur implémente ces méthodes puis ces méthodes sont appelées par le framework (game object management) (c'est l'inversion de contrôle) . La même chose avec les méthodes OnCollisionEnter, OnCollisionExit. Ils sont dans le même Monobehaviour mais je parierais qu'ils sont appelés par le cadre physique.

Un aperçu: Engine, Runtime, Editor, SDK

Étant donné que le terme moteur était toujours un peu vague et est toujours (et il ne s'améliore pas avec d'autres développements technologiques) une explication préliminaire.

Le terme moteur est utilisé pour plusieurs choses et on ne peut pas dire de façon unique laquelle a raison. En 2004, lorsque j'ai eu pour la première fois un contact avec l'écriture de moteurs de jeu, c'était aussi vague. Vous aviez un moteur de jeu au sens d'une sorte de code chargeant des données prédéfinies et vous permettant de jouer au jeu. Puisqu'il charge des données prédéfinies, ils ont été appelés moteurs basés sur les données. Vous les compilez une fois et les données externes auraient pu être des jeux différents sans les recompiler. À un moment donné, cela ressemblait à un runtime.

L'éditeur est clair. Il vous permet de définir les données prédéfinies chargées par le moteur / runtime.

Un moteur avec un éditeur s'appelait SDK (par exemple Hammer SDK).

Ensuite, il y avait / sont des moteurs dédiés. Un moteur phyiscs, moteur de rendu, moteur de son, moteur de gestion d'objet de jeu, moteur de réseau, ....

À mon avis, ce ne sont pas des moteurs (en particulier un moteur de rendu N'EST PAS un moteur de jeu car il ne fait que du rendu). Lorsque j'utilise le moteur de jeu Google, les résultats contiennent 90% de moteurs de rendu purs qui ne sont pas des moteurs de jeu. J'appellerais toutes ces bibliothèques, mais comme elles peuvent charger des données prédéfinies, elles correspondraient au terme moteur basé sur les données.

Une dernière petite note avant d'entrer dans les détails: j'ai obtenu avec succès un master en informatique. Ma thèse de maîtrise portait sur le thème "comment développer le cœur d'un moteur de jeu". C'est-à-dire la partie du code qui rassemble tous les autres moteurs, fait la gestion des objets de jeu, la boucle de jeu, etc ...

J'ai publié ma thèse de maîtrise sous la forme d'un (court) livre. Le seul commentaire sur Amazon d'un acheteur / lecteur est (après quelques années): il ne s'agit pas d'un moteur de jeu. Depuis que j'ai obtenu mon diplôme avec succès et que j'ai donc défendu ma thèse contre 3 programmeurs expérimentés (dont 2 dédiés aux jeux et aux applications interactives), je suppose que j'ai écrit un moteur de jeu.

Éditeur

Facile: vous permet de définir les données dans le format requis par les autres parties et élimine donc la nécessité d'écrire ces fichiers à la main ou d'utiliser des outils externes pour les créer.

C'est ce que fait l'éditeur Unity 3D.

Runtime

Ce terme est souvent utilisé également avec le moteur (qui peut être correct ou incorrect).

Le runtime exécute les données générées et fait ce qu'il a à voir avec les données. Par exemple, vous montrer le jeu et vous laisser jouer. Il ne crée aucune donnée (sauf peut-être enregistrer des parties) dans le sens où vous ne pouvez pas modifier le jeu lui-même.

Le lecteur Web Unity est / était un runtime vous permettant de jouer à des jeux Unity dans un navigateur Web.

Vous pouvez charger et exécuter plusieurs jeux différents avec le même runtime.

Dans le cas de l'API de script Unity 3D, il y a une coupure entre les fonctionnalités qui fonctionneront dans le jeu et les fonctionnalités qui ne fonctionneront que dans l'éditeur.

SDK

Ce terme est souvent appelé cadre .

À l'époque, un SDK était un ensemble d'outils comme un éditeur, IDE (environnement de développement intégré) pour les programmeurs, les exportateurs pour les formats de données et le moteur d'exécution.

Ainsi, un SDK / framework vous fournit un flux de travail et des utilitaires prédéfinis et vous montre une manière (bien conçue) de créer (facilement) un jeu.

Fondamentalement, le moteur Unity 3D serait erroné car il s'intégrerait davantage dans la direction du SDK. Mais comme Unity est encore plus, un nouveau mot / définition est nécessaire pour correspondre à ce qu'il est.

Quoi qu'il en soit, pour introduire l'autre terme, un SDK / framework vous fournit un pipeline de développement de jeux prédéfini (non seulement un pipeline d'actifs mais peut-être, comme Unity, un pipeline pour les actifs, la logique, les builds, les déploiements, ....)

Moteur

sarcasme sur Utilisé pour tout car tout le monde veut être cool en écrivant non seulement une bibliothèque, un framework ou un jeu mais mieux écrire un moteur complet. sarcasme éteint

Déclenchons-le:

Un moteur

1. est un morceau de code / logiciel
2. il est destiné à être réutilisé dans plusieurs projets (vous pouvez également écrire un moteur de jeu pour un seul jeu)
3. pour être réutilisé, le moteur de jeu sépare la partie réutilisable de la partie spécifique au jeu
4. pour être réutilisable (selon la façon dont il est destiné à être réutilisé), il existe différentes saveurs, comme un moteur piloté par les données chargeant des données externes

Un moteur peut être composé de plusieurs autres moteurs (puisque tout est appelé moteur de nos jours). Un moteur de jeu peut inclure

• un moteur de rendu faisant le rendu (ENCORE: dieu, bon sang, enfer: le code ne faisant que du rendu N'EST PAS un moteur de jeu)
• un moteur physique faisant la physique (c'est un moteur physique, pas un moteur de jeu)
• un moteur d'IA qui gère les choses de l'IA (c'est un moteur d'IA et non un moteur de jeu)
• un moteur de réseau (par exemple RakNet) faisant le truc de réseau (c'est un moteur de réseau, pas un moteur de jeu)
• un moteur audio qui fait les trucs audio (c'est un moteur audio et non un moteur de jeu)

Un exemple pour une application basée sur un moteur principal fournissant un cadre basé sur un plug-in pour tout regrouper dans un modèle de gestion d'objets de jeu basé sur des composants. Chaque sous-moteur (rendu audio) est un module ajouté au moteur de jeu sous forme de plug-in. Chaque composant peut faire partie d'un sous-moteur / module. Et la gestion des objets de jeu (basée sur les composants) est le lien de connexion entre les modules séparés.

La définition la plus proche pour Game Engine

Un moteur de jeu est la partie du code source de votre jeu qui offre toutes les fonctionnalités qui est destinée à être réutilisée accross jeux multiples et vous permettent de code et exécuter votre jeu. Il rassemble donc toutes les autres parties du code (rendu, audio, physique, gestion des objets de jeu, mise en réseau) qui sont soit des bibliothèques, des frameworks ou des moteurs dédiés (rendu, physique, ...).

Le moteur du jeu est le bordel au milieu.

Comme @Josh l'a déjà indiqué, il n'y a pas de définition stricte du framework ou du moteur mais, dans un sens conceptuel, les deux sont des outils très différents.

Un framework contient une abstraction de base de l'API avec laquelle travailler, donnant à l'utilisateur des outils de niveau supérieur pour interagir avec la plate-forme ou la fonctionnalité sans (généralement) se soucier des performances, de la compatibilité, etc. Dans les exemples que vous avez donnés, SDL est un framework, il donne vous abstarction sur la plate-forme, et vous pouvez construire votre logiciel derrière cette couche sans se soucier de la gestion des fenêtres, des trucs spécifiques au système d'exploitation, etc. Si vous voulez construire un logiciel entier, vous allez avoir besoin de différents cadres, par exemple SDL pour gérer les médias et des trucs de plate-forme, Box2D pour gérer la physique, etc.

Un moteur est différent, dans ce cas, l'outil expédie tout le nécessaire pour le développement, un moteur physique vous fournira tout le nécessaire pour gérer la physique et livrera une API facile à utiliser, donc, si vous voulez construire une simulation physique vous n'a pas besoin d'une autre bibliothèque tierce. Les moteurs ne sont rien de plus qu'une collection de frameworks, d'autres moteurs, interfaces, extraits et code général qui fournit tout le nécessaire pour terminer le projet sans avoir besoin d'autres tiers ni s'inquiéter des choses de niveau inférieur.