Ajax.

[Seren]

Après voir fait un peu de recherche et de brainstorming sur les solutions techniques , j'ai l'impression que Ajax est particulièrement adapté pour le développement de jeux php, au moins pour la partie dynamique.

Avantages :
- Permet de ne recharger qu'une partie d'une page à la fois à la suite d'une action. (Example carte.) et donc limite la consomation de bande passante.
- la mise en forme des données est effectuée côté client à partir d'un objet JSON. Inutile de transmettre toutes les balises html. Encore un gain de bande passante.

Inconvénient :
- Des fonctions JS supplémentaires à charger. (potentiellement jusqu'à quelques Ko par pages.)
- Complexité accrue du code.

Est-ce qu'il y a d'autres aspects que j'ai oublié et qui sont important à envisager avant de se lancer ?

Sinon combien parmi vous utilisent Ajax pour une partie de leur site ? Est-ce que vous pouvez évaluer le gain apporté par Ajax ?

[LoK]

J'utilise AJAX pour mon projet, je trouve en effet que cet ensemble de technologies se prête très bien aux jeux en lignes.

Les principaux avantages selon moi :
- Gain de bande passante théorique (on a pas encore pu tester le gain réel) pour les raisons que tu as évoqué.
- Fonctionnalités accrues qui permettent de rendre le site vraiment attractif (peut compenser la "pauvreté" des jeux par navigateurs), améliorer la jouabilité (des temps d'attente considérablement réduits par exemple)...

Les inconvénient sont :
- Un code complexe.
- Des problèmes de référencement.
- La nécessité d'avoir JS activé.
- Le problème de l'accessibilité (compatibilité entre navigateurs), accès aux personnes handicapées...

Pour le code JS à charger à chaque page, je pense que c'est négligeable dans la mesure où le nombre de page est très réduit. Dans mon cas, il n'y aura plus que 2 pages par exemple.

[GreGoire]

Ouais mais au niveau de la complexité du code quand tu regarde par exemple les implémentations de Prototype.js on peut faire du AJAX très simplement vu qu'il permet de faire directement appel à des fonctionalités sympathiques et surtout extremement compatibles !

(J'avais commencé a faire mon propre module et quand j'ai découvert ça, les personnes qui utilisaient des navigateurs comme Safari ou Opera m'ont dit que ça fonctionnait avec)

[Seren]

Dans la même veine j'ai trouvé un truc sympa hier soir.

Plutôt que d'utiliser un prototype.js avec tous les commentaires et autre charactère inutiles, utilisez une version compressé.

http://www.stevekallestad.com/blog/prototy...compressed.html

J'avoue qu'à 60k pour le prototype.js je m'en serais jamais servi, compresser ça fait plus que 25k c'est plut tentant..

Sinon dans le style léger, il y a les moo tools. Un peu moins de fonctionnalité mais des libs de l'ordre de 8 ou 10k.

[zumba]

j'utilise aussi mais j'ai fait mon propre mini framework (et c'est un bien grand mot), un peu hybride mais bcp plus simple à utiliser et debugger : j'envoie directement le html, pas un xml à remouliner, puis je l'injecte dans le innerHtml qui va bien. Finalement un "framework" ajax n'est qu'une implémentation autour de l'objet xmlhttprequest qui comme son nom ne l'indique pas a rien à voir basiquement avec xml.

Concernant les arguments :
- le gain de perf est évident. même la logique y gagne. On fait des applicatifs web, pas des contenus.
- c'est vrai que ca peut être complexe à mettre en oeuvre, je me suis pas mal arraché les cheveux sur la gestion des forms en ajax. Et bien sûr les histoire de compatibilité cross browser c'est l'horreur, en ceci réutiliser une lib "du marché" comme prototype est un gain certain !
- le référencement ? certes mais c'est un faux problème sur un jeu. Un jeu c'est une interface web, un applicatif, quel intérêt d'indexer son contenu ? par contre évidement il faut mettre en frontal un "portail" pour acceder au jeu codé classiquement et optimisé pour le référencement.
- la taille de la lib JS - quand bien même se serait 60k ou est le problème ? justement elle ne sera pas rechargée à chaque requête, non (comme dit lok)? balancée une fois pour toute la session avec la masterpage de ton interface. qui plus est les Js sont stockés en cache. En gros ca revient a balancer un plus gros paquet initial mais après tu regagnes 10 fois ca pendant la session avec un confort accru. Et croi smoi les effets de cache réduisent énormément le chargement initial. Pour ma part j'envoie plus de 400 images à l'initialisation de l'interface et ca ne prend que 3 secondes (en adsl 2+), et jusqu'à 15s en adsl 512. Bon après en rtc certes c'est plus jouable.
- la nécéssité d'avoir JS activé : oui certes mais au dela d'un certain niveau d'ergonomie il faut bien avoir une techno dynamique côté client de toute facon. Js a l'avantage d'être embarqué en standard sur tous les navigateurs. Perso on ne m'a jamais remonté que c'était un pbm.
- l'accessibilité : ça c'est vrai. Les browsers braille notamment doivent avoir du mal à se débrouiller. Je pense que c'est un pbm inhérent à toute page dynamique pas forcément à une page construite avec ajax. Bon après il y a plein d'autres réflexes comme les infobulles systématiques, supporter le changement des polices par le navigateur... Mais dans mon cas il est clair que mon jeu est innacessible aux handicapés.

voilà, oui oui je suis un fan de la techno, je le reconnais !

[Galaan]

Je rejoinds completement Zumba. J'use en j'en abuse et cela dynamise le site au point de pouvoir realiser des effets "real time", ce qui pour un jeu est quand meme tres appreciable.

Je suis pas convaincu que le code soit tellement plus complique sauf si on commence a faire du parsing. Mais si on en arrive la, c'est a mon avis, que le code est deja complique. Sinon reinjecter du html dans des divs formates par le css est vraiment a la porter de tous et permet d'avoir un code bien propre.

Bref je suis aussi un fan et je ne saurai que trop t'encourager dans cette voie.

Galaan

[Haram turval]

En effet. les histoires de parsing autant oublier actuellement.
La seule propriété potable, responseXML merdouille sacrément avec IE7.

Autant donc utiliser responseText qui cause bien moins de problèmes.

Si tu mets juste une zone à jour, change les innerHTML du client.
Si tu dois faire plusieurs changement d'un seul coup, autant renvoyer du code JS que tu évalues. (très pratique aussi pour mettre à jour les variables de la page après un traitement externe dans un fichier php)

Enfin, pour grapiller encore un peu sur les Ko et la bande passante, je spécifie bien le type de mes headers (comme "text/txt" pas exemple) pour éviter de me retrouver avec des entêtes HTTP non nécessaires.

Je suis fan de cette technologie aussi et avec un petit enrobage XML/XSLT, c'est détonnant !