Parfois, au détour d'un article sur le jeu vidéo, je lis des phrases du type les « développeurs font très peu de jeux sous Linux car la plateforme est difficile à programmer ». Comme ça, sans se perdre dans les détails de la difficulté. Et parfois même dans des magazines ou des sites de bonne qualité... quand ils parlent jeu. La raison du manque de jeux natifs sous Linux semble donc être d'ordre technique. Voyons ça de plus près.

Définissons un peu le contexte : nous parlons ici de jeux natifs, c'est-à-dire que l'on installe sur le disque dur et qu'on lance localement et non des jeux de technologies web, comme les jeux Flash¹.

Je vais passer en revue différents domaines de la création d'un jeu, d'un point de vue technique, pour voir où cela pourrait coincer.

Le hardware

Mentionner Linux est assez vague, Linux est techniquement le nom d'un noyau de système d'exploitation qui peut se lancer sur de nombreuses plateformes, avec du hardware très différent. Cependant, lorsque l'on mentionne Linux dans un contexte d'ordinateur personnel, et encore plus lorsque l'on parle de jeux, il y a abus de langage. Lorsque ces articles parlent de Linux, ils parlent en fait des systèmes d'exploitation basées sur le noyau Linux (on appelle ça des distributions) utilisées sur un ordinateur personne de type « PC ».

Autrement dit, on parle ici de Linux tournant sur du hardware qui pourrait faire tourner Windows.

Même si ces deux systèmes d'exploitation ont une manière de voir leur environnement différente, il reste que, derrière, ce sont donc les mêmes périphériques avec les mêmes normes techniques, les mêmes processeurs, les mêmes cartes graphique et mêmes cartes son.

Du fait du peu de support de certains constructeurs au niveau des drivers, il y a même moins de périphériques compatibles Linux que compatibles Windows. On verra plus loin que c'est un avantage du point de vue du développeur.

Accéder au hardware

Si le hardware est sensiblement le même sous un PC sous Windows ou Linux, cela peut être la manière d'y accéder qui gêne. En effet, il n'y a par exemple pas DirectX(R) sous Linux, du moins pas nativement. Sous MacOS-X ou Playstation 3 non plus. Ce qui ne gêne pas certains développeurs de développer des jeux sur ces plateformes.

Forcément, un développeur qui choisi une solution technique fortement ancrée pour une plateforme spécifique va avoir une certaine difficulté à faire tourner son jeu sur une autre plateforme. Mais c'est un choix, qui peut d'ailleurs être tout à fait judicieux, pas une obligation.

On pourrait alors arguer qu'il est plus difficile de programmer un jeu sous Linux car les environnements dédiés jeu sont plus nombreux et plus facile à mettre en œuvre sous Windows. C'est un argument recevable pour les petites productions qui vont développer sur du XNA ou du Unity3d. Si je doute que XNA permette de faire un jour des jeux sous Linux, cela ne doit poser aucun soucis technique à Unity3d, qui cible déjà des plateformes bien plus variées qu'un simple changement d'OS sur un même matériel.

D'autres plateformes, comme Unreal, ciblent déjà Linux.

Les assets

On pourra noter aussi que, puisque seul la couche logicielle change, deux versions Linux et Windows d'un même jeu peut partager ses assets (textures, meshs, sons,...). Les performances seront similaires et il est de toute façon d'usage dans le monde du jeu PC de permettre à l'utilisateur de régler le niveau de détail du jeu, sachant qu'il tournera sur des machines à des puissances très différentes.

C'est à comparer avec un jeu commun entre une console de salon et un PC, voire entre deux consoles de salon, où il n'est pas rare de devoir adapter les assets pour tirer le meilleur parti des différences de plateforme.

Conclusion sur le hardware

Si un jeu Linux est plus difficile à programmer qu'un jeu Windows, on vient de voir que cela ne venait pas du hardware. Programmer un jeu sous console, et encore plus multi-plateforme PC/Console, est bien plus complexe. Et de nombreux développeurs le font quand même.

Cherchons ailleurs.

Compétences logiciel

Puisque le matériel n'est pas en cause, regardons du côté logiciel. Il y a bien sûr de quoi programmer le hardware sous Linux : des jeux existent, même s'ils sont peu nombreux. Peut-être s'agit-il de manque de compétences pour programmer la plateforme ?

Là encore, je dis non. D'abord car les API disponibles sous Linux sont souvent déjà connues des développeurs (OpenGL ou FMOD par exemple) et qu'ensuite, encore une fois, des développeurs qui sont capables de réapprendre à chaque nouvelle génération de console un matériel et des API nouvelles peuvent très bien apprendre à programmer sous Linux.

