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

Citation:

---

Envoyé par Camille_B

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 ?

---

Disparaitre non, encore une preuve d'une flagante méconnaisance du sujet,
personnelement me retrouver avec un compilateur qui compile soit en js +svg ou en swf, je trouve que c'est plutot un avantage.
Par contre ce que je trouve très désagréable c'est qu'adobe ce désengage du flash, a cause d'une communauté open sources et d'une pomme verseuse, qui n'ont pas été capable en 10 ans de fournir quelque chose de plus puissant que ce produit proprio, une communauté de critiqueur, qui passe leur temps à médire flash, et qui au final accouche d'un flash killer, qui n'en a que le titre. Qui profite d'une chance affolante : celle d'avoir servi de justificatif a une firme : Apple qui ne voulais pas voir détruire sont fond de commerce. Ce html5 a pus grandir et gagner en galond, sans avoir a faire preuve de force. Ce n'est pas le html5 qui ronge le flash, c'est la méconnaissance, les mauvais développeur, steve joob avec en corollaire une communauté de fane boy et de libriste. Et me dire que d'ici quelque temps le web risque d'être moins rapide, moins puissant, avec des outils moins bon, moins productif pour cause de penser unique a tendance a m’énerver ! Surtout que, a aucun moment je n'ai vue d'exemple d'html5 qui m'ont fait dire, le "html5 est au dela de flash". bien au contraire !
Et Adobe ne fait que suivre cette pensé unique, cette fameuse pensé unique.
( tout en fesant au passage des éconnomies en virant de ci de la quelques employé et en fesant developper leur idée par les éditeurs de naviguateur ):D

Citation:

---

Envoyé par ferber

Surtout que, a aucun moment je n'ai vue d'exemple d'html5 qui m'ont fait dire, le "html5 est au dela de flash". bien au contraire !

---

Et tu n'en verras pas avant très longtemps, voire si quelque chose d'autre se profile, jamais.

Un truc qui plaisait pas avec Flash, c'est qu'il vient d'une seule entreprise, qui n'a pas de compte à rendre. Il n'est pas pensé pour que chacun décide lui-même s'il le gère ou non : on peut le gérer si Adobe fait ou fait faire un player Flash, sinon on peut pas. Il y a bien eu quelques tentatives de faire des players indépendants et indépendantistes, mais ils ne marchent pas. Deux raisons :
- pour y arriver il faut une expertise sur le sujet de Flash, d'un niveau totalement déraisonnable pour une technologie de cet ordre.
- il faut fournir les mêmes bugs que l'implémentation de référence, celle sur x86 windows.
C'est pas un si gros problème que ça à mon avis, en tout cas pas encore. Mais ça plaît pas. Ce n'est pas intéropérable au sens web.

HTML5 n'a pas ce problème. Et les autres problèmes, un certain nombre peuvent être réglés avec l'évolution. C'est basé sur JavaScript et donc il n'y a pas grand-chose de neuf à spécifier, ce qui fait des specs courtes et accessibles pour une technologie de cet ordre. Si quelqu'un a un bug, il n'a qu'à le résoudre pour s'aligner avec la spec, comme les autres. C'est universel et intéropérable.
Par contre, ça demande (beaucoup) plus de ressources, et les frameworks de développement Flash n'existent pas pour HTML5. Ils pourraient exister, il suffirait de les faire, mais il n'y en a pas là, maintenant.
Et, il y a cette question de gestion des DRMs, souvent souhaité, bien que totalement contradictoire à la notion d'interopérabilité.

Je suis... Surpris, que Flash soit lâché si vite et qu'il n'ait pas de vrai remplaçant. En temps et en heure, un truc semblable à HTML5 remplacera Flash pour ce qui est souhaité interopérable, et un truc semblable à Flash restera pour ce qui est souhaité obscurci. Mais la techno n'est pas prête.

Bonsoir,

Certains de mes clients se plaignent du manque de redirection vers la bonne version du site mobile, lorsqu'ils sont sous iphone 3 ou 4 ?

L'user-agent ne semble pas reconnu de la meme facon. Avez-vous deja rencontre le probleme ?

