Unreal Engine 4

[war-p]

Ouh yeah!
Ça vient de tomber, bonne nouvelle pour les plus pauvres d'entre-nous!

http://www.pcgamer.com/unreal-engine...0&ns_fee=0

[Saito Gray]

Notez qu'Epic viens de verser 30€ a utiliser sur leur marketplace a ceux qui une subscription avant que le moteur ne devienne gratuit.
C'est classe de leur part.

Le moteur commence a être utilisé un peu partout, leur marketplace se remplit tout doucement, Unity a du souci à se faire !

[Roscopolo]

Le moteur commence a être utilisé un peu partout, leur marketplace se remplit tout doucement, Unity a du souci à se faire !

Le moteur commence a être utilisé un peu partout, leur marketplace se remplit tout doucement, Unity a du souci à se faire !

Non, Unity n'a pas de souci à se faire : je finis en ce moment une comparaison Unity / UE4 (un mois sur chaque, études des docs, etc) et si UE4 a incontestablement des avantages, ça reste un choix hasardeux pour les indés :

a) La licence UE4 indés est prohibitive : 5% de royalties sur les ventes ça peut très bien vouloir dire 30% des profits. Unity et ses 900€ par an est incomparablement plus avantageux pour tout studio sérieux (y compris studios d'une ou deux personnes).


b) Unity favorise le vite fait bien fait tant que tu rentres dans leur moule (tout de même très large) et ça convient très bien aux indés. Leur API est simple, naturelle, rapide à apprendre, et C# est un excellent langage, moderne, très productif avec d'excellents outils.

En comparaison le C++ est une horreur anachronique avec un modèle de compilation obsolète (compilation lente + compilateurs complexes à écrire == outillage pourri, et l'écriture du code est conditionnée par les besoins du compilo plutôt que de l'algo). La productivité, la fiabilité et la maintenabilité en prennent un sale coup. Et le code d'UE4 use et abuse d'une métaprogrammation lourdingue à investiguer (à leur décharge le langage pousse dans cette direction) et il me semble aller à contre-sens des standards modernes du C++ (utilisation d'un GC avec RTTI à gogo plutôt que des smart pointers). Enfin les API d'UE4 bien que plus puissantes et personnalisables nécessitent aussi beaucoup plus de travail pour être exploitées.

Du coup UE4 nécessite plus de boulot pour chaque chose en termes de programmation et il me semble plutôt tourné vers les grandes équipes. Certes UE4 te laissera moins souvent à poil au milieu du chemin car si tu ne rentres pas dans leur moule tu pourras toujours bidouiller leurs sources. Et aussi parce que les API d'UE4 sont plus exhaustives et couvrent plus de cas. Certes tu auras aussi moins de pbs de perfs au bout du compte, ce qui aurait nécessité du temps sur certaines optimisations (même si tout n'est pas rose: leur GC est aussi problématique que celui d'Unity). Certes le déboguage est généralement plus aisé avec UE4. Certes il est plus facile de trouver des biblios tierce-parties de qualité en C++.

Sauf que pour la majorité des jeux tout ça ne doit pas compenser le surcroît de complexité et la productivité amoindrie.


c) Le marketplace se remplit mais il reste bien triste par rapport à celui d'Unity. Si aujourd'hui tu veux des assets, tu vas pomper celui d'Unity (et tu dais une croix sur tout ce qui s'appuie sur du code - substances par ex - et tu te tapes des conversions à la main de tous les shaders et tu refais certains mappings UV).


d) Après UE4 a des avantages, comme son système de prog visuelle si tu as le budget pour programmer des blueprints pour les gamerdesigners, ou son système de shaders que les artistes peuvent créer directement. Mais en général je le trouve quand même plus lourd : les tâches faciles y sont fastidieuses, les tâches complexes ne le sont pas plus.


e) En termes visuels U5, Cryengine, Frostbite et UE4 se valent. Tous utilisent peu ou prou les mêmes techniques de toute façon. Je ne suis même pas sûr que le rendu proprement dit d'U5 soit plus lent.



Bref, je pense que Unity et UE4 ont de beaux avantages respectifs, le premier convenant sans doute mieux aux petites équipes et le second aux grandes.

Notez qu'Epic viens de verser 30€ a utiliser sur leur marketplace a ceux qui une subscription avant que le moteur ne devienne gratuit.
C'est classe de leur part.

Pour les studios ça ne change rien mais :
a) C'est cool pour les moddeurs.
b) Ça va inciter davantage de pros et d'étudiants à essayer pour voir.

[Saito Gray]

J'aurais dû me douter que j'allais attirer des fanboy...

a) UE4 propose son moteur complet, sans aucune restriction et open source au public. Unity propose un truc super limité.
L'amateur, le modder, l'indé va se faire la main sur des outils complets, open sources et très vite patché (Le support d'Unity étant une grosse blague, presque 3 ans pour corriger des bugs connus, c'est fort).
Un fois que ces gens auront fait leurs armes sur ce moteur, assez pour sortir un jeu qui peux potentiellement récolter de l'argent (plus de 90% des projets commencés tombe a l'eau, bon courage.) On pourra parler des royalty qui ne sont PAS excessives. Le cout sur le développement n'est pas si gros, surtout vu le prix de malade des licences d'autre logiciel à payer.

b) Tu n'aimes pas le C++. Cool. En quoi c'est un argument pour Unity ? D'autant plus qu'UE propose un EXELENT système de visual scripting qui permet de debugger en un clin d'oeil et de distribuer des taches beaucoup plus facilement. Pendant qu'un codeur s'amuse avec son code un designer se sert des blueprint et de leur possibilité.
Le prototypage et la construction de niveau et donc beaucoup plus rapide.
Et je ne parle même pas du fait que l'on puisse débuggé visuellement, ce qui m'a fait gagner un temps énorme par rapport a Unity.

