Informatique

Le c++ étant inutile lorsqu’on utilise un moteur de jeu (les blueprints étant plus simples et pratique) est-il plus logique pour une équipe amateur de ce concentré sur un effectif le maîtrisant ? Et quelles sont ses limites ? À l’inverse quels sont les avantages et inconvénients de créer un moteur de jeu et privilégier des développeurs ?
Merci à l’avance pour vos réponses

Je pense qu'on ne peut pas faire plus complet que ça pour le C++ vs Blueprint, ça vient d'Epic Games en plus https://docs.unrealengine.com/en-US/Resources/SampleGames/ARPG/BalancingBlueprintAndCPP/index.html

Sinon pour reprendre certains de tes points car tu as l'air de mélanger plusieurs choses :

-Déjà les Blueprints ça ne concerne qu'Unreal Engine 4. D'autres moteurs ont du visual scripting mais quand on parle de Blueprint on parle de lui explicitement

Le c++ étant inutile lorsqu’on utilise un moteur de jeu (les blueprints étant plus simples et pratique)

TLDR : Le mieux c'est de faire un hybride des 2

Le C++ ne devient pas inutile, en général je crée mes classes mères en C++ avec des fonctions/variables de base que je choisis d'exposer ou non pour ensuite créer des classes BP basées sur celles-ci. Je trouve cela plus lisible personnellement (encore une fois ça dépend des personnes) et je me sers de la rapidité qu'offrent les BP pour prototyper à mon avantage. Une fois que mes tests sont bouclés, je passe en général les parties BP que j'estime pertinentes en C++. J'y gagne en performance et en lisibilité.

est-il plus logique pour une équipe amateur de ce concentré sur un effectif le maîtrisant ? Et quelles sont ses limites ?

Le but d'une équipe c'est de sortir le jeu le plus rapidement possible avec des performances solides. Les BP aident à ça car ça permet de prototyper très rapidement. De plus les questions de performance ne se posent généralement pas à moins de faire un jeu très exigeant niveau calculs.
Par contre à mesure que le projet va grossir il va falloir avoir une organisation/convention en béton armé pour ne pas se perdre avec tous les nodes et un outil de source control bien maîtrisé (perforce par exemple). Sinon c'est vraiment casse gueule alors qu'avec du C++ github/gitlab et le format de code rendent le tout bien plus lisible à mon sens.

À l’inverse quels sont les avantages et inconvénients de créer un moteur de jeu et privilégier des développeurs ?

Comme j'ai dit au-dessus je pense que tu ne connais pas bien UE4 et que tu ne sais pas qu'on peut faire de l'hybride C++/Blueprint voire qu'on peut coder en C++ dessus.

Les limites de créer un moteur de jeu c'est qu'à moins d'avoir un jeu assez simpliste ou très spécifique va falloir se retrousser les manches, tout coder en C++ avec Opengl par exemple tout ça pour au bout de 4/5 ans pour des personnes expérimentées aboutir à un moteur fonctionnel qui n'aura même pas 1/100e des fonctionnalités des moteurs disponibles. Et tu n'auras même pas commencé le jeu.

Du coup à moins de faire ça à but didactique (en apprendre plus sur la 3D en info, buffers, shaders etc) y a très peu d'intérêt. Même les gros studios se plantent dessus parfois, cf Square Enix. Ils recommencent très très rarement un nouveau moteur à partir de zéro

M

Merci pour ta réponse rapide et complète
Je ne parle que d’ue4 car c’est le moteur qui m’intéresse le plus et ma question se basait sur une équipe d’amateur
Donc celon toi l’utilisation des blueprint pourrait se suffir à elle même mais on pourrait l’optimiser avec du c++ ?
Et donc une équipe amateur aurait avantage à se concentrer uniquement sur du blueprint comme dis précédemment puisque apprendre le c++ ne serait pas rentable en terme de temps/efficacité ?

Le 21 novembre 2019 à 00:03:13 ericvoubz a écrit :
Merci pour ta réponse rapide et complète
Je ne parle que d’ue4 car c’est le moteur qui m’intéresse le plus et ma question se basait sur une équipe d’amateur

Ca marche, je précisais au cas où.

Donc celon toi l’utilisation des blueprint pourrait se suffir à elle même mais on pourrait l’optimiser avec du c++ ?
Et donc une équipe amateur aurait avantage à se concentrer uniquement sur du blueprint comme dis précédemment puisque apprendre le c++ ne serait pas rentable en terme de temps/efficacité ?

