Discussion :

[hickscorp]

Ceci est un double post de ce que j'ai déja mis ici:
http://www.developpez.net/forums/sho...56#post1286356
J'effacerais ou mettrais "Résolu" sur celui des deux qui ne génère pas de réponses ^^

Bonsoir à toutes et à tous,

Je me permet de soliciter les plus expérimentés d'entre vous afin de répondre à quelques questions que je me pose...

Tout d'abord, un rapide récap de la situation s'impose
Je développe en projet perso une ébauche de MMORPG. La partie serveur est en Java (Peut être un peu de C++ plus tard, flemme pour le moment):
- Le plus efficace a été de laisser de côté le modèle multithread. Un thread par client si +1000 clients en même temps me semble un peu trop utopiste).
- Tous les calls RPC sont aussi exclus, j'utilise des sockets NIO (Un listener principal threadé associe un socket à chaque objet Player après son autentification).
- J'évite de tabler sur la sérialisation d'objets pour la partie réseau, car côté client le language ne sera pas forcément Java.
- Le thread listener utilise un parser XML pour décortiquer les inputs, et les places dans un sync arraylist qui sert de queue.
- Parallèlement un 2e thread examine la queue, extrait les commandes (en FIFO donc) et les execute ou non, fonction de tests internes aux rêgles du jeux, et envoie directement le résultat au(x) client(s) concerné(s) par le résultat (Je m'interroge quant à la mise en place d'une queue ici aussi, mais il me semble que c'est inutile pour le moment et non critique à mettre en place dans le futur )
- Pour effectuer la persistence de tous les objets du jeu, j'ai conçu un modèle d'objet générique dont tous les autres découlent. Le stoquage est pour le moment assuré par du MySql à l'aide du pilote JDBC fourni par MySql.

Aucun schéma n'est encore adopté côté client, je m'efforce de maintenir une version "light" en Flash au fur-et-à-mesure que le serveur avance. Toutefois le protocole sera au final ouvert afin de permettre à chacun de pouvoir développer son propre client de la façon la moins contraingnante que possible (Le protocole est pour le moment encapsulé en XML mais je prévois de donner la possibilité à chaque client de choisir entre divers formats).

Maintenant, les questions
Ce jeu étant le tout premier temps réel réseau que je développe (Ma copine crée l'Artwork), je ne sais pas du tout comment est censée être structurée la partie traitement des taches "autonomes"...
Vu qu'au final, j'aimerais que les "mobs"/"NPC" se déplacent tout seuls au milieu des joueurs, je pense qu'il faut au serveur une notion d'unité de temps, de tick quoi, mais comment? Dois-je utiliser un timer (ou boucle avec test sur temps de dernière exec) vérifiant chaque object toutes les "n" millisecondes? Ou dois-je tourner perpetuellement sur tous les objets en updatant ceux qui ne l'ont pas été depuis "max" milliseconds? Help...

Dernier point... Je cherche une ou plusieurs personnes ayant une expérience dans le domaine, pour répondre ponctuellement à ce genre de questions. Je n'ai jamais plus de deux questions par semaine, mais le fait que j'ai toujours la/les même(s) personne(s) comme interlocuteur(s) serait pas mal, cela éviterait de récapituler à chaque fois le background du jeu
Quite bien sûr à poster ici les trucs pertinents pour aider les suivants.

Bon, je crois que c'est tout, j'éspère avoir été clair, parfois je m'embrouille souvent je m'embrouille pas toujours je m'embrouille.... Zavez compris

Merci!
Pierrot.

Je rajoute après coup:
- Les "mobs" ce sont les monstres, les trucs qui vivent sans forcément interaction, ou contre lesquels on se bat, etc. Dans l'idéal, je voudrais éviter le Dongeon & Dragons, pas de succession porte-monstre-drop-levelup. Trouver une armure sur un cadavre de scorpion est un concept débile, mon objectif est de ne placer que des mobs style loups, biche, cerf, serpent etc... A partir de la matière première reccueuillie en les tuant, on pourra alors créer des items en s'adressant à un personnage possédans un corps de métier adapté...
- Les "NPC" sont les "Non Playing Characters", les personnages dirigés par IA. Dans l'idéal, je voudrais un total de 0 NPC sur la version prod... Le but étant de déléguer toutes les taches accomplissables à des gens acceptant d'endosser l'identité du personnage les gérant...

[Sixissor]

je ne sais pas du tout comment est censée être structurée la partie traitement des taches "autonomes"...
Vu qu'au final, j'aimerais que les "mobs"/"NPC" se déplacent tout seuls au milieu des joueurs, je pense qu'il faut au serveur une notion d'unité de temps, de tick quoi, mais comment? Dois-je utiliser un timer (ou boucle avec test sur temps de dernière exec) vérifiant chaque object toutes les "n" millisecondes? Ou dois-je tourner perpetuellement sur tous les objets en updatant ceux qui ne l'ont pas été depuis "max" milliseconds? Help...

Je me souviens que pour un projet réseau que j'ai fait il y a quelque temps j'ai été confronté au même problème, et j'ai trouvé une solution assez simple:
en ce qui concerne toutes les informations que le serveur doit retransmettre aux clients simultanément, j'avais fait un thread sur le serveur (encore un... ) qui envoyait des informations aux clients toutes les N millisecondes mais là j'ai utilisé une astuce: j'ai bridé la boucle d'envoi à 60 fps, comme ça je savais que dès que le serveur envoyait une information de ce type aux clients, elle était envoyé toutes les 1/60 secondes.
Dans ton cas tes mobs auront la même position (que calculera le serveur) sur tous tes clients et qui sera rafraichit toutes les 1/60 secondes... Mais c'est un peu violent
Sinon une autre méthode, le serveur définit un point d'arrivé ou une direction à suivre et c'est le client qui s'occupe de calculer les coordonnées pour y arriver: une fois que le déplacement est terminé, le client envoie la mise à jour de la position au serveur, mais dans ce cas il faut brider la boucle "de rendu et d'affichage" du client. Bref, à toi d'essayer et de trouver la meilleure méthode.
Il y en a sûrement beaucoup...

En ce qui concerne le nombre de clients... Soit tu le brides, soit tu fais plusieurs serveurs

Après tu peux optimiser en créant plus de threads en fonction de tes besoins mais ça devient vite affreux avec la synchronisation
Dans un tel programme, la structure est très importante, mais les threads encore plus, c'est pour ça qu'il faut passer pas mal de temps à réaliser un projet de ce type et vaut mieux y traîner que d'y revenir et réecrire des parties par la suite.

En tout cas ta méthode de gestion du réseau m'a l'air pas trop mal jusque là... Tu es sur la bonne voie De tous les modèles réseau, le modèle multithreads m'a paru le meilleur.
Par contre je te conseillerai le C/C++ avec la lib Posix de socket car elle fonctionne pratiquement pareil sous Unix et sous Windows, et en plus c'est suffisament bas niveau pour te permettre une vraie gestion réseau. Maintenant, comme je ne connais pas la lib Java que tu utilises pour le réseau... Je ne peux pas comparer.
Elle utilise quel protocole ta lib ? TCP ou UDP (ou autres) ?

Bonne chance tu en auras besoin avec les threads

[Matthieu Brucher]

T'as déjà au moins fait un jeu en réseau simple ?

[shenron666]

En complément à ce qu'a dit Sixissor, j'ajouterai une règle à suivre si tu veux éviter toute triche (hack des trames réseau par exemple) :
le serveur a toujours raison, que ce soit sur une position d'un monstre ou d'un joueur, l'existence d'un objet à ramasser, ...
ce n'est pas facile et tu vas devoir malgrès tout être tenté de l'enfreindre dans certains cas, cheche tous les moyens de l'éviter et prends cette décision en dernier recours en notant dans ta "todo-list" qu'il faut que tu corriges cela

si tu veux t'éviter de lourdes transactions réseau et une charge supplémentaire sur le serveur, évites les tests et calculs de collision entre 2 objets qui se déplacent (2 joueurs, 2 monstres, 1 joueur 1 monstre)

Je rajoute après coup:
- Les "mobs" ce sont les monstres, les trucs qui vivent sans forcément interaction, ou contre lesquels on se bat, etc. Dans l'idéal, je voudrais éviter le Dongeon & Dragons, pas de succession porte-monstre-drop-levelup. Trouver une armure sur un cadavre de scorpion est un concept débile, mon objectif est de ne placer que des mobs style loups, biche, cerf, serpent etc... A partir de la matière première reccueuillie en les tuant, on pourra alors créer des items en s'adressant à un personnage possédans un corps de métier adapté...
- Les "NPC" sont les "Non Playing Characters", les personnages dirigés par IA. Dans l'idéal, je voudrais un total de 0 NPC sur la version prod... Le but étant de déléguer toutes les taches accomplissables à des gens acceptant d'endosser l'identité du personnage les gérant...

juste pour t'embêter, en fançais on dit :
- mobs = streums
- NPC = PNJ (Personnage Non Joueur)

Bon courage

ps:

Dans l'idéal, je voudrais éviter le Dongeon & Dragons, pas de succession porte-monstre-drop-levelup. Trouver une armure sur un cadavre de scorpion est un concept débile

totalement d'accord avec toi sur ce point

je te conseillerai d'aller voir le site de Kamron (Jérémy Chatelaine)
www.kamron.net
il a développé Kyrne pendant 5 ans, un projet de mmorpg gratuit qu'il a fini par abandonner (comme beaucoup) pour diverses raisons
je te conseille particulièrement cette page :
http://jeremy.chatelaine.name/french...firstrules.php
et également le document de "Chris Taylor" dans la section Design

[la_tupac]

Salut, je suis passé par la aussi mais le srv multithread est effectivement une impasse car il te faut un serveur de l'armée pour faire jouer 4 joueurs en même temps. La solution est le multiplexing ( voir select() Winsock ). La solution finale (sans mauvais jeux de mots sur la 2em guerre mondial) ressemble à ça :

- un thread d'acceuil avec un socket en listening qui ajoute chaque nouvelle connexion puis en attend une autre.
- un thread de receptio packets avec fonction select() qui bosse sur touts les sockets clients.
- le même en envoi.
- un thread gestion NPC-MOBS-INTERACTIONS.

enfin le vrai soucis reviens : la bande passante montante. Donc bosse dure sur le protocol ainsi que le cryptage de tes packets.
Soit fort : j'y ai passé près d'un an et c'est pas terminé (soit je fais un peu de zèle).

a+

[nouknouk]

rhô, c'te déterrage de topic qui a plus de deux ans

A noter qu'il serait intéressant de savoir ce que ce projet est devenu...
Si hickscorp repasse par là un jour...

[Mickael23]

Pourquoi select tout le temps?

Un serveur multitheader n'est pas une impasse et des modeles de sockets tel que IOCP sur les platformes windows et epoll sur les platformes linux sont bien plus recommandé pour un serveur de mmorpg.

[yamashi]

Pourquoi select tout le temps?

Un serveur multitheader n'est pas une impasse et des modeles de sockets tel que IOCP sur les platformes windows et epoll sur les platformes linux sont bien plus recommandé pour un serveur de mmorpg.

Il faut te dire que dans un MMORPG le plus lourd ce n'est pas le reseau mais les calculs a effectuer pour chaque client, l'interaction, les collisions...
Le reseau en lui même n'est pas lourd comparer a tout ca.
Déjà ne pense pas a faire du multithread, c'est bien trop compliqué et dangereux pour rien... (Tu risques même d'avoir de moin bonne performance à cause de tout les lock...)
Alors pourquoi pas epoll, kpoll, kqueue ?
Parce que ce n'est pas portable... Et des benchmarks montrent que select et epoll/kqueue se valent jusqu'a 1000 connexions.
Donc ce que tu peux faire, c'est 1 thread select/ n clients.

Sur mon serveur qui marche très bien je fonctionne comme ca:

Thread main -> select()
|-> thread world, qui gère le monde...
|-> thread cli, pour une interface console (dors la plus part du temps)

Donc a partir de select je passe mes messages recu au thread world qui lui ne fait que suivre le modèle suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
world.update();
pour tout client, client.update();

En fait ca ne se passe pas réellement comme ca, je casse la list des clients en n morceau (n étant le nombre de core disponible), j'execute de facon parrallèle la logique nécessitant la base de donné...
Puis je reprend la liste de départ de je la balance au GPU pour faire le reste.

PS : IOCP c'est les désavantages de select et du multithread ensemble donc c'est même pas la peine d'y penser...

[DzzDDzzD]

Il faut te dire que dans un MMORPG le plus lourd ce n'est pas le reseau mais les calculs a effectuer pour chaque client, l'interaction, les collisions...
Le reseau en lui même n'est pas lourd comparer a tout ca.
Déjà ne pense pas a faire du multithread, c'est bien trop compliqué et dangereux pour rien... (Tu risques même d'avoir de moin bonne performance à cause de tout les lock...)
Alors pourquoi pas epoll, kpoll, kqueue ?
Parce que ce n'est pas portable... Et des benchmarks montrent que select et epoll/kqueue se valent jusqu'a 1000 connexions.
Donc ce que tu peux faire, c'est 1 thread select/ n clients.

