[eternite23]

Bonjour

Je projette de créer un MMORPG.
Parmi les questions que je me pose, il y a celle de ce que j'appellerai le "moteur réseau". Un moteur donc capable de gérer les actions de milliers de joueurs - synchronisation, reception, feedback.

Est que des toolbox comme Unity, ou encore Unreal Dev Kit intègre un tel moteur, capable de gérer effectivement des milliers de personnes ?
Faut il toujours créer soit même ce fameux moteur ?

Faut il utiliser des choses comme ICE , Racknet en plus de Unity, UDK ?

[Titan.]

Salut,
je répondrais pour Unity vu que c'est celui sur lequel je travail.
tu a un moteur réseau builtin qui n'a pas de limite virtuel au nombre de joueur, mais en admettant que tu fasse pas tourner le serveur sur ta connexion de particulier mais sur une connexion symétrique un minimum solide tu doit pouvoir monter a 50 - 70.
maintenant il existe des moteurs réseau que tu peut acheter en plus de ta licence unity. le plus connue étant photon
il te faudra toujours un serveur en béton mais au moins tu sera plus limité par un netcode qui chie dans la colle. en revanche pour photon, la licence gratuite te permet pas de dépasser 100 joueurs, si tu veut un nombre virtuellement illimité t'en a pour 800$.
en fait c'est comme ton moteur de rendu, soit t'est doué et ta du temps, et tu le fait toi même, soit ta de l'argent. mais perd pas de vue qu'un jeu inde, même surtout un mmo t'aura du mal a réunir 100 joueurs.

perso: je te conseillerai de partir sur photon (si tu sais pas le faire toi même), de mettre en prod une version bridé a 100 joueurs, et si ton mmo a du succès, demander des dons pour pouvoir débrider le serveur et pour la location du serveur (qui va surement être de l'ordre de 50 a 150 euro par mois : location de serveur OVH)

pour UDK, je sais qu'il intègre un moteur réseau également qu'il est pas non plus formidable et qu'il existe aussi des solution commercial pour contourner le problème, si ta de l'argent.

ps: si tu veux vraiment du monde, au delà de 200-300 joueurs il te faudra un système de "shard" sur plusieurs serveur, mais ca dépasse mon niveau, dit toi bien que faire un mmo c'est quelque chose de trés complexe, surtout la partie reseau, et que méme en achetant une solution toute faite qui coute un bras tu fera pas de miracle, si il sufisait de mettre 800$ pour pouvoir faire un RvR de ouf qui marche sans lag, des boites comme bioware-mythic aurait pas aboutit a un résultat aussi lamentable que swtor ou warhammer.

[eternite23]

Merci pour ces réponses.
En effet qd tu parles de budget et d'un bras, je m'étonne qu'il n'y ait pas de moteurs réseaux MMO "tout" fait disponibles. Il est possible que parmi le nombre d'acteurs finalement réduit des jeux AA, chacun préfère garder ses recettes et sans doute son propre moteur.

Mon jeu n'a pas pour objectif d'avoir une réactivité à toute épreuve, même si la présence d'une activité PK nécessite un minimum de feedback. Cependant, il s'agit de combat en mode quasi automatique - pas de pouvoirs/mode d'attaque à activer.

Cependant, j'aimerai pouvoir en effet accueillir plusieurs centaines, ou si possible, plusieurs milliers de joueurs.

En ce qui concerne l'aspect budget, investir qq centaines, peut etre milliers d'euros ne me parait pas déraisonnable si cela permet effectivement à un jeu de fonctionner, et d'accueillir ceux qui veulent y jouer.
Sans prétendre réussir à le faire, ce serait cependant dommage de se "rater" parce qu'on a une architecture pourrie, qui finalement ne permet pas d'accueillir les joueurs - je me rappelle par exemple de Darkfall, où il fallait etre là , entre 18h00 et 18h05 pour pouvoir acheter l'un des rares licences mises en vente : cela a du décourager plus d'un joueur.

En ce qui concerne l'aspect moteur, style photon, je ne vois pas trop effectivement l'intérêt de le faire moi même, n'en ayant pas l'expérience il est bien improbable que je puisse faire mieux.
Par contre, d'apres ta réponse, si je prends Unity, il vaut mieux tout de suite intégrer photon, meme en version libre. L'intégrer a posteriori demanderait j'imagine des adaptations de codes qui obligeraient à modifier le projet ?( question sous-entendue : le moteur fourni par Unity n'est pas une version light de photon ? )

