J'ai constaté que de nombreux développeurs de jeux de grande taille et bien connus développent souvent leurs propres moteurs. Les exemples incluent Valve, Crytek, Ubisoft, Epic Games et Square-Enix.
Serait-ce simplement parce qu'ils le peuvent ou est-il probable que les moteurs existants ne répondent pas aux exigences requises, de sorte que nous développerions les nôtres? Je peux difficilement imaginer un jeu qui nécessite un moteur spécifique. Les goûts de Unity ou Unreal sont simplement suffisants pour faire n'importe quel type de jeu; même si non, ils ont un code source, qui peut être modifié pour satisfaire même des besoins extraordinaires.
Pourquoi un développeur de jeux écrirait-il son propre moteur au lieu d'utiliser les moteurs existants?
la source
Réponses:
Un studio peut choisir de "construire" au lieu d'acheter sa technologie:
En général, il est judicieux de posséder et de contrôler les éléments essentiels au succès de votre entreprise et d’externaliser ceux qui ne le sont pas.
Pour certains studios, la conception ou la narration de leurs jeux peut être la ressource essentielle sur laquelle ils comptent capitaliser pour réussir. Pour ces studios, il est logique d'acheter simplement une technologie qui permettra à leurs concepteurs de réaliser la vision appropriée.
Pour d'autres, la technologie peut être la base du succès. Les studios qui construisent des MMO, par exemple, auront généralement besoin de créer cette infrastructure eux-mêmes, car elle est essentielle à leur succès (et le middleware existant est généralement inapproprié, du moins pour les plus grands titres "AAA").
Notez que certains des studios que vous avez énumérés (Crytek et Epic en particulier) ont pratiquement cessé d' essayer de dominer directement le marché des jeux et sont presque certainement beaucoup plus considérés comme des éditeurs de middleware que comme des développeurs de jeux.
la source
comme dit par Josh Petrie :
J'écris aussi mon propre moteur, et je suppose que la raison en sera différente pour chaque développeur, mais en fait, je n'aime généralement pas travailler dans le code des autres peuples. Je suis compulsif en ce sens que si je sens que je peux le construire moi-même, il ne sert à rien de se contenter de rien d'autre .
J'ai testé différents types de moteurs de jeu, API de rendu, etc., notamment Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, etc. beaucoup plus encore ... Je voulais commencer à écrire des jeux - j'ai téléchargé beaucoup de choses à la recherche d'un bon et point d'entrée bien documenté ...
Cependant, mon problème était qu'à l'époque je n'avais aucune idée de ce qui se passait sous le moteur. Je voulais un bon contrôle et un cadre que je connaissais comme ma poche. J'ai eu l'idée "HEY! Je pense que la seule façon pour moi de comprendre comment fonctionne cette chose et de la comprendre est d'essayer de construire mon propre moteur entièrement à partir de zéro. La majeure partie de mon histoire de programmation était avec des solutions Web et de traitement. - Ce fut un tout nouveau jeu de balle pour moi.
C'est ce que j'ai fini par faire.
J'ai donc choisi de configurer XNA puisque je connaissais déjà C # et j'ai commencé à réfléchir à comment et par où commencer. J'avais besoin d'une idée.
J'ai décidé que, quoi qu'il arrive, j'entrerais directement en 3D .
Obtenir les bases était cool - le genre de lot sprite, mais au fur et à mesure de mes progrès, j'ai découvert de nouveaux obstacles et barrières - le premier étant la limite de lot . Mon objectif était de créer un jeu capable de restituer au moins 10000 entités dans le tableau de bord à tout moment.
Je me suis lancé dans une nouvelle expérience d'implémentation de l'instanciation par shader (et appris HLSL alors que j'y étais), j'ai abandonné les objets Model et Effect intégrés à XNA pour écrire mes propres remplacements. J'ai eu du mal à comprendre les flux de VBO au début; J'ai cassé des choses - je suis allé en ligne pour poser des questions sur l'instanciation et je l'ai gardé jusqu'à ce que je comprenne enfin ce que faisait le GPU. Cela a payé maintenant, plus de 20 000 entités de test effectuaient des zooms dans ma fenêtre après quelques jours de débogage de mon VBO avec PIX (dxsdk).
J'avais maintenant "quelques" idées sur le fonctionnement des pipelines de rendu, mais je ne l'avais pas encore fait. J'ai fini par créer mes propres états de jeu, caméras, effets de post et objets d'entité, qui se sont éloignés du pipeline de contenu XNA en créant le mien. Les chargeurs (aversion personnelle envers XNB) ont créé une chaîne géométrique complexe, triée en profondeur et en fusion, ainsi que des images-objets instanciées et du texte projetés dans la scène du jeu.
J'ai ajouté, corrigé, modifié et expérimenté sans cesse pendant presque toute une année. En fin de compte, cela s'est bien passé. Je comprenais maintenant ce qui se passait sous le capot, car je l’ai créé, mon bébé.
Maintenant, mon moteur était presque stable et presque fini. Ce n'est pas parfait: le script est honky et l'interface graphique n'était pas géniale du tout. Mais j'ai toujours aimé ça. Des milliers de lignes de code, de ressources et de supports - stockés dans un référentiel privé git de 2 Go, et tous les maux de tête auxquels j'ai dû faire face en essayant de réaliser un type de développement que je n'avais jamais fait auparavant. Chaque obstacle que j'ai surmonté a été une leçon apprise - et un soulagement.
J'ai retiré presque tout ce que je voulais dedans.
Mais à la fin, j'ai décidé qu'il était temps de la rabaisser. Même si je me suis contenté d'écrire un moteur aussi énorme tout seul, avec les conseils du réseau et d'autres amis de Gamedev, j'ai décidé de tout recommencer - et de le faire mieux - car maintenant, cette fois, je sais surtout Qu'est-ce que je fais.
Ce projet est toujours caché dans mon dépôt GIT.
Mon deuxième passage à l'écriture d'un nouveau moteur (cette fois sur MonoGame) progresse bien. Quand quelque chose se brise, c'est plus facile à réparer. Moins de dégâts. J'espère montrer publiquement mon jeu cette année, car j'ai tendance à être un peu trop attaché à mon code.
En fin de compte, l'écriture de mon propre moteur est la façon dont j'ai appris à le faire, tout en étant capable de dire que je sais et que je comprends exactement ce que fait chaque composant et comment il est censé fonctionner. En fait, je déteste lire le code des autres, en particulier pour les grands projets non documentés. Je veux que tout ce que j'utilise soit construit par moi.
C'est juste moi si. Je doute que j'utilise jamais un moteur préconçu, probablement parce que je pense que c'est plus amusant pour moi d'écrire mes propres frameworks que de rester assis et de gérer le code de quelqu'un d'autre - un contrôle total.
la source
La raison essentielle absolue pour écrire votre propre moteur (et cela me surprend que personne ne l’ait encore appelé) est pour le débogage .
Si vous avez écrit un jeu volumineux et compliqué et qu'il contient un bogue crash et que vous avez le code source (et que vous connaissez parfaitement ce code en raison de son écriture), vous pouvez simplement attacher un débogueur à le processus et trouver ce qui cause le crash. Terminé.
Si vous utilisez le moteur disponible dans le commerce de quelqu'un d'autre et que vous ne possédez pas le code source de ce moteur (normalement, vous n'en avez pas), le débogage de tout problème qui survient - même à l'intérieur de votre propre code - se poursuit être monumentalement plus difficile. Et si vous rencontrez un bogue dans le moteur lui-même, vous ne pourrez pas le résoudre vous-même. Comment voudriez-vous être à une semaine de votre date de publication et permettre à quelqu'un de découvrir un bogue de blocage dans le moteur que vous utilisez? Un bogue de blocage que vous ne pouvez pas corriger car il se trouve dans un moteur propriétaire auquel vous ne vous connectez pas. avoir le code source? J'ai vu cela se produire - vous n'avez d'autre choix que de passer un appel de support urgent au fournisseur et espérez qu'il peut (et est intéressé par) résoudre le problème pour vous, pendant que vous fouillez,
Le développement de jeux est difficile, mais le débogage est beaucoup plus difficile. Dans mon livre, tout ce qui rend le développement de jeu plus difficile, mais le débogage plus facile est un énorme gain net.
la source
Il y a de très bonnes réponses ici, mais il manque un point supplémentaire important.
Aujourd'hui, beaucoup de moteurs sous licence étaient des moteurs dédiés .
Prenons Unreal comme exemple car il est si omniprésent.
Aujourd'hui, lorsque vous pensez à Unreal, vous avez tendance à penser à un moteur que vous avez sous licence et que vous pouvez utiliser au lieu de devoir construire le vôtre, mais ce n'est pas toujours le cas et il était une fois le moteur inexistant. une entité séparée.
Il était une fois il y avait un jeu appelé Unreal . Les développeurs de celui-ci ont décidé de construire leur propre moteur plutôt que de céder une licence à un moteur existant . Avance rapide à travers plusieurs itérations et ce moteur devient le moteur Unreal que nous connaissons aujourd'hui.
Le problème, c’est qu’il s’agit d’un problème œuf-poule. Chaque licence de middleware que vous pouvez obtenir sous licence a démarré quelque part, et souvent, elle n’était pas du tout un middleware (parfois, elle n’était même pas écrite dans l’ intention de devenir un middleware et son état actuel est en réalité un accident ). Les gens écrivent leurs propres moteurs parce que, finalement, quelqu'un doit écrire le moteur, et le moteur dédié d'aujourd'hui pourrait devenir le middleware sous licence de demain.
la source
Il existe d'autres raisons pour lesquelles un studio peut choisir de "construire" plutôt que "d'acheter" sa technologie:
Je suis également d’accord avec les demandes / besoins spécifiques, et la guerre des prix des moteurs et des licences oblige certains studios à déployer certains moteurs.
Les bonnes motivations pour "acheter" ou "utiliser" d'autres moteurs sont les suivantes:
la source
Raison historique (principalement).
Qui est lié à la tarification.
Chaque jeu que vous avez vu sous Unreal ou CryEngine ces dernières années a dû débourser beaucoup d'argent. Surtout si vous voulez obtenir le code source (c'est-à-dire que vous vouliez UE, pas seulement UDK.)
Mais cela a changé. Maintenant, tout le monde peut se permettre des moteurs encore plus gros, alors que la course aux prix a commencé.
Qu'est-ce que cela signifie ...
Bien qu'ils ne soient pas des jeux AAA comme ils l'ont été.
Voir le moteur Warhammer40k / COH sur Relic ou celui utilisé par les généraux chez EA.
Ainsi, même si tout le monde peut se permettre d'acheter des moteurs plus gros, ils n'offrent pas nécessairement un meilleur choix.
Les gens l'adorent pour sa facilité d'utilisation, ses performances rapides et son énorme stock d'actifs.
Bien sûr, Unity est capable de se déployer sur presque toutes les plateformes.
Donc voilà. Besoins, tarification dans le passé et tel.
la source
(ie.: you want UE, not UDK only.)?Qu'en est-il de l'organisation de l'équipe?
La documentation et le support, pas le code, se trouvent derrière les éléments de débogage, car à la fin, je ne voulais pas que mon groupe de construction touche le code de mon propre moteur. Cela pourrait être un gâchis.
J'ai donc besoin d'un groupe de soutien pour le faire. Mais cela augmente les coûts: plus de personnes, plus d'endroits, plus de lignes téléphoniques, plus d'administration ...
Une solution à ce problème peut être l'externalisation ... d'une entreprise de middleware, en libérant des ressources pour la création de jeux, à savoir le groupe de créateurs et les rédacteurs.
Pour une entreprise en démarrage, ce n'est pas une mauvaise option à utiliser et non à construire. Et, après avoir obtenu une masse critique de revenus, vous voudrez peut-être construire votre propre moteur ...
la source
bien. pour la plupart des jeux qui utilisent leur propre moteur créé par leurs développeurs. souvent. ils ne peuvent pas faire les choses avec un moteur tiers. ils se débrouillent donc pour faciliter le développement de leur propre jeu. ou possible au moins.
et beaucoup de jeux qui utilisent leur propre moteur juste en général. mieux travailler. parce qu'ils sont plus personnalisés et 100% correspondent à leur tâche. et le jeu lui-même se sent différemment. C'est vraiment facile de jouer à un jeu et de dire que c'est fait par. moteur irréel ou autre chose. moteur plus personnalisé en général et devrait aboutir à un jeu qui se sent unique. semble unique et fonctionne de manière unique et il devrait fonctionner mieux qu'un jeu qui a été créé sur un moteur pré-fabriqué.
la source
Ma réponse étant différente de celle existante, je l’ajoute bien qu’il soit tard:
Si vous prenez l'exemple de Valve de la question ou de la série Witcher, le processus est le suivant:
La même approche est adoptée par presque tous les développeurs financièrement raisonnables qui développent leur propre moteur. En modifiant un moteur, ils acquièrent des connaissances sur le fonctionnement d'un moteur et se heurtent à des contraintes de conception résultant d'un moteur sous licence. À la fin, ils disposent des connaissances internes nécessaires pour créer un moteur, de l’argent pour financer la création d’un moteur et d’un projet qui bénéficiera d’un moteur dédié. À ce stade, la raison pour laquelle un moteur a été créé est: Parce que c’est une chose intelligente à faire.
la source
mon professeur de programmation nous a dit d'utiliser uniquement les API / méthodes / classes / fonctions que vous savez construire
parce que si vous ne savez pas comment le construire et que vous utilisez le travail de quelqu'un d'autre, vous ne savez pas comment cela fonctionne et quand vous ne savez pas comment quelque chose fonctionne, vous êtes beaucoup plus sujet aux erreurs et aux problèmes et vous heurter à des murs de confusion
apprendre des choses simples peut, lorsqu'il est composé, entraîner des problèmes étranges, sans parler de quelque chose de complexe comme un moteur de jeu, en particulier lorsque vous êtes censé utiliser ce moteur de jeu pour exécuter votre jeu, ce qui peut entraîner de nombreux résultats et problèmes inattendus
et le moteur de jeu ne suit pas le code logique ou toute autre logique lorsqu’il est construit, bien que certaines choses soient prévisibles, mais en réalité, tout sera construit sur la base de la compréhension et de la connaissance de certains langages de programmation ou du fonctionnement de certains systèmes.
Par exemple, si je choisis d’écrire une équation mathématique, je peux l’écrire de nombreuses façons, que je puisse la représenter avec des polynômes, un calcul différentiel, une géométrie de base, une algèbre ou tout ce qui me convient, mais j’écris parfois sous une certaine forme / format pour pouvoir manipuler ce qui est facilement disponible, comme si je planifiais beaucoup de manipulation de vertex, je pourrais écrire ce modèle mathématique en utilisant la géométrie de base, mais si je voulais changer la courbe en utilisant des gradients, je pourrais me concentrer sur le calcul différentiel pour pouvoir pour manipuler facilement les gradients, etc. et il en va de même pour tout ce que je prévois pour avoir un accès plus facile à
et parfois le moteur de jeu actuel peut ne pas me donner la flexibilité de ce que je compte faire ou même peut-être qu'il vous donne cette option, mais il est très difficile à faire, car le moteur de jeu se concentre sur les forces de la physique en tant que source principale de mouvement et de manipulation de objets dans le jeu
de toute façon j'espère que j'ai clairement fait comprendre ce que j'essayais de signaler
la source