Pourquoi un développeur de jeux écrirait-il son propre moteur au lieu d'utiliser les moteurs existants?


41

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?



1
Ils ne veulent pas acquérir de licence pour les moteurs de jeu d'autres sociétés et les payer.
János Turánszki

Je suppose que c'est ce que vous faites lorsque vous avez plus de 9K employés ...
glampert,

3
Il existe plusieurs contre-exemples de grands studios qui créent des titres AAA en utilisant des moteurs tiers tels que Unreal ou CryEngine .
Philipp

3
Valve a commencé par utiliser le moteur Quake, puis a finalement écrit le leur pour des jeux ultérieurs. Il s'agit souvent d'apprendre à utiliser ce qui est disponible, puis de vouloir finalement obtenir quelque chose de plus que ce que propose le moteur existant. À quel point vous devez faire de lourdes modifications ou rouler vous-même.
Nairou

Réponses:


53

Un studio peut choisir de "construire" au lieu d'acheter sa technologie:

  • Technologie héritée; un studio a peut-être commencé à construire sa propre chaîne d’outils avant même qu’il n’y ait un middleware viable.
  • Exigences particulières; un studio peut avoir un ensemble particulier d’exigences qui ne sont pas bien adaptées au middleware existant ou
  • Préoccupations budgétaires; un studio peut ne pas être en mesure d'assumer les dépenses ou les obligations contractuelles d'un middleware existant.
  • "Pas construit ici syndrome;" Les responsables techniques des studios peuvent se méfier (de manière raisonnable ou déraisonnable) des technologies qu’ils n’ont pas développées et qu’ils ne comprennent donc pas parfaitement.

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.


20
J'ajouterais que les technologies "construites ici" présentent parfois des avantages. Un exemple est la manière dont Unity3D modifie son CLUF à chaque version et ajoute des restrictions étranges, telles que l'absence de "jeux de hasard". Lorsque vous accordez une licence à un technicien, vous êtes à la merci du donneur de licence de ne pas révoquer la licence sans raison particulière (comme dans le cas des droits de propriété intellectuelle permettant de créer des jeux sous licence) ou de décider de vous facturer de corriger leurs bugs.
Skrylar

sérieusement, Unity dit "pas de jeux de hasard"? Ils avaient même l'habitude d'avoir une page spécifique sur le jeu dans la section Communauté de leur site web!
Jhocking

La page de Unity, unité3d.com/industries/gambling, indique que vous pouvez acheter une "licence de jeu Unity". Je n'ai pas trouvé de prix pour cela, mais on dirait qu'ils vous permettent toujours de créer des jeux pour les jeux d'argent à condition de payer pour une licence spéciale.
Alex

1
En outre, il est plus facile de commencer avec ce que vous savez déjà et de construire un moteur, sans même savoir ce qu’il en est. Un moteur n'est rien qu'une collection de cas d'utilisation; si vous essayez de réduire la redondance, vous finissez par écrire un moteur, et si vous essayez simplement de construire le jeu, vous vous retrouvez avec un système monolithique. Il est très difficile d'obtenir un moteur de jeu et d'apprendre à le faire afficher un pixel, puis de réaliser qu'il ne peut pas le faire car il voit tout comme une texture. Vous n'avez pas à vous en préoccuper lorsque vous écrivez le vôtre.
Dmitry

18

comme dit par Josh Petrie :

" Pas construit ici syndrome ;"

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.


13
Cela se lit beaucoup plus comme une anecdote personnelle décousue; vous pouvez probablement éditer ceci pour le rendre beaucoup plus concis et donner une meilleure réponse.
Josh

2
C’est certainement un excellent moyen d’apprendre et de créer votre jeu lorsque vous avez le temps de tout faire. Quand en effet c'est juste toi. Mais que se passe-t-il si vous souhaitez un jour collaborer avec quelqu'un? Ou travaillez-vous dans une entreprise avec aussi d'autres programmeurs? Si quelqu'un souhaite rejoindre votre projet, n'est-il pas un peu étrange qu'il soit alors supposé lire votre code - pour lui, le code des autres… la chose même que vous DÉTESTEZ? Je trouve que lire du code est également une compétence très importante. Sans vouloir vous offenser, je suis sûr que vous avez beaucoup appris et écrit un moteur génial - remarquez simplement que ce n'est pas tout.
Antont

Je suis conscient de cela, chaque travail que j'ai eu impliquant n'importe quel type de code dans n'importe quelle langue a toujours été solo pour moi D;
Codie Morgan