Pouvez-vous tester cette url depuis un iphone 4 et un galaxy s2 ?
Http://www.freetalent.fr/demos/billybox/web

Merci

La réalité du web en ce moment c'est que la plupart des jeux et des sites à "forte animation" sont réalisés en flash. On peut tourner cela comme on veut mais c'est un fait. J'ai des enfants 5 à 8 ans, tous les sites sur les lequels ils jouent, sont en flash. C'est comme cela.

La question peut etre aussi pourquoi il y a 5 ans les personnes se sont tournés vers Flash plutot que Javascript. Les réponses sont multiples :
- faire une animation en flash est simple et le rendu est beau et lissé
- en javascript dès que tu fais un truc, il faut tester le navigateur car suivant le navigateur ce n'est pas le meme appel ou le même fonctionnement, c'est assez galère,
- en javascript, pas bcp d'environnement de dév...
- en javascript, des qu'il y a un nouveau naivigateur, tu es obligé de vérifier que ton code marche.

A l'heure actuelle, les choses évolues, tu peux utiliser des frameworks qui permettent de faire une certaine abstraction du navigateur (pas trop quand même). Il commence avoir des IDEs assez pro.

Citation:

---

Le javascript ...C'est universel et intéropérable.

---

C'est pour cela qu'il y a tjrs xxx if pour déterminer le navigateur et le code adéquat lol. (il suffit de regarder le code de cette page)

Petit précision, HTML5 ne remplacera pas réellement flash, car il y a des choses en flash que tu ne peux pas faire en HTML5. Il va succéder, et les sites vont évoluer différement...

Je dirai que le problème majeur du développement HTML/Javascript vient du fait que chaque navigateur va interpréter le code à "sa sauce". Meme si depuis des annees, un effort est fait pour plus du compatibilité entre les navigateurs.

Avec Flash, il n'y a pas ce problème puisque le player est le même partout. Le seul gros problème de Flash vient de sa consommation en ressources système, et depuis les dernières versions du player, des plantages réguliers.

A savoir qu'Adobe a annoncé son arrêt de développement du player sur les mobiles et tablettes. La derniere en date est la version 11 (hyper buguée), il n'y aura pas de version 12. Les players seront donc, soit plus maintenus, soit développés par le constructeur lui-même (ce qui va être un beau foutoir).

Quand a HTML5, c'est bien joli, mais on constate que seulement 80% des fonctionnalités promisent sont présentent. En encore, selon le navigateur elles ne sont pas toutes prisent en compte. C'est tout de même regrettable, sachant que l'on parle de l'HTML 5 depuis plus de 5 ans, et qu'il ne semble pas évoluer plus que ça.

Citation:

---

Envoyé par snopims

- faire une animation en flash est simple et le rendu est beau et lissé

---

Je dirais plutôt que cétait bien plus simple. En l'absence de framework, ça l'est toujours, d'ailleurs.
Il y a aussi le fait qu'à l'époque, le JavaScript ne tournait pas dans un JIT, il était très lent, bien plus que Flash qui avait optimisé les parties sensibles.

Citation:

---

Envoyé par snopims

- en javascript dès que tu fais un truc, il faut tester le navigateur car suivant le navigateur ce n'est pas le meme appel ou le même fonctionnement, c'est assez galère,

---

Euh, en 95 oui, mais on est en 2000 là. Pardon, 2011.
De une, il suffit d'utiliser jQuery ou similaire. De deux, ce ne sont pas les navigateurs qu'on teste, mais ce qu'ils gèrent ou non.

Citation:

---

Envoyé par snopims

- en javascript, pas bcp d'environnement de dév...

---

Pas d'objection.

Citation:

---

Envoyé par snopims

- en javascript, des qu'il y a un nouveau naivigateur, tu es obligé de vérifier que ton code marche.

---

Bof, non, depuis Chrome tout le monde s'en tape. Le nouveau n'a qu'à être compatible.

Citation:

---

Envoyé par snopims

C'est pour cela qu'il y a tjrs xxx if pour déterminer le navigateur et le code adéquat lol. (il suffit de regarder le code de cette page)

---

