Que dois-je considérer lors de l'évaluation des bibliothèques, des moteurs et des frameworks pour créer un jeu?

Je vais faire un jeu. J'ai remarqué qu'il existe de nombreux moteurs de jeu, bibliothèques et frameworks disponibles, et j'ai un peu de mal à décider lequel utiliser.

Je suis déjà assez bon avec certains langages de programmation, mais il y en a d'autres que je ne connais pas du tout. Je ne suis pas contre l'apprentissage de nouveaux langages de programmation, si cela peut vous aider, mais mon véritable objectif est juste de faire mon jeu.

Quels critères dois-je utiliser pour comparer les moteurs, les bibliothèques et les frameworks les uns aux autres, afin de pouvoir décider lequel me permettra d'être le plus productif pour terminer mon jeu?

C'est un peu comme choisir une voiture ou un ordinateur. Ou à peu près tout ce qui a des fonctionnalités variées, dont certaines vous tiennent beaucoup à cœur, d'autres qui ne vous dérangent pas et d'autres que vous ne souhaitez même pas inclure.

1. Faites une liste des fonctionnalités qui vous intéressent. Par exemple, support 2D / 3D, éclairage, physique, utilise un langage que vous connaissez bien, etc.
2. Classez-les en fonction de leur importance, en fonction de votre projet actuel.
3. Recherchez vos options et pour chaque option, essayez de classer leurs fonctionnalités de support en fonction de leur adéquation avec les objectifs de votre projet.
4. Utilisez celui qui correspond le mieux à vos objectifs. Alternativement, vous pouvez sélectionner les premiers et leur donner un essai routier. Mettez en œuvre une fonctionnalité simple de votre jeu et voyez celle que vous préférez.

Je pense que cela revient en grande partie à savoir ce que vous voulez. Ce qui signifie que vous devrez avoir une assez bonne idée du jeu que vous créez. Ce qui signifie probablement que vous aurez besoin d'un plan assez détaillé sur la façon d'implémenter votre jeu et ce qu'il comprendra. En prime, avoir toutes ces informations détaillées vous aidera en fait à terminer votre jeu. Il est beaucoup plus facile de suivre un plan et de cocher des choses sur une liste que d'avoir une idée de jeu et de commencer à écrire du code.

Vous devez d'abord avoir une idée approximative de ce que sera votre jeu et de ce dont il aura besoin. Il y a les questions habituelles comme si oui ou non votre jeu aura besoin de physique. Ensuite, il y a les questions interdépendantes, qui concernent principalement l'environnement dans lequel votre jeu sera développé et exécuté et la façon dont votre jeu est ou non commercial.

• Quelles plateformes soutiendrez-vous? Sur quelle plateforme développez-vous votre jeu?
• Dans quel (s) langage (s) de programmation comptez-vous implémenter votre jeu?
  • Ceci est influencé par les plateformes que vous avez l'intention de prendre en charge.
• Quels types de graphiques, d'audio et d'entrée votre jeu aura-t-il?
• Votre jeu est-il gratuit ou open source, ou est-il commercial?
  • Si vous êtes open source, voudrez-vous devenir commercial plus tard, soit avec votre jeu, soit avec un autre jeu qui utilise le moteur de votre premier jeu?

Si vous allez être uniquement Windows, les bibliothèques basées sur DirectX et C # sont de bons candidats. Si vous voulez être multiplateforme, vous voudrez peut-être regarder les bibliothèques basées sur OpenGL et C / C ++, ou Flash si votre jeu est en 2D et vous pouvez vous permettre les outils d'Adobe. Comme votre plateforme, votre langage de programmation influencera vos bibliothèques disponibles. Un programme écrit en C ++ aura du mal à appeler une bibliothèque Java.

Si votre jeu est commercial, vous pouvez envisager d'acheter un moteur comme Unity. Si votre jeu est gratuit ou open source, vous voudrez vous concentrer sur les bibliothèques qui sont également open source, ou du moins gratuites pour les projets non commerciaux. Les bibliothèques open source sont également utiles pour les projets commerciaux. Lorsque vous regardez des bibliothèques open source, assurez-vous de vérifier leur licence. Certaines licences vous obligent à créer des parties de votre propre logiciel open source selon la façon dont vous utilisez une bibliothèque. Vous limiter aux bibliothèques open source placera évidemment une autre limite sur les bibliothèques que vous pouvez utiliser.

Lorsque vous regardez une bibliothèque, assurez-vous de vérifier à quel point son développement et sa communauté sont actifs. Je ferais confiance à une bibliothèque qui est bien connue et qui gère activement plus d'une bibliothèque qui est hébergée sur la page Web de l'université de quelqu'un qui n'a pas été mise à jour depuis 1999.

Une dernière question, surtout si ce n'est pas votre premier projet de jeu, est de savoir si certains aspects de votre jeu auront besoin et que vous savez que vous aurez du mal à faire si vous essayez de le faire vous-même. Parce que ces aspects en particulier sont des candidats pour trouver une bibliothèque. Si votre jeu nécessite une détection de collision et que vous savez que vous ne pouvez pas implémenter la détection de collision vous-même (comme je ne le peux pas), envisagez de prendre un moteur physique et de tirer parti des fonctionnalités de détection de collision qu'il contient.