Sur mon serveur qui marche très bien je fonctionne comme ca:

Thread main -> select()
|-> thread world, qui gère le monde...
|-> thread cli, pour une interface console (dors la plus part du temps)

Donc a partir de select je passe mes messages recu au thread world qui lui ne fait que suivre le modèle suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
world.update();
pour tout client, client.update();

En fait ca ne se passe pas réellement comme ca, je casse la list des clients en n morceau (n étant le nombre de core disponible), j'execute de facon parrallèle la logique nécessitant la base de donné...
Puis je reprend la liste de départ de je la balance au GPU pour faire le reste.

PS : IOCP c'est les désavantages de select et du multithread ensemble donc c'est même pas la peine d'y penser...

plutot d'accord mais pas totu à fait pour la partie "Il faut te dire que dans un MMORPG le plus lourd ce n'est pas le reseau mais les calculs a effectuer pour chaque client" avec 5000 clients suivant la taille des paquets le reseau peu deja devenir un point de blocage mais la le blocage est effectivement plus lié a un probleme de BP qu'au fonction de traitement du reseau.


sinon entierement d'accord pour le multithread, il faut en limiter les usage, diviser et faire executer une meme tache simple sur plusieurs core marche bien mais apres tous faire en multithread c'est la garantie d'apparition de problème d'acces concurrent de dead lock et d'etats instables.