(08-02-2019, 09:47 PM)Xenos a écrit : 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.
Vu que le joueur est dans son coin, il peut le résoudre assez simplement. De même que tu peux t'en sortir si tes joueurs sont synchrones.
Tu t'y prendrais de la même façon si tes joueurs interagissent de façon asynchrone ? Je t'offre une situation : si A est absent et que B attaque A, B va détruire des éléments de A. C va ensuite attaquer A à la suite de B. Les données de A doivent être mises à jour à C. Le joueur A n'a jamais été là. Admettons qu'une fois l'attaque lancée les joueurs B et C se sont aussi absentés. Tu te retrouves, au moment précis de l'attaque, sans aucun joueur connecté.
Tu attends donc le retour d'un d'entre eux voire de tous pour mettre à jour les données ? Tu attends la cron qui tourne, par exemple toutes les minutes ? Et donc, si un joueur D attaque dans cette minute, il joue sur des données non à jour ? Mettre à jour les données quand le joueur se repointe dans une situation d'interaction n'est pas satisfaisant, de même que le cron ne suffit pas. Le cron peut gérer cette situation si tu fais une exécution dans l'ordre des événements, mais il ne gérera pas un joueur E qui viendrait espionner la situation vécue dans le laps de temps où ça n'a pas été exécuté. Le joueur E n'aura donc pas la vision du jeu à N+30s d'un événement arrivé à N parce que ton cron tourne à N+1m. Tu peux en revanche le gérer de façon insatisfaisante en renvoyant le résultat au joueur E à N+1min, une fois que son propre événement est exécuté.
Bien évidemment, ça correspond à des besoins de jeux web classiques (tu en as pas mal, c'est pas un souci, et avec une bdd) où ton langage serveur est bien souvent PHP. Faire des démons en PHP qui soient infinis, ça se fait, mais il faut faire gaffe si tu es sur une version antérieure à 5.3 (me semble) pour gérer les fuites mémoires potentielles.
Par contre, je ne vois pas en quoi le fait d'avoir une cron (qui reste à proprement parler un démon) qui tourne multiplierait ton risque de bug puisque c'est quelque chose de parfaitement géré par le serveur. Je vois bien pour un démon infini fait à la main, en revanche.
Et oui, un FPS ne serait pas géré ainsi, de même qu'une LAN classique où ta partie dure plusieurs minutes à plusieurs heures tout au plus et pour lequel tu peux te passer de bdd. Déjà, parce que le serveur peut être un joueur, et non pas ton propre serveur. Et, ma foi, il ne serait pas fait avec du PHP non plus comme pour la plupart des sites, ce que sont en général les jeux webs classiques. Parce que, oui, les besoins et dimensionnements ne sont pas les mêmes.