[DEBAT-RS] Choix d'une architecture réseau type MMO RPG/FPS/RTS/RSA

Questions à propos du scripting. Hors Shader, GUI, Audio et Mobile.
Avatar de l’utilisateur
MartyMacFLy
Messages : 13
Inscription : 07 Août 2019 11:19
Contact :

[DEBAT-RS] Choix d'une architecture réseau type MMO RPG/FPS/RTS/RSA

Message par MartyMacFLy » 18 Août 2019 19:38

Salut à tous,

Clause du sujet: Histoire d'éviter les insultes et la guerre, je tiens juste à vous prévenir que je ne suis pas en train de créer un jeux, j’apprends :hehe: Et j'ouvre un débat dans le cadre du "plaisir public" :diable:

Je ne suis pas responsable si quelqu'un tente de créer un MMORPG avec un RaspberryPi à 40€.
Pour ceux qui souhaite insister, les MMORPG disposent d’énormément de serveur très couteux et coder par des équipes extrêmement compétente, vous ne trouverez aucune réponse dans mon topic, c'est juste de la "recherche", de la gymnastique mentale


Je suis actuellement en train de développer un semblant de serveur type MMO en C#, tournant sur un RasberryPi3B+ (le truc de bricoleur du dimanche quoi). Car la connexion entre une dizaine de personne, c'est facile, on peut coder avec les fesses, et garder quelque chose de rapide. Alors que si l'on souhaite gérer des milliers de personnes (c'est utopique et .. onirique mais ça m'a travailler toute la nuit :pleur4: ), il faut être beaucoup plus rigoureux sur la façon de gérer les clients.

J'hésite donc entre 2 architectures réseaux pour le moment, c'est tout ce que mon cerveau à pu produire ce weekend.

La première :
J'ai un Thread de réception UDP qui tourne en boucle, et à la réception d'un paquet formaté venant du client, de type [TYPE de TRAME]:[IDENTIFIANT UNIQUE]:[DATA], un switch m’envoie la requête dans un Thread dédié au [TYPE DE TRAME].
Donc pour exemple :
Le Thread de réception reçoit UPDATE_POSITION:MARTY:x52,y85, il l'envoi donc dans un Thread dédié au UPDATE_POSITION déjà instancié et démarrer au lancement du programme.
L'avantage que je trouve à ce format, c'est que les Thread dédié sont déjà instancié, démarré, et surtout le nombre est fixé en fonction du nombre de [TYPE DE TRAME].
En revanche, pour l’inconvénient principal, c'est qu'une file d'attente pourrait se créer à l'entrée de mes Thread si trop de requête sont envoyé.

La seconde :
J'ai toujours mon Thread de réception UDP qui tourne en boucle, avec la réception classique de trame formaté [TYPE de TRAME]:[IDENTIFIANT UNIQUE]:[DATA]. Sauf que cette fois, je créer un Thread par [IDENTIFIANT UNIQUE] et je gère chaque client à part dans un Thread.
L'exemple qui va bien :
Le Thread de réception reçoit CONNECT:PAULETTE:JEVEUJOUER, je créer un Thread attitré à PAULETTE et je lui autorise la connexion. Ensuite, il reçoit UPDATE_ODEUR:PAULETTE:JEPU, donc c'est le Thread attitré à PAULETTE qui va gérer son UPDATE_ODEUR.
J'ai un peu peur avec ce format, j'ai l'habitude de travailler avec les Threads, mais pas avec 100 Threads, je sais pas si ça peut tenir le coup. Par contre là pas de problème de file d'attente, et synchronisation de Timer/Latence entre les joueurs beaucoup plus facile à mettre en œuvre.

La Troisième (bonus):

