Multijoueur en ligne

Je réfléchis de plus en plus à faire un portage en ligne de mon jeu (style bomberman à 4 joueurs). J'ai lu quelques tutos mais je ne suis pas sûr de mesurer l'enjeu et le concept.

J'imagine qu'il est indispensable de synchroniser toutes les frames la position des joueurs, des bombes et le chrono mais est-ce nécessaire aussi pour les objets plus statiques comme les blocs de décors, les blocs destructibles...

Si quelqu'un qui a fait l'expérience de cela peut me donner quelques petits conseils sur les pièges bêtes à éviter et la synchronisation d'un jeu offline version online je suis preneur !

Merci encore à tous et spécialement à Oni, grâce à vous mon projet a déjà largement dépassé celui développé sur mmf2 et ce n'est que le début !

Alors en général pour une architecture réseau pour plusieurs joueurs, on choisis d'utiliser un serveur "maître", ou se connecterons les clients.

Le serveur écoute un port, accepte les connections, regarde si la personne est en droit de se connecter.
Il écoute aussi les joueurs connectés, et s'occupe de la réception et retransmission/traitement des messages.

La premier chose a faire est de définir un "protocole".
Pour chaque message, tu vas définir un identifiant, chaque identifiant aura une fonctionnalité.

Par exemple:
0: connexion acceptée (serveur -> client)
1: update position joueur (serveur <-> client)
...

Pour ce qui doit être update:
Tout ce qui est dynamique, tout simplement. Les blocs incassables par exemple, pas besoin de les update.
Par contre la position du joueur devrais être update a chaque frame:
Client -> envoie coordonnées player au serveur -> retransmission aux autres clients

Pour tout ce qui est update de positions, faut utiliser un système d'interpolation pour pas avoir des saccades.
Le mieux est d'envoyer les touches pressées ainsi que les coordonnées, ça évite de se soucier de l'interpolation, et comme ça si y a un petit lag le joueur continueras de bouger fluidement (et au pire il se recalera la ou il est réellement).

Pour ce qui est la synchronisation en elle même, c'est un domaine vachement complexe et en général on se prend vraiment la tête dessus que pour les jeux extrêmement dynamiques genre FPS.
Dans ton cas essaye de faire sans et vois ce que ça donne. Sinon va voir sur le forum de developpez.com j'avais trouvé de très bon sujet qui en parlaient.

Ah bah tiens, je profite du topic pour poser deux-trois questions sur le même sujet   (m'enfin j'suis sûr que ca pourra aussi être utile à Herdge!)

