Jouer avec AJAX I/III

Ajax & développement de jeu : avantage ou inconvénient ?

lundi 28 août 2006 par Arckam

Le but de cette série de trois articles est de vous permettre d’introduire une pincée d’Ajax dans vos jeux. Nous commencerons par voir quels sont les avantages que l’on peut espérer de cette technique. Nous passerons ensuite en revue une (parmi d’autres) vision de l’implémentation d’Ajax. Enfin, le dernier article se penchera sur les frameworks disponibles actuellement sur le net.

Intro

Ajax, Web 2.0, la mode est à l’asynchrone ... Ajax est-il incontournable ? Est-il véritablement intéressant d’utiliser Ajax comme méthode d’échange d’information dans le cadre du développement d’un jeu ?

Petits rappels

AJAX, pour Asynchronous JavaScript and XML est une technique de développement web qui vise à rendre les pages plus ergonomiques. L’objectif est de donner une sensation de réponse instantanée à l’utilisateur. Le principe de base est terriblement simple : échanger de faibles quantités d’information via un appel asynchrone - et en général grâce à du code XML, entre le client et le serveur.

Quand on parle d’Ajax, on entend trois choses :

1. L’utilisation intensive de JavaScript
2. L’utilisation de l’objet XMLHttpRequest
3. L’utilisation du langage XML pour le transfert des informations

Les puristes ajouteront un soupçon de XSLT pour le rendu, mais ce sont des puristes ;-)

Vous l’aurez tous compris, Ajax, comme le DHTML, n’est pas une technologie en soi, c’est le fait d’utiliser un groupe de technologie ensemble dans un but précis.

Utiliser Ajax a des avantages : meilleure gestion de la bande passante, interactivité améliorée, hype pour n’en citer que quelque uns. Cette technique a aussi des inconvénients : diminution de l’accessibilité, mise en péril de l’ergonomie à laquelle l’utilisateur est habitué, temps de réponses non maîtrisés et principe de l’asynchronisme généralement mal assimilés par les programmeurs débutants.

Mise en situation

Mettons-nous dans la peau d’un webmaster lambda. Il développe son premier jeu. Pour simplifier notre propos considérons que son jeu ne compte que trois éléments : des pages plutôt statiques, comme des news, un classement, ou une FAQ. Des pages plutôt dynamiques, comme une carte. Et des pages composées presque exclusivement de formulaires, comme l’administration de compte ou le passage d’ordres.

Comment juger de l’intérêt d’une technologie ? En dehors de l’aspect subjectif « j’implémente parce que j’en ai envie » ou « parce que ça m’amuse », mesurons le degré d’intérêt en fonction de trois critères : l’ergonomie, les performances et la simplicité.

Valeur ajoutée à l’ergonomie générale
Comment l’utilisateur va t-il percevoir ce changement ? Va-t-il avoir la sensation que les « performances » de l’interface sont améliorées ? Va-t-il disposer de nouvelles fonctionnalités qui s’intègrent harmonieusement avec le reste, avec les fonctions par défaut de son navigateur (par exemple avec le bouton Back) ?

Supposons que notre webmaster n’affiche que 5 news. Il pourrait vouloir proposer un lien « Voir les news suivantes », ou un accès aux « archive » avec un calendrier. Sans Ajax le principe est simple, on ajoute un paramètre au script qui affiche la page et on rafraichi la totalité de la page. Avec Ajax on économise l’appel à ce script. On ne rafraichi que le contenu que l’utilisateur demande : les news. Il reçoit sa réponse plus vite, sans le « clignotement » de la page qui se rafraîchi. Attention néanmoins à ne pas le dérouter. Il faut que le changement sur la page soit clair, bien visible.

