Beaucoup d’entre vous m’ont contacté pour me demander ce qu’il fallait utiliser pour faire une jeux avec XNA. En effet il y a beaucoup de possibilités, XNA, MonoGame, ANX… En fait aujourd’hui on ne parle plus de XNA en tant que Framework mais en tant que technologie. Comme vous le savez peut être, à la base XNA est un Framework développé par Microsoft qui a pour but de facilité la vie du développeur sur PC, XBox 360 et Windows Phone 7 en fournissant une couche d’abstraction au dessus de DirectX 9.0. Historiquement le support de Windows Phone a été ajouté depuis la version 4.0 qui fonctionne uniquement avec Visual Studio 2010 (à partir de Express), les versions 3.1 et 3.0 fonctionnent quant-à elles uniquement avec Visual Studio 2008 et ciblent les PC et Xbox 360. Nous allons maintenant voir rapidement ce qu’est la technologie XNA, puis je vous expliquerais ce que ce sont les autres Framework dit « alternatifs ».

XNA Game Studio

Le Framework

XNA est avant tout un ensemble de fichiers dll qui sont utilisés par Visual Studio, c’est ce qu’on appel des références. Ces dlls sont requises pour exécuter votre jeu, c’est d’ailleurs pour ça que quand vous installez un jeu qui est construit avec XNA vous devez installer le fameux XNA Redistribuable qui n’est en réalité qu’un paquet contenant les fichiers dlls de XNA. La différence entre les fichiers contenus dans XNA Redistribuable et XNA Game Studio (le SDK) est simple, l’un contient uniquement les fichiers nécessaires à l’exécution du jeu, l’autre contient les mêmes avec en plus des autres fichiers pour les développeurs.

Le Content Pipeline

En plus de fournir des fichiers dll, qui sont utilisés par Visual Studio dans votre projet et par votre exécutable pour fonctionner, on trouve des outils pour travailler avec le Framework. Le plus connus est le Content Pipeline qui est intégré au processus de compilation du projet. C’est un processus qui se déroule pendant la compilation et qui va compresser vos ressources (graphiques, sonores, fonts, modèles 3D) dans un format spécial et portable que seul XNA sera capable de décoder. Cela permet dune part d’avoir des ressources plus petites et de gagner en taille sur le disque (très important sur Xbox 360 ou Windows Phone) mais ça vous permet de protéger vos ressources lorsque vous distribuez votre jeu à un utilisateur (typiquement il ne pourra pas ouvrir les fichiers XNB). A l’échelle du développeur le Content Pipeline est vue comme un dossier qui se nomme par défaut « Content », depuis XNA 4.0 c’est un peu plus que ça puisque c’est un projet supplémentaire dans la solution (une solution est un regroupement de plusieurs projet, comme les Workspace sur Eclipse). C’est donc un dossier où vous glissez vos ressources pendant le développement et chaque fois que vous compilez elles sont compressées en XNB qui eux même sont ensuite copiés dans un dossier à côté de votre exécutable. Le Content Pipeline agit aussi comme gestionnaire de ressources car c’est grâce à lui que vous pourrez charger des choses du dossier Content (donc des XNB si vous m’avez bien suivis). Il ne chargera pas les ressources plusieurs fois mais une seule (ce qui évite de devoir tenir à jour une liste de ressource manuellement, même si.. il faut le faire hein ^_^)

Techniquement un programme est lancé avant la compilation pour transformer vos ressources et les copier où il faut. Ce programme appel les fichiers dlls Microsoft.Xna.Framework.Content.Pipeline.xxx.dll fournis avec le SDK.

Les outils livrés avec le Framework

Comme tout bons gros Framework, XNA est livré avec des outils pour travailler sur des points spécifiques d’un projet. On trouve XNA Game Studio Device Center (ouf..) qui permet d’enregistrer une console Xbox 360 ou un mobile sous Windows Phone 7.5 pour l’utiliser dans vos développement et pouvoir déployer directement dessus (par contre attention il faut une licence de développeur pour pouvoir déployer dessus..). C’est donc un outils indispensable pour faire autre chose que du jeu sur PC. Il existe d’autres outils fournis, par exemple XNA Framework Remote Performance Monitor for Xbox 360 (ouf puissance 16 !) permet d’analyser les performances de votre jeu sur une console Xbox 360 depuis votre PC.