Je n'ai pas de chiffres, mais quelque chose me dit qu'il y a bien plus de programmeurs au fait des technologies utilisées sous Linux que de programmeurs sur console.

Autres raisons

Le temps

On ne peut pas le nier : développer pour une plateforme en plus, en considérant que la version maîtresse est la version Windows, prend du temps. Il y a deux manières de faire une version multi-plateforme :

• développer les versions simultanément : beaucoup plus facile car les problèmes sont détectés sur le moment, la méthode demande cependant plus d'investissement.
• développer une version, puis l'autre : cela peut amener la seconde version à hériter de bugs cachés dans la première version et demander un peu plus de travail ; l'avantage étant que l'investissement est décalé par rapport au développement de la première version.

Le temps de développement supplémentaire est-il si gros ? Rappelons encore que nous sommes là sur une même machine. Seule la couche logicielle change. Si les bons choix architecturaux et technologiques sont fait dans la version initiale en prévision de son portage, alors le temps d'adaptation à l'autre plateforme n'est pas si énorme.

À titre d'exemple, j'ai adapté pour Linux un jeu Windows. Je n'ai pas vraiment compté le temps que j'y ai passé, mais cela n'a pas dépassé 10 heures (j'évalue plutôt à 7 heures, temps de tests compris). Ce jeu était déjà adapté au multi-plateforme et l'adaptation consistait à implémenter quelques fonctions et recompiler le tout. Quelques bugs sont apparus (méthode numéros deux ci-dessus) et ont fait que cela a pris un peu de temps. L'adaptation n'est pas parfaite : il resterait à faire un package avec gestion de dépendances, méthode préférée sous les distributions Linux au simple .zip que j'ai livré. Il reste aussi quelques soucis qualitatifs à l'installation.

Il reste probablement 2 ou 3 heures à passer dessus.

10 heures... 10 heures pour un programmeur seul. Ce n'est pas un gros programme, mais cela donne une idée du peu de travail nécessaire.

En fait, et cela se ressent dans les problème qualitatifs que j'ai mentionné, ce qui a manqué est principalement du test : j'ai testé le jeu sur deux ordinateurs, il a été testé par quelques personnes qui ont bien voulu faire un retour. Cependant, il manquait une vraie phase de tests sur différents matériels et différentes distributions.

Et c'est cela qui prendrait du temps pour une adaptation complète. Et le test sur ordinateur personnel est long car il nécessite beaucoup de tests matériel, ce qui n'est pas le cas sur console.

En cela, oui, adapter un jeu sous Linux est plus long qu'adapter un jeu sur console. À balancer avec le temps de développement, qui lui, est plus court.

Et c'est là, je l'évoquais tout à l'heure, que le matériel plus restreint supporté par les distributions Linux est un avantage. Moins de matériel à tester².

Diversité des distributions

Comme je l'évoquais au début, Linux est un abus de langage pour désigner de nombreux systèmes d'exploitation ayant pour base commune le noyau Linux. Cependant, cet abus de langage est assez limité : on ne désigne pas Android sous le nom de Linux, pourtant, s'en est un. Le noyau Linux est présent dans de nombreux matériels sans que leurs utilisateurs soient au courant.

Finalement, sont appelés Linux un nombre restreint de produits. Restreint mais nombreux tout de même : Debian, Red Hat, Ubuntu, Suse, Slakware,... La page sur Wikipedia présente même un arbre généalogique des différentes distributions.

Cela fait peur : est-ce que le programme tournera de la même manière sur toutes les distributions ? Il y a des solutions techniques, plus ou moins élégantes, mais dans les grandes lignes, cela ne pose pas vraiment de problèmes. La difficulté se situe à nouveau dans le test, qui sera multiplié par le nombre de distributions supportées. Elle se situera aussi éventuellement dans l'intégration naturelle à une distribution, l'histoire de package que je citais au début.

À noter que dans le monde Windows, le problème de disparité des versions existe aussi : toutes les versions de Windows ne se comportent pas de la même manière. Le monde Windows a réglé le problème : à une époque donné, un jeu n'est généralement compatible qu'avec la dernière version grand public et sa précédente³. Peut-être qu'il tournera avec d'autres versions. Cela n'est juste pas garanti.

On peut imaginer la même chose dans le monde Linux : un développeur peut garantir le fonctionnement pour Ubuntu et toucher ainsi la grande majorité des utilisateurs grand public, éventuellement une autre grande distribution. Sur le reste... et bien cela fonctionnera peut-être.

