Homemade Pixels

Des pixels frais qui sortent du four le blog de MrHelmut.

XNA est mort, vive MonoGame

Depuis quelques jours, on voit fleurir des news par ici par là qui annoncent l’arrêt d’XNA par Microsoft et maladroitement interprété comme étant la fin du service Xbox Live Indie Games. Il y a une légère confusion dans ces annonces qui font suite à un mail de Microsoft à ses MVP. Mais si il y a une chose qui est sur, c’est que XNA, c’est bel et bien terminé. Sauf qu’on le savait depuis quelques années maintenant. Retour sur l’avènement d’un SDK, et pourquoi sa chute ne changera rien au quotidien de bien des développeurs.

XNA

xnaPour vous la faire courte, XNA est un framework de développement de Microsoft et qui permet de faire des jeux cross-platfrom Windows/Xbox360/Windows Phone 7. C’est un framework de haut niveau basé sur Direct3D, très bien conçu, facile à prendre en main et robuste. Il est assez vite devenu une référence dans son domaine.

Fin 2008, avec l’arrivée d’XNA 3, Microsoft ouvre le service Xbox Live Indie Games (XBLIG) qui permet à ceux qui se sont acquittés d’une licence ($100/an) de publier leurs jeux sur Xbox360 auprès du grand public, et de pouvoir les vendre sans autre intermédiaire (i.e. éditeur) ni l’achat d’un SDK. Ce qui aura pour effet de pérenniser XNA, devenu alors très robuste et mis en avant par un market. A savoir que ce service est presque entièrement tenu et régulé par les gens qui ont une licence développeur. En fait, lorsque vous voulez publier un jeu sur ce service, il n’y a aucune certification de la part de Microsoft, ce sont les autres développeurs comme vous qui jugent la qualité technique de votre jeu et donnent leur accord. Plus vous évaluez d’autres jeux, plus votre avis a de poids dans la décision de sortir un jeu ou non (via un système de karma). C’est ce qu’on appelle un système de peer reviewing (revue par vos paires). Le monde scientifique marche exactement de la même façon. Bien entendu il y a des biais dans un tel système, mais là n’est pas la question. L’avantage du système, c’est qu’il a créé une grosse communauté de développeurs indépendants très soudées. Les tuyaux que l’on pouvait avoir sur le forum d’XNA étaient tous très pertinents et il y avait toujours quelqu’un pour vous aider. Le service a bien tourné, il y a eu pas mal de perles, voir des success story qui ont atterries sur Xbox Live Arcade (The Dishwasher, ou Dust: An Elysian Tale, pour ne citer qu’eux).

Mais ce qu’il faut en retenir, c’est un framework robuste, bien documenté et a priori pérennisé par un service commercial. La pérennité a encore été accentuée puisque Microsoft était allé jusqu’à fournir XNA dans le SDK Windows Phone 7 en tant qu’API 3D principale (surement dans le but de faciliter les portages XBLA vers WP7).

Les prémices d’une chute

De par son ouverture, le service des XBLIG laissait un peu tout et n’importe quoi passer. Des milliers de jeux ont débarqué, allant d’excellents à très douteux. Il est vite devenu difficile de se faire une place au soleil et seule une poignée de studios ont réussi à tirer leur épingle du jeu. Il est aujourd’hui difficile de se faire plus de $100 et il n’y guère plus que les clones de Minecraft qui trustent le panneaux du TOP.

Cet engorgement du market a commencé à effriter la communauté (sans parler des problèmes de placement des XBLIG dans le dashboard), avec les studios les plus talentueux qui ont fuit vers d’autres plateformes comme Steam (tels que Zeboyd Games ou même SwingSwing). Changeant souvent de technologie au passage, afin de proposer des jeux cross-platfrom Windows/Mac, ce que XNA ne permet pas.

