Quels sont les avantages d'OpenGL nu par rapport aux frameworks / moteurs pour les petits développeurs? [fermé]

J'ai remarqué une tendance des développeurs indépendants à s'éloigner des frameworks et des moteurs, et à se diriger vers l'utilisation d'OpenGL nu, ou à l'utiliser en combinaison avec SDL / SFML2. En tant que développeur indépendant, je ne vois pas ce qu'OpenGL de bas niveau peut offrir sur des moteurs ou des cadres distincts.

La plupart des moteurs et frameworks décents offrent les fonctionnalités dont vous avez besoin et ne vous gênent jamais. Ils pourraient également ouvrir la possibilité de traiter directement avec OpenGL. Certains offrent même la fonctionnalité de compilation multi-plateforme!

Je comprends l'aspiration à apprendre ce qui se passe sous le capot, mais je ne vois aucun avantage qu'OpenGL pourrait offrir aux développeurs indépendants sur les moteurs ou les cadres.

Pourriez-vous expliquer le raisonnement derrière la construction de jeux à partir de zéro en utilisant OpenGL?

Il s'agit en grande partie d'une question / réponse basée sur une opinion, donc ce n'est pas nécessairement idéal pour cette plate-forme, mais de toute façon:

Pourquoi pas de framework / moteur indépendant? Voici mes deux cents:

• Manque de budget: c'est probablement le plus gros point pour la plupart des petits développeurs indépendants. De nombreux frameworks ou moteurs ne vous permettront pas de publier votre produit sans acheter une version plus chère (en supposant qu'une version bon marché ou gratuite soit disponible) et / ou payer des redevances, ce que vous devrez toujours considérer pour les petits projets. Parfois, vous devez même payer une fois par plate-forme également.
• Complexité: la plupart des moteurs ou frameworks appartiennent à l'une des deux catégories suivantes:
  • Ils sont soit très limités pour un genre spécial ( RPG Maker en est un exemple typique).
  • Ou l'yre est tout simplement trop générique avec beaucoup de choses que vous n'utiliserez probablement pas de toute façon (comme Unity ).
• Code propriétaire: la plupart des moteurs ne sont pas open source et pour obtenir la source réelle, vous devrez payer encore plus (si disponible). Sans le code source réel, le portage sur d'autres plates-formes peut être difficile, voire impossible (encore une fois, RPG Maker serait un exemple parfait).
• Clunkyness: C'est mon opinion personnelle, mais au moins pour moi, c'est souvent une déception plutôt énorme compte tenu des moteurs et des frameworks premade, surtout lorsque vous construisez juste un petit jeu. Qui veut jouer à un petit jeu de pause d'une taille de 200 Ko, mais avec un temps d'exécution de 50 Mo?
• Choix de la langue: certains moteurs et frameworks ne fournissent pas de bibliothèques à utiliser dans votre propre code. Au lieu de cela, ils fournissent un cadre ou un runtime qui utilisera son propre langage de script ou un langage défini (comme Javascript ou C #). Si vous écrivez votre propre moteur personnalisé, vous êtes libre d'utiliser la langue que vous avez choisie.
• Protection de votre travail: si vous utilisez un moteur ou un framework prédéfini, les chances sont élevées que d'autres pourraient avoir beaucoup plus de facilité à modifier ou décompiler votre code ou vos actifs, ce que vous voudrez peut-être éviter (même si c'est juste pour garder votre meilleur score) nettoyer). Le code personnalisé et la gestion des actifs ajoutent un obstacle beaucoup plus important à franchir, en particulier lorsqu'ils sont compilés en code natif.
• Image de marque: cela peut être mineur pour beaucoup, mais certains moteurs et frameworks vous obligent à afficher leur logo ou peut-être même des publicités, prenant essentiellement vos libertés pour choisir qui / quoi promouvoir. Bien sûr, cela dépend souvent de la licence réelle, des frais de licence, etc.
• Incompatibilité avec les licences: c'est quelque chose que beaucoup ne considèrent même pas lors du choix d'un moteur, mais selon ce que vous voulez faire, cela peut être un facteur majeur. Même si vous achetez un moteur, vous pourriez être empêché de divulguer des sources ou des documents connexes. Quelque chose comme ça pourrait rendre le modding impossible, même si vous souhaitez que les utilisateurs puissent le faire. Prenez le moteur Source de Valve ( Half-Life 2 , Team Fortress 2 , etc.) comme exemple: ils permettent aux moddeurs d'utiliser leur moteur pour leurs propres projets. Si ces jeux étaient basés sur (par exemple) Unreal Engine, cela ne serait pas possible, en raison des limitations impliquées par les conditions de licence.