Là c'est la guerre, je fais un gros mix, une usine à gaz. En gros je fais une inception de Thread :
Le Thread de réception UDP reçoit CONNECT:SERGE:JECODESTARCITIZENTOUTSEUL, je l'envoi dans le Thread CONNECT qui à un Thread attitré a SERGE.
Ou l'inverse, Le Thread de réception UDP reçoit SEND_CHAT:EDGAR:"Je révolutionne le MMORPG", je l'envoi dans un Thread attitré à EDGAR, puis dans le Thread enfant SEND_CHAT.
Celui là j'y crois vraiment moyen, sauf si j'arrive a overclocker l'ARM de mon Raspberry à 100Ghz :mdr1: mais ça m'est aussi passé par la tête donc je balance on sait jamais ahah ...

Si vous avez des critiques sur les architectures proposé, je suis preneur, et si vous avez des architecture plus dingue encore, on est tous preneur :-D
Dernière édition par MartyMacFLy le 02 Sep 2019 09:53, édité 4 fois.

Avatar de l’utilisateur
Alesk
Messages : 2086
Inscription : 13 Mars 2012 09:09
Localisation : Bordeaux - France
Contact :

Re: [MY-RS] Choix d'une architecture réseau type MMO

Message par Alesk » 18 Août 2019 20:38

J'suis un noob en réseau, donc j'ai pas de grands conseils à te donner (et j'aurais peut-être besoin de ton aide si tu peux me filer un coup de main sur le code réseau de mon bomberman)

... mais jette un oeil là dessus : https://www.youtube.com/watch?v=wwLW6CjswxM

ça pourrait t'ouvrir des pistes :mrgreen:

Avatar de l’utilisateur
MartyMacFLy
Messages : 13
Inscription : 07 Août 2019 11:19
Contact :

Re: [MY-RS] Choix d'une architecture réseau type MMO

Message par MartyMacFLy » 19 Août 2019 20:00

Merci pour la vidéo :)
Bon finalement ils ont l'air d'utiliser un modèle réseau assez simpliste d'un Thread par joueur avec des tunnels pour faciliter le dialogue. (De ce que j'ai compris, j'ai pas tout regardé je l'avoue ahah )

Par contre le moteur du jeux est monstrueux chapeau au dev' Oo !

Passe en mp pour expliquer ton besoin en réseau ;)

Avatar de l’utilisateur
MartyMacFLy
Messages : 13
Inscription : 07 Août 2019 11:19
Contact :

Re: [MY-RS] Choix d'une architecture réseau type MMO

Message par MartyMacFLy » 22 Août 2019 14:56

Petit up, pour l'avancé de mes recherches.

En trainant un peu sur les forum de dev' de jeux. En lisant des documents écrits par des équipes complètes. Je remarque déjà que l'UDP, pour du MMORPG-like, c'est quasi mort (sauf les MMOFPS/TPS, mais ça c'est des équipes de fou furieux).

Les plus gros MMORPG utilisent le protocole TCP, pour sa fiabilité. Exactement ce dont on a besoin, de la fiabilité, car le serveur instaure beaucoup de limite au joueur (règlement etc..). Je m'étais attardé sur l'UDP, par affinité et simplicité, ce qui était une mauvaise idée.

De mon côté, pour mon projet de console qui discute entre elle. Je vais soulager mon serveur, et instancier ma MAP fictive. Chaque instance tournera sur un serveur différent (bon en réalité ça sera plein de machines virtuelles avec une puissance équivalente à un RasberryPi 3B+).

Pour le threading : .
1: Connecter/Déconnecter les client sur le serveur MAIN;
2: Recevoir les données;
3: Envoyer les données;

Pour les serveurs :
1: Serveur de connexion principal, qui sera connecter en tant que maitre/esclave avec les autres serveurs;
2: Gérer la base de donnée;
3: Le serveur pour les instance de combat (j'utilise un serveur à part car c'est pendant un combat qu'on impose le plus de règlement);
S+1: Un serveur par instance;

C'est l'architecture la plus proche des MMORPG que j'ai pu trouvé pour le moment. Et comme d'habitude, si vous avez des idées, des remarques, on est tous preneurs :) !
De mon côté je bidouille ça.

Répondre

Revenir vers « Scripting Javascript, C# et Boo »