08-02-2019, 09:47 PM
Que ce soit à la minute ou en dessous, ton archi pue des genoux (pour ne pas dire d'ailleurs) si t'en viens à ce genre de solution qui boucle. Là, soit tu revois ton process/gameplay/façon de faire, soit tu fais comme un jeu AAA, avec un "démon" (serveur) tournant en continue pour gérer le temps réel. Mais je connais pas de FPS ou assimilé qui se joue en ligne en temps réel avec une BDD...
De toute façon, c'est assez simple: quand une archi bien puante comme ça est utilisée, elle ne fait rien 99.9% du temps, et ne fais quelque chose "d'utile" que 0.1% de ce temps. Donc, t'as multiplié tes coûts et tes risques de bug par 1000, pour rien. En revanche, ce genre de chose marche sur un jeu AAA (exemple le plus classique de jeu multi en temps réel) car là, le serveur ne se tourne pas les pouces 99.9% du temps: il est chargé tout le temps de la partie (qui parfois, est "tournante", aka en fin de partie, le serveur passe à la map suivante et on recommence, pas toujours avec les mêmes joueurs puisqu'ils vont et viennent, mais avec la même charge pour le serveur).
En revanche, ta solution est bonne Metallique: tu sauves en BDD le fait que le batiment sera fini à 3H59, puis quand un joueur se pointe (ou que le cron anti-stack-trop-grosse tourne) à 7h, tu marque le batiment comme construit et tu produis les ressources correspondant à la différence de temps (3H01 de production). Tu marques alors que le batiment a produit pour la dernière fois à 7H, et quand le joueur se repointe à 8H, tu procède de même: tu as 1 batiment qui a produit à 7H pour la dernière fois, il est 8H, donc le batiment a produit 1H, et tu ajoutes ces ressources aux stocks du joueur, puis tu marque le batiment comme ayant produit à 8H.
Et si un autre joueur attaque à 10H et pille tous les stocks du premier, alors tu procèdes selon le même schéma: le batiment du 1er joueur a produit à 8H pour la dernière fois, donc, tu calcules les ressources produites pendant ces 2H, tu les ajoutes aux stocks du 1er joueur, tu marque que le batiment a produit pour la dernière fois à 10H, et tu transfère toutes les ressources du 1er joueur vers le 2nd joueur pour simuler l'attaque.
C'est simple, efficace, et adapté à une archi web classique.
De toute façon, c'est assez simple: quand une archi bien puante comme ça est utilisée, elle ne fait rien 99.9% du temps, et ne fais quelque chose "d'utile" que 0.1% de ce temps. Donc, t'as multiplié tes coûts et tes risques de bug par 1000, pour rien. En revanche, ce genre de chose marche sur un jeu AAA (exemple le plus classique de jeu multi en temps réel) car là, le serveur ne se tourne pas les pouces 99.9% du temps: il est chargé tout le temps de la partie (qui parfois, est "tournante", aka en fin de partie, le serveur passe à la map suivante et on recommence, pas toujours avec les mêmes joueurs puisqu'ils vont et viennent, mais avec la même charge pour le serveur).
En revanche, ta solution est bonne Metallique: tu sauves en BDD le fait que le batiment sera fini à 3H59, puis quand un joueur se pointe (ou que le cron anti-stack-trop-grosse tourne) à 7h, tu marque le batiment comme construit et tu produis les ressources correspondant à la différence de temps (3H01 de production). Tu marques alors que le batiment a produit pour la dernière fois à 7H, et quand le joueur se repointe à 8H, tu procède de même: tu as 1 batiment qui a produit à 7H pour la dernière fois, il est 8H, donc le batiment a produit 1H, et tu ajoutes ces ressources aux stocks du joueur, puis tu marque le batiment comme ayant produit à 8H.
Et si un autre joueur attaque à 10H et pille tous les stocks du premier, alors tu procèdes selon le même schéma: le batiment du 1er joueur a produit à 8H pour la dernière fois, donc, tu calcules les ressources produites pendant ces 2H, tu les ajoutes aux stocks du 1er joueur, tu marque que le batiment a produit pour la dernière fois à 10H, et tu transfère toutes les ressources du 1er joueur vers le 2nd joueur pour simuler l'attaque.
C'est simple, efficace, et adapté à une archi web classique.