• La bibliothèque fait-elle ce dont vous avez besoin?
• Est-il spécialisé pour faire ce dont vous avez besoin? Combien d'encombrement y est attaché?
• Comment est-il conçu? Voulez-vous vomir quand vous le voyez? Si oui, ce n'est probablement pas le meilleur choix pour votre santé et votre santé mentale.
• Est-il suffisamment flexible pour répondre à vos besoins? Il n'est pas bon de remarquer que la bibliothèque ne fonctionne pas après avoir déjà écrit la moitié de votre code avec.
• Quelle est la pérennité de la bibliothèque? Le développeur ajoute-t-il des fonctionnalités au fil du temps? Est-il en train de réparer les choses? Améliore-t-il les choses? Cela peut faire toute la différence s'il est probable que le développement de votre jeu prenne quelques années. Pas si important pour les petits projets que vous aurez dans un mois.
• La taille est-elle appropriée? Pour les petits projets, cela peut faire une grande différence si le joueur doit télécharger 20 Mo ou 200 Mo. Les projets plus importants sont probablement suffisamment grands pour que la taille du middleware ne fasse pas de différence.

En plus des fonctionnalités spécifiques au jeu que les gens ont commentées, vous devriez également considérer quelques questions générales.

1. structure de support - même si le moteur de jeu est parfait, le support est peut-être trop cher ou inexistant.
2. à quel point est-il facile d'apprendre - vous ne voudrez peut-être pas quelque chose de trop grand, car le temps d'apprendre peut être prohibitif.
3. couvre-t-il vos projets futurs - vous ne voudrez peut-être pas investir du temps à apprendre un moteur parfait pour l'instant, seulement pour réapprendre un tout nouveau moteur à partir de zéro pour le prochain projet. Ou peut-être que vous le voulez.
4. licence - si vous créez un jeu en source fermée, assurez-vous que la licence du moteur ne le rend pas open source.

Un petit cheat sheet pour évaluer les bibliothèques, les frameworks, les moteurs et les SDK et choisir les meilleurs

• Les bibliothèques, les frameworks, les moteurs SDK, etc. sont des outils destinés à résoudre des problèmes pour vous ou à vous aider à résoudre des problèmes et à répondre à certaines exigences.
• Évaluer signifie trouver celle qui répond le mieux aux exigences.

Par conséquent, avant même de commencer à évaluer, vous devez être clair dans quel scénario vous êtes et quelles exigences vous avez / voulez avoir car ce sont les questions auxquelles l'évaluation doit répondre.

Le scénario définit d'où viennent les exigences (qui décide ce qui est une exigence et ce qui ne l'est pas).

Les scénarios typiques sont:

Le scénario de projet le plus hobbiest

Vous seul ou avec des amis souhaitez créer votre (peut-être le premier) jeu. Parfait, vous pouvez tout décider par vous-même et vous n'êtes limité qu'aux exigences techniques de base et aux exigences techniques (que ce soit un jeu mobile, un jeu PC, un jeu console, un jeu web, ....). Vous pouvez décider ce que vous voulez.

Les exigences implicites seront que vous souhaiterez peut-être apprendre quelque chose de spécifique (un langage, un framework / moteur spécifique)

Le scénario étudiant

Les exigences peuvent provenir de votre professeur. Exigences typiques que j'avais dans ce cas: le jeu doit avoir des éléments physiques et un support réseau multijoueur. Ou il doit être écrit en C ++. L'évaluation devient donc facile. Vous recherchez un moteur de jeu qui vous permet de coder en c ++ et qui peut déjà inclure un moteur réseau et physique.

Une exigence plus mauvaise (la vie réelle): tout doit être écrit à partir de zéro (mais l'utilisation de bibliothèques est autorisée). Aucun éditeur n'est donc autorisé (par exemple Unity3D). Vous ne recherchez donc pas des moteurs / sdks mais des bibliothèques.

Le scénario du jeu indépendant

Vous voulez gagner de l'argent avec le jeu plus tard. Pour cela, vous devrez le vendre d'une manière ou d'une autre, ce qui vous amènera à vérifier quelles exigences proviennent du magasin sur lequel vous souhaitez vendre votre jeu.

Autorise-t-il les jeux Java, les jeux HTML5, ....)

Faut-il que vous incluiez des bibliothèques spécifiques (si oui, dans quelles langues ces bibliothèques sont-elles disponibles)

Google Playstore vous demandera d'écrire votre jeu en tant que jeu Android, Apple AppStore vous demandera d'écrire votre jeu en tant qu'application iOS. Ou vous devez choisir un moteur multiplateforme.

Le scénario professionnel

