Les différentes licences des API utilisées pour développer un jeu

Les différentes licences des API utilisées pour développer un jeu

 

 

Gachot | Guillaume | 10/05/2018

 

 

Sommaire

 

  1. Introduction et définition des API

 

  1. L’émergence des API

 

  1. Le cas de la 3D : quand les API dictent l’évolution du matériel

 

  1. Le retour au bas niveau : la revanche de Khronos ?

 

 

 

De quoi l’API est le nom ?

Une API, c’est une Application Programming Interface. Expliquons chacun de ces termes et leurs relations.

  • Application : une application, c’est un service accessible par un humain ou un programme informatique via internet. Quelques exemples d’applications : un portail open data, un réseau social..
  • Programming : un programme est un ensemble de fonctions informatiques écrites par un développeur (ou une intelligence artificielle, mais c’est un autre sujet) qui exécute des tâches à sa place. Par exemple, si je dois transformer des adresses postales en coordonnées géographiques, je peux le faire à la main. Où je peux écrire un programme pour le faire à ma place.
  • Interface : Une interface est la porte d’entrée à travers laquelle le programme pourra interagir avec l’application. L’utiliser requiert souvent un comportement codifié et attendu.

C’est à travers cette interface, qu’un programme pourra interagir avec une application.

En français, une API se traduit par Interface de Programmation Applicative (IPA donc).

 

Et ça fait quoi une API ?

Ah la bonne question ! Et la réponse est : une foule de choses ! Mais nous y reviendrons après, pour le moment, parlons de comment cela fonctionne.

Une API, c’est une abstraction qui permet d’utiliser un service sous-jacent.

Une quoi ? Une abstraction. Un exemple de tous les jours devrait nous aider.

Portrait de l’API en machine à laver

Prenons un fournisseur d’eau :

  • le fournisseur produit et distribue un service : l’eau
  • le fournisseur utilise une infrastructure pour assurer la distribution : aqueducs, tuyaux, robinets d’arrivée d’eau…

À ce fournisseur correspond un consommateur :

  • le consommateur a besoin du service (l’eau) pour faire fonctionner son lave-linge
  • le lave-linge est vendu avec un flexible d’alimentation dont l’embout est standardisé
  • le consommateur relie son lave-linge au fournisseur en vissant le flexible au robinet d’arrivée d’eau.

Sans ce robinet, le consommateur aurait dû sortir son fer à souder pour relier « en dur » sa machine au tuyau (et gâcher une bonne partie de son week-end). Ce robinet est une abstraction. Il fait office d’interface entre le tuyau et la machine à laver.

Le robinet (l’API) est une abstraction du service nécessaire. Il permet à une machine à laver (le programme) de consommer de l’eau (une application) dans des conditions pré-définies et standardisées (embout standardisé).

De la même façon qu’un particulier délègue la production et l’acheminement d’eau à une entreprise, « les APIs permettent aux développeurs de déléguer le service qu’ils consomment« .

 

Les API, un pouvoir commercial incontestable ?

Les Interfaces de Programmation peuvent être mises en place par :

  • Des bibliothèque logicielle,
  • Certains services web,
  • Les systèmes d’exploitation.

Ces différents types d’applications logicielles vont choisir d’ouvrir leurs données au public en leur donnant un accès simplifié. Dans cette perspective, ces différentes applications vont créer une des méthodes de programmation par défaut.

L’API est par conséquent un atout indéniable dans la commercialisation de ces acteurs qui vont mettre à disposition leur donnée à un public élargi. En quelque sorte, ce système de mise à disposition d’une interface de programmation va largement participer à l’élargissement de son public initial. On peut considérer que les acteurs qui choisissent d’exploiter les données d’une application (exploitation facilitée par l’API de l’application) vont par ce biais collaborer avec cette application et son système ; Il s’agit donc d’un partage gagnant-gagnant.

 

Les API un degré d’abstraction des développeurs

