Discussion :

[Hinault Romaric]

HTML5 est-il adapté pour les jeux sur le Web ?

La puissance et les pièges du langage explorés lors d’un événement parrainé par Google et Microsoft


Le futur standard émergeant du Web HTML5, qui est « présenté comme la technologie devant repousser les limites du Web », a été disséqué lors de l’événement « New Game Conference».

Parrainé par Google et Microsoft, «New Game Conference» est le premier événement HTML5 pour les développeurs de jeux, qui s’est déroulé à San Francisco.

Les sessions qui ont été présentées lors de la conférence ont permis d’explorer à partir d’exemples concrets, la construction des jeux HTML5 en utilisant Canvas, WebGL et JavaScript. Le port des jeux natifs iOS sur le Web a été également à l’ordre du jour.

Il en ressort que le HTML5 serait de plus en plus adopté, avec l’apparition des nouveaux outils devant faciliter le développement. « Ce que nous voyons est un flot de nouveaux outils qui abaissent les barrières pour l’écriture du code HTML5 par les développeurs Web », note Richard Hilleman, directeur de « creative officer of game maker Electronic Arts » et conférencier principal de New Game Conference.

Le support des applications HTML5 serait également effectif sur la plupart des navigateurs. «Plus de 50% des navigateurs du marché peuvent maintenant exécuter la version HTML5 du célèbre jeu Angry Brids », remarque Advocate Seth Ladd développeur chez Google.

Google essaye de faire du Web une plateforme de jeux avec notamment sa galerie Chrome Web Store et son projet Native Client qui permet d’exécuter du code natif dans le navigateur. « Si le Web a vraiment gagné, il n’a commencé à gagner que récemment […] et l’ampleur de cette victoire continue d’être débattue » conclut Advocate Seth qui voit les applications Web remplacer les solutions natives.

Malgré l’enthousiasme des participants pour le HTML5, l’entreprise Quimby, de par son expérience pour le développement des Jeux HTML5, émet quelques réserves pour les solutions mobiles. « Le message que reçoivent les consommateurs sur HTML5 est qu’il fonctionne partout. Ce n’est pas fondamentalement vrai » note l’éditeur.

Quimby estime que pour cibler autant de périphériques que possible, y compris les vieilles versions d’Android qui sont encore très utilisées en dehors des USA, le développeur devrait s’abstenir d’utiliser des technologies populaires comme JQuery, WebGL et Canvas.

Quoi qu'il en soit, cet événement a permis de constater combien le HTML5 semble permettre le développement d’applications Web complexes. « Nous pensons que le HTML5 est grand, mais nous ne pouvons utiliser dans le monde du mobile que le plus petit dénominateur commun » conclut Quimby.





Source : New Game Conference


Et vous ?

Avez-vous déjà utilisé le HTML5 pour développer des jeux ? Qu’en pensez-vous ?

[Golgotha]

Avez-vous déjà utilisé le HTML5 pour développer des jeux ? Qu’en pensez-vous

Oui, ma première impression c'est que c'est gourmand en ressource, et ça manque de couche supplémentaire pour faire de la POO directement, à voir avec toutes les libs qui sont en train de sortir, il va surement y avoir quelques chose de bon qui va sortir. Sinon en quelques lignes de code on peux bien s'amuser déjà.

[cd090580]

Quimby estime que pour cibler autant de périphériques que possible, y compris les vieilles versions d’Android qui sont encore très utilisées en dehors des USA, le développeur devrait s’abstenir d’utiliser des technologies populaires comme JQuery, WebGL et Canvas

Pour cela Google devrait faire pression sur les fabricants pour qu'ils diffusent tous la dernière version pour tous les périphériques mobiles...

[Camille_B]

et ça manque de couche supplémentaire pour faire de la POO directement

Il serait bon de faire remarquer qu'iDtech 4 (le moteur de Doom 3) est écrit en ... C.

Langage qui, comme chacun sait "manque de couche supplémentaire pour faire de la POO" agréablement.

J'ajoute agréablement car, comme chacun sait, on peut de la POO en C.