Je dois dire que je sais exactement pour quelles raisons une personne déploie son propre moteur / outil / peu importe. Mais cela a un prix (comme toutes choses) ... J'ai le sentiment que tous les patrons le détestent quand on ne peut pas lire / comprendre le code le plus pourri qui soit, alors allez-y et jetez-vous dedans comme ** * Une tonne de code mal écrit mal maintenu sans documentation, il suffit de vous en faire une idée (le monde "réel"). Sans vouloir vous offenser.
Quonux

C'est la raison pour laquelle nous, programmeurs, ne pouvons pas avoir de belles choses. Parce que nous voulons toujours tout faire nous-mêmes au lieu d'utiliser des méthodes de travail fiables. J'ai un besoin compulsif d'écrire tout moi-même, mais j'apprends lentement à faire confiance aux autres et jusqu'à présent, cela me fait plus de bien que de mal :)
Maurycy

15

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.


3
C'est l'un des principaux avantages de l'utilisation d'un moteur open source (cocos2d-iphone). Nous pouvons le déboguer exactement de la même manière que le code que nous avons écrit. En fait, je trouve que la façon de penser à l'open source est que c'est votre code. S'il y a des bugs, nous devrons les corriger, comme dans toute autre partie de notre code.
Antont

1
Cela peut être dit de n'importe quel middleware. Le code de débogage représente 80% du travail d'un programmeur et la gestion du middleware est un problème courant avec la technologie sur laquelle nous évoluons aujourd'hui avec plus de middleware que nous ne pouvons en compter. Apprendre à surmonter cela ne constitue qu'une partie du travail. Si le moteur ne tombe pas en panne, vous ne pouvez pas contrôler la volonté de quelque chose d'autre. Moins de pièces mobiles est une bonne idée, mais quand cela devient compliqué comme un jeu, vous devrez en gérer beaucoup, de toute façon.
Tim

@ Tim je suis tout à fait en désaccord - le fait qu'un élément externe puisse mal se comporter de manière difficile à corriger ne signifie pas que nous devrions simplement hausser les épaules et nous résigner à laisser tout ce qui se comporte mal de manière difficile à corriger. Il faut évidemment prendre les choses au cas par cas, mais un moteur est un gros système dans lequel se cachent souvent des bugs complexes. Pourquoi ne voudriez-vous pas cela sous votre contrôle, si vous pouvez vous permettre de le faire vous-même?
Trevor Powell

@TrevorPowell Cela dépend évidemment de la complexité du projet et, comme vous le dites, cas par cas, mais il faut simplement envisager de réinventer une roue (surtout si elle est grande) pour gagner du temps en ne le faisant pas. il. Le middleware facilite les choses. En tant que développeurs, nous pensons pouvoir toujours réinventer une solution pour la rendre meilleure sans considérer la qualité de cette solution. Quelques chocs> réinvention> La mauvaise solution
Tim,

2
@ Tim RE: "Le middleware rend les choses plus faciles", j'ai eu des expériences très différentes de celles que vous avez, apparemment.
Trevor Powell

9

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.


2
Il est à noter que, à l'époque, lorsque les jeux tels que Unreal ont été créés, il n'y avait tout simplement pas d'autre choix que de tout écrire à partir de zéro. Ce n'est que depuis quelques années que nous avons le choix entre les moteurs N ...
joltmode

3

Il existe d'autres raisons pour lesquelles un studio peut choisir de "construire" plutôt que "d'acheter" sa technologie:

  • Nouvelles plateformes : nouvel OS mobile, console ou contrôleurs. Pensez à Leapmotion, à Google Glass, etc. Le support multi-plateformes est difficile
  • Nouveaux mécanismes de jeu et / ou éditeurs en jeu : pensez à FEZ, il y a quelques années (2D ou 3D)
  • Manque de bons éditeurs de jeux gratuits à code source ouvert . Manque de bonne documentation sur la source existante d'anciens jeux
  • Evolution des outils dans la chaine de production (ou en ajouter de nouveaux)
  • Prix ​​des moteurs et guerres de licences

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:

  • Réutilisation de code : un moteur déjà utilisé dans d'autres jeux est plus testé, plus stable et peut avoir la plupart des fonctionnalités nécessaires, à partir du premier jour.
  • Étendre : vous pouvez étendre certains moteurs open source.
  • Gratuit : ou presque gratuit, car même les moteurs open source gratuits nécessitent du temps de développement pour apprendre.

