Le probleme des collisions est vraiment un probleme tres courant en informatique et pour arriver a gerer ce probleme il y a essentiellement 2 grandes regles a respecter lors du design de l'application (web ou non d'ailleurs) :

1/ d'une part, il faut concevoir les choses pour que les collisions soient le moins probable possible... style pas de collisions dans 99.9% des cas
2/ d'autre part, il faut prevoir et gerer ses collisions

Pour le 1/, il faut bien identifier quelle partie de ton algorithme est sujet a collisions et comment la reduire au maximum... en temps d'execution. Y a t'il possibilite de sortir une partie du code de cette partie, de separer cette partie en plusieurs morceaux... ?
Pour le 2/, utiliser des transactions est une solution :)

Voila, suis-je plus clair ?

Merde, tu développes quelques choses sur lequel tu n'as pas accès ensuite ?
Au risque de me répéter encore une fois aussi, tu as un problème d'algo. Et je te confirme encore une fois que l'on a pas besoin de faire autant de requêtes pour calculer si peu de choses.

Si ton serveur met une seconde pour update, t'as un souci de serveur aussi ou d'algo au choix...

et non je mets pas a jour à chaque événement mais a chaque demande du joueur. en fait, lors d'une demande de mise a jour, je charge l'ensemble des événement du joueur antérieur a la date de mise a jour. je les traite chronologiquement. si l'événement est de type flotte, alors de charge l'ensemble des événements du joueur en interaction via la flotte, antérieur a la date d'impact de la flotte. dans cette seconde liste, s'il y a à nouveau des flottes a traiter, je charge de la même manière les événements.
en gros, je fais une mise a jour en cascade ...

Et alors qu'est-ce qui t'empêche de rajouter cette méthode avant un nouvel événement pour t'assurer que la liste ne contiennent jamais plus de 2-3 événements ?

Sérieusement les mec, au lieu de poser des questions et de pas vouloir entendre les réponses... Branchez vous le cerveau, "je peux pas", ç a veut dire quoi c'est pas toi qui dev, c'est pas toi qui met une vérif où tu veux ?

A qui tu veux faire croire que ton clavier peut pas demander les événements d'un autre joueur que celui en cours ?

Oulala... si c'etait vrai :P
Enfin rire, ce que tu appelles probleme de lag n'est pas uniquement lie au client...
1/ a moins d'etre sur un serveur dedie, rien ne te garantit que le site voisin (ou les sites) du tien ne vas pas utiliser toutes les connections SQL ou tout le CPU pendant 1 ou 2 secondes. Les hebergeurs essaient d'eviter ca mais ca arrive.
2/ a moins de fortement limiter le nombre de joueurs, s'il y en a un grand nombre en ligne au meme moment, ils peuvent faire lagger ton serveur
Imagine que ton  serveur ne peut pas gerer plus de 100 traitements en parallele (chiffre totalement theorique).... si tu as plus de 100 joueurs dans ton jeu, tu t'expose au fait qu'ils soient tous en ligne en meme temps.
3/ meme dans le cas ou tu as un PC multicoeurs dedie et 300 Go de RAM,a moins d'acheter une bande passante garantie a ton hebergeur, rien ne t'affranchit d'un eventuel engorgement de la bande passante de ton hebergeur...

baalbi a écrit:

et doit pouvoir jouer de manière fiable et précis, sachant que sur ce genre de jeu, la précision a la seconde près est bien souvent requise. juste un exemple :
J1 attaque J2 pour lui détruire sa flotte. a la dernière seconde, J2 sauve sa flotte en l'envoyant sur une autre planète. or, lors de la requête pour aller sur la page flotte, le système effectue une mise a jour de J2 pour vérifier ce qu'il a etc ... imaginons que juste avant impact J1 espionne J2 (ce qui est assez fréquent). J2 doit donc traiter cet événement flotte qui fait parti de sa liste d'événements.
dans le même temps, J1 souhaite voir le résultat de l'espionnage. il doit aussi traiter les 2 flottes (au même titre que J2).
suivant l'ordre d'arrivé des demandes, J2 peut se retrouver en attente, et donc ne pas pouvoir sauver sa flotte.

Je comprends le besoin... mais a mon avis tu le prends par le mauvais bout : un site web ne repond pas a la seconde. Tu ne pourras jamais eviter une eventuelle perte de requete ou un eventuel "lag". C'est comme ca ne serait-ce que parce que la communication browser serveur web c'est du protocole TCP et non de l'UDP.
Enfin bon, j'ai essaye de t'expliquer mais je ne dois pas etre tres clair car visiblement tu ne comprends pas ce que je veux dire. Le mieux c'est que tu essaies, que tu vois ce que ca donne par toi-meme. Et comme cela tu comprendras.

baalbi a écrit:

De plus, vu que le jeu est en "temps réel", la moindre mise en attente volontaire n'est pas concevable, même de l'ordre d'une seconde.

Je pense que l'on ne se comprend pas bien car pour une application web cette reponse n'a pas de sens... Lorsque tu affiches une page web, tu as toujours un temps d'attente, tu ne peux pas y echapper. Ca peut etre 1/2 seconde, ca peut etre 3 seconde, ca depend de tres nombreux facteurs (debit internet montant, descendant, charge du serveur, charge du reseau...) et ca n'est pas maitrisable. Ce que je voulais dire c'est que si ton evaluation prendre moins d'une seconde, la mise en attente sera transparente pour le joueur. Ca sera juste "un petit peu plus lent" que d'habitude. Il ne notera pas ca a mon avis.

L'autre truc c'est que si cette mise a jour est de l'ordre d'une seconde, il ne doit pas y avoir de collisions... ou uniquement extremement tres rarement. Donc quelque part, tant que ca ne plante pas ton jeu, ca ne me semble pas un probleme.

Par ailleurs, juste une question en passant... tu as pense a l'hebergement de ce jeu ? Les herbergeurs proposant des moteurs tarnsactionnels ne sont pas hyper courants... ce d'autant plus que les transactions sont gourmandes en CPU/memoire.

Soit deux joueurs, J1 et J2. Une flotte de J1 impacte J2 au temps Ti. chacun de ces joueurs ont des événements à traiter avant l'impact.
Si les joueurs demande une page (donc actualisation de leur compte) dans un labs de temps suffisamment cour, chaque joueur commence sa liste de mise a jour. Lorsqu'ils arrivent a l'événement flotte, ils vont chercher à mettre à jour le compte de l'autre joueur à la date d'impact, donc refaire a nouveau les mises a jour que l'autre a commencé(en effet, les mises a jour n'étant pas terminées, elles ne sont pas visible dans la base de données).
c'est après cela qu'il est possible de traiter la flotte.

pour un évenement, tu peux avoir un flag "en train d'etre traité", que tu mettrait à 1 afin d'éviter les collisions.

Il est impossible normalement que deux evenements arrivent en même temps (si tu as bien modélisé ça, avec une liste d'attente des evenements) (par evenement je veux dire des choses non prévisibles par le joueur -> interactions entre joueurs-> attaques ou catastrophes naturelles)

ça me donne envie de faire un jeu du genre, histoire de montrer que c'est pas si difficile que ça, ou alors je me met un doigt dans l'oeil, et je suis tout a fait a coté de la plaque ^^

Peut-etre as-tu dans ce cas un probleme de design... Si ton traitement dure 1/2 seconde, la mise en attente ne pose pas de probleme. Tu affiches un panneau, please wait a second, and lance un refresh 2 secondes plus tard.
Si ton traitement dure 10 ou 15 secondes, comme je l'ai dit plus haut, ca ne peut pas fonctionner comme ca.