Salut à tous !

J'essaye de programmer un petit jeu multijoueur. C'est un jeu de plateforme, donc temps réel et beaucoup d'inputs à gérer chez chaque client.

Ma question concerne l'architecture du moteur réseau.
Quelles informations envoyer, quand et comment ?
J'hésite entre les sockets UDP et TCP.

La solution que j'envisage en ce moment est d'utiliser TCP pour envoyer exactement chaque input (appui de touche, clic de souris...) du client 1 au client 2 (via un serveur). Ainsi, le client 2 peut reproduire les actions du joueur 2 en interne.
Cependant, je trouve déjà de nombreux désavantages à cette idée.

Si vous avez des pistes ou des conseils, ça me ferait très plaisir d'en apprendre plus sur l'architecture réseau (à un niveau modeste bien sûr, pour l'instant j'essaye juste avec 2 joueurs en LAN).

Voilà, merci d'avance et bonne journée !

Hello,

Si tu es sur une architecture LAN entre deux postes, deja tu n'as pas besoin d'un serveur. Le serveur est utile pour des jeux avec un nombre de joueurs plus important et/ou au travers d'internet.

Le TCP est a mon avis la meilleure solution car tu assures la réception des informations. L'UDP ne te permettra pas ce genre de choses.

Ensuite au niveau de tes messages, si c'est un simple jeu de plateformes, tu peux juste définir un système ou tu envoies l'état de ton personnage sous deux variables :
1. son mouvement
2. son action

exemples :
AVANCE-TIR
SAUTE-RIEN
COURRE-SE BAISSE

Tu n'envoies un message entre les postes que si l'un des 2 paramètres change. Si le joueur avance pendant 15sec sans rien faire d'autre (ou ne bouge pas pendant x secondes) tu n'auras pas de message qui transitera durant ce temps

Tu fais par contre un contrôle avec ce qu'on appelle une "ligne de vie" qui renvoie le statut toutes les 1min afin de contrôler que les deux postes sont toujours connectés.

Déjà avec cette façon de faire tu devrais pouvoir avancer sereinement

A+
Uri

Perso j'utilise les deux

TCP pour ce qui doit arriver à coup sûr (dégâts sur un ennemi, etc)
UDP pour ce qui est pas trop important mais qui doit arriver vite (inputs des déplacement d'un joueur)

après ça dépend de ton jeu

Merci à tous, et merci Uri, ta réponse m'éclaire bien

Donc si je me passe de serveur, l'architecture ressemblera à ça :

(l'engrenage bleu est le moteur physique qui gère les inputs).

T'as des libs très utiles pour le réseau, genre enet ou raknet (suivant quelle licence tu veux).

Houla,

Attention, tu n'avais pas parlé d'un moteur physique. Ce genre de moteur est bien plus complexe a synchroniser en réseau !

En LAN ca ne devrait pas poser de problème mais si tu espères un jour porter ton projet via le Net ca peut provoquer des situations inattendues car un meme evenement sur ton moteur a quelques millisecondes d'intervalles peut provoquer des situations différentes.

Dans ce cas, je te conseille plutôt de passer par un serveur qui gèrera ta physique globale et enverra un état du monde aux joueurs.

En gros, ton joueur envoie un message identique a ce que j'ai dis au dessus.
Ensuite le serveur gère le monde d'un point de vue physique
Enfin il envoie un vecteur normalisé de déplacement a chaque client.

Tu peux aussi passer par un moteur physique interne au client afin de faire de la précognition et corriger les erreurs via les messages envoyés par le serveur.

A+
Uri

Ecaille deLune : vu la modestie de mon projet je me contente de la SFML

Uri : c'est ce que je me disais (risque d'asynchronicité...). Du coup ça va être plus long que je ne le pensais, mais ça a l'air aussi dur que passionnant à réaliser.

Encore merci, si ça marche je vous tiendrai au courant.

Petite question :
Tu codes en quoi ton projet ?

A+
Uri

C++, j'utilise SFML avec Code::Blocks.

Ça va faire 2 ans que je programme en amateur, et là j'ai envie de m'attaquer au réseau

Pour revenir au serveur qui gère le monde, mon plus gros problème reste de savoir ce que le serveur envoie aux clients pour les mettre à jour.

Il faudrait envoyer la position des joueurs au moins tous les dixième de seconde pour que ce soit fluide. Est-ce possible en TCP ?

Encore une petite question.
Imaginons que le client et le serveur aient tous deux une classe en commun : "classe.hpp".
S'ils utilisent exactement la même, est ce que je dois recopier pour le client et le serveur le fichier .hpp ou est ce que je peux le factoriser ?

Concernant l'envois, tu peux simplement faire un boolean "moved" qui passe à true si le joueur à bougé, ou qui reste à false si le joueur n'a fait aucun mouvement. S'il passe à true du envoies à tous les clients la nouvelle position du joueur.

(A faire dans une partie update du serveur ).

Hello,

Oui essaie de travailler avec des variables prenant le moins de bits possible afin d'avoir un message le plus léger possible.

Perso je travaille avec des énumérations.
Mon message est composé de l'ID du client, son mouvement, son action.

Exemple d'énumération

<Serializable()> Public Enum EStatus As Integer
StandBy
Walk
MoveBack
Run
Fall
JumpUp
JumpRequest
Flyhack
StrafeLeft
StrafeRight
End Enum

Mon message sera de cette forme :
1524|EStatus.Walk|EAction.Shoot

A+
Uri

Merci bien, c'est très éclairant
Et pour les classes partagées, des idées ?

Une autre question rapide : vaut-il mieux envoyer régulièrement la position de tous les objets aux clients, ou alors peut on se contenter d'update la position d'un objet que quand celui-ci est déplacé ?