12-04-2008, 09:37 PM
Bonsoir à tous,
Je profite de cette belle catégorie pour poser une question qui m'enquiquine un peu en ce moment. Mais tout d'abord explications!
Voilà, dans mon projet de jeu, j'ai un chat intégré. Un chat particulier dans le fait qu'il est différent suivant la zone dans laquelle le personnage se trouve. C'est un peu comme les canaux IRC en gros. On est dans une auberge, c'est un chat propre à l'auberge, on va dehors, zoup on change de chat, pour trouver celui de la place de la ville (par exemple).
Jusque là, pas très compliqué. Mais vu que ce chat en question est réactualisé automatiquement par JS toutes les 5 à 10 secondes (ça reste encore à définir), je cherche à faire quelque chose d'assez optimisé pour éviter de faire planter tout ça.
J'ai déjà plusieurs idées sur le sujet, je vous les expose ici :
1 - Tout stocker dans la même table "chat" de ce style là :
|id_message|id_zone|id_joueur|texte|date
2 - Stocker chaque "canal" différent sur une table différente (du nom chat_zone_id) avec ce schéma-là :
|id_message|id_joueur|texte|date
3 - Stocker chaque canal différent dans des fichiers texts différents (du nom zone_id dans le dossier chat/ par exemple) avec pour chaque ligne ces infos :
id_joueur | texte | date
4 - Il y a surement d'autres possibilités que je ne connais pas...
Si on étudie les 4 méthodes en détail, on peut y dégager quelques inconvénients/avantages pour chacune d'elle :
1 - Avantage : tout est stocké dans la même table, pas de souci en cas de rajout de nouvelles zones. La table deviendra un peu lourde, mais un nettoyage de celle-çi sera de toute façon appliqué, supprimant tous les messages datant de plus de deux heures. Inconvénient : Je trouve qu'il y a une certaine lourdeur dans la requete qui demande une condition WHERE pour récupérer les bons messages. Si on compte par dessus une requete pour récupérer le nom du joueur à partir de l'id (bon ça se fait par une jointure SQL mais bon...). Imaginons qu'il y ait 400 joueurs online, qui rafraichissent dans leur coin cette requete toutes les 5 à 10 secondes...
2 - Avantage : pas de clause WHERE dans la requete initiale (même si la jointure reste indispensable pour récupérer le nom et le profil de ceux qui parlent). Inconvénient : Ma ville de départ comprenant déjà une trentaine de zones différentes, alors que le reste du monde n'est pas encore ajoutée, j'ai peur de crouler sous les tables chat_zone_id dans PHPMyAdmin, et donc d'avoir une "légère" gêne niveau update, sauvegarde, etc... de la BDD.
3 - On se passe de mysql pour la première requete, mais on en a toujours besoin (à moindre mesure, je suis d'accord), pour récupérer les profils. Ce que je ne sais pas par contre, c'est la "performance", enfin si sur ce genre de fichiers, il est plus performant de tout mettre dans un fichier texte que dans une table SQL. A vrai dire, vu que "techniquement", ça allège MySQL d'une requête, je pense être gagnant, mais il se peut que ça soit le contraire...
Si vous avez des idées, des confirmations (ou infirmations), d'autres propositions, n'hésitez pas. Je ne vous empêche pas non plus de me décrire comment vous avez érigé votre chat chez vous, pour votre jeu.
Amicalement,
PS : J'avais effectivement pensé à la méthode IRC, mais cela obligerait les gens à utiliser un applet Java... Déjà que moi, pourtant "ouvert", je n'aime pas cet applet, je ne me vois le proposer à ceux qui joueraient à mon jeu
Je profite de cette belle catégorie pour poser une question qui m'enquiquine un peu en ce moment. Mais tout d'abord explications!
Voilà, dans mon projet de jeu, j'ai un chat intégré. Un chat particulier dans le fait qu'il est différent suivant la zone dans laquelle le personnage se trouve. C'est un peu comme les canaux IRC en gros. On est dans une auberge, c'est un chat propre à l'auberge, on va dehors, zoup on change de chat, pour trouver celui de la place de la ville (par exemple).
Jusque là, pas très compliqué. Mais vu que ce chat en question est réactualisé automatiquement par JS toutes les 5 à 10 secondes (ça reste encore à définir), je cherche à faire quelque chose d'assez optimisé pour éviter de faire planter tout ça.
J'ai déjà plusieurs idées sur le sujet, je vous les expose ici :
1 - Tout stocker dans la même table "chat" de ce style là :
|id_message|id_zone|id_joueur|texte|date
2 - Stocker chaque "canal" différent sur une table différente (du nom chat_zone_id) avec ce schéma-là :
|id_message|id_joueur|texte|date
3 - Stocker chaque canal différent dans des fichiers texts différents (du nom zone_id dans le dossier chat/ par exemple) avec pour chaque ligne ces infos :
id_joueur | texte | date
4 - Il y a surement d'autres possibilités que je ne connais pas...
Si on étudie les 4 méthodes en détail, on peut y dégager quelques inconvénients/avantages pour chacune d'elle :
1 - Avantage : tout est stocké dans la même table, pas de souci en cas de rajout de nouvelles zones. La table deviendra un peu lourde, mais un nettoyage de celle-çi sera de toute façon appliqué, supprimant tous les messages datant de plus de deux heures. Inconvénient : Je trouve qu'il y a une certaine lourdeur dans la requete qui demande une condition WHERE pour récupérer les bons messages. Si on compte par dessus une requete pour récupérer le nom du joueur à partir de l'id (bon ça se fait par une jointure SQL mais bon...). Imaginons qu'il y ait 400 joueurs online, qui rafraichissent dans leur coin cette requete toutes les 5 à 10 secondes...
2 - Avantage : pas de clause WHERE dans la requete initiale (même si la jointure reste indispensable pour récupérer le nom et le profil de ceux qui parlent). Inconvénient : Ma ville de départ comprenant déjà une trentaine de zones différentes, alors que le reste du monde n'est pas encore ajoutée, j'ai peur de crouler sous les tables chat_zone_id dans PHPMyAdmin, et donc d'avoir une "légère" gêne niveau update, sauvegarde, etc... de la BDD.
3 - On se passe de mysql pour la première requete, mais on en a toujours besoin (à moindre mesure, je suis d'accord), pour récupérer les profils. Ce que je ne sais pas par contre, c'est la "performance", enfin si sur ce genre de fichiers, il est plus performant de tout mettre dans un fichier texte que dans une table SQL. A vrai dire, vu que "techniquement", ça allège MySQL d'une requête, je pense être gagnant, mais il se peut que ça soit le contraire...
Si vous avez des idées, des confirmations (ou infirmations), d'autres propositions, n'hésitez pas. Je ne vous empêche pas non plus de me décrire comment vous avez érigé votre chat chez vous, pour votre jeu.
Amicalement,
PS : J'avais effectivement pensé à la méthode IRC, mais cela obligerait les gens à utiliser un applet Java... Déjà que moi, pourtant "ouvert", je n'aime pas cet applet, je ne me vois le proposer à ceux qui joueraient à mon jeu