Seulement dans le code obsolète ou par les débutants ou quand tu veux faire des stats sur les navigateurs utilisés. Pourquoi cette page aurait-elle changé son code dès que cela est devenu possible, alors qu'elle marche très bien comme ça ?

Universel, ça veut pas dire que tout le monde gère, mais que tout le monde peut décider de gérer.

Citation:

---

Envoyé par snopims

Petit précision, HTML5 ne remplacera pas réellement flash, car il y a des choses en flash que tu ne peux pas faire en HTML5. Il va succéder, et les sites vont évoluer différement...

---

C'est ce que j'ai dit.

bonjour,

Moi je suis convaincu qu'actuellement pour certaines catégories de jeux (jeu 2D de réflexion, d'arcade etc.), html5 est adapté pour les jeux.

Je me suis moi-même lancé dans un projet de jeu en html5... :)

deux exemples trouvés sur le net qui m'ont convaincu à me lancer :

- http://www.wordico.com/
- http://play.lostdecadegames.com/onslaught_arena/demo


cdt,

rummyworld

Citation:

---

Envoyé par rummyworld

bonjour,

Moi je suis convaincu qu'actuellement pour certaines catégories de jeux (jeu 2D de réflexion, d'arcade etc.), html5 est adapté pour les jeux.

Je me suis moi-même lancé dans un projet de jeu en html5... :)

deux exemples trouvés sur le net qui m'ont convaincu à me lancer :

- http://www.wordico.com/
- http://play.lostdecadegames.com/onslaught_arena/demo


cdt,

rummyworld

---

Mais des jeux étaient aussi codés en BASIC sur Amstrad , ce n'est pas une question de pouvoir ou pas , bien sur qu'on peut. Sauf que quand le jeux est un business les boites ont certaines attentes , exactement comme pour la question de la balise video et audio. La il n'y a pas de "choix" technologique puisque c'est la "seule" techno disponible.Le fait qu'elle soit standard ne la rend pas efficace pour le job, c'est tout.

Citation:

---

Envoyé par thelvin

Je dirais plutôt que cétait bien plus simple. En l'absence de framework, ça l'est toujours, d'ailleurs.
Il y a aussi le fait qu'à l'époque, le JavaScript ne tournait pas dans un JIT, il était très lent, bien plus que Flash qui avait optimisé les parties sensibles.



Euh, en 95 oui, mais on est en 2000 là. Pardon, 2011.
De une, il suffit d'utiliser jQuery ou similaire. De deux, ce ne sont pas les navigateurs qu'on teste, mais ce qu'ils gèrent ou non.




Pas d'objection.




Bof, non, depuis Chrome tout le monde s'en tape. Le nouveau n'a qu'à être compatible.



Seulement dans le code obsolète ou par les débutants ou quand tu veux faire des stats sur les navigateurs utilisés. Pourquoi cette page aurait-elle changé son code dès que cela est devenu possible, alors qu'elle marche très bien comme ça ?

Universel, ça veut pas dire que tout le monde gère, mais que tout le monde peut décider de gérer.



C'est ce que j'ai dit.

---

C'est du grand n'importe quoi. Franchement, vous developpez vraimentpour le web ? A c roire que vous n'avez pas eu de gros projets cross-platform a gerer. JQury, oui c'est tres sympa, il simplifie beaucoup de chose, mais il faut tout de meme ajuster son code pour que les interfaces reagissent de la meme maniere d'un navigateur a un autre. Et ca sur un planning de dev, ca s'appelle du temps de perdu.

Chrome est a la ramasse en terme d'interpretation de HTML5. Aujourd'hui seul firefox est capable de prendre en charge le html5 a 84%. Chrome ne le prend qu'a 69% pourtant c'est du ggogle, initiateur d'android. Va comprendre charles.

Aujourd'hui il y a de moins en moins de respect des standarts. Tout est ouvert et chacun peut faire son flash player ou sa jvm a sa sauce. Ca n'a plus de sens. Merci l'open source.

Je ne suis pas fan des systemes proprietaires, mais je pense que l'on va droit dans le mur avec tout c es framework livres en pature a des developpeurs qui ont chacum leur "standart"'.

