D'Unity 2D à Unreal Paper 2D

La Game Developers Conference approche à grands pas et nous sommes impatients d’entendre les annonces des grands studios !

Cela faisait un moment que je voulais essayer l’Unreal Engine. Je ne doutais pas qu’il puisse surpasser Unity sur des rendus 3D complexes, mais pour ce premier test je me suis concentré sur des choses simples en 2D pour me familiariser avec l’interface utilisateur, le processus de build du moteur, le scripting… L’Unreal Engine ressemblait dans mon esprit à une bête indomptable (j’ai passé des heures sur Unreal Tournament quand j’étais jeune) mais venant d’un background Unity, la bête a été facilement apprivoisée ! Si vous n’avez jamais essayé l’Unreal Engine, la première chose à faire est de consulter le guide Unreal Engine 4 pour les développeurs Unity !

Moteur & Éditeur J’ai installé Unreal sur mon Mac et mon PC. Mon vieil iMac (2013) arrive à le faire tourner, mais je n’imagine pas y développer un gros projet 3D. Comparé à Unity, ça semble bien plus lent, j’ai eu des freezes, des crashs, etc. Mais le truc génial, c’est qu’aucun Mac n’est nécessaire pour faire un build iOS ! Unreal rejoint ainsi Adobe AIR comme seules technologies permettant de builder pour iOS depuis un PC, et c’est énorme ! À noter que je suis un utilisateur Mac heureux, mais avoir le choix, ça compte.

L’éditeur d’Unreal ressemble à celui d’Unity, avec un Content Browser, un World Outliner (Hiérarchie), Details (Inspector)… Vous ne serez pas perdu puisqu’il utilise lui aussi un système entité/composant.

Après avoir créé un projet, ou lancé des exemples, la première chose que l’on remarque facilement, c’est qu’il y a des tonnes d’objets créés au runtime ! Un projet Unreal ne démarre pas avec une Scène vide comme dans Unity. Chaque projet Unreal est associé à un GameMode. La lecture de la documentation du GameMode vous rappelle qu’Unreal Engine a été conçu pour faire des jeux FPS 3D multijoueurs ! Donc oui, il n’y aura probablement pas de Deathmatch dans votre app, ni de Match State ou de Spectators… mais vous ne pouvez pas retirer le GameMode de votre projet, donc il faut vous y familiariser. Côté positif, notez que si un jour vous devez supporter le multijoueur dans votre app, le moteur sera presque prêt !

J’ai donc configuré mon personnage blueprint (j’y reviens plus loin) comme Default Pawn Class du GameMode et je l’ai placé dans le niveau. Mais à la compilation, comment ça, il y a deux personnages ? Le deuxième est créé automatiquement par le GameMode ! J’ai mis une éternité à comprendre comment supprimer / empêcher celui créé par le GameMode au runtime ! Sélectionnez le composant Pawn, puis pour la propriété auto possess player, choisissez player 0. Et voilà !

Ajout de sprites 2D Unreal fonctionne bien avec les SpriteSheets. En utilisant TexturePacker, vous disposez d’un template prêt à l’emploi, donc vous pouvez facilement exporter vos assets pour Unreal. Le système 2D d’Unreal s’appelle Paper2D. Comparé à la 2D d’Unity, il y a des avantages et des inconvénients :

• Support des TileMaps !
• Pas de moteur physique 2D (Box2D uniquement supporté sur la plateforme Windows).
• Pas d’effecteur 2D (comme une plateforme à sens unique).
• Le Z-sorting ou Y-sorting (puisqu’Unreal inverse les axes Y et Z) est comme dans Unity : compliqué. Vous pouvez trier selon un axe, Settings, rendering, transulancy sort policy : trier selon l’axe (y -1.0), mais le y déplace aussi la physique (j’y reviendrai plus tard). Ou/et vous pouvez gérer ça via Actor (alias GameObject) / Rendering / Translucency Sort Priority.
• Pas de propriété flip (ajoutée récemment par Unity).
• Pour avoir une animation de sprite, créez un Flipbook. L’animation sera jouée directement dans la Scène et dans le Content Browser.
• Pas d’équivalent à Mecanim.