Franchement ouais, apprendre en même temps le C++ et Unreal c'est casse gueule, laissez tomber si vous n'avez aucune connaissance dessus et concentrez-vous sur l'apprentissage d'Unreal et des Blueprint, vous aurez déjà assez à faire avec ça. De nombreux jeux ont été sortis en Blueprint only, c'est parfaitement possible de faire un projet abouti avec.

Ok merci beaucoup pour tes réponses parce que je vois rarement des gens recruter des personnes qualifiées en blueprint mais plus souvent des développeurs etc donc d’où ces questions

Le 21 novembre 2019 à 00:52:20 ericvoubz a écrit :
Ok merci beaucoup pour tes réponses parce que je vois rarement des gens recruter des personnes qualifiées en blueprint mais plus souvent des développeurs etc donc d’où ces questions

C'est parce que les studios de JV vont rechercher des développeurs qui seront capables de travailler avec leur solution maison et les améliorer ou s'ils bossent sur UE4 étendre les fonctionnalités du moteur ou coder des plugins privés pour faciliter les transferts d'assets à partir de leurs outils. Et aussi un développeur apprendra rapidement à se servir des BP car ça reste de la programmation visuelle. Les BP sont très spécifiques à UE4 alors que des personnes sachant programmer dans des langages "classiques" pourront appliquer leurs connaissances sur différents projets/logiciels.

Tu ne verras des demandes de qualification en BP si l'offre d'emploi annonce explicitement chercher du personnel pour bosser sur UE4, ce sont souvent les technical designer qui s'en servent.

Vu que vous êtes une équipe amateure cherchant à sortir un jeu ces considérations ne vous concernent pas, si vous souhaitez décrocher un job dans l'industrie plus tard par contre ça peut valoir le coup selon le post convoité d'apprendre la programmation.

Le c++ étant inutile lorsqu’on utilise un moteur de jeu (les blueprints étant plus simples et pratique)
est-il plus logique pour une équipe amateur de ce concentré sur un effectif le maîtrisant ?

Tout depends de la taille du projet en effet. Pour des jeux simple ou "moyens", le blueprint peut suffire. Les bases sont deja posées dans UE4 et tu peux faire tout le gameplay en blueprint. Dans ce cas, le C++ n'intervient que lorsque tu as des fonctionnements complexe ou des algorithmes gourmands a integrer.

Pour des jeux plus ambitieux, c'est une combinaisons entre C++ et blueprint (n'oublions pas que le blueprint, ce sont des "nodes" qui appellent des fonctions C++).

> À l’inverse quels sont les avantages et inconvénients de créer un moteur de jeu et privilégier des développeurs ?

Il faut beaucoup de competences pour creer un moteur, il faut beaucoup de monde pour le creer et le mettre a jour. En gros quand tu aura fini ton moteur il est fort possible qu'il doit depassé graphiquement. L'avantage c'est que tu maitrise tout dedans et que tu peux le faconner suivant le besoin de ton jeu (tu peux faire un moteur pour le type de jeux que tu fais par exemple).

Faut dire aussi, qu'Unreal est plus récent et plus abouti qu'Unity par exemple, donc moins grande communauté, moins d'entraide (tutos, etc.) et moins de ressources.
Mais permet également peut-être un peu plus de liberté avec le B.P.
Pour cela aussi sans doute que les entreprises préfèrent recruter des programmeurs C++, qui pourront plus aisément manipuler le B.P.

Bonjour,

Le 21 novembre 2019 à 17:21:26 zebtorax a écrit :
Unreal est plus récent et plus abouti qu'Unity

Unreal c'est 1998, A l’époque, l’éditeur étais nommé UDK, unity c'est 2005 ^^.

Le 21 novembre 2019 à 09:06:15 Lapintade a écrit :
Tout depends de la taille du projet en effet. Pour des jeux simple ou "moyens", le blueprint peut suffire. Les bases sont deja posées dans UE4 et tu peux faire tout le gameplay en blueprint. Dans ce cas, le C++ n'intervient que lorsque tu as des fonctionnements complexe ou des algorithmes gourmands a integrer.

Pour des jeux plus ambitieux, c'est une combinaisons entre C++ et blueprint (n'oublions pas que le blueprint, ce sont des "nodes" qui appellent des fonctions C++).

Depuis plusieurs années maintenant, je ne programme plus qu'en blueprint (gain de temps) pour le compte d'entreprises, fini le c++ de mon côté, sauf de très rare bouts de code (a force des mises a jour, de moins en moins de c++ requis).

