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 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.
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.
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.
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.
Aller plus loin
- Le site officiel (945 clics)
- Le site officiel de Haxe (208 clics)
- La dépeche sur la sortie de Haxe 3.2.0 (156 clics)
- Les sources (94 clics)
- Le billet de Lars Doucet (110 clics)
# Godot
Posté par Goffi (site web personnel, Mastodon) . É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 NumOpen . Évalué à 10. Dernière modification le 13 juillet 2016 à 16:43.
En attendant Godot, on a OpenFL.
# "Parenté" entre OpenFL et Flash ?
Posté par Eiffel . Évalué à 5. Dernière modification le 13 juillet 2016 à 12:57.
Je ne suis pas sûr d'avoir bien compris alors je pose la question :
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 Le Gab . Évalué à 1. Dernière modification le 13 juillet 2016 à 15:29.
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 memz . Évalué à 3.
Non parce que le moteur d'exécution de Flash lui-même n'est pas ré-implémenté.
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…
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).
[^] # Re: "Parenté" entre OpenFL et Flash ?
Posté par memz . Évalué à 1.
À noter que OpenFl propose une gestion des SWF:
http://www.openfl.org/learn/tutorials/using-swf-assets/
# Orthographe et sens
Posté par rogo . Évalué à 8.
[…] a récemment substitué OpenFL à Scaleform pour produire son dernier jeu vidéo mobile, John Madden. Une grande majorité […]
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.
À 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 !
[^] # Re: Orthographe et sens
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Orthographe et sens
Posté par mrlem (site web personnel) . Évalué à 1.
Il n'y aurait pas une petite inversion ?
[^] # Re: Orthographe et sens
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Orthographe et sens
Posté par nado . Évalué à 0.
Le plus simple reste d'utiliser Haxe Develop. Intellij Idea, Sublime Text, ou VsCode qui supportent aussi très bien les développements Haxe et OpenFL. NdM : Ou vim ou emacs ou Ed.
Sinon ça fait un peu bizarre.
# et pourquoi pas ?
Posté par Selso (site web personnel) . É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 David Mouton (site web personnel) . É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 Selso (site web personnel) . Évalué à 0.
Ca reste satisfaisant comme réponse.
Merci pour ce retour d'expérience.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.