Comment faire pour qu'un combat se déroule à un timestamp donné ?

[hercull]

Bonjour je développe actuellement un jeux en php de gestion dans le temps type ogame et j’aurai besoins de vos lumières sur certains points:
J'ai créer le script de combat qui marche seulement ,je n'ai pas encor mis en place le compte a rebours et donc le combat se fait directement après avoir choisi son armée et la cible, et je me pose une question, comment faire pour que le combat se déroule au timestamp que l'on aura enregistré en base? sans que le joueur soit connecter ou que la page se recharge?
merci.

[Xenos]

Salut,

pour ce genre de problème, je considère la réduction du paquet d'onde.

La réduction du paquet d'onde est un concept de la mécanique quantique selon lequel, après une mesure, un système physique voit son état entièrement réduit à celui qui a été mesuré.

En d'autres mots, appliqué à un jeu PHP, je ne considère pas que le jeu doit avoir simulé le combat pile poil à une date donnée. En revanche, je considère que si un élément (joueur, IA, ou autre) accède à une information, celle-ci est à jour.
En termes pratiques, cela revient à dire que, dans ma BDD, j'ai le timestamp du moment où le combat a lieu. Mais lorsque ce timestamp est atteint, je ne fais rien (à quoi ca servirait de simuler un combat, si aucun joueur n'est en ligne?).
En revanche, dès qu'un joueur se connecte/visite une page, je regarde la BDD, et je simule tout combat dont le timestamp est dépassé ou atteint. Ainsi, le joueur a des données à jour, mais je n'ai pas besoin de réaliser le combat au moment "exact" où il a lieu: je ne le réalise qu'une fois qu'un joueur accède à une page qui peut être influencée, directement ou indirectement, par ce combat.

Donc, finalement, si je reprend mon analogie avec la physique quantique (analogie grossière mais bon): tant que mon système (le serveur) n'est pas observé (un joueur vient sur une page), il est dans un état "superposé" (je n'ai aucune idée de quels combats sont censés avoir déjà eu lieu). Mais dès qu'un observateur (joueur) mesure (se connecte à une page) mon système (et voit le jeu), alors je simule tout ce qui aurait dut être simulé auparavant.

