codec-abc a écrit :
Mouai... pas convaincu. Le shader de base sous Unity c'est celui qui est correct pour faire du PBR. Donc pour peu que tu fasses pas nawak avec les lumières et l'environnement, tu vas avoir un truc plutôt joli sans effort. Unreal fait quoi de mieux "out of the box" ?

Tu dois vraiment avoir que le nez dans Unity pour pouvoir dire ça. A moins que tu ne fasses référence que au système de shaders, mais juste vu qu'on est dans le sujet... :P

L'UE4 fait TOUT mieux "out of the box" que Unity. Je l'ai déjà dit :
- Unity = moteur avec la structure de base et derrière si t'as des besoins tu codes.
- UE4 = moteur avec la structure de base ET des tonnes de fonctionnalités déjà implémentées si besoin ET si t'as des besoins complémentaires tu codes.

J'vais prendre l'audio parce que c'est mon domaine... tout ce que je vais dire que Unity n'a pas c'est que je l'ai par défaut (sans une once de code dans le moteur).
"Audio sources" (les trucs qui font du son à un endroit donné dans l'environnement) :
- Pas de son non-spatialisé à une distance définie, les sons sont toujours spatialisés
- Pas de gestion de "sound culling" / "voice management" ( gestion du compte max, comment traiter le culling etc )
- Pas d'occlusion basique ( low pass quand un son est camouflé derrière un objet )
- Pas de gestion d'azimuth pour la spatialisation
- Pas de système nodal pour gérer : de l'aléatoire, des vars internes, de la modulation...

Et j'en passe, ça c'est pour moi la base. Si tu veux gérer ça dans Unity, c'est à coder. Et j'peux te dire que bloquer une ressource pour gérer du sound culling ou de la gestion de compte max sur des instances de son, c'est clairement pas un truc qu'une boite de dév a envie de faire. C'est certainement pas pour rien que la majorité des jeux Unity tournent sur FMOD ou Wwise. Sérieux... pas de gestion d'aléatoire au niveau du son dans un moteur aussi âgé, c'est limite ridicule.

C'est que la surface de l'audio ça. On parle de "haut-parleurs" basiques dans l'enviro... si je commençais a parler des fonctionnalités avancées audio en terme de routage, de classes, de mixs, sous-mixs, de streaming, tu verrai à combien d'années lumière Unity est de l'UE4. Et pourtant, je suis pas encore satisfait de ce que l'UE4 fait nativement comparé à du middleware comme FMOD ou Wwise.

Sortit de mon domaine, c'est plus complexe, mais de base... instances de matériel, système de cinématique, système de dialogues avec gestion de plusieurs interlocuteurs et de leur genre, système de sous-titres, système de L10n intégré, système d'animation intégré au moteur depuis la 4.26, système de particules totalement dingue, système d'instanciation de géométrie en fonction de blueprints, système de level streaming et sub-levels.

C'est sans fin. Plus tu découvres l'UE, plus tu te rends compte du puits sans fond en terme de fonctionnalités existantes sans avoir à appeler un codeur.

Big Apple a écrit :
Pire, l'interface de l'Unreal Engine est dégueulasse et leur système de blueprints est un espèce de Scratch pour adulte.

Non. L'interface de l'UE n'est pas "dégueulasse". Tu ne l'aimes pas ou tu ne la connais pas peut être. Mais si celle de l'UE est "dégueulasse", celle de Unity l'est tout autant. Ce sont des idéologies différentes, ce sont des aspects visuels différents... mais l'UE explose littéralement l'ergonomie de Unity.

Comme le dis CBL, rien que l'iconisation de l'interface est super archaïque. Tous les prefabs ont la même gueule, pas de preview. Manipulation des assets assez minimale, pas de fonctionnalités avancées (batch processing, batch renaming, recherche de dépendances, sauvegarde de recherches pour se faire des "librairies"...)
Par exemple, j'aurai pas eu de système de batch dans l'UE, je serai devenu dingue sur la loca des doublages. Je sais même pas comment font les gros projets sur Unity pour ce genre de quantité de données.

Après je suis conscient des faiblesses de l'UE qui mériteraient d'être améliorées... comme le fait que l'UI consomme des render pass et que tu dois fermer l'intégralité de tes fenêtres si tu veux les perfs maximales ingame dans l'éditeur. Mais non, on ne peut pas résumer l'UI de l'UE à "dégueulasse" quand on connait celle de Unity... où c'est qu'on manque clairement d'objectivité.

Quand au système de blueprint et le réduire à un "Scratch pour adulte" c'est également ne pas comprendre la puissance de cet outil. Ce qui est assez drôle d'ailleurs c'est que beaucoup de "fans" de Unity pointaient du doigt ce système... mais depuis qu'il existe pour Unity, tout le monde l'utilise.

Les blueprints c'est la vie. Tous les studios utilisent ça, aussi bien pour faciliter la vie des "tech artists" que des level designers ou même des codeurs. Même les très gros projets exploitent les blueprints, on le voit à plusieurs reprises dans des reportages sur les studios, le plus récent en tête étant Fallen Order.

Nier / refuser l'utilisation des blueprints dans un studio, c'est ou que t'as une team de codeurs qui a beaucoup trop de temps libre devant eux. Ou c'est ne pas saisir l'intérêt monstrueux qu'offre cette techno.

Rien que pour donner de la vie à tes environnements, le blueprint c'est limite obligatoire. J'me revois à l'époque de l'ID Tech 4, où pour faire une porte qui explose il fallait scripter ça en texte. Là un LD il choppe ses objets, pose 4 nodes, mets un trigger. C'est fini, ça part en prod, ça a pris 10 minutes.

Et ne me faites pas dire ce que je n'ai pas dit : l'UE4 a des faiblesses indéniablement.

C'est juste que les "pro-Unity" ont une tendance à ne pas creuser les capacités énormissimes qu'a l'UE4 et à rediriger systématiquement la discussion vers le système de shader qui est vraiment le dernier des problèmes des deux moteurs :)

Unity vs UE, ça me rappelle un peu les threads rap vs métal de ma jeunesse.

Dernièrement c'est le rendu du moteur d'Horizon/Death stranding qui m'a impressionné.
Il permet tellement de vista de ouf dans Horizon... C'est limite dommage que d'autres studios ne puissent pas le réutiliser (a part Kojima prod).
Pourquoi les studios ne mettent pas a minima a dispo (payante pq pas) leur assets, textures etc... Y a des fois un boulot de dingue qui est fait mais qui n'est qu'exploité que pour une suite et uniquement une partie.
Je trouve ça dommage que chaque développeur doive tout redmodeliser un monde from scratch a chaque fois alors que tu as déjà des biomes bien jolis que tu pourrais réadapter. Idem pour l'IA, y a pas des trucs open source qui existent pour éviter genre le fiasco de l'IA de cyberpunk ?...
Bon après c'est ma vision de joueur, j'y connais pas grand chose en dev de jeux...

De mon humble expérience, je trouve UE bcp plus praticable en équipe. Et pour les graphs c'est bcp plus agréable "out of the box".
Par contre je ferai pas un jeu solo avec. J'ai pas gd chose a foutre de faire du rendu réaliste, et Unity m'est bcp plus agréable a une petite échelle.

@Max: J'ai un peu la flemme de tout reprendre (Surtout que je suis plutôt d'accord) mais je ne nie pas que Unity n'est pas en dessous en terme de features. Ce que je disais c'est que CBL manquait pas mal de pondération dans ses propos à tel point qu'on avait l'impression qu'Unity n'est pas une alternative à Unreal. Or c'est le cas pour les jeux qui n'ont pas de prétention de faire un AAA, ce qui mine de rien laisse pas mal d'opportunités de l'utiliser.

