23-02-2016, 06:03 PM
(Modification du message : 23-02-2016, 06:09 PM par Sephi-Chan.)
(23-02-2016, 05:07 PM)Xenos a écrit : Donc ton framework JS qui gère les liens à sa sauce est capable de savoir que j'ai réglé mon navigateur pour que les liens & formulaires d'un domaine donné s'ouvrent tous dans le même onglet? Les liens <a> qu'il va ajouter se comporteront normalement, ok, mais les liens que le framework va "piloter" à sa sauce suivront la bonne règle (aka, celle donnée par l'utilisateur)? Ou genre si je configure les liens vers des images pour qu'elles s'ouvrent dans ma visionneuse habituelle, le framework JS le saura?
Le framework n'en sait rien et s'en fout : il crée des liens standards, point. Si tu crées un lien vers rien du tout pour ouvrir un pop-in, alors oui ce n'est pas un lien standard et le développeur aurait mieux fait d'utiliser une autre balise.
(23-02-2016, 05:07 PM)Xenos a écrit : Heu, oui, je me focalise sur le problème de la navigation parce que c'est la question de ce topic. Et heu, oui, "les jeux font tous eux-même dans une page à leur sauce", c'est un peu le soucis: la navigation dans le jeu est dictée par le jeu au lieu d'être du ressort du navigateur.
Personne n'a dit que la navigation était le sujet. Tu as séparé le sujet (à raison) parce que tu voyais venir un hors sujet sur le fait que tout se déroule sur une même page. Je cite :
(17-02-2016, 11:39 AM)LOmniscient a écrit : Autre précision : tout se déroule sur la même page, que du JS et de l'actualisation Ajax, pas de rechargement.
Tu as donné ton avis en indiquant que tu y voyais surtout la perte de la navigation. Très bien, mais tout n'a pas besoin de tourner autour de ça. D'autant qu'au final, il y a très peu de comportements que le site-jeu peut surcharger. C'est dommage de jeter le bébé avec l'eau du bain.
(23-02-2016, 05:07 PM)Xenos a écrit : Si on prend l'exemple de DVO (je n'y suis plus mais bon), il ne me semble pas possible d'ouvrir, par exemple, les "pop-in" dans de nouveaux onglets. Ou de faire un "précédent" dans une pop-in. Parce que le site fait les choses à sa sauce JS (franchement, c'est pas le pire).
• T'as le droit, j'ai jamais dit le contraire. Seulement, d'un point de vue d'utilisateur, je trouve cela ch*ant de devoir "réapprendre" à naviguer à chaque site que je visite
Quand la page Web présente un plateau de jeu interactif, je pense que tout le monde est capable de faire la part des choses et comprendre qu'il est sur un jeu, et plus sur un simple site Internet.
Quand tu joues à un jeu vidéo tu admets ne pas pouvoir transposer tout ce que tu fais sur les autres jeux : tu n'attends pas que les contrôles de la manette dans Dark Souls se comporte de la même manière que dans Gran Turismo : ce n'est pas le même jeu. Même au sein d'un genre similaire — disons Starcraft et Age of Empires — tu as des divergences, mais également beaucoup de points communs.
Dans un jeu par navigateur, c'est pareil, tu dois effectivement apprendre à utiliser le jeu — et pas réapprendre à naviguer sur le site — même si le support de ce jeu est un site Web classique, qui lui fonctionne normalement.
Je sens beaucoup de mauvaise foi dans le reste des réponses, donc je vais y répondre globalement :
Créer un jeu via un SDK quelconque requiert d'apprendre des technologies supplémentaires : tout le monde ne souhaite pas se lancer dans de tels apprentissages, à plus forte raison quand les technologies Web classiques répondent aux besoins. Et en effet, les navigateurs sont bien suffisants pour beaucoup de jeux : même des jeux avec un écran de jeu unique. Que l'écran de jeu change ou que l'on change de page, ça n'a finalement pas grande importance.
Enfin, un jeu par navigateur requiert forcément un moindre de travail de distribution qu'un jeu distribué via l'export d'un SDK, un App Store ou autre. Et à moins d'un jeu solo ou multi en peer-to-peer, il te faudra de toute façon un serveur, que les communications reposent sur HTTP ou non.