c) Le marketplace d'UE se remplit lentement, car ses assets sont tous testés et fonctionnent. C'est loin d'être le cas d'Unity.

Pour finir j'ai utilisé Unity plus souvent qu'UE, mais je fais le switch depuis quelques mois. L'Unreal Engine est vraiment supérieur ergonomiquement et on s'y sans vraiment plus a l'aise.

Si Unity ne change pas son modèle économique, la boite fonce droit dans le mur. Leurs avantages restants ne retiendront pas longtemps ni les amateurs ni les dev.

Au final j'ai fait un long message pour pas grand-chose, la situation actuelle est relativement simple.
UE4 est open sources, a un suivi rapide et une communauté bien formée. Le moteur fait des merveilles visuellement et est utilisé par des gros noms de l'industrie.
Il utilise aussi un outil puissant de visual scripting qui permet au débutant de bricoler sans se prendre le chou avec du code.
Le moteur est gratuit ET complet ce qui va encourager plus de monde à se jeter dans le bain et à l'utiliser pour leur projet.

Unity c'est 1500$ ou 75€ par mois pour avoir des ombres.

[fadox]

Tain ce bmdj, je comptais souscrire, je vais sur le site et là surprise :D

[Grhyll]

J'aurais dû me douter que j'allais attirer des fanboy...

Après le message argumenté et équilibré de Roscopolo, qui essaie de faire le point sur les deux selon ses critères, c'est plutôt toi qui as l'air d'un fanboy à descendre l'un en flèche et encenser l'autre

[Zevka]

Dans mes souvenirs (erronés, donc), c'était déjà prévu qu'il le fasse, du coup ça ne m'a pas surpris, zut. J'aime bien les bonnes surprises.

J'avais rapidement testé l'UE3, à l'époque, par rapport à Unity ça faisait vraiment plus grosse usine à gaz longue à prendre en main, sans proposer grand chose de mieux pour des projets d'envergure limitée ou moyenne.

Va falloir mettre les pattes sur ce UE4 et voir ce que ça donne maintenant ! J'ai commencé un petit projet sur Unity qui se heurte justement à ses limites, donc ça tombe à point nommé.

[Saito Gray]

Après le message argumenté et équilibré de Roscopolo, qui essaie de faire le point sur les deux selon ses critères, c'est plutôt toi qui as l'air d'un fanboy à descendre l'un en flèche et encenser l'autre

Ok, c'est cool.