XAct est vraiment un gros morceau dans XNA car il permet de créer des projets sonores qui contiennent les sons et les musiques de votre jeu. On peut faire des réglages très puissants sur les différentes pistes et samples, par exemple on peut choisir la méthode de lecture des musiques (mémoire ou streaming), ajouter des effets DSP et bien plus encore.

Le futur du Framework de Microsoft

Depuis un moment Microsoft ne communique plus sur son Framework et pour cause la sortie prochaine de Windows 8 et Windows Phone 8 mais aussi de sa prochaine console.. Le but de Microsoft est d’apporter plus de souplesse aux développeurs en fournissant une nouvelle approche dans le développement d’applications multimédia et des jeux : amener DirectX directement chez le développeur en lui permettant d’utiliser du code C++ natif, cela ne veux pas dire qu’on ne peux plus utiliser le langage C# dans Windows 8 non, cela veux dire que désormais le développeur a plus de responsabilité dans ses développements, c’est donc plus dur aussi pour lui.. mais les gains devraient être là aussi. C’est aussi une manière de barrer la route aux développeurs du dimanche qui ne maitrise pas DirectX… Aussi pourquoi continuer de maintenir un Framework C# uniquement managé qui au fil des années est devenu beaucoup moins performant (nous sommes passé à DirectX 11 aujourd’hui). C’est donc un fait, le Framework XNA de Microsoft est voué à disparaitre petit à petit. Maintenant rien ne nous dit que Microsoft ne sortira pas une nouveau Framework…

Les alternatives

Pourtant XNA est une technologie éprouvée, que les développeurs de jeux adorent, car elle est pratique simple et efficace. Le Framework est tellement populaire qu’il a été réécrit pour d’autres plateformes par des développeurs passionnés. C’est alors qu’est apparu dans un premier temps Mono.Xna puis XnaTouch (une version de XNA dédiée à iOS) et enfin MonoGame (la reprise du projet XnaTouch mais cette fois ci pour toutes les plateformes et pas seulement pour iOS). L’avantage de ces Framework c’est leurs côté Open Source et portable, rendant ainsi la technologie XNA à porté de tous les terminaux, qu’ils soient fixes ou mobiles.

Mais concrétement c’est quoi une réécriture ? Ca marche comment ?

Je vais prendre l’exemple de MonoGame car c’est exactement pareil pour tous les Framework « XNA Like ». Comme je l’ai dit plus haut on utilise avant tout des fichiers dlls qui sont utilisé en tant que référence dans le projet. Et bien là c’est pareil, MonoGame est un projet de type bibliothèque (donc le résultat de la compilation est un ou plusieurs fichiers dll) où toutes les classes, structures et méthodes qu’on trouve dans le Framework XNA de Microsoft ont été réécrites, les mêmes espaces de nom sont aussi utilisé en général (sauf pour ANX qui remplace Microsoft.Xna par Anx). XNA n’est pas Open Source donc certaines méthodes et classes n’implémentent pas les choses de la même manière, c’est d’autant plus vrai que MonoGame n’utilise pas (j’y reviens tout de suite) DirectX 9.0 pour communiquer avec le GPU ou les périphériques mais OpenGL (via OpenTK.dll, le wrapper OpenGL pour .Net) et SDL (via Tao.Sdl.dll), cela lui permet d’être parfaitement portable.

En apparence on a donc exactement la même chose :

Un code source identique puisqu’aucun appel direct à DirectX n’est fait avec XNA
Un fichier exécutable et un dossier Content avec des ressources*

Cependant le font est différent :

Utilisation d’OpenGL à la place de DirectX pour des soucis de portabilité
Les fichiers dll ne sont pas les mêmes (les références)
Il n’y a pas de phase de compression des ressources (mais ça arrive \o/), donc pas de Content Pipeline
L’utilisation des Shaders n’est pas encore possible (en fait si mais.. c’est compliqué actuellement)

Comme vous pouvez le constater la chose qui change c’est uniquement les références (donc les fichiers dll) et.. les outils créés par Microsoft qui eux n’ont pas été réécrits (t’imagine recoder XACT toi ?).

