Quelles techniques permettent aux jeux Web de mettre à jour fréquemment les ressources du joueur?

Il y a longtemps, il y avait ce jeu en ligne appelé Utopia (et je suis sûr qu'il est toujours là), les tours se font par heure. Vous n'obtenez que du nouvel or / bois d'œuvre ou quoi, pas toutes les heures.

Certains jeux Web plus récents ont des ressources qui augmentent en résolution plus fine, comme par minute. Supposons donc qu'un joueur ait un taux de production alimentaire de 5 par minute - le joueur verra sa quantité de nourriture augmenter chaque minute. Je ne sais pas s'il est sage de définir constamment un travail CRON pour mettre à jour la base de données SQL, que je suppose être ce qu'ils utilisent, car elle est basée sur le Web. Peut-être que je me trompe, chaque minute.

Quelles techniques ces jeux en ligne utilisent-ils? Ajouté sur Edit: Et la base de données peut-elle vraiment gérer la charge?

Il me semble que vous pouvez simplement stocker les taux de production, le niveau de ressource de base et un horodatage mis à jour. Ensuite, chaque fois que vous avez besoin de connaître le niveau de ressource réel, vous pouvez simplement multiplier le taux de production par le temps écoulé.

Chaque fois que le niveau de ressource réel change - mettez simplement à jour le niveau de base. Chaque fois que le taux de production change, mettez à jour le niveau de base au niveau réel et l'horodatage à l'heure actuelle.

De cette façon, au lieu de mettre à jour chaque joueur (y compris vraisemblablement ceux qui ne sont pas actuellement connectés) chaque minute, vous ne mettez à jour que les lignes qui sont réellement utilisées activement par les joueurs.

(Si votre jeu "coche" une fois par minute, j'imagine qu'un "nombre de tours" quelconque pourrait être meilleur qu'un horodatage réel.)

Un avantage secondaire de ce système est que vous pouvez utiliser la même logique que celle utilisée pour mettre à jour la base de données et prévoir les valeurs sans les modifier - pour envoyer uniquement les informations nécessaires au client (plutôt que de les mettre à jour une fois par minute) et pour prévoir valeurs sur le client.

Les bases de données SQL modernes couramment utilisées (MySQL, Postgres, Oracle, MSSQL, etc.) vous permettent de planifier des procédures stockées à exécuter avec des intervalles de temps arbitraires. C'est une méthode très légère pour exécuter des mises à jour comme celle-ci et supprime la nécessité d'appeler un script ou un programme externe pour le faire pour vous.

Cela permet également à la base de données d'optimiser la requête que vous exécutez une seule fois, au lieu de le faire à chaque fois qu'un script externe l'invoque, ce qui est très utile du point de vue des performances. Bien sûr, cela ne s'applique que si vos mises à jour sont suffisamment triviales pour être programmées dans votre propre langage de script. Les mises à jour des ressources, les déconnexions automatiques des intervalles de temps, la purge des enregistrements et autres sont d'excellents candidats pour ces procédures stockées planifiées.

La charge que votre base de données subit provient probablement à 99,9% des chargements de pages, des mises à jour du moteur de jeu et similaires, car un jeu populaire peut facilement avoir des centaines de milliers de requêtes par seconde. Par rapport à la charge qui résulte de l'exécution de quelques requêtes (bien que celles qui touchent une grande partie d'une table) une fois par minute, la charge ne devrait pas être un problème. C'est-à-dire, sauf si vous mettez à jour des valeurs indexées par la base de données. Vous devez éviter à tout prix de mettre à jour les colonnes indexées si vous vous inquiétez des performances.

Concernant les mises à jour:

Certains utilisent des travaux CRON qui atteignent une certaine page PHP de temps en temps.

Certains utilisent des travaux CRON, exécutant cette fois un certain processus.

Une autre approche consiste à effectuer des mises à jour «juste à temps» - chaque fois qu'une page est chargée, exécutez les mises à jour en attente et effectuez-les à ce stade. C'est généralement ce que vous devez faire si vous ne pouvez pas exécuter des travaux CRON ou des processus de longue durée.

Enfin, d'autres exécutent l'intégralité de l'application Web en un seul processus, afin qu'ils puissent mettre à jour chaque fois qu'ils le souhaitent.

Le système final est le meilleur si vous avez cette option disponible car vous pouvez stocker les données en mémoire. La mise à jour de quelques milliers de lecteurs une fois par minute est triviale si vous modifiez simplement des données dans la RAM plutôt que d'avoir à écrire dans une base de données SQL traditionnelle.

Mais si vous n'avez pas ce luxe, vous pouvez utiliser une sorte de mise en cache. Quelque chose comme memcached peut être une option (en fonction de votre hébergement) qui est à mi-chemin entre la mémoire et une base de données. Vous pouvez stocker des valeurs transitoires dans memcache et les enregistrer uniquement dans la base de données lorsque cela est absolument nécessaire.

Entre memcache et une base de données SQL traditionnelle, il existe d'autres options, par exemple. les différents magasins de clés / valeurs ou magasins de documents: des trucs comme MongoDB , CouchDB , les offres Amazon ou Google, etc ... ie. tous les systèmes sous le terme générique NoSQL . Celles-ci ne vous donnent généralement pas la puissance d'interrogation générique ni toujours toutes les mêmes garanties de sécurité d'une base de données traditionnelle, mais sont souvent beaucoup plus rapides à utiliser. (Ce qui n'est pas si surprenant, car ils font moins pour vous.)

Mais tout cela suppose qu'une base de données normale ne peut pas gérer la charge. En fait, dans la plupart des cas, c'est probablement le cas. Si je dois émettre 10 000 appels UPDATE par minute pour augmenter les niveaux de ressources, ce n'est pas très évolutif une fois que vous commencez à ajouter tout le reste par dessus. Mais si vous changez cela pour mettre à jour la ressource pour tout le monde avec 1 appel SQL, soudain, les choses semblent beaucoup plus positives. Ne surestimez donc pas le coût d'une certaine fonctionnalité, car elle peut souvent être mise en œuvre sous une forme plus efficace.

Je suis en faveur de KISS : "Keep It Simple, Stupid!"

Je ne vois aucune raison pour laquelle un travail cron ne fonctionnerait pas, et l'avantage est que les options d'hébergement Web bon marché ne vous permettent souvent pas d'exécuter directement des commandes, mais elles vous permettent d'exécuter des commandes cron. Il n'y a donc pas besoin d'un serveur dédié coûteux.

Vous pouvez également faire votre code de mise à jour en PHP ou dans votre langue de préférence, en utilisant la commande cron ou en utilisant le navigateur de texte. Les instructions de Configuration des tâches cron contiennent plusieurs exemples de commandes que vous pouvez utiliser pour envoyer une requête ping à votre propre page à intervalles.wget --spider http://yoursite.com/secretphppage.phplynx

Je me souviens avoir regardé le code d'un clone de Planetarion. Tout est PHP, mais le code ticker est en C brut - avec les liaisons C MySQL. Le modèle de données étant très simple, les mises à jour se produisent très rapidement.