Bonjour !

Aujourd'hui, après une pause, je décide de repartir dans mon projet de MMO (fou d'ailleurs vu ma motivation)...

Cependant, pendant que je progrèse du coté 3D et rendue, je me retrouve bien largué du reseau qui est quand même la base du projet ! Et résultat, je repousse au lendemain, je procrastine... (je voulais sortir le mot) et j'avance pas !


Ce problème c'est que pour comprendre, au début j'ai besoin de tutos pour me fixer des bases fonctionnel. Les tutos que j'ai eu sont 1 chat (client/serveur), ... et rien d'autres, donc je me retrouve convaincu que tout le reseau fonctionne sur le principe du chat, mais voilà, ça ne me convaint pas !

J'utilise RakNet car c'est la seul lib qui proposait des tutos claires.

Pour l'instant mon chat fonctione comme ça :

                                -------->Client2
Client1 -----> Serveur-------->...
                                -------->Client3

Bon, c'est la bonne chose, mais je n'arrive pas a comprendre comment la lib fait pour savoir qui est qui, qui fait quoi, ...
Sachant que les flux devront êtres (théoriquement) multiples et croisé car :

Joueur1 : Saute -> Code [/*/224587557521], <-[/*/54287557521]->voit le joueur2 courrir, ...........
Joueur2 : Cours -> [/*/54287557521], <-[/*/224587557521]->voit le joueur2 sauté, .........

Ce qui fait que les infos sont colosalles, mélangé, préciseuses, et en plus doivent renvoyer 3 positions par objet mobile en temps réel....


BAM, la je pet un cable, je pige plus rien !

Et sur le tas, on rajoute du reseau pour le telechargement d'info, du chat, ....

Ya t'il plusieur socket d'utilisé ? Comment tous se tas peut gerer ?


Bref, je me suis lancée dans le reseau sans VRAI connaissance et mainteant je l'ai dans le...


Merci de votre patience pour m'expliquer comment voire ces choses en retirant la cire que j'ai dans les yeux.

(Et si je vous dérange vous plutot qu'un autres site, c'est parce que vous êtes bien callé, et surtout vous sentez pas vos pets comme bcp de programmeur )


PS : Quels sont les façon de proposé ses petits modelages de low comme ressources libre ?

Dernière modification par Willikus (10-05-2007 19:52:46)

Juste une petite question en quel langage travaille tu? utilise tu mono/.net?

J'essairais de te donner quelques conseils cet aprem vu que je bosse actuellement sur le même type de projet mais que moi c'est la 3d qui me pose de gros soucis alors que j'ai un modèle de réseau simple mais efficace.

J'utilise le c++...

