Multijoueur en ligne

Bon j'ai réussi à faire une version multi a peu synchronisée mais je rencontre quelques problèmes.

Par exemple quand j'ouvre le jeu en mode fenêtré et que je déplace la fenêtre, cela met le jeu en pause et le jeu se désynchronise par rapport aux autres joueurs. Y-a-t-il un moyen simple d'éviter cela ? Si un joueur a son PC qui ralentit par exemple, comment ralentir également les autres ou leur demander d'attendre ?

Merci !

Étonnant. A chaque fin de step le client envoie un message au serveur, et quand le serveur a recu les messages de tous les clients, il leur renvoie un autre message pour leur dire qu'ils peuvent continuer.

Ben pour moi ce n'est pas le cas. Y-a-t-il un moyen d'obliger la synchronisation de tout le monde lorsqu'un joueur ne répond plus ou est en pause ?

bin, toutes les secondes, tu à un objet qui envoie une demande de syncro à tout le monde, comme ça, t'est sûr que t'aura, au pire, une seconde pour détecter les lagg et les corriger (si c'est possible).

Le soucis en fait, c'est que sous windows quand tu grab une fenêtre, ça la met en pause.
Autant avec l'api win32 doit y avoir moyen de corriger ça, autant avec GM je sais pas du tout si c'est possible.

Mais dans tous les cas, une règle importante: le serveur ne peut se permettre d'avoir des lags.
Et ça ce sera aux joueurs de choisir qui va le lancer, pour pas qu'il se passe de conneries.

Si le serveur doit attendre que le client ait bien reçu le message du serveur et qu'il la renvoie, lorsque tu auras dix joueurs de connectés ça ne va vraiment pas le faire. Tous les jeux font d'une manière asynchrone, on ne se préoccupe pas de quand le client reçoit le paquet, ni s'il le reçoit, bien sûr on le vire s'il n'a pas répondu depuis 30 secondes par exemple.

T'as pas compris le soucis.
Le soucis ici c'est si le serveur freeze n secondes, comment les clients doivent réagir.

(et surtout comment empêcher le grab window de faire freezer l'application)

Tu peux savoir quand le serveur est bougé en comparant la valeur actuelle et celle précédente de window_get_x/y() ensuite je pense que le meilleur moyen c'est de dire aux clients de se mettre en pause aussi, de toute façon le serveur t'es pas censé le bouger tout le temps... :/
Ou sinon bah tu le rend carrément invisible, ou tu le mets en petite icone dans la barre près de l'heure (me rappelle plus son nom).

Sauf que si ton appli freeze, ça sert a rien de comparer les coordonnées de la fenêtre

GG x)
Ia pas une fonction window_set_movable ou un truc dans le genre ?

Pas vraiment, un moyen de contourner ça d'une manière bien dégueulasse serait de faire la fenêtre borderless..

The Dark Tiger a écrit:

bin, toutes les secondes, tu à un objet qui envoie une demande de syncro à tout le monde, comme ça, t'est sûr que t'aura, au pire, une seconde pour détecter les lagg et les corriger (si c'est possible).

Ok ça marche mais comment on code un tel objet ? Y'a des fonctions pour ça ?

Moi ce que je ferais, c'est au lieu de faire "réception > traitement", je ferais "réception > mise en tableau" (ou liste), et après tu sélectionnes les données à traiter (c'est à dire les dernières arrivées).

En général pour ça on utilise une queue comme structure.

Merci les gars mais je ne suis pas encore à l'aise avec tout ça. Est-ce que quelqu'un pourrait illustrer ça avec un exemple un peu plus concret et proche du langage de GM ?

Bon après quelques test je rencontre bien des problèmes de synchronisation. Les problèmes ne viennent pas que du serveur mais aussi des clients. Il survient par moments de petites différences et le décalage se creuse petit à petit. (les personnages se décalent, le seed n'ai pas lu en même temps lors d'apparition aléatoire d'objet)

J'ai vu qu'il existait un mode "garanti" dans le multi de game maker qui assure que les clients reçoive bien leur paquet (même si cela ralentit le débit à priori). Est-il fiable et utilisable ?

Sinon comment coder le fait que l'on veille que le jeu passe à la frame suivante si et seulement si touts les clients ont reçu leur update ?

Le mode garanti de GM ne changera rien, et avec la 39dll c'st aussi garanti (c'est le protocole qui change, TCP ou UDP).
Dans le genre code à deux balles tu fait un while qui tourne en boucle tant que canPlay==false, et tu fais que quand tu recois l'ordre du serveur canPlay se met à true, puis tu le remet à false dès que t'as passé ta boucle :
canPlay=false;
while(!canPlay){
if(/*tu as recu l'ordre du serveur) canPlay=true;
}
// tu joue

M'enfin c'est clair que GM n'est pas adapté à ca... :/

Utilises toujours TCP.
UDP c'est pour ceux qui savent a quoi ils touchent.

Ok merci je vais essayé ça !

En fait je ne sais même pas quel protocole j'utilise.

J'utilisais les fonctions de EZ multiplayer (qui utilise lui même le 39dll). C'était très pratique avec des fonctions comme net_client_send() où tu peux envoyer plusieurs variables d'un coup et plus besoin de clear le buffer... mais bon ça se trouve tous les problèmes viennent de là.

Avec les boucles infinie aucun risque que le jeu se décale ? (même d'une frame ?)

Nop, ca devrait pas.