Zecreator

Quand on lit ça :

Citation:

---

Chrome est a la ramasse en terme d'interpretation de HTML5. Aujourd'hui seul firefox est capable de prendre en charge le html5 a 84%. Chrome ne le prend qu'a 69% pourtant c'est du ggogle, initiateur d'android. Va comprendre charles.

---

et que l'on se permet de commencer par ça :

Citation:

---

C'est du grand n'importe quoi. Franchement, vous developpez vraimentpour le web ?

---

On a franchement envie de vous renvoyer à ça :

http://html5test.org

Chrome 15 : (343 pt + 13 pt bonus) / 450 => 79%

Firefox 8 : (314 pt + 9 pt bonus) / 450 => 71%

IE9 : (141 pt + 5 pt bonus) / 450 => 32%

Et je ne parle même pas du gloubi-boulga présent sur tout ce fil qui mélange allègrement HTML5, Javascript, CSS etc.

On ne fait pas du jeu vidéo avec HTML5, on fait du jeu vidéo avec un peu de HTML5 (canvas, local storage etc.) et beaucoup de javascript.

Dire qu'un navigateur ne gère que tant de pourcentage de html5 et l'autre 10% de plus ou de moins n'a donc pas de sens, tout ce qui compte c'est que le navigateur gère les parties de HTML5 utiles à la conception de jeux vidéo.

D'après ce site :
http://html5demo.braincracking.org/index.php

les % sont bien différents.

Zecreator

Citation:

---

On ne fait pas du jeu vidéo avec HTML5, on fait du jeu vidéo avec un peu de HTML5 (canvas, local storage etc.) et beaucoup de javascript.

---

les api sont spécifiés par le W3C comme le DOM. ce n'est pas ECMA qui décide des API qui ne sont en théorie pas liées à un langage particulier. On parle donc bien d'HTML5. il n'y a pas de canvas ou d'objet audio dans javascript , pas plus que d'XMLHTTPREQUEST.

Vous répondez à côté.

Je n'ai jamais dis qu'HTML 5 n'avait rien à faire là-dedans, j'ai juste dis que la partie qui intéressait le développement d'un jeu est réduite (on n'a pas besoin de tout HTML 5), et qu'une grosse partie du dev se fait avec Javascript.

Bonjour

Citation:

---

Envoyé par zecreator

Aujourd'hui il y a de moins en moins de respect des standarts. Tout est ouvert et chacun peut faire son flash player ou sa jvm a sa sauce. Ca n'a plus de sens. Merci l'open source.

---

Cela relève plus de la science-fiction que de la réalité. Je ne connais que Gnash comme implémentation libre de Flash et ce n'est pas un player Flash qui cherche à se comporter différemment de l'implémentation propriétaire si on met de côté les bogues.

Quant à Java, la JVM d'Oracle et celle d'OpenJDK partagent une grande partie du code, c'est encore plus vrai dans Java 1.7. La fragmentation des JVM ne concerne pas l'environnement desktop, cela ne touche que l'environnement mobile pour les terminaux compatibles J2ME/MIDP. Je ne vois pas du tout le rapport avec l'open source. Votre remarque est donc sans fondement.

Citation:

---

Envoyé par zecreator

Je ne suis pas fan des systemes proprietaires, mais je pense que l'on va droit dans le mur avec tout c es framework livres en pature a des developpeurs qui ont chacum leur "standart"'.

---

Vous n'êtes pas obligé d'utiliser les frameworks en question. L'écosystème Java n'a pas attendu WebGL et Canvas pour permettre la création de jeux en 3D dans le navigateur (et aussi en dehors) notamment avec des bindings d'OpenGL/OpenGL-ES dont JOGL (cf. "Zoltar's Return" de Lilian Chamontin dès 2004). C'est bien sympa la 3D sans avoir à installer le moindre plug-in mais cela va poser encore plus de problèmes que le support des applets comme une partie plus importante des couches sous-jacentes réagira de manière potentiellement différente à la fois en fonction du système d'exploitation et du navigateur malgré les jolis standards. Essayez de réécrire Minecraft en Javascript; après, on en reparlera. Je ne suis pas une mauvaise langue, je pense juste que le couple Javascript + HTML5 + WebGL manque de maturité. La situation sera peut-être bien différente dans 5 à 10 ans.

