Salut tout le monde !

Aujourd'hui on ne va pas encore revenir sur les ventes hebdomadaires de "Blocks That Matter" mais plutôt... Quoi ? Vous les voulez vraiment ? Bon ok, mais rapidement alors, et juste après on parle (enfin !) des versions Windows/Mac/Linux.

Attention, ça va être un peu technique, mais je l'espère quand même un peu intéressant.

> Couverture média

E3 oblige, BTM s'est fait discret sur la toile cette semaine. Mais est-ce que vous avez vu Rayman Origins, From Dust, Journey, Sound Shapes et PixelJunk : Side Scroller ? Voilà des titres plutôt rafraichissants au milieu de tout ces "Modern War Shooter" fps.

> Ventes

Bien, à présent voici l'état des ventes depuis la semaine dernière.

Comme vous le pouvez le voir, le jeu s'est massivement vendu en France et...presque pas ailleurs. Cela s'explique par un manque flagrant de couverture par des sites étrangers.

Il semble que nous ayons donc des difficultés à trouver notre public au Royaume-Uni et aux Etats-Unis. Peut-être avec la sortie PC ?

Vous y êtes habitués maintenant, voici donc les chiffres, jour après jour, au format "ventes/téléchargements (taux de conversion)".

- j23 (6/3/2011) : 61/ 280 (21.7%)
- j24 (6/4/2011) : 86 / 251 (34.2%)
- j25 (6/5/2011) : 99 / 285 (34.7%)
- j26 (6/6/2011) : 47 / 171 (27.4%)
- j27 (6/7/2011) : 33 / 83 (39.7%)
- j28 (6/8/2011) : 33 / 86 (38.3%)
- j29 (6/9/2011) : 28 / 77 (36.3%)
- j30 (6/10/2011) : 27 / 89 (30.3%)
- j31 (6/11/2011) : 37 / 93 (39.7%)
- j32 (6/12/2011) :39 / 84 (46.4%)

- total: 244 / 683 (35.7%)

- global: 1850 / 9558 (19.3%)

Et une jolie courbe pour illustrer l'évolution des ventes depuis le premier jour :

1.850 ventes en un mois, c'est pas mal...mais toujours pas suffisant pour manger. C'est pourquoi les versions PC sont vitales pour le futur de Swing Swing Submarine. On est en tout cas bien loin des 251.355 ventes de FortressCraft :]

> Du côté des joueurs

Encore merci à tous ceux qui, parmi vous, nous ont envoyés un mail ou deux pour nous dire que vous aviez terminé le jeu et surtout pour nous dire ce que vous en avez pensé. c'est toujours un plaisir d'avoir des retours de joueurs.

Nous avons également reçu plusieurs messages provenant de joueurs impatients ou qui pensaient que les versions PC étaient déjà disponibles. Impossible pour l'instant d'avancer une date précise (même si cest pour bientôt), par contre on peut tout à fait vous dire où nous sommes du portage !

> A propos du portage de "Blocks That Matter"

Comme vous le savez, BTM est disponible sur Xbox Live Indie Games, ce qui signifie qu'il a été développé en utilisant le language C# (on dit aussi C-sharp) et le framework Xna. Xna est un framework qui ne tourne que sur Xbox et sur Windows, et nécessite également le framework .NET 4.0 qui est ni plus ni moins qu'une technologie Microsoft.

En gros, on aurait tout à fait pu proposer le jeu sur Windows dès le jour de sa sortie Xbox, mais comme il nous semble important de ne pas laisser les utilisateurs Mac et Linux sur le carreau, nous avons entamé le portage du jeu afin de proposer une version "universelle" sur ordinateurs.

Il nous a bien évidemment fallu faire des choix. Au final, j'ai retenu deux solutions, et vous allez voir laquelle donne les meilleurs résultats sur les 3 plateformes.

>> La méthode "facile"

Plusieurs amis développeurs (Garry, Marc et Elisée) m'ont parlé de "Mono Game".

>>> Presentation