pimpim a écrit :
Dernièrement c'est le rendu du moteur d'Horizon/Death stranding qui m'a impressionné.
Il permet tellement de vista de ouf dans Horizon... C'est limite dommage que d'autres studios ne puissent pas le réutiliser (a part Kojima prod).
Pourquoi les studios ne mettent pas a minima a dispo (payante pq pas) leur assets, textures etc... Y a des fois un boulot de dingue qui est fait mais qui n'est qu'exploité que pour une suite et uniquement une partie.
Je trouve ça dommage que chaque développeur doive tout redmodeliser un monde from scratch a chaque fois alors que tu as déjà des biomes bien jolis que tu pourrais réadapter. Idem pour l'IA, y a pas des trucs open source qui existent pour éviter genre le fiasco de l'IA de cyberpunk ?...
Bon après c'est ma vision de joueur, j'y connais pas grand chose en dev de jeux...

Pour le moteur Feed a déjà répondu a çà :

feed a écrit :
tu ne peux pas prendre un moteur interne et facilement l'exposer au public. Ca implique d'enlever tout ce qui est propriétaire, faire en sorte que le moteur soit bien isolé de tout ce qui est code jeu, enlever les licences des logiciels tiers, et surtout documenter exhaustivement tout ce qu'il est possible de faire.
Et ça, c'est dans le cas où ton moteur est suffisamment modulaire pour pouvoir être utilisé dans d'autres jeux.

