Histoire d'éxécution ?...

[NicoMSEvent]

+1 pour les transaction SQL ( indice : commit; rollback; )

[Unkof]

Tâche Cron non, il faudrait qu'elle soit lancée toutes les secondes, ca ne rime à rien.

Je vais donc revoir tout ca avec le commit / rollback ... de toute facon, je ne vois pas d'autre solution.

Si j'ai bien compris le commit/rollback ne fonctionne qu'avec des bases InnoDB, en utilisant mysqli, on oublie les tables MyIsam, quelqu'un peut confirmer ?

[nicodd]

La vraie question est de savoir pourquoi diable tu dois avoir des tas de requêtes qui se lancent toutes les secondes.
C'est une erreur fréquente d'essayer de faire du pseudo "temps réel" en PHP, réfléchis à comment éviter ca et tu y gagnera en perfs, tout en évitant des bugs idiots.
Par exemple, pour ton soucis, pourquoi regarder toutes les secondes si tous les batiments sont construits ?
Vérifie lorsque le joueur actualise sa page, idéalement par session pour ne pas surcharger la bdd si ses batiments à lui sont construits.
Lorsqu'un joueur B attaque ton joueur A, tu mets à jour les batiments des deux joueurs en question.

Pour ce qui est des transaction, effectivement il faut utiliser innoDB.

[Unkof]

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.

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 ...

[Anthor]

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.

Et comment font les autres ? Faut pas dire que ton problème soit une exclusivité non plus, y'a déjà pas mal de monde ayant bossé sur des algo similaires..

[Allwise]

J'arrive toujours pas à trouver la logique dans ce système qui consiste à faire exécuter un script par un utilisateur qui met à jour les données de tous les utilisateurs, y a un truc qui doit m'échapper. Tu places un traitement plutôt critique dans la navigation d'un joueur au hasard... Mouais. Je vois toujours ici une grosse erreur de conception et le choix de la mauvaise solution.

Si les données de ton jeu ont besoin d'être sans cesse rafraichies parce que tu as besoin d'être toujours à jour, faudrait ptete te poser la question sur le type de jeu que tu développes. C'est un jeu en temps réel, donc faut utiliser les outils adéquates. La gestion des événements est une bonne solution pour ce genre de problème, seulement tu sembles pas l'utiliser comme il faut.

Tu pourrais par exemple utiliser un script qui tourne en boucle et qui met donc constamment les infos à jour. Il n'y aurait ainsi aucun risque de collision, les données seraient toujours à jour et tu contrôles la mise à jour des données, elle ne dépend plus de tes utilisateurs.
Tu pourrais aussi développer un serveur qui gèrerait intégralement ton univers et qui tournerait également 24h/24... MAis c'est encore autre chose.

[Unkof]

Anthor:Comment font les autres ? ... ben justement, qui a développé ici un jeu style Travian qui fonctionne et qui y bosse dessus ? Je veux bien tester son jeu, et discuter de ses choix avec lui. Je n'ai jamais dit que j'avais la science infuse, moi je fais comme ca, c'est tout. J'ai jamais dit que mon problème était exclusif, c'est le problème qu'on dû rencontrer tous ceux qui ont développé ce style de jeu, mais étant un peu nouveau ici, et n'ayant pas non plus pris le temps de fouiller tous les sujets, je ne sais pas qui s'est attaqué à un jeu de stratégie tant réel, et qui ai déjà une alpha ou une beta jouable. Si t'as des pseudos à me donner de développeurs qui sont ici, qui ont fait des jeux de stratégie temps réel sur lesquels je peux m'inscrire et jouer, je t'écoute, et je me ferai un plaisir de discuter avec le/les développeurs du/des jeux si y en a un qui veut bien partager ses connaissances.

Allwisearce que tu ne comprends pas la logique, c'est forcément un problème de conception ? ...

Si tu le dis, on va dire que t'as raison.

[Anthor]

Je te le dis aussi, c'est un problème de conception ^^

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

Et alors ? Quel est le problème, A enclenche la mise à jour du joueur B lors de l'attaque. B est bien à jour.

le joueur B a perdu 30% de ces troupes avant qu'elles n'arrivent sur le joueur A

On se demande d'ailleurs comment des troupes en mouvement ont elle bien pu disparaitre de chez B non ?

[QuentinC]

SI on prend le problème autrement : le fait que A et B aient conclu des affaires au moment où C affiche la page, on s'en fout. Enfin, C s'en fout. Je pars du principe qu'on doit pouvoir calculer l'issue du combat entre A et B lorsque le premier des deux se connecte. Ce combat ne regarde pas C, donc ce n'est pas au détour d'un chargement de page ne concernant que C qu'il faut calculer l'issue du combat de A contre B. ON calcule lorsque c'est nécessaire, le monde entier n'a pas forcément besoin de savoir exactement qui a combattu qui à l'autre bout de la carte.

[Unkof]

Anthor:Tu te demandes d'ailleurs comment des troupes en mouvement ont elle bien pu disparaitre ? Ca s'appelle la famine, quand tu manque de bouffe, y a des morts, Tu comprends là ? On voit que t'as bien suivi l'histoire. J'attends encore que tu me donnes des pseudos de gars qui ont un jeu de stratégie temps réel fonctionnel, sur lequel on peut jouer, puisque y en a plein ... ^^

On va dire que vous avez tous raison, et que je ne sais pas ce que je fais. Ca fera plaisir à certains qui savent tout, et ca mettra fin à ce débat ridicule.

Sujet clos pour moi.