En ce qui concerne la carte, il est nécessaire de supporter un minimum de scrolling. La solution du rafraîchissement de la page à chaque déplacement est possible, bien sur, mais fort limité tout de même. Sans parler que son jeu aura l’air à la traîne techniquement. Quand on parle de scrolling on pense forcement à maintenir un (ou des) buffer(s). Techniquement, Ajax est bien adapté à ce type d’utilisation. A tout moment il est possible de déclencher le pré chargement d’une partie de la carte de façon invisible. Maintenir le buffer devient plus simple. Le XML se prête aussi à ce type d’utilisation. Le buffer deviendra un ou plusieurs node(s) dont on assurera le rendu via une fonction JS qui va bien.

Reste les pages dotées de formulaires. Nous étions habitués à devoir les valider d’abord côté client, puis à éventuellement demander une correction à l’utilisateur. Depuis fort longtemps nous sommes tous habitué à vérifier nos formulaires une seconde fois côté serveur. Ajax apporte ici deux avantages majeurs :

1. la possibilité de proposer des informations contextuelles (pensez au système d’auto-completion de gmail par exemple).
2. la possibilité de valider le formulaire au fur et à mesure, donnant un feedback plus rapide à l’utilisateur, évitant ainsi la frustration du formulaire refusé.

Bien sur, ça n’exclu pas la vérification côté serveur, mais ici l’intérêt en terme d’ergonomie est énorme, puisque les formulaires sont partout dans nos jeux.

Gain de performances côté serveur
Que va-t-on gagner en définitive ? On peut estimer le gain en fonction du temps d’exécution des scripts. De la répartition des requêtes SQL. Du taux d’utilisation moyen des ressources. Mais globalement ce qui nous intéresse c’est surtout le temps de réponse du site.

Le serveur n’a pas besoin de calculer le rendu de toute la page. Il n’effectue le plus souvent qu’un seul SELECT, pour récupérer les informations demandées par l’utilisateur. L’économie ici est triple :

1. On économise sur les SELECT qu’aurait effectué le serveur si il avait du rafraîchir toute la page, puisque seules les infos demandées sont rafraîchies
2. On économise la bande passante : pas besoin de renvoyer tout le code HTML, mais seulement un petit bout de code XML.
3. On économise sur le rendu : raffinement supplémentaire, le rendu peut-être délégué à une fonction JS, autant d’économie en temps d’exécution PHP.

Ceci dit Ajax peut avoir un effet pervers : la multiplication des requêtes. Il est tentant par exemple d’effectuer un rafraîchissement automatique par polling. Une aide contextuelle dans un formulaire utilisé pour chaque passage d’ordre signifie une requête au serveur web (et potentiellement une requête SQL) à chaque fois. Si la solution peut-être envisageable attention aux ressources qu’elle requiert.

Simplicité de mise en œuvre
Est-il aisé d’implémenter cette solution ? Est-il plus aisé de continuer à utiliser les techniques habituelles de DHTML ? Pourra-t-on la maintenir facilement ? Pourra-t-on facilement l’améliorer ? Considérons pour le moment que notre MJ ne se base pas sur un framework existant.

Soyons réaliste, non Ajax n’est pas simple à mettre en œuvre. Il demande une certaine expérience du développement web, sans doute plus que le DHTML à son époque. Il demande également une grande rigueur dans le code. Il est souvent nécessaire de jongler avec les éléments via leur id’s, de pouvoir modifier le contenu à la volée, en respectant le look&feel du site, d’où le besoin intensif de CSS. Ajax nécessite aussi de bien comprendre le concept d’asynchronisme, d’en connaître les limites et les risques.

Conclusions

Nous approfondirons les points abordés dans la suite, mais d’ores et déjà une réponse s’impose : oui, Ajax peut nous être utile. Le gain d’ergonomie peut-être énorme : assistance au remplissage des formulaire, aide contextuelle, réactivité accrue, meilleure gestion des cartes, autant de domaine ou Ajax excelle. La mise en place demande tout de même un minimum de réflexion. Où l’appliquer, tout d’abord. Quel sera l’impact sur les performances du serveur ? Enfin, la conception même du jeu devra évoluer, on pourra dans un premier temps se contenter d’intégrer Ajax à l’existant, mais pour en tirer vraiment partit il faudra souvent repasser par la case développement. Stay tuned et rendez vous dans le numéro 2...