Bonjour,
J'ai actuellement en tête de realiser un mmo en 2d isometrique (d'ailleurs, j'ai fini à environ 40% l'editeur de niveau en une semaine ) et je cherche de la doc, des cours/tutos et également des conseils pour ce qui est du réseau. Le jeu sera programmé en python avec surement un peu de c/c++ pour les parties demandant beaucoup de calcul coté serveur (pathfinding, collisions).

Donc pour l'instant , j'ai pensé à un systeme comme ceci:

Connexion en TCP du client au serveur pour s'identifier (soit un serveur à part mais je pense plutot à un thread qui gere uniquement cela).
Ce serveur renvoie l'adresse IP et le pseudo du joueur au serveur (ou thread) principal (le tout sera stocké dans un dictionnaire).

Ensuite entre le client et le serveur principal, je pense utiliser l'UDP (le jeu étant en temps réel ):
Le client envoie en boucle les entrées clavier au serveur , le serveur traite le tout et renvoie les données comme la position des joueurs , des monstres etc...

Il yaura également un module de chat en TCP.

Ce systeme vous semble t-il viable pour un petit mmo (genre si j'arrive à avoir 100 joueurs connecté en simultanés (qui ne seront pas tous sur la même map normalement ), ca serait déjà pas mal

Et aussi, en ce qui concerne la sécurité, si le client ne fait qu'envoyer les entrées clavier, ya t-il quand même des précautions à prendre ?

"les parties demandant beaucoup de calcul coté serveur (pathfinding, collisions). "
ça je sais que c'est le client qui doit le gérer

non mais ca si c'est le client qui le fait, il ya risque de hack
(enfin pour les collisions, ca se fera des deux cotés pour eviter d'avoir un perso qui rentre dans un mur et qui saute juste aprés avoir recu la position devant le mur )

Sinon, pour le fait d'envoyer une seule fois, le probleme c'est que les paquets envoyé avec UDP on un risque de se perdre

OP, avant de te lancer dans une architecture aussi complique, je te suggere de faire simple. Ne te galere pas a faire du TCP et de l'UDP pour differente chose. Fait totu en TCp et regarde ce qui t'arrive. En pratique les gens cherches a utiliser UDP parcequ'ils ont l'impression que ca sera mieux, mais en en pratique ce n'est pas utile si souvent.

godrik

j'avait lu que pour les applications temps réel, l'UDP était mieux du fait de sa vitesse
Mais si tu me conseille de faire tout en TCP, la difference de vitesse entre les packets UDP et TCP sont négligables alors ?

Pour résumer simplement la différence entre TCP et UDP, TCP s'assure que tes paquets arrivent à bon port. Il fait beaucoup de vérifications pour te le garantir, ce qui le ralentit.

A l'inverse, UDP essaye d'aller le plus vite possible, il ne fait pas 10.000 vérifications et de temps en temps, les paquets sont perdus.

Ca ne rend pas UDP moins bon que TCP, tout dépend de ton application. Par exemple sur Youtube, ton flux vidéo est transmis en UDP. Parce que c'est pas grave si tu perds quelques paquets, l'utilisateur aura juste une baisse de qualité de la vidéo un bref instant. Plus il y a de paquets qui passent, plus la qualité sera bonne, mais perdre un paquet n'est pas critique.

Pour un jeu, ça dépend de ce que tu envoies. Quoiqu'il arrive, je te conseille de d'abord tester TCP. Ne passe à UDP que si les échanges de données sont trop lents (et dans ce cas, garde à l'esprit que ton paquet peut ne pas arriver à destination).

Le serveur sers en effet qu'a informer de l'interaction entre les joueurs.

Pour un déplacement par exemple. Lorsque le joueur A se déplace vers le haut, tu indique aux autres joueur JOUEUR_A-HAUT lorsqu'il s'arrete tu envoi un paquet JOUEUR_A-ARRET-coorX-coorY afin de replacé le joueur exactement au bon endroit au cas ou une latence serais apparu.

Le déplacement en soit doit être codé coté client. Sinon pour 100 joueurs qui se déplace tu aura beaucoup trop de requette simultanées.

Tout le secret d'une architecture réseau pour un MMO repose sur l'optimisation des paquets envoyé. Il faut limité au maximum l'envoi d'informations inutile.

ok, merci , donc je vais d'abord essayer d'implémenter le tout en TCP

"Le serveur sert juste à faire la liaison entre ce qu'un joueur voit et ce que l'autre joueur fait . (Un perso qui se déplace)."

Oui, et non, ça dépend des cas, tu ne peux pas laisser le contrôle total sur les clients, par exemple si je hack le jeu et retire les collision murs/personnage, je pourrais alors traverser tout les murs et le serveur ne me l'interdira pas, la même chose si le serveur m'envoie la position de tout les joueurs du niveau, il me suffit de changer les textures par des textures transparentes et j'ai une vue infinie. Le client va lui même calculer les collision, mais le serveur doit aussi le faire pour s'assurer qu'il n'y a pas de triche/bugs, tout comme il ne faut pas bêtement renvoyer toutes les actions de tout les joueurs du niveau (en plus ça fait plus de données à renvoyé).

Bien sûr dans une première version on peut tout renvoyer sans rien vérifier, mais pour la version finale ce n'est pas possible (sauf si vous voulez que votre jeu ressemble à WarZ).

Je pense que la solution idéale est un savant mélange des 2.

D'un côté le client doit faire un maximum de choses, et de l'autre le serveur doit synchroniser tout le monde de temps en temps.

On le voit bien dans les jeux en ligne. Lorsqu'il y a un lag, tu ne vois plus personne bouger pendant X secondes puis tu te retrouves téléporté à ton point de départ. Pendant le lag, tu n'étais plus connecté au serveur, mais tu pouvais quand même bouger, tirer, ... Lorsque la connexion revient, tu te retrouves la ou tu étais avant le lag. Tout vérifier en permanence ce n'est pas possible, mais tu peux très bien vérifier de temps en temps et rectifier les erreurs.

Par exemple, imagine qu'un joueur se déplace tout droit. Tu peux raisonnablement penser qu'il gardera la même direction/vitesse pour les prochaines 100ms. Du coup, le joueur ne va pas envoyer sa position tous les 10ms mais tous les 100ms. Pour les autres joueurs, tu prédis sa position en fonction de sa dernière position connue, de sa vitesse et de sa direction. Dès que tu reçois une nouvelle position de la part du joueur, tu utilises celle-ci comme nouvelle position initiale (pareil pour la vitesse/direction).

Bref, en essayant de prédire ce que le joueur va faire et en rectifiant en cas d'erreur, tu peux limiter significativement le nombre de paquets qui transitent (critique pour un jeu réseau).

Mais ça reste compliqué à gérer pour toi, car tu dois pouvoir corriger toutes les erreurs (si le joueur a subitement changer de direction, il est possible qu'il ait "évité" les tirs ennemis, ...). Bref, commence simple avec du TCP + transmission de toutes les données + vérification de tout. Quand ça marchera bien, tu pourras commencer à optimiser tout ça.

UDP ce'st bien et c'est utile dans certains cas. Mais j'ai vu plein de gens se lancer dans UDP sans trop s'y connaitre en reseau et passer des semaines entieres a debugger leur moteur de communication. TCP c'est quand meme vachement plus simple et si tu n'as pas besoin d'UDP, ca va significativement t'arranger la vie.