Gestion des évènements

[Xenos]

Salutations,

Dans Variispace, des évènements peuvent se produire, et impliquer les joueurs. Par exemple, le joueur A peut lancer une attaque sur le joueur B. Ou la flotte du joueur C peut être arrivée sur une planète. Ou la flotte du joueur D peut avoir terminé sa mission d'extraction. Ou celle-ci a été interrompue (faute de place dans les soutes). Etc.

Initialement, j'avais monté ça sous la forme d'une table (id_player; event_name; id_fleet, id_spaceship, id_other_player,...) et je stocke dedans les id des "trucs" concernés (la flotte attaquée, le vaisseau créé, etc).

Mais après avoir implémenté les attaques, au cours desquels des vaisseaux et des flottes disparaissent, j'ai un soucis: ces IDs ne référencent plus rien!

Donc, je suis parti maintenant sur la table (id_player, event_name, opt_string1, opt_string2,...) [je trouve que faire 2 table,s (id_event, id_player; event_name) + (id_event, var_name, string_value) pour faire du 1-N est trop lourd, sachant que j'aurai max 5-6 strings à stocker et que je ne veux pas batailler avec des strings magiques partout, l'event name comme string magique c'est bien suffisant) et je sauve les infos "figées" dedans (nom de la flotte, du joueur, etc).

Vous avez d'autres façon de gérer ça?

[niahoo]

Si c'est juste pour du log tu stockes les données au lieu des ID, si c'est utilisé dans le code alors tes données ne servent plus à rien donc tu mets des foreign keys et tu les supprimes en même temps que l'objet référencé, ou fais du soft-delete.

[Xenos]

Ouep, c'est exactement ce sur quoi je suis parti du coup

[niahoo]

ce qui est beau c'est que je ne sais pas quelle solution tu as choisi mais que nous sommes d'accord

[Xenos]

Ops : )

> La première solution est exactement ce sur quoi je suis parti du coup

[Xenos]

Bon, j'ai rechangé au final...

J'ai finalement changé de structure de table, pour créer une table "event_type VARCHAR; event_options JSON; event_date TIMESTAMP"
Du coup, dans le type d'event, j'insère une string-magique, type "gvt:fleet has arrived" et dans la colonne JSON, j'ai stocké non seulement l'id de la flotte et de sa destination (dans cet exemple), mais aussi le nom de cette flotte et le nom de la destination (nom de la planète ou de l'étoile).

Ainsi, dans le formattage PHP de la page des évènements, je récupère le type & ses options, et en fonction du type d'event, j'affiche un message différent dans lequel je peux avoir le nom de la flotte/planète/étoile (même si elles n'existent plus vu qu'elles sont freezées dans le json) tout en permettant d'avoir un lien (vu que j'ai l'id) clickable pour voir cette flotte/planète/étoile. Si jamais elles n'existent plus, tant pis, le lien débouchera sur une 404 mais le joueur devrait, de toute façon, voir dans la suite des évènements que "la flotte XX a été détruite" ou "la planète YY a été détruite" etc

Le seul "inconvénient", c'est que j'ai alors pas mal de string "magiques": une pour le type d'event, et une pour chaque clef de l'objet JSON stocké, contenant les infos de l'event... Mais je pense que c'est gérable (car restreint aux events) et en un sens, c'est pas plus mal d'avoir ces string magiques (faire 1 classe/event ou un truc du genre, c'est beaucoup beaucoup trop verbeux vu le nombre d'évènement que je peux avoir... j'ai même pas une première release et j'ai déjà bien 15 events différents)

[niahoo]

Ben les string magiques en base tu devrais les avoir dans une constante de classe et dans une enum en base.
Et ces clés sont mappées vers un templat, une classe ou une méthode static de qui prépare les données d'un template.
Et ces fonctions exploitent les clés du json. Ainsi toutes tes chaines magiques sont listées quelque part. Après oui c'est pas bien grave.

[Xenos]

Y'a trop pour en faire des enum SQL, et comme il s'agit de JSON, les options dépendent du type de base. ie:
- gvt:fleet shot us => options: id_fleet_atack, fleet_attack_name, id_fleet_defend, fleet_defend_name, damages etc
- gvt:fleet arrived => options: oc_type, id_oc, oc_name (oc = objet céleste, ie planète, étoile etc)

Et comme tout ça se déroule en SQL pur (parce que j'aime bien les prcoédures stockées), j'ai pas de classe PHP listant ces string magiques dans des constantes (hiérarchisées au besoin)...