Tout cela pour dire que cet argument est moins "technique" que "culturel", entendu que la gêne des devs dès qu'il n'y a pas de fonctionnalités objets à la C ou à la Java est plus lié à l'enseignement qu'aux possibilités techniques réelles.

J'en veux pour preuve id Tech 4, mais aussi, plus simplement Javascript, langage objet boudé uniquement parce que le modèle objet est celui des Prototypes qui sort des habitudes des développeurs.

[psykokarl]

Tout cela pour dire que cet argument est moins "technique" que "culturel", entendu que la gêne des devs dès qu'il n'y a pas de fonctionnalités objets à la C ou à la Java est plus lié à l'enseignement qu'aux possibilités techniques réelles.

C'est d'avantage lié à qualité l’interpréteur mis a disposition par le navigateur. Il est considéré comme étant de bonne facture quand le script est interprété correctement.
Les problèmes du javascript sont que les navigateurs sont des environnements de développement des plus médiocre, la syntaxe du langage a mal vieilli et ses limitations ont été un frein pénible pour l'évolution du web.
Peu d'outils pour diagnostiquer les erreurs, peu d'information sur celle ci si elle sont détectées, une librairie native avec une syntaxe contre intuitive, différence de librairie entre les navigateurs, possibilités limités du langage qui sont certes un plus niveau sécurité mais combien de bidouilles douteuses pour arriver à ses fins, etc...

Les choses se sont améliorés mais beaucoup en ont bavé avant d'en arrivé la...

[ferber]

bref le message est clair : le html5 c'est plus que limite, c'est pas du niveau de flash, ni de silverligth, ni de java. Mais si on fait des efforts, beaucoup d'effort on doit pouvoir arriver a faire quelque chose de moins bien et en plus longtemps. Ajouter a ça une syntaxe JS calamiteuse, des apis variantes, non multi plateforme, Sans oublier que vos source sont récupérable via bouton droit afficher la source...
Vous obtenez le html5.

Et je me dit, mais pourquoi ? Faute aux idéologies communistes ? A l'open sources ? les drogues peut-être ? Ou simplement car des incultes pense que leur navigateur cracheront moins vites avec des pub en js accéléré GPU ?
Je ne serrait dire mais en tous cas le html5...

Ca fait pas envie.
Et au passage "native client" ce n'est pas vraiment w3c inside.
Donc le saint argument des normes qui fait baver et trembler tout bon libriste me fait encore une fois doucement rigoler.
Bref, think différents, tous contre adobe, vive le html5.

[Niark13]

@Camille_B : Tu dois confondre avec l'ancien moteur (celui de Quake 3). Parce que le code de Doom3, c'est bien du C++, pas du C.

[Strackel]

Avez-vous déjà utilisé le HTML5 pour développer des jeux ? Qu’en pensez-vous

J'ai déjà développer 7 mini jeux en HTML5, JavaScript et CSS 3.

Nous avons testé pas mal d'outils pour développer des jeux compatibles Iphone et Android et pour cette raison la plupart des outils ont été écarté. Viens ensuite le problème de la fluidité. nous avons donc dû utilisé le CSS 3 pour réaliser les animations.

Des problèmes se posent dès que l'on déplace des éléments de la page et que l'on veut gérer les collisions. Cela reste néanmoins faisable.

Bilan : Même si le HTML 5 semble à première vu la solution pour développer des jeux compatibles à tous les smartphones, cela limite énormément l'utilisation du HTML 5 pour que cela fonctionne et soit fluide.

Latency Kills The Game

[Aurelien.Regat-Barrel]

Et je me dit, mais pourquoi ? Faute aux idéologies communistes ? A l'open sources ? les drogues peut-être ?

Ben Steve Jobs je ne pense pas qu'il était un coco fan d'open source, et c'est peut être lui qui a tapé le plus fort sur Adobe et flash (par contre il était fan de LSD, c'est p'têt ça effectivement...).

@Camille_B : Tu dois confondre avec l'ancien moteur (celui de Quake 3). Parce que le code de Doom3, c'est bien du C++, pas du C.

