Proposition alternative de la DB

[ferdodo]

          ### Proposition alternative de la DB

DISCLAIMER: Je voulais faire plus de tables mais je suis limité à 15 sur drawSQL DISCLAIMER 2: C'est l'architecture de données en base, ça ne reflète pas la forme des données transitées par l'API ni celles côté front.

Utilise le principe d'event sourcing : on n'enregistre pas l'état du tamago à un instant T. On ne record en DB que 3 choses:

• les inputs utilisateurs (joue une carte, joue un objet)
• la création/mort d'un tamago
• les ajouts dans l'inventaire utilisateur/la main joueur

Le principe, c'est que quand un joueur lance une partie dans son navigateur, on rejoue en background la partie localement en lui envoyant:

• son tamago
• son inventaire et sa main
• ce qu'il a joué jusque là et les évènements que sont tamago a reçu Une fois le jeu synchronisé, on peut laisser la partie tourner normalement avec pour uniques calls serveurs :
• le joueur joue une carte/objet
• le joueur doit recevoir une carte
• le tamago lance un évènement
• le tamago meurt

Différences avec le design précédent

• Séparation user/player : l'utilisateur porte les informations qui persistent d'une partie à l'autre, joueur ne porte que les informations de la partie en cours.
• Le tamago ne porte plus ses stats. Seulement celles qui le définissent initialement (ses stats max et regen)
• Abstraction du temps en "tick" (pas d'intérêt particulier, c'était juste pour avoir à préciser d'unité de temps)
• Ajout d'un "seed" au tamago qui permet de générer les évènements du tamago

https://drawsql.app/teams/johnnyguyes-team/diagrams/copy-of-tamagokill

Originally posted by @JohnnyGuye in https://github.com/DevGirl-Team/tamagokill/issues/14#issuecomment-2185258924

[ferdodo]

Je propose quelques suggestions,

Revenir sur une table unique pour Player (On a pas besoin de profil utilisateurs comme Netflix)

Les joueurs (Player) on des cartes (Cards). (pas des user_cards) Les joueurs (Player) ont des Objects (Items). (pas des user_object) et surtout pas appeler ca Object, il faut éviter les mots conflictuels en js. Les tamago on des status (pas des tamago_status)

Supprimer Card et Object DeathType et Status. (Pourquoi faire une table en bdd pour du contenu statique ? Un fichier de config (ou autre) suffit, et ca permet aussi de supprimer trois table pivot)

Integrer le CardRanking a la Card. Integrer death au tamago.

Supprimer les stats et input_log et event ? (Overkill ? on a pas la maturite pour faire de l'event sourcing)

On se retrouve avec 5 tables. Simple.

Player Card Item Tamago Status