Palido a écrit :
Que ce soit en webGl ou html5 ou autre, j'attends toujours de voir un "Dofus" ou un "Bastion" débarquer et cartonner, qui fonctionne sur tous les devices sans avoir à installer quoique ce soit d'autre qu'un plugin, qui était de toute manière installé quasimment partout....

Alors de tête je peux citer:
Game Of Bombs (Bomberman Multi)
Prodigy (un MMO genre Pokémon à base de maths)
Indie Arena Booth (Une version virtuelle et multi de la Gamescom)
Les petits jeux Facebook

Au niveau moteurs 2D, il y a beaucoup de belles choses : pixi.js, phaser, mo.js,... sans compter l'exporteur d'Unity et celui d'Animate (le nouveau nom de Flash). Ce n'est pas tant un problème d'outils si le web est devenu chiant. C'est plus une absence de volonté de le rendre vivant. C'est en grande partie du au fait que la majorité du traffic web est désormais scindé en deux:
-la majorité est sur mobile (et donc en portrait et via un écran tactile)
-le reste est sur laptop (donc landscape et à la souris)
C'est un cauchemar pour combiner les deux quand tu veux faire quelque chose un poil interactif.

Au niveau moteurs 2D, il y a beaucoup de belles choses : pixi.js, phaser, mo.js,... sans compter l'exporteur d'Unity et celui d'Animate (le nouveau nom de Flash).

Sur Animate, je viens de faire un simple test : une animation de forme (déformation vectorielle, pas un simple agrandissement) hyper basique d'un rond qui se transforme en ovale. Résultat : je me retrouve avec un ensemble de fichiers html/js/png (tout un site!) qui pèse 98,8ko. Heureusement que je n'ai fait ce test qu'en 24 ips... On pouvait faire de vraies animations riches et longues pour beaucoup moins. Il n'y a pas le plugin Flash à télécharger qui intégrait toutes les librairies, mais on le faisait qu'une fois toutes les X semaines. Là, en terme de poids, c'est énorme pour un truc aussi basique.

Pour mon test, l'animation n'est plus vectorielle et a été transformée en une spritesheet png. Il y a bien un export .svg, mais ça ne semble pas prendre en compte les anims. Je n'ai pas beaucoup utilisé Animate, mais je crois qu'en script, c'est pareil : c'est super limité. Il me semble qu'il est tout simplement impossible de refaire tout ce que l'on pouvait faire avant en export html5.

Unity c'est chouette, mais c'est une usine à gaz (normal, ce n'est pas pensé pour ce genre d'utilisations) et l'export html impose pas mal de limites.

J'ai déjà testé pas mal de solutions en html/js. C'est cool, ça marche et tout. Mais c'est très limité.

Et contrairement à ce que tu dis, avec Flash, c'était plutôt simple de gérer le touch / multitouch / souris / clavier. De même pour les différentes résolutions, le plein écran, les orientations écrans et même agrandissement de fenêtres "responsive". A l'époque où Flash était dispo sur Android, tout ça ne posait pas de problème.

Aujourd'hui, malgré toutes les solutions qui existent, c'est effectivement un cauchemar. Il n'y a pas d'alternative viable et faire des trucs plus enrichis demande des compétences plus élevées.

Enfin bref, tout ça, c'est du passé.

Palido a écrit :
une animation de forme (déformation vectorielle, pas un simple agrandissement) hyper basique d'un rond qui se transforme en ovale. Résultat : je me retrouve avec un ensemble de fichiers html/js qui pèsent 98,8ko. Heureusement que je n'ai fait ce test qu'en 24 ips...

Là c'est un souci avec Animate qui rajoute une chier d'overhead, car tu peux faire la même chose en pur svg pour quasi rien.

Là c'est un souci avec Animate qui rajoute une chier d'overhead, car tu peux faire la même chose en pur svg pour quasi rien.

