01-04-2010, 06:30 PM
dans mon premier "essai" (vu que je refonds tout) j'étais parti sur une méthode intermédiaire :
j'avais une seule page qui portait tout le jeu
celui ci se basant sur des onglets (des div quoi), des menus et descriptions (tes "popup")
A l'origine (mais je n'avais pas encore fait les calculs du niveau de chargement initial) je ne chargeais que ce qui était visible, soit la page, le premier onglet et aucune "popup" (div) ou "aide en ligne" ou autre
ensuite l'expérience utilisateur :
on regarde le descriptif/aide/popup diverse : alors soit le div existe déjà, soit une requête ajax récupérant plusieurs données (pour réduire le nombre de requêtes sql)
Exemple (cherchez pas c'est une illustration) :
j'ai des caractéristiques (force, endu, etc..)
j'ai des barres d'énergie (vie/mana/etc...)
j'ai des objets (épée, fiole, etc..)
j'ai des décors (arbre, maison, ...)
dans mon modèle, ces quatre familles correspondent à 4 tables complètement différentes (pour simplifier)
1) le joueur passe sa souris sur la barre de vie :
js s'aperçoit que l'aide n'existe pas, il fait une requête ajax et récupère toutes les infos de vie, mana, etc... puis crée les div correspondantes, enfin affiche les infos de la barre de vie
2) le joueur passe sa souris sur la barre de mana :
js s'aperçoit que l'aide existe, il affiche le div
3) le joueur passe sa souris sur un arbre
js s'aperçoit que l'aide n'existe pas, il fait une requête ajax et récupère toutes les infos qui vont bien. La on peut imaginer ne faire une requete avec une clause " where type in (les types affichés et visibles par le joueur) " afin d'éviter de ramener les infos de "la super épée qui tue que personne connait encore mais qui est en base"
4) sur le rocher
ben ça a été chargé et donc il suffit de s'afficher
si le joueur ne regarde pas les caractéristiques, elles n'auront jamais été chargé
maintenant, à relativiser, mais c'est vers cela que j'irai avec les réflexions suivantes :
1) ca évite de faire 100 requêtes ajax pour les 100 objets de l'inventaire, si noeudnoeud passe la souris sur chaque (je connais des noeudnoeud qui le font, genre moi)
2) à voir par l'étude ou le postulat, il est certainement pertinent de charger directement certaines infos, celles tout le temps regardées
3) découper au bon niveau : si récupérer les données de 100 objets c'est énormes, ben n'en récupère que 20, segmente par la classe ou autre chose
et enfin 4) déjà dit plus haut, si ca ne rajoute que 1ko autant tout ramener
j'avais une seule page qui portait tout le jeu
celui ci se basant sur des onglets (des div quoi), des menus et descriptions (tes "popup")
A l'origine (mais je n'avais pas encore fait les calculs du niveau de chargement initial) je ne chargeais que ce qui était visible, soit la page, le premier onglet et aucune "popup" (div) ou "aide en ligne" ou autre
ensuite l'expérience utilisateur :
on regarde le descriptif/aide/popup diverse : alors soit le div existe déjà, soit une requête ajax récupérant plusieurs données (pour réduire le nombre de requêtes sql)
Exemple (cherchez pas c'est une illustration) :
j'ai des caractéristiques (force, endu, etc..)
j'ai des barres d'énergie (vie/mana/etc...)
j'ai des objets (épée, fiole, etc..)
j'ai des décors (arbre, maison, ...)
dans mon modèle, ces quatre familles correspondent à 4 tables complètement différentes (pour simplifier)
1) le joueur passe sa souris sur la barre de vie :
js s'aperçoit que l'aide n'existe pas, il fait une requête ajax et récupère toutes les infos de vie, mana, etc... puis crée les div correspondantes, enfin affiche les infos de la barre de vie
2) le joueur passe sa souris sur la barre de mana :
js s'aperçoit que l'aide existe, il affiche le div
3) le joueur passe sa souris sur un arbre
js s'aperçoit que l'aide n'existe pas, il fait une requête ajax et récupère toutes les infos qui vont bien. La on peut imaginer ne faire une requete avec une clause " where type in (les types affichés et visibles par le joueur) " afin d'éviter de ramener les infos de "la super épée qui tue que personne connait encore mais qui est en base"
4) sur le rocher
ben ça a été chargé et donc il suffit de s'afficher
si le joueur ne regarde pas les caractéristiques, elles n'auront jamais été chargé
maintenant, à relativiser, mais c'est vers cela que j'irai avec les réflexions suivantes :
1) ca évite de faire 100 requêtes ajax pour les 100 objets de l'inventaire, si noeudnoeud passe la souris sur chaque (je connais des noeudnoeud qui le font, genre moi)
2) à voir par l'étude ou le postulat, il est certainement pertinent de charger directement certaines infos, celles tout le temps regardées
3) découper au bon niveau : si récupérer les données de 100 objets c'est énormes, ben n'en récupère que 20, segmente par la classe ou autre chose
et enfin 4) déjà dit plus haut, si ca ne rajoute que 1ko autant tout ramener