Le point le plus marquant reste quand même l’absence du compression de ressources (Content Processor) qui n’est pas présent et donc le dossier Content qui n’est pas créé par défaut. En fait quand on créé un projet MonoGame, on créé à côté de l’exécutable un dossier Content et on y place les ressources, soit au format XNB car MonoGame sait les décoder (les spécifications sont ouvertes), soit au format non compressé (pour les images uniquement ou les musiques au format OGG). Pour un gros projet avec des SpriteFont, des sons, des musiques, des vidéos, des objets 3D, il faudra alors avoir à côté de soit un projet vide XNA pour pouvoir utiliser le compresseur de ressource (Content Processor) afin d’avoir des fichiers XNB utilisables par MonoGame.

J’attire votre attention sur le fait que l’équipe derrière MonoGame travail sur un compresseur de contenu qui permettra, quand il sera terminé, de faire le même travail que celui disponible dans le Framework de Microsoft. En regardant les sources du Framework ANX je constate la présence de ANX.Framework.ContentPipeline.cs qui permet de travailler avec le contenu, n’ayant pas encore testé ce Framework je ne peux pas vous en dire plus pour le moment.

Donc en fait porter un jeu créé avec XNA vers MonoGame revient à quoi ?

Créer un projet standard dans Visual Studio (ou n’importe quel autre EDI .Net)
Ajouter les références (les dlls) de MonoGame au projet
Copier / Coller le code de base créé avec XNA
Copier le dossier Content du jeu de base créé avec XNA à côté de l’exécutable du port MonoGame

C’est tout ! Il y a quand même quelques cas particuliers suivant la plateforme et les technologies utilisés, par exemple si vous utilisez XACT il faudra tout revoir, idem si vous utilisez des shaders personnalisés.

Plus haut je disais que MonoGame reposait sur OpenGL et c’est vrai, mais depuis la sortie de Windows 8, un backend DirectX 11 a été ajoutée et c’est grâce à lui que toutes les communications GPU et périphériques sont réalisés. L’avantage de MonoGame commence réellement de se faire sentir de ce côté car si au début nous étions dépendant d’OpenGL pour des raisons de portabilité, cela posait des problèmes de performance sur certaines plateformes or maintenant avec DirectX pour Windows 8 (et prochainement Windows tout court !) les performances vont considérablement augmenter.

Mais alors par où commencer ?

Par le début l’ami ! Oui je recommande vivement d’apprendre à utiliser la version Microsoft de XNA avec Visual Studio 2010 (Express qui est gratuit ou supérieur si vous avez) car ça vous permettra de vous familliariser correctement avec le Framework mais aussi d’utiliser tous ses outils. Quand vous serez prêt vous pourrez alors vous intéresser à MonoGame ou d’autres alternatives comme ANX ou ExEn (que je ne recommande pas) et être efficace rapidement car vous serez comment tout fonctionne et vous serez quoi faire face au Content Pipeline 😉

Il est clair que dans un futur proche nous pourrons utiliser directement une de ces alternative et c’est pour ça qu’en début d’article je parlais d’XNA en tant que Technologie et pas en tant que Framework car quand on parlera XNA on pensera à la structure du projet, au gestionnaire de contenu, au dossier Content…

Une petite note sur ANX avant de finir si vous voulez bien. Les fichiers dlls fournis avec ANX s’utilisent comme celles de MonoGame il n’y a pas de problèmes là dessus, la chose à prendre en compte est que l’espace de nom d’ANX n’est pas Microsoft.Xna.Framework mais ANX.Framework, donc si vous l’utilisez il faudra remplacer toutes vos directives

using Microsoft.Xna.Framework.xxx

par

using ANX.Framework.xxx

Bien entendu si vous êtes sous Linux et que perdre un peu de temps au début ne vous fait pas peur alors il faut foncer ! Ca marche bien, c’est là alors n’hésitez pas (branche develop3d :P)

Si certains points sont encore un peu flou pour vous n’hésitez pas à réagir dans les commentaires ou à me contacter sur Google+ ou Twitter ! Sur ce codez bien !