+- 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 : Rapport d'événement/action : Quelles Solutions ? (/showthread.php?tid=4725)
Pages :
1
2
Rapport d'événement/action : Quelles Solutions ? - Ter Rowan - 11-04-2010
Salut
Je suis en train de développer un module de résolution d'action et j'essaie d'imaginer comment je pourrais décrire à chaque participant/témoin ce qui se passe/s'est passé.
En hypothèse / contrainte :
- le jeu n'est pas en temps réel, le plus dont je me rapproche du temps réel est de l'ajax (donc ce n'est pas le serveur qui envoie des données, c'est le client qui les demande)
- les joueurs peuvent être connectés ou non quand l'action a lieu. Tous, qu'ils soient connectés ou non auront le rapport (soit par ajax, soit à la connexion)
- le rapport est à la première personne : si A fait quelque chose à B, le joueur de A voit "vous faites quelque chose à B" et le joueur de B voit "A vous fait quelque chose".
- j'ai un système de traduction/grammaire (très artisanal) qui me permet d'avoir les phrases à "n'importe quelle personne" (donc pas de soucis pour "stocker" la donnée
- potentiellement un des témoins/participants ne voient pas tout (fonction de compétence, etc...) du genre pour le même exemple : le joueur de A voit "vous faites quelque chose à B" et le joueur de B voit "Quelqu'un/un gars costaud/un asiatique costaud/... vous fait quelque chose"
donc voilà...comment faire ?
+ stocker l'événement en BDD et lorsque chaque joueur demande le rapport, réaliser les calculs et phrases ? (ca m'embête un peu sur le sujet "détection" comment A peut savoir -ou avoir l'impression- que B l'a vu ou non, si c'est à la connexion de B que je fais ce calcul)
+ créer un fichier par joueur de rapport ?
etc..
Je ne sais pas trop comment faire
RE: Rapport d'événement/action : Quelles Solutions ? - Allwise - 11-04-2010
Quand un joueur interagit avec un autre, tu stockes tout simplement l'action dans une table, avec l'id de chaque joueur, l'action et d'autres infos dont tu pourrais avoir besoin. Par exemple, la date et l'heure, et si l'action a été lue par les joueurs. C'est aussi le bon moment pour faire les calculs et "appliquer" l'action puisqu'au moins l'un des deux joueurs concernés est connecté.
Lorsqu'un joueur se connecte, tu récupères les actions qui le concernent dans la table des actions et qui sont antérieures à sa dernière connexion, ou qui n'ont pas le flag "lu", tu les affiches et tu passes ce flag à "lu".
Cette table est en fait une sorte de table de logs.
RE: Rapport d'événement/action : Quelles Solutions ? - Ter Rowan - 11-04-2010
donc pour toi la solution, est de stocker en base et de générer à la demande le "html" du rapport
C'est une des hypothèses à laquelle je pensais mais j'hésitais avec la génération de fichiers "cache ?" qui étaient générés directement lors de la résolution de l'action, évitant ainsi les interrogations SQL.
Je ne sais pas quelles autres solutions on peut imaginer et ce qui est le plus pertinent
RE: Rapport d'événement/action : Quelles Solutions ? - Cartman34 - 11-04-2010
La solution que j'ai à te proposer est proche de celle de Allwise mais avec comme amélioration, une mise en cache.
Je reprend:
Tu as une table dans laquelle tu enregistres toutes les informations sur l'évènement.
J'ajoute:
Dans cette même table, tu ajoute 2 champs.
Un pour le message tu joueur A et un pour le message du joueur B que tu ne remplies pas de suite (tu pourrais mais c'est mieux de répartir les tâches sur ton serveur).
Quand le joueur A réclame le message de cet évènement, s'il n'existe pas, tu le génères et l'enregistres dans l'entrée correspondante de la table. Sinon tu le récupères simplement de l'entrée de l'évènement.
De même pour le joueur B.
RE: Rapport d'événement/action : Quelles Solutions ? - Allwise - 11-04-2010
Tu peux très bien utiliser la base de données pour cette problématique. Si tu utilises seulement des fichiers, tu auras des doublons. Chaque action se retrouvera dans deux fichiers : celui du joueur A et celui du joueur B. Avec ce modèle tu auras, je pense, 1 fichier par joueur, à terme ça peut faire beaucoup.
En passant par ta BDD tu auras une table, avec un seul enregistrement pour chaque action. De plus, dans ce cas de figure les requêtes SQL seront très légères. Tu auras deux clés étrangères, player1 et player2, donc deux jointures, faites sur la clé primaire de la table des joueurs. Ce sera donc rapide, que tu aies 10, 100, 1000, 10000 ou 100000 joueurs. Tu pourras en plus tirer des stats sur les actions les plus populaires, les moins utilisées, purger la table de façon à ne conserver que les xx actions de chaque joueur etc...
Il ne faut pas oublier que les bases de données sont très performantes, qu'elles sont là pour ça. Après, rien ne t'empêche d'utiliser la BDD et de mettre une couche de cache par dessus. Mais dans ce cas je ne pense pas que ça apporte grand chose. Cacher des requêtes SQL est utile pour celles qui parcourent un très grand nombre d'enregistrements, qui mettent du temps à s'exécuter.
RE: Rapport d'événement/action : Quelles Solutions ? - Chandler - 11-04-2010
Désolé de m'insérer dans la discussion mais avec cette méthode le calcul se fait au moment où l'un des 2 joueurs se connectent c'est ça? Dans ce cas si un joueur externe à l'action veut voir il faut attendre que l'un des deux protagonistes le lise avant alors?
RE: Rapport d'événement/action : Quelles Solutions ? - atra27 - 11-04-2010
Non il faut updater dés qu'il y a un accés quelconque aux infos du joueur.
C'est toute la difficultée d'un jeu asynchrone, on ne peut updater que quand il y a un accés, donc on update quand on demande les infos (en gros quand un joueur regarde les infos du joueur concerné)
Je te conseille de faire une fonction getplayerinfo($idjoueur) par exemple...
Enfin sa dépend des cas, si tu veux plus d'explications, regarde sur le forum... ou poste dans un sujet sur la question :p
Bon recentrons....
RE: Rapport d'événement/action : Quelles Solutions ? - Ter Rowan - 11-04-2010
là vous me parler de deux champs supplémentaires correspondant à A et B mais si il y a A B C D E F G... etc (imaginez un match de rugby, sont trente sur le terrain + les spectateurs + les soigneurs entraineurs + remplacants etc... comment faire ? transformer les colonnes en ligne (mais du coup augmenter le volume considérablement) ?
RE: Rapport d'événement/action : Quelles Solutions ? - Cartman34 - 11-04-2010
Tu peux créer une table pour ça alors.
Soit pour le cache en général et tu enregistres le type et l'id de l'entrée correspondante avec.
Soit tu fais une sort de table des rapports similaire à la première idée sauf qu'il y en a une pour chaque besoin et que c'est implicite.
Soit tu enregistres tout dans un champs contenant un tableau linéarisé de tous les messages.
RE: Rapport d'événement/action : Quelles Solutions ? - Allwise - 11-04-2010
Qu'il y ait 2 ou 10 joueurs ça change pas, tu peux toujours le gérer via une table, mais ça change un peu.
Voici un schéma qui pourrait gérer tes rapports d'action.
terrowan.jpg (Taille : 58,73 Ko / Téléchargements : 24)
- La table action_type gère les différents types d'action. Par exemple :
nom : "Attaque"
texteActif : "Vous avez attaqué %s !"
textePassif : "%s vous a lancé une attaque !"
- La table action stocke toutes les actions des utilisateurs. Par exemple, si le joueur A lance un sort de masse sur les joueurs B, C, D, E, F, on aura un enregistrement avec
action_typeFK: xx
joueurFK : id_du_joueur_A
datestart : NOW()
- La table joueur_has_action contiendra, pour chaque action, autant de lignes qu'il y a de joueurs impactés. Donc ici, on en aura 5, une pour B, C, D, E, F :
1er enregistrement : joueurFK : id_du_joueur_B, actionFK : 1
2nd enregistrement : joueurFK : id_du_joueur_C, actionFK : 1
3eme enregistrement : joueurFK : id_du_joueur_D, actionFK : 1
etc.
Et on a un champ vue, qui indique si le joueur concerné a vu le message ou pas, ça peut toujours servir.