Coder en blueprint ou en c++ sur Unreal engine reviens a la même chose, toutes les classes sont déjà codés si on veut faire des hooks.
Un hook en c++ va appeler la fonction c++ de base du moteur, si tu le fais en BP, ça va appeler la fonction c++ de base du moteur aussi (aucune diff, que ce soit en c++ ou BP).

Si on veut du code custom (classe sans parent) on peut le faire en BP ou en c++ (la encore, on va appeler les fonctions c++ de base du moteur qu'on en a besoin, que soit en c++ ou BP).
Si le blueprint étais juste la pour appeler son code c++ il n'aurais aucun intérêt et autant tout écrire en c++ (la seule chose que j’évite d’écrire en BP, c'est les Bind, même si c'est faisable, c'est juste pas opti).

Le BP n'est pas non plus moins performant que le c++, si on sais optimiser un code en c++, pourquoi on ne pourrais pas optimiser un code en BP?.
Le BP n'a pas été créé pour permettre a des gens qui ne savent pas programmer, qu'il puisse faire un jeu, a force il le permet, mais en soit c'est juste une manière différente d’écrire son code.
Mon point de vue est que le BP est la pour faciliter et accélérer l’écriture du code, rien de plus.

Il y a quelques années oui, il étais impossible de faire un vrai jeu en full BP, mais ce n'est plus le cas.
Pour moi, ça reviens a la même chose que le jeu soit en full BP ou c++, sinon, tous les jeux auquel j'ai participé seraient en c++ et on ne me permettrais pas de tout écrire en BP.

Pour info, j'ai démarré sur Quake Engine (Quake, 1995), GoldSrc (HL1, 1998, maj de Quake engine) et UDK (Unreal, 1998), en gros j'ai plus de 15 ans d'unreal engine.
J''ai aussi fais des jeux en directx et openGL, mais on perd trop de temps de conception car on dois faire un moteur, faire un éditeur de map, et ensuite commencer a faire le jeu, au final le jeu est dépassé a sa sortie.

Le 10 décembre 2019 à 22:40:55 sstephh a écrit :
Bonjour,

Le 21 novembre 2019 à 17:21:26 zebtorax a écrit :
Unreal est plus récent et plus abouti qu'Unity

Unreal c'est 1998, A l’époque, l’éditeur étais nommé UDK, unity c'est 2005 ^^.

Bien vu. Merci pour l'info...
Mais comme tu le dis toi même c'était moins fastoche à l'époque avec UDK. Le moteur était encore un peu une véritable usine à gaz, tandis qu'Unity semblait être une bonne alternative pour du cross-plateformes, notamment pour le web et mobile.
L'UE4 est beaucoup plus récent qu'Unity. Ce serait bien d'avoir une date, pour le coup...

UE4, c'est une maj d'UDK si tu préfères il y a juste eu un changement de nom, et était déjà compatible pc et linux, la structure et les classes restent les mêmes.
Il dois bien y avoir des versions d'Unity, j'imagine qu'a notre époque, vous codez pas sur la 1.0 ^^.

Je vais pas surenchérir l'argumentation au risque de réveiller le troll bien connu Unity Vs Unreal.
C'est du trop déjà vu, poah.

Mes messages n'ont pas pour but de troll, tu me demande une date pour UE4, alors qu'UE c'est UDK ^^, le plus simple tu veux faire du c go unity, du c++ unreal, le reste c'est seulement des préférences perso, et puis j'y connais rien sur Unity :p

Très bien, un simple ressenti me fait dire qu'à l'époque Unity était une meilleure alternative, plus simple d'utilisation et plus abordable pour du cross-plateforme, tandis que, je n'ai pas de grand souvenir mais UDK semblait être plus difficile à prendre en main.
Mais maintenant c'est plutôt l'inverse, depuis l'UE4 semble avoir rattrapé son retard sur Unity, bien que cela reste encore un peu juste au niveau des ressources (tutos, store, etc.) Le fait est qu'Unity continu à progresser de son côté également.

UDK C'est Unreal 3. Il y a eu de vrais gros changement pour UE4 (passage du script au C++/Blueprint).
UE4 c'est 2012 et passé en public en 2014.
Quand a la difference blueprint/C++, elle est importante sur les gros algorithme (le blueprint reste du langage interprété).
Pour les projets très avancés, le C++ est necessaire, voir meme modifié le moteur (c'est ce qu'on fait en ce moment).
Mais pour les projets moins abouttis, le blueprint est largement suffisant.

Modifier le moteur ?
Pour quelles raisons ?
J'espère que ce n'est pas " top secret ultra confidentiel " au moins...