Les jeux en HTML5 deviendront-ils une réalité

J’ai déjà eu l’occasion de vous parler des rich internet games, mais je ne crois pas avoir abordé le cas des jeux utilisant uniquement HTML et javascript. Il y avait déjà un certain nombre d’expérimentations (à l’image du JS-Wars sur Chrome Experiments) mais deux projets récents me font dire que l’idée n’est pas si folle.

Il y a tout d’abord Akihabara, un framework permettant de développer des jeux à l’ambiance très rétro à l’aide de différentes librairies. Le résultat est surprenant mais fonctionne parfaitement comme en témoignent les démos (ne pas appuyer sur “a” mais sur la touche “z”), Leave Me Alone un jeu de plateformes :

Exemple de jeux de plateforme avec
Exemple de jeux de plateforme avec Akihabara

Solitude, un Shoot’Em Up :

Exemple de Shoot'Em Up avec Aki
Exemple de Shoot'Em Up avec Akihabara

Ou encore Capman, un clone de Pac-Man :

Exemple de Pac-Man avec Akihabara
Exemple de Pac-Man avec Akihabara

Quel est l’intérêt de réaliser des jeux en HTML5 ? La portabilité tout simplement ! Car même si ces jeux ne fonctionnent que sur les navigateurs récents (donc pas sur IE), ils fonctionnent très bien sur les smartphones iPhone ou Android. Certainement pas de quoi faire trembler les gros éditeurs comme Gameloft ou ngmoco, mais de quoi réfléchir avant de se lancer dans le développement d’applications pour des types de jeux ne nécessitant pas de grosses ressources comme les RPG textuels.

Autre exemple avec le Aves Engine, un framework de développement avec un solide couche métier : Aves, HTML5 Game Engine with Social Built In.

De la 2,5D en HTML5 avec le Aves Engine
De la 2,5D en HTML5 avec le Aves Engine

Le moteur du framework gère de façon native les cartes en 3D isométrique, la gestion de collisions… Pas de démo jouable pour le moment mais une vidéo très impressionnante :

Là encore l’idée n’est pas révolutionner le marché du jour au lendemain (pour cela je m’intéresserais plutôt au futur Unity 3) mais plutôt de réfléchir au recours systématique à Flash. Peut-être que le déploiement de certaines catégories de jeux comme les Point & Click pourraient être facilité avec ce type de framework.

Encore une fois je ne suis pas en train d’annoncer la fin de Flash au profit d’HTML5 mais plutôt le début d’une refléxion sur une approche low tech du jeu en ligne. À suivre…

MàJ (02/07/2010) : L’éditeur allemand Dextrose vient de racheter l’Aves Engine pour construire le premier moteur de jeu complet en HTML5 (cf. Dextrose, the browser-based game engine, acquires Effect Games).

Silverlight aurait dépassé les 50% de taux d’installation

Le moins que l’on puisse dire est que les équipes de Microsoft ne sont pas très loquaces sur les statistiques d’installation de Silverlight. Pourtant il semblerait que le plug-in de Microsoft progresse à un rythme constant (à raison de 2% supplémentaires tous les mois) et que la barre symbolique des 50% de taux d’installation ai été dépassée en Mars 2010. C’est en tout cas les chiffres que donne le site RIAStats :

Taux d'installation des différentes technologies RIA
Taux d'installation des différentes technologies RIA

Ces statistiques ne sont pas à prendre à la légère car elles sont fondées sur les données remontées par plus de 26 millions de navigateur dans 102 pays : Presque 55% pour Silverlight (versions 2 et 3) et plus de 98% pour Flash (versions 8 à 10). Un taux d’installation pas tout à fait confirmé par le site StatOwl (qui annone un peu plus de 43%) mais avec un rythme de progression plus important.

Impossible de vérifier ces chiffres auprès de Microsoft qui ne semble pas vouloir communiquer là-dessus (peut-être attendent-ils une confirmation formelle du dépassement de la barre des 50% ?), contrairement à Adobe qui exhibe fièrement ses chiffres : Flash Player penetration et Flash Player Version Penetration.

Alors bien sûr la grande question est : À partir de quand une technologie est-elle suffisamment bien déployée pour être viable ? Je ne pense pas qu’il faille axer la réflexion sur les chiffres mais plutôt sur l’engagement de l’éditeur : Microsoft est une maison solide qui a la ferme intention de s’installer durablement sur le marché des RIA / RDA avec Silverlight et ils mettront les moyens pour y parvenir. Il est vrai que les 99% de pénétration de Flash en font rêver plus d’un (ce taux est par exemple supérieur à celui de Javascript, et oui !), mais les possibilités de Silverlight en matière de Vidéo et son portage sur la gamme Windows Phone en font une technologie incontournable.

Je dirais même plus : Heureusement que Microsoft est là pour stimuler le marché car il ne faut pas compter sur Sun et son JavaFX (étonnamment silencieux) ni sur Curl (en silence radio depuis l’année dernière). Peut-être va-t-il également falloir observer de près ce que la communauté va faire avec HTML5 et SVG. Je ne suis pas persuadé que ce couple soit une solution réellement crédible pour le moment, mais il ne faut pas non plus sous-estimer la capacité d’une communauté à promouvoir des alternatives libres / standardisées.

Vous êtes plutôt application mobile ou site web optimisé pour les smartphones ?

Alors que la barre des 500.000 unités vendues vient d’être franchie par l’iPad, je m’interroge sur l’impact que cette machine pourrait bien avoir sur le marché, ou plutôt sur les éditeurs de sites web.