La plupart des moteurs et frameworks décents offrent les fonctionnalités dont vous avez besoin et ne vous gênent jamais.

Est-ce qu'ils? Cela dépend plutôt exactement de ce que vous faites, graphiquement.

Pour de nombreux types de jeux, il existe des réponses standard aux questions graphiques. Le jeu 2D moyen par exemple peut être très bien géré avec les prouesses 2D de, par exemple, XNA / MonoGame. Ce ne sont que des sprites, qui peuvent venir par lots pour le terrain, peuvent être tournés, etc.

Mais que se passe-t-il si votre jeu était le jeu 2D moyen, vous lisez des techniques intéressantes, telles que l'utilisation d'une carte de hauteur pour construire un imposteur qui a l'apparence de la profondeur par rapport à l'écran. Et vous voulez faire ça.

Vous utilisez maintenant un mappage normal et peut-être même un mappage de parallaxe. Le tout dans le même contexte de "rendu des sprites", mais nécessitant plus que beaucoup de moteurs 2D purs. Plus précisément, cela nécessite un "sprite blitting" multitexturé, ce qui n'est pas quelque chose que de nombreux moteurs 2D peuvent faire.

Que faites-vous si votre moteur ne peut pas s'adapter avec vous? Cela signifie donc que vous devez effectuer plusieurs passes, une pour la couleur et une pour l'éclairage via une carte normale. Mais cela ne fonctionne pas, car vous avez besoin du champ de hauteur normal de la carte pour utiliser le mappage de parallaxe avec la recherche de couleur. Et maintenant? Vous avez besoin de l'alpha pour faire de la transparence, donc vous ne pouvez pas voler l'alpha. Et le moteur ne prend tout simplement pas en charge les multitextures.

Vous devez donc choisir l'une des options suivantes:

1. Abandonnez l'idée. Cela signifie que votre jeu est fonctionnellement limité par votre moteur.
2. Piratez le moteur pour avoir le multitexture. En supposant que vous ayez accès au code source, vous vous chargez maintenant de piquer le code de quelqu'un d'autre. Cela signifie également que vous devez le maintenir et ne pas le casser avec vos trébuchements.
3. Faites de votre mieux, dans les limites du moteur. Vous pouvez donc obtenir la parallaxe sur les cartes normales, mais pas sur les couleurs. Ce n'est peut-être pas exactement ce que vous vouliez, mais c'est mieux que rien.

À titre d'exemple, prenez Geometry Wars. La plupart des moteurs 2D aspireraient à ces types de visuels, car la plupart d'entre eux sont construits autour de sprites de dessin, pas de lignes. C'est un jeu qui a besoin d'un rendu très spécialisé.

À la fin de la journée, vous devez assumer la responsabilité des éléments de votre jeu qui sont importants pour les besoins de votre jeu. Si l'apparence visuelle de votre jeu est principalement développée par le style artistique des images et des modèles que vous utilisez, plutôt que par des effets spécifiques, alors utiliser une solution pré-packagée est très bien. Mais si le style visuel de votre jeu est défini de manière significative par un code de rendu personnalisé, les chances sont bonnes qu'un moteur standard puisse devenir une sérieuse limitation si vous décidez de faire des choses qui sont hors de la boîte.

De plus, il y a un problème très pratique: tous les moteurs de jeu ne sont pas également portables.

Avec la récente montée en puissance des plates-formes mobiles, le marché des jeux est réparti sur de nombreux systèmes d'exploitation et appareils d'interface utilisateur. Tous les moteurs ne fonctionnent pas sur tous les appareils. Et si votre moteur ne fonctionne pas sur une plate-forme, vous ne prendrez certainement pas le temps de le faire fonctionner sur une seule. Après tout, c'est pourquoi vous avez utilisé un moteur en premier lieu, non?

S'il est important pour vous que votre jeu fonctionne sur une plate-forme particulière, vous devez à nouveau en assumer la responsabilité. Et la façon la plus "simple" de réussir avec cela est de le faire vous-même. Pour construire un moteur qui peut fonctionner sur plusieurs plates-formes, en utilisant peut-être des cadres spécifiques à la plate-forme plus simples lorsque cela est nécessaire pour gérer certains détails de bas niveau. De cette façon, s'il se casse, c'est votre code; vous êtes la meilleure personne pour y remédier.