Pour un développeur, les Interfaces de programmation se traduisent par un niveau d’abstraction supplémentaire. C’est-à-dire qu’ils vont pouvoir utiliser les fonctions préparées par l’API, sans devoir comprendre le fonctionnement global de l’application. Ces API sont reliées aux bibliothèques de données de l’application initiale, mais elles sont indépendantes de l’application de base et peuvent être utilisées sur d’autres plateformes web.

Ces API vont donc permettre d’utiliser un ensemble de fonctions prêtes à l’emploi, définissant des méthodes de départ qui vont pouvoir être utilisées pour programmer des fonctionnalités plus complexes.

Par exemple, certaines applications de type réseaux sociaux vont mettre en place des protocoles permettant aux utilisateurs de se connecter à l’application. Cette connexion dédiée au réseau social va ainsi pouvoir être utilisée en dehors de l’application pour se connecter sur une autre plateforme.

Comprendre les API par l’absurde : le conducteur et sa voiture

Pour mieux comprendre l’étendue et l’utilisation des Interfaces de Programmation, prenons un exemple : Pour conduire, il n’est pas nécessaire de comprendre l’ensemble des mécanismes de la voiture. La voiture met à disposition des utilisateurs des fonctions toutes prêtes qui vont permettre son utilisation (les essuie-glaces, le levier de vitesse…). Les API sont des fonctions dédiées aux développeurs pour leur fournir des outils de programmation. Grâce à ces méthodes de base, les développeurs vont pouvoir utiliser des variables/méthodes fournies par l’application et programmer des fonctions plus complexes.

 

Les API et les langages de programmations

Une API définit des fonctions pour un ou plusieurs langages informatiques spécifiques. Normalement, n’importe quel langage web orienté objet (JavaScript, java, C++…) pourrait être utilisé pour récupérer les données d’une application. Les applications qui mettent en place une API vont mettre en place des méthodes de base dans un langage spécifique afin de faciliter l’utilisation de ces données.

Il existe deux configurations d’API :

  • Il peut exister des versions différentes d’une API pour différents langages informatiques.
  • Certaines API vont au contraire choisir d’indiquer des variables et méthodes d’utilisation sans pour autant inverstir un langage spécifique. Dans ce cas, les applications vont définir un langage de structuration des données qui devra être utilisée par défaut (ex : XML, AJAX…).

Toutes les API vont recommander un ou plusieurs langages de programmation qui selon eux est le plus adapté pour manipuler ses données.

 

Les API disponibles au sein du langage java :

« Cartographie » des API pour les applications Windows Modern UI :

 

 

Cette plus grande facilité de programmation offerte par ces API système n’est toutefois pas sans contrepartie : très logiquement, le portage d’un logiciel devient plus compliqué, puisqu’il faut en réécrire toutes les portions utilisant des API système (à noter que dans le monde Unix, il existe une API système standardisée, l’API POSIX, qui permet le portage d’un système à l’autre, et même, dans une certaine mesure, vers Windows, qui supporte une partie de l’API POSIX depuis l’arrivée de Windows NT). Par exemple, si un développeur opte pour la solution facile du stockage des paramètres de son logiciel dans la base de registre via l’API Windows, il devra mettre en place un autre système de stockage s’il veut porter son application sous Linux.

 

Des API « indépendantes » ont également rapidement fait leur apparition. Ni liées à un langage de programmation, ni liées à un système d’exploitation, elles sont souvent très spécialisées, comme par exemple les API permettant de développer des plug-ins pour une application, de manipuler des grands nombres, ou encore des API d’abstraction du matériel destinées à faire des rendus 3D sans avoir à se soucier du type de carte graphique utilisée (HAL, Hardware Abstraction Layer).

 

L’utilisation d’API a également un autre avantage, au-delà du gain de temps dans le développement : l’utilisation de bibliothèques de fonctions partagées a permis une certaine uniformisation des interfaces des logiciels. Ainsi, en utilisant les mêmes API pour présenter les données ou pour demander des entrées, deux programmes présentent une interface similaire à l’utilisateur, ce qui permet de simplifier leur prise en main (l’utilisateur pouvant plus facilement prendre ses marques) et donne une cohérence d’ensemble aux différentes applications installées sur un ordinateur. Avec un peu d’habitude, il est même parfois possible de reconnaitre quelles API ont été utilisées pour l’interface d’un logiciel.

 

