24-02-2016, 06:34 PM
Citation :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.Perso, je trouve que c'est justement du ressort du navigateur de faire cela, l'avantage étant la possibilité de fournir une version en cache (ou d'avoir un plugin navigateur bloquant les liens quand on a perdu la connexion: cela revient à ce que ce site web fait, sauf que c'est auto-porté sur tous les sites car dans le navigateur et non dans chaque site).
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.
Citation : Les nouvelles balises peuvent arriver par exemple quand j'ouvre un panneau de jeu.Du coup, pour moi, là, on est dans de la navigation. Et je préfère avoir la possibilité d'ouvrir ce panneau de jeu dans un autre onglet (histoire de bénéficier du multi-écran par exemple).
Citation : tu ne conçois pas que le site Web n'est qu'un conteneur pour le jeuC'est tout à fait cela.
Et d'accord, L'Omniscient l'a plutôt bien formulé: ok, vous aimez bien l'idée de perdre de vue le fait d'être dans un navigateur. Perso, j'aime bien le garder. Cela peut venir du fait qu'avec plusieurs écrans, le navigateur est à gauche et non au centre (les jeux usuels sont au centre en revanche).
@Argorate:
si tu veux vraiment réduire l'impact réseau, il me semble bien plus efficace de faire un jeu hors-navigateur qui enregistrera les choses en dur sur le disque plutôt que de risquer leur re-téléchargement régulier, genre en cas de F5. Si tu configures proprement les choses (headers de cache et d'expiration), ton serveur ne sera même pas recontacté pour récupérer les CSS. Le même procédé s'applique si tu passes par un XSL comme patron de page. Ainsi qu'aux JS (et autres ressources genre PNG) Leur re-téléchargement peut être forcé en changeant l'URL (type ?v=2.0).
Les lags d'un jeu pas-par-navigateur me semble quand même nettement plus faibles (connexion persistante & protocole adapté). Si quelqu'un a une métrique là-dessus, je suis preneur.
Je ne dis pas le contraire: XSL est "verbeux" (cela reste quand même pas si dément que cela). Mais cela se compresse. L'avantage est de séparer ce template XSL du reste du site.
Citation : donc la première fois c'est le JS qui permettra de créer le DOM selon sa navigationBen justement: pour moi, cela se trouve déjà dans le navigateur ça.
Citation :Soit tu les envois en texte brut avec un syntaxe que tu fais toi même, sois tu sérialises en JSON car c'est fait pour et directement traduisible en JS.Soit tu les envoies en XML que le navigateur interprétera nativement avec le XSL gardé en cache (mais je m'éloigne)
Pour ta comparaison avec Yahoo, faut pas déconner ^^
Yahoo regorge d'images dans tous les sens: normal que le temps de chargement soit long. Une vraie comparaison comparerait le même si avec les deux structure.
Tiens, cool, je vais pouvoir lancer une autre question: si votre site est fait en JS qui récupère des données JSON, les traite et les fous dans le DOM, comment faites-vous pour permettre aux joueurs de "skinner" le jeu? Ok, ils peuvent changer la présentation CSS, mais comment feriez-vous pour le permettre de vraiment skinner le jeu, et de changer
Code :
<div id="character">
<div class="carac">
<div id="hp">100/100 <span class="icon-hp></span></div>
<div id="mp">200/200 <span class="icon-mp></span></div>
</div>
</div>
en
Code :
<meter min="0" max="100" value="100"/>
<meter min="0" max="200" value="200"/>
?
perso, j'aime bien l'idée de me laisser la possibilité de séparer le "skin" du jeu, et de permettre aux joueurs de faire le leur, de le partager et d'utiliser ceux des autres (un peu comme Ogame le faisait... POINT GODWIN DU JEU WEB !)