Pour les assets, ca se fait déjà, partiellement. Regarde la bibliothèque quixel megascans.
Mais ca se voit plus vite qu'on croirait. J'ai a peine bidouillé sur les moteurs, et je commence déjà a repérer les caillous de megascan qui sont utilisés dans plein de trucs. Et c'est juste des cailloux.
Et puis en JV le style d'un environnement est beaucoup plus différent d'un jeu au l'autre que dans des films par exemple, ce qui les rend beaucoup plus reconnaissables. Et parfoit inutilisables dans un jeux qui n'a pas exactement le même style. Du coup si on se mettait a réutiliser des biomes complet ca sauterait aux yeux. Même des objets, tu as le problème que le joueur a tout le loisir de les inspecter longuement si ca lui prend. Les tasses a café de Alyx, je te promet que si elles sont réemployés dans un autre titre je vais les reconnaitre instantanément.

Bref, réutiliser certains éléments ca se fait un peut, mais pour éviter une sensation de déjà vu les studios sont toujours obligés d'en créer de nouveau ou au moins modifier ceux existants.

Enfin, il y a la question de la progression technologique.
Ca ne fait pas si longtemps que les graphismes on atteint un niveau de réalisme satisfaisant et arrêté de progresser a pas de géant tous les 2 ans, rendant envisageable de réutiliser les même éléments a quelques années d'écart. Il n'y a pas si longtemps, si tu repompait des models d'un jeu qui venait de sortir, le temps que tu finisse le tient les models étaient tellement datés qu'ils étaient inutilisables.

kakek a écrit :

pimpim a écrit :
Dernièrement c'est le rendu du moteur d'Horizon/Death stranding qui m'a impressionné.
Il permet tellement de vista de ouf dans Horizon... C'est limite dommage que d'autres studios ne puissent pas le réutiliser (a part Kojima prod).
Pourquoi les studios ne mettent pas a minima a dispo (payante pq pas) leur assets, textures etc... Y a des fois un boulot de dingue qui est fait mais qui n'est qu'exploité que pour une suite et uniquement une partie.
Je trouve ça dommage que chaque développeur doive tout redmodeliser un monde from scratch a chaque fois alors que tu as déjà des biomes bien jolis que tu pourrais réadapter. Idem pour l'IA, y a pas des trucs open source qui existent pour éviter genre le fiasco de l'IA de cyberpunk ?...
Bon après c'est ma vision de joueur, j'y connais pas grand chose en dev de jeux...

Pour le moteur Feed a déjà répondu a çà :

feed a écrit :
tu ne peux pas prendre un moteur interne et facilement l'exposer au public. Ca implique d'enlever tout ce qui est propriétaire, faire en sorte que le moteur soit bien isolé de tout ce qui est code jeu, enlever les licences des logiciels tiers, et surtout documenter exhaustivement tout ce qu'il est possible de faire.
Et ça, c'est dans le cas où ton moteur est suffisamment modulaire pour pouvoir être utilisé dans d'autres jeux.

