[PHP/SQL] Système de vêtements

[Shao]

Je me posais une question à propos de la mise en cache de l'image. Est ce qu'il n'y a pas des risques que si le joueur en question modifie son skin et que les autres joueurs l'ont déjà vu, le skin ne soit pas modifié pour ceux qui l'ont déjà regardé une première fois ?
Tout dépend en fait comment sera identifié le skin du joueur. Ca veut dire que dans le nom de l'image du skin, il faut un paramètre variable (la date de dernière modification par exemple).

Au moins avec les CSS, le problème ne se pose pas, si on change d'armure, on change d'identifiant d'image et donc pas de problème de cache. :p

[wild-D]

- enfin l'image de "son perso" elle à un gôut différent si on a 10 combinaison possible pour 10000 joueurs, ou à l'inverse 1'000'000 combinaison pour 10 joueurs/sur la map.

marrant j'ai aussi le pb en cours d'étude (ça a l'air d'être un indispensable des jeux).


quand à la bande passante c'est aussi le même problème; si c'est juste pour ton perso; ou si c'est pour tous les perso de la map avec du multi-perso par case et une map plein écran, on n'a pas le même soucis en fonction du panel de combinaison possible 10 ou 10M ?.

pour moi du css c'est un id ou une class dans le xhtml et c'est tout (et pas des styles="et ici 3 tonne de déf de style" avec des div inclu les un dans les autre avec ce genre de def de style à rallonge)

donc en xhtml strict t'as juste un <div class="AXX BXX CXX DXX EXX"><div/><div/><div/><div/></div>; c'est pas franchement plus lourd que du <img src="img/AABBCCDDEE.jpg" alt=""/>

p.s.
et je parle même pas de construction coté client.(parce qu'après tout pourquoi le faire sur le serveur si on envoie les image sous forme de brique au client)

[Holy]

Je rajouterai à ce qui a déjà été dit par Oxman et wild-D que l'image générée dynamiquement n'est pas mise automatiquement dans le cache du navigateur, donc la bande passante explose

Et même dans une solution de type génération de tous les vêtements possibles grâce à un petit script et enregistrement des images dans un dossier, chaque fois que tu modifieras un élément de ton équipement, ça te balance une nouvelle image, donc paf la bande passante ^^

Et encore une dernière chose, le problème des proportions est le même que pour la génération d'images non ?

Personnellement j'utilise les librairies d'image uniquement de manière ponctuelle pour des graphismes par exemple (mis à jour tous les x temps), ou pour des travaux légers.

[wild-D]

Je rajouterai à ce qui a déjà été dit par Oxman et wild-D que l'image générée dynamiquement n'est pas mise automatiquement dans le cache du navigateur, donc la bande passante explose

en envoyant le bon header; elle sera mise en cache comme n'importe quelle image statique.
C'est juste que par défaut la majorité des serveur sont configuré pour envoyer pour les script php un header pour éviter la mise en cache. Donc si on oublie de faire ce qui faut...

[Holy]

Je rajouterai à ce qui a déjà été dit par Oxman et wild-D que l'image générée dynamiquement n'est pas mise automatiquement dans le cache du navigateur, donc la bande passante explose

en envoyant le bon header; elle sera mise en cache comme n'importe quelle image statique.
C'est juste que par défaut la majorité des serveur sont configuré pour envoyer pour les script php un header pour éviter la mise en cache. Donc si on oublie de faire ce qui faut...

Wep, il faut la passer en 304 ^^

Mais ça a aussi des inconvénients que Shao a cité plus haut, la mise en cache peut créer des décalages selon les joueurs, c'est pas très cool et pas toujours flexible.

[keke]

Coucou,

Sur d'autres projets, j'utilise la génération d'image via GD , que je sauvegarde juste après la validation de l'utilisateur.
Je pense qu'il s'agit d'un Optimum entre ressource, hit et touti quanti. En effet, il n'y aura jamais 1000 utilisateurs modifiant au même moments son image, et par ailleurs, une fois sauvegardé, l'image ne prend aucun temps à être recalculée.
Elle peut alors être réduite à volonté pour des besoins précis voir même sauvegardé en grand et petit format.

Bref. J'avais par ailleurs fais un script sur des têtes de mon jeu ... mais j'avais abandonné faute de graphismes.

Kéké

[Roworll]

Confronté au même problème, j'avais aussi opté pour la superposition d'images plutôt que la construction "à l'avance".
Dans l'absolu, j'avais
- 6 races
- 9 types d'armure
- 4 orientations possibles
- 12 armes possibles pour la main gauche
- 12 armes possibles pour la main droite
- 8 armes à 2 mains
- 10 cultures
Le tout multiplié par 2 (hommes et femmes) soit 656 640 combinaisons possibles, réalisables à tout moment, chacune pouvant être partagée par plusieurs joueurs.
Rien que la taille sur le disque m'a fait reculer.

Au final, j'ai donc choisi la superposition d'images avec la possibilité d'installer un pack graphique (mettre les images en local) pour les plus téméraires.

Le pack graphique local a quelques gros avantages
- Un temps de chargement beaucoup plus rapide
- Réduction du trafic sur le serveur
- Possibilité pour l'utilisateur de faire ses propres packs

Pour les désavantages
- Demande quelques manipulations de la part de l'utilisateur pour l'installation et les modifications
- Inutilisable entre autres sous Opera sans bidouilles plus pointues

[Allwise]

C'est quoi ces packs graphiques ?
Dans ton problème, y a beaucoup de possibilités mais faut les nuancer avec la probabilité qu'elles soient toutes satisfaites. Ca pourrait être intéressant d'ailleurs, de savoir combien de possibilités existent pour x joueurs.

Bon sinon, l'autre jour j'étais parti dans l'idée de gérer les images côté serveur, donc j'ai pris un peu de temps et j'ai développé ça.
Je crée un nouveau topic, si ça dérange je reposterai dans celui-ci.