La communauté a aussi pris un coup avec la chute de ses deux plus gros sites communautaires :

  • Ziggyware, qui a disparu du jour au lendemain suite au passage de l’ouragan Gustav (2008) par Baton-Rouge, la ville de résidence du webmaster.
  • Sgt Conker, qui a été bêtement parké l’année dernière suite à son abandon par son domain holder qui avait perdu toute motivation suite aux détails précédents. J’avais des tutoriels sur ce site.

Un bon bout des meilleures ressources sur XNA a disparu avec ces deux sites.

Après la sortie d’XNA 4, l’équipe en charge du framework est devenue silencieuse. Des gens comme Shawn Hargreaves (le boss de l’équipe, qui a officié sur Extreme-G, les Moto GP, la lib Allegro et monsieur “deferred shading”) qui postait très régulièrement des gemmes sur le fonctionnement d’XNA a subitement arrêté toute publication pour parler d’autres choses (de Direct3D et XAML notamment). Le message était intrinsèque : l’équipe d’XNA a été ré-affectée au sein de Microsoft. On peut aisément supposer qu’ils s’occupent désormais de la partie 3D du SDK Windows Phone 8.

La dernière version majeure d’XNA date de 2010.

Le couperet

Début 2012, premier grand coup d’éclat a véritablement faire vaciller XNA : la décision de Microsoft de retirer XNA du SDK de Windows Phone 8. Tout le monde pensait XNA plus ou moins pérennisé par son introduction dans l’écosystème Windows Phone, mais cette décision était à la fois surprenante et prévisible (avec le silence radio de l’équipe d’XNA).

Second coup d’arrêt peu de temps après, Microsoft retire totalement XNA du SDK de Windows 8, et annonce par la même occasion qu’XNA ne fonctionnera pas dans des applications ModernUI (ex-Metro). Ici, plus aucun doute, XNA était cuit de chez cuit.

Fin Octobre, Microsoft tient sa conférence BUILD, sa grande messe pour développeurs. Une session MonoGame y est tenue et Microsoft encourage à demi-mot à passer à ce nouveau framework.

On en vient aux événements de cette semaine. Microsoft envoi un mail à tous ses Most Valuable Professional (MVP) XNA/DirectX. Le mail en question annonçait l’arrêt de l’attribution du titre MVP dans la catégorie XNA/DirectX en expliquant que XNA n’était plus une technologie supportée et que DirectX n’évoluerait plus (ce qui ne signifie absolument pas que Direct3D n’évoluera plus, ce sont deux choses distinctes). Il s’agit donc d’une semi-annonce, mais qui en tout cas est on ne peut plus officielle.

Il n’y aura pas de nouvelle version d’XNA et le framework ne sera plus inclus dans aucun produit Microsoft à l’avenir. Mais en l’état, XNA peut toujours être utilisé pour faire des jeux Windows, et il n’y a pas de raison que cela cesse de fonctionner du jour au lendemain.

MonoGame, ou pourquoi XNA est encore mieux qu’avant

monogamelogo512x512S’il y a un framework qui commence a vraiment faire parler de lui ces temps ci, c’est bien MonoGame. Il s’agit ni plus ni moins de la ré-écriture open source d’XNA (avec une compatibilité quasi parfaite avec ce dernier). Cerise sur le gâteau, il est cross-platform Windows/Linux/MacOS/iOS/Android/Vita/Ouya/RaspberryPI/Chrome/WindowsPhone8. (Ouf !) On perd juste la compatibilité Xbox360 au passage.

Actuellement en version 3.0, MonoGame est déjà plutôt robuste et convertir un jeu XNA est plutôt enfantin. Seul hic, MonoGame n’inclus pas encore de moyen aussi simple qu’XNA d’intégrer son ContentPipeline. Mais cela devrait arriver d’ici 2-3 mois avec MonoGame 3.5 (ou dès maintenant en nightly) qui n’aura strictement plus rien à envier à XNA. Le projet n’est pas encore aussi stable qu’XNA mais il est très entretenu et proposera à terme bien plus de choses qu’XNA en terme d’API et de facilités.