Vous avez non seulement un magasin fournissant des exigences, mais très probablement un éditeur ou un client ayant ses propres imaginations d'exigences. Dans ce scénario, vous aurez également une plus grande équipe de développeurs employés. En fonction de leurs compétences, de nouvelles exigences se posent (nos programmeurs ne peuvent écrire qu'en c ++, nous ne pouvons donc pas utiliser un moteur de jeu Java / Android pur sans qu'ils aient besoin de (beaucoup de) temps pour apprendre quelque chose de nouveau).

Je n'entre pas dans les détails de ce scénario, une fois que vous avez réussi à constituer une équipe d'employés et à trouver un client / éditeur, vous savez déjà ce que vous recherchez pour évaluer les choses.

Comment puis-je décider quelles sont mes exigences lorsque je suis un hobbiest ou un indi et que personne d'autre ne me le dit?

Posez-vous des questions sur vos objectifs et votre jeu?

• Quel devrait être mon jeu? mobile, pc, web (html / Js), quels contrôleurs vais-je utiliser (écran tactile, gyroscope, manette de jeu)

• Ce qui est nouveau dans mon jeu et ce que les autres jeux ont aussi. Les parties que les autres jeux ont également (rendu, audio, gestion des entrées) seront effectuées par la plupart des outils (moteurs de jeu) que vous pouvez trouver ou il est facile de regrouper des bibliothèques ayant cette fonctionnalité dans votre propre jeu ou moteur de jeu.

• Quelle est la dimension de mon projet: oiseaux en colère ou skyrim? Angry Birds peut être fait dans presque tous les outils et skyrim serait limité aux outils haute performance avec des années (supposées) de personnalisation supplémentaire (les moteurs de terrain haute performance ne sont pas faciles)

• Mon seul objectif est-il simplement de terminer un match? Oui? parfait, vous pouvez utiliser quelque chose de très avancé comme Unity, Unreal, ... avoir un éditeur pratique et une grande communauté vous fournissant des tutoriels et répondant à vos questions. Il enlève le fardeau de la gestion des tâches de bas niveau comme le chargement de maillage, l'implémentation de vos propres fonctions mathématiques, ....

• Mon objectif est-il d'apprendre quelque chose de spécifique? Oui? que voulez-vous apprendre?

• Quelle langue dois-je choisir? Si l'objectif est toujours juste de terminer votre jeu, choisissez celui que vous / votre équipe connaissez le mieux? Si vous voulez apprendre une langue spécifique, vous choisirez un outil dans cette langue.

• L'outil X aura-t-il suffisamment de performances pour mon jeu? Peut-être que vous ne le saurez jamais. Même dans les grandes productions, la phase d'optimisation et de polissage prend beaucoup de temps et est un énorme travail pour y arriver. Commencez à vous soucier des performances lorsque vous rencontrez des problèmes de performances. Vous ne savez pas comment l'outil fonctionnera à moins d'atteindre ses limites. Tout sur le site Web du développeur d'outils n'est qu'une approximation. Après des années d'évaluation des outils, j'ai cessé de croire quoi que ce soit du site Web des développeurs.

Répondre à ces questions vous amène aux exigences. L'évaluation consiste à trouver une liste d'outils et à TESTER (et pas seulement à lire la page d'accueil) ce que l'outil peut fournir ou non.

Les exigences ne sont pas gravées dans la pierre mais sont dynamiques. Ils vont et viennent pendant le développement. Si le jeu a besoin de physique ou non, par exemple, cela dépend de la conception. Si la conception change, l'exigence peut également changer.

Prenez les exigences que vous avez et commencez. Les exigences changeantes sont le pain quotidien de la souffrance, ahm, des développeurs heureux, indépendamment de la taille du projet et du niveau d'expérience.

Allez ici .

Malgré le nombre de moteurs de jeu disponibles, vous n'avez en fait pas beaucoup de choix.

1. restrictions de licence. Certains moteurs entraveront votre capacité à publier votre produit sans d'abord payer des frais de licence importants, par exemple Unity , utilisé pour facturer des frais supplémentaires pour la compilation sur iOS, par exemple (cela a changé en 2016 )
2. plates-formes. Vous souciez-vous de cibler plusieurs plateformes? Lesquels?
3. 2D ou 3D? Certains moteurs répondent à la 2D.
4. Nécessite de la physique? Certains moteurs fournissent de la physique
5. FPS, RTS? Il peut être judicieux d'utiliser un moteur spécialisé pour le type de jeu que vous créez.
6. De toute évidence, vous aimeriez travailler dans votre langue préférée. Vous n'aimez pas C? Alors n'utilisez pas Allegro!
7. Êtes-vous un grand modèle de conception, fan OOP? Modèles bien connus de «surutilisation» d'OGRE
8. Développement actif? Vous devriez considérer le compromis entre la disponibilité des fonctionnalités de pointe (DX11 / OGL 4) et la stabilité d'un moteur dont le développement a ralenti il ​​y a quelques années
9. Base d'utilisateur? Une large base d'utilisateurs signifie généralement de meilleurs forums, donc plus facile de répondre à vos questions