Alors pour être le plus objectif possible, actuellement on a un moteur gratuit, open source, qui en l'espace d'un an a vu défiler 7 versions mineures.
Un moteur qui devient gratuit et donc accessible pour tous.
Le moteur permet également de faire des exports gratuitement sur toutes les plateformes ( à l'exception des consoles qui demande une licence de la part du constructeur)
Le moteur inclut également un système de programmation visuelle noob frendly.
La communauté est naissante, mais présente.
Le marketplace est relativement vide.

De l'autre on a Unity qui dans sa version gratuite ne rivalise absolument pas avec ses concurrents.
Le moteur ne demande pas de royalties, mais le coup d'entrée est élevé et les modules d'export sont payants.
Même s'il existe des plug-ins de programmation visuels, il ne rivalise absolument pas avec les Blueprint d'Unreal Engine.
Malgré tout la communauté d'Unity est immense, le nombre de tuto est astronomique et le marketplace regorge d'asset.

Actuellement Unreal tente une approche agressive. Ils veulent se poser en leader et le politique de prix va pousser les gens à utiliser le moteur pour leur projet.

Objectivement si Unity ne se remue pas les fesses le moteur va droit dans le mur. Les royalties ne sont appliquées qu'en cas de réussite, il n'y a aucun couts, aucun risque de jeter 1500$ par les fenêtres si ton projet foire.
Actuellement Unreal est l'option safe pour tout un tas de dev.

[Louck]

De l'autre on a Unity qui dans sa version gratuite ne rivalise absolument pas avec ses concurrents.

Mouai, les goûts et les couleurs.... On peut continuer à comparer bêtement les deux frameworks, chacun a ses avantages et inconvénients, que ce soit au niveau des fonctionnalités, de la communauté, ou des supports.

Même si le moteur est très performant et produit de jolies effets, si tu met un novice devant les frameworks UE4 et Unity, il n'hésitera pas à choisir ce dernier pour son côté intuitive et aisé. Et c'est gratuit (sauf si tu veux la version Pro ou quand tu fais un chiffre d'affaire supérieur à 10.000$).


Je ne pense pas qu'un UE4 gratuit va faire de l'ombre à Unity. On pensait la même chose quand UE4 et CryEngine ont revu leurs tarifs, l'année dernière. Unity n'a pas bougée d'un pouce.


Où ca peut être fun, ca sera quand les développeurs vont utiliser UE4 pour faire la prochaine Global Jam ou Ludum Dare.

[Saito Gray]

Même si le moteur est très performant et produit de jolies effets, si tu met un novice devant les frameworks UE4 et Unity, il n'hésitera pas à choisir ce dernier pour son côté intuitive et aisé. Et c'est gratuit (sauf si tu veux la version Pro ou quand tu fais un chiffre d'affaire supérieur à 10.000$).

Justement non. Unreal a fait énormément d'effort pour améliorer son ergonomie et propose un moyen de scripte du gameplay sans code.
Ca a l'air de rien c'est c'est un sacré avantage, surtout vu le nombre de gens qui veulent s'y mettre avec des connaissances limitées en programmation.

La version gratuite d'Unity est bien trop limitée pour sortir quelque chose d'intéressant, elle n'inclus même pas les ombres, et c'est bien là le problème. Entre un moteur entier gratuit et un limité beaucoup de gens vont se tourner vers l'entier même s'il est plus complexe d'apparence.

Unity n'a pas bougé, car le Marketplace d'Unreal été inexistant jusqu'a ces derniers mois. La situation ne changera pas tout de suite, mais d'ici quelques années je ne serrais vraiment pas étonné de voir Unreal devenir le moteur par défaut des indé.

Unity version pro est un bon moteur, aucun doute là-dessus, il est complet et permet des merveilles, mais son tarif freine sa progression.
La concurrence dans ce domaine n'apporte que du bon, même si j'apprécie beaucoup plus Unreal j'espère voir Unity continuer son succès et apporter de nouvelles choses, mais pour le moment, ça ne doit pas être vraiment la fête dans leurs bureaux.

[Myron]

En tout cas Unity doit faire une annonce dans 50 minutes. Coïncidence? ^^

https://www.youtube.com/watch?v=N8Ao5oyflik

[Roscopolo]

J'aurais dû me douter que j'allais attirer des fanboy...

Hospitalis caritas et coetera....

Pour répondre brièvement il me semble que tu as adopté la perspective du développement amateur et je ne pense pas que celle-ci soit importante. L'écrasante majorité des jeux indés sont faits par des pros : talents complémentaires expérimentés, avec du capital à disposition et souhaitant tirer subsistance et profit de leur travail en sachant dans quoi ils s'embarquent. C'est à ces personnes que UE ou Unity doivent se destiner.

Sans vouloir t'offenser (je me trompe peut-être) dans ton cas j'ai plutôt l'impression que tu cherches un outil te permettant d'oeuvrer au mieux dans ton coin en n'ayant qu'une partie des compétences requises. Gamemaker me semblerait plus indiqué. Ma propre perspective est professionelle


Quelques points:
a) Les lacunes du C++ ne sont pas une affaire de goût mais un fait, et les blueprints ne sauraient s'y substituer du fait d'un facteur de 1 à 100 en termes de productivité et de capacités.

b) 5% des ventes brutes (donc 8% des revenus après marge du distribueur), ce n'est pas ce que j'appelle "rien".


Cela étant dit pour mon propre projet je pense qu'UE4 est, d'une courte tête, le meilleur choix, mais c'est dû à des besoins très spécifiques et atypiques. Je pense que la plupart des jeux indés seront mieux lotis avec Unity.

En tout cas Unity doit faire une annonce dans 50 minutes. Coïncidence? ^^

https://www.youtube.com/watch?v=N8Ao5oyflik

Ils ont déjà annoncé que la version gratuite aurait désormais toutes les fonctionnalités de la pro. La seule différence est qu'il faudra acheter la pro au-delà de 100k€ de revenus.

Et je ne pense pas que cette annonce ait été improvisée après celle d'UE4, je crois qu'elle était prévue de longue date et c'est tout à fait sensé.

[Saito Gray]

Oui, non, j'ai pas envie que ça tourne à la guerre des moteurs, qui font tous leur job relativement bien. J'arrête là, le topique parle d'UE4 Unity à deja le sien.

Concernant ma perspective, je me mets à la place des gens pas forcément pro qui sont à la recherche de leur premier moteur.
Personnellement j'ai travaillé 3 ans sous Unity avant de faire le switch et j'ai aussi une licence Gamemaker qui permet de faire des choses bien sympa assez rapidement (coucou Hotline Miami.)

Maintemant, je pense qu'UE4 est aussi adapté à l’indé qu'Unity, l'ergonomie a été revue et c'est bien mieux que sur L'unreal Engine 3.

Je n'enlève rien au mérite d'Unity qui est très capable (sur depuis la version 5 qui rivalise en qualité graphique avec EU4) mais le cout de la licence pour moi reste trop élevé.

[Sahnvour]

...

b) Ça c'est ton avis personnel. Tu as beau jeu de parler de parti pris avec un paragraphe pareil

Pour avoir utilisé les deux et menant actuellement un projet sur UE4, le temps de compilation doit être à vue de nez 2* plus lent sur UE, passant de 3 à 6 secondes, pour avoir du code natif, car oui le modèle de compilation du C++ et du C# (qui n'est donc pas réellement compilé) ne sont en fait pas comparables sans prendre en compte qu'ils sont totalement différents. Ceci dit c'est sûr que C++ accuse son âge à ce niveau là, c'est d'ailleurs pour ça qu'il est prévu de le moderniser drastiquement pour C++17.

Concernant leur RTTI, il pallie à une "faiblesse" du C++, ou tout du moins un autre paradigme que celui des langages dynamiques post 1990 (oui j'omets volontairement LISP, smalltalk et tout le tintouin). Et en quoi les smart pointers aident à avoir un RTTI ? Question sérieuse si tu as une réponse valable mais à première vue j'en suis pas convaincu. Leur système limite l'utilisateur à l'héritage simple et encourage à l'utilisation d'interfaces, pour limiter l'impact de la virtualisation sur les performances ; et héritage simple + interfaces = C# (entre autres).

Pour la méta-programmation je vois pas où est-ce que tu t'y es heurté Sachant que l'utilisation de templates n'est pas de facto de la méta-programmation.

Je suis personnellement (tu l'auras deviné) plus friand de C++ que de C# (que j'aime aussi par ailleurs), et je ne me trouve pas moins productif avec.


c) Y'a vraiment des studios indés de quelques personnes qui se lancent dans un jeu sans graphiste, et achètent tout sur le marketplace de leur moteur favori

Allegorithmic est partenaire avec Epic, et fournit des plugins pour utiliser leurs produits. Peut-être que tout n'est pas disponible à vrai dire je n'en sais rien mais c'est un peu de la mauvaise foi.