Pour les assets, ca se fait déjà, partiellement. Regarde la bibliothèque quixel megascans.
Mais ca se voit plus vite qu'on croirait. J'ai a peine bidouillé sur les moteurs, et je commence déjà a repérer les caillous de megascan qui sont utilisés dans plein de trucs. Et c'est juste des cailloux.
Et puis en JV le style d'un environnement est beaucoup plus différent d'un jeu au l'autre que dans des films par exemple, ce qui les rend beaucoup plus reconnaissables. Et parfoit inutilisables dans un jeux qui n'a pas exactement le même style. Du coup si on se mettait a réutiliser des biomes complet ca sauterait aux yeux. Même des objets, tu as le problème que le joueur a tout le loisir de les inspecter longuement si ca lui prend. Les tasses a café de Alyx, je te promet que si elles sont réemployés dans un autre titre je vais les reconnaitre instantanément.

Bref, réutiliser certains éléments ca se fait un peut, mais pour éviter une sensation de déjà vu les studios sont toujours obligés d'en créer de nouveau ou au moins modifier ceux existants.

Enfin, il y a la question de la progression technologique.
Ca ne fait pas si longtemps que les graphismes on atteint un niveau de réalisme satisfaisant et arrêté de progresser a pas de géant tous les 2 ans, rendant envisageable de réutiliser les même éléments a quelques années d'écart. Il n'y a pas si longtemps, si tu repompait des models d'un jeu qui venait de sortir, le temps que tu finisse le tient les models étaient tellement datés qu'ils étaient inutilisables.

Compris :-) Ça paraît logique en effet.
Reste quand quand tu vois certains dev indépendants recréer des petits OW, je me disais que ça ne les dérangerait pas trop de repartir d'un monde déjà modélisé (a adapter quand meme). Plus généralement y a des maps qui pourraient etre un peu reprises mais avec un gameplay différent, combien de fois j'ai voulu planer comme dans btow en haut d'une montagne dans Horizon ! Me parlez pas de gods & monsters par contre !

codec-abc a écrit :
@Max: J'ai un peu la flemme de tout reprendre (Surtout que je suis plutôt d'accord) mais je ne nie pas que Unity n'est pas en dessous en terme de features. Ce que je disais c'est que CBL manquait pas mal de pondération dans ses propos à tel point qu'on avait l'impression qu'Unity n'est pas une alternative à Unreal. Or c'est le cas pour les jeux qui n'ont pas de prétention de faire un AAA, ce qui mine de rien laisse pas mal d'opportunités de l'utiliser.

Tu déformes totalement mon propos. Je ne parle que du rendu.

Mais pour répondre à ce que tu dis, même pour les petits projets, UE 4 me semble plus adapté qu'Unity de nos jours. Outre tous les outils que propose de base le moteur et la bibliothèque d'assets grandissantes, les Blueprints simplifient largement la partie code à tel point que les artistes peuvent faire des jeux sans avoir besoin de développeurs. C'est d'ailleurs pour cela que de plus en plus d'indies passent sur UE4. Je le redis mais le seul cas de figure pour lequel je prendrais Unity à la place d'UE 4 est si je devais faire un jeu mobile ou Switch.

Je ne vais pas revenir sur le rendu. On est visiblement pas d'accord et c'est pas hyper constructif en l'état.

Pour le Blueprint c'est certain que c'est plus accessible que du code pour les non initiés à la programmation mais hormis faire des choses simple je doute de la scalabilité de la chose. D'expérience un artiste ça code mal et ça fait très rapidement une usine à gaz inmaintenable (normal c'est pas son job à la base). Or ça reste du code (sous forme graphique plutôt que textuel) en moins expressif car aujourd'hui on a toujours pas trouvé mieux que la représentation textuelle pour faire concis (sans compter que c'est plus simple sur certains sujet liés. J'ai pas expirmenté les conflits de merge sur le Blueprint mais déjà que ça peut être chiant sur du texte j'imagine pas sur de gros Blueprint l'enfer que ça doit être).