D'autres plateforme ont des éclatements bien pire : dans les téléphones portables, il faut à peu près faire une version du jeu par modèle de téléphone. Même sur des plateforme concentrées comme iPhone ou Android, les divers matériels et les diverses versions obligent à gérer la diversité des plateformes.

Là encore, finalement, tout n'est question que de temps, de volonté de faire. Il n'y a pas d'obstacle technique insurmontable, et aucun qu'on ne trouve déjà ailleurs.

Les outils

Le sujet est un peu annexe, car lorsque l'on programme pour console, on ne programme pas sur console. Et il n'est pas obligatoire lorsque l'on programme pour Linux de programmer sur Linux.

Mais cela serait dommage de s'en passer.

Cependant, lorsque je parle de programmer sur Linux à certains programmeurs, j'ai parfois droit à des yeux ronds. Particulièrement chez les plus anciens qui ont gardé des souvenirs visiblement douloureux de leurs études à programmer avec des outils vus comme rustiques.

Autrement dit : il n'y a pas Visual Studio sous Linux, comment on va faire ?

Heureusement, sur Linux sont disponibles de nombreux outils de développement. Si l'on veut quelque chose d'aussi peu pratique que Visual Studio⁴, on peut retrouver une sorte de clone avec Code::Blocks. Mais on peut aussi aller vers Eclipse, pour citer un autre environnement bien connu, ainsi que des solutions libres ou propriétaires de différents types. Il y en a pour tous les goûts.

Et non, vous n'êtes pas obligés d'utiliser gdb en ligne de commande pour débugger.

Mais alors ?

Si tout à l'air si simple et si rose dans le développement de jeux sous Linux, pourquoi y en a-t-il si peu ?

Cet article, qui est écrit en réaction à la phrase « la plateforme est difficile à programmer », a tenté de montrer brièvement que la technique n'était pas en cause. Les programmeurs de jeux vidéo ont l'habitude de résoudre de problèmes et de programmer sous des plateformes bien plus complexes qu'un simple changement de couche logicielle sur une plateforme PC.

C'est ailleurs qu'il faut chercher l'absence de gros titres sur Linux. Alors qu'on y trouve de plus en plus d'indépendants.

Tout simplement, le retour sur investissement n'est pas évident. Il n'est même probablement pas calculé par la plupart des éditeurs. La plateforme Windows est une plateforme très piratée et je pense qu'il y a une crainte que, pour une même plateforme matérielle, la situation soit la même sous Linux.

Les joueurs étant peu nombreux sous Linux (puisqu'il y a peu de jeu ; problème de l'œuf et de la poule), ce marché de niche est délicat à négocier, particulièrement si le développement conjoint ou le portage du jeu coûte cher.

Pourtant, les sorties de World of Goo l'année dernière et du Humble Indie Bundle cette année ont montré deux choses : il y a un public joueur et demandeur qui utilise Linux d'une part et ce public est près à payer d'autre part. En effet, quand World of Goo est passé en « Payez ce que vous voulez », les statistiques ont montré que les joueurs Linux avaient en moyenne dépensé plus pour le titre. La même chose a été constatée sur l'Humble Indie Bundle.

On pourra penser que la rareté du jeu sous Linux provoque ce paiement plus fort. Peut-être. Mais on voit surtout qu'il y a un marché qui ne demande qu'à s'emballer.

Qui fera le premier pas ? Des tentatives d'éditions ont été faites pour les jeux sous Linux. Quelques gros jeux, comme Unreal ou Quake, ont été sortis dessus⁵.

Ce qu'il manque, à mon avis, et qui pourrait rassurer les éditeurs sur les risques de piratage sur un marché de niche, c'est une plateforme de vente online. Steam sous Linux par exemple ? Après tout, Steam est à présent disponible sur MacOS-X, une autre plateforme traditionnellement pauvre en jeu vidéo.

Même si j'aimerais qu'un concurrent sérieux à Steam apparaisse, pour éviter les risques de monopole qui seraient dommageables, je verrai l'arrivée de Steam sous Linux d'un très bon œil. C'est le genre de choses qui me feraient jouer à nouveau sur PC.

Messieurs les éditeurs, à vous ! Ne vous inquiétez pas, les studios de production sauront faire.

En guise de continuité, je vous propose d'écouter le podcast Du pain et des jeux épisode 1 où l'on retrouvera un passage sur Steam sur Mac avec une évocation d'un éventuel Steam sur Linux.