Bonjour à tous, je voudrais savoir quel moteur essayer pour un projet perso.

Je n'ais pas de connaissances en C++ (que de vieille bribe, mais pendant presque 15 ans sans y toucher, c'est devenus proche du néant), je voulais donc avoir votre avis, puisque n'utilisant pas le C++, si les blueprints étaient suffisant, ou si je devais absolument apprendre le C++, ou si un mix C++ + Blueprint serait plus avantageux ?

J'ai pour projet, de tenter un open world, en vus TPS, sur un mix Fantasy/fantastique proche de l'ambiance Lovecraftienne, je n'aurais pas besoin d'un physique super élaboré comme celle du Cryengine (de toute maniere il me semble que ce dernier n'est pas u tout fait pour des débutant), mais j'aimerais quand même une interaction environnemental comme dans Zelda (pas BOTW faut pas déconner non plus), mais au moins de quoi déplacer des éléments, tirer des poutre avec son grappin ou se balancer etc.

Du coup au vus du projet quel serait le meilleur des deux pour moi?
Je sais qu'il y a quelques années ont m'aurait dit d'office unity, ne serait que pour la bibliothèque d'asset, mais comme désormais UE4 offre aussi chaque mois (je crois) des assets, je suis un peux largué.

Les deux se valent techniquement.
Après pour un débutant je dirais Unity même si j'utilise UE4.
Le problème d'UE4 c'est sa communauté inexistante ( 9 questions sur 10 posées sur le forum officiel ne trouvent jamais de réponse), sa très faible documentation et sa politique du "on rajoute plein de truc mais on optimise/corrige jamais ce qu'on a", qui en fait une usine à gaz bourrée de bugs.
Si tu veux du visual scripting (cad comme les blueprint d'UE4) tu as des soliutions pour Unity mais elles ne sont pas natives.

du coup pour l'utilisation des Visual scripting, c'est pas plus problématique que le blueprint UE ?

Le 11 mai 2019 à 17:26:06 Alex3112 a écrit :
Les deux se valent techniquement.
Après pour un débutant je dirais Unity même si j'utilise UE4.
Le problème d'UE4 c'est sa communauté inexistante ( 9 questions sur 10 posées sur le forum officiel ne trouvent jamais de réponse), sa très faible documentation et sa politique du "on rajoute plein de truc mais on optimise/corrige jamais ce qu'on a", qui en fait une usine à gaz bourrée de bugs.
Si tu veux du visual scripting (cad comme les blueprint d'UE4) tu as des soliutions pour Unity mais elles ne sont pas natives.

Beaucoup de choses avancées qui relèvent uniquement de ton opinion, attention à ne pas affirmer des choses sans fondements surtout sans sources.

Le 11 mai 2019 à 18:01:22 Quinlan_ a écrit :

Le 11 mai 2019 à 17:26:06 Alex3112 a écrit :
Les deux se valent techniquement.
Après pour un débutant je dirais Unity même si j'utilise UE4.
Le problème d'UE4 c'est sa communauté inexistante ( 9 questions sur 10 posées sur le forum officiel ne trouvent jamais de réponse), sa très faible documentation et sa politique du "on rajoute plein de truc mais on optimise/corrige jamais ce qu'on a", qui en fait une usine à gaz bourrée de bugs.
Si tu veux du visual scripting (cad comme les blueprint d'UE4) tu as des soliutions pour Unity mais elles ne sont pas natives.

Beaucoup de choses avancées qui relèvent uniquement de ton opinion, attention à ne pas affirmer des choses sans fondements surtout sans sources.

Que c'est fatiguant ce genre de commentaire inutile, en général j'évite d'y répondre.
Évidement que c'est mon opinion et pas celle du voisin, c'est le principe d'une discussion.
Accessoirement j'utilise UE4 en moyenne 10 heures par jour quasiment quotidiennement depuis 5 an et UDK auparavant, je pense mon opinion suffisamment fondée.
On est là pour donner son opinion, pas pour avoir à justifier la moindre phrase.
Maintenant si tu ne partage pas mon opinion, je t'invite à expliquer à l'auteur de ce sujet pourquoi mon opinion est mauvaise parce qu'au final tu ne répond pas du tout au sujet.

Du coup pour trouver des asset et de l'aide FR vaut mieux Unity?

Le 11 mai 2019 à 20:08:30 Alex3112 a écrit :

Le 11 mai 2019 à 18:01:22 Quinlan_ a écrit :

Le 11 mai 2019 à 17:26:06 Alex3112 a écrit :
Les deux se valent techniquement.
Après pour un débutant je dirais Unity même si j'utilise UE4.
Le problème d'UE4 c'est sa communauté inexistante ( 9 questions sur 10 posées sur le forum officiel ne trouvent jamais de réponse), sa très faible documentation et sa politique du "on rajoute plein de truc mais on optimise/corrige jamais ce qu'on a", qui en fait une usine à gaz bourrée de bugs.
Si tu veux du visual scripting (cad comme les blueprint d'UE4) tu as des soliutions pour Unity mais elles ne sont pas natives.

Beaucoup de choses avancées qui relèvent uniquement de ton opinion, attention à ne pas affirmer des choses sans fondements surtout sans sources.

Que c'est fatiguant ce genre de commentaire inutile, en général j'évite d'y répondre.
Évidement que c'est mon opinion et pas celle du voisin, c'est le principe d'une discussion.
Accessoirement j'utilise UE4 en moyenne 10 heures par jour quasiment quotidiennement depuis 5 an et UDK auparavant, je pense mon opinion suffisamment fondée.
On est là pour donner son opinion, pas pour avoir à justifier la moindre phrase.
Maintenant si tu ne partage pas mon opinion, je t'invite à expliquer à l'auteur de ce sujet pourquoi mon opinion est mauvaise parce qu'au final tu ne répond pas du tout au sujet.

Bravo l'argument d'autorité.
Ensuite non tu n'as pas compris le principe d'un débat. Ce qui est avancé sans preuves peut etre refuté sans preuves. Ton opinion seule n'a aucun interet, l'auteur n'est pas plus avancé dans sa recherche, et d'eventuelles personnnes interessées par le sujet n'en n'apprendraient pas d'avantage

Le 11 mai 2019 à 21:43:23 Quinlan_ a écrit :

Le 11 mai 2019 à 20:08:30 Alex3112 a écrit :

Le 11 mai 2019 à 18:01:22 Quinlan_ a écrit :

Le 11 mai 2019 à 17:26:06 Alex3112 a écrit :
Les deux se valent techniquement.
Après pour un débutant je dirais Unity même si j'utilise UE4.
Le problème d'UE4 c'est sa communauté inexistante ( 9 questions sur 10 posées sur le forum officiel ne trouvent jamais de réponse), sa très faible documentation et sa politique du "on rajoute plein de truc mais on optimise/corrige jamais ce qu'on a", qui en fait une usine à gaz bourrée de bugs.
Si tu veux du visual scripting (cad comme les blueprint d'UE4) tu as des soliutions pour Unity mais elles ne sont pas natives.

Beaucoup de choses avancées qui relèvent uniquement de ton opinion, attention à ne pas affirmer des choses sans fondements surtout sans sources.

Que c'est fatiguant ce genre de commentaire inutile, en général j'évite d'y répondre.
Évidement que c'est mon opinion et pas celle du voisin, c'est le principe d'une discussion.
Accessoirement j'utilise UE4 en moyenne 10 heures par jour quasiment quotidiennement depuis 5 an et UDK auparavant, je pense mon opinion suffisamment fondée.
On est là pour donner son opinion, pas pour avoir à justifier la moindre phrase.
Maintenant si tu ne partage pas mon opinion, je t'invite à expliquer à l'auteur de ce sujet pourquoi mon opinion est mauvaise parce qu'au final tu ne répond pas du tout au sujet.

Bravo l'argument d'autorité.
Ensuite non tu n'as pas compris le principe d'un débat. Ce qui est avancé sans preuves peut etre refuté sans preuves. Ton opinion seule n'a aucun interet, l'auteur n'est pas plus avancé dans sa recherche, et d'eventuelles personnnes interessées par le sujet n'en n'apprendraient pas d'avantage

Justement, on est pas dans un débat monsieur la tronche en biais mais sur un forum de discussion. Sur ce je te blacklist parce que je n'ai ni l'âge ni le temps pour ces bêtises.

du coup j'avoue que cela ne m'avance pas plus ^^"

Le 11 mai 2019 à 21:43:23 Quinlan_ a écrit :
Bravo l'argument d'autorité.
Ensuite non tu n'as pas compris le principe d'un débat. Ce qui est avancé sans preuves peut etre refuté sans preuves. Ton opinion seule n'a aucun interet, l'auteur n'est pas plus avancé dans sa recherche, et d'eventuelles personnnes interessées par le sujet n'en n'apprendraient pas d'avantage

Pourtant avant de balancer des messages qui ne veulent rien dire, il serait intéressant, je pense, de lire les messages que tu critiques (ou si c'est déjà le cas, essayer de les comprendre).

Des arguments avec preuves il en a fourni. La commu UE4 inexistante c'est un fait, il suffit de regarder son forum officiel ou de faire un rapide tour sur un site genre Stack Overflow.
Sa faible documentation, c'est aussi un fait, il suffit, attention ça va te surprendre, d'aller voir la doc :D (et si elle te parait complète, aller comparer avec celle proposée par Unity).

Bref, techniquement les 2 se valent, Unity est plus accessible, UE4 possède les blueprints qui permettent de faire énormément de choses sans avoir à coder quoi que ce soit, mais l'Assets Store d'Unity propose des solutions permettant de faire du Visual Scripting (mais c'est en général des plugins payants).

D'ailleurs en parlant d'Assets Store, celui d'Unity est très fourni et permet de trouver énormément de chose pour ne pas avoir forcément à réinventer la roue.

Le 12 mai 2019 à 12:50:20 ShellShock a écrit :

Le 11 mai 2019 à 21:43:23 Quinlan_ a écrit :
Bravo l'argument d'autorité.
Ensuite non tu n'as pas compris le principe d'un débat. Ce qui est avancé sans preuves peut etre refuté sans preuves. Ton opinion seule n'a aucun interet, l'auteur n'est pas plus avancé dans sa recherche, et d'eventuelles personnnes interessées par le sujet n'en n'apprendraient pas d'avantage

Pourtant avant de balancer des messages qui ne veulent rien dire, il serait intéressant, je pense, de lire les messages que tu critiques (ou si c'est déjà le cas, essayer de les comprendre).

Des arguments avec preuves il en a fourni. La commu UE4 inexistante c'est un fait, il suffit de regarder son forum officiel ou de faire un rapide tour sur un site genre Stack Overflow.
Sa faible documentation, c'est aussi un fait, il suffit, attention ça va te surprendre, d'aller voir la doc :D (et si elle te parait complète, aller comparer avec celle proposée par Unity).

Bref, techniquement les 2 se valent, Unity est plus accessible, UE4 possède les blueprints qui permettent de faire énormément de choses sans avoir à coder quoi que ce soit, mais l'Assets Store d'Unity propose des solutions permettant de faire du Visual Scripting (mais c'est en général des plugins payants).

D'ailleurs en parlant d'Assets Store, celui d'Unity est très fourni et permet de trouver énormément de chose pour ne pas avoir forcément à réinventer la roue.

Exactement.

Il me semble que l'équipe de Unity bosse actuellement sur un système de visual scripting natif mais pas dispo avant un bon moment, ce qui t'obligera probablement à mettre la main au portefeuille pour une solution qui dépend entièrement d'un contributeur lambda avec le support/suivi de mise à jour qui va avec si tu tiens absolument à du visual scripting.

Par contre comme on l'a dit, tu devra majoritairement apprendre à coder en blueprint seul, avec une documentation officielle qui ne couvre pas la moitié des fonctionnalités du moteur, t'obligeant à poser des questions sur un forum officiel où 99% des personnes sont là pour poser des questions plutôt que répondre à celles des autres (avec 2 ou 3 personnes du staff d'Epic qui répondent à 0.1% des questions) et à essayer de deviner comment telle ou telle chose fonctionne.
C'est faisable puisqu'on le fait tous mais c'est forcément plus laborieux que sur un moteur qui bénéficie d'une vraie communauté et d'une doc digne de ce nom.

A toi de peser le pour et le contre selon ton projet

ok merci beaucoup

pour l'apprentissage de UE4 je suis tombé sur ce Youtubeur https://www.youtube.com/channel/UCEnPuFDPRzZzeH2UFJ1Q4cA
il y a un un équivalent ou quelqu'un de meilleur sur la sphere FR dédié a unity?

Je rejoins un peu ce qui se dit aussi (sauf pour le "les 2 se valent techniquement"). C'est pas du tout vrai, UE4 est largement plus performant qu'Unity.
Le reste, je suis d'accord. Manque de communauté sur UE4. Peu de ressources, pas de doc correct. C'est souvent la galere de trouver de l'aide. Unity est bien plus accessible sur ces point.
Le blueprint, c'est très puissant, ca peut suffire a faire un jeu complet. Ca utilise des fonctions C++, et si les briques dont tu as besoin existent deja, tu n'as pas besoin de faire du C++. (mais du coup faut bien comprendre comment marche le moteur pour utiliser le blueprint).

Tu as aussi les tutos de Jean Charpentier pour UE4.

et les fameux tutos de Meletou.

Le problème des blueprints c'est que ça brise la commu en deux.
Quand tu sais coder t'as pas envie d'apprendre à relier des blocks logiques entre eux.
Et Unity c'est très bien, mais ça m'a l'air d'avoir été utilisé par tellement de projet poubelle, qu'une grosse part des infos que tu trouves sont faites par des amateurs (alors que tu trouveras beaucoup plus de pro sur UE).
Je dirais d'aller sur Unity pour pas d'embêter

Le 13 mai 2019 à 00:04:13 RegleGraduee a écrit :
Le problème des blueprints c'est que ça brise la commu en deux.
Quand tu sais coder t'as pas envie d'apprendre à relier des blocks logiques entre eux.

Attention, Epic ne s'est pas cassé la tête à intégrer du visual scripting, la "nativisation" des blueprints, etc. Dans le but de permettre à des néophytes de s'amuser avec leur moteur.
C'est un outil pour améliorer la productivité en évitant d'avoir à retaper des milliers de fois les mêmes bouts de codes (qui tiennent dans une seule "boite"), ça permet de debbuger plus facilement le code, etc.
Personne ne code tout un jeu sur UE4 100% en C++, pas même Epic
En général un projet c'est un maximum de blueprint et seulement des classes C++ pour des fonctions plus exotiques qui ne sont pas réalisables en blueprint.

Le 12 mai 2019 à 23:50:51 Lapintade a écrit :
Je rejoins un peu ce qui se dit aussi (sauf pour le "les 2 se valent techniquement"). C'est pas du tout vrai, UE4 est largement plus performant qu'Unity.

Je ne parlais pas de performances, mais de feature. Je n'utilise plus Unity depuis longtemps donc je ne m'avancerai pas sur ses performances mais je me tiens au courant de ce qu'ils font et je sais qu'ils ont fait beaucoup d'efforts pour rattraper leur retard sur les moteurs concurrents. En terme de rendu par exemple et comme je le disais, bientot en terme de productivité via leur sytème de visual scripting maison.

Le 13 mai 2019 à 00:29:34 Alex3112 a écrit :

Le 13 mai 2019 à 00:04:13 RegleGraduee a écrit :
Le problème des blueprints c'est que ça brise la commu en deux.
Quand tu sais coder t'as pas envie d'apprendre à relier des blocks logiques entre eux.

Attention, Epic ne s'est pas cassé la tête à intégrer du visual scripting, la "nativisation" des blueprints, etc. Dans le but de permettre à des néophytes de s'amuser avec leur moteur.
C'est un outil pour améliorer la productivité en évitant d'avoir à retaper des milliers de fois les mêmes bouts de codes (qui tiennent dans une seule "boite"), ça permet de debbuger plus facilement le code, etc.
Personne ne code tout un jeu sur UE4 100% en C++, pas même Epic
En général un projet c'est un maximum de blueprint et seulement des classes C++ pour des fonctions plus exotiques qui ne sont pas réalisables en blueprint.

Moué quand tu sais coder en principe t'as pas besoin de répéter ton code. Je pense surtout que les Blueprints permettent aux intermédiaires (graphistes, level designer ...) de pouvoir se débrouiller sans faire appel aux programmeurs, et sur des gros projets ça doit permettre de faire gagner énormément de temps

Le 13 mai 2019 à 00:55:36 RegleGraduee a écrit :

Le 13 mai 2019 à 00:29:34 Alex3112 a écrit :

Le 13 mai 2019 à 00:04:13 RegleGraduee a écrit :
Le problème des blueprints c'est que ça brise la commu en deux.
Quand tu sais coder t'as pas envie d'apprendre à relier des blocks logiques entre eux.

Attention, Epic ne s'est pas cassé la tête à intégrer du visual scripting, la "nativisation" des blueprints, etc. Dans le but de permettre à des néophytes de s'amuser avec leur moteur.
C'est un outil pour améliorer la productivité en évitant d'avoir à retaper des milliers de fois les mêmes bouts de codes (qui tiennent dans une seule "boite"), ça permet de debbuger plus facilement le code, etc.
Personne ne code tout un jeu sur UE4 100% en C++, pas même Epic
En général un projet c'est un maximum de blueprint et seulement des classes C++ pour des fonctions plus exotiques qui ne sont pas réalisables en blueprint.

Moué quand tu sais coder en principe t'as pas besoin de répéter ton code.

Je comprend pas ce que tu veux dire.
Programmer c'est faire des milliers de répétitions, peu importe le langage.
Dans un jeu, la même fonction va être appelée des centaines et des centaines de fois (par exemple une fonction qui met à jour les points de vie du joueur, tu vas l'appeler quand le joueur subit des dégâts, quand il consomme un item qui remonte ses points de vie, quand il gagne un niveau, etc.).
En code brut c'est la même ligne à taper encore et encore, alors qu'en blueprint c'est juste un node à placer dans ton graph.
Quand tu multiplie ça sur le code de tout un jeu, c'est des centaines d’heures de gagnées.
Sans compter que c'est beaucoup plus lisible puisque visuel (d'où le nom), que tu peux ouvrir une fonction appelée dans ton code simplement en double cliquant dessus, etc.
Je connais le C++ et je l'utilise pour faire ma propre version du moteur à partir des sources mais je ne l'utilise quasiment jamais pour un jeu.
Là par exemple je bosse sur un projet de RPG depuis un an et demi et je n'ai absolument aucune classe C++ dans mon projet. Pourquoi je m'embetterais avec ça alors que tout mon code est réalisable en blueprint.
Avant la limite c'était le performances sur les petites configs mais aujourd'hui tu peux convertir ton projet en blueprint en C++ en cochant une case dans le moteur et avoir les mêmes performances qu'en ayant tout codé directement en C++

Attention, Epic ne s'est pas cassé la tête à intégrer du visual scripting, la "nativisation" des blueprints, etc. Dans le but de permettre à des néophytes de s'amuser avec leur moteur.
C'est un outil pour améliorer la productivité en évitant d'avoir à retaper des milliers de fois les mêmes bouts de codes (qui tiennent dans une seule "boite"), ça permet de debbuger plus facilement le code, etc.
Personne ne code tout un jeu sur UE4 100% en C++, pas même Epic
En général un projet c'est un maximum de blueprint et seulement des classes C++ pour des fonctions plus exotiques qui ne sont pas réalisables en blueprint.

Tiens donc c'est marrant ça pour un expert tu ne sembles pas au courant des best practices d'epic concernant les blueprints...C'est tout l'inverse, Epic n'utilisent que le C++ pour développer leur jeu (exemple Fornite). Ils se servent des blueprints uniquement comme moules de leur classes C++ afin d'y parametrer des valeurs par defauts (Mesh, materials par exemple). Ca evite aux designer d'avoir à toucher à du code cpp.

https://youtu.be/2edoacF53F0?t=1984

Et ce n'est pas totalement vrai qu'il est possible de faire entièrement son jeu en blueprints. Beaucoup de features de l'engine (voire trop) ne sont pas exposées et il devient alors nécessaire d'utiliser à minima des plugins. (Exemple : l'intégralité du online subsystem)

Le blueprint est avant tout un outil de prototypage, et Epic conseille formellement de l'utiliser avec précaution et d’éviter de shipper des projets avec.

Tiens donc c'est marrant ça pour un expert tu ne sembles pas au courant des best practices d'epic

Un peu de respect svp.

Je suis d'accord avec Alex, le blueprint c'est très bien pour tout ce qui est gameplay haut niveau. Je pense que personne ne s'embette a tout coder en C++, c'est une horreur. (je suis codeur C++).

Le 14 mai 2019 à 09:29:12 Lapintade a écrit :

Tiens donc c'est marrant ça pour un expert tu ne sembles pas au courant des best practices d'epic

Un peu de respect svp.

Je suis d'accord avec Alex, le blueprint c'est très bien pour tout ce qui est gameplay haut niveau. Je pense que personne ne s'embette a tout coder en C++, c'est une horreur. (je suis codeur C++).

Je sais pas si ça vaut bien le coup de se lancer dans des discussions techniques ici mais bon.
Les jeux d'Epic Games ont aussi la particularité d'être majoritairement des jeux multijoueurs compétitifs qui doivent tourner sur la plus grande plage de configurations/plateformes possible, avec un ping et un input lag le plus bas possible.
Ce qui fait que la priorité sur le développement de ce type de jeu, c'est l'optimisation du game thread, donc de tous les calculs effectués sur CPU, là où le bottleneck se trouve sur le render thread sur tout autre type de jeu.
Optimiser le game thread pour gagner quelques millisecondes sur du blueprint converti en C++ via la "nativization" en passant à un code en pur C++, ça n'a absolument aucun impact sur un jeu qui est limité par le GPU.(90% des jeux sur 90% des configs/plateformes)

Hors de ce contexte, aucun projet sur UE4 n'a à gagner à être codé en C++ s'il n'a pas besoin de classe C++.
Sur un jeu solo PC/Console next gen, n'importe qui préférera activer des options graphiques comme le "DFAO", les "planar reflections", augmenter la résolutions des ombres, etc. et rendre son jeu limité par le render thread plutôt que de faire des économies sur les graphismes, pour être limité par le game thread et l'optimiser pour gagner quelques millisecondes (tout l'inverse d'un jeu multijoueur compétitif)