Cool de voir le jeu avancer : ) A quand les premiers tests?!
Je suis un peu surpris de devoir passer par un CONCAT pour la diff de temps; je suis plus habitué à la syntaxe MySQL type DATEADD(NOW(), INTERVAL -:hunt_speed MINUTES)
Perso, je définirait updated_at à NOW lors de la création de la ligne dans hunts. Ca évite de rendre la colonne nullable, et ca garde une sémantique encore plus simple à la colonne. Ca te fait aussi sauter la condition sur le created at (puisque updated_at n'est plus NULLable, et que donc, le 2nd test du AND implique [par logique du jeu] que le 1er test du AND est vrai et peut donc sauter) et ça rend la query réellement lisible
En revanche, le delta entre deux appels ne devra pas être "trop grand" car là, tu ne peux faire qu'un saut de 1 step.
Nota: pas besoin de Laravel ou d'un quelconque framework pour faire du cron dans la DB: y'a les EVENT pour ça, qui permettent de faire des queries SQL (perso, de lancer une procédure stockée qui fait la simulation du jeu) toutes les X jours/heures/minutes/secondes (y'a même les "cron à la seconde" via ça, oui...!) L'un des atouts IMO (mais faut faire un jeu full-sql), c'est qu'on n'a pas besoin de faire communiquer un client (php, cron, qu'importe) avec le serveur SQL: on n'est donc pas limité par le nb de connexions max, on n'a pas de risque de "unreachable DB" si jamais l'hébergement web est en rade, et on peut lancer "l'event" à la mano (ie: si l'event c'est juste CALL procedure... alors on peut faire directement un CALL procedure pour simuler le jeu).
Mais en revanche, comme toute approche full SQL, niveau débuggeur, c'est "démerde-toi" (j'ai la triste impression de faire du JS du coup x) )... Là, je suis personnellement preneur de toute solution (mais je n'en ai jamais trouvée!) pour faire du pas à pas dans la procédure, ou à défaut, avoir le n° de ligne de la procédure quand une erreur survient (c'est d'un chiant de ne pas même avoir cette info! :o )
Bonne continuation!
@L'Omniscient: c'est pas une vue pour le joueur hein, c'est la vue de la liste des tests du code...
Je suis un peu surpris de devoir passer par un CONCAT pour la diff de temps; je suis plus habitué à la syntaxe MySQL type DATEADD(NOW(), INTERVAL -:hunt_speed MINUTES)
Perso, je définirait updated_at à NOW lors de la création de la ligne dans hunts. Ca évite de rendre la colonne nullable, et ca garde une sémantique encore plus simple à la colonne. Ca te fait aussi sauter la condition sur le created at (puisque updated_at n'est plus NULLable, et que donc, le 2nd test du AND implique [par logique du jeu] que le 1er test du AND est vrai et peut donc sauter) et ça rend la query réellement lisible
En revanche, le delta entre deux appels ne devra pas être "trop grand" car là, tu ne peux faire qu'un saut de 1 step.
Nota: pas besoin de Laravel ou d'un quelconque framework pour faire du cron dans la DB: y'a les EVENT pour ça, qui permettent de faire des queries SQL (perso, de lancer une procédure stockée qui fait la simulation du jeu) toutes les X jours/heures/minutes/secondes (y'a même les "cron à la seconde" via ça, oui...!) L'un des atouts IMO (mais faut faire un jeu full-sql), c'est qu'on n'a pas besoin de faire communiquer un client (php, cron, qu'importe) avec le serveur SQL: on n'est donc pas limité par le nb de connexions max, on n'a pas de risque de "unreachable DB" si jamais l'hébergement web est en rade, et on peut lancer "l'event" à la mano (ie: si l'event c'est juste CALL procedure... alors on peut faire directement un CALL procedure pour simuler le jeu).
Mais en revanche, comme toute approche full SQL, niveau débuggeur, c'est "démerde-toi" (j'ai la triste impression de faire du JS du coup x) )... Là, je suis personnellement preneur de toute solution (mais je n'en ai jamais trouvée!) pour faire du pas à pas dans la procédure, ou à défaut, avoir le n° de ligne de la procédure quand une erreur survient (c'est d'un chiant de ne pas même avoir cette info! :o )
Bonne continuation!
@L'Omniscient: c'est pas une vue pour le joueur hein, c'est la vue de la liste des tests du code...