Mono Game est un portage multi-plateforme du framework Xna qui utilise Mono.

Mais alors, c'est quoi Mono (rapidement) ?

Mono est une implémentation multi-plateforme du framework .NET (incluant les compilateurs). Cela signifie que si vous programmez en utilisant Mono, vous écrirez exactement le même code que si vous utilisiez le framework .NET lui-même...mais que votre code tournera sur les plateformes supportées par Mono.

Mono n'est qu'un "portage" (plus précisément une implémentation) du framework .NET, il n'inclut pas la couche du framework Xna qui permet de gérer l'affichage (accéléré matériellement) ou encore l'audio, la gestion des manettes, etc.
Afin de gérer de telles fonctionnalités, Mono Game s'appuie sur une autre librairie (encore une!) : OpenTK. OpenTK permet a Mono (ou .NET) d'accéder à des librairies (encores d'autres !) comme OpenGL (rendu) ou OpenAL (son) alors que ces librairies sont écrites dans un autre language (le C).

>>> Pourquoi est-ce la méthode "facile" ?

Vu le dernier paragraphe compliqué, vous vous demandez sûrement en quoi tout cela semble facile puisque cette méthode implique de nombreux frameworks et librairies !

En fait, l'intérêt de ces librairies est qu'elles vous permettent de conserver votre code C# déjà existant. En théorie, tout ce que vous avez à faire c'est de compiler avec ces librairies, la syntaxe du code restera la même. Plutôt cool, non ?

>>> Ce que j'ai obtenu avec Mono Game jusqu'à présent

Il ne m'a fallu qu'un petit week-end pour porter le jeu avec Mono Game. J'ai apporté quelques modifications à la librairie de Mono Game (qui est open source) afin de réussir à faire tourner Blocks That Matter car la librairie ne prend pas en charge la lecture et le chargement des fichiers XML, ni les contrôles claviers (seulement le support écran tactile pour iPhone/Android...que nous n'utilisons pas).

Il n'y a pas encore de support audio dans Mono Game, vous devez donc tout écrire vous-même en utilisant OpenTK (grâce à l'encapsulation d'OpenAL) et faire aussi quelques implémentations de classes Xna.

Comme le son n'est pas crucial dans un premier test, j'ai dédidé d'essayer sans trop m'en préoccuper, et voilà ce que j'ai obtenu après plusieurs heures de travail :

Le rendu est un peu saccadé et ça n'est pas dû qu'à la capture Fraps. Même sans Fraps, j'obtiens des chutes de framerate (le jeu met largement plus de 33ms pour rendre une image, et le framerate est très variable. Pour info, un jeu à 60FPS met 16ms pour rendre une image).

Il faudrait que je fouille un peu plus pour voir où se situe le goulot d'étranglement...peut-être dans Mono Game...ou simplement dans Mono.

Je ne pense pas que ce soit dans le code du jeu puisque le jeu tourne parfaitement avec l'implémentation Xna/C#/.NET, même sur mon Mac Mini (sous Windows).

>>> Les + de Mono Game

- Facile de maintenir toutes les versions (console, Win, Mac, Linux) puisqu'il sagit d'une même code à la base

- Pas besoin d'ajouter beaucoup de code pour faire tourner le jeu avec Mono Game

- Pas vraiment un portage, plutôt une "émulation"

>>> Les - de Mono Game

- De très mauvaises performances pour le moment

- Pas facile à déployer sous Linux (trop de dépendances)

