Page Dossier
Le problème de la portabilité, ou le gros choc de simplification…
Le problème de la portabilité, ou le gros choc de simplification…
PC Linux
  • Partager sur :

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

Le problème de la portabilité, ou le gros choc de simplification…

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.

Le problème de la portabilité, ou le gros choc de simplification…

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

Le problème de la portabilité, ou le gros choc de simplification…

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

Le problème de la portabilité, ou le gros choc de simplification…

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.

Mis à jour le 26/05/2016
PC Linux

COMMENTAIRES

Vous devez être connecté pour poster un commentaire.
christophedlr
christophedlr
MP
27 mai 2016, 10:40

Vu que Microsoft est entrain d'intégrer nativement Linux au sein de Windows 10 (déjà la dernière build, actuellement en Alpha) intègre nativement le bash, sh et la plupart des commandes linux (rm, cp, mv, ls...), bientôt l'excuse ne sera plus tenable puisqu'il sera possible de développer nativement sous Linux à partir de Windows et ce, sans utiliser de librairie faisant le lien puisqu'il suffira de développer du linux et se sera déjà pris en charge par Windows.
Pour rappel, Windows 10 intègrera à terme, n'on seulement bash, sh et les outils Linux, mais sera capable d'exécuter des exécutables linux (fichiers ELF, par rapport aux exécutables Windows qui sont des PE) et les bibliothèque dynamiques linux (.so, équivalent des .dll Windows). Ainsi, l'environnement graphique X11 de Linux, sera nativement géré (mais pas forcément installé sur le système cependant) ; hors les ELF Linux sont déjà géré par Mac.

Ainsi, un développement fait sous Windows en utilisant l'API graphique de Linux, serait pleinement utilisable sous Windows, Mac et Linux. Simplement Mac et Linux devant installer X11 (peut être plus compliqué sous Mac), mais sous Windows son installation pourrait être automatiser par le jeu lors de l'installation, si l'environnement n'est pas présent.

Tout comme actuellement les jeux, installes souvent des dépendances (par exemple PhysX si non présent ou trop vieux par rapport à la version demandée par le jeu). Les problèmes s'envolent donc, non pas par une action de Linux, mais par Microsoft qui retourne enfin sa veste et accepte Linux.

Lire la suite...
Serlavis
Serlavis
MP
27 mai 2016, 10:21

En tant qu'ancien utilisateur Amiga, je suis passé naturellement sous Windows en 1998 et j'utilise Linux depuis une quinzaine d'années et je trouve cette analyse très pertinente et juste. Il est certain que si un jour Linux venait à être vraiment apte pour le jeu je n'hésiterais pas à définitivement abandonner Windows car coté applications pour un usage domestique Ubuntu est largement plus facile d'utilisation que Windows.

Bon boulot.

Lire la suite...
Top commentaires
Serlavis
Serlavis
MP
27 mai 2016, 10:21

En tant qu'ancien utilisateur Amiga, je suis passé naturellement sous Windows en 1998 et j'utilise Linux depuis une quinzaine d'années et je trouve cette analyse très pertinente et juste. Il est certain que si un jour Linux venait à être vraiment apte pour le jeu je n'hésiterais pas à définitivement abandonner Windows car coté applications pour un usage domestique Ubuntu est largement plus facile d'utilisation que Windows.

Bon boulot.

Lire la suite...
SOMMAIRE

Le problème de la portabilité, ou le gros choc de simplification…