et l'utilisation du C dans Q3 répondait aussi à un besoin particulier : celui de pouvoir compiler le code client en q3asm, c.a.d du bytecode maison exécuté dans une machien virtuelle maison. Pour faire ça il faut modifier un compilo - LCC dans ce cas. Faire ça avec un compilo C, c'est nettement moins de boulot que pour du C++.

[Warshadow]

[...] remarque Advocate Seth Ladd développeur chez Google.

"Advocate" n'est pas son prénom mais son titre chez Google (un équivalent d'évangéliste). Son nom est donc Seth Ladd... tout court !

[daYop]

"le développeur devrait s’abstenir d’utiliser des technologies populaires comme JQuery, WebGL et Canvas."

jquery on s'en fiche mais sans canvas, ni webGL comment faire un jeu qui tienne la route face à Flash et Unity ?

De + c'est marrant qu'ils passent sous silence les perfs variables en fonctions des support ET des OS, l'impossibilité de packager ses fichiers, de protéger ses assets, son code, sans parler de la sécurité avec les 'outils de développeurs' on peut changer a la volé les valeurs du jeu (pv, score,...)

Donc non, miser sur html5 c'est manquer de réalisme, y'en qui vont y laisser des plumes ^^

[Camille_B]

@Camille_B : Tu dois confondre avec l'ancien moteur (celui de Quake 3). Parce que le code de Doom3, c'est bien du C++, pas du C.

Exact. Au temps pour moi.

Donc non, miser sur html5 c'est manquer de réalisme, y'en qui vont y laisser des plumes ^^

La technologie n'est effectivement, à l'heure actuelle, pas au point pour ce domaine, mais d'ici quelques années il est fort probable que cela soit intéressant.

[camus3]

La technologie n'est effectivement, à l'heure actuelle, pas au point pour ce domaine, mais d'ici quelques années il est fort probable que cela soit intéressant.

Dans quelques années on verra autre chose , et pas sur que le consensus se poursuive autours des standards, microsoft ou apple sont dans la partie pour une stratégie court-termiste. ,et si ces technos n'apportent pas les bénéfices escomptés... Enfin il y aura toujours le problème des vieux navigateurs et des perfs de canvas ou javascript sur mobile par exemple. Car si beaucoup de terminaux ont acces à HTML5 , le problème des perfs est tout autre.

[DonQuiche]

Javascript est parfaitement adapté au jeu sur mobile : sa puissance permet d'animer jusqu'à cinq sprites en même temps et l'écran des smartphones permet justement d'afficher jusqu'à cinq sprites.

Merci de ne pas prendre ce propos trop au sérieux.

[Camille_B]

Enfin il y aura toujours le problème des vieux navigateurs et des perfs de canvas ou javascript sur mobile par exemple

Hum... problème secondaire pour l'industrie selon moi.

Deux préoccupations : logicielle et matérielle.

Est-ce que cela préoccupe les concepteurs de jeux vidéos d'exiger l'installation de DirectX 10 ? Non.

Je ne vois pas pourquoi ils devraient se préoccuper d'exiger l'installation d'un navigateur récent (qui a de forte chance d'être déjà installé).

Est-ce que cela les préoccupe d'exiger l'achat d'un nouveau pc à défaut de changer la carte graphique pour un modèle plus balèze qui consomme encore plus ? Non.

Alors pourquoi se préoccuper des perfs sur des mobiles d'ancienne génération ?

Javascript est tout à fait apte à produire des jeux vidéos de qualités et aux perfs très correctes. Tout dépend du type de jeu. Et ça c'est le court-terme !

Le moyen-terme ce sont des terminaux mobiles embarquant des interpréteurs javascript de qualité.

Je ne vois donc pas trop ou se situe le problème. Les "gros" de l'industrue misent de plus en plus sur html+css+javascript, et Adobe lui-même semble privilégier ce trio au détriment de flash !

Mais sur ce forum que d'aigreur : "javascript c'est nul", "c'est inadapté", "c'est lent" etc.

La réalité c'est que pour une fois c'est bien les développeurs attachés au proprio (flash et consort) qui se retrouve à la masse.

