Discussion :

[LittleWhite]

XNA est-il mort ? Doit-on encore s'intéresser à la technologie de Microsoft pour faire des jeux ?

Présentation

En tant que développeur de jeux vidéo, vous avez sûrement entendu parler de XNA. Peut-être même que vous vous y êtes intéressé et que vous avez développé des programmes ou des jeux avec.
Pour rappel, XNA est une série d'outils proposée par Microsoft pour faciliter le développement de jeux pour les plateformes Windows, Zune, Windows Phone 7 et même la Xbox 360. Pour cela, XNA repose sur le langage C#, la bibliothèque de jeux DirectX, l'éditeur Visual Studio, le débogueur GPU PIX, l'outil audio XACT. Ce framework a été une des premières opportunités offerte aux développeurs indépendants de publier des jeux sur une console (la Xbox 360) et d'avoir une visibilité augmentée à travers le Xbox Live.
Le public visé par cet ensemble d'outils sont les étudiants, les passionnés et les développeurs indépendants. Afin de bénéficier de la publication sur le Xbox Live Marketplace, il est nécessaire d'avoir un compte premium vendu au prix de 99 $ par an.
Vous pouvez découvrir une présentation approfondie (analyse de l'architecture, description technique...) dans cet article.


Historique

La toute première version de XNA (appelée XNA Game Studio Express) a été publiée le 11 décembre 2006. Durant l'année 2007, une seconde version (XNA Game Studio Express 1.0 Refresh) est apparue, proposant une mise à jour de la version précédemment nommée. Ensuite, quatre autres versions ont été distribuées, toutes nommées XNA Game Studio (2.0, 3.0, 3.1, 4.0). La dernière version (4.0) a été publiée le 9 mars 2010.
Pour information, la version 3.0 apportait le support de Zune et de la communauté Xbox Live, le C# 3.0, LINQ et la plupart des versions de Visual Studio 2008. La version 3.1 rajoutait le support du playback vidéo, une nouvelle version de la bibliothèque audio et le support des avatars Xbox 360. Quant à la dernière version, elle apportait le support de Windows Phone 7.5 et de Visual Basic.

Avec cette version estampillée 4.0, les MVP (Most Valuable Professionals) ont été avertis que le support s'arrêterait courant avril 2014. Aucune autre version du framework n'est prévue et Microsoft ne travaille plus du tout dessus, comme il est possible de l'apprendre dans cette actualité. De plus, lors de la sortie de la quatrième version, des utilisateurs étaient confus par le rapprochement du framework avec le SDK de Windows Phone et à l'époque déjà, certains présageaient la mort du framework.


Les jeux développés avec XNA

De nombreux développeurs ont utilisé cette technologie pour publier leurs jeux, que ce soit sur Xbox 360 ou sur PC. Nous pouvons citer Terraria, Fez, Escape Goat, Dust : An Elysian Tail.... Il serait bien dommage d'oublier Chibis Bomba, un jeu présenté dans nos pages.


Les alternatives

Comme vous l'avez compris, Microsoft ne compte plus faire de mise à jour. Le support de Windows 8, ou des nouvelles versions de Visual Studio ne sera jamais réalisé. Pourtant, la technologie n'est pas morte. Cela est possible grâce au projet open source MonoGame. MonoGame est une implémentation libre de la bibliothèque XNA 4. La deuxième bonne nouvelle est que l'équipe ne se limite pas au support des plateformes Microsoft, car il vous sera aussi possible de cibler Mac OS, Linux, Android, PlayStation Mobile, OUYA ainsi que Windows 8 et Windows Phone 8.
Le projet est toujours en développement actif et la version 3.2 a été publiée le 7 avril 2014. De nombreux projets professionnels l'utilisent déjà comme Bastion ou encore Fez.
Il faut aussi noter que Microsoft utilise MonoGame pour supporter Windows 8 dans leur propre projet : Kodu.

Si vous cherchez à tout prix à installer XNA 4 sur Visual Studio 2012 ou 2013, vous pouvez utiliser cet outil qui se chargera d'activer le framework dans les éditeurs de Microsoft.


Conclusion

Lors de sa sortie, le framework avait donné une opportunité très intéressante pour les étudiants qui souhaitaient s'insérer facilement dans le monde du développement de jeux vidéo, notamment grâce à une bibliothèque simplifiée et l'utilisation du langage C#, mais aussi pour les développeurs indépendants souhaitant cibler la console de jeux de Microsoft.
Malheureusement, Microsoft abandonne finalement cette technologie, possiblement car le marché est devenu bien plus compétitif avec des solutions comme Unity. Toutefois, grâce au projet Monogame, les studios reposant sur XNA peuvent continuer leurs travaux et même s'offrir un support de plateforme étendu.


Votre opinion

Avez-vous essayé d'utiliser XNA ? Qu'en pensez-vous ? Quel est votre avis sur MonoGame ?
Pensez-vous que XNA/MonoGame est une technologie obsolète ? Pourquoi ?
Conseilleriez-vous aux nouveaux développeurs de partir sur d'autres solutions ? Lesquelles ?


Voir aussi

Guide de migration XNA vers MonoGame en français
Les tutoriels XNA/MonoGame de Developpez.com

[jean_kevin_musclor]

XNA c'est surtout fait pour initier les débutants à la programmation de jeux vidéo, et pour prototyper des moteurs avant de les porter en c++, c'est pas vraiment pensé pour faire un produit commercial.

Pour faire du jeu commercialisable en c# on utilise plutôt unity.

[jean_kevin_musclor]

J'aurais peut-être pas du faire de comparaison avec unity car ça n'a vraiment rien à voir avec xna (le seul point commun c'est que parmi leurs langages utilisés il y'en a deux avec la même syntaxe, mais le c# pour ms framework et le c# pour mono c'est pas du tout la même mv dessous). Microsoft ça n'est pas leur boulot de faire des moteurs de jeux...

XNA n'est pas un moteur c'est juste l'actuel wrapper officiel de directx pour débuter et prototyper des jeux windows en c#/vb#. C'est juste la continuation du wrapper directx pour VB, qui lui même était la continuation du wrapper VGA pour QB. Ils lui ont juste donné un autre nom que "directx numéro x pour c#" car xna a l'avantage de faire abstraction de la version.

Alors bien sûr il y'a toujours eu des jeux à petit budget réalisés avec ces wrapper pour basic/c# mais ça a jamais été une solution géniale.

[edit] Je me demande si les développeurs de casual n'ont pas été embrouillés par tout ce bazar de syntaxes. Unity c'est la continuation de middlewares qui sont progressivement passés de syntaxes basic-like à des syntaxes java-like. Peut-être que les habitués du basic se sont du coup sentis plus à l'aise sur xna que unity ...

[edit2] Il faut dire aussi que les wrappers directx pour basic/c# c'est traître, parce que c'est des langage haut niveau lents, mais ça ne sert qu'à prototyper de l'algo bas niveau (et oui il faut tout coder soi-même) destinés à être porté en suite en c++. difficile d'obtenir des performances intéressantes en se contentant de xna donc, à moins de faire du gameplay 2d avec des calculs élémentaires.
ça n'a donc strictement rien à voir avec unity qui lui a les librairies physx et umbra qui s'occupent de tous les algo bas niveau et le script c# est reservé à la fonction du script d'un engine, donc au game design.

[Nathanael Marchand]

Il faut dire aussi que les wrappers directx pour basic/c# c'est traître, parce que c'est des langage haut niveau lents, mais ça ne sert qu'à prototyper de l'algo bas niveau (et oui il faut tout coder soi-même) destinés à être porté en suite en c++. difficile d'obtenir des performances intéressantes en se contentant de xna donc, à moins de faire du gameplay 2d avec des calculs élémentaires.

A moins de vraiment utiliser des trucs du genre CUDA, on a des très bonnes perfs en C# (oui oui, même équivalentes à ce qui pourrait se faire en C++). On a même les instructions vectorielles et la compilation native

[jean_kevin_musclor]

J'ai déjà essayé... les instructions vectorielles natives ne sont pas suffisantes pour égaler les perfs du c++.

Les jeux 3d requièrent des algorithmes complexes comme le parcours de graph, la detection de collisions, le clipping, les déformations de mailles, etc... chaque objet est constemment en train de faire des tests sur une tonne d'autres objets.

Par exemple t'as tes 50 corps rigides mobiles actifs qui testent en permanence une cinquantaine de polygones et/ou volumes chacun et le test est fait en moyenne 5 fois pour la précision (on arrive déjà à un ordre de grandeur de type 10000 tests avec un algo compliqué à chaque fois...), le frustum camera qui clippe une trentaine de portails ou occluders, et puis tous ces objets en plus doivent parcourir des structures compliquées genre octree-bsp-etc, rajoute la partie du décor qui est partiellement mise à jour (explosions ou building).
Bref c'est vriament des calculs méga-lourdingues. Il est difficile d'obtenir des perf intéressantes avec c#-xna, et même en optimisant comme un malade tu n'arriveras jamais à égaler la vitesse de physx/umbra qui font ça nativement dans unity. j'ai essayé, ça marche pas...

En + xna n'est pas une solution portable donc c'est pas plus prévu que les jeux pros que ne l'était le wrapper dx pour vb ou le vga qb.

C'est fait pour débuter, s'entraîner et prototyper, et ça le fait très bien avec un environnement de prog simplifié. Il faut l'utiliser pour quoi c'est fait.

[I_Pnose]

J’ai testé XNA puis Monogame. J’ai d’ailleurs créés quelques applis Windows 8 grâce à ce dernier (cf. ma signature).

C’est très bien pour de petits projets, mais là où un moteur de jeux (dans la trempe de Unity) permet au développeur de se concentrer véritablement sur son jeu, XNA/Monogame/N’importe quel autre framework va nécessiter beaucoup plus de travail de la part du développeur pour mettre sur pied une base de jeu minimale ; si on veut de la physique on se la code, si on veut des shaders on se farcie du HLSL à la main, si on veut un joli terrain avec LOD dynamique on se le code... Au final on passe plus de temps à développer un moteur de jeu qu’à véritablement développer son jeu.

C’est ce qui fait la force de Unity, UE, Cry Engine et consort, et c’est vers ces solutions qu’il faut s’orienter si on a la volonté de mener à bien un projet de jeu vidéo.

Pour ce qui est des perf de XNA vs Monogame vs C++, j’aime bien ce lien qui date un peu. On voit clairement que XNA peut être 10 fois plus lent que du Directx natif, et que SharpDx (qui est un wrapper DirectX pour .Net utilisé notamment par Monogame pour assurer le pan Windows) s’en sort plutôt bien (en réalité il s'en sort même bien mieux que ce que l'article laisse entrevoir, car pas mal d'opti ont été apportés depuis, et le ratio perf SharpDX/C++ s'approcherait plus des 1.15~1.25 que des 1.5~2.3).

[Mat.M]

J'ai déjà essayé... les instructions vectorielles natives ne sont pas suffisantes pour égaler les perfs du c++.

Dans la prochaine version de Visual Studio, on pourra avoir du code C# transformé en natif.

Quant à Unity c'est sans doute un excellent outil mais sans vouloir relancer tout un débat, je doute qu'on puisse faire un jeu AAA avec.
C'est parfait pour les petites équipes qui ont peu de moyens; les studios un minimum expérimentés préférent construire leur propre middleware.

[Thorna]

XNA ne m'a servi que pour voir s'il était possible de faire un peu de 3D en C#.
Dès les premières rumeurs d'arrêt de XNA, j'ai migré en SharpDX. C'est plus bas niveau mais parfait pour ce dont j'avais besoin.
Puis, dans le cadre de ma grande quête "apprendre un truc nouveau", j'ai testé SharpGL et j'ai maintenant migré vers le langage D et Derelict3.

[jean_kevin_musclor]

Hé au fait on a oublié de répondre au quizz de littlewhite.

Votre opinion

Avez-vous essayé d'utiliser XNA ? Qu'en pensez-vous ? Quel est votre avis sur MonoGame ?

Non. J'ai débuté la 3d avec le basic. Donc j'en pense pas grand chose.

Pensez-vous que XNA/MonoGame est une technologie obsolète ? Pourquoi ?

XNA oui puisque microsoft l'a droppé. Monogame je sais pas trop si l'équipe de développement va suivre.

Conseilleriez-vous aux nouveaux développeurs de partir sur d'autres solutions ? Lesquelles ?

Pour ceux qui veulent produire des jeux vite il y'a les moteurs.

Pour ceux qui veulent apprendre la programmation de moteur 3d avec un langage plus facile que le c++, ou bien faire du prototypage, je conseillerais jogl ou webgl qui sont des solutions plus standard que xna.

[ShadowTzu]

jean_kevin_musclor> "tout le reste" peut également être calculer par le GPU.

[jean_kevin_musclor]

Ouais sauf que la théorie et la pratique ne vivent pas dans la même galaxie et qu'on est sensé répartir la charge sur tous les processeurs de la machine et que le gpu est sensé calculer les choses pour lesquelles le gpu est optimisé. Or des algos de recherche codés en basic je le sens pas trop...

Et pour ceux qui veulent dévier vers le débat "est-il dans l'intérêt d'un développeur de jeu de faire l'impasse sur le langage c++", ça mériterait un topic complet. Je pourrais déballer douze kilomètres d'arguments appuyés par l'expérience pour vous prouver que la réponse est non avec un grand n, mais ça serait hors sujet.

jean_kevin_musclor> "tout le reste" peut également être calculer par le GPU.

J'ai jeté un oeil à ton moteur 3d en basic, je vais pouvoir étoffer ma réponse.

Ton moteur est un moteur d'affichage, ce sont effectivement des "algos" pour lesquels un gpu est optimisé, et comme je disais plus haut je mets des guillemets à "algo" parce que c'est rien que des bêtes boucles for.

Les algorithmes de moteur de jeu ça n'est pas les mêmes, ce sont d'une part des algo indépendants du gpu facile à porter car du calcul pur, d'autre part ce sont des algo récursifs ou itératifs basés sur des structures non-linéaires. Quelques exemples d'algos classiques qu'on retrouve dans la plupart des moteurs de jeu: arbres spatiaux moins obvious que les octree (bsp, bvh, etc), culling récursif basé sur une structure sector/portal, ia basée sur du pathfinder, broad phases de collision des moteurs physiques également basées sur des parcours d'abres (souvent des kd-tree, qu'on construit souvent au loading), etc... il y'a très peu de calculs vectoriels dans ces algos là, juste quelques petits produits scalaires ou en croix, tout le reste c'est de la recherche dans des tableaux (comme de la bdd mais en plus chiant), et, je vois pas trop lintérêt de déléguer ça au gpu à part se compliquer la vie inutilement.

[I_Pnose]

Quant à Unity c'est sans doute un excellent outil mais sans vouloir relancer tout un débat, je doute qu'on puisse faire un jeu AAA avec.
C'est parfait pour les petites équipes qui ont peu de moyens; les studios un minimum expérimentés préférent construire leur propre middleware.

Quand on voit qu’il faut débourser entre 1500 et 4500 euros (si on souhaite cibler iOS et Android) pour Unity Pro, là où Unreal Engine est accessible pour 19 euros/mois, je me demande si Unity est réellement la solution la plus abordable financièrement ^^ (en termes de facilité d’apprentissage je ne dis pas).

VB6 était transformé en natif aussi, ça n'est pas pour ça qu'il égalait la vitesse du c++ ...

VB6 intègre énormément de mécanismes de vérification couteux, mais en mettant un peu les mains dans le cambouis et en optimisant un peu son compilateur on est en mesure d’obtenir des perfs similaires voire supérieures à celles du C++.

Et pour ceux qui veulent dévier vers le débat "est-il dans l'intérêt d'un développeur de jeu de faire l'impasse sur le langage c++", ça mériterait un topic complet. Je pourrais déballer douze kilomètres d'arguments appuyés par l'expérience pour vous prouver que la réponse est non avec un grand n, mais ça serait hors sujet.

On parle d’un développeur de jeu ou d’un développeur de moteur de jeu =P ?
Les gros Middlewares utilisés par l’industrie sont développés en C++, je te l’accorde, mais les développeurs qui utilisent l’outil ne développent pas nécessairement en C++ (à titre d’exemple, j’ai joué un peu avec le Cry Engine, et tout le scripting se fait en LUA, sous Unity c’est du pseudo javascript ou du C#, sous UDK/UE on a le choix entre un langage de script maison ou du C++).

NonPeut-être pas obsolète mais pas faite pour des projets d'envergure.

Après je ne pense qu’il y ait réellement une limite à l’envergure des projets réalisables avec XNA/Monogame. Je pense que c’est avant tout une question de productivité/efficacité.

D’un point de vue subjectif, outre les considérations d’obsolescence (qui ne concernent qu’XNA, car câblé sur une version obsolète de DirectX, là où Monogame s’appuie sur les dernières versions d’OpenGl et de DirectX), je pense qu’à l’heure actuelle, pour la personne qui souhaite réellement développer un jeu vidéo, il existe des outils bien plus efficaces pour arriver au même résultat (Unity pour ne pas le citer, car il est de loin le plus facile d’accès).

Du côté de XNA, si je devais citer quelques jeux auxquels j’ai joué et qui tiennent la route ; Terraria, Schizoid et Magicka. Du coté de Monogame ; ceux présents sur cette page (à l’exception de Infinite Flight que je n’ai pas testé). Il est clair que nous ne sommes pas face à des jeux AAA, mais nous sommes tout de même loin d’un morpion ou un casse-briques ^^.

[ShadowTzu]

Ouais sauf que la théorie et la pratique ne vivent pas dans la même galaxie et qu'on est sensé répartir la charge sur tous les processeurs de la machine et que le gpu est sensé calculer les choses pour lesquelles le gpu est optimisé. Or des algos de recherche codés en basic je le sens pas trop...

Et pour ceux qui veulent dévier vers le débat "est-il dans l'intérêt d'un développeur de jeu de faire l'impasse sur le langage c++", ça mériterait un topic complet. Je pourrais déballer douze kilomètres d'arguments appuyés par l'expérience pour vous prouver que la réponse est non avec un grand n, mais ça serait hors sujet.



J'ai jeté un oeil à ton moteur 3d en basic, je vais pouvoir étoffer ma réponse.

Ton moteur est un moteur d'affichage, ce sont effectivement des "algos" pour lesquels un gpu est optimisé, et comme je disais plus haut je mets des guillemets à "algo" parce que c'est rien que des bêtes boucles for.

Les algorithmes de moteur de jeu ça n'est pas les mêmes, ce sont d'une part des algo indépendants du gpu facile à porter car du calcul pur, d'autre part ce sont des algo récursifs ou itératifs basés sur des structures non-linéaires. Quelques exemples d'algos classiques qu'on retrouve dans la plupart des moteurs de jeu: arbres spatiaux moins obvious que les octree (bsp, bvh, etc), culling récursif basé sur une structure sector/portal, ia basée sur du pathfinder, broad phases de collision des moteurs physiques également basées sur des parcours d'abres (souvent des kd-tree, qu'on construit souvent au loading), etc... il y'a très peu de calculs vectoriels dans ces algos là, juste quelques petits produits scalaires ou en croix, tout le reste c'est de la recherche dans des tableaux (comme de la bdd mais en plus chiant), et, je vois pas trop lintérêt de déléguer ça au gpu à part se compliquer la vie inutilement.

Path finding sur GPU: http://gpgpu.org/2012/06/20/multi-agent-path-planning
Octree sur GPU: http://gpgpu.org/2010/01/20/gpu-simu...nd-gpu-octrees
Collision sur GPU: http://gpgpu.org/2010/12/27/fast-gpu...ormable-models

L’intérêt de faire ça sur le gpu lorsqu'on fait du game en .NET est justement d'avoir quelque chose d'équivalent voir même de plus performant que si cela aurait été codé en c++ (gpu=100Gb/s)
Ce n'est pas se compliquer la vie inutilement, c'est trouver des solutions intelligemment.
j'en reviens donc à la même conclusion: En ce qui concerne les perfs du .NET pour les "algorithmes complexes" c'est devenu vraiment négligeable notamment depuis DirectX11 avec DirectCompute.

Pour en revenir à XNA, basé sur DirectX9 (pas de compute shader) il est en effet difficile d'avoir de bonne perf avec ce genre d'algo. Alors qu'avec MonoGame (basé sur DirectX11) ou les wrapper (SharpX, SlimDX, ...) on a accès à DirectCompute et donc à la possibilité de coder de "gros" jeux.

Mon Opinion?
L'avenir des codeurs XNA est de passer à MonoGame.

[jean_kevin_musclor]

I-Pnose > Je ne vois pas de séparation catégorique entre les utilisateurs de moteur qui ne feraient que du script et les développeurs de moteur qui ne feraient que du c++, il me semble que c'est plus nuancé que ça. Les utilisateurs de unity par exemple peuvent faire des extensions en c++, et ils peuvent aussi faire une surcouche de moteur en c#. Pour cry engine ou id tech engine c'est encore plus évident tu mets les mains directement dans la source, c'est du boulot collectif où chacun pose son truc, je vois pas de séparation entre deux groupes. Et enfin dans le cas des jeux à petit budget codés maison, il n'y a aucune séparation jeu/moteur.

ShadowTzu > Je sais que les gpu gèrent très bien les structures type grille/octree car ce sont des structures integer simples qui collent très près à la structure de la ram. Ceci dit il me semble que l'algo qu'on fait dans les octree gpu en général c'est le raycast, qui est une bête boucle for et pas un algo récursif. Je sais aussi que les gpu gèrent la dernière étape des algos de collision (qui elle aussi est une bête boucle for) puisque ce sont des calculs vectoriels, par contre les broad phase dans les structures compliquées des moteurs physiques, j'en doute. Bref tes articles confirment que le gpu c'est fait pour les algos pour lesquels le gpu est optimisé, pas pour la totalité des algo donc. si le cpu servait à rien ça se saurait...

[Franck.H]

Avez-vous essayé d'utiliser XNA ?

Non

Quel est votre avis sur MonoGame ?

Ayant plongé un peu dedans en faisant une suite de tutoriels, je trouve qu'on est encore loin d'une intégration complète car il fallait, par exemple, pour afficher du texte, utiliser un outils pour convertir les fichiers au format xnb pour que les polices soient utilisable. Je ne parle même pas des fichiers audio que je n'ai pas réussi à utiliser correctement (c'est mon tutoriel manquant d'ailleurs) donc pour moi, MonoGame à encore du chemin à faire !

Pensez-vous que XNA/MonoGame est une technologie obsolète ? Pourquoi ?

Peut-être pas obsolète mais pas faite pour des projets d'envergure.

Conseilleriez-vous aux nouveaux développeurs de partir sur d'autres solutions ? Lesquelles ?

Suivant la grandeur du projet, XNA/MonoGame pour des tests de codes vite fait ou du prototypage comme ça a été dit précédemment mais sinon je conseillerais vivement Unity qui permet maintenant de faire également de la 2D aussi bien que de la 3D et qui permet de mettre facilement en scène votre jeu. J'ai surtout trouvé l’interaction (par exemple) entre l'ajout d'une variable publique dans le code et son apparition dans l'interface de l'éditeur formidable, j'ai jamais vu ça

[negstek]

ça me rappelle silverlight, c'est risqué de s'investir dans les technos microsoft, beaucoup d'heures d'apprentissage finalement perdues au moins on a pas ces problèmes avec les projets open source comme MVC (pour .Net sur codeplex) ou autres perles du genre.

[I_Pnose]

ça me rappelle silverlight, c'est risqué de s'investir dans les technos microsoft, beaucoup d'heures d'apprentissage finalement perdues au moins on a pas ces problèmes avec les projets open source comme MVC (pour .Net sur codeplex) ou autres perles du genre.

Le cycle de vie de XNA est calqué sur celui de la XBoite 360, ce fait était acté dès le départ (puisqu’à la base ce Framework était censé permettre aux dév indé de développer des jeux pour pc et console le plus facilement possible). C’est donc pour cette raison que XNA ne peut plus évoluer (hardware de la XBox figé) et va être peu à peu délaissé pour d’autres solutions. Et c’est également pour cette raison que le projet Monogame n’a pas attendu la fin de vie programmé de XNA pour voir le jour, le projet reprend le flambeau et fait mieux -sur tous les fronts- que son grand frère (perfs, multiplateforme, dernière version des api graphiques, dernière version des IDE, etc...). Dans la mesure où les syntaxes de Monogame et de XNA sont 100% identiques (jusqu’aux noms des namespaces) l’investissement dans la techno de Microsoft n’est pas perdu.

Concernant Silverlight, oui ça a fait un flop auprès du grand public, mais il reste que les technologies sous-jacentes à Silverlight sont à la base de tout l’écosystème Microsoft actuel ; on retrouve du XAML dans les projets WP8/8.1, Win8/8.1, WPF, WF... l’investissement sur le langage n’est donc pas perdu non plus (quant aux projets RIA propulsés par Silverlight, ils peuvent, au besoin, être traduits en applications W8 et/ou WP8 pour limiter la casse, et surtout toucher un public plus large).

[Iradrille]

La toute première version de XNA (appelée XNA Game Studio Express) a été publiée le 11 décembre 2006.

Pour le développement de jeux PC, XNA est obsolète depuis son lancement : les premiers GPU supportant DirectX 10 sont sortis en novembre 2006 (Geforce 8800).
Son principal intérêt reste quand même le développement de jeux consoles, et je pense que sur ce point il à rempli son rôle.

Après je ne connais pas vraiment ni XNA ni Monogame, donc je peux pas vraiment en dire plus.