[Titan.]

le moteur de unity est différent de photon, après tu pourra adapter ton programme pour passer de l'un a l'autre mais chaque fois que je fait ce genre d'operation un peut lourde y'a plus rien qui marche, et puisque tu est partit pour aprendre a utiliser un outils autant tout de suite apprendre a utiliser celui qui va te servir dans la version final

[Veilugarux]

Citation :

Publié par eternite23

Merci pour ces réponses.
En effet qd tu parles de budget et d'un bras, je m'étonne qu'il n'y ait pas de moteurs réseaux MMO "tout" fait disponibles. Il est possible que parmi le nombre d'acteurs finalement réduit des jeux AA, chacun préfère garder ses recettes et sans doute son propre moteur.

Mon jeu n'a pas pour objectif d'avoir une réactivité à toute épreuve, même si la présence d'une activité PK nécessite un minimum de feedback. Cependant, il s'agit de combat en mode quasi automatique - pas de pouvoirs/mode d'attaque à activer.

Cependant, j'aimerai pouvoir en effet accueillir plusieurs centaines, ou si possible, plusieurs milliers de joueurs.

En ce qui concerne l'aspect budget, investir qq centaines, peut etre milliers d'euros ne me parait pas déraisonnable si cela permet effectivement à un jeu de fonctionner, et d'accueillir ceux qui veulent y jouer.
Sans prétendre réussir à le faire, ce serait cependant dommage de se "rater" parce qu'on a une architecture pourrie, qui finalement ne permet pas d'accueillir les joueurs - je me rappelle par exemple de Darkfall, où il fallait etre là , entre 18h00 et 18h05 pour pouvoir acheter l'un des rares licences mises en vente : cela a du décourager plus d'un joueur.

En ce qui concerne l'aspect moteur, style photon, je ne vois pas trop effectivement l'intérêt de le faire moi même, n'en ayant pas l'expérience il est bien improbable que je puisse faire mieux.
Par contre, d'apres ta réponse, si je prends Unity, il vaut mieux tout de suite intégrer photon, meme en version libre. L'intégrer a posteriori demanderait j'imagine des adaptations de codes qui obligeraient à modifier le projet ?( question sous-entendue : le moteur fourni par Unity n'est pas une version light de photon ? )

Je pense qu'avant de dépensé beaucoup d'argent tu devrais faire le cahier des charges de ton jeu. Et posé tout le gameplay sur papier.

[eternite23]

En ce qui concerne le gameplay et disons, cahier des charges, c'est déjà fait - même si ce n'est pas publié ici.
Le cahier des charges peut évoluer en fonction des capacités : les miennes, celles des outils disponibles, leurs couts.
J'en suis donc à évaluer ces aspects.

[Toro]

Le moteur de Ryzom, le Ryzom Core a un très très bon moteur réseau et il est complètement gratuit : http://dev.ryzom.com/projects/ryzom/wiki
Par contre, il faut savoir programmer.

[eternite23]

Je vais donner un peu plus de détail sur ce que je projette de faire.

En ce qui concerne l'aspect graphique, si je peux avoir une 3D simple, qui ne grève pas les performances de l'ensemble, ce sera sans doute un plus.

Au niveau du gameplay, les actions possibles pour les joueurs mettront toutes un temps "important" à s'exécuter : de l'ordre de 2s minimum, ce qui correspondra certainement à un déplacement.
Les autres actions pourront s'avérer plus longues. Les combats seront en résolution automatique, et ne feront pas appels à des déclenchement de pouvoir comme dans d'autres MMORPG. Les actions de crafting seront plus longues.
On est donc bcp plus proche d'un tour par tour que de l'action effrénée d'un FPS.

Par contre, en plus des joueurs, il y a aura un nombre important de NPC. Sans doute 5 à 10 fois le nombre de joueurs.
Ces NPC feront le même genre d'action que les joueurs : déplacements, combats automatiques, crafting.

Ces actions seront effectuées par la quasi totalité des NPC du jeux.
Si le jeu parvenait à avoir par exemple 5000 joueurs, on aurait donc de l'ordre de 50 000 actions en "attente" en permanence. Avec donc des actions qui prendraient entre 2s et plusieurs dizaines de secondes.

Pensez vous que les systèmes qui nous sont accessibles - investissement de qq milliers d'euros au plus - soient capables de faire tourner un tel jeu ?

[Toro]