Bon nombre de développeurs ont déjà pris le pas, comme les auteurs de Bastion qui ont porté leur jeu XBLA sur Chrome et iOS en deux temps trois mouvements. Même Microsoft l’utilise, en atteste la sortie de Skulls of the Shogun sur le Windows Store de Windows 8.

Les Xbox Live Indie Games dans tout ça ?

L’arrêt d’XNA signifie déjà une chose : la prochaine console de Microsoft ne le supportera pas. On peut donc supposer à juste titre que les Xbox Live Indie Games n’existeront plus dans la prochaine Xbox. Si ils existeront encore, ce sera via un autre SDK, mais étant donné les difficultés actuelles des développeurs à contacter Microsoft pour se faire payer les ventes de jeux XBLIG, mon petit doigt me dit qu’il n’y a déjà plus personne au bout du fil. Et donc un arrêt probable du service à court terme, peut être même d’ici l’E3.

En attendant une hypothétique annonce, l’arrêt d’XNA annoncé par Microsoft ne signifie pas du tout l’arrêt des XBLIG en soi. Le service continu, et on peut toujours développer et soumettre des jeux XNA. Jusqu’à nouvel ordre.

Pour le reste, la communauté XNA est actuellement en émoi suite cette annonce, bien que tout le monde s’y attendait.

Et en me relisant, je me rend compte que mon billet ressemble à celui de Valryon. Loin de moi l’idée de faire pareil, il me semblait juste nécessaire de faire la différence entre XNA et XBLIG, ainsi qu’entre DirectX et Direct3D. La presse généraliste faisant souvent l’amalgame.