Google doit sans doute une partie du succès de ses produits aux nombreuses API :

 

 

Plus récemment, c’est au niveau des services en ligne qu’on a pu observer une explosion du nombre de nouvelles API. Les services les plus populaires proposent en effet quasiment tous une API, accessible via des requêtes web (WebService, REST…), pour permettre à des développeurs de créer facilement des applications s’interfaçant avec ces services. Ainsi, on trouve par exemple des applications en ligne de commande permettant d’automatiser l’envoi de photos vers un compte Google Photos via les API du géant de la recherche.

 

L’API Unity permet de cibler toutes les plateformes majeures quasiment sans ada :

 

Notons enfin qu’avec le temps, le concept d’API a été poussé à un tel niveau, que l’on trouve aujourd’hui des API … servant à utiliser d’autres API ! Cette architecture se justifie par le besoin de réaliser des applications multiplateformes s’intégrant convenablement avec les différents OS sur lesquelles elles sont portées. Comme chaque plateforme a ses propres API systèmes, le portage nécessiterait en théorie de réécrire toutes les portions de l’application ayant besoin d’accéder aux API systèmes. Et c’est là qu’interviennent les API intermédiaires : elles proposent des fonctions équivalentes à celles proposées par les principales API systèmes et implémentent ensuite ces fonctions en utilisant les API systèmes.

 

Dès lors qu’il se limite aux fonctions de ces API intermédiaires, le développeur pourra ainsi intégrer son application sur tous les systèmes sur lesquelles ces API ont été portées, sans qu’il n’ait rien à réécrire. Parmi ces API destinées à faciliter le portage, on peut citer par exemple Qt, utilisée par de nombreuses applications, ou encore, dans le monde du jeu vidéo, l’API du moteur de jeu Unity, qui permet notamment une abstraction de l’API 3D du système (Direct3D sous Windows, OpenGL sur la plupart des autres OS), et qui est aujourd’hui très populaires chez les développeurs de jeux indépendants, à qui il facilite la mise à disposition de jeux sous Android, iOS, Linux, OS X et Windows. Ces facilités profitent aujourd’hui largement au monde du jeu vidéo, en dynamisant la scène indépendante, ce qui contraste fortement avec l’époque des débuts de la 3D, où les limitations des API dédié, encore balbutiantes, rendaient souvent les choses très compliquées et obligeait bien souvent les développeurs à faire plusieurs versions distinctes de leur code.

 

 

Au début de la 3D sous Windows, le choix des API était en effet particulièrement important et conditionnait la capacité du jeu à utiliser ou non toutes les capacités de la carte 3D. Il n’était alors pas rare qu’un jeu soit proposé avec le support de plusieurs API, en laissant l’utilisateur choisir quelle version installer dans le cas où son système aurait été compatible avec plusieurs d’entre elles. En effet, avant que Direct3D et, dans une moindre mesure, OpenGL, ne s’imposent comme API de référence pour la 3D, chaque constructeur de carte graphique avait ses API, propres à son matériel. Les jeux étaient donc souvent développés dans une version Direct3D, compatible avec toutes les machines, mais exploitant à l’époque très peu, voire pas du tout, l’accélération matérielle, et dans une version spécifique à telle ou telle marque de carte graphique.

 

Le jeu POD (1997) était décliné en 4 versions : ATI, rendu logiciel (avec CPU MMX), S3 et 3dfx :

La plus célèbre à l’époque était l’API Glide, un dérivé d’OpenGL, propre aux cartes 3dfx. On reconnaissait son usage à un logo 3dfx en 3D s’affichant au lancement du jeu. Bien plus évoluée que les premières versions de Direct3D, Glide était la chouchoute des développeurs de jeux, d’autant plus qu’à l’époque, les cartes 3dfx étaient très largement répandues chez les joueurs, du fait de leur capacités bien supérieures à la concurrence. Elles étaient par exemple les premières à savoir lisser les textures, offrant ainsi un rendu beaucoup plus propre, avec une différence flagrante entre la version Direct3D (sans lissage dans les premières versions) et la version Glide d’un même titre.

 