On mise sur flash, c'est super, c'est géré par une grosse boîte. La grosse boîte dit : bon, maintenant c'est le web. Et là on a les boules après avoir pendant des années daubé sur javascript. On a les boules car on voit la techno dans laquelle on a investit disparaître peu à peu, et le mépris qu'on avait pour l'autre fait qu'on n'a pas développé les compétences nécessaires.

Il est amusant de voir à quel point, sur ces sujets, les avis sont totalement divergeant dans la sphère "logiciel libre" (forcément). Pourtant dans ce petit monde, il y a pas plus d'incompétents qu'ici.

Preuve s'il en est qu'il s'agit ici moins d'une affaire technique, que d'une affaire... politique ? sociologique ? d'habitude ?

[DonQuiche]

Est-ce que cela préoccupe les concepteurs de jeux vidéos d'exiger l'installation de DirectX 10 ? Non.

Je ne vois pas pourquoi ils devraient se préoccuper d'exiger l'installation d'un navigateur récent (qui a de forte chance d'être déjà installé).

Est-ce que cela les préoccupe d'exiger l'achat d'un nouveau pc à défaut de changer la carte graphique pour un modèle plus balèze qui consomme encore plus ? Non.

Ouhlà, attention tout de même, dans les deux cas on parle bien de jeux mais pas des mêmes. Il faut distinguer le hardcore gaming d'une part, qui peut en effet se permettre d'exiger des bécanes à peu près récentes (enfin... les jeux actuels ciblent encore OGL 2.0/2.1 et Dx9, soit 2002-2006) en échange d'une super-production, du casual gaming d'autre part pour lequel le nombre de plateformes supportées est déterminant et qui doit pouvoir être lancé au travail. Les modèles économiques du premier et du second n'ont rien à voir ! Le premier coûte cinquante euros, le second est gratuit et l'audience doit être captée en une minute (quand il ne suffit pas de la faire venir).

Le jeu en javascript, c'est évidemment pour le casual gaming, pas pour le hardcore gaming ou pas avant très (très) longtemps. Et de ce côté là, la situation entre flash et js est la suivante :
* iOS : javascript
* Android : flash (aux US les vieux androids sont majoritaires)
* Windows Phone : ?
* PC: flash supporté à 98%, html5 à 50%

Du coup, au contraire, je dirais que js relève d'un choix technique plus que commercial aujourd'hui, à moins de vouloir d'abord cibler les niches vides d'iOS. Même si, évidemment, à terme il devrait supplanter Flash, celui-ci me semble être pour le moment le plus intéressant sur le plan commercial.

[Camille_B]

Ok pour la distinction entre hardcore et casual (et encore, la distinction n'est pas si nette... nethack, Dwarf Fortress, casual ou hardcore ? etc.).

Il reste qu'au niveau technique l'optimisation n'est plus de mise dans les prods "classique" sur pc. Rien ne le justifie dans les faits, vraiment rien.

Qui dit que dans quelques mois ce soit pareil pour les mobiles, le casual gaming etc ?

Ce que je veux dire c'est que l'on exige de jeux webs des choses que l'on exige, malheureusement, de moins en moins sur pc.

Et encore,

Ensuite ce "tableau" est faux :

* iOS : javascript
* Android : flash (aux US les vieux androids sont majoritaires)
* Windows Phone : ?
* PC: flash supporté à 98%, html5 à 50%

Il faut le corriger ainsi, et là on comprend bien mieux l'enjeux :

* iOS : javascript
* Android : flash (aux US les vieux androids sont majoritaires) + javascript
* Windows Phone : javascript
* PC: flash supporté à 98% + javascript

Car enfin, je suis un peu gêné par le html5 dans cet article. HTML5 c'est une petite partie du problème, le gros c'est javascript.

Javascript et le DOM suffisent pour faire un jeu (+ des progs côté serveur). Ce qu'apporte HTML 5 et CSS 3 ce sont des facilités supplémentaires, rien d'autre.

D'ailleurs on a pas attendu HTML 5 pour faire des jeux.

C'est exactement la conclusion de l'article : actuellement il est préférable de faire des jeux javascript "à l'ancienne" (sans html 5 et css 3). Ça fonctionne partout, vraiment partout.

[DonQuiche]

@Camille B
Si le hardcore gaming PC ne s'optimise plus, c'est que la plupart des jeux sont des portages venant de machines bien moins puissantes. Cela dit, je ne suis pas du tout sûr que cette absence d'optimisation soit vraie pour tous les jeux.

Quant à la raison qui fait qu'on exigerait des jeux mobiles ce que l'on n'exige plus des jeux PC (l'optimisation), c'est tout simplement du fait que la réserve de puissance sur PC est large alors que l'on a vite fait de mettre le CPU d'un mobile à genoux, et sa batterie encore plus vite. Qui plus est, un jeu PC est généralement codé en C++, qui part avec un avantage significatif sur JS.