d) Pas mal de game/level designers sont capables de s'en sortir en blueprint et de prototyper/modifier des éléments de gameplay ou des outils éditeur.
Les blueprints sont super pratiques et pas du tout contre-productif ; certes ça prend plus de place à l'écran et plus de clic-clic-clic, mais le gain de temps pour les progs derrière est énorme. Ce système permet énormément de choses, et c'est un avantage considérable sur Unity (ou autre).


S'il y a un point sur lequel il faut attaquer Epic à mon avis, c'est plutôt sur le manque de tutos et de documentation (autre qu'un listing de fonctions), en particulier pour le C++.
Je me suis retrouvé plusieurs fois à devoir lire les sources et faire du trial&error pour comprendre le fonctionnement de certaines choses, et ça c'est moins excusable.

Edit : j'ai oublié de préciser que Unreal pas plus qu'un autre ne pousse les utilisateurs à faire de la merde. Des gens qui codent n'importe comment et qui savent pas utiliser le moteur, j'en ai vu aussi chez Unity.

[oks2024]

Au passage, Unity 5 est passé gratuit (en dessous d'un certain bénéfice (100 000$ ?), ensuite licence à 1500$, pas de royalties).

*relance de dix*

[Poussin Joyeux]

Pfff... Et moi qui commençais à me mettre à Leadwerks... Je pense que ces dernières années, j'aurai passé plus de temps à essayer les moteurs à cause de leur nouvelles offres qu'à réellement programmer...

[Sahnvour]

Unity était obligé de passer gratuit pour survivre, surtout avec UE4 qui le devient aussi (même le forfait à 20€ par mois aurait suffit à les bouffer).
Du coup ils contre attaquent sur les royalties, c'est pas plus mal.

[Clear_strelok]

Dites-donc messieurs, si on est un petit nouveau dans le monde merveilleux du développement ça vaut le coup de télécharger l'UE4 vu que c'est passé gratuit ? C'est ergonomique et tout ?
C'est pas pour un usage particulièrement complexe, c'est surtout pour des trucs du genre:

• Découvrir un peu cet univers.
• Avoir un bon moteur de rendu pour des modèles et textures que je fais pour mes mods mais que je suis actuellement obligé d'afficher dans un moteur qui les massacre en beauté.
• Et puis le cas échéant pouvoir créer rapidement des cartes simples pour étudier un peu le level design.

[Louck]

Unity était déjà gratuit, dans ses précédentes versions.
Ils ont juste sortie une nouvelle version.

[Roscopolo]

Ça c'est ton avis personnel.

Mon avis est que les handicaps du C++ sont bien réels. A l'évidence nous ne sommes pas d'accord, tu considères mon avis subjectif, je considère que c'est le tien.

et je ne me trouve pas moins productif avec.

Quelques exemples :
* Intellisense ne fonctionne qu'une fois sur trois et il faut des plombes pour construire l'index. Et souvent une lente recherche dans les fichiers est la seule solution.
* "Go to definition" hésite à chaque fois entre plusieurs endroits et ne fonctionne qu'une fois sur trois.
* Les squiggles affichent des erreurs erronées.
* Pour trois erreurs moisies affichées, une seule est vraiment un point à corriger.
* Il faut réapprendre une batterie d'API basiques (structures de données, fichiers, chaînes, etc) spécifiques à UE4 pour compenser l'absence de bonnes API standards.

Oui, j'ai Visual Assist X. C'est mieux mais pas top.

le temps de compilation doit être à vue de nez 2* plus lent sur UE, passant de 3 à 6 secondes

Beaucoup plus. La compilation en C# est quasiment instantanée alors que mes temps de compilation sous VS sont d'une vingtaine de secondes avec un projet encore largement vide (à l'exception des zillions de headers du moteur inclus par défaut par UE4). Tes 6s m'étonnent un peu.

Pour moi la compilation C++ c'est souvent le moment où je perds patience et me déconcentre et finis par aller sur Google ou chercher un café. D'ailleurs devine ce qui m'a ramené ici ?

Ceci dit c'est sûr que C++ accuse son âge à ce niveau là, c'est d'ailleurs pour ça qu'il est prévu de le moderniser drastiquement pour C++17.

Oui, comme on devait le moderniser avec c++ 11. Disons qu'en 2017 on aura un langage au niveau de ce qu'on avait ailleurs en 2000 et que UE7 devrait s'être mis à la page d'ici 2025. Ne resteront alors que les nombreux boulets hérités du passé.

Dans le même genre on devrait avoir une gestion unifée des chaînes de caractères. A la place on doit jongler entre FString, FName, FText, char*, wchar_t*, et autres ! En 2017 dans une API où les chaînes de caractères ne risquent pourtant pas de poser de problème de performance et pourraient très bien être unifiées.

Concernant leur RTTI, il pallie à une "faiblesse" du C++, ou tout du moins un autre paradigme que celui des langages dynamiques post 1990 (oui j'omets volontairement LISP, smalltalk et tout le tintouin). Et en quoi les smart pointers aident à avoir un RTTI ?

Les RTTI ne servent à ma connaissance qu'à deux choses : la sérialisation et le GC. S'il n'y avait que la sérialisation il serait plus simple pour le codeur d'écrire le code manuellement (sans davantage d'erreurs). J'en déduis donc que le choix de requérir ces données est là pour le GC.

Pour la méta-programmation je vois pas où est-ce que tu t'y es heurté Sachant que l'utilisation de templates n'est pas de facto de la méta-programmation.

Pour moi tout usage de templates relève de la métaprogrammation (on les utilise pour générer un code virtuel) mais c'est une question subjective.

Je m'y suis heurté parce que pour simplement savoir si oui ou non dans la version shipping j'aurai des vérifications aux bornes il m'a fallu examiner leurs templates conteneurs, leurs templates allocateurs, leur procédure de build et d'autres choses encore. Ça a été une longue et pénible séquence de poupées gigognes qui, du fait des insuffisances de VS et VAX, s'est avant tout déroulée à grands coups de ctrl+shift+f.

Si je reconnais volontiers que dans la plupart des langages plus modernes le même niveau de modularité des structures de données aurait été impossible sans surcoût ou copié-collé, je pense quand même que les templates ne sont pas un bon modèle. Et puis, bon, parfois le copier-coller est la solution : la preuve, personne n'est satisfait des templates de l'autre et chaque framework réinvente la roue ! Comme quoi il ne faut pas se palucher avec la modularité, ça ne l'est jamais assez. KISS : simple, stupid.

c) Y'a vraiment des studios indés de quelques personnes qui se lancent dans un jeu sans graphiste, et achètent tout sur le marketplace de leur moteur favori

Tu peux très bien avoir des graphistes et acheter des assets secondaires tous faits. Même des studios AAA le font, par exemple pour des objets du quotidien (à quoi bon modeler des couverts ?). Des outils comme Daz3D sont également en vogue pour les persos. Il faut juste éviter de ne pas en abuser, par exemple ne pas afficher une image bof tirée de deviant art en guise de générique de fin (/kiss Bioware).

Allegorithmic est partenaire avec Epic, et fournit des plugins pour utiliser leurs produits. Peut-être que tout n'est pas disponible à vrai dire je n'en sais rien mais c'est un peu de la mauvaise foi.

Je ne connais pas leur business model mais sur le marketplace d'Unity ils vendent leurs substances à la pièce alors qu'il me semble que pour UE tu es obligé d'acheter leur soft. Mais je me trompe peut-être. Ce n'était qu'un exemple de toute façon.

Ce système permet énormément de choses, et c'est un avantage considérable sur Unity (ou autre).

Oui, je l'ai moi-même souligné : c'est formidable pour les game designers. Mais il faut une équipe assez large pour avoir des game designers dédiés et non-programmeurs. Cela dit je veux bien croire que pour le scripting du niveau ça reste avantageux même pour un programmeur, je verrai.

S'il y a un point sur lequel il faut attaquer Epic à mon avis, c'est plutôt sur le manque de tutos et de documentation (autre qu'un listing de fonctions), en particulier pour le C++.

A mon avis c'est surtout la jeunesse de la communauté qui pêche. Après tout la doc de Unity n'est pas tellement meilleure et je préfère avoir les sources. En revanche avec Unity tu trouves ta réponse sous Google en 2 minutes.

Dites-donc messieurs, si on est un petit nouveau dans le monde merveilleux du développement ça vaut le coup de télécharger l'UE4 vu que c'est passé gratuit ? C'est ergonomique et tout ?
C'est pas pour un usage particulièrement complexe, c'est surtout pour des trucs du genre:

• Découvrir un peu cet univers.
• Avoir un bon moteur de rendu pour des modèles et textures que je fais pour mes mods mais que je suis actuellement obligé d'afficher dans un moteur qui les massacre en beauté.
• Et puis le cas échéant pouvoir créer rapidement des cartes simples pour étudier un peu le level design.

L'édition de niveau n'est pas ma spécialité mais il paraît que UE4 est le meilleur sur ce point. De toute façon, oui, essaie, profite du fait que c'est gratuit.

En revanche les moteurs de jeux sont des bousins complexes et rarement ergonomiques, et UE4 et moi sommes partis sur des bases difficiles (supprimer ou renommer un fichier sont apparemment trop high-level pour UE4).

Enfin tu devrais rendre tes modèles avec l'outil qui les affichera, c'est le meilleur moyen de les embellir pour ce dernier. Et UE4 n'est pas un éditeur de modèles 3D même s'il a quelques capacités il me semble.

[oks2024]

Non, Unity était en version Free avec pas mal de limitation qui se révèlent bloquantes sur des projets un peu sérieux. Maintenant c'est Unity avec toute les features qui est gratuit, et ça change beaucoup de choses.

Aussi un détail, les royalties de Unreal c'est 5%, mais sur le prix du jeu, pas sur ce qu'on touche. Si le jeu est vendu sur l'appstore 10$, Unreal touche 0.50c, sans prendre en compte les 3$ que prélève déjà Apple. Si en plus il y a un partenaire, éditeur, ça fait vite un gros coût.

Sinon oui, Clear_strelok, je te conseille au moins de tester, il commence à y avoir une communauté et des tuto pour le prendre en main, et le rendu est quand même agréable sans rien changer.

[Sahnvour]

Mon avis est que les handicaps du C++ sont bien réels. A l'évidence nous ne sommes pas d'accord, tu considères mon avis subjectif, je considère que c'est le tien.

Ce que tu appelles un handicap, c'est simplement une autre façon de faire, avec des avantages et des inconvénients différents.

Quelques exemples :
* Intellisense ne fonctionne qu'une fois sur trois et il faut des plombes pour construire l'index. Et souvent une lente recherche dans les fichiers est la seule solution.
* "Go to definition" hésite à chaque fois entre plusieurs endroits et ne fonctionne qu'une fois sur trois.
* Les squiggles affichent des erreurs erronées.
* Pour trois erreurs moisies affichées, une seule est vraiment un point à corriger.
* Il faut réapprendre une batterie d'API basiques (structures de données, fichiers, chaînes, etc) spécifiques à UE4 pour compenser l'absence de bonnes API standards.

Oui, j'ai Visual Assist X. C'est mieux mais pas top.

Qu'est-ce que ça a à voir avec le C++ ? Visual studio est mauvais pour l'analyse de ce langage, c'est de notoriété publique. Je suis tout à faire d'accord c'est casse burnes au possible mais ce n'est imputable ni au langage ni à UE. D'ailleurs ils ont fait un blogpost pour dire que dans VS 2015 ils ont amélioré ça avec un cas à +15 000% il me semble de mémoire. Peut-être de quoi devenir utilisable

Beaucoup plus. La compilation en C# est quasiment instantanée alors que mes temps de compilation sous VS sont d'une vingtaine de secondes avec un projet encore largement vide (à l'exception des zillions de headers du moteur inclus par défaut par UE4). Tes 6s m'étonnent un peu.

Quand je touche uniquement du code, pas du header inclut dans tout le projet, c'est relativement rapide, de l'ordre de 5/6 secondes environ. De mémoire sur le même ordinateur, Unity était clairement pas instantané non plus et freezait plusieurs secondes quand je revenais sur sa fenêtre. Cela dit ma machine de boulot a de très sérieux problèmes davec son disque dur donc c'est sûrement pas représentatif de la réalité ; c'est pour ça que j'ai pris un cas qui bouffe pas trop niveau IO sur des milliers de fichiers. Je reconnais que ça peut être biaisé donc, mais c'est pas forcément à l'avantage d'unreal.

Pour moi la compilation C++ c'est souvent le moment où je perds patience et me déconcentre et finis par aller sur Google ou chercher un café. D'ailleurs devine ce qui m'a ramené ici ?

Idem, mais pas pour les mêmes raisons

Oui, comme on devait le moderniser avec c++ 11. Disons qu'en 2017 on aura un langage au niveau de ce qu'on avait ailleurs en 2000 et que UE7 devrait s'être mis à la page d'ici 2025. Ne resteront alors que les nombreux boulets hérités du passé.

Dans le même genre on devrait avoir une gestion unifée des chaînes de caractères. A la place on doit jongler entre FString, FName, FText, char*, wchar_t*, et autres ! En 2017 dans une API où les chaînes de caractères ne risquent pourtant pas de poser de problème de performance et pourraient très bien être unifiées.

Je ne suis pas language-layer et tu as sûrement raison pour la première partie, mais dans UE4 ils préconisent d'utiliser la macro TEXT partout, c'est pas le plus pratique mais fonctionne tout seul.
Quant à FString, FText et FName ils ont des utilités différentes et ne servent pas uniquement à gérer du texte. FName a plus une sémantique d'identifiant, FString de mémoire est plus une "string-view", etc.

Les RTTI ne servent à ma connaissance qu'à deux choses : la sérialisation et le GC. S'il n'y avait que la sérialisation il serait plus simple pour le codeur d'écrire le code manuellement (sans davantage d'erreurs). J'en déduis donc que le choix de requérir ces données est là pour le GC.

Cela sert aussi à checker au runtime avec le coût le plus réduit possible si un objet hérite d'une certaine classe ou implémente une certaine interface, alors qu'on utilise un pointeur polymorphe. C'est par exemple utilisé pour la fonction Cast<T>, les itérateurs d'acteurs et d'autres trucs bien pratiques comme le système entité composant

Pour moi tout usage de templates relève de la métaprogrammation (on les utilise pour générer un code virtuel) mais c'est une question subjective.

Je m'y suis heurté parce que pour simplement savoir si oui ou non dans la version shipping j'aurai des vérifications aux bornes il m'a fallu examiner leurs templates conteneurs, leurs templates allocateurs, leur procédure de build et d'autres choses encore. Ça a été une longue et pénible séquence de poupées gigognes qui, du fait des insuffisances de VS et VAX, s'est avant tout déroulée à grands coups de ctrl+shift+f.

Tu veux vraiment invoquer Tomaka et Rout ?
Non c'est pas de la TMP, c'est un truc tout à fait acceptable en production et la bibli standard utilise le même principe pour les conteneurs et les allocateurs par exemple.

Bon voilà pas la peine de rentrer dans un débat du meilleur langage/moteur (surtout que c'est moi qui arrive après la bataille ) mais je tenais quand même à le défendre sur certains points. Et pourtant il me casse les pieds tous les jours sur beaucoup d'autres.

[Roscopolo]

Ce que tu appelles un handicap, c'est simplement une autre façon de faire, avec des avantages et des inconvénients différents.

Attends, faut pas charrier !

* Leur modèle de compilation n'est pas différent, il est obsolète et n'avait sa raison d'être que lorsque les ordinateurs avaient 32ko de RAM et ne pouvaient pas stocker le graphe syntaxique complet de l'appli en mémoire. Et ça entraîne des foules de choses : lenteur de la compilation, difficulté d'écriture de l'outillage (donc mauvais outils), headers et donc nécessaire redondance, ordre d'écriture conditionné par le compilateur plutôt que par l'ordre idéal de lecture, etc.

* Le fait d'avoir 36 types pour les caractères et les chaînes n'est pas différent, c'est juste obsolète (les 1% de cas qui auraient vraiment besoin de types spécifiques et rapides pourraient toujours se débrouiller).

* VS pour le C++ n'est pas différent, il bogue à mort depuis quinze ans, tout simplement. Et encore une fois si tous les outils pour le C++ boguent c'est bien à cause du C++ (trop lent à compiler et analyser, trop complexe, difficulté d'écriture des compilos en général et d'une analyse incrémentale pour intellisense, normalisation tardive, etc).

* L'absence de support natif pour des concepts qui expliciteraient la gestion de la mémoire n'est pas différent, c'est là aussi une mauvaise pratique obsolète : la comparaison avec Swift ou Rust est édifiante et me fait soupirer chaque fois que je dois écrire un monstre comme std::unique_ptr<TArray<MyType>> ou chaque fois que je vois un pointeur brut dans une méthode sans savoir si c'est un paramètre d'entrée ou de sortie et sans être sûr de savoir qui sera la responsable de la durée de vie du pointeur après l'appel.

Et tout ça a forcément un impact sur la productivité, à commencer par le fait de devoir jongler entre en-têtes et sources et tout écrire/modifier en double.


En vrac :
* MS fait toujours de belles promesses, la réalité est toujours décevante. Aujourd'hui j'ai testé d'autres IDE. Qt Creator a l'air d'être robuste, je vais poursuivre mes essais avec lui parce que si je dois passer trente mois avec VC++ je vais être malheureux et haïr ce projet. Je ne suis pas fan de leur espace de travail par contre.

* La compilation proprement dite en C# dure moins d'une seconde même sur de gros projets. Mais Unity semble faire d'autres étapes : je parie qu'il réimporte ensuite la biblio et compile ensuite à la volée de nouvelles méthodes. Ca prend trois secondes et c'est effectivement lourd. Un avantage d'UE4 c'est que tu peux complètement zapper l'éditeur alors que pour Unity le contourner serait trop lourdingue (quoiqu'on peut peut-être écrire un plugin VS pour ça).

* Je te remercie pour l'info pour FName. Mais pour le reste on est bien obligé de naviguer entre TChar* pour les litéraux, FString pour les concaténations et autres, et ensuite n'importe quel autre type selon les besoins de telle ou telle API. Sans vraiment de justification à ça.

* Je te remercie également pour les infos sur les vérifications des types lors des casts. Cela dit je ne pense pas que ça a été ce qui a motivé les dévs d'UE4 à introduire un système de RTTI, je reste sur l'idée que c'est le GC et la sérialisation.

* Enfin j'aurais aussi du mal à dire de C#, c'est loin d'être mon langage rêvé et comme je l'ai dit je ne pense pas que ce soit le bon choix pour ce projet (besoin d'utiliser des biblios écrites en C++, graphe d'objets trop complexe pour un GC non-générationnel, très gros besoins en CPU), d'où en partie mes essais avec UE4. Ecrire des pans significatifs de code c# en unsafe et p/invoke ne semblait pas bien commode.

[oks2024]

Le C++ à sans conteste des défauts, mais pour du jeu vidéo t'a pas trop le choix.

Beaucoup de développeur voudrait changer ça (mais en fait plus pour être plus proche du C que du C#), mais je ne pense pas que ça arrivera, trop de dépendances, d'habitudes, etc.

Unity se permet le C#, parce qu'il n'autorise que du scripting haut niveau, mais tout le reste du moteur est en C++.
Unreal à fait le choix d'un éditeur nodal plutôt qu'un langage de script (il faut dire que leur précédente tentative avec le Kismet était pas géniale), qui génère du C++. Mais dans les fait c'est la même chose, c'est juste que comme UE donne toute les sources tu vois le code engine alors que dans Unity il est caché.

Pour la lenteur de compilation c'est un problème, mais il se contourne. Dans une conf. cppcon un développeur explique leur setup pour la compilations, Assassin's Creed Unity c'est environ 6 millions de lignes de code, et un full rebuild prend 5 minutes. Sur Far Cry 4 ils sont à moins d'une minute.

Après pour ce qui est de Visual Studio et du C++ pour l'utiliser tout les jours j'ai pas vraiment de reproche majeur à lui faire. Enfin c'est sûr que c'est pas parfait, mais j'ai encore rien vu de mieux et ça n'entrave pas ma productivité, une fois deux ou trois réglages/plugins activés. D'ailleurs pour les .h en fait ça me manque en C#, je trouve ça bien plus pratique de pouvoir avoir un résumé d'une classe de manière assez rapide, avec un minimum de commentaires tu as rarement besoin de voir l'implémentation.

Et pour le VS le debugger est assez incontournable, par contre MSbuild pourrais être bien meilleur.

Bref, tout ça pour dire que je pense pas qu'il faille se laisser intimider par le c++ de l'Unreal Engine, à moins de bosser sans arrêt sur l'engine en lui même, je pense qu'on évite une grosse partie de la lourdeur du langage si on se concentre sur le gameplay.



Par contre, un détail pour les RTTI sur les casts à ta place j'en prendrai pas l’habitude c'est assez déconseillé, en fait sur pas mal de projets c'est même souvent complètement désactivé.

[King Kadelfek]

@Roscopolo
@Saito Gray
Je ne sais pas qui a raison et qui a tort, mais en tout cas vous abordez un paquet de points intéressants.

Perso je suis sous Unity et je ne prévois pas d'en changer, mais j'y vois quand même beaucoup d'inconvénients.
En restant avec les outils proposés par Unity (son éditeur Mono) on reste coincé avec une vieille version de .Net. De plus, Unity a ses propres bibliothèques qui viennent oblitérer d'autres classes utiles. Je pense notamment à System.Drawing (pour tracer / dessiner énormément de choses).

Pour moi, l'un des plus gros points noirs d'Unity, c'est une gestion catastrophique des textures. A part un set_pixel(s) / get_pixel(s), il n'y a rien digne de ce nom (même en plugins) pour faire des opérations sur des pixels, ne serait-ce qu'un simple draw ou combine. C'est 15 ans de retard par rapport à la SDL.
Même RPG Maker XP met une misère à Unity sur les opérations pixel. Et en plus, Unity est lent pour ces manipulations.

L'un des plus gros manques est sans conteste l'écriture de textes sur des textures. Avec Unity, pour combiner des images, on est censés créer une caméra virtuelle, positionner les éléments devant et prendre un screenshot avec la caméra virtuelle. Il faut bien sûr oublier le pixel perfect.

> inb4 c'est un logiciel 3D t'as qu'à utiliser des shaders
Oui mais non. Il y a des domaines complets des textures qui nécessitent de vraies compositions et opérations pixel à pixel.
Je pense notamment à la fabrication procédurale d'images comme les cartes à jouer. Particulièrement quand on traite avec des lectures / écritures sur disque.

De plus, l'importation de textures avec Unity prend obligatoirement en compte les informations gamma de l'image, ce qui cause des changements de teinte (invisible à l'oeil nu, mais pour les combinaisons de pixels c'est l'horreur).

Enfin bref, Unity 3D pour traiter des textures 2D, c'est pas la joie.

[Sahnvour]

Par contre, un détail pour les RTTI sur les casts à ta place j'en prendrai pas l’habitude c'est assez déconseillé, en fait sur pas mal de projets c'est même souvent complètement désactivé.

C'est pourtant la base pour savoir avec quel type d'actor ou composant tu travailles, même en blueprint.

[oks2024]

Je viens de vérifier et sur UE4 aussi les RTTI c++ sont désactivés, et ils utilisent leur propre système à la place.

[Sahnvour]

Ah oui, quand Roscopolo parlait de RTTI c'est le système de reflection maison d'Epic.

[Roscopolo]

Beaucoup de développeur voudrait changer ça (mais en fait plus pour être plus proche du C que du C#), mais je ne pense pas que ça arrivera, trop de dépendances, d'habitudes, etc.

Les habitudes ça peut se vaincre, le problème c'est qu'il faut pouvoir s'interfacer avec le code C++ des plateformes et biblios tierce-parties. Au moins pouvoir générer automatiquement des imports des classes et fonctions, ça ferait déjà le gros du boulot.

Ensuite, oui, le remplaçant de C++ sera un autre langage de bas niveau. Je voterai pour Rust lorsqu'il sera plus mûr.

Enfin si c'est pour faire du C++ avec un ramasse-miettes à moitié fait et des vérifications des bornes en shipping, autant faire du C#. Le C++ utilisé au quotidien y compris dans les parties critiques d'applis hautes-performances est de moins en moins bas niveau. Pendant ce temps il y a désormais de bons compilateurs AOT C# et certains offrent la possibilité de désactiver les vérifications aux bornes. Le delta performances est très faible et tu peux utiliser des tableaux pour éviter le GC Le code critique reste plus difficile à écrire et maintenir qu'en C++ mais ça se fait et tu te rattrapes sur le reste.

Après pour ce qui est de Visual Studio et du C++ pour l'utiliser tout les jours j'ai pas vraiment de reproche majeur à lui faire. Enfin c'est sûr que c'est pas parfait, mais j'ai encore rien vu de mieux et ça n'entrave pas ma productivité, une fois deux ou trois réglages/plugins activés.

Disons que tu t'es habitué à avoir des fonctionnalités qui déconnent deux fois sur trois : intellisense à désactiver complètement, bascule source/header, autocomplétion, fausses erreurs, find all references moins efficace qu'un ctrl+shift+f.

A peu près rien ne marche pour l'édition. Si ce n'était le déboguage et Visual Assist qui sauve un peu la mise, VS serait un notepad++ à 1k€. Et effectivement les produits concurrents ne valent guère mieux. C'est la grosse misère quand tu as l'habitude d'autres langages où l'IDE fait son job.

Mais, oui, on s’habitude à tout. Demande à un manchot cul-de-jatte aveugle, il te dira qu'une fois le coup de main nez pris, ce n'est pas si terrible.

Bref, tout ça pour dire que je pense pas qu'il faille se laisser intimider par le c++ de l'Unreal Engine, à moins de bosser sans arrêt sur l'engine en lui même, je pense qu'on évite une grosse partie de la lourdeur du langage si on se concentre sur le gameplay.

Je suis d'accord, mon problème n'est pas tant avec les API d'UE4 pour lesquelles je suis bien conscient qu'il y a une étape d'adaptation assez longue à gober mais après laquelle ça ira. Mon gros problème c'est l'outillage minable du C++.

...

Oublie tout de suite cette grosse bouse de MonoDevelop et utilise Visual C# Express (gratuit) avec le plugin Unity(gratuit). Oui le plugin peut désormais fonctionner avec la version express.

La seule raison pour utiliser MonoDevelop c'est si tu bosses sur Mac. Unity étant développé sur Mac, ceci explique cela.



Ensuite j'ai du mal à voir en quoi ton besoin de composition pixel-à-pixel ne peut pas être satisfait par un shader, voire par un rendu vers une texture dans certains cas, mais tu as peut-être raison. Mais alors si vraiment tu veux faire du dessin côté CPU je pense que ça relève d'une biblio spécialisée. D'ailleurs je ne crois pas que UE4 ait davantage d'outils pour toi. Par exemple un rendu parfait du texte serait sans doute trop coûteux pour un jeu, il faut des techniques spécifiques côté GPU (distance field et coverage mask perso, éventuellement avec subpixel rendering - à la Qt/WPF).

Après si tu veux faire ça toi-même (pas le texte) il ne faut surtout pas passer par GetPixel/SetPixel ! Il faut directement lire et écrire l'image entière d'un coup et manipuler un tableau de pixels. Pour accélérer encore les choses, tu peux faire ça en code unsafe (tu épingles le tableau via fixed et tu manipules ton pointeur comme un tableau).

Note aussi qu'il existe des wrappers dotnet pour la SDL ou d'autres biblios. Cherche du côté de OpenTK ou Monogame. Ces solutions peuvent sans doute être utilisées avec Unity et sont portables.

Enfin pour le texte dans les JV, vu qu'on utilise typiquement de larges tailles visibles de loin et suffisamment grandes pour afficher une bordue autour, on privilégie les bitmaps fonts. C'est rudimentaire, rapide et cela donne de très beaux résultats, surtout si le bitmap a été fait avec amour plutôt qu'automatiquement depuis une fonte vectorielle.

[tompalmer]

Question : on peut faire que des fps/TPS ou globalement de la 3D avec Unreal ? Rien en 2D ?