Holivar sur l'opportunité d'utiliser des moteurs pour créer des jeux a commencé immédiatement après l'apparition des premiers moteurs de jeux.
Ce post sur reddit n'est pas un exemple idéal de contre-arguments raisonnables contre l'utilisation constante des moteurs, mais je crois que le désir irrésistible de les utiliser donne un peu de fanatisme.
Raisonnons sagement
Je pense qu'il n'y a pas de réponse toute faite à la question de savoir si le développeur doit utiliser le moteur. Un développeur avisé, avant de choisir une technologie, évalue toutes les options possibles.
Niveau de compétence
Avez-vous suffisamment de compétences pour utiliser efficacement l'option sélectionnée? Si vous n'avez aucune expérience en programmation, vous devrez en apprendre beaucoup avant d'être prêt à créer un jeu à partir d'un ensemble de bibliothèques disparates.
Si vous n'avez ni compétences techniques ni intérêt à les apprendre, alors il n'y a vraiment pas d'options - vous devez travailler avec le moteur (ou convaincre quelqu'un de faire la partie technique pour vous; bonne chance avec ça!).
Il existe un état intermédiaire entre un manque complet de compétences et un niveau professionnel. Il est principalement situé dans le pays des langages de script: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D, etc. Tous sont destinés à ceux qui souhaitent acquérir un certain niveau de connaissances techniques afin d'obtenir rapidement des résultats.
Si vous êtes un programmeur expérimenté / professionnel capable de maîtriser en toute confiance un logiciel tiers, vous pouvez utiliser cette compétence et décider du degré de minimalisme / maximalisme de votre approche (qu'il s'agisse d'un SDL extrêmement minimal ou d'un moteur Unreal entièrement équipé).
Objectifs de développement
Quels sont vos objectifs dans ce projet? Les technologies devraient maximiser leur réalisation:
- C'est un passe-temps pour vous et surtout vous voulez vous développer en tant que développeur? Vous devriez peut-être rester à l'écart de Unity et Unreal et envisager de développer des jeux basés sur des bibliothèques de niveau inférieur.
- Est-ce une entreprise pour vous? À ce niveau, les choses deviennent beaucoup plus compliquées. Les options doivent être évaluées en fonction de nombreux facteurs: pouvez-vous embaucher des personnes familiarisées avec la technologie? Ces gens veulent-ils utiliser la technologie? Cela correspond-il à votre calendrier? Avez-vous les compétences nécessaires pour l'utiliser efficacement? Vos artistes / designers aiment-ils la technologie?
Intérêt
Si vous travaillez plus (ou prévoyez de travailler) avec des développeurs que seul, vous devez évaluer dans quelle mesure les autres personnes s'intéressent à la technologie. Si vous travaillez avec un ancien moteur / framework que tout le monde déteste, il vous sera difficile de trouver des développeurs motivés pour votre projet.
Considérez également comment les artistes et les designers interagiront avec la technologie. Voulez-vous créer des outils pour rattraper la fonctionnalité Unreal? Ils compareront inévitablement les capacités du moteur et les leurs. J'ai entendu dire que même les studios AAA ont un problème avec les artistes nécessitant des fonctionnalités Unreal qui ne sont pas encore implémentées dans le fork actuel du studio Unreal.
Si vous travaillez seul, vous devez entretenir une forte passion pour les projets. Si vous détestez la technologie avec laquelle vous travaillez, alors abandonnez probablement le travail. Si vous abandonnez, tous vos efforts seront réduits en poussière (à l'exception d'une expérience inestimable).
Que vous donnent-ils vraiment?
Jonathan Blow a une vidéo incroyablement sage sur ce que
les moteurs de jeu donnent réellement . Ils résolvent des problèmes «simples» pour vous, mais ils gênent quand ils essaient de résoudre un problème difficile, qui constitue des jeux passionnants.
Oui, bien sûr, vous obtenez un excellent éditeur, des outils de niveau professionnel et un moteur qui est venu à des milliers de développeurs, mais vous le payez avec de nombreux autres aspects:
- Parfois, les solutions qui y sont utilisées sont trop généralisées: peut - être que dans votre jeu la gravité est appliquée d'une manière complètement nouvelle, mais alors vous devez vous battre avec le système de gravité Unreal défini de manière rigide. Peut-être que vous créez un projet avec un modèle de réseau complexe, puis vous devrez vous débarrasser complètement de l'architecture du serveur Unreal.
- Parfois, les solutions sont trop spécialisées: si vous vous êtes plongé dans les tripes d'Unreal Engine, vous avez vu que tout le moteur est criblé d'un code de tir à la première personne. Si vous créez un jeu de ce genre, tant mieux. Sinon, ce ne sera que source de confusion.
- Parfois, il y a trop de choses dans le moteur: cela met à rude épreuve le cerveau et l'ordinateur. Réaliser une simulation complète de la physique du solide, un pipeline 3D avec une animation squelettique et trois cadres est un buste absolu pour un jeu 2D. Vous devrez trouver comment désactiver toutes ces fonctionnalités Unreal, bonne chance avec ça. Personnellement, je trouve que les performances d'Unreal sont décevantes même dans des mondes de test avec peu d'objets.
Vous devez poser la question: "De quoi ai-je vraiment besoin?" Débarrassez-vous de tout ce qui est superflu. Chaque système inutile est une perte de temps et de ressources.
Qu'est-ce qui est nécessaire pour votre projet?
La technologie doit être gérée par votre projet, sauf s'il s'agit d'une démonstration technologique. Si vous créez un jeu, vous devez travailler uniquement avec les technologies qui influencent le jeu - uniquement avec les plus nécessaires pour transmettre votre vision. Si le moteur vous offre le moyen le plus rapide de sortir votre jeu, alors c'est un bon choix. Mais ce ne sera pas toujours le cas!
Il y a des jeux réussis qui serviraient le mauvais service de l'un des moteurs disponibles:
- Pour Dreams , un rendu personnalisé a été écrit qui simplifie et accélère la création intuitive des ressources 3D.
- No Man's Sky utilise activement de toutes nouvelles méthodes de génération procédurale. Lors de la mise en œuvre de telles choses dans le moteur, vous devrez constamment y faire face.
- Dans Minecraft , seules quelques-unes des fonctionnalités des moteurs standard pouvaient être utilisées.
L'avenir de votre (et de notre) industrie
Lorsque vous utilisez une technologie, il convient de penser à la
fermeture . Joel Spolsky a une série d'articles sur une stratégie commerciale pour le développement de logiciels, dans laquelle il réfléchit sur la
fermeture du produit . En bref, son idée est que les entreprises sont intéressées à vous obliger à utiliser leur produit, car si vous n'utilisez pas le produit, elles ne gagnent pas d'argent. Les maîtres dans la capture d'industries entières sont Apple, Microsoft, Adobe et Autodesk, ils créent le sentiment qu'il n'y a pas d'autre alternative que leur logiciel.
La fermeture affecte même les développeurs amateurs / solo. J'ai un ami qui est constamment en difficulté avec Unity (mises à jour de rupture de compatibilité, système de prototypage, adware, support 2D médiocre ...). Il veut s'éloigner d'Unity, mais est fortement verrouillé dans ce moteur car la plupart de son code (et de ses données) repose sur l'API Unity.
Pourquoi les moteurs achètent-ils?
Unreal et Unity sont dictés par les exigences du marché. Leurs clients de niveau AAA, avec l'aide de plusieurs millions de contrats, déterminent le cours du développement futur des moteurs. Si vous travaillez sur un jeu dont la structure ne coïncide pas avec les objectifs de ces joueurs AAA, les développeurs des moteurs ne vous serviront pas aussi fidèlement. Par exemple, les jeux de voxels bidimensionnels, procéduraux, expérimentaux et les jeux avec de grandes quantités de données doivent presque toujours chercher quelque chose qui leur est propre.
Plus les fonctions semblent lumineuses, plus la direction des entreprises (qui n'est le plus souvent pas des technophiles) cherche à utiliser des moteurs. Des fonctionnalités telles que les plans du moteur Unreal sont très populaires auprès des artistes et des concepteurs, mais elles posent beaucoup de problèmes aux programmeurs. (Ceci est typique de tout langage de script; si vous autorisez des personnes qui n'ont pas étudié la programmation à programmer, le résultat sera médiocre, semblable à la gravité des graphiques dessinés par les programmeurs).
Les nouvelles fonctionnalités facilitent-elles vraiment la fin de votre jeu? Vont-ils vraiment ajouter de la valeur au produit final?
Lutte contre la centralisation
Chaque fois que l'un des studios passe de son propre moteur à Unreal ou Unity, les sociétés Epic et Unity gagnent encore plus de puissance dans l'industrie du jeu. Au début, une telle centralisation peut sembler rentable (après tout, 500 ingénieurs travaillent sur le moteur, excellent!), Mais dans quelques décennies cela deviendra un vrai problème. Google vient à l'esprit: cette entreprise a capturé la grande majorité des fonctions que les gens utilisent sur Internet, et cela leur a coûté la perte d'une grande partie de la vie privée.
Même au niveau des loisirs, l'abandon de la recherche en faveur d'Unreal ou Unity nuit aux générations futures de moteurs. Cela peut même nuire à Unreal lui-même: si tout le monde utilise Unreal, Epic ne pourra pas embaucher quelqu'un d'autre pour créer une nouvelle génération du moteur, car personne ne saura comment les moteurs de jeu sont écrits!
L'avenir peut être open source
Si nous, en tant qu'industrie, voulons croître, créer de plus en plus de produits de haute qualité, alors nous devons partager plus, pas moins, pour partager les technologies.
Je pense que l'industrie va dans cette direction, quoique extrêmement lentement. Cela est particulièrement vrai des studios de jeux de niveau AAA, qui cachent toujours le code de leurs moteurs pour obtenir un avantage concurrentiel (imaginaire?).
- Microsoft a fait d'énormes pas dans cette direction. Si même ils changent, je suis sûr que les autres le peuvent.
- Le contrat de licence Unreal contient une clause qui vous permet de vous fier à son code lorsque vous travaillez sur son propre moteur (propriétaire ou gratuit). Je pense que c'est un grand progrès.
- Grâce à son ouverture totale et son accès gratuit, Godot gagne en popularité, et j'espère que s'il reçoit suffisamment de temps et de soutien, il deviendra un concurrent de Unity (et finalement Unreal).
- id Software (à l'époque de John Carmack) a publié le code source complet de Doom à Doom 3 . Carmack avait de nombreuses raisons de faire avancer une telle décision. Le plus convaincant pour les entreprises est que cela ne nuit pas aux ventes. Le modèle de shareware utilisé par Doom - le développeur donne le moteur et vend des données - peut être une stratégie efficace aujourd'hui. Si votre entreprise craint que des concurrents ne «volent» votre technologie, vous pouvez publier votre code après la sortie d'un nouveau jeu (comme id). Après le départ de Carmack, id semble avoir perdu tout intérêt à publier du code.
Qualité logicielle
Jonathan Blow et
Casey Muratori sont de fervents critiques des pratiques modernes d'écriture de logiciels. Leur point de vue est que nous créons des modules complémentaires sur des couches d'abstractions depuis si longtemps que nous obtenons d'énormes couches fragiles de déchets inutiles, ce qui ne nous permet pas d'écrire de meilleurs produits.
Peut-être que leur philosophie est plus proche de l'idéalisme que du pragmatisme (ce qui entraîne généralement un retard dans la sortie des jeux), mais si elle est proche de vous, alors vous ne devriez pas l'ignorer.
La vitesse, la qualité et l'élégance de votre technologie sont-elles importantes pour vous? Beaucoup de gens sont assez satisfaits de la réponse négative, mais certains veulent créer des programmes d'une manière plus «propre».
Quelles sont les alternatives?
Au lieu d'utiliser le moteur, vous écrivez simplement un jeu.
Les débutants pensent souvent qu'ils ont besoin d'un moteur pour créer un jeu. Avec une forte probabilité, ils devraient rejeter ce point de vue. Les débutants perdront du temps à mettre en œuvre des fonctions de moteur inutiles, au lieu de laisser le jeu décider lui-même de ce dont il a absolument besoin. Seul le jeu devrait contrôler ce dont le moteur a besoin (bien sûr, Unity peut être pris comme contre-exemple, comme exemple de l'approche «moteur d'abord»; Unreal Engine 4 a Paragon, Fortnite et Unreal Tournament pour soutenir ce concept, sans oublier des dizaines d'années d'expérience en libérant un nombre infini de jeux dans les versions précédentes des moteurs).
Utilisation de bibliothèques
Partir de zéro n'a de sens que si vous avez les compétences et prévoyez de créer de l'innovation dans un composant particulier (ou si vous avez des limites). Dans tous les autres cas, il existe de nombreuses bibliothèques d'intégration. C'est particulièrement bon lorsque vous savez que, par exemple, le système de physique standard convient parfaitement aux exigences de votre projet (cela est particulièrement important car pour mettre en œuvre votre propre physique, vous avez besoin de beaucoup de connaissances dans ce domaine).
Voici quelques bibliothèques qui peuvent combler l'écart entre le travail à partir de zéro et l'utilisation d'un moteur entièrement fini:
- Graphiques: SDL, SFML, Ogre
- Physique: Bullet, PhysX (qui est récemment devenu open source - une énorme victoire!)
- Son: SDL, SFML
Ce n'est qu'une très petite fraction des bibliothèques existantes.
Un grand avantage de l'utilisation des bibliothèques est qu'il vous offre la plus grande flexibilité parmi toutes les options. Si vous écrivez tout le code dans un seul moteur, vous devrez faire d'énormes efforts pour le porter. Si vous écrivez un jeu comme une collection de bibliothèques, vous avez une grande mobilité et pouvez remplacer des sous-systèmes entiers. Si la bibliothèque ne répond pas à vos besoins, vous pouvez en essayer une autre ou même écrire votre propre remplacement.
De plus, Unreal et Unity prennent en charge l'importation de bibliothèques liées dynamiquement. Cela signifie que vous pouvez commencer à travailler avec les bibliothèques, puis passer à Unreal sans avoir à réécrire tout le code de base du gameplay, car il se trouve dans la bibliothèque. Pour que le code soit suffisamment flexible pour de tels changements, une réflexion sérieuse est nécessaire, mais je pense que cela en vaut la peine pour un projet moyen ou à long terme.
En conclusion
J'ai présenté plusieurs points de vue sous lesquels les technologies peuvent être prises en compte lors de leur choix. Passez quelques semaines sur une étude détaillée, ce qui peut vous faire économiser plusieurs mois de travail de portage ou même des années de désagréments à l'avenir.
En fin de compte, votre tâche principale est de terminer le projet. Vous devez vous efforcer de trouver le chemin le plus court pour résoudre ce problème. Cela peut être tout à fait inattendu pour vous!