# Jeux vidéo > Jeux vidéo (Discussions générales) > Le coin des développeurs >  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&amp;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  ::rolleyes:: 

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é  ::huh::  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  ::huh:: 

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  ::P: 




> 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  ::o: 





> 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 ?  :B): 
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 ?

----------


## oks2024

https://www.unrealengine.com/html5/

Il y a un support de la 2D, j'avais vu quelques tuto, mais pour être honnête je ne sais pas ce que ça peut valoir. Par contre sur ce point Unity s'est bien améliorer.
Pour la 3D par contre je ne pense pas qu'il y ai de restrictions, surtout que vu que le code source est dispo tu peut toujours modifier quelque chose de bloquant.

----------


## Sahnvour

Tu peux faire de la 2D, mais le code est considéré "early access".
J'ai eu un peu à l'utiliser, et ça marchait plutôt pas mal mais j'étais loin de faire un jeu 2D, c'était plutôt de l'intégration d'éléments 2D dans un monde 3D. Donc c'est faisable mais il faut garder en tête que tu peux rencontrer quelques problèmes.

----------


## Saito Gray

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


Bon alors Unreal c'est comme Unity, un moteur 3D généraliste.Tu peux faire tout ce que tu veux avec.

Les exemples présents sur le site te montre quand même plein de choses, on a de la prévisualisation architecturale, un top down shooter, un jeu de stratégie, un FPS un TPS. Bref, tu es complètement libre.

Concernant la 2D c'est la même chose qu'Unity. Si c'est pour faire de la 2D pure, un jeu uniquement constitué de menu par exemple, c'est pas vraiment l'idéal.

Unreal inclu Paper2D un chouette plug-in qui facilite beaucoup l'utilisation de sprites 2D dans le jeu.
Beaucoup on déjà bricoler avec, on trouve des top down shooter, des shmup, des petits jeux mobiles tout simples.
Malgré tout le module est encore en développement, il n'a pas encore de documentation complétée et n'a donc pas de tuto officiel. Mais la communauté commence à s'intéresser à Paper2D et commence à sortir de bon tuto sur le sujet.

Après Unreal ne fait pas de miracle. Même avec son système de visual scripting il est quand même indispensable d'avoir des bases en programmation pour sortir quelque chose d'intéressant.

----------


## Adu

Ok, donc pour tout ce qui est shoot'em up type R-Type ou autre plateformers à la Mario, je suis limite même plus dirigé vers Gamemaker que Unity alors ?

----------


## oks2024

Après rien n'empêche de faire un shmup 3D avec un gameplay 2D.
Par contre pour un jeu de plateforme ça signifie que tu va devoir faire des animations, et là c'est un challenge de plus.

Mais oui, si tu veux faire de la 2D, travailler avec des sprites, je me renseignerai un peu plus sur Unity, voir si tu peut arriver simplement au résultat que tu veux, et sinon Gamemaker est fait pour ça, mais je l'ai trouvé plus limité, lourd, et moins agréable à utiliser.

----------


## Iwakurasan

> Ok, donc pour tout ce qui est shoot'em up type R-Type ou autre plateformers à la Mario, je suis limite même plus dirigé vers Gamemaker que Unity alors ?


  Ca dépend du résultat que tu veux obtenir. Si tu veux de la vraie 2D "plate", oui. Mais tu peux également faire un jeu en 3D avec un scrolling 2D (comme ça ou ça).

----------


## Saito Gray