Je veux bien des conseils (même si ce n'est pas le même language) au moins pour m'orienté.


(" moi c'est la 3d qui me pose de gros soucis" si c'est niveau modelage je peux faire/expliquer quelques trucs )

Bon... je suis surement bassinant

Mais "I have a dream" !

Je pensais :

Est il possible de séparer les information reseau en indiquant comme suit : (les /*..*/ seront invisible et reste des instructions)

/*chat*/ Willikus : Comment aller vous ?                                       Chat
/*action*/*Willikus*/*coucou*/                                                      Action du perso : salut de la main
/*position*/*1032*/*4152*/*1442*/                                              Se situe en x:1032, y:4152, z:1442
/*target*/*1032*/*4152*/*1552*/                                                Se déplace vers une position  x:1032, y:4152, z:1452
/*equipement*/*ID25421*/*ID485444*/*...*/                                Le perso est actuellement équipé de ...
...

Est ce que le taux de rafraichissement peut permettre un tel fonctionnement ?
Faut t'il limité l'emition de ces instructions lors de changement ?
Exple :
Position : permanent
Target : SI mouvement
equipement : SI modif
action : SI activé
...


Merci !

j'ai pas trop compris ce que tu voulais faire, mais garde a l'esprit que :

1 - tu ne concoit pas ton application autour du réseau, mais tu choisi les structures de données que tu va partager

2 - tu doit autant que possible éviter que les actions du joueurs influent de facon a surcharger le traffic ( a doom 1, on pouvait faire planter le réseau en tirant sur un type en continu, parce que 1 balle = 1 paquet envoyé)

3- les performances du réseau sont en général bonnes, mais un mmorpg restera quoi qu'il arrive une daube en terme de performances des lors que 30 personnes seront au meme endroit

Dernière modification par Jerry Kan (14-05-2007 21:29:23)

Donc pour éviter la surcharge du serveur, il y a interet a repartir plusieurs serveurs, performant pour les flux rapide (combat, deplacement) et plus lent pour l'inventaire et le stockage d'info divers ?
Ya t'il possibilité qu'un client active plusieurs serveurs selon désire ?

Ensuite, dans un FPS (mon choix), une balle = forcément 1 paquets.
Etant données que si on file 1 coup d'epee, 1 seul dégat doit etres comptabilisé...

Pour finir, "30 personnes font laguer", qu'en est t'il des serveurs Ennemy Territory qui gère 32 (voir 64) personnes au dégat, balles par balles avec un multitude d'action compliqué (médic, ingénieur, ...) ?

Merci tout de même pour "tu ne concoit pas ton application autour du réseau, mais tu choisi les structures de données que tu va partager"
Qui fait que je vais poursuivre ma programmation du jeu

Willikus :

Donc pour éviter la surcharge du serveur, il y a interet a repartir plusieurs serveurs, performant pour les flux rapide (combat, deplacement) et plus lent pour l'inventaire et le stockage d'info divers ?
Ya t'il possibilité qu'un client active plusieurs serveurs selon désire ?

techniquement c'est possible, en pratique c'est extremement compliqué, ca constitue un projet rien que de concevoir une telle architecture, (les systèmes répartis sont mon domaine en fait) tu as des problèmes de synchronisation, de cohérence, etc ..

Willikus :

Ensuite, dans un FPS (mon choix), une balle = forcément 1 paquets.
Etant données que si on file 1 coup d'epee, 1 seul dégat doit etres comptabilisé...

ah non tu peux encapsuler tes informations dans 1 meme paquet, sans avoir a les générer de facon directement indépendante, l'idée, c'est que tu va envoyer souvent des information de position par exemple, et quand tu va tirer/frapper, tu ajoute ou rempli un champ a ton paquet, tu n'en génére pas un en plus, ce que je veux expliquer, c'est qu'il faut tout envoyer dans le meme pas paquet,


C'est a dire que tu va avoir 1 frame par seconde graphique, un frame par seconde dans le coeur de ton appli, et un frame par seconde de mise a jour réseau, (les 3 sont indépendants dans mon idée de la conception)
apres, tu peut toujours faire de l'interpolation pour mieux gérer les transitions, mais ca a ses limites

Willikus :

Pour finir, "30 personnes font laguer", qu'en est t'il des serveurs Ennemy Territory qui gère 32 (voir 64) personnes au dégat, balles par balles avec un multitude d'action compliqué (médic, ingénieur, ...) ?

Ennemy territory c'est un MMORPG ? les perfs sont un peu meilleures pour les jeux FPS, et les serveurs sont monstrueux
les actions compliqués n'ont pas de vrai influence sur la charge du traffic réseau,
Mais je persiste dans mon analyse, tant que l'industrie restera sur les modeles actuels de client-serveur, ont aura des performances tout juste passables

Willikus :

Merci tout de même pour "tu ne concoit pas ton application autour du réseau, mais tu choisi les structures de données que tu va partager"
Qui fait que je vais poursuivre ma programmation du jeu

ce que je veux dire c'est : crée ton application, et voit le données que tu partage entre deux joueurs, ca implique bien sur que ta conception facilite la récupération/la réception cohérentes de ces données, (faut pas que ya des bouts de données partout a charger/mettre a jour)

Dernière modification par Jerry Kan (15-05-2007 08:51:03)

Jerry Kan :

C'est a dire que tu va avoir 1 frame par seconde graphique, un frame par seconde dans le coeur de ton appli, et un frame par seconde de mise a jour réseau, (les 3 sont indépendants dans mon idée de la conception)

et ca c'est une bétise de ma part, un lapsus plus ou moins révélateur, parce que j'ai tendance a les imaginer comme ca, bien sur que le coeur et le FPS graphique sont souvent fortement liés,
selon la conception le FPS réseau doit l'etre plus ou moins, mais c'est tjs comme ca que j'y pense spontanément

Salut !
Concernant les déplacements, pourquoi envoyer des coordonnées absolues de ton perso ? En envoyant uniquement la valeur des déplacements tu peux utiliser des nombres de taille moindre occupant bien moins d'octets lors des transmissions. N'utilise le Z que si ton perso doit effectuer des vols (Lévitation, Aviation, etc). Sinon laisse gérer le z par le serveur en fonction de la configuration du terrain et le client gérer ça avec la physique avec une synchro a l'arrivée (fin de la chute).

Heu... dans un serveur de MMORPG, laissé gerée le Z de chaque perso ?! Ca me parait un peu surchagent non ?

Ensuite, un paquets, il correspond a quoi en réalité (parce que je vois ça partout sans comprendre)

Je voit mal comment contenir plusieurs variables dans 1 "chose" puis les séparer et les reconnaitre ?!

Si on envoie la position absolue, il faut un flux constant et assez rapide non ?

Merci !

Willikus :

Heu... dans un serveur de MMORPG, laissé gerée le Z de chaque perso ?! Ca me parait un peu surchagent non ?

je crois que l'idée de diOxy c'étais de faire recalculer le z par le serveur ET le client, afin déviter de le transmettre, voire de ne pas le faire calculer par le serveur (le serveur aurai une vision a plat)

Willikus :

Ensuite, un paquets, il correspond a quoi en réalité (parce que je vois ça partout sans comprendre)

Je voit mal comment contenir plusieurs variables dans 1 "chose" puis les séparer et les reconnaitre ?!

en fait, selon ce que tu utilise pour faire du réseau, tu va devoir concevoir une structure de donnée dans laquelle tu rempli des champs, (positions, actions, etc ..) et tu l'enverra, si possible la taille de la structure (ton paquet logique) ne doit pas dépasser la taille des paquets de données physiques (ta carte réseau envoie les données paquets par paquets)

Willikus :

Si on envoie la position absolue, il faut un flux constant et assez rapide non ?

de toute facon, il faut un flux constant,
le problème avec les positions relatives, c'est que si on rate une, ca deviens nimporte quoi, alors que les abs ca me semble mieux

Presque ça Jerry Kan !

Je me base sur la gestion de déplacement du serveur de mmorpg RunUO. Le fichier MAP utilisé par le client est également utilisé par le serveur ce qui fait que pour une position X,Y, vu que le personnage ne vole pas (sauf cas contraire : lévitation, coup de pied a l'arrière train, avion), il a ou finira par avoir les pieds sur terre, donc le z ET ou SERA connu par le client et le serveur sans être obligé de le transmettre.

Pour les positions relatives, c'est vrai qu'elles risquent d'être décalées, mais une routine côté serveur demandant a interval régulier une synchro X,Y,Z permet de régler ça. Nous parlons bien d'un MMORPG, pas d'un FPS.

Toujours sur l'histoire de paquet (oui j'ai la tête dur et je comprend mal quand j'ai pas de visuel, le cas du reseau):

Un paquet c'est comme une mini base de données avec des champ plein, ou vide, que le serveur peu lire car programmé pour lire ce format de paquets et récuperer chaque ligne du tableau ?

Le reseau, c'est pas mon domaine du tout, mais j'aime bien partager les bonnes adresses
http://www.gamedev.net/reference/list.asp?categoryid=30

et de façon plus générale, http://www.gamedev.net/reference/