Système physique Sur Unreal, la physique est gérée un peu différemment que sur Unity. Sur Unity, vous aviez une Entité, avec un composant SpriteRenderer et vous pouviez ajouter un ou plusieurs composants Rigidbody2D pour définir la collision sur ces composants. Sur Unreal, la collision peut être définie directement dans l’éditeur de source du Sprite. Donc si vous déplacez la profondeur du Sprite (via l’axe Y), ça changera aussi la gestion des collisions puisqu’on utilise un moteur physique 3D !

D’un point de vue API, Unreal expose une méthode Tick similaire à Update dans Unity, mais il n’y a pas de FixedUpdate. À la place, vous pouvez activer le physics-sub-stepping.

À la rencontre des Blueprints On y est… la vraie bête d’Unreal. Unity propose une API C#, Unreal une API C++. Cependant, si vous creusez dans l’univers d’Unreal, vous découvrirez une autre façon très populaire d’ajouter du scripting à votre jeu : les Blueprints. Les Blueprints sont une interface de scripting visuel intégrée à Unreal. Avec des moteurs comme Unity ou Unreal, ce ne sont pas seulement les développeurs qui les utilisent mais aussi les gameplay designers, les level designers, les sound designers, etc. Et avoir des outils comme ceux qu’on a créés dans A Blind Legend est vraiment important pour toute l’équipe. Comme c’était la première fois que j’utilisais un outil de scripting visuel, j’étais enthousiaste. Je pensais que ce serait plutôt simple… quelle naïveté ! C’est vraiment une autre façon de penser. J’ai passé des heures à faire des choses simples que j’aurais réglées en quelques minutes même en C++ ! En fait, je comprends que ce soit plus lisible que du code pour un non-développeur, mais écrire ses propres blueprints n’est pas une mince affaire.

Alors on oublie les Blueprints et on passe au tout C++ ? Eh bien, ce n’est pas si simple. Les Prefabs d’Unity ne sont que des GameObjects avec des Components marqués comme Prefabs pour l’instanciation au runtime, etc. Sur Unreal, un Prefab est une classe Blueprint. Donc vous créez un Actor (alias un GameObject), vous ajoutez des composants, et enfin vous ajoutez une classe Blueprint. Les Prefabs d’Unity souffrent d’un gros manque : pas de support des prefabs imbriqués ! Sur Unreal, une classe Blueprint peut hériter d’une autre, et c’est tellement puissant ! Et en plus, les classes Blueprint peuvent hériter de classes C++ ! Donc vous ferez votre partie de programmation solide en C++ et vous exposerez des scripts simples via Blueprint pour que votre équipe puisse les gérer. On sent qu’Unreal est plus adapté à une hiérarchie de jeu complexe qu’Unity.

Input Concernant les Input, Unreal a une gestion similaire à Unity pour le mapping des axes, claviers, etc. Ils peuvent être lus directement via Blueprint.

Versioning Bon, jusqu’ici Unreal avait pas mal de points positifs, non ? Mais cette dernière partie… aïe ! Alors préparez-vous pour une mauvaise nouvelle : il n’y a aucun moyen (dites-moi que j’ai tort) de sauvegarder les fichiers d’Unreal en texte brut. Pas de support YAML comme dans Unity, tout est sauvegardé en fichier binaire (sauf les fichiers C++, évidemment). Donc pas de versioning facile sur les Blueprints. Quel dommage ! En fait, vous ne pouvez pas utiliser d’outils externes pour gérer le diffing. Vous devez utiliser le contrôle de source intégré à Unreal. Vous devrez peut-être reconfigurer votre repository pour pouvoir utiliser le contrôle de source intégré.

Voilà donc pour ce premier article sur Unreal ! Peut-être que ça évoluera avec d’autres articles ;)

Utiliser Unreal pour un jeu purement 2D, ça paraît un peu irréel (vous avez saisi la blague), mais finalement ce n’est pas si éloigné de faire un jeu 2D avec Unity. À côté de ces grands noms, il y a des petits qui font un travail génial pour afficher des pixels à l’écran : Starling 2 beta est sorti, et Nez, un petit nouveau basé sur MonoGame.