Au vu de ta demande, je te suggère fortement de tester Ryzom (dispo en gratuit) pour voir ce qu'il a dans la ventre.
Il a été développé en utilisant le Ryzom Core (RC) dont je te parlais dans le post précédent.
En fait RC est le moteur complet du jeu qui a été rendu open-source (avec même les assets du jeu sauf le son). Donc tu as tout pour faire un MMO.

Ryzom a la particularité de gérer une tétrachiée de PNJ à action complexes sans faire souffrir le serveur de jeu. Crée-toi un compte et va te balader dans la campagne autour du camp et tu y trouveras des hordes (dans le sens premier c'est à dire groupe d'animaux) un peu partout. A la grande époque de Ryzom on avait plusieurs milliers de joueurs à un instant t et bien 10 fois ce nombre en mobs et le serveur ne bronchait pas.
Petit vidéo : http://vimeo.com/1608296

[Titan.]

il faut savoir que peut importe le temps que va prendre une action, elle demande toujours autant de bande passante, a savoir un RPC. ce qui va fortement influer cette bande passante, c'est la fréquence de tes appelles. ce qui est le plus lourd a synchro c'est ta position. en fait ta trop de paramètre qui entre en compte pour pouvoir donner un nombre de joueurs possible. si tes déplacement se font sur un quadrillage, tu peut te contenter d'envoyer un rpc pour dire où tu va au lieu de faire une synchronisation UDP de ta position (par exemple sur unity, par défaut c'est 15 fois par seconde), dans ce cas tu peut vraiment mettre énormément de joueurs. les mobs devrait pas trop baisser les perfs si bien codé, tu peut même laissé une grosse part de résolution locale par exemple.
j'ai pas trop compris ta résolution automatique, en fait il aurait fallu post une présentation détaillé de ton concept de jeu.

sinon pour le moteur de Ryzom, je sais pas si tu développe Taro, mais lire, assimiler et modifier (pour créer un jeu complètement différent), une bonne centaine de milliers de ligne de code C++ bien crade, il faut vraiment être motivé

[Toro]

Il veut faire un MMO, il a intérêt à être motivé !
Pour ce qui est des moteurs de MMO, celui de Ryzom est peut-être difficile à comprendre mais il a l'avantage d'être gratuit, de fonctionner réellement et surtout de tenir la charge sans problème. Il est un des rares à regrouper ces 3 critères. Énorme plus, il a une équipe active de dev prête à répondre à toutes les questions.
Il y en a bien d'autres faciles d'approche comme Realm Crafter, Eclipse Origins mais trop limités et d'autres comme WorldForge incomplets.
Il y a aussi les moteurs solides comme BigWorld ou Hero Engine mais ceux-là sont hors de prix pour une petite équipe.

[Titan.]

Hero engine, tu a une licence gratuite jusqu’à publication, mais en revanche il prennent 30% des bénéfice une fois sortit, (comme l'UDK, vu que l'op l'a cité je suppose que c'est déjà pris en considération), je lui ai pas conseillé puisque ils mettent 2 mois a fournir l'éditeur quand tu passe commande, et qu'il est tellement instable que j'ai même pas réussi a faire tourner sans crash la scène de démo.

BigWorld, j'ai jamais essayer mais la licence indie est a 300$/ans + 10% des revenue, je sais pas ce qu'il vaut en revanche, mais ça peut être une piste a creusé.

c'est pas plus hors de prix que l'UDK, surtout si son jeu sors pas.

ps: le Ryzom core est gratuit, mais la licence t'autorise t'elle a l'utiliser pour un projet commercial ?

[boulbard]

Il y a aussi ICE qui à l'air d’être bien pour un MMO (petit exemple), mais par contre pour une licence commerciale faut voir avec la boite au cas par cas et je n'ai aucune idée des prix pratiqués.

[Toro]

Citation :

Publié par Titan.

Hero engine... et qu'il est tellement instable que j'ai même pas réussi a faire tourner sans crash la scène de démo.

Le projet "The repopulation" est d'ailleurs dans la galère avec cet engine. En 2011 ils ont eu une gros blocage entièrement du à des bugs de l'engine.

Citation :

Publié par Titan.

ps: le Ryzom core est gratuit, mais la licence t'autorise t'elle a l'utiliser pour un projet commercial ?

Tout à fait. Par contre c'est du GNU AGPL, à ce que j'ai compris cela oblige à rendre toute modification de l'engine open source. Mais cela ne concerne que le moteur. Les images, sons, graphismes, scripts de quêtes, mécanismes, etc ne sont pas concernés par cette license.

