OpenFL 4.0

Posté par (page perso) . Édité par tankey, Benoît Sibaud, palm123, Xavier Claude et NeoX. Modéré par ZeroHeure. Licence CC by-sa
31
13
juil.
2016
Technologie

OpenFL est une API graphique libre et gratuite, permettant de créer des jeux et des applications cross-platform. Il y a quelques jours, une nouvelle version majeure de OpenFL, la version 4, a été publiée. Cette dépêche profite de l'occasion pour faire un tour des possibilités offertes par cette API.

OpenFL logo

OpenFL est donc capable de compiler nativement pour les plateformes Linux, Windows, MacOS, iOS, Android, Raspberry PI, BlackBerryOS, Firefox OS, HTML5, Tizen, Wii U, PS3, PS Vita, PS4, et Xbox One, tout en profitant de l'accélération GPU via OpenGL, OpenGL ES, WebGL, Stage3D, et un moteur de rendu spécifique pour les consoles de jeu.

Parce qu’il a un historique important dans le développement de jeux vidéo et parce qu'il est naturellement orienté multi-plateforme, OpenFL utilise Haxe comme langage de programmation.

OpenFL

Architecture

OpenFL est une API comme OpenGL l'est aussi. Elle repose essentiellement sur l'API Flash et s'oriente naturellement vers la production de contenus interactifs, d’applications, de jeux, d’interfaces 2D et d'animations.

OpenFL Architecture

Elle s'appuie sur la bibliothèque Lime qui se charge de toute la mécanique de compilation croisée. On va y revenir.

Moteur de jeu

C'est clairement dans le jeu vidéo que cette API se développe le plus.
Le célèbre jeu “Papers, Please”, gagnant d’un Bafta et fort de quelques 30 récompenses utilise OpenFL. Electronic Arts, le géant du jeu vidéo, a récemment substitué OpenFL à Scaleform pour produire son dernier jeu vidéo mobile, (John Madden NFL). Une grande majorité des essais au Ludum Dare exploite cette API. OpenFL a par ailleurs concentré ses efforts pour ouvrir la porte du développement sur consoles de jeu.

HaxeFlixel, construit par-dessus OpenFL, est un framework de développement de jeux vidéo 2D populaire.
Personnellement j'attends avec impatience la sortie de Defender's Quest 2 et Yummy Circus.

Stencyl va encore plus loin en offrant tout un environnement de développement en plus d'un très bon moteur de jeux.
Stencyl Editor

Interfaces

Dans le domaine des IHM, on retrouve HaxeUI qui propose une solution efficace pour construire des interfaces. Il est à noter que la V2 devrait bientôt sortir.

Ian Harrigan, le principal développeur, a présenté lors du dernier WWX cette nouvelle version. En attendant la vidéo, vous pouvez retrouver ses interviews et ses supports de présentation.

Lime

Lime est la bibliothèque gratuite et open-source, qui sert de fondation à OpenFL et à d'autres projets.
Elle s'occupe de la partie multi-platforme. Elle expose les contextes Canvas, DOM, GL (WebGL, OpenGL, OpenGLES) en fonction des plateformes et unifie les I/O pour OpenFL (clavier, souris, écrans, joystick…) via SDL. Lime offre également une API audio mais expose OpenAL pour ceux qui veulent quelque chose de plus bas niveau. Elle supporte :

  • Windowing
  • Input
  • Events
  • Audio
  • Render contexts
  • Network access
  • Assets

Heaps

Heaps est un framework de développement de jeu 3D qui repose directement sur Lime.

Evoland et NorthGard sont de très bons exemples de ce que peut faire Heaps.

Screenshot NorthGard

Pour bien commencer

Le plus simple reste d'utiliser Haxe Develop. Intellij Idea, Sublime Text, ou VsCode supportent aussi très bien les développements Haxe et OpenFL. NdM : Ou vim ou emacs ou Ed.