2

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

  • Vous verrez beaucoup plus de jeux utilisant à la fois UE4 et CryEngine.
    Bien qu'ils ne soient pas des jeux AAA comme ils l'ont été.
  • Les exigences et les besoins personnalisés pour chaque projet ne vont pas disparaître.
    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.
  • Il y en a d'autres sur le marché. Comme l'unité.
    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.


1
Je n'appellerais pas Havok "fortement modifié".
Josh

Havok n'est-il pas juste un moteur physique?
Philipp

C’est vrai, et GW2 n’a pas fait grand chose à sa note, si je me souviens bien.
Josh

Tu ne veux pas dire (ie.: you want UE, not UDK only.)?
Keavon

#JoshPetrie: Désolé, je ne suis pas expérimenté à Havok / je n'ai jamais joué avec. Je suis donc tombé sur le fichier LICENSE de GW2, puis j'ai visité sa page wiki il y a quelques jours et j'ai vu Havok. Ensuite, j'avais un vieux souvenir de voir "Havok" au début d'un jeu, où je pensais que c'était le moteur. Mais à ce moment-là, j’ai également regardé Havok et je savais que c’était un moteur physique. tl; dr: J'ai mélangé les choses à propos de Havok. || #Philipp: C'est un peu plus que ça, mais effectivement ce n'est pas un moteur de jeu, mon mauvais. || #Keavon: D'accord, corrigé. Merci!
Apache

0

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


0

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


0

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:

  • Licence un moteur
  • Modifier / adapter le moteur à vos besoins
  • Sortir le jeu et générer de l'argent
  • Créer son propre moteur pour le prochain match

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.


-2

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


6
-1 Si vous travaillez sur un projet de taille respectable, vous êtes censé utiliser des fonctions / classes dont vous ne savez pas comment il a été écrit, et vous ne pourrez peut-être pas en écrire un vous-même sans avoir à étudier le nombre de livres sur le Web. sujet. Je ne parle pas de ce que tout programmeur devrait savoir, mais un moteur de jeu est un projet énorme, et on s'attend à ce que le sujet spécialisé du programmeur X ne connaisse pas le sujet Y et doive donc utiliser la fonction, je ne le suis pas non plus. ce qui implique que vous ne devriez pas savoir utiliser l’API, mais que vous n’avez peut-être pas assez de connaissances pour en écrire une.
concept3d

2
Votre professeur sait-il comment construire une voiture complète à partir d'éléments chimiques à partir de rien? Ou bien le conduit-il en supposant que cela fonctionne ;-)
Kromster dit de soutenir Monica

1
@ concept3d il y a une différence entre travailler sur un projet où quelqu'un d'autre conçoit les fonctions / classes que vous utilisez, parce que généralement si vous ne comprenez pas quelque chose qui peut être facilement expliqué, un programmeur qui utilise des classes de code / fonctions / bibliothèques il Elle ne sait pas que c'est une personne stupide. Même les classes et les API disponibles publiquement sont livrés avec des manuels et des wiki qui expliquent ce que font ces API ou ces fonctions. S'attendre à les utiliser sans savoir ce que c'est, c'est comme essayer de nager. eaux profondes sans savoir nager, et vraiment ignorantes et sujettes aux erreurs
thingybingytie

@ hopjoppe5 Si vous cochez la réponse acceptée, ce sont les seules raisons pour lesquelles les gens construisent leur propre technologie. Beaucoup de bibliothèques / codes sont externalisés dans le monde réel et vous devez les utiliser. Lire les manuels est différent de connaître l’implémentation. Certains algorithmes vous découragent même de l’implémenter vous-même et devraient être mis en œuvre par des experts du sujet. Si vous avez une expérience réelle du monde, vous comprendrez cela. Tout savoir est impossible.
concept3d

L'une des principales raisons de l'abstraction est d'écrire du code afin que les personnes qui ne savent pas comment cela fonctionne puissent toujours l'utiliser. Lorsque vous travaillez sur un jeu plus grand que pong, il est peu probable que vous connaissiez tous les éléments de code. Et dans la plupart des cas, c'est une bonne chose, car cela signifie que vous pouvez vous concentrer sur ce sur quoi vous travaillez en ce moment, plutôt que de vous inquiéter de la manière dont le système de saisie peut traiter votre demande d'événement "On Action Key Down".
Aidiakapi
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.