Citation:

---

Envoyé par gouessej

La situation sera peut-être bien différente dans 5 à 10 ans.

---

C'est marrant, on disait la même chose... il y a 5 ou 10 ans.

Que de mots de bienvenue au HTML5 !

Hello,

Je me permets de faire mon petit retour d'expérience sur le sujet des jeux 2D. Je me suis amusé à porter un jeu de platforme en XNA vers HTML5/Canvas grâce à l'utilisation de la librairie EaselJS. J'ai publié un article et le code complet du jeu ici : http://blogs.msdn.com/b/davrous/arch...4-easeljs.aspx et j'ai fait 1 heure de session autour du développement d'un jeu de plateforme en vidéo ici : http://blogs.msdn.com/b/davrous/arch...-en-html5.aspx

Mon objectif était de voir si l'on pouvait faire un jeu cross-navigateur et surtout cross-devices (iPad, Android & Windows Phone 7) grâce à HTML5.

La conclusion de mes tests et recherches sont les suivantes :

- HTML5/Canvas sont parfaitement adaptés aux jeux 2D sur les desktop grâce à l'accélération matérielle présente maintenant dans IE9, Firefox, Chrome et bientôt Opera. De plus, les GPU et CPU mangent assez facilement la charge. Ainsi, mon jeu tourne sans problème à 60 fps sur mon Vaio Z équipé d'une nVidia GT330m sous IE/FF/Chrome.
- C'est nettement moins le cas des mobiles! Le même jeu tourne dans les 10 fps sous iPad 2. Il tourne un chouilla mieux sous mon Windows Phone 7 (HD7) grâce à l'accélération matérielle d'IE9 dessus mais cela reste totalement injouable!

Bref, un canvas pleine page sur les mobiles n'est pas trop envisageable aujourd'hui. Par contre, rien n'empêche de faire des petits canvas et de les faire bouger à travers CSS. C'est ce que fait Angry Birds version HTML5 si vous regardez. CSS et CSS3 transitions & animations sont en effet matériellement accélérés sous iPad par exemple. Donc mieux vaut s'appuyer dessus pour faire bouger ses sprites plutôt que de balancer tout cela dans un gros canvas. J'ai commencé à faire des tests que l'on retrouve dans mon dernier article sur CSS3 Animation ici : http://blogs.msdn.com/b/davrous/arch...ions-css3.aspx . J'aimerais bien aller plus loin en réécrivant le jeu à base de plusieurs petits canvas + animations CSS mais c'est un boulot assez important (refaire les tests de collisions, etc.).

Je pense qu'il faut du coup une couche d'abstraction qui sera apportée bientôt par des frameworks de jeux comme EaselJS pour que l'on ne se galère pas dessus. Mais je pense aussi qu'HTML5 est une belle oppornité pour les petits jeux multi-plateformes. Il faut juste faire attention de développer son jeu en partant du mobile (Mobile First comme disent les américains) puis d'ajouter d'éventuels effets en montant sur les plateformes plus puissantes.

Bye,

David

@Davrous
Merci à toi pour ce retour détaillé. :)