15 commentaires pour “XNA est mort, vive MonoGame”

  1. Aristo dit :

    Curieux qu’ils abandonnent un marché (même petit) au profit d’un concurrent multi-platformes.

  2. Valryon dit :

    On a structuré pareil notre billet, mais le tiens est bien plus clair, approfondi et renseigné. On reconnaît le chercheur ! :)

    MonoGame est vraiment très prometteur, et nombre de développeurs aide à la progression du framework. C’est une très belle relève.

    L’annonce de l’arrêt d’XNA a aussi donné un coup de fouet à la communauté qui s’est retrouvée sur Twitter avec #becauseofXNA. C’est plutôt impressionnant de voir que ce framework a “changé des vies” : pas mal de gens font ce qu’ils font maintenant grâce à lui. Et il y a même un peu d’humanitaire, le créateur de Dust : an Elysian Tail a gagné suffisamment d’argent pour aider la réparation de plusieurs églises.

  3. LeGreg dit :

    Pour ceux qui suivent Microsoft depuis longtemps, savent que pour un truc pérenne il ne faut pas se reposer sur les composants à la mode issus de MS.. Win32 et DirectX sont à peu près stables, même si ça sent mauvais du côté de Metro UI et WinRT.

  4. El_Porico dit :

    Je trouve ça vraiment superbe –pour le PC.

    Le problème pour les plateformes mobiles c’est qu’il n’y a pas de solution native. Il faut une license Mono for Android / Monotouch pour iOS qui coute au bas mot $999.

    Par contre j’ai bien envier de tester leur version Windows Phone 8, car je pense qu’il sera facile de porter mon jeu (framework Java libgdx pour Android: les concepts sont les même, à base de spritebatch et de lib de bases pour les maths)

  5. divide dit :

    Je m’étais renseigné sur les framework mobile il y a peu, et il existe aussi d’autres alternatives excellentes qui offrent des performances natives pour un moindre coût:

    -Marmalade, pour $499 tu as iOS, Android, BlackBerry, WP8 (et pour $1499 iOS, Android, BlackBerry, WP8, Mac OSX, Windows Desktop, Connected TV Platforms). C’est un framework extrêmement poussé et complet (tout s’installe en un seul package, simulateur inclus).
    -Appcelerator Titanium, gratuit, iOS, Android, Windows and BlackBerry, hybrid and HTML5. Le framework repose sur le concept d’applis javascript transformés en code natif.
    -Qt 5.1 qui sort cet été, gratuit, Win/Mac/Linux/iOS/Android/BlackBerry.

  6. neFAST dit :

    -Qt 5.1 qui sort cet été, gratuit, Win/Mac/Linux/iOS/Android/BlackBerry
    Vraiment ils vont sortir iOS/Android/BlackBerry en release cet été ? Ca me parait bien rapide

  7. divide dit :

    En fait la version BlackBerry est déjà dispo avec Qt 5.0 il me semble, la version Android est un merge dans la branche principale d’un projet open-source (Necessitas) presque bouclé et la version iOS est en bon chemin aussi.
    On peut voir des protos fonctionnels des versions Android et iOS dans cette vidéo de Novembre 2012.

  8. MrHelmut dit :

    A noter que MonoGame sur iOS/Android compile le C# en natif (via MonoTouch/MonoAndroid, produits hélas payants et obligatoires comme vous l’avez souligné), mais il y a encore une indirection pour les appels graphiques (à cause d’OpenTK).

    Après, je ne m’y connais pas plus que ca dans les alternatives, en dehors de Marmalade (si on exclu les framework pur web), qui effectivement est sympa.

  9. Dyblast dit :

    Qt sur iOS semble mal barré (du moins pour une partie des fonctionnalités) vu qu’on ne peux pas utiliser un autre moteur JS que celui de Apple…
    Pour la version Android, ils ont mis un paquet de gens sur l’affaire (je dialogue avec une personne qui travail sur le projet). Il y a des grandes chances que effectivement cela soit pour bientôt.

  10. divide dit :

    Dyblast a dit :
    Qt sur iOS semble mal barré (du moins pour une partie des fonctionnalités) vu qu’on ne peux pas utiliser un autre moteur JS que celui de Apple…

    cad ? Je comprend pas trop le rapport avec JS, Qt étant un framework essentiellement C++ ?
    D’autre part Marmalade propose bien un framework C++ pour iOS sans que ca pose pb, et Appcelerator embarque son propre interpreteur/compilateur JS il me semble.

  11. Gui13 dit :

    QT5 repose énormément sur son language descriptif QML, qui s’appuie lui-même sur JavaScript pour tourner.
    En interne, ils sont passés à V8, le moteur JS de Google Chrome.

    Or Apple ne supporte que JavaScriptCore, un moteur JavaScript intégré à Webkit. Du coup c’est pas l’idéal pour QT5.

    Par contre, y a un truc qui me chiffonne: QT4 utilise/utilisait JavaScriptCore pour le QML, il n’y a que sur QT5 qu’ils sont passés à V8. J’imagine que le vieux code est toujours là? Ou au moins qu’ils ont abstrait le moteur JS assez bien pour repasser sur JSC? Je trouve rien sur le net.

  12. neFAST dit :

    Dîtes Qt5.1 sur iOS et android, j’espère qu’il faudra pas passer par QtQuick et leur merde en qml, si ?

  13. divide dit :

    J’imagine que QML n’est pas une obligation et qu’on pourra utiliser les widgets a l’ancienne (auquel cas osef de JS).
    Ceci dit dans la tech video on voit Qt iOS avec une interface dynamique QML style donc ils ont du resoudre le pb.

  14. Gui13 dit :

    Ou bien jailbreak le device, pour ramener la libV8.
    Dans tous les cas, neFAST, je suis pas d’accord: leur “merde QML” est 10 fois plus efficace pour avoir une UI en 2 temps 3 mouvements. D’autant plus que tu peux ramener les composants critiques en perf (remplissage de modèles, traitements lourds) dans un componsant Qt C++.
    L’adoption de V8, avec son JIT très (très) efficace, rendra ce genre de chose encore plus rarement nécessaire.

  15. Dyblast dit :

    Effectivement et cela permet une bonne séparation du code, tout ce qui est lié a l’UI tu le fait en QML (images, composants, effets, …) et tout ce qui est traitement en C++.

Laisser un commentaire

Vous devez être connecté avec votre compte Wefrag pour publier un commentaire.