Ensuite, mon tableau n'était pas faux, il était fait pour html5. Toi, tu étends l'usage de js pour les jeux à html4. Certes, on peut faire certains jeux en html4. Mais pas tous : il y a une bonne raison au fait que les dévs ont préféré flash à html4 pendant toutes ces années.

Cela dit, oui, html4 est plus répandu que flash, qui est plus répandu que html5. Mais html4 est limité et le comparer à Flash/html5 est abusif. Il y a une limite à ce que l'on peut faire avec un jeu d'images (jpg, gif, png, svg) prédéfinies que l'on peut simplement afficher à différentes positions sans jamais faire varier la couleur, l'inclinaison, appliquer aucun effet et en étant incapable de générer des images à la volée. Un rayon laser qui balaie la pièce ? Prière de demander au designer de préparer 360 versions du graphisme, ça ne fera que 5Mo à télécharger.

C'est exactement la conclusion de l'article : actuellement il est préférable de faire des jeux javascript "à l'ancienne" (sans html 5 et css 3). Ça fonctionne partout, vraiment partout.

Des jeux javascript à l'ancienne ? J'ai beau regardé sur le web, je ne vois que des jeux en flash. Alors quelle conclusion en tirer ?

PS : Non, ok, il y a Ogame. Certes, il y a ce genre de jeu à l'affichage statique, ainsi qu'une pléthore de roguelike plus ou moins confidentiels. Plutôt une minorité.

[Camille_B]

Cela dit, je ne suis pas du tout sûr que cette absence d'optimisation soit vraie pour tous les jeux.

C'est certains.

c'est tout simplement du fait que la réserve de puissance sur PC est large alors que l'on a vite fait de mettre le CPU d'un mobile à genoux, et sa batterie encore plus vite.

Certes, mais soyons sérieux, flash n'est pas un modèle de légèreté !

Des jeux javascript à l'ancienne ? J'ai beau regardé sur le web, je ne vois que des jeux en flash. Alors quelle conclusion en tirer ?

J'ai le souvenir de tetris-like, de jeux de voitures, et même des marios.

En réalité on peut faire beaucoup avec javascript. Il suffit de voir ce que l'on peut faire avec une bibliothèque comme crafty.js qui est compatible... IE6.

http://craftyjs.com/

Non, le principal problème de Javascript jusqu'à HTML 5 c'est principalement les développeurs eux-mêmes qui le prenait pour un jouet, et donc les concepteurs des navigateurs qui n'avaient jamais penser à optimiser le moteur JS outre mesure. Franchement c'est surtout Google qui a changé la donne.

Ça n'est pas le HTML 5 qui a fait voir JS d'un autre oeil, c'est V8 (le moteur JS de Chrome).

[DonQuiche]

En réalité on peut faire beaucoup avec javascript. Il suffit de voir ce que l'on peut faire avec une bibliothèque comme crafty.js qui est compatible... IE6.

http://craftyjs.com/

Je viens d'aller voir leurs démos et c'est en fait assez décevant. Malgré une résolution limitée à 550*440, l'animation n'est pas fluide lors d'un scrolling, du fait d'une absence de vsync et de micro-saccades, sans doute lors du passage du GC (surtout sous Firefox). Qu'est-ce que cela peut donner sur des mobiles encore moins puissants, en dépit d'une résolution encore inférieure ? 15 ips souffreteuses ? Pas très agréable.