Cela dit, j'aimerais y apporter un gros bémol. Je dispose encore ce soir d'une "veille" machine (2008) - la nouvelle arrive demain. A l'époque il s'agissait d'une configuration haut de gamme et donc vraisemblablement encore supérieure à ce dont dispose le pur casual gamer moyen aujourd'hui (c2d E6850 - et ati 5700 mais c'est le CPU qui compte ici). En fait, elle fait encore tourner sans accroc presque n'importe quelle grosse production 3D moderne avec des options graphiques en medium, voire parfois élevées.

J'ai donc testé ton jeu. Verdict : sous Firefox (dernière version, alors que le pékin moyen en est resté à la 3.x), j'ai bien 60fps la très grande majorité du temps... Sauf lors de ces quelques pics de 0,5s où l'on passe soudain à 4 ou 5 fps (20 fps affichés). Ce qui, pour un jeu de plateforme est calamiteux, les ralentissements se produisant bien sûr pile au moment où l'on ajuste le saut. Quant à Chrome (dernière version), pourtant plus rapide en général sur ce genre d'exercices, il bute à 20fps en permanence. Tous les tests ont été faits avec un PC au repos, etc.

Du coup, pour des jeux qui viseraient le casual gamer, en tout cas des gens qui ne renouvellent pas leur machine tous les 18 mois et dont le CPU n'est pas un foudre de guerre, les performances de la solution canvas me semblent au contraire totalement inadaptées pour tous les jeux réclamant une certaine fluidité (plateforme, etc).

En somme, si la limite est bien le CPU comme je le pense, l'utilisation de frameworks risque malheureusement d'empirer les choses. Je pense plutôt qu'il faut vraiment s'appuyer très peu sur le canvas, aussi peu que possible et tenir compte de cette limite dans le game design, même si c'est limitatif. Accessoirement, il doit sans doute être possible et préférable d'exécuter la logique du jeu (collisions, etc) indépendamment du système de rendu. Enfin, sous Firefox j'ai activé l'option "search as you type" ce qui m'interdit d'utiliser les touches du clavier dans des jeux en html (pas de pb avec flash par contre), un facteur tout de même très limitant. :aie:

Citation:

---

Envoyé par DonQuiche

J'ai donc testé ton jeu. Verdict : sous Firefox (dernière version, alors que le pékin moyen en est resté à la 3.x), j'ai bien 60fps la très grande majorité du temps... Sauf lors de ces quelques pics de 0,5s où l'on passe soudain à 4 ou 5 fps (20 fps affichés). Ce qui, pour un jeu de plateforme est calamiteux, les ralentissements se produisant bien sûr pile au moment où l'on ajuste le saut. Quant à Chrome (dernière version), pourtant plus rapide en général sur ce genre d'exercices, il bute à 20fps en permanence. Tous les tests ont été faits avec un PC au repos, etc.

---

Salut DonQuiche,

J'aurais bien envie de te donner une réponse trollesque en te disant de tester sous IE9/10 ;-). Plus sérieusement, il y a vraiment des différences entre les navigateurs pour l'instant à ce sujet. Cela a été illustré dans cet article : http://www.phoboslab.org/log/2011/08/are-we-fast-yet par le développeur du site de benchmark suivant: http://www.phoboslab.org/log/2011/08/are-we-fast-yet . Pour Chrome, tu as essayé d'activer l'accélération matérielle en allant dans about:flags?

Sinon, ton retour est intéressant. J'ai pourtant testé sur différentes machines mais je n'avais pas eu de différences aussi importantes de FPS. J'avais vu que pour tous les navigateurs utilisant l'accélération matérielle par défaut ou non, il faut bien faire gaffe à la qualité de ses drivers. J'ai eu beaucoup de problèmes avec des chipset ATI par exemple, donc je ne recommande plus que des nVidia pour mes démos.

Bye,

David

Bonjour Davrous. :)

Oui, Chrome et Firefox bénéficient tous deux de l'accélération matérielle (j'avais déjà vérifié dans about:flags sous Chrome et about:support sous Firefox). Note cependant que ce n'est pas le cas de la majorité des utilisateurs : Do users actually get hardware acceleration ?, mieux vaut donc ne pas compter dessus. Qui plus est, mes drivers ont été mis à jour il y a un ou deux mois. Et, surtout, je n'observe de problème nul part de ce côté-ci, que ce soit en jouant à un jeu ou en lorsque je code pour OGL ou D3D, ce qui me met naturellement aux premiers rangs pour connaître les capacités de la CG de ma machine. ;)

Toutefois, je pense que tu as tort de regarder du côté de l'accélération matérielle. Pour un jeu de cette taille, avec au plus quelques dizaines de sprites, je parie que l'on pourrait très bien faire le rendu en GDI+ avec plusieurs centaines de fps. A mon avis, on voit plutôt les limites d'un système qui n'est pas prévu pour ça à l'origine, d'un langage relativement lent et de couches empilées les unes au-dessus des autres.