À gauche, rendu Direct3D sans accélération matérielle, à droite rendu Glide avec une carte 3dfx :

Mais avec la montée en puissance d’NVIDIA et d'ATI (rachetée depuis par AMD), il est devenu de plus en plus compliqué pour les développeurs de jeux d’utiliser les API propriétaires des fabricants de cartes graphiques, et ce sont deux API 3D indépendantes du matériel qui ont petit à petit conquis le marché : Direct3D, exclusivement sous Windows, et OpenGL disponible sur la plupart des plateformes. La première est devenue très largement majoritaire sur le secteur du jeu vidéo PC, tandis qu’OpenGL a conservé l’avantage dans le monde de la 3D professionnelle et sur la majorité des autres systèmes.

 

Direct3D a pris une telle importance qu’il fait désormais quasiment office de « roadmap » pour les fabricants de GPU. Puisque les jeux s’appuient massivement sur Direct3D, les principaux fabricants travaillent en effet main dans la main avec Microsoft pour définir les spécifications des futures versions de Direct3D, et donc les fonctions que leurs GPU vont devoir supporter, car il serait peu utile pour eux d’avancer dans leur direction et de voir leurs produits sous-exploités par les jeux, faute de support par Direct3D. Ce n’est donc qu’une fois les spécifications d’une nouvelle version de Direct3D arrêtées que les constructeurs passent à la conception de GPU implémentant ces fonctionnalités, et qui seront ensuite présentés dans les communications comme des GPU compatibles avec telle version de DirectX (le grand ensemble d’API multimédia dont Direct3D fait partie). Les constructeurs continuent tout de même de proposer quelques fonctions propriétaires, soit pour préparer le terrain à l'arrivée d'une future version de DirectX, soit pour proposer quelques spécificités dans des jeux « optimisés » pour leurs GPU (via des programmes de coopération avec les studios de développement), mais ces fonctions sont rarement essentielles.

 

OpenGL ES règne en maître sur le monde mobile... Pour l'instant :

 

Cette domination de Microsoft sur les API 3D pourrait toutefois toucher à sa fin grâce à l’explosion du marché mobile, dont Microsoft est quasiment absent. Le support de Direct3D est déjà vu comme une fonctionnalité très secondaire chez les fabricants de GPU mobile, qui basent leur roadmap sur OpenGL, ou plus précisément, sur OpenGL ES (Embedded Systems), un sous-ensemble d’OpenGL dédié aux mondes de l’embarqué et du mobile, et l’arrivée de nouvelles API pourrait accélérer le mouvement.

 

Au Clair de la Tech : Le retour au bas niveau : la revanche de Khronos ?

 

Cette domination de Direct3D est donc un gros problème pour tous les développeurs souhaitant réaliser des jeux multiplateformes. Il est quasiment indispensable d’utiliser Direct3D pour la version Windows et Xbox, car les pilotes OpenGL sont souvent à la traine niveau performances, et OpenGL pour toutes les autres plateformes, sur lesquelles Direct3D n’est pas nativement disponible.

Pour simplifier cette opération, certains ont recours à un empilement d’API. Ainsi, plutôt que d’utiliser directement Direct3D dans le code de leur jeu, ils vont passer par une API 3D intermédiaire (comme celle fournie par exemple par le moteur Unity), cette API se chargeant ensuite de « traduire » ses propres fonctions en appels à des fonctions de la principale API 3D disponible sur le système. S’il est pratique pour le développement, cet empilement n’est pas bon pour les performances, cette couche de traduction imposant forcément du temps de calcul en plus.

 

Wine implémente les API Windows sur les API Unix pour permettre leur exécution :

