+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Sites "mono-page" (/showthread.php?tid=7594)
RE: Sites "mono-page" - Xenos - 23-02-2016
@Sephi
Citation : D'autant que ne pas casser le navigateur est au cœur des frameworks cités.
Comment un framework coté serveur (le même code pour tous) pourrait-il espérer ne pas casser le comportement du navigateur qui dépend à la fois du type de navigateur (opera, firefox et IE n'ont probablement pas les mêmes façons de naviguer), du support de navigation (mobile, PC, tablette, lecteur vocal, liseuse) et des préférences utilisateurs (là, faudra m'expliquer comment elles peuvent être préservées).
Pour rappel: je parle bien des JS qui "hookent" les liens pour faire les choses à leur sauce, pas des JS qui ajoutent des balises dans le DOM (l'exemple de niahoo ne me choque pas: le JS peut ajouter des balises dans le DOM, le soucis n'est pas là: il est plutôt sur "qu'est ce qui a déclenché l'ajout de ces balises,").
@niahoo
Citation :single-page app à la seule frange des apps qui ne respectent pas les conventions du webMais comment une app single-page peut-elle "respecter les conventions web", puisqu'elle se met à gérer elle-même la notion de navigation (d'une façon que le webmaster pense être "mieux que la méthode native", mais cette "méthode native" est multiple puisqu'elle dépend du navigateur de l'utilisateur) ?
Je n'ai rien contre un site constitué d'une page (genre CV, ou http://breachattack.com/ ). En revanche, une app va souvent avoir besoin d'une notion de navigation dans l'app, et là, je trouve que l'écrasement du comportement du navigateur par la sauce-maison du site est souvent préjudiciable.
Si on se contraint à utiliser un navigateur, il me semble que c'est pour sa fonctionnalité de navigation. Sinon, autant utiliser des SDK étudiés pour développer des jeux hors-navigateur: pour y avoir déjà mis les mains, je peux vous assurer que c'est génialement adapté pour faire un jeu.
Si on ne laisse pas la navigation au navigateur, même si le jeu "tournera partout", il ne sera adapté qu'à 1 seul support. D'où les "je ferai le portage mobile plus tard" qu'on peut lire sur le forum. Si on laisse faire le navigateur, il n'y a pas de portage à faire (seulement un éventuel skin CSS).
Si on fait un Crysis dans le navigateur, okay le téléphone l'affichera, mais je doute que le jeu y soit véritablement "fonctionnel". Si on le dev sur un SDK hors navigateur, on gagne un temps fou et on peut l'adapter aux supports. L'aspect "ça marche partout" du web n'est pas due au fait d'être un site, mais au fait que le navigateur adapte automatiquement le HTML et la navigation au support.
Pour reprendre les termes de Sephi, "disponible partout, sans installation, avec des technologies simples…": les SDK hors navigateurs font pareil (même mieux).
Les jeux peuvent être plug & play (sans installation), Unity peut exporter un jeu vers un tas de supports (Neoaxis est plus limité), et ces SDK sont ultra-simples d'utilisation: on crée le jeu lui-même, sans apprendre/maintenir/gérer des trucs annexes. C'est sur que c'est "beau" de faire un L4D² dans un navigateur, mais niveau industriel, je ne vois pas l'intérêt?!
RE: Sites "mono-page" - Sephi-Chan - 23-02-2016
(23-02-2016, 02:42 PM)Xenos a écrit : @Sephi
Citation : D'autant que ne pas casser le navigateur est au cœur des frameworks cités.
Comment un framework coté serveur (le même code pour tous) pourrait-il espérer ne pas casser le comportement du navigateur qui dépend à la fois du type de navigateur (opera, firefox et IE n'ont probablement pas les mêmes façons de naviguer), du support de navigation (mobile, PC, tablette, lecteur vocal, liseuse) et des préférences utilisateurs (là, faudra m'expliquer comment elles peuvent être préservées).
Pour rappel: je parle bien des JS qui "hookent" les liens pour faire les choses à leur sauce, pas des JS qui ajoutent des balises dans le DOM (l'exemple de niahoo ne me choque pas: le JS peut ajouter des balises dans le DOM, le soucis n'est pas là: il est plutôt sur "qu'est ce qui a déclenché l'ajout de ces balises,").
Les frameworks que j'ai cité (React, Marionnette et Angular) sont tous client-side. Ils permettent — entre autre — de gérer l'aspect navigation proprement et sans aller à l'encontre des préférences utilisateurs, car ils reposent sur les API du navigateur (pushState). L'URL change quand tu navigues, le site réagit aux événements précédent/suivant, et selon tes préférences si tu ouvres dans un autre onglet, etc. Le développeur n'a rien à hardcoder : il laisse faire le navigateur.
En plus, tu focalises la question sur le seul problème de la navigation, alors que la plupart des jeux n'ont même pas besoin de gérer cet aspect navigation. Le plus souvent, les sites proposent une page de jeu sur laquelle tout se passe.
Pour toi qui joue à Dévotion, tu ne joues que sur une page qui contient plein de choses et qui change dynamiquement selon l'état du jeu. En quoi est-ce une mauvaise utilisation du support navigateur (j'exclue tout ce qu'Argorate voudrait t'empêcher de faire dans TON navigateur : on ne peut pas blâmer l'outil pour quelques développeurs pénibles) ?
(23-02-2016, 02:42 PM)Xenos a écrit : Si on se contraint à utiliser un navigateur, il me semble que c'est pour sa fonctionnalité de navigation. Sinon, autant utiliser des SDK étudiés pour développer des jeux hors-navigateur: pour y avoir déjà mis les mains, je peux vous assurer que c'est génialement adapté pour faire un jeu.
Si on ne laisse pas la navigation au navigateur, même si le jeu "tournera partout", il ne sera adapté qu'à 1 seul support. D'où les "je ferai le portage mobile plus tard" qu'on peut lire sur le forum. Si on laisse faire le navigateur, il n'y a pas de portage à faire (seulement un éventuel skin CSS).
Si on fait un Crysis dans le navigateur, okay le téléphone l'affichera, mais je doute que le jeu y soit véritablement "fonctionnel". Si on le dev sur un SDK hors navigateur, on gagne un temps fou et on peut l'adapter aux supports. L'aspect "ça marche partout" du web n'est pas due au fait d'être un site, mais au fait que le navigateur adapte automatiquement le HTML et la navigation au support.
Pour reprendre les termes de Sephi, "disponible partout, sans installation, avec des technologies simples…": les SDK hors navigateurs font pareil (même mieux).
Les jeux peuvent être plug & play (sans installation), Unity peut exporter un jeu vers un tas de supports (Neoaxis est plus limité), et ces SDK sont ultra-simples d'utilisation: on crée le jeu lui-même, sans apprendre/maintenir/gérer des trucs annexes. C'est sur que c'est "beau" de faire un L4D² dans un navigateur, mais niveau industriel, je ne vois pas l'intérêt?!
J'ai quelques questions pour toi :
- Est-ce que les outils deviennent caduques dès lors qu'un autre est adapté à la tâche ?
- N'a-t-on pas le droit de détourner l'usage initial d'un outil ?
- Pour bien des jeux, le support navigateur convient très bien : pourquoi changer ?
- Pourquoi apprendre à utiliser Unity (et la stack technologique qui va avec) quand on peut faire un jeu dans le navigateur avec des technologiques qu'on maîtrise déjà ?
- Pourquoi s'embêter à publier des applications sur divers supports (avec les délais de mise à jour) alors qu'un site permet à chacun de venir sur une version toujours à jour ?
RE: Sites "mono-page" - Xenos - 23-02-2016
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?
Oui, je me focalise sur le problème de la navigation parce que c'est la question de ce topic. Et 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.
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).
• Non, ils ne sont pas caduques, mais il me semble que les SDK de dev de jeux hors-navigateur sont plus récents que les technos/frameworks que t'as cité... Donc je ne comprends pas cet argument?!
• 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
• Pour bien des jeux "à formulaires/tableaux", oui, cela convient et c'est adapté. Pour ces jeux qui veulent tout piloter dans leur frame, j'en doute...
• C'est vrai: pourquoi utiliser Inkscape pour dessiner quand on sait coder du SVG/XML... Il me semble aussi avoir vu passer l'argument "quand on fait soit-même des AJAX, le monopage est pourri mais il ne l'est pas quand on apprend le framework 'bidule'" : donc ceux ne connaissant pas déjà ces frameworks devraient plutôt apprendre à utiliser ces SDK plutôt que les frameworks?
• Ca, t'es pas obligé de le faire dans un navigateur: c'est la différence entre un jeu par navigateur (qui s'exécute dans le navigateur) et un jeu par internet (qui utilise le réseau internet). Ton jeu fait par SDK peut très bien se mettre à jour tout seul, et tu te retrouves juste avec un hébergement web statique (cool, c'est moins cher en plus!) hébergeant les ressources du jeu.
RE: Sites "mono-page" - Sephi-Chan - 23-02-2016
(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.
RE: Sites "mono-page" - Argorate - 24-02-2016
Qu'es ce que tu dirais de TMI... :p
ma page de jeu c'est (outre le <head>) :
Code :
<body><div data-view="game/index"></div></body>Tout mon jeu sera mono page et créer en JS et à la demande en plus ! (idem pour l'admin d'ailleurs).
C'est bien plus malin de restreindre les échanges client-serveurs quand ils sont inutiles. Dans le cadre d'un jeu (tel que je les conçoi), le but est 0 rechargement de page.
Plutôt que d'avoir des view en code serveur, qui en plus doivent être transporter sur le réseau (ce qui pollue la planète au passage), je les met en JS, je les envoi une seule fois et c'est en cache, terminé. Si le joueur viens régulièrement, le cache ne sera jamais vider car utilisé quotidiennement.
Quand a ton argument du cas de la mise à jours du JS, je pense qu'en prod, on doit rendre ça le plus rare possible et regrouper les MAJ JS en une seule grosse MAJ, que d'en faire plein de petite bien sur.
Sinon, il y a turbolinks que j'utilise sur jepolitique.fr par exemple (je t'en avais déjà parlé), qui permet de faire de la "mono-page" multi-page, puisqu'il change l'url via le JS et donc permet d'utiliser les fonctionnalités standards du navigateur (précédent, suivant) comme si tu avais changer de page, alors que tout est rafraichie en AJAX et que tu ne recharges justement jamais ton site (ce qui encore une fois, est bien plus malin, et bien plus rapide, y a qu'à voir le temps de chargement d'une page sur jepolitique et la comparer a n'importe quel site standard, je les pulvérise^^ J'utiliserai d'ailleurs ce procéder pour les pages autre que la page de jeu pour TMI).
Donc pour moi les "mono page" avec ce genre de cheat sont plus l'avenir qu'un méfaits. Le réseau serait bien plus alléger et performant si tous les sites étaient ainsi fait
RE: Sites "mono-page" - Xenos - 24-02-2016
D'accord, Sephi, je croyais que tu parlais de Framework qui vont justement altérer comment régissent les liens. Donc, ok, je redis: pas de soucis pour ajouter des balises DOM à la volée. Maintenant, ma question est: quelles conditions/causes (chez vous) entraînent l'apparition de ces nouvelles balises?
Dans un jeu "classique" (hors navigateur), oui, je m'attends à devoir réapprendre les contrôles de chaque jeu, pas de soucis.
En revanche, dans un navigateur, nope, je ne m'attends pas à devoir ré-apprendre la navigation au sein de chaque site. Je suis peut-être extra-terrestre sur le coup, mais bon... En tant qu'utilisateur, cela me gonfle de voir un site réagir à sa sauce aux évènements de navigation (clique/ou autre sur les liens par ex).
Je ne vois pas en quoi il serait plus dur d'apprendre à coder grâce à un des framework que tu cites que d'apprendre à utiliser les softs des SDK. Et tu as la même facilité de distribution d'un jeu via navigateur ou via SDK (s'il gère la mise à jour auto du jeu, ce qu'ils peuvent maintenant faire).
Je n'arrive pas à comprendre en quoi "faire 0 changement de page web", c'est bien? En quoi "coder des trucs dans mon jeu pour faire le boulot de la couche réseau", c'est bien (que ce soit un FW ou pas)? Si on ne veut transporter que les données, pourquoi pas faire du XML/XSL (qui ne touche pas à la façon de naviguer)? Un lecteur d'écran n'est pas perdu quand du JS altère le DOM? Il n'y a jamais eu de "collision" d'id (deux éléments d'un même ID dans la page)? Comment cela se passe si je clique un lien "hooké" par le JS, et que je perds le réseau? Ou qu'il est lent? Je peux faire "echap" et retrouver l'état de la page avant le clique? Ou cliquer ailleurs?
"Je les pulvérise": je demande à en voir la métrique. Entre compression, headers, cache client, CDN, et rendus progressifs, je ne serai pas aussi catégorique.
(PS: je redis, c'est hyper-basé sur l'opinion, j'en suis conscient, mais en tant qu'utilisateur, je n'aime vraiment pas les sites qui veulent me ré-apprendre à naviguer chez eux)
RE: Sites "mono-page" - MadMass - 24-02-2016
Comment vous faites en mono-page si y'a une coupure de connexion sur une requête ajax par exemple ? Pour éviter que tout le js qui tourne bien parte en carafe ? ^^
RE: Sites "mono-page" - niahoo - 24-02-2016
Bah tu affiches que la connexion a été perdue, et tu poll ton serveur pour voir quand elle est revenue et reprendre où tu en étais.
Pour le coup c'est plus sympa qu'un changement de page qui va juste tourner à vide 30 secondes (ou 0 selon le type de déconnexion) puis afficher une page d'erreur indiquant que le site est disponible.
RE: Sites "mono-page" - Sephi-Chan - 24-02-2016
(24-02-2016, 03:29 PM)Xenos a écrit : D'accord, Sephi, je croyais que tu parlais de Framework qui vont justement altérer comment régissent les liens. Donc, ok, je redis: pas de soucis pour ajouter des balises DOM à la volée. Maintenant, ma question est: quelles conditions/causes (chez vous) entraînent l'apparition de ces nouvelles balises?
Les nouvelles balises peuvent arriver par exemple quand j'ouvre un panneau de jeu.
(24-02-2016, 03:29 PM)Xenos a écrit : Dans un jeu "classique" (hors navigateur), oui, je m'attends à devoir réapprendre les contrôles de chaque jeu, pas de soucis.
En revanche, dans un navigateur, nope, je ne m'attends pas à devoir ré-apprendre la navigation au sein de chaque site. Je suis peut-être extra-terrestre sur le coup, mais bon... En tant qu'utilisateur, cela me gonfle de voir un site réagir à sa sauce aux évènements de navigation (clique/ou autre sur les liens par ex).
Je dirais plutôt que tu es très fermé sur ce qu'on peut faire ou non d'un navigateur. J'ai l'impression que tu ne conçois pas que le site Web n'est qu'un conteneur pour le jeu : le jeu existe dans cette page et vient avec ses propres contrôles, qui sont largement communs avec ceux de la page Web, avec éventuellement quelques différences.
Tu t'acharnes sur ce point de la navigation alors que c'est qu'un tout petit bout de la question : la plupart des jeux n'ont pas besoin de lien ou de navigation, donc au mieux on n'y touche même pas, au pire on se fout de la casser.
Il faut être pragmatique : la doctrine "c'est un navigateur donc tout ce qui s'y passe doit avoir trait à la navigation" n'a pas de raison d'être.
(24-02-2016, 03:29 PM)Xenos a écrit : Je ne vois pas en quoi il serait plus dur d'apprendre à coder grâce à un des framework que tu cites que d'apprendre à utiliser les softs des SDK.
Quand tu développes pour le Web, tu apprends à utiliser Javascript et tu peux t'en resservir partout. Ce n'est pas le cas de chaque technologie de SDK.
Si tu apprends l'API de React, tu pourras t'en reservir sur plein de sites, qu'ils soient des jeux ou non.
Tu pourras même t'en servir pour développer des applications pour mobiles (via React Natives) ! Ce sont des compétences portables.
(24-02-2016, 03:29 PM)Xenos a écrit : Je n'arrive pas à comprendre en quoi "faire 0 changement de page web", c'est bien? En quoi "coder des trucs dans mon jeu pour faire le boulot de la couche réseau", c'est bien (que ce soit un FW ou pas)? Si on ne veut transporter que les données, pourquoi pas faire du XML/XSL (qui ne touche pas à la façon de naviguer)? Un lecteur d'écran n'est pas perdu quand du JS altère le DOM? Il n'y a jamais eu de "collision" d'id (deux éléments d'un même ID dans la page)? Comment cela se passe si je clique un lien "hooké" par le JS, et que je perds le réseau? Ou qu'il est lent? Je peux faire "echap" et retrouver l'état de la page avant le clique? Ou cliquer ailleurs?
"Je les pulvérise": je demande à en voir la métrique. Entre compression, headers, cache client, CDN, et rendus progressifs, je ne serai pas aussi catégorique.
Et inversement, en quoi faire recharger la page est bien ? Tu trouves ça joli et immersif une page qui clignote en se rechargeant ?
C'est sympa un canal de discussion qui recharge la page à chaque message que tu envoies ? C'est sympa de recharger la page pour voir les nouveaux messages ?
Tu ne fais pas le boulot de la couche réseau, tu envoies des requêtes (très légères) et tu reçois des réponses (très légères), puis tu réagis en fonction.
(24-02-2016, 03:29 PM)Xenos a écrit : (PS: je redis, c'est hyper-basé sur l'opinion, j'en suis conscient, mais en tant qu'utilisateur, je n'aime vraiment pas les sites qui veulent me ré-apprendre à naviguer chez eux)
Je serais curieux de connaître des cas pratiques où ça t'a gêné. Pour le moment, ça ressemble plus à une religion.
Je trouve ça inquiétant et vraiment malsain de renoncer à toute créativité pour un dogme.
(24-02-2016, 03:32 PM)MadMass a écrit : Comment vous faites en mono-page si y'a une coupure de connexion sur une requête ajax par exemple ? Pour éviter que tout le js qui tourne bien parte en carafe ? ^^
Les callbacks des appels ne sont simplement pas exécutés. A chacun de choisir une façon de le gérer. Par exemple, si on fait un jeu où on se déplace de case en case, on a souvent tendance à commencer le mouvement dès l'envoi de la requête, pour que ça paraisse plus rapide, il faut donc ici faire revenir le personnage à sa place initiale si on a pas de réponse du serveur dans les X secondes.
Sur un site "à rechargement", on tomberait sur la page d'erreur du navigateur et il faudrait faire précédent.
RE: Sites "mono-page" - L'Omniscient - 24-02-2016
Wha, bah dis donc, je savais pas que mes messages avaient provoqué tout ça xD
Xenos et cette haine viscérale du JS ! xD
Bon alors, tout d'abord, perso, je comptais faire une version mobile différente pour un soucis marketing, pas du tout d'adaptation mobile.
Et de toute façon, étant donné ma mise en page, une adaptation mobile un minimum jouable aurait demandé une profonde refonte du design. (Je dois déjà adapter le menu sur des écrans à moins de 800 px je crois un truc comme ça).
Sur ma mono-page ya pas de scroll, j'ai inséré un bouton pour jouer facilement en plein écran (donc en oubliant toutes les fonctionnalités navigateurs), et surtout, si j'ai fais du monopage, c'est parce que j'ai pensé mon jeu style jeu-vidéo, sans les contraintes du navigateur (parce que le côté navigateur fait perdre une certaine immersion tout de même, avec les onglets qui clignotent, le facebook qu'on va voir etc).
La possible présence du navigateur permet tout de même une facilité d'accès si on veut y aller vite fait voir ce qui a changé dans le jeu. (Après ya certes un petit temps de chargement à attendre, mais au final, pas plus long qu'une page web classique.)
J'ai aussi fait en sorte qu'il y ait le moins de boutons possible et que l'interface soit le plus épurée possible. Sur un site web, lorsqu'on passe d'une page à une autre, on a quand même plus la sensation d'être au même endroit, et on est parfois dérouté, du simple fait du changement visuel de la page entre deux chargements de page. Après, tout ce qui est site annexe, informations sur les administrateurs ou ce genre de choses, c'est sur la pate-forme web.
Si on prend par exemple : http://www.heroic-fantasy.fr/
Evidemment, je trouve que ce n'est pas du tout adapté à du monopage. Un site / jeu se construit selon son contenu. En plus, la fonction précédant du navigateur provoque parfois des bugs d'actualisation, ou pareil, avoir plusieurs onglets, tu n'as pas les informations actualisées, donc tu fais parfois des actions JS sur une page non actualisées qui ne fonctionnent pas puisque tu as fait d'autres actions sur d'autres pages (donc en terme d'optimisation pour le joueur c'est pas idéal non plus le multi pages hein).
D'autre part, pour une connexion lente, c'est peut-être plus agréable de recharger une seule fois la page et de pouvoir y jouer que de charger plein de fois des contenus de page. (Expérience vécue aussi).
Après oui, pour la deconnexion, un petit message comme le dit niahoo c'est très bien.
J'ai un peu la même conception du jeu qu'Argorate (bon après pour le tous les sites web en JS c'est autre chose xD).
Par contre Argorate, j'ai pas pris en compte le cache.
Si tu met à jour un code JS d'une page web, il va conserver ce qui est en cache plutôt que d'actualiser ? Comment forcer le cache à se réinitialiser ?