Ensuite le site de OpenFL propose une série de tutoriels plutôt efficaces. Celui sur le jeu pong est pas mal du tout.

Vous pouvez également lire ce très bon billet «Flash is Dead, Long Live OpenFL» de Lars Doucet sur OpenFL et tout son écosystème

En bref, OpenFL est une très belle technologie à découvrir ou redécouvrir.

  • # Godot

    Posté par (page perso) . Évalué à 5.

    Salut,

    je ne m'intéresse pas (plus) trop au développement de jeux pour être honnête, mais on entend beaucoup parler de Godot (y compris ici).

    Du coup je me pose la question par curiosité : est-ce que les 2 plateformes sont comparables, et si oui quelles seraient les raisons de choisir l'une plutôt que l'autre ? J'avais cru comprendre que Godot avec un langage plutôt proche de Python ce qui n'a pas l'air d'être le cas de Haxe (ce qui n'est pas un bien ou un mal, juste une observation).

    C'est quand même intéressant de voir ces outils qui facilitent l'écriture multi-plateformes, même en dehors du jeu vidéo.

    • [^] # Re: Godot

      Posté par (page perso) . Évalué à 10. Dernière modification le 13/07/16 à 16:43.

      En attendant Godot, on a OpenFL.

  • # "Parenté" entre OpenFL et Flash ?

    Posté par . Évalué à 5. Dernière modification le 13/07/16 à 12:57.

    Je ne suis pas sûr d'avoir bien compris alors je pose la question :

    • OpenFL est une implémentation open source de Flash ?
    • OpenFL est une API permettant d'appeler Flash ?

    Avec une telle API les développeurs n'ont plus vraiment d'excuse pour ne pas porter leurs jeux sur Linux .

    • [^] # Re: "Parenté" entre OpenFL et Flash ?

      Posté par . Évalué à 1. Dernière modification le 13/07/16 à 15:29.

      Avec une telle API les développeurs n'ont plus vraiment d'excuse pour ne pas porter leurs jeux sur Linux .

      Les développeurs n'utilisent plus d'excuses depuis bien longtemps, le nombre de jeux portés ou natifs sous linux est grandissant, on est pas loin du ratio 1:1 si on exclue les "gras" studios tel que Ubisoft, Dice, EA, Blizzard/Activision qui eux s'en foutent de linux pour le moment mais Valve, Codemasters et pléthore de studio indés côtés sont là.
      Et puis, il me semble que PlayOnLinux (Wine) est une possibilité de dernier recourt.

      Les devs ont de quoi faire avec Source, Unity 3D, Unreal Engine, Game Maker. Je cite les technos proprios là et si on rajoute les technos libres multi-plateformes par essence, bien… on ne peut être qu'enthousiaste aux JV sous linux, enfin, je l'ai un peu mauvaise vu que je n'ai plus le temps de jouer. :/

      Néanmoins, si il y avait un manque, je le vois plus du côté d'AMD/ATI, assez en retard face à nVIDIA et Intel en terme de pilotes stables et performant sous Linux.

      Bref, il est loin le temps où la seule solution à proposer était Ogre3D sans qu'on ait jamais vu une production avec.

    • [^] # Re: "Parenté" entre OpenFL et Flash ?

      Posté par . Évalué à 3.

      OpenFL est une implémentation open source de Flash ?

      Non parce que le moteur d'exécution de Flash lui-même n'est pas ré-implémenté.

      OpenFL est une API permettant d'appeler Flash ?

      OpenFL est une API pour Haxe qui ressemble à celle de Flash/ActionScript. Haxe et son écosystème permettent ensuite de compiler vers Flash, HTML5, des exécutables natifs…

      Avec une telle API les développeurs n'ont plus vraiment d'excuse pour ne pas porter leurs jeux sur Linux .

      Si tu veux parler des jeux existants pour Flash, et que ceux-ci ont été écrits en ActionScript (et pas en Haxe), il faudra tout de même les convertir au préalable (d'un point de vue du langage, de ActionScript vers Haxe, d'un point de vue de l'API de celle de Flash vers celle de OpenFL et d'un point de vue des ressources graphiques de SWF vers autre chose).

  • # Orthographe et sens

    Posté par . Évalué à 8.

    […] a récemment substitué Scaleform pour OpenFL pour produire son dernier jeu vidéo mobile (John Madden) Une grand majorité […]

    […] a récemment substitué OpenFL à Scaleform pour produire son dernier jeu vidéo mobile, John Madden. Une grande majorité […]

    • Substituer X à Y, c'est mettre X à la place de Y.
      Ce prince [Caligula] faisait transporter de la Grèce en Italie les plus parfaites statues des dieux, auxquelles on coupait la tête pour y substituer la sienne, [Diderot, Essai sur les règnes de Claude et de Néron. I, 5] in Littré, substituer.
    • Il manque un point à la fin de la phrase.
    • Le John Madden entre parenthèses, j'ai supposé que c'était le nom du jeu, mais sans certitude car la syntaxe indiquait le contraire. Une virgule suffit à l'apposer, et des guillemets ou l'italique permettent de signaler que l'on cite un titre. A contrario, les parenthèses sous-entendent un élément extérieur, par exemple la source de l'information.
    • Accessoirement, il manque une virgule dans la phrase précédente, pour le bloc de gagnant à récompenses.

     
    À part ça, la dépêche est excellente : une présentation succincte mais claire, avec un peu de contexte pratique et historique, et des pointeurs pour aller au-delà. Merci !

  • # et pourquoi pas ?

    Posté par (page perso) . Évalué à 2.

    Ces frameworks multi-cibles (Web et Mobile) me font réellement saliver, moi qui n'ait aucune expérience de développement d'application WebApp/Android/iPhone.
    D'autant plus que maintenant il en sort des 'plus ou moins' gratuits : celui-ci, monkey-X, unity3D.

    Mais je m'interroge sur leur viabilité pour le développement ? est-ce qu'il ne faut quand même pas avoir de solide bases sur ce qu'il se passe derrière (connaître le Java, Cocoa, …).
    Et si l'on a ces bases, ces développements sont-ils assez souples pour intégrer du code natif pour combler des "trous" ?

    Est-ce que l'on peu faire du RAD (transition du code vers les Widgets 'natifs' proposés pour développer des IHMs simples.
    Où alors est-ce cantonné à du développement de jeu, avec éventuellement une API graphique à part comme Unity ?

    Quelqu'un peut-il me répondre en ce qui concerne ce framework ? Merci.

    • [^] # Re: et pourquoi pas ?

      Posté par (page perso) . Évalué à 2.

      Je ne sais pas pour les autres mais dans l'ensemble il est important de comprendre ce qu'il se passe derrière. Un bon développeur ne code pas à l'aveugle, et croire que ce genre d'outils peut vous abstenir de ce travail, est une douce illusion.
      Cependant, OpenFL fait du bon boulot et ne nous oblige pas à mettre les mains dedans, enfin pas au début.
      Il est très facile d'ajouter à votre projet OpenFL des extensions natives en fonction des plateforme ciblée.
      http://blog.zame-dev.org/openfl-extension-in-10-steps/

      Sur un de nos projets on a fait le contraire. On a utilisé NME, l'API à l'origine d'OpenFL, pour faire un widget natif de notre module de dessin. Les développeurs codent leurs applications mobiles en Java, Swift, ou ce qu'ils veulent, et intègrent notre widget comme si de rien n'était. Nous n'avons qu'on code à maintenir pour faire évoluer notre module pour toutes les plateformes.

      J’espère avoir répondu à vos questions.

      • [^] # Re: et pourquoi pas ?

        Posté par (page perso) . Évalué à 0.

        Cependant, OpenFL fait du bon boulot et ne nous oblige pas à mettre les mains dedans, enfin pas au début.

        Ca reste satisfaisant comme réponse.
        Merci pour ce retour d'expérience.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.