[eternite23]

Pour faire suite à tout cela, voici quelques précisions sur le projet et son état d'avancement.
La carte est en effet plutot découpée sur des cases de 10m*10m, subdivisées elles mêmes en 16 cases - 2.5m donc de coté.
Toute créature se trouvera sur l'une de ses cases, et y sera seule. Une mise à jour de 15 positions par seconde ne se justifiera pas, dans la mesure où le déplacement d'une case 10*10 à l'autre demandera plusieurs secondes - c'est donc un jeu plutot 'lent".

En ce qui concerne la résolution des combats, il n'y a pas de pouvoirs à appliquer durant le combat, ni de déplacement style esquive, etc... C'est donc plus du "tour par tour". Le jeu dans son ensemble peut s'assimiler en tour par tour du fait de sa lenteur. Cependant je ne pense pas imposer un découpage "artificiel", du style "tout le monde se déplace au top de mon chrono. Il y a aura donc bien une impression de temps réel, mais au déroulement lent.

En ce qui concerne les moteurs de jeux, j'en ai examiné qq uns - Unity, C4Engine, Essenthel, Neoxis -, pas forcement en profondeur, évidemment. Ils présentent des fonctionnalités tres intéressantes, mais semblent pour la plupart - enfin ceux accessibles financierement et "techniquement" - tres axés sur ce coté MMORPG avec qq dizaines de joueurs.
Ils gèrent donc bcp de choses - physiques, collisions - mais justement à des fréquences dont je n'ai pas besoin. En contrepartie, aucun ne semble en mesure de gérer des centaines de joueurs. Tous ne mettent pas à disposition le source à un prix, là encore, raisonnable. Il semble donc difficile de "papier" sur la capacité par exemple de Unity à gérer le jeu tel que je l'envisage, même en simplifiant certaines choses, mais tout en admettant une connexion de centaines ou milliers de joueurs donc. L'offre de uLink n'est pas non plus tres claire, et tout semble reposé sur le concept de "zones" et d'instances.

En conséquence de quoi, je me suis dit que ces moteurs visaient un type de jeu particulier, avec un dimensionnement "prédéfini".
Ce dimensionnement semble essentiellement conditionné par l'aspect moteur réseau. Même si on peut parfois leur adjoindre des licences complémentaires de moteurs réseau, il semble bien difficile d'avoir un chiffre "concret" qui permette de dire "oui on peut gérer 2000 personnes" avec ce jeu, dans un monde en particulier seamless, et je dirais même vraiment seamless - on ne passera pas par un couloir qui masque le changement d'instance.
J'ai donc besoin de zones "dynamiques" tout en ayant un monde aussi grand que je pourrais le vouloir, et en pouvant gérer presque "chaque arbre".

Il n'est pas facile d'avoir des infos, en combinant toutes les contraintes - parmi lesquelles l'envie de coder en C#, qui est mon langage "quotidien". Revenir au C++ ne m'enchante guère, et me mettre à Python, guère plus. On comprendra donc que j'ai privilégié dans mon "étude" certains moteurs plutot que d'autres.

Pour l'instant donc, je m'évertue de comprendre justement cette problématique réseau, vu qu'elle semble prépondérante.
Et je me suis tourné pour le moment vers Photon, qui semble plus évolué que lidgren par exemple.

J'ai envisagé aussi de m'intéresser à JMonkeyEngine, mais peut on baser un développement de plusieurs années sans doute, sur un projet avec si peu d'"acteurs" ?

L'idée donc qui se profile est un ensemble M-Ogre - Photon, auxquel je pourrais adjoindre "finement" si possible des modules de gestions complémentaires si nécessaires.
Cela complique singulièrement les choses, mais la maitrise complète ou presque des sources, semblent être la seule "sécurité" que l'on peut prendre pour ne pas se retrouver brutalement bloqué par un engorgement réseau.

On voit d'ailleurs que même de grands moteurs - enfin leur composante gratuite - comme UDK ou Cry Engine sont prédéfinis pour fonctionner avec qq dizaines de joueurs maximum. N'ayant bien sur pas les moyens d'acheter et d'étudier les sources du Cry Engine par exemple, je me propose donc d'utiliser des solutions plus "modestes" comme celles évoquées plus haut, pour un jeu, qui devrait ressembler visuellement bcp plus à un Anno-Ultima, qu'à un MMORPG classique en 3D, quoique la décision n'est pas totalement arrétée.