Une autre approche, toujours par empilement d’API, peut consister à utiliser Direct3D dans le jeu, et à intercaler sur les autres plateformes une API intermédiaire exposant les mêmes fonctions que l’API Direct3D, mais en les implémentant via des fonctions OpenGL. Moins performante et souvent plus sujette aux bugs, cette approche est généralement réservée aux jeux dont la décision de portage intervient tardivement dans le cycle de développement. La société TransGaming s’est par exemple spécialisée dans ce type de portages, en s’appuyant sur le projet Wine, une implémentation open-source sous Unix des principales API Windows, y compris Direct3D.

 

Mantle, un nouveau modèle d’API pour mieux tirer parti des GPU :

 

Pour éviter ces empilements d’API, il faudrait privilégier des API indépendantes du système, comme OpenGL, mais à condition que leur implémentation dans les drivers Windows soit efficace. Et justement, Khronos, le groupe de travail à l’origine d’OpenGL a peut-être l’occasion de prendre sa revanche contre Microsoft et de refaire son retard dans les années à venir, grâce à un nouveau mouvement initié par AMD il y a trois ans avec l’API Mantle : le retour à des API 3D plus « bas niveau », et limitant autant que possible le travail réalisé par le CPU, pour le décharger au maximum vers le GPU. Avec les API 3D classiques, le GPU est en effet souvent limité par le CPU, et c’est d’autant plus vrai lorsque plusieurs couches d’API sont empilées, toutes les couches intermédiaires étant gérées exclusivement par le CPU. Khronos a largement repris les travaux d’AMD pour mettre au point sa propre API 3D bas niveau, qui a été publiée en version 1.0 il y a quelques jours : Vulkan.

 

Vulkan, futur challenger du champion DirectX de Microsoft ?

 

 

Si Microsoft a bien entendu lui aussi pris le train en marche et repris des concepts de Mantle dans son Direct3D 12, Vulkan pourrait prendre l’avantage grâce à son support matériel bien plus large et à son caractère multiplateforme, avantage de poids dans un marché du jeu vidéo qui n’est plus aussi centré sur Windows qu’il y a dix ou vingt ans. En effet, alors que Direct3D 12 est réservé à des cartes graphiques relativement récentes et à des PC sous Windows 10, Vulkan est rétro compatible avec tous les GPU OpenGL 4 et OpenGL ES 3.1 et est d’ores et déjà disponible sous Android, Linux et Windows. Concrètement, ces prérequis correspondent à des GPU dont certains sont sortis il y a près de 10 ans, comme par exemple les GeForce de la série 8000 ou encore les toutes premières Radeon HD (pour l’instant le support par les drivers est toutefois limité chez la plupart des constructeurs aux GPU de moins de quatre ans, ce qui réduit quelque peu la portée de cette rétrocompatibilité).

 

Direct3D 12 met aussi l’accent sur la performance, en limitant l'impact du code de l’API :

 

Il s’agit donc là d’une occasion en or pour Khronos d’inverser la tendance, et de faire de Vulkan la nouvelle API de référence pour la 3D, avec une solution performante et compatible avec tous les OS. Mais Microsoft ne va probablement pas se laisser faire, d’autant qu’il a encore quelques atouts dans sa manche, dont le fait que Direct3D est un composant d’une API bien plus large (DirectX), très utilisée et couvrant aussi d’autres domaines (le son, la gestion des manettes de jeu, etc…), alors que les autres API de Khronos Group sont plus minoritaires, seul OpenGL et OpenCL ayant tiré leur épingle du jeu. Il sera donc intéressant de garder un œil sur ces deux acteurs dans les prochains temps, pour voir si Khronos parviendra à détrôner Microsoft, et en espérant que cette concurrence relancée profite à tout le monde et qu’elle se fasse loyalement et sans coup bas (Microsoft a un certain passif en la matière, notamment avec une forte baisse des performances OpenGL sous Windows lors du passage de XP à Vista…). Khronos a d’ores et déjà obtenu une première victoire, en remportant l’adhésion de Valve, qui voit en Vulkan une bonne occasion de pousser SteamOS auprès des joueurs.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *