Lorsque le nombre de jeux a commencé à décoller sur Linux (entre 2013 et 2015), la question technique s'est posée pour tous les développeurs voulant attraper le train en marche. Fallait-il développer nativement pour cet OS ? Ou utiliser un système d'émulation ?

Début 2013, à la surprise de tous, John Carmack jette un pavé dans la mare aux manchots : le développement natif ne serait pas viable sur cette plateforme et il préconise simplement d'améliorer...Wine, suggérant même que Valve va mobiliser des ressources sur le sujet. Sans suite de la part de Valve, évidemment… Et la déclaration fut par ailleurs assez mal accueillie par la communauté, ce genre de développement condamnant Linux à rester un citoyen de seconde classe dans le jeu vidéo (Les portages via Wine ne sont en général bien acceptés que pour les vieux titres).

Mais pour difficile à avaler qu’elle soit, la vision du père du moteur ID Tech n’en était pas moins partagée par de nombreux développeurs et éditeurs. Et malgré la forte croissance du catalogue Linux, les adaptations natives et optimisées pour cette plateforme restaient rares. Certes, quelques titres phares du catalogue Windows ont bien fini par faire leur apparition sur la plateforme Linux, mais sans qu’ils aient été réellement développés pour elle. En fait, les développeurs ont utilisé pour ce faire une couche intermédiaire, baptisée translation layer (mais le terme wrapper est souvent utilisé) et chargée de traduire les appels Direct3D vers OpenGL. Par exemple, Valve exploite ToGL, qui n'est pas sans rappeler WineD3D. Feral Interactive (GRID : Autosport, Tomb Raider 2013) semble utiliser un système appelé IndirectX, et considère ses portages, compilés et développés sur Linux, comme natifs. Virtual programming, responsable des portages de The Witcher 2, Bioshock Infinite ou encore ArmA III, utilise la technologie Eon. Elle aussi, est vendue comme une implémentation native complète des technologies Windows (D3D). On notera que l’association du terme natif à ces « passerelles sources » fait débat chez les puristes : ainsi ces systèmes interviennent en général à la compilation, produisant un nouveau binaire, alors que Wine traduit les appels Direct3D à la volée depuis le binaire original. Pour autant, le moteur n'est évidemment ni développé ni optimisé pour le système cible, et quoi que ces passerelles devraient proposer une alternative plus performante que Wine, les résultats pratiques sont en vérité très variables, le pire pouvant régulièrement côtoyer le meilleur. Un des développeurs d'Eon parle d'ailleurs de compromis entre Wine et un projet natif.

Sans être développés nativement pour Linux, The Witcher 2 reste proche de la version Windows

Concrètement, certains portages sont proches de la version Windows (The Witcher 2, Borderlands 2), d'autres moins performants (Alien isolation, mais surtout, Shadow of Mordor) et quelques-uns sensiblement meilleurs (ArmA III, Left 4 Dead 2, XCOM 2, Team Fortress 2). Dans le même esprit, certains titres, comme Metro Last Light, qui semblent en retrait de prime abord, mettent en fait en évidence des bogues de jeunesse : une fois le filtrage SSAA désactivé, la version Linux du jeu de 4A Games tourne mieux que la version Windows. Enfin, Dota 2 Reborn est un cas à part. Basé sur le moteur source 2, il n'utilise pas de wrapper : la version Linux est entièrement écrite en OpenGL natif. Cette version est nettement plus performante que la version DirectX sur Windows. Il faut également noter que ces systèmes « passerelle » sont récents sur Linux, et ont bénéficié d'une optimisation depuis leur création. Ainsi, les performances de la première version de Witcher 2 étaient nettement en retrait, et elle avait été accueillie sous les huées.

Dota 2 Reborn est l'un des très rares titres développé en natif sous OpenGL.

Maintenant, et pour revenir sur les exemples de développements rapides et rentables que nous listions au chapitre précédent, il paraît évident qu’ils n’ont pas trouvé le salut dans les solutions que nous venons d’évoquer… Non… En vérité, ils ont profité d’un mouvement encore jeune mais qui devrait s’accentuer dans les prochaines années : l’intégration native de la composante Linux dans les moteurs modernes, que ce soit pour la création (existence d’un client Linux) ou pour l’exportation (compilation du jeu). Tout ne se fait évidemment pas en un clic, mais cette avancée facilite grandement les développements multiplateformes. En général, ces moteurs ne nécessitent aucun code spécifique aux systèmes cibles, à moins que le développeur ne fasse intervenir des intergiciels (middleware), des modules externes ou n'altère le code source. De nombreux moteurs sont désormais compatibles Linux, avec des portages en cours ou à venir qui se multiplient : Unity (Armikrog, Pillars of Eternity), Unreal Engine (ARK : Survival Evolved, Street Fighter V), CryEngine (Homefront  : The Revolution, Kingdom Come : Deliverance)…

Le moteur Unity a permis de proposer un portage Linux "Day One" de Wasteland 2

C’est d’ailleurs ce qu’il ressort clairement des exemples proposés ci-dessus. Les développeurs de Kona, en passant par un moteur Unity multiplateforme, ont ainsi pu gérer l’adaptation de leur jeu sur Linux ET Mac en moins d’une journée (Fait intéressant, les développeurs n'utilisent pourtant pas Linux au quotidien !). Ce constat est à rapprocher des déclarations des développeurs de Door Kickers, pour lesquels le portage du moteur maison a pris seulement 2 jours de développements, et 3 jours de tests/mises à jour dans les mois suivants.

Facilité technique, rentabilité… Sans prétendre que Linux peut aujourd’hui faire de l’ombre à Windows en tant que plateforme de jeu, on peut cependant raisonnablement affirmer que l’OS libre dispose maintenant de bases solides pour assoir son développement en la matière. Toutefois, si le support de Linux semble avoir bien progressé sur les moteurs de jeu « commerciaux », il n’arrive toujours pas à percer du côté des moteurs propriétaires : Johan Anderson, directeur technique sur le moteur Frostbite (EA), avait ainsi réaffirmé fin 2015 que la prise en charge de Linux restait plus qu’improbable, et il en est sans doute de même du côté d’Ubisoft (Anvil Next, Dunia Engine), ou de Square Enix (Glacier Engine II, Crystal Tools). Et ces choix sont bien entendu compréhensibles : si des projets comme Door Kickers ou Pillars of Eternity peuvent trouver des leviers de rentabilité malgré la faible base d’utilisateurs Linux, ce n’est absolument pas le cas des grosses productions, qui visent des chiffres de ventes bien supérieurs à cette fameuse base, et qui doivent par ailleurs absorber des coûts de structures et de développement plus importants.

A priori, peu de chances de voir un Battlefield 1 arriver sur Linux pour le moment

Au mieux, Linux reste dans ce cas de figure une option de portage a posteriori, si ce dernier n’est pas trop complexe, et si le jeu a déjà trouvé sa rentabilité sur d’autres plateformes. Quant à savoir si le système d’exploitation sera capable de dépasser cet état de fait, pour s’engager dans une nouvelle phase de croissance, plus orientée vers des titres triple A, c’est tout le problème posé par l’échec de l’opération Steam machine de Valve. Cette dernière, si elle avait été couronnée de succès, aurait pu permettre une certaine forme de généralisation de la plateforme Linux, attirant petit à petit des plus gros développeurs. Malheureusement, c’est un rôle qu’elle ne jouera pas, à l’évidence.

Sachant cela, et au regard des arguments que nous avons avancé plus haut, Linux ne pourra compter à l’avenir que sur un seul levier : aller vers encore plus de simplification des portages. Une simplification qui demandera que de profonds changements interviennent dans les équilibres qui régissent les API graphiques actuellement. Une possibilité qui servira de conclusion à ce dossier, dans la page qui suit.