Haha. ça me rappelle un topic ou justement je proposais une solution pour contourner ce problème. En relisant tes posts sur le topic en question, je vois qu'à l'époque tu ne saisissais pas le problème qui arrive quand on balance 50 000 requêtes ajax au même moment.
Voilà le topic en question : http://www.jeuweb.org/showthread.php?tid...#pid102699
en utilisant ajaxq, tu peux mettre toutes tes requêtes de déplacement dans une queue spécifique et elles ne partiront qu'une par une. Oui, mais, ton joueur change de case deux fois par secondes, et tes requêtes prennent 2 secondes pour faire l'aller retour. Soit 1 seconde (l'aller) pour que le serveur soit à jour (+ le temps de traitement en PHP). Dans ce cas, c'est simple : à chaque requête de déplacement, tu peux 'clear' la queue, tu annules toutes les requêtes en attente et tu les remplace avec celle du dernier déplacement effectué.
du coup, tes déplacements lancent plein de requêtes, mais seules celles qui sont lancées alors qu'il n'y a plus de communication en cours vers le serveur sont lancées. je sais pas si c'est clair ... tu te déplaces, ça lance la requête T1, elle part. la queue est vide. Tu te déplaces et mets en queue les requêtes T2, T3, T4, chacune annulant la précédente (sauf qu'il faut bien s'assurer que la T2 n'annule pas la T1 puisque cette dernière est en communication avec le serveur (point important)). Tu te déplaces encore, tu clear la queue et place la T5 en queue. La T1 se termine, *pouf* la requête T5 est envoyée vers le serveur. La queue est vide, tu te déplaces, la T6 est mise en queue, etc...
C'est une première approche je pense, ton serveur ne sais pas toujours ou est ton joueur, mais il pourra, dans notre exemple, contrôler les points T1 et T5. Si tes attaques ont une portée courte ça sera gênant car un joueur sera considéré au point T1 tant que le serveur n'aura pas reçu T5, alors qu'en T2 il aurait été hors de portée d'un tir ennemi.
Mais bon, on ne fait pas du real time avec de l'AJAX hein
Je vois que tu as posté sur le topic de Maks. Je ne sais pas comment il fait, mais je pense qu'il confirmera, en envoyant juste l'ID du joueur et sa nouvelle position, la taille de la requête est légère et donc ça va assez vite pour capter la plupart des points de déplacement.
Tu peux ensuite essayer avec deux queues, et balancer tes requêtes sur chaque queue chacune leur tour. Mais ça pose un problème de race condition car tu ne veux surtout pas qu'une requête T2, lancée après une requête T1, arrive avant cette dernière, ce qui peut arriver si T1 était dans une queue ou une précédente requête mettait beaucoup de temps.
Avec ajaxQ je prendrais donc une queue unique pour chaque type de requête : 'moves' pour les déplacement et 'default' pour tout le teste (tout ce qui ne demande pas une précision temporelle particulière). Si les attaques doivent se faire dans l'ordre, une queue 'attacks', etc.
J'aime bien ce plugin mais encore une fois pour un jeu faut voir, ça ne sera peut-être pas suffisant ! Peut-être qu'avec websockets on peut faire quelque chose de similaire (à savoir annuler les requêtes en attente pour envoyer des informations plus fraîches). WS va plus vite à ce qu'il me semble.
Voilà le topic en question : http://www.jeuweb.org/showthread.php?tid...#pid102699
en utilisant ajaxq, tu peux mettre toutes tes requêtes de déplacement dans une queue spécifique et elles ne partiront qu'une par une. Oui, mais, ton joueur change de case deux fois par secondes, et tes requêtes prennent 2 secondes pour faire l'aller retour. Soit 1 seconde (l'aller) pour que le serveur soit à jour (+ le temps de traitement en PHP). Dans ce cas, c'est simple : à chaque requête de déplacement, tu peux 'clear' la queue, tu annules toutes les requêtes en attente et tu les remplace avec celle du dernier déplacement effectué.
du coup, tes déplacements lancent plein de requêtes, mais seules celles qui sont lancées alors qu'il n'y a plus de communication en cours vers le serveur sont lancées. je sais pas si c'est clair ... tu te déplaces, ça lance la requête T1, elle part. la queue est vide. Tu te déplaces et mets en queue les requêtes T2, T3, T4, chacune annulant la précédente (sauf qu'il faut bien s'assurer que la T2 n'annule pas la T1 puisque cette dernière est en communication avec le serveur (point important)). Tu te déplaces encore, tu clear la queue et place la T5 en queue. La T1 se termine, *pouf* la requête T5 est envoyée vers le serveur. La queue est vide, tu te déplaces, la T6 est mise en queue, etc...
C'est une première approche je pense, ton serveur ne sais pas toujours ou est ton joueur, mais il pourra, dans notre exemple, contrôler les points T1 et T5. Si tes attaques ont une portée courte ça sera gênant car un joueur sera considéré au point T1 tant que le serveur n'aura pas reçu T5, alors qu'en T2 il aurait été hors de portée d'un tir ennemi.
Mais bon, on ne fait pas du real time avec de l'AJAX hein
Je vois que tu as posté sur le topic de Maks. Je ne sais pas comment il fait, mais je pense qu'il confirmera, en envoyant juste l'ID du joueur et sa nouvelle position, la taille de la requête est légère et donc ça va assez vite pour capter la plupart des points de déplacement.
Tu peux ensuite essayer avec deux queues, et balancer tes requêtes sur chaque queue chacune leur tour. Mais ça pose un problème de race condition car tu ne veux surtout pas qu'une requête T2, lancée après une requête T1, arrive avant cette dernière, ce qui peut arriver si T1 était dans une queue ou une précédente requête mettait beaucoup de temps.
Avec ajaxQ je prendrais donc une queue unique pour chaque type de requête : 'moves' pour les déplacement et 'default' pour tout le teste (tout ce qui ne demande pas une précision temporelle particulière). Si les attaques doivent se faire dans l'ordre, une queue 'attacks', etc.
J'aime bien ce plugin mais encore une fois pour un jeu faut voir, ça ne sera peut-être pas suffisant ! Peut-être qu'avec websockets on peut faire quelque chose de similaire (à savoir annuler les requêtes en attente pour envoyer des informations plus fraîches). WS va plus vite à ce qu'il me semble.