Unity et Unreal ont quasiment les mêmes fonctions et la même manière de faire en ce qui concerne la 2D, le plus d'Unity actuellement c'est son nombre de tuto (même si en trouver un qui est a jour n'est pas chose simple).

Le choix d'un moteur dépend surtout de ce que tu veux faire, mais il faut aussi prendre en compte avec quel outil tu es le plus a l'aise.

Pour un jeu 100% 2D sans effets de lumière, de déformation ou de truc un peu compliqué le mieux ça reste d'utilisé un moteur dédié a la 2D.
Game maker ou Love sont de très bons exemples qui sont très bons et simples a utilisé (même si Love2D demande des connaissances en programmation. Mais bon, le Lua c'est vraiment pas le langage le plus complexe)

Game Maker n'est pas limité. Si on passe par le langage de script et que l'on planifie bien sont projet avant de se jeter dedans le moteur peu faire des choses très intéressantes et rapidement.
C'est un très bon moteur 2D qui se colle un peu une mauvaise réputation à cause de ses outils drag and drop limité. Mais en tant que moteur il fait des choses très sympa, Hotline Miami et Spelunky sont là pour le prouver.

----------


## Adu

Oui, je cherche un truc vrai 2D plate ave des sprites à l'ancienne, donc ok, je reste sur gamemaker alors  ::):

----------


## tompalmer

Game maker c'est la life

----------


## Metalink

Ouais mais Gamemaker ça donne pas de taf dans l'industrie  :tired:

----------


## Iwakurasan

> Ouais mais Gamemaker ça donne pas de taf dans l'industrie


Va dire ça aux gens de Dennaton.  ::P:

----------


## Saito Gray

Même s'il n'est pas le plus utilisé, Game maker a quand même un petit palmarès au sain de l'industrie.
Une fois que tu connais et maitrises un moteur de jeu, passer d'un moteur à l'autre n'est pas si difficile que ça. L'important c'est d'avoir de l'expérience, de savoir comment fonctionne la logique d'un jeu. Une fois que tu maitrises ça, c'est relativement simple de passer d'un moteur à un autre.

"L'industrie" s'en tape un peu sur quel moteur tu as travaillé, l'important c'est d'avoir de l'expérience. De toute façon les gros studios on leur propre moteur et même s'ils utilisent quelque chose comme UE4 il y a fort a parier que tu serras quand même formé pour coller a leur manière de travailler.

D'autant plus qu'actuellement pour rentrer dans l'industrie, surtout chez les gros, si tu n'as pas des compétences ultras spécialisées, tu as beau connaitre le moteur sur le bout des doigts tu ne les intéresseras pas spécialement.

----------


## Metalink

Je sais, je sais et je suis bien d'accord avec vous  :;): 
Je dis juste que voilà, si on se place d'un côté purement "compétences", j'ai encore jamais vu d'offre d'emploi ou de studio qui mentionnant GM, contrairement à Unity ou autres  ::P:  Bref, désolé pour ce petit HS, c'était juste une petite remarque !

----------


## oks2024

Non, non, je suis d'accord avec toi, pour quelqu'un qui voudrait le lancer dans un petit projet histoire de se faire la main en vue de gagner de l'expérience pour ensuite travailler dans le jeu vidéo, ça serai une à mon avis une erreur de choisir gamemaker.

Ce n'est pas utilisé ditout, et les exemples de jeux réalisé avec gamemaker viennent de studio indé, de deux ou trois personnes, et qui ne recrutent absolument pas.
De plus Gamemaker avec son langage à lui et sa façons de tout simplifier font qu'il est vraiment très particulier, et que peu de choses que tu va apprendre là seront réutilisable ailleurs.

En gros c'est parfait pour des game designer qui veulent mettre en application des idées de gameplay sans trop se compliquer les choses avec du code, pour un programmeur l’intérêt est pas très grand.

Unity est assez incontournable, il est accessible gratuitement depuis un petit moment maintenant, et j'aurai du mal à croire qu'une personne désirant bosser dans le jeu vidéo n'y ai pas jeté un coup d’œil. Pour du jeu mobile ou pour des programmeurs qui veulent se spécialiser dans le gameplay, ça me parait l'idéal.

Unreal Engine c'est un peu le Graal des aspirant programmeurs Engine/graphique, dans Unity toute cette couche la est cachée, abstraite, si bien que quand tu arrive dans un studio et que tu te retrouve a devoir modifier un moteur de plusieurs millions de lignes de code tu ne sais pas par où commencer. Maintenant c'est possible de se faire une idée avant d'être dans une grosse boîte, et à mon avis c'est un gros plus sur un CV.

----------


## tompalmer

Mais qui voudrait se lancer dans un tel panier de crabe que l'industrie du jeu vidéo ?  ::P:  

Restez dans l'artisanat

----------


## King Kadelfek

> 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.


Merci pour les informations, je vais aller voir de ce côté.  ::): 




> [...] tu épingles le tableau via fixed et tu manipules ton pointeur comme un tableau 
> [...] wrappers dotnet pour la SDL ou d'autres biblios.
> [...] OpenTK ou Monogame


Ça me fait pas mal de pistes à explorer, merci.




> 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.


 Je me suis déjà retrouvé coincé dans les pièges de la localisation  (j'ai fait un soft de localisation pour RPG Maker), alors je fais très  attention à ça. Pour l'instant, j'utilise plutôt des fonts courantes  gérant déjà tout l'UTF-8 + ANSII et ses copains (tous caractères  occidentaux).




> 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.


C'est pour faire des écritures de fichiers PNG sur disque. Ça ressemble à des cartes à jouer, mais c'est fait pour partager des créations réalisées ingame avec d'autres joueurs.



Les informations sont codées dans la bordure de l'image (et répétées, ce qui crée le schéma). J'ai bien sûr besoin d'importer les images en pixel perfect, c'est pour ça que je parle des problèmes liés aux informations gamma (qui changent les valeurs RGB ).

Sinon, outgame je travaille au maximum avec ImageMagick, ça aide beaucoup pour le contrôle du format et des informations.



Je pense qu'il doit y avoir des librairies pour importer des textures  ingame dans Unity, plutôt que les solutions comme Resources.Load et WWW.
Enfin bon, là on est dans un domaine très spécifique, et je doute que Unreal apporterait un avantage. Je vais repartir sur Unity avec les nouvelles pistes.  ::):

----------


## Roscopolo

> Je me suis déjà retrouvé coincé dans les pièges de la localisation  (j'ai fait un soft de localisation pour RPG Maker), alors je fais très  attention à ça. Pour l'instant, j'utilise plutôt des fonts courantes  gérant déjà tout l'UTF-8 + ANSII et ses copains (tous caractères  occidentaux).


Au pire tu peux avoir deux solutions : une bitmap pour les occidentaux, une vectorielle pour les autres. Mais si vraiment tu veux un beau résultat il te faut des bitmap fonts et/ou de larges polices. Pas forcément grandes mais larges, ou avec détour/outline (ce qui n'est pas trivial du tout et ce que font correctement les générateurs de bmp fonts si je ne m'abuse).




> http://i291.photobucket.com/albums/l...0_00_00_00.png


Ouhlà, oui, c'est sale, ça sent le manque de hinting, tu as utilisé FontRenderingMode.Smooth au lieu de HintedSmooth ? Ou alors tout a peut-être été décalé d'un demi-pixel lors de ta composition ? Ou l'antialiasing global était peut-être activé ?

Cela dit, même s'il y a une anomalie ici, tu auras de toute façon du mal à obtenir un vrai bon résultat avec une police aussi fine. Surtout sans subpixel rendering.




> Enfin bon, là on est dans un domaine très spécifique, et je doute que Unreal apporterait un avantage. Je vais repartir sur Unity avec les nouvelles pistes.


 Faudrait tester. Si j'étais plus avancé avec UE4 je t'aurais bien fait ça en deux coups de cuillère à pot mais pour l'instant ça me prendrait une demi-journée (x3 avec le coeff de sécurité).

----------


## Roguellnir

> Non, non, je suis d'accord avec toi, pour quelqu'un qui voudrait le lancer dans un petit projet histoire de se faire la main en vue de gagner de l'expérience pour ensuite travailler dans le jeu vidéo, ça serai une à mon avis une erreur de choisir gamemaker.
> 
> Ce n'est pas utilisé ditout, et les exemples de jeux réalisé avec gamemaker viennent de studio indé, de deux ou trois personnes, et qui ne recrutent absolument pas.
> De plus Gamemaker avec son langage à lui et sa façons de tout simplifier font qu'il est vraiment très particulier, et que peu de choses que tu va apprendre là seront réutilisable ailleurs.


Bah... Ce qui compte le plus c'est ta capacité a t'adapter. Connaitre bien un soft utilisé par une boite c'est un plus, mais le contraire est pas un frein obligatoire.
Un moteur subit une terrible mutation durant son utilisation intensive sur un projet, du coup certaines habitudes de la version "vierge" deviennent trompeuses. Pire certaines de ses transformations pourront se retrouver portées sur un projet différent parce qu'elles sont historiques a l’équipe et là... 
Parlant d'habitudes trompeuses, ce que tu vas apprendre par toi meme sur ton projet ne correspond peut-être pas a la façon de produire a grosse échelle, et tu vas devoir perdre des habitudes pour rentrer dans le carcan d'une production lourde/longue/multi-plateformes/etc.
Il y a aussi tous les outils internes avec des techno' propres a la boite que tu auras jamais eu la chance de rencontrer.

Bref, ce que tu fais de ton Game Maker comptera quand même. Ensuite faudra assurer sur la question du "Pourquoi avoir choisi Gamemaker ?"



> Mais qui voudrait se lancer dans un tel panier de crabe que l'industrie du jeu vidéo ?  
> 
> Restez dans l'artisanat


Il en faut ! Et il y'a de l'artisanat a tous les niveaux, n'en déplaisent a certains.

----------


## King Kadelfek

> Ouhlà, oui, c'est sale, ça sent le manque de hinting, tu as utilisé FontRenderingMode.Smooth au lieu de HintedSmooth ? Ou alors tout a peut-être été décalé d'un demi-pixel lors de ta composition ? Ou l'antialiasing global était peut-être activé ?


Je crée une caméra secondaire + render texture, j'affiche un 3D text à l'écran, puis je récupère la render texture (qui a un fond transparent) et je la combine avec la texture de la carte à jouer.
Je le fais une fois par texte (titre, nom d'auteur, numéro de version, description, etc) et je fais tout ça à l'échelle 1:1 (ce qui revient à afficher des 3D Texts faisant à peine quelques pixels de haut à l'écran). Je pourrais aussi afficher la carte à jouer dans la caméra secondaire, afficher tous les textes et faire une seule capture avec la render texture.
Je précise qu'il s'agit d'un fichier PNG généré sur le disque et fabriqué au maximum en CPU, pas un élément ingame avec des GameObjects. 

Caméra + Render Texture sans planche de Bitmap fonts est la solution la plus simple que j'ai trouvée à l'époque sur les forums Unity. Mais bon, aussi, les forums Unity sont remplis de types qui donnent des procédures en 25 étapes pour afficher un rectangle à l'écran, alors je veux bien croire qu'il y ait mieux que la render texture.

De ce que j'ai pu voir, la plupart des CCG créent carrément leurs cartes outgame (exemple : Photoshop et batch), pour avoir le résultat voulu. Ça explique les Go d'installation pour des jeux quasiment sans graphismes. J'ai réfléchi d'ailleurs à une génération ingame des cartes avec ImageMagick en line command, mais ça compliquerait la compatibilité alors que j'ai déjà un build Linux 100% fonctionnel sans effort (les cartes servent à partager les créations des utilisateurs donc elles nécessitent d'être créées côté client).
(je sais, il y a des builds Linux et Mac pour ImageMagick, donc ça reste possible, mais je n'ai pas ces plateformes)

(je m'aperçois que mes posts deviennent un peu HS par rapport au sujet, je m'en excuse, j'irai créer un autre topic)

----------


## Roscopolo

> Je crée une caméra secondaire + render texture, j'affiche un 3D text à l'écran, puis je récupère la render texture (qui a un fond transparent) et je la combine avec la texture de la carte à jouer.


Avant toute chose je rappelle que j'ai peu d'expérience avec Unity (un mois). En revanche je m'y connais pas mal en rendu du texte.

Ta méthode me semble bonne à une grosse exception près : l'utilisation d'un 3D mesh. Typiquement ce genre de choses est fait pour matérialiser un gros texte en 3D avec perspective & co, pas pour afficher un petit texte ajusté au pixel près. Utiliser le système d'UI d'Unity me semble plus judicieux.

Ensuite, comme je l'ai dit, ton problème c'est le manque de hinting : si la barre de ton L fait un pixel de large, il faut décaler le rectangle du L pour que la barre ne soit pas à cheval sur deux pixels. En cherchant Unity hinting, je suis tombé hier sur FontRenderingMode qui propose HintedSmooth. Je viens de relancer Unity et quand tu importes une police il te propose de choisir le "rendering mode". Essaie donc de changer ça.

Concernant ImageMagick, de ce que j'en sais il opère le traitement "standard" : anti-AA en niveau de gris + hinting. Je pense que Unity peut en faire de même. Quant à photoshop il joue dans une autre catégorie : leur traitement des polices est tel qu'à ce stade ce n'est plus de l'algorithmique, c'est du vaudou.  Il met la honte à n'importe quel OS ou biblio 2D de ma connaissance. Et je ne te parle même du résultat si tu ajoutes une légère ombre portée derrière ou un détour - à ce stade c'est orgasmique et tu courras très longtemps avant d'obtenir le même résultat programmatiquement.

Enfin en chechant Unity hinting tout à l'heure j'ai vu un lien qui pointait apparemment sur un plugin Unity utilisant les signed distance field. Au cas où même après avoir forcé le hinting tu n'aurais pas un résultat suffisant. Mais d'abord tu devrais changer de police.

----------


## King Kadelfek

L'ordre de rendu des éléments sous Unity rend difficile la capture de GUI, il faut faire de l'asynchrone avec des coroutines, etc. Ça ne m'a pas posé de problèmes pour le système de screenshots, mais bizarrement les autres systèmes ont été plus compliqués.
Je ne connaissais pas le hinting. Et je n'ai pas fait du tout attention au rendering mode.

Je suis dans une philosophie de développement ou une première version graphiquement crade peut tenir la route, du moment que niveau data c'est pur. Je vais quand même tenter ma chance sur ces éléments que tu indiques pour améliorer le tout.  ::): 

Merci pour tes conseils Roscopolo.  :;):

----------


## Sahnvour

SFML pourrait peut-être faire l'affaire ?

----------


## Poussin Joyeux

En découvrant le concours CPC, j'ai découvert les Jams de itch.io et en voici une en rapport avec les discussions enflammées qui ont suivi les annonces UE4 et Unity:
http://itch.io/jam/battle-of-the-engines

 ::P:

----------


## King Kadelfek

> SFML pourrait peut-être faire l'affaire ?


J'ai fait un tour sur leur forum et quelques recherches Google, et je ne vois pas de preuve comme quoi c'est viable de faire tourner SFML.Net avec Unity.
Par contre, je remarque qu'ils ont un binding Ruby (je fais du prototypage rapide avec Ruby), alors je testerai. Merci du lien.  :;): 





> En découvrant le concours CPC, j'ai découvert les Jams de itch.io et en voici une en rapport avec les discussions enflammées qui ont suivi les annonces UE4 et Unity:
> http://itch.io/jam/battle-of-the-engines


Oh, c'est le genre de trucs qui fait qu'après on a des articles comparatifs pour l'utilisation des softs. Genre "sous X c'est facile de faire Y mais moi j'ai choisi Z".  ::): 

Y'a une réduction de 50% sur l'un des premiers jeux envoyés, il faut se dépêcher de l'acheter.  ::P: 
http://theimpossiblegamemaker.itch.io/the-horror-v001

----------


## Sahnvour

Pourquoi ce ne serait pas viable ?
SFML est modulaire, tu peux très bien l'utiliser uniquement pour faire du rendu dans une texture et la sauvegarder sur le disque, ça ne devrait pas poser de problème que ce soit inclus dans un projet Unity, pour ce que j'en sais.

----------


## King Kadelfek

> Pourquoi ce ne serait pas viable ?
> SFML est modulaire, tu peux très bien l'utiliser uniquement pour faire du rendu dans une texture et la sauvegarder sur le disque, ça ne devrait pas poser de problème que ce soit inclus dans un projet Unity, pour ce que j'en sais.


Je n'ai pas dit que ce n'était pas viable, j'ai dit que je n'en voyais pas de preuves : je n'ai trouvé aucune personne disant avoir intégré SFML dans Unity, y compris après des recherches approfondies sur le forum officiel SFML. 
Techniquement, tout est possible. Mais :
1- il n'y a aucune documentation ou tutoriel sur comment faire cela
2- peut-être que ça va prendre beaucoup de temps à faire
3- s'il y a un problème, personne ne peut aider 
4- même si ça marche, peut-être qu'il y aura des soucis futurs (comme par exemple la compatibilité pour le build Web ou le build Linux)

Il m'est déjà arrivé de faire des portages et de développer des moteurs graphiques / physiques avec des librairies ou combinaisons de librairies peu connues, je connais les risques. Ça peut potentiellement faire perdre des jours de développement, avec des problèmes ultérieurs inconnus que l'on se retrouve à supporter parce qu'on a bâti son architecture sur une solution manquant de fiabilité. 
C'est la même raison pour laquelle une boîte n'engage pas un prestataire qui n'a pas fait ses preuves.

Dans l'immédiat, je préfère donc chercher un peu plus pour voir si je peux trouver une solution qui a fait ses preuves.

----------


## Poussin Joyeux

Certains d'entre vous ont sorti un jeu sur UE4 ou ont la réponse à ma question ci-dessous? 
Je me demande juste comment ils font pour savoir combien de personnes ont acheté le jeu (comme ils prélèvent 5% par jeu vendu).

----------


## schouffy

Bah c'est à toi de leur déclarer ton CA et leur part. Ils te font "confiance".

----------


## Poussin Joyeux

Ok merci pour ton retour!
Je me demandais s'il y avait un système de connexion en ligne pour repérer les nouveaux utilisateurs, etc... Mais donc c'est basé sur une simple déclaration. 
J'imagine que si le jeu sort sur Steam avec le logo UE au démarrage, ils doivent quand même avoir un contrôle pour vérifier que ce jeu leur rapporte bien des sous (car sinon les gens pourraient omettre de déclarer leur jeu!).

Je précise que je n'ai encore pas touché à UE4. Je me posais juste la question car je trouve le rendu UE4 plus sympa que sur Unity.

----------


## schouffy

Je pense qu'ils s'en tapent un peu, peut-être un contrôle par-ci par-là pour l'exemple, mais leur revenu vient des studios AAA.
Et quand tu commences à avoir > 100k€ par an de revenu, tu achètes ta licence avec plaisir.

Au fait toutes les infos sont là : https://www.unrealengine.com/release

Le rendu UE4/Unity, c'est pas vraiment une question de moteur, plutôt une question d'assets. C'est juste que UE4 est distribué avec des assets, materials, shaders etc de super bonne qualité, donc le petit proto bidon que tu vas faire en 1 heure t'en mettra plein les yeux. Mais tu peux sans doute obtenir un rendu aussi bon sur Unity. (Même si j'avoue que les démos UE4 sont souvent au dessus des démos Unity, peut-être que leur budget est supérieur aussi). Jette un oeil à Layers of Fear pour un jeu Unity qui a vraiment de la gueule par exemple.
De toute façon tu peux pas trop te tromper, ce sont deux super moteurs. J'ai choisi Unity car pour le mobile c'est mieux, et parce que je suis bcp plus productif en c#. Mais si tu connais c++ et que tu veux faire du desktop, tu peux te jeter sur UE4.

----------


## Roscopolo

> Certains d'entre vous ont sorti un jeu sur UE4 ou ont la réponse à ma question ci-dessous? 
> Je me demande juste comment ils font pour savoir combien de personnes ont acheté le jeu (comme ils prélèvent 5% par jeu vendu).


Comme toujours dans ce genre de contrat ils utilisent des audits : tu es tenu par la licence de maintenir une comptabilité détaillée et vérifiable des ventes, et Unreal peut à n'importe quel moment t'imposer un audit (à leurs frais pour UE4). Et ils en conduisent.

Souvent l'entreprise vendant ce type de contrat a aussi en place des moyens d'estimer tes ventes avant l'audit. Par exemple via des contacts chez les revendeurs, enquêtes d'opinion, comptes publics, etc.





> Et quand tu commences à avoir > 100k€ par an de revenu, tu achètes ta licence avec plaisir.


Dans le monde merveilleux de Winnie l'Ourson peut-être, mais dans la réalité où les studios indés ont des charges et salaires à payer et des bénéfices serrés, souvent inférieurs à 10%, quand il n'y a pas de déficit, l'idée de refiler 5% à Unreal est tout sauf une partie de plaisir. D'où les contrôles.

Ton raisonnement découle, je présume, de l'idée que tu te places dans le cas d'un dév solo ne se versant pas de salaire et pour qui tout revenu est donc un bénéfice. Ce n'est pas le cas du studio indé normal.

----------


## schouffy

Je me plaçais dans le cas d'un dév solo qui se verse un salaire, et est bel et bien supposé payer ses outils lorsque ces derniers lui rapportent des sous.
Je t'accorde que je n'ai jamais approché la rentabilité sur un projet de jeu vidéo, donc mon point de vue est assez naïf  :;):

----------


## Poussin Joyeux

Merci pour vos retours à tous les deux (et pour le lien vers la page UE4 qui détaille tout le processus). 
Quand on est arrivé à gérer le développement d'un jeu jusqu'au bout et à le mettre en vente, faire cette démarche une fois par trimestre, ce ne doit pas être le plus compliqué j'imagine.

Et *schouffy*, Layers of Fear est en effet très joli! (même si je préfère les jeux aux teintes plus claires)
J'avais regardé sur Google images des screenshots de jeux sur Unity puis sur UE4 et à chaque fois je trouvais les images plus belles sur les jeux UE4. Mais comme tu dis, en plus des assets, le budget n'est pas le même non plus sans doute!

- - - Mise à jour - - -




> Je me plaçais dans le cas d'un dév solo qui se verse un salaire, et est bel et bien supposé payer ses outils lorsque ces derniers lui rapportent des sous.
> Je t'accorde que je n'ai jamais approché la rentabilité sur un projet de jeu vidéo, donc mon point de vue est assez naïf


J'espère que tu as une autre activité à côté alors, en attendant la gloire  ::P:

----------


## Poussin Joyeux

Je l'ai installé mais j'avais des problèmes car le Epic Games Launcher ne parvenait jamais à se connecter aux serveurs (je suis sur Windows 10 et avec BitDefender).
J'ai fini par trouver la solution alors je la place ici au cas où  ::): 

Il faut rajouter *-http=wininet* à la fin de la ligne de commande:
*"C:\Program Files\Epic Games\Launcher\Portal\Binaries\Win64\EpicGamesLaun  cher.exe" -http=wininet*

----------


## Poussin Joyeux

Bon finalement, je vais retourner sur Unity pour l'instant car bien que ce soit plus effectivement plus joli au premier abord (et je trouve l'éditeur très bien aussi), c'est par contre assez lourd en terme de génération. 
J'ai par exemple ajouté une petite montagne à un exemple de base et il a mis presque 5mn à recalculer l'éclairage avant de jouer la scène. Je n'ai sans doute pas le PC adéquat pour l'instant!

----------