Comme vous le voyez ma principale préoccupation reste donc l'architecture à envisager pour gérer un monde capable d'évoluer, avec des centaines ou milliers de joueurs, sur une même ile, suffisamment grande pour que bien sur, tout le monde ne se retrouve tout de même pas au même endroit.
Mais même pour l'organisation en thread du coté serveur, il est difficile d'avoir une info sur une architecture "simple".

[Titan.]

Salut, tu trouvera rien de simple dans le monde du mmo ,
simplement pour reprendre ce que tu disais a propos des temps de chargement: aucun moteur va te proposer un monde sans temps de chargement, c'est a toi de le coder en utilisant un systeme de chargement par streaming, c'est a dire que le jeux doit charger en continue les élément devant toi, sans oublier de détruire ce qui est derrière, ca c'est pour le coté client, le coté serveur lui est obliger de tout calculer malheureusement, la seul solution est donc de séparer le travail entre plusieurs shard ("sous serveur"), deja pour un monde couper en zone le changement de zone (et donc de shard est compliqué) mais dans un monde seamless c'est encore plus compliquer, puisque il faut, si 2 joueurs s'affronte sur une limite qu'ils ne remarquent pas qu'il y a un "changement de map" entre eux, je vais pas te mentir je sais pas le faire, mais j'aurai bien quelques idée sur la question.

sinon pour la charge reseau essai de compter en octet/seconde (avec des estimation) et pas en joueurs, tu trouvera plus facilement réponse a tes question de charge

[Eno]

Si tu dev un truc simple je te conseil vivement de coder ton propre moteur réseau!

Citation :

Publié par eternite23

Mais même pour l'organisation en thread du coté serveur, il est difficile d'avoir une info sur une architecture "simple".

C'est un truc qu'il faut surtout pas faire imo!

[eternite23]

Qqu a t il déjà vu un design-pattern, des algorithmes qui détailleraient la façon de résoudre les "actions" des joueurs et du jeu en général ?
Il y a forcement des méthodes éprouvées pour le faire.

En retrouve des mécanismes de synchro dans les moteurs de jeux. Qqu a t il décortiqué le schéma de traitement "simultané" de ces actions ?

Je ne parle pas ici que concept de caméra par exemple, mais bien de la façon d'organiser les threads, piles d'actions à résoudre, etc...

[GtB]

Je ne connais pas ton niveau de connaissance en la matière de toute façon je ne peux t'aider que sur des concepts de base, n'étant pas très calé niveau programmation et n'étant pas du tout académique, mes connaissances en la matière ne t'aideraient pas de toute façon

La première notion importante est celle de persistance.
Un joueur ramasse une pomme.
-le premier degrés de la persistance c'est le broadcast de l'évènement pour dire aux joueurs alentour que tu lances l'animation ramassage, et la disparition de la pomme dans ta poche, et ici il y a déjà beaucoup de techniques différentes pour ne pas avoir à informer tout le serveur que tu as ramassé une pomme.
-le 2ème degré de persistance c'est d'informer les joueur qui entre dans la zone si la pomme est accessible ou pas.
-le 3ème degré de persistance c'est d'inscrire la pomme dans ton inventaire, dans une base de donnée donc.

Après un autre notion c'est le pilotage des évènements, l'idée étant qu'il ne doit y avoir qu'un pilote pour chaque entité pilotable.
On peut partir de la base que le serveur pilote tous les monstres, mais il est possible de faire autrement :
-les montres peuvent avoir un comportement pseudo-aléatoire facilement vérifiable, ils s'auto-pilotent donc.
-un joueur agressant ces monstres prendra la main sur le pilotage des monstres vis-à-vis des autre joueurs.
-un autre joueur pourra reprendre la main sur le pilotage si son niveau d’agression prend le pas.
-puis une condition de reset du pilotage est rencontrée et les montres rentre en auto-pilotage.
C'est juste un exemple pour montrer la notion de pilotage, en gros le pilote c'est lui qui gère la continuité de la chaîne de persistance, ici cela s'appliquerait mieux dans un contexte p2p.

Il faut rajouter une autre couche, le filtrage et la validation des actions ce qui n'est pas des plus simple.

Bon ben c'est un peu la base d'un environnement multi-user persistant. C'est ce qui définira ton design-pattern et tes algos et non pas quelques recettes toute faite, parce que les approches sont nombreuses et variées.