Concernant la synchro justement, est-ce qu'à chaque step t'attends les données du serveur pour continuer ou tu les reçois et les gères quand tu les reçois (dans un thread séparé quand t'utilise pas GM) ? Je penchais plutôt pour cette solution mais j'ai ptêt faux.

Et autrement la plus grande difficulté je pense : si les données sont transférées de manière asynchrone, comment tu gère les id des objets ? Si tous les id des objets se suivent, tu risque d'avoir à un moment deux clients qui créent un objet avec le même id, et quand va y avoir la syncho chaque client aura deux objets différents avec le même id :/ Pour contourner le problème faire en sorte que les ids attribués ne se suivent pas un par un, mais avec un random(1000), exemple des ids attribués :
1er objet : 320
2eme objet : 1782
3eme objet : 2145
etc...
Donc la ia plus qu'un chance sur 1000 que deux objets aient le même id, donc devrait pas y avoir de problème, ou tellement rarement que c'est plus très grave, mais c'est vraiment du bricolage je trouve...

Voilà, si tu sais comment faire ca, merci, autrement pour tout le reste je fais exactement comme tu viens de l'expliquer ^^

Faut que la réception des messages (pour le client) se fasse dans un thread a part oui.
Pour le serveur y a plusieurs façons de faire mais un thread de lecture + thread d'écriture est souvent la meilleur chose a faire.

Pour les identifiants il faut gérer cela soit même.
Apres je parle de mon expérience en C++, avec GM ça risque d'être casse ******* a faire sans thread ni 'vrai' conteneurs.
Mais doit y avoir moyen de se débrouiller en gérant l'ordre d’exécution des instances, et en gardant en mémoire manuellement les instances crées tout en leur attribuant un id custom.

Bah moi ce serait en java donc pas de problème pour les threads, avec GM c'est effectivement un bordel sans nom...
Mais tu saurais faire un truc plus 'sophistiqué' que mon histoire de id random ?

Oui utilises juste un système de slots.
Tu gardes tes instances dans un vector, l'id de l'instance = sa position dans celui ci.
Quand une instance est détruite tu laisse le slot vide en attendant de le re remplir.
A chaque destruction/création tu passes par le serveur pour que lui même ainsi que tous les clients fassent la même chose.

Ouais mais alors tu risque pas d'avoir des problèmes dans certains cas ? Genre si deux clients créent un nouvel objet alors qu'il a pas été synchronisé chez les autres, ils vont avoir la même place dans le Vector, et donc le même id, nan ?
Après ptêt que dans la pratique ca arrive jamais mais en théorie c'est dangereux ca nan ?

Si t'es en TCP les messages sont toujours reçu, alors a moins que t'ai mal prog ta gestion d'instance, je vois pas comment ça pourrait arriver en fait.
Surtout que la gestion des ID, c'est le serveur, qui est le "maître" qui doit les assigner et s'en occuper.

En gros tout passe par le serveur, et les clients ne sont que son "reflet".

C'est bien en TCP mais t'as raison, j'avais pas la bonne logique : moi c'était chaque client qui définissait l'id à la création et qui l'envoyait au serveur qui le partageait aux autres clients. Donc ouais je vais faire que quand un objet est créé (par le client), le serveur lui renvoie son id à lui et aux autres clients.

Donc t'as raison, il peut plus y avoir de problème comme ca, merci de ton aide !

En multijoueur faut vraiment penser de cette façon: c'est le serveur qui gère tout.

Si c'était possible coté client on ne gérerais que l'affichage (mais en pratique c'est rarement le cas)

Onilink a écrit:

Pour tout ce qui est update de positions, faut utiliser un système d'interpolation pour pas avoir des saccades.
Le mieux est d'envoyer les touches pressées ainsi que les coordonnées, ça évite de se soucier de l'interpolation, et comme ça si y a un petit lag le joueur continueras de bouger fluidement (et au pire il se recalera la ou il est réellement).

Pourrais-tu m'expliquer simplement ce qu'est un système d'interpolation ?

Et sinon quel est le protocole le plus simple et le plus efficace à utiliser pour le multi ? (réseau local inclu vu qu'il existe Hamachi)

Sinon si j'ai bien compris : 1 joueur créer la partie et est le serveur, les 3 autres sont clients et le rejoignent. Ensuite les 3 clients envoient uniquement leur "keys input" au serveur et le serveur renvoie aux clients toutes les mises a jours des objets dynamiques dans la partie. C'est bien ça ?

Pour le serveur t'as deux façons de faire:
-une application externe (léger car pas besoin des ressources graphiques, et peut être balancé sur un serveur physique)
-une application collé au client (pas forcément le mieux car ça peut vite devenir le bordel)

Un système d'interpolation sert a faire une transition "douce" entre deux position.
Par exemple un objet qui est aux coordonnées x = 10 a t=0 et x = 20 a t=2, tu peux imaginer qu'a t=1 bah x=15, ça c'est une interpolation linéaire.

Pour le protocole c'est a toi de le définir en fonction des besoins, mais pour ce qui est plus bas niveau il faut passer par des sockets en mode TCP (et se rappeler que TCP == stream => il faut donc découper les messages a la réception).

OK merci je commence à saisir l'idée. Est ce que quelqu'un aurait un exemple d'une petite application en multi à faire partager histoire que je me rende mieux compte ? Merci !

Pour GM j'ai peur que tu trouves pas grand chose

Bon alors nouvelle question... Sachant que je suis totalement inexpérimenté dans le multijoueur en ligne, vaut-il mieux utiliser les fonctions de GM de base ou le 39.dll ?

La 39dll car les fonctions de base de GM sont quasi inutilisables.

Ok. Dans mon jeu j'ai 4 joueurs (au max) qui utilisent les 4 directions et les boutons A et B. (6 variables en tout)

Si ,pour chaque joueur client, j'envoyais à chaque frame un paquet au serveur avec ces 6 valeurs cela serait viable et sans gros lag ?

J'ai regardé beaucoup de tutos sur le sujet où ils envoient systématiquement les coordonnées x et y de leur personnage, cela modifie bien la position mais ne permet pas l'animation du personnage.

Je ne résonne probablement pas comme il faudrait, si quelqu'un veut essayer d'expliquer comment il mettrait un "bomberman like" en multi sur GM ça serait peut être plus simple. (en gros, les échanges de données indispensables de données entre le serveur et les clients).

Merci !

T'inquiète, c'est pas avec 6 misérables variables que tu va faire lager ton jeu
Si j'étais a ta place j'enverrais quand meme la position de chaque joueur, quitte a interpoler ensuite (sauf si tu peux gérer le type de variable envoyé avec la 39dll, alors un boolean par touche est mieux), puis pour les actions envoyer un ordre seulement quand la touche est appuyée.
Mais bon, pour un bomberman t'as pas vraiment besoin de te faire ***** à optimiser à fond ; mais au moins ca te fera comprendre la logique !

Merci, oui j'utilise bien un booléen par touche.

Donc en gros si
- je rajoute dans mon jeu des objets clients et serveur pour la connexion
- que je remplace mon script qui check les touches pressées par un script qui envoie directement au serveur
- et que le serveur renvoies aux clients les touches pressées par les autres joueurs

Ca devrait fonctionner ? (parce que si oui, du coup c'est beaucoup plus simple que ce que j'avais imaginé)

Oui, mais faut envoyer les coordonnées aussi pour pas qu'il y ai de décalages.
A la limite les coordonnées c'est pas obligé de les envoyer chaque frame, mais ça mange pas de pain.

GM utilise un seul type de donnés, donc t'as l'impression d'utiliser un boolean mais il prend autant de mémoire qu'un double, donc je vois pas trop l'intérêt d'envoyer les touches pressées. Limite tu peux envoyer que la direction a chaque fois qu'elle change.
Mais bon comme dit c'est pas très important à ce niveau ^^

Les touches pressées ça simplifie la gestion des animations & co en fait.

Oui c'était par rapport aux animations. Je mettrais aussi x et y du coup. Pour les bombes par contre je n'ai pas besoin du coup ? (car elles peuvent se déplacer si un joueur les poussent)

Normalement les bombes ça se fera automatiquement ouai.

Par contre pour l'apparition aléatoire des bonus quand un bloc est détruit, est-ce que la fonction aléatoire calculera de la même manière sur toutes les machines ou est ce que je dois le gérer uniquement sur le serveur puis l'envoyé aux clients ? (j'utilise la fonction random() uniquement)

J'ai l'impression que GM a une fonction random() prévisible et régulière je me trompe ?

Faut que tu fasse un random_set_seed(seed) avec la même seed sur chaque client. Par contre faut que quand un fasse un random tous les autres le fassent aussi, sinon t'es décalé et ca sert plus a rien.
Autant pour moi pour les animations par contre.

Pas de soucis .

Donc si je fais random_set_seed(1) sur toutes les machines en meme temps ça marchera ?

Ouaip, mais la t'aura toujours les même valeur. En général on utilise l'heure, tu devrais définir une seed depuis le serveur et l'envoyer ensuite aux clients.

Ouaip génère ta seed depuis le serveur, comme toujours serveur -> master x)

J'ai vu qu'il existait "EZ multiplayer" en plus du 39dll, ça a l'air plutôt simple à utiliser, est-ce que vous confirmez que c'est bien ?

Sinon existe-t-il un moyen radide sous GMS pour lancer plusieurs fois le jeu dans l'éditeur (pour tester le multi) ou faut-il compiler à chaque fois une .exe pour tester ?