Clairement oui. Et si tu me trouves un outil qui permet de faire ça proprement (en plus d'offrir tout ce que Flash permettait de faire: animation + interactivité, je serais déjà très content), je suis preneur.

Un autre problème aujourd'hui, c'est que malgré tout, ces technos sont dépendantes du bon vouloir des navigateurs. Avant on dépendait du bon vouloir d'une compagnie, aujourd'hui, de plusieurs... Par exemple, les animations SMIL ont failli sauter avec Chrome il y a quelques années. Il y a la maintenance à prendre en compte. Mes projets Flash d'il y a 10-15 ans tournent toujours nickel aujourd'hui.

Palido a écrit :
Et contrairement à ce que tu dis, avec Flash, c'était plutôt simple de gérer le touch / multitouch / souris / clavier. De même pour les différentes résolutions, le plein écran, les orientations écrans et même agrandissement de fenêtres "responsive". A l'époque où Flash était dispo sur Android, tout ça ne posait pas de problème.

Ce n'est pas un problème de techno mais d'investissement. Que ce soit en Flash ou en HTML5, ça prend du temps de repenser l'interface, les visuels et les interactions en passant d'une plateforme à l'autre. Tu peux très bien redimmensionner un canvas à la volée mais ça ne fera pas pour autant une bonne expérience. Si tu fais un jeu de plateforme 2D pensé pour le 16/9, il ne ressemblera à rien en portrait, Flash ou pas.

Mais pour revenir au problème initial, ce que tu dis est faux : Steve Jobs n'a pas bloqué Flash pour sauver ses 30%. Flash a été interdit dès la sortie de l'iPhone (sorti en Juin 2007) avant même l'existence de l'App Store (sorti en Juillet 2008). Steve Jobs ne voulait même pas d'App Store

"While originally developing iPhone prior to its unveiling in 2007, Apple's then-CEO Steve Jobs did not intend to let third-party developers build native apps for iOS, instead directing them to make web applications for the Safari web browser. However, backlash from developers prompted the company to reconsider, with Jobs announcing in October 2007 that Apple would have a software development kit available for developers by February 2008. The SDK was released on March 6, 2008." (Wikipedia)

Ce n'est pas un problème de techno mais d'investissement. Que ce soit en Flash ou en HTML5, ça prend du temps de repenser l'interface, les visuels et les interactions en passant d'une plateforme à l'autre. Tu peux très bien redimmensionner un canvas à la volée mais ça ne fera pas pour autant une bonne expérience. Si tu fais un jeu de plateforme 2D pensé pour le 16/9, il ne ressemblera à rien en portrait, Flash ou pas.

Dans le web, le responsive, c'est quelque chose qu'on prévoit en amont. Ca prend du temps et c'est un investissement, mais c'est une étape obligatoire, à moins qu'il ne s'agisse d'un projet foireux. Une fois un process établi, on peut le répéter et gagner du temps. Tous les outils existants de conception et de design aujourd'hui sont pensés pour le responsive. Côté dev, même chose.

Dans le JV, c'est plus récent. Il n'y a qu'à voir l'état des jeux sur PC pendant très longtemps quand on changeait de résolution. Ou les jeux consoles tournant sur de nouvelles générations de TV. L'UI était alors pensée pour des résolutions fixes et communes, on joue -à priori- en plein écran (absolument vrai sur consoles et mobiles, moins sur PC): il n'y avait pas besoin de logique de responsive. C'est quelque chose qui a évolué avec le temps et qui commence seulement à se démocratiser. Notamment parce que la taille des écrans et la variété des résolutions se sont beaucoup plus diversifiées avec le temps. Le DPI scaling n'a été ajouté dans l'Unreal Engine 4 qu'en 2014... Venant du web: je trouve ça super tardif.

Aujourd'hui, des solutions ont été dévelopées permettant d'optimiser cette étape et de prévoir des comportements plus responsives. Et ça se ressent dans plus en plus de jeux où il est possible de customiser les éléments d'interface (changer la typo manuellement / dynamiquement en fonction des résolutions, déplacement des items, prise en compte de la safe zone, etc). En bref, ça se démocratise, parce que les outils/pratiques ont changé. L'investissement lui est devenu obligatoire (notamment parce que l'accessibilité prend -enfin- de l'importance).

Mais tout ça ne touche qu'à l'UI. En dehors de l'UI, je ne vois aucune raison pour lesquelle un jeu de plateforme en 2D ne ressemblerait rien en 16/9 ou en 4/3. Dans la plupart des moteurs, de simples réglages permette de gérer le content scaling. A moins que ton jeu 2D ne repose uniquement sur le format même de l'écran, vraiment, je ne vois pas.

Pour un jeu en 3D avec des réglages de FOV, je peux comprendre... mais ce n'est pas comme si c'était un problème difficile à régler (mis à part pour les vue FPS et/ou pour des raisons d'optimisation).

Mais pour revenir au problème initial, ce que tu dis est faux : Steve Jobs n'a pas bloqué Flash pour sauver ses 30%. Flash a été interdit dès la sortie de l'iPhone (sorti en Juin 2007) avant même l'existence de l'App Store (sorti en Juillet 2008). Steve Jobs ne voulait même pas d'App Store

Entre 2007 et la mise à l'arrêt de Flash par Steve Jobs en 2010, Steve Jobs a clairement eu le temps de changer d'avis. La preuve: l'App Store a été lancé malgré tout et surprise : ça leur a rapporté énormément d'argent. Pourquoi s'en priver ?

Even back then, just after its debut, the App Store's success surprised Jobs, who said Apple hadn't expected the App Store to "be this big." "The mobile industry's never seen anything like this," he said.

[...]

Jobs said that he didn't expect the App Store would be a big profit generator, with Apple instead launching it to add value to the iPhone. Jobs was wrong, though, and Apple's services category is the size of a Fortune 100 company, largely on the strength of the App Store. In Q2 2018, for example, services brought in $9.19 billion and the App Store set an all time revenue record.

(source)

Avec le temps, et tu peux t'en rendre compte en rematant les conf Apple qui se sont succédées, l'App Store a clairement pris de plus en plus d'importance pour Apple et le nombre d'apps est devenu un véritable argument de vente.

C'est assez dingue et je tiens à insister dessus : vendre un smartphone puissant n'était pas le seul argument, l'accès à un store où l'on pouvait PAYER EN PLUS pour des apps est devenu un argument de vente à part entière. C'est un peu WTF quand on y pense.

A l'époque, en 2007, la principale raison pour laquelle il ne voulait pas de Flash, c'était à cause de son utilisation de la batterie et les mauvaises performances qui aurait donné une mauvaise image aux iPhones. Et il avait raison.

Mais cela n'a pas empêché Android de (mal) faire tourner Flash pendant plusieurs années, tout en ayant des performances qui se sont améliorées avec le temps. Puis, la pression s'est intensifiée sur la question de Flash. Au point où plusieurs boîtes ont sorti des browsers sur iOS (Skyfire était le plus connu) permettant de d'accéder à certains contenus Flash. A cette époque, le streaming vidéo illégal était en plein boom: une menace pour le store vidéo d'Apple. Il y avait même un mode qui permettait de... streamer tout Internet et donc d'accéder à tout contenu existant sur le web (avec un lag incroyable...).

Le jour où on l'on pourra streamer tout Internet, l'App Store d'Apple tirera la tronche et c'est peut être justement le début avec ce genre de news.

Et pour en revenir à ma théorie dark futurology : la solution pour Apple sera finalement de sortir un OS mobile streamé, comme ça, plus de soucis pour leur écosystème.

Palido a écrit :
Mais tout ça ne touche qu'à l'UI. En dehors de l'UI, je ne vois aucune raison pour lesquelle un jeu de plateforme en 2D ne ressemblerait rien en 16/9 ou en 4/3. Dans la plupart des moteurs, de simples réglages permette de gérer le content scaling. A moins que ton jeu 2D ne repose uniquement sur le format même de l'écran, vraiment, je ne vois pas.

Ba prend Sonic par exemple. C'est un jeu conçu pour tourner en paysage et en 16/9 pour les versions modernes. Maintenant balance le tout en portrait en 9/18 voire en 9/19. Tu fais comment ? Soit tu croppes comme un malade et tu ne vois pas ce qui arrive soit tu dézoomes à fond et c'est illisible.

Palido a écrit :
Dans le web, le responsive, c'est quelque chose qu'on prévoit en amont. Ca prend du temps et c'est un investissement, mais c'est une étape obligatoire, à moins qu'il ne s'agisse d'un projet foireux. Une fois un process établi, on peut le répéter et gagner du temps. Tous les outils existants de conception et de design aujourd'hui sont pensés pour le responsive. Côté dev, même chose.

C'est bien ce que je dis. Et de nos jours les fournisseurs de contenu n'ont plus envie d'investir pour être responsive. Le meilleur exemple est Facebook où la version desktop est désormais la version mobile avec des gros vides au milieu.

Ba prend Sonic par exemple. C'est un jeu conçu pour tourner en paysage et en 16/9 pour les versions modernes. Maintenant balance le tout en portrait en 9/18 voire en 9/19. Tu fais comment ? Soit tu croppes comme un malade et tu ne vois pas ce qui arrive soit tu dézoomes à fond et c'est illisible

Il n'y a pas de règle absolue : ça dépend de chaque jeu. Dans ton exemple, tu ne parles que du ratio d'écran et pas de la résolution ni de taille d'écran et donc de DPI. Mais l'une des solutions peut aussi être de garder le même ratio tout en ajoutant des bandes. Le gameplay ne change pas (ou peu).

Après, ça veut pas dire que tous les jeux sont voués à être joués sur tous les écrans, c'est sûr. Mais techniquement, y a pas de raisons que ce soit tout cassé.

Le meilleur exemple est Facebook où la version desktop est désormais la version mobile avec des gros vides au milieu.

L'ancienne version de Facebook était de l'adaptative design. La nouvelle est du vrai responsive. Les deux sont coûteux en terme de conception : l'adaptative demande de penser à plusieurs "états" différents en fonction des écrans tout en gardant un semblant de contrôle sur l'allure du site, le responsive permet d'avoir une "structure unique et commune" mais est quant à elle techniquement plus compliquée à mettre en place. Et souvent -c'est le cas avec la nouvelle version-, on se retrouve avec des gros vides au milieu.

Je ne dis pas que c'est casse, juste que ça ressemblera à rien :)
Je développe pas mal de sites webGL en ce moment donc le sujet m'intéresse et je dois résoudre des tonnes de problèmes sur mobile. Mais je suis aussi super surpris des résultats.

En dehors des éléments d'UI, globalement, c'est des choix qui sont les mêmes que dans le cinéma ou à la télé : tronquer ou pas, upscaler ou pas, ajouter des bordures ou pas : en gros, comment (re)cadrer.

L'avantage dans le web ou dans le JV, c'est qu'il est plutôt courant de remplacer les bandes noires, quand le cas se présente, par de l'habillage qui rend le truc plus joli, voire même des infos utiles. Et sinon, il reste la solution ultime si tu dois jongler entre les modes portraits et paysages : empêcher l'utilisation de l'un ou de l'autre...

C'est ce qu'on du faire pour l'un d'entre eux : forcer le mode paysage. Mais du coup tu as un autre soucis : la barre d'adresse et la barre d'état qui te prend un tiers de l'écran. Pour virer le tout on force l'utilisateur à faire défiler le site vers le haut de manière fictive. Ca marche mais c'est moche.

Il y a aussi la possibilité de transformer le site en webapp fullscreen avec un raccourci qui se place sur l'écran d'acceuil, si c'est une possibilité (mais y aura d'autres conséquences, bien évidemment...).

(On commence à être hors-sujet, on risque le masquage!)

On y a pensé aussi mais je connais personne qui fait cela donc on s'est dit que l'utilisateur de base ne le ferait pas non plus

(oh t'inquiète. Au pire quelqu'un postera un message qui relancera le sujet d'origine)