Donc le joueur a "besoin" d'être connecté (0 joueur connecté = 0 simulation), mais pas forcément pile au moment du timestamp.
Dans le cas d'ECLERD, j'ai appliqué ce principe, mais j'ai fauté: j'ai considéré qu'il y aurait surement 1 joueur par heure, ou au moins, par jour, de connecté. C'est pas vraiment le cas, et la simulation dégénère, mais cela, ça vient de mes algorithmes, pas du principe de la simulation (en termes plus mathématiques, mon problème vient du fait que j'approxime une fonction par la méthode d'Euler, mais avec un pas trop petit et ducoup, l'approximation est mauvaise comme on le voit sur le graphique).

[niahoo]

sujet maintes fois débattu ... mais pour en rajouter une couche je pense que la solution de Xenos est une solution naïve : le premier joueur du matin va se manger un temps de chargement de page de deux heures (j'exagère) pour peu que les calculs à faire soient complexes et/ou nombreux.

De plus, par principe, le monde de ton jeu est toujours dans un état indéfini, et tu dois déclencher explicitement tous les calculs quand tu veux faire une action uniquement côté serveur (sans action de la part d'un joueur). Cela laisse également la place aux race conditions et t'oblige à mettre en place des sémaphores ou des transactions complexes bien relou, pour rien.

Enfin, cela oblige certains chargement de page à être longs (deux heures, donc ) alors que pendant les minutes précédentes le serveur se tournait les pouces. Mais ils seront parfois courts quand il n'y à rien de plus à faire, ce qui amène à une inconsistance du comportement de l'appli d'un point de vue utilisateur. Et oublie les jeux en quasi-temps-réel du coup.

Mais ça a l'avantage, pour un jeu de gestion tranquille, de ne pas nécessiter d'installation supplémentaire de logiciels.

Ensuite en plus consistant tu as les CRON ou WebCRON ou mieux, un serveur de tâches tel que PHPResque.

[Xenos]

Le 1er joueur ne va pas simuler tout le monde, niahoo En revanche, oui, la 1ere connexion du jour de chaque joueur sera plus longue que leurs connexions suivantes.
Et rien ne t'oblige à faire d'abord le calcul, et ensuite servir le client. Tu peux parfaitement lancer les calculs dans un thread, et servir le client dans un autre. Ou encore, servir le client d'abord, puis lancer les calculs ensuite (mais là, attention à ce que les données envoyées avant les calculs ne soient pas trop anciennes).

Enfin, j'ajouterai que si les calculs sont lourds et complexes, alors le jeu perd (à mon avis) un grand intérêts, car des calculs lourds et complexes reflètent souvent un jeu lourd et complexe (je peux citer mon propre exemple malheureusement), et donc un jeu injouable ou non-attractif.

En revanche, je suis d'accord avec l'hétérogénéité de ce principe: le serveur se tourne les pouces quand il n'y a personne, et trime plus quand il y a du monde.

[Thêta Tau Tau]

Le principe de "faire la maj quand on a besoin d'infos", c'est très utile (voir obligatoire pour les ressources qui varient en permanence), mais il ne faut pas l'appliquer à tout non plus, surtout quand plusieurs joueurs sont concernés.

Imaginons un joueur, qui a lancé 10 attaques avant d'aller dormir.
Il va donc falloir simuler 10 combats quand il se reconnectera le matin.
Mais pour savoir combien il y a de ressource à piller sur chacune de ces 10 attaques, il va falloir mettre à jour les 10 villes/planètes attaquées, donc tous leur bâtiments, recherches etc.
Imaginons qu'elles aient été attaquées par d'autres joueurs la même nuit (avant l'attaque de notre joueur), ou qu'elles aient attaqué au contraire, ben va falloir le simuler aussi.
Au final peut se retrouver à devoir mettre à jour des dizaine de villes/planètes. Et dans certains jeux avec beaucoup "d'échanges" entre joueurs, ont peut se retrouver à devoir mettre à jour tout le serveur (si pour mettre à jour un joueur on a besoin de mettre à jour 5 autres joueurs, pour mettre à jour ces 5 autres joueurs faut en mettre à jouer 25 etc.).

Bref "faire la maj quand on a besoin d'infos" c'est obligatoire pour ce qui varie en permanence (ressources, position d'une armée en mouvement...), c'est possible pour les trucs qui ne concernent qu'un joueur (fin de construction d'un bâtiment par exemple), mais je pense que ça ne doit pas être utilisé quand il y a plusieurs joueurs impliqués dans l'action (attaques, échanges commerciaux...).

[Sephi-Chan]

L'asynchrone : pourquoi et comment ?

Mais bien sûr, il faut un serveur dédié (même un tout petit ou un VPS) pour en tirer pleine puissance.


PS : pense à choisir un bon nom pour ton sujer. Un titre comme "Une question" est nul car on ne sait pas ce qu'on va voir dans le sujet.
Je l'ai renommé pour toi cette fois-ci mais il faudra que tu le fasses toi-même à l'avenir.

[Argorate]

-> resque + dédié

sinon pour un mutu j'utilise la solution "naïve" de Xenos, pas trop le choix

[niahoo]

tu peux mettre un webcron au moins. Si tu n'as pas besoin de précision ça permet au moins de traiter les modifs minute par minute.

[hercull]

Merci de vos réponse je comprend le raisonnement et j'y avais déjà pensé seulement un autre problème interviens dans le cas ou au moment de l'attaque l’armée de la cible est en déplacement et donc si on ne simule pas au moment du timestamp et qu'on attend que le joueur se connecte et recharge la page alors comment savoir si au timestamp de l'heure du combat son armée était bien sur sa base ou en déplacement?

Merci pour le changement du titre.

[hercull]

Pas de réponse?