Nicodd:Si tu fais une tâche cron, t'as pas d'autre choix que de le faire à la seconde, ou alors il va falloir expliquer à ton joueur qui est connecté et qui attends le résultat de son attaque pourquoi il ne l'a pas dans la seconde.
Ben si tu avais passé 31 mois comme moi à développer le projet, tu comprendrais pourquoi ce n'est pas gérable de faire comme ca.
Si tu prends un joueur B qui attaque un joueur A, et que tu ne fais que mettre à jour les batiments des 2 joueurs, il te manque du monde, et t'arrive au gros bug direct. Pourquoi ? Simplement parce que si le joueur B a lui même était attaqué par un joueur C avant d'arriver chez le joueur A, que le joueur C a vidé le stock de bouffe du joueur B, que le joueur B a perdu 30% de ces troupes avant qu'elles n'arrivent sur le joueur A, tes prises en compte, tu les gères comment ? Sans parler de la production d'unités, qui change évidement la conso, les constructions de batiments, les pertes de troupes cause de famine, les livraisons de commercants, etc etc ... qui interagissent.
T'appliques ca à grande échelle, sur plusieurs centaines, voir plusieurs milliers de joueurs, bonjour le résultat. Imagines aussi le joueur qui lance 30000 unités en production, qui part pendant 7/8 jours, genre vacances ou autre, un bon mois d'août par exemple, mutiplié par le nombre de joueurs ... de quoi mettre le serveur à terre dès le retour du 15 août ... :p
Si j'ai choisi de traiter ca dans un script d'evenement global, tu peux être sûr que ca a été mûrement réfléchi ..
Le problème d'interaction dû au fait que le même script peut être lancé par 2 joueurs en même temps, ca se gère, je n'avais pas pensé à ca, tout simplement. Après mûre réflexion, c'est logique. Il suffit maintenant de modifier le script de gestion d'évènement pour qu'il le prenne en compte, et avec quelques commit/rollback, rien de plus simple.
Merci pour la confirmation des transactions ...
Citation :Lorsqu'un joueur B attaque ton joueur A, tu mets à jour les batiments des deux joueurs en question.
Ben si tu avais passé 31 mois comme moi à développer le projet, tu comprendrais pourquoi ce n'est pas gérable de faire comme ca.
Si tu prends un joueur B qui attaque un joueur A, et que tu ne fais que mettre à jour les batiments des 2 joueurs, il te manque du monde, et t'arrive au gros bug direct. Pourquoi ? Simplement parce que si le joueur B a lui même était attaqué par un joueur C avant d'arriver chez le joueur A, que le joueur C a vidé le stock de bouffe du joueur B, que le joueur B a perdu 30% de ces troupes avant qu'elles n'arrivent sur le joueur A, tes prises en compte, tu les gères comment ? Sans parler de la production d'unités, qui change évidement la conso, les constructions de batiments, les pertes de troupes cause de famine, les livraisons de commercants, etc etc ... qui interagissent.
T'appliques ca à grande échelle, sur plusieurs centaines, voir plusieurs milliers de joueurs, bonjour le résultat. Imagines aussi le joueur qui lance 30000 unités en production, qui part pendant 7/8 jours, genre vacances ou autre, un bon mois d'août par exemple, mutiplié par le nombre de joueurs ... de quoi mettre le serveur à terre dès le retour du 15 août ... :p
Si j'ai choisi de traiter ca dans un script d'evenement global, tu peux être sûr que ca a été mûrement réfléchi ..
Le problème d'interaction dû au fait que le même script peut être lancé par 2 joueurs en même temps, ca se gère, je n'avais pas pensé à ca, tout simplement. Après mûre réflexion, c'est logique. Il suffit maintenant de modifier le script de gestion d'évènement pour qu'il le prenne en compte, et avec quelques commit/rollback, rien de plus simple.
Merci pour la confirmation des transactions ...