Alors autant pour ce qui est archi et visualisation de produit (choses qui n'ont pas besoin de beaucoup de code) ça permet aux artistes d'être indépendant. Autant de la à faire un jeu complet je suis pas sur que ça soit très pertinent.

Alors oui tout ce qui est version control pour les Blueprints c'est pas jojo. Par contre pour débugguer c'est super efficace car tu n'as pas besoin d'IDE externe et tu peux voir le chemin d'exécution de manière claire. Les Blueprints, c'est justement parfait pour deux types de projets:
-les petits projets : tu peux coder un jeu entièrement en Blueprints sans souci
-les gros projets : pendant que le code "principal" du jeu est codé en C++, les artistes et les game designers peuvent développer des scripts dans leur coin pour modifier des comportements, animer des objets ou lancer des effets.

codec-abc a écrit :
@Max: J'ai un peu la flemme de tout reprendre (Surtout que je suis plutôt d'accord) mais je ne nie pas que Unity n'est pas en dessous en terme de features. Ce que je disais c'est que CBL manquait pas mal de pondération dans ses propos à tel point qu'on avait l'impression qu'Unity n'est pas une alternative à Unreal. Or c'est le cas pour les jeux qui n'ont pas de prétention de faire un AAA, ce qui mine de rien laisse pas mal d'opportunités de l'utiliser.

Alors autant je suis capable d'argumenter pour l'UE4, autant moi je trouve Unity supra cool. Je m'éclate à bidouiller dedans, je trouve que c'est un moteur très chouette avec plein de possibilités, et tu peux lui faire cracher des trucs de ouf si tu y mets du tiens.

Après j'ai tellement d'heures dans l'UE4 à faire tout est n'importe quoi, des mini-jeux, des mods, de la VR, des jeux complets... ce truc est totalement dingue. Hors esquiver les royalties, je vois pas de raison spéciale à ne pas l'utiliser aujourd'hui.

Par contre pour rebondir sur ce que tu dis sur les blueprint entre temps... il ne faut pas voir le blueprint QUE comme des trucs posés à l'arrache par des LDs ou des artistes (même si c'est vrai et que ça existe dans les projets). Moi j'ai un gros background code, toutes mes impléms blueprint pour l'audio son super réfléchies pour être scalable et modifiable sans péter l'intégralité des maps qui utilisent actuellement le blueprint en milieu de prod.

Quant au versioning, il faut savoir que le blueprint est en réalité du full-text. Si tu copies une section de blueprint, tu peux la coller dans un fichier texte, la sauvegarder et la ré-exploiter et la coller dans la zone "nodale" à un autre endroit et hop ça te remet tous tes nodes.
Avec un Perforce derrière c'est pas plus compliqué de maintenir à peu près correctement tes versions. D'ailleurs, c'est du checkout exclusif l'UE4, donc le versioning est bien moins problématique... deux personnes ne peuvent pas bosser simultanément sur des assets de blueprint.

C'est pas pertinent de faire un jeu complet en blueprint... tout du moins un GROS jeu. Mais tu serai étonné de la quantité de blueprint qui régissent les jeux UE4. Tu peux avoir toute la logique de progression d'une map gérée par blueprint, parce que c'est plus facile à gérer et à itérer dessus comme ça.
Tout ce que tu vois bouger, avec un p'tio peu d'interaction : blueprint.
Fonctionnalité basiques (ouvrir une porte, trigger d'un effet ou d'une anim) : blueprint.
Fonctionnalité "avancées" pour certains aspects du jeu : blueprint. Exemple : sur Space Hulk Deathwing, j'ai posé une mécanique d'ambiance sonore intégralement en blueprint. Sur le projet actuel aussi, un jour je sortirai quelques articles sur mon blog, j'ai posé beaucoup de mécaniques ambiantes sonores en blueprint.

Franchement le blueprint, c'est le coeur de l'UE aujourd'hui... c'est pas fait pour gérer les mécaniques du coeur du jeu surtout sur les gros projets. Mais c'est là à tous les étages pour tout le reste.