- Pas vraiment un portage, plutôt une "émulation" (oui c'est aussi un -)

>> La méthode "difficile"

Enfin difficile, disons que ce n'est pas la plus difficile de toutes. Elle consiste à porter le code du jeu en Java, ainsi qu'un équivalent du framework Xna et des fonctionnalités utiles au jeu apportées par le framework .NET.

>>> Présentation

Java est un language de programmation qui a la particularité d'être pensé pour faciliter le déploiement multiplateforme puisqu'il s'appuie sur des Machines Virtuelles pour exécuter du "bytecode".

Bien que Java ne soit à la base pas fait pour afficher des éléments accélérés en hardware (matériel, avec une carte 3D), ni pour jouer des effets audio complexes, une feature spéciale permet à Java d'utiliser des librairies C ou C++. En effet, avec JNI quelques librairies comme OpenGL (rendu) et OpenAL (audio) peuvent être encapsulées et manipulées depuis du code JAVA.

C'est ce que j'ai utilisé à travers une librairie appellée LWJGL. Cette librairie facilite la création de pas mal de choses (créer une fenêtre, un contexte Open GL, etc...) et englobe des librairies orientées "jeux" bien utiles.

>>> Pourquoi est-ce la méthode "difficile" ?

C'est la méthode "difficile" principalement parce que vous devez réécrire du code (parfois beaucoup), Java et C# ne fonctionnent pas de la même façon. Heureusement, les deux languages ont quand même des similarités : ils utilisent tous les deux un système de gestion de mémoire et sont orientés Objet (vous allez le voir en image plus loin).

C# étant la réponse de Microsoft à Java, les deux languages partagent le même ADN et il n'est pas rare de voir de troublantes similarités entre les classes de Java et de .NET.

Voici une fonction qui dit si un "upgrader" (les grosses boites grises dans le jeu) peuvent ou non s'ouvrir quand le joueur collecte un nouveau bloc. A gauche la version Java, à droite l'originale en C#.

Les deux codes sont très similaires, et ça l'est parfois encore plus (bon parfois moins aussi).

>>> Ce que j'ai obtenu avec Java jusqu'à présent

Toutes les cinématiques et tous les niveaux se chargent. Les contrôles (claviers et gamepad) sont pris en charge, les sons ne sont pas encore implémentés. Voici ce que j'ai obtenu après 2 ou 3 semaines de travail :

Comme vous pouvez le voir, le framerate est bien meilleur ici que sur le portage Mono Game (même machine, même outil de capture, même durée).

Bien sûr, il reste encore des choses qui sont un peu cassées (comme la police de caractères et la position de l'oeil du Tetrobot, le pauvre). Comme pour la version Mono Game, je n'ai pas encore implémenté les sons (bien qu'une partie du code soit déjà portée).

>>> Les + de Java

- Les performances sont là pour un petit jeu comme le nôtre

- Parfois très proche du C# en terme de syntaxe

- Une applet in browser envisageable (pour une démo ? Pour de la promotion ?)

- Déploiement sur plusieurs plateformes avec les mêmes performances (voir les images ci-dessous)

>>> Les - de Java

- Et parfois c'est quand même très éloigné du C# en terme de syntaxe

- Obligation de réécrie (et parfois copier/coller ou adapter) beaucoup de code

>> Et la méthode "super difficile" ?

Hé bien ça aurait été de réécrire entièrement le jeu en C++, ce qui est bien plus long que de réécrire en Java puisque C# et C++ n'ont pas grand-chose en commun (si ce n'est que ce sont deux languages orientés Objet).

>> Les prochaines étapes du portage

Je pense que je vais concentrer mes efforts sur la version Java puisque c'est celle qui offre les meilleures performances et qui nous simplifie le déploiement sur Win/Mac/Linux.

La prochaine étape pour moi est de faire fonctionner les sons. Puis de corriger quelques bugs ici et là, remplacer la police de caractères et faire quelques optimisations Java (et il y a de quoi faire, mes souvenirs de Java sont un peu rouillé par moments, mais j'ai mon Mojo).
 Et reste aussi à implémenter les nouvelles fonctionnalités promises avec les versions PC. Oui, c'est beaucoup de travail ! Mais d'un autre côté, vous méritez, joueurs PC, une version décente du jeu vous aussi !

On aura d'ailleurs sûrement besoin de volontaires pour lancer une application de test sur vos machines, on en a déjà quelques'uns mais on lancera bientôt un nouvel appel via un post dédié !

A la prochaine !

Des bisous.

Guillaume