Tout à commencé avec l’iPhone : Belle machine, système d’exploitation robuste et certainement la meilleure expérience de surf sur le web en situation de mobilité (du moins à la date de sa sortie). Résumons une longue argumentation en disant que pour un usage d’appoint, l’iPhone et son Safari remplit largement sa promesse. Bien évidemment vous ne passeriez pas des heures à surfer sur le web avec votre iPhone car ce smartphone n’a pas été conçu pour ça. D’autant plus qu’il existe une myriade d’applications proposant une expérience plus riche et plus immersive. OK, jusque là tout va bien.

Prenons maintenant le cas de l’iPad : Belle machine, même système d’exploitation, même navigateur. Surfer sur le net avec un iPad veut donc dire être soumis aux mêmes limitations (pas de Flash, pas de survol avec la souris). Là c’est tout de suite un peu plus gênant dans la mesure où l’iPad est vendu comme  l’avenir de l’informatique domestique, le remplaçant de votre ordinateur (avec son clavier et sa souris).

Passée la première prise en main (où l’impression générale est très bonne), l’iPad se révèle au final un peu décevant pour surfer le web, pour les limitations que nous lui connaissons. Réponse d’Apple : “C’est la faute des éditeurs de sites qui ne sont même pas foutus de sortir des version iPad-ready“.

Exemple de site optimisé pour l'iPad
Exemple de site optimisé pour l'iPad

Nous avons mis une dizaine d’année à nous débarrasser de la logique du “Site optimisé pour XYZ et Apple voudrait nous faire replonger dedans ? Oui et non. Oui parce qu’une compatibilité HTML5 suffit pour être “iPad-ready” (ils se cachent donc derrière l’argument des standards web). Non car les éditeurs ont aussi la possibilité de sortir une application (en fait un widget).

La tentation est grande de se lancer dans la confection d’une application pour plusieurs raisons :

  • L’expérience utilisateur est parfaitement maîtrisée ;
  • L’attention de l’utilisateur est concentrée ;
  • Elle est disponible en mode déconnecté.

Par contre il y a des contreparties à ne pas négliger :

  • Vous devez soit apprendre le bon langage (Objective C), soit sous-traiter la réalisation à un spécialiste ;
  • Vous devez faire approuver votre application pour qu’elle intègre l’App Store d’iTunes ;
  • Vous devez vous plier au mécanisme de mises à jour imposé par Apple ;
  • Vous devez vous assurer que l’application est compatible avec le format iPad ;
  • Vous devez développer autant de version de l’application que vous ciblez de smartphones.

Autant vous dire qu’il faut y réfléchir à deux fois avant de lancer votre application iPhone / iPad car il y a des coûts cachés. C’est effectivement une très bonne chose que d’être présent sur l’un des panneaux de l’écran d’accueil de l’iPhone / iPad (qui fonctionne comme des bookmarks), mais le ROI est loin d’être probant.

Autant le développement de widgets et autres micro-applications a été grandement simplifié / viabilisé par des technologies comme AIR, autant pour les applications mobiles tout reste à faire. D’autant plus que le marché des smartphones évolue vite (iPhone OS still dominates mobile web; Android on the way up) et que celui des touchbooks devraient aussi être amené à bouger avec l’arrivée de machines propulsées par Android.

Je suis intimement persuadé que ce phénomène de widgetisation du web (“développez une application pour mes machines et tout se passera bien“) est néfaste car elle disperse les ressources et donc les budgets des annonceurs. Je suis beaucoup plus partisan d’une approche raisonnée qui consiste à développer une version smartphone d’un site web plutôt que de se lancer dans le développement de x versions d’une application mobile (pour iPhone, Android, Symbian, BlackBerry…).

Cette solution permet de bien mieux maîtriser les coûts de développement, de s’affranchir des contraintes de déploiement / mises à jour, de cibler un panel bien plus large de smartphones, de capitaliser de l’expérience sur une technologie pérenne (HTML 5). Illustration avec la version mobile de Twitter :

La version mobile de Twitter
La version mobile de Twitter

Même si les possibilités par rapport à une application sont restreintes, le ROI est imbattable. Peut-être que la combinaison gagnante est de proposer une version mobile de votre site web ou service en ligne et de proposer une application payante avec des services à valeur ajoutée (la grande question étant : “Qu’est-ce qu’un service à valeur ajoutée“).

Donc au final, je trouve cette idée de sites web “iPad-ready” complètement rétrograde. Mais transposée en “Smartphone-ready” ou en “Touchbook-ready“, là ça devient beaucoup plus intéressant (surtout avec une redirection automatique vers la bonne version).

Bon en fait la combinaison réellement gagnante serait d’avoir un site web avec des versions smartphone / touchbook et une application mobile payante mais reposant sur un code-source unique. C’est en quelque sorte ce que promet Adobe avec son Open Screen Project et la possibilité dans CS5 de compiler une application Flash en une application iPhone. Le nirvana des Rich Mobile Applications, nous y sommes presque !

À moins que tout ceci ne soit remis en cause avec le lancement ce soir de la V.4 de l’iPhone OS…

Mise à jour (9 avril 2010) : Voilà c’est fait, Apple vient d’inclure une close dans sa licence pour interdire l’utilisation du compilateur Flash de CS5. D’un côté je me dis qu’il faut des mesures extrêmes comme celle-là pour garantir une expérience utilisateur cohérente sur l’iPhone, d’un autre je pense que celà complique la tâche des annonceurs et des éditeurs d’applications. Les produits d’Apple et d’Adobe font partie de mon quotidien professionnel depuis des années et je m’attriste de voir ce conflit s’envenimé…