Actuellement se tient à San Francisco une série de conférences organisées par Microsoft et étalées sur trois jours, le but étant pour la firme de présenter ses dernières avancées technologiques et techniques aux développeurs. Ainsi on y parle Windows 8.1, Kinect, Internet Explorer, etc… Le sujet qui nous intéresses tous actuellement est la possibilité de voir un remplacent pour XNA et apparemment le verdict a été donné : Unity3D. Le moteur Unity est disponible pour Windows 8, Windows Phone 8 et Xbox One, cependant il n’est gratuit que sur PC, pour ces autres plateformes il faudra acheter une licence qui est vraiment trop chère pour le développeur de garage d’à côté. Alors on pourrait se demander ce qui se passe chez Microsoft, pourquoi donner les commandes à un tiers ? Pourquoi ne pas nous avoir fait lever les bras hier soir en nous annonçant XNA 5 et un XBLIG nouveau, revu et corrigé ? Et bien je pense qu’il y a deux facteurs. Premièrement c’est du travail en moins pour Microsoft car ça fait de la documentation, du support, des frais de R&D en moins et c’est donc la société derrière Unity qui va dépenser à la place de Microsoft. Ensuite il y a le fait que sur le XBLIG il n’y a pas que des belles productions, beaucoup de gens disent d’ailleurs que le XBLIG est le coin à « jeux de merde » sur Xbox 360 et ça Microsoft l’a mal vécu et c’est une manière de fermer cette section. Oui car si les développeurs doivent acheter une licence (oh combien chère bon sang) de Unity pour développer sur Xbox One, ils ne sortirons que des jeux avec une qualité finale minimum, c’est donc pour Microsoft la première phase d’entrée.
MonoGame freiné par la communauté et par l’empreinte de XNA
Je l’ai dis plusieurs fois sur ce blog et ailleurs, XNA est un super Framework et MonoGame est un projet vraiment fou. Malheureusement il y a des points très noir concernant MonoGame qui me font penser de plus en plus à l’abandonné clairement. Quand XNA 4 est sortie il y a eu en même temps un tas de limitations car les productions devaient être capables de tourner sur téléphone portable, de plus XNA introduit une gestion du contenu pratique mais aussi terriblement merdique car dés que vous voulez charger une ressource qui n’est pas prise en compte nativement par le Framework il faut écrire un « custom processor » avec un « custom importer ». C’est une perte de temps, c’est compliqué et je connais plus d’un développeur XNA qui n’a jamais écrit son importer car il faut le dire, c’est chiant à écrire et ça ne motive pas. De plus XNA est proche de la XBox et beaucoup de choses en font référence dans le Framework, des choses qui ne devraient pas être présentes dans MonoGame à mon sens.
Maintenant parlons de MonoGame, ce superbe projet dont je suis fan mais qui me déçoit à son tour. La communauté derrière le projet a été très active mais actuellement on constate un gros frein dans le développement et les innovations de ce dernier. J’ai l’occasion de lire le code source souvent et je constate qu’il y a un tas de choses que personne n’utilisent et qui sont encore maintenus, ce qui est normal puisque le but du projet est de coller au plus proche de XNA 4, je constate aussi que le fait de vouloir prendre en compte le maximum de plateforme rend le framework extrêmement complexe, il y a des fichiers avec un nombre énorme de directives #if #elif #else #endif et je peux vous affirmer par expérience que ce n’est pas une partir de plaisir à lire. La grosse faiblesse du Framework à mon sens est de vouloir être comme XNA 4, c’est sur beaucoup de gens peuvent porter leurs jeux, mais au final qu’est ce qui est le mieux pour un jeu ? Un port basique ? Ou un port plus travaillé avec une utilisation des fonctions natives de la plateforme ? La réponse sera différente pour chacun. De plus il y a deux grandes mouvances dans la communauté, ceux qui veulent faire bouger le Framework vers quelque chose de plus jeune, moins lourd, et ceux qui veulent une copie conforme de XNA 4 avec ses défauts.
Le cas YnaEngine
Aujourd’hui dans YnaEngine ce qui me dérange, c’est d’être obligé d’avoir plusieurs dépendances et d’en être (oui passer moi le jeu de mot) dépendant. Ainsi je suis tributaire du contenu de MonoGame, de sa stabilité et de son avancée, de ses régressions, de son manque d’implémentation de telle ou telle fonction. C’est quelque chose qui ne me posais pas de soucis jusqu’à maintenant, mais désormais j’aimerais pouvoir avoir un moteur qui fonctionne au mieux, qui ne fasse pas trop de place (car je vend partout qu’il est léger) et qu’il ne soit pas chiant à mettre en place. Un autre point noir est que MonoGame contient des modules et classes que je n’utiliserais jamais dans YnaEngine et rien que les enlever pourrait diminuer la taille de MonoGame considérablement. Ainsi tout ce qui traite de XACT, du réseau (oui le module entier), des gamer services et du content processing (là c’est à discuter, il faudrait faire un gros refactoring) et bien je n’en ai pas besoin.
Atlantis, une expérimentation de plus en plus intéressante
Il y a quelques temps de cela je me suis fixé comme objectif d’écrire en un weekend un micro Framework, clone de XNA, avec uniquement les fonctionnalités 2D et de porter les classes de bases du moteur 2D de Yna, en JavaScript. J’ai relancé la même opération le weekend suivant, cette fois-ci avec le langage Java. Dans les deux cas la consigne était simple : Ne pas utiliser de bibliothèques annexes, il fallait tout faire à la main. Alors oui j’ai réinventé la roue, mais j’ai tellement appris. Par la suite j’ai commencé une autre version d’Atlantis en C# avec SharpDX mais celle-ci était plus un test pour voir si je pouvais migrer Yna facilement vers SharpDX. Enfin j’ai écris une version d’Atlantis en C++ avec SDL2 (oui il faut vivre avec son temps, SDL2 !) qui fonctionne pas trop mal mais j’y reviendrais en temps et en heure.
Qu’est-ce qu’Atlantis concrètement ?
Le projet est simple : Créer un Framework dans plusieurs langages, avec la même API tout en respectant les spécificités du langage. Le fait d’écrire le Framework dans plusieurs langages permet de repasser à chaque fois sur le code qui a été fait et de le réévaluer. Ainsi j’ai par exemple corrigé certains bugs dans Yna après avoir relus certaines parties des sources. Il faut aussi comme je l’ai précisé plus haut éviter un maximum les dépendances, alors des fois on a pas le choix mais d’autres coup il faut réécrire les choses et on peut s’en passer. J’ai par exemple ré-implémenter une classe Matrix (disponible sur tous les ports).
Atlantis Engine c’est donc deux gros modules, un Framework qui doit être une version améliorée de XNA où on ne garde que le bon et on vire le reste, et un moteur qui est la réécriture de Yna en mieux et plus optimisé. Aujourd’hui le Framework contient environ 3/4 de ce que j’appellerais le « contenu de base » de XNA, à savoir des classes comme Vector2/3/4, Matrix, Quaternion, Game, ContentManger, GameComponent, SpriteFont, SpriteBatch, etc… avec des petits extras.. Les deux gros sujets sont les objets GraphicsDevice qui permet de dessiner de la 3D et SpriteBatch qui permet de dessiner en une passe GPU une série d’images (grossièrement c’est une fusion de texture).
Atlantis est utilisable aujourd’hui presque comme XNA, on dérive la classe Game et on dérive les méthodes de base et on commence à charger du contenu et à le dessiner. Le moteur inclue le gestionnaire d’état, les sprites animés, l’interpolateur et bien plus encore et il est donc facile de créer un petit jeu.
Et Yna dans tout ça ?
Yna ne va pas s’arrêter tout de suite et je ne vais pas supprimer le support de MonoGame car si je faisais ça je n’aurais plus d’outil prêt pour faire des jeux multiplateformes. Les différentes choses que j’apprends tous les jours en travaillant sur Atlantis me permettent de rendre Yna meilleur, ça me permet aussi de le remettre en question. Là je suis en face d’un gros chantier car je pense réécrire toute la partie du moteur 3D.
A terme, je pense qu’Atlantis remplacera Yna mais ça n’arrivera pas tout de suite, d’ici là je dois aussi me libérer du temps pour créer des jeux, pour le moment je sais que le prochain sera réalisé durant le 7 Days FPS…
Quelques liens
- AtlantisEngine.js
- AtlantisEngine.java
- Mon tumblr (des screens work in progress de mon travail)
- Ma page github