L'attente active (boucle qui tourne en continue et teste ce qu'il faut faire) est souvent une solution bancale car sur-consommatrice de puissance.
Lancer le calcul à la réception d'une requête pose un soucis d'expérience utilisateur: le premier connecté va attendre, parfois plusieurs minutes façon Eclerd, avant de voir la page. Envoyer la page, déconnecter le client, puis calculer n'est pas non plus envisageable (le client reçoit des données périmées car le calcul s'est lancé après).
L'approche prédictive présente le problème que t'as exposé: le calcul N peut influencer le calcul N+1 dont la prédiction devient fausse.
L'alternative usuelle est un Cron Job, qui toutes les heures ou moins (ou plus) va lancer un script PHP qui effectuera les calculs à faire. On peut avoir une "stack" listant ces calculs dans la BDD. Ovh propose une interface pour cela, dans son manager. Sinon, il existe du tuto web. C'est pas complexe: on a un fichier lu par Linux dans lequel on indique les fréquences d'exécution d'un fichier donné (script PHP par exemple, ou commande MySQL).
C'est cette approche que j'utiliserai.
On peut quand même lancer le calcul lors de la réception de la requête si ce calcul est focalisé sur le joueur. Par exemple, pour la prochaine version d'eclerd, la planète entière sera régulièrement recalculée en hors-ligne (via le cron), mais je peux recalculer le pays du joueur (ou un morceau) à chaque requête qu'il envoie, pour qu'il ait des informations hyper-dynamiques (toujours à jour). Cela complexifie un peu les choses car au lieu d'avoir une seule date de dernière simulation pour tout le serveur (sauvée en BDD), j'ai une date de dernière simulation pour chaque usine (stockée aussi en BDD), mais je pense que cela vaut le coup.
Après, il ne faut pas oublier que PHP est un veau (tout langage client sera lent d'ailleurs). Ce genre de simulation consiste souvent à faire de la simple manipulation de données, donc je conseillerai de la faire en MySQL, ou dans tout autre langage de BDD que tu utilises. Pour ma part, la v0 d'Eclerd faisait le calcul de simulation en lisant les données de la base, en les récupérant dans PHP, en caclulant dans PHP, puis en mettant la BDD à jour. C'est très très lent. Depuis que je suis passé par de la procédure SQL, j'ai divisé le temps par 100 voire plus. Donc une ou plusieurs procédures SQL de simulation, lancées par un CRON, devraient être suffisante (les calculs n'ont pas l'air complexes dans ce jeu).
Lancer le calcul à la réception d'une requête pose un soucis d'expérience utilisateur: le premier connecté va attendre, parfois plusieurs minutes façon Eclerd, avant de voir la page. Envoyer la page, déconnecter le client, puis calculer n'est pas non plus envisageable (le client reçoit des données périmées car le calcul s'est lancé après).
L'approche prédictive présente le problème que t'as exposé: le calcul N peut influencer le calcul N+1 dont la prédiction devient fausse.
L'alternative usuelle est un Cron Job, qui toutes les heures ou moins (ou plus) va lancer un script PHP qui effectuera les calculs à faire. On peut avoir une "stack" listant ces calculs dans la BDD. Ovh propose une interface pour cela, dans son manager. Sinon, il existe du tuto web. C'est pas complexe: on a un fichier lu par Linux dans lequel on indique les fréquences d'exécution d'un fichier donné (script PHP par exemple, ou commande MySQL).
C'est cette approche que j'utiliserai.
On peut quand même lancer le calcul lors de la réception de la requête si ce calcul est focalisé sur le joueur. Par exemple, pour la prochaine version d'eclerd, la planète entière sera régulièrement recalculée en hors-ligne (via le cron), mais je peux recalculer le pays du joueur (ou un morceau) à chaque requête qu'il envoie, pour qu'il ait des informations hyper-dynamiques (toujours à jour). Cela complexifie un peu les choses car au lieu d'avoir une seule date de dernière simulation pour tout le serveur (sauvée en BDD), j'ai une date de dernière simulation pour chaque usine (stockée aussi en BDD), mais je pense que cela vaut le coup.
Après, il ne faut pas oublier que PHP est un veau (tout langage client sera lent d'ailleurs). Ce genre de simulation consiste souvent à faire de la simple manipulation de données, donc je conseillerai de la faire en MySQL, ou dans tout autre langage de BDD que tu utilises. Pour ma part, la v0 d'Eclerd faisait le calcul de simulation en lisant les données de la base, en les récupérant dans PHP, en caclulant dans PHP, puis en mettant la BDD à jour. C'est très très lent. Depuis que je suis passé par de la procédure SQL, j'ai divisé le temps par 100 voire plus. Donc une ou plusieurs procédures SQL de simulation, lancées par un CRON, devraient être suffisante (les calculs n'ont pas l'air complexes dans ce jeu).