[eternite23]

Bonjour

Je vous présente mon projet de "MMORPG", nommé Outland Runner.
Je mets MMO entre guillements, ayant pris soin de lire attentivement de nombreux posts concernant la difficulté de mettre au point un tel jeu pour une petite équipe.

Cependant, certains choix pour ce jeu sont destinés en fait à limiter autant que possible les "grosses difficultés" qui seraient propres aux MMO - réactivité du gameplay, contenu à rallonge et contenu highend, graphismes 3D, etc... Le but est en effet de contourner et d'éviter ce qui rend la réalisation d'un MMORPG impossible par une petite équipe.

Voici un résumé du gameplay :
MMO sur un monde découpé en îles.
Chaque île accueillera plusieurs centaines à plusieurs milliers de joueurs
Action lente : chaque action demandera en général plusieurs secondes de “résolution” : le jeu ne sera donc pas axé sur des combats rapides ou tres rapides comme dans un FPS. Ce choix est dicté à la fois pour des raisons de performances mais aussi du système d’avancée des joueurs
système de progression à base de “compétences” apprises en temps réél – voir Eve Online. pas d’XP
visualisation dans une forme de 3D isométrique – pas de vision à la 3e personne, ni subjective.
une économie entièrement gérée par les joueurs
transport de marchandises organisé par les joueurs : pas de système de transport automatiques”
PNJ employés par les joueurs, ou les organisations politiques/ économiques dirigées par les joueurs
système de besoins et d’aspirations pour les PNJ
système politique, avec votes de lois
système de justice pour les aspects
système de PK en open zone, régulé par la présence de PNJ embauché
système de météo
des aspects d’exploration et de recherche
système mafieux : vols, extorcsion de fonds, activités illégales
systèmes de contrats économiques, transports, sécurité
construction libre des bâtiments, housing.

Un blog de développement a été créé à l'adresse suivante : http://outlandrunners.wordpress.com

N'hésitez à venir y suivre l'actualité du jeu, je me sentirai un peu moins seul
Certains éléments du game play sont plutôt clairement définis, d'autres demandent encore à être approfondis. A la fois en terme d'intérêt, de gestion des dérives, et des impacts techniques sur le jeu.

Pour le moment, je suis surtout en train d'étudier les aspects techniques de création de jeu. Le choix des outils n'est pas totalement arrété bien sur, même si des préférences assez marquées pour différences raisons, du fait de mon expérience en tant que développeur - actuellement C# / SQL Server.

Même si j'ai un passé de développeur C/C++, je ne souhaite pas plus que çà réutiliser des langages non managés. Le coté assez lent de mon jeu me permettra peut être de l'éviter.

Je ne suis pas sur d'utiliser un GameEngine, ayant l'impression qu'ils sont quand même plutôt destinés à des MMO assez "classiques, avec gestion de la physique, vue en 3D sophistiquée, réactivité de type "temps réel". Je pourrais envisager en prenant un moteur dont le source est fourni, de l'alléger peut être, mais c'est à ce demander si c'est un pari gagnant au final. Peut être qu'il est plus intéressant de développer à un moteur "nécessaire et suffisant", plus adapté à gérer bcp de joueurs, tout en minimisant la réactivité nécessaire. Je me disperse un peu sur cet aspect, mais c'est vous l'aurez compris, le point qui me souci le plus - à juste titre je pense.

[lujan]

J'aime beaucoup, je pense que ce sera l'une des prochaines approches de mmo.

Ca ce rapproche pas mal d'Archéage et pathfinder, avec pour influence directe : EVE ?

[eternite23]

En effet, l'influence de Eve Online est assez forte. On pourrait aussi citer Ultima je pense, même si pour le moment, j'hésite à "densifier" les aspects tactiques du PVE/PVP. Je souhaitais en rester à quelque chose de simple, mais j'ai bien sur conscience de l'intérêt que porte les joueurs à cela. Peut il être compensé par d'autres aspects ? C'est un peu la question.

L'ambition graphique est par contre infininement plus modeste - je serais surement à titre personnel joueur à ArcheAge néanmoins et le suis à Eve, bien sur.

J'ai penvie our Outland Runners, d'une immersion et d'un "investissement" dans la destinée commune, plutot qu'un parcours "individuel et héroique". Même si je souhaite apporter des composantes roleplay pour favoriser les aspects sociaux du jeux.

[Senader]

Pour ta question, il faut à mon avis ajouter la profondeur nécessaire au combat, c'est vraiment une partie importante. Quelle que soit la profondeur d'un jeu, si on a fait le tour des combats en une demi heure on s'ennuie très vite.

[eternite23]

C'est sans doute vrai, vu à quel point c'est omniprésent dans les jeux. Il faut que je réfléchisse à cet aspect, peut etre avec qqu qui s'occuperait de réfléchir plus complètement à cela.

Pour ceux que cela intéresse, j'ai fait un petit compte rendu de la lecture "Game Coding Complete 4th Edition de Mike McShaffry; David Graham"

Cela se trouve sur mon blog de développement http://outlandrunners.wordpress.com

[eternite23]

Même si ce n est sans doute pas le chemin le plus court, nous avons décidé finalement de creuser la plateforme Ogre pour la réalisation de Outlandrunners Runners - plus de précisions sur le blog http://outlandrunners.wordpress.com pour ceux que cela intéresse

[eternite23]

Le forum des éventuels collaborateurs de Outland Runners vient de s'ouvrir à l'adresse http://forumsbckoff.outlandrunners.com
Le projet est dans sa phase de game design.

[Titan.]

Salut,
Déjà sache que j'admire le fait que tu te tiennes à ton projet depuis 1 an, que tu ait un planning et que tu t'y tiennes.
Maintenant, si tu fais le bilan, au bout d'un an tu commences seulement le game design, avec les livres que tu as lus tu devrais commencer à te rendre compte que tu ne peut pas faire un mmo amateur. c'est comme décider de se lancer dans la construction d'une cathédrale "amateur" après avoir feuilleté un livre de maçonnerie et regarder la couverture d'un livre d'architecture.
Personnellement, j'ai moi aussi un "projet" de mmo...
Pour l'atteindre, j'ai commencé par aller chercher un diplôme d'ingénieur, avec de grosses connaissances en dev, mais également apprendre à être cadre, savoir gérer une boîte, etc. et j'ai conscience que ça va certainement finir comme 3Dduo, un fail qui ruine un investisseur assez con pour m'avoir fait confiance et ensuite du serious gamme et du jeu Facebook pour pouvoir bouffer.

Maintenant que j'en ai fini avec l'avertissement d'usage que tu dois être soulé à force de lire, je vais essayer de t'aider plus directement:
- déjà sur ton blog, tu es surpris que pathfinder utilise Unity, effectivement le moteur réseau built-in ne permet pas de gérer efficacement un mmo, mais tu as accès au .NET, tu peux recoder ton implémentation réseau, même si tu perds l'interface graphique kikoo propre à Unity. ensuite il existe plusieurs librairies réseau disponible, la plus connue étant
photon.
d'autre part, ne perd pas de vu que tu à 2 applications à programmer, un serveur et un client, ils n'ont pas besoin d'être écrit dans le même langage ni de tourner sur le même OS.

- je travaille avec ogre -bullet au travail actuellement (stage), vu que c'est votre techno cible n'hésite pas à me poser des questions techniques par mp je pourrais y répondre facilement, par contre je préfère 1000 fois unity et te conseille vivement de reconsidérer ton choix.

- les fautes d'orthographe, mais surtout le SMS et les fautes de frappe dans un blog, ça pique les yeux, un blog ça demande une réalisation soignée, ça se tape pas comme on tape un troll en pleine partie de LoL... tu as déjà excessivement peut de chance de trouver des gens compétents, là tu te tire une balle dans le pied.

[eternite23]

En ce qui concerne les fautes, il y en a qq unes en effet. Sans doute une volonté de ne pas passer non plus trop de temps à vérifier tout cela, mais je ferais un effort ;-)
Quand à Unity, je n'en exclue pas totalement l'usage. Je me suis intéressé de loin à photon, et disons que si je devais retenir un framework réseau, c'est clairement l'un de ceux qui avaient attiré mon attention. La partie réseau est sans doute la partie la plus délicate. En ce qui concerne le coté MMO, c'est qd même un terme tres "large". Il faut bien donner un nom au type de jeu envisagé, mais l'idée maitre reste de faire des choses... selon ce qui sera possible. Le projet ne nous amenera jamais à refaire un wow, ni un qcq MMO de ce type là : c'est en effet irréalisable. Je n'en ai ni les moyens, ni en effet les compétences.
Je reste donc dans l'idée de faire... selon ce qui sera possible de faire, en particulier en terme de graphismes, de réactivité réseau et de concurrence d'accès.

Tout cela du reste j'ai déjà eu l'occasion de le dire. Quand à la programmation, ça fait qd même 20 ans que la pratique. Enfin en vérité, plutot 30. Je crois donc avoir un peu de bouteille malgré tout.

Et le game design sera sans doute organisé selon un effet de couches, permettant de ne retenir au final que celles qui nous semblent réalisables.
Pour la durée, j'avance au rythme qui me parait "gérable" sans finir sur les rotules : les semaines de travail sont déjà assez chargées.

Et même si tout cela n'aboutit pas... cela sera tout de même une expérience intéressante. Donc rdv dans un an ;-)

[Titan.]

tes fautes d'orthographe ne sont pas un problème tu n'en fait pas assez pour que ça gène la fluidité de lecture, en revanche le SMS est à proscrire, rien que dans ce message où tu dit faire un effort, tu met une abréviation par ligne, à chaque fois on s'arrête pour chercher ce que tu a voulu dire, d'ailleurs le "qcq" j'ai toujours pas trouvé, bon dans ce cas si on comprend la prase même en retirant ce paté, mais c'est pas toujours le cas... et les fautes de frappe de ton blog prouvent que tu ne te relis pas.

pour ce genre de publication (surtout si t'en rédige qu'une poigné par an), tu doit travailler ton style, te faire relire par des proches, faire plusieurs jet avant d'arriver à la version final, etc. tu essai de convaincre des gens de bosser bénévolement pour toi à chacun de tes post.

['Az]

Citation :

Publié par Titan.

d'autre part, ne perd pas de vu que tu à 2 applications à programmer, un serveur et un client, ils n'ont pas besoin d'être écrit dans le même langage ni de tourner sur le même OS.

Ils n'ont pas besoin, mais c'est quand même un plus non négligeable. Il y a toujours un bout de code qui gagne à être en commun. Déjà le protocole, mais aussi (et surtout) tout un tas de règles de game-design qui pourraient avoir besoin de tourner des deux côtés, et dont il faut systématiquement reporter le code.

Par exemple, le calcul des collisions, qui va demander une validation à la fois du client et du serveur.

@eternite23:

Il semblerait que tu vises un jeu PC, le choix de la technologie doit donc impérativement prendre en compte ton mode de distribution. Un installeur sur le site de ton jeu a toute les chances de n'attirer personne : Beaucoup de gens ne voudront pas prendre le temps d'installer le jeu. Seul les grand nom arrivent à se frayer un chemin de cette façon.

Via steam, c'est déjà plus accessible, mais c'est moins d'indépendance, et l'entrée est plus sélective.

L'idéal pour débuter, c'est via navigateur, mais ça limite énormément la techno : actuellement : Unity, Flash ou Java.


Je vois que tu passes énormément de temps à te documenter, mais fais tu de la mise en pratique ? Des prototypes ? Des petits jeux moins ambitieux pour prendre la main ?

La théorie est une chose, mais la plupart des problèmes que tu rencontreras ne seront écrit dans aucun des livres que tu pourras lire.

Je ne saurais que te conseiller d'en choisir une qui s'adapte à ce que tu veux dans les grandes lignes, puis de l'étudier à fond et commencer des prototypes.

Ca sera beaucoup plus instructeur, et ton jeu avancera plus vite. Si tu te rends compte après coup que ça n'était pas le choix idéal, tampis.

C# / unity me semble une bonne option, parce que le C# est un langage puissant, unity une plate forme très à la mode, et parce qu'il y a énormément de documentation disponible. Même si en tant que linuxien, ça me fait grincer des dents d'avoir à conseiller unity ^^'

Excellente bibliographie par ailleurs, certains titre m'inspirent

[eternite23]

Apres une interruption d'environ 6 mois, le projet a repris.
Afin de couper court à ses heures passées à la recherche de "la" techno/game engine idéale, j'ai fort logiquement tranché lors de cette reprise, pour un développement sous Unity, en C#.

Pour la partie serveur, j'utiliserai Photon de Exit Games.
J'ai eu aussi l'occasion de passer d'intéressantes heures à échanger sur un forum qui avait été créé pour échanger sur le game play du jeu.

Mais je me suis rendu compte aussi que cela m'entraînait sur toujours plus d'options, et d'éléments à implémenter, sans savoir forcement ce qui serait gérable - et en particulier à combien de joueurs, ce qui reste toujours le point le plus délicat à évaluer.

Bien qu'il soit recommandé d'avoir un Game Play totalement défini au départ, cela m'a semblé peu compatible avec le fait de faire avancer un minimum le projet.
J'ai donc opté pour une approche Scrum/Agile, qui montrera surement quelques bottlenecks, mais qui m'a permis au moins de démarrer l'ensemble.

Malgré l'attractivité permanente que cela représente, j'ai choisi - et je résiste - au fait de consacrer mon temps au design, graphismes, sound design, etc...
Il faut reconnaître que même quand on teste son "proto", on a envie qu'il soit beau ou au moins présentable. Et quand je vois la qualité de réalisation de certains graphistes ici ou ailleurs, cela donne clairement envie.

Mais j'ai choisi de me concentrer sur le gameplay, le codage des interactions, etc... Donc de mettre au point les choses en terme de data et d'actions.
L'aspect client-serveur du jeu me montre d'ailleurs combien cela s'avère nettement plus compliqué qu'un jeu solo.

Les progrès sont donc modestes, mais quand je vois ce qu'il a fallu déjà écrire pour gérer une simple cueillette d'un fruit sur un arbre - et encore manque-t-il de nombreuses choses - je vois bien que l'aspect itératif du développement du projet s'impose.
Et pourtant c'est une action basique que l'on voit dans de nombreux MMO/RPG.
D'autres ont-ils été étonné de la "complexité" de cette simple action en mode Full Authoritative ?

A suivre sur http://outlandrunners.wordpress.com

[Corvanders]

Ça a l'air très intéressant comme projet à suivre.

Hop, le blog est dans mes favoris .

[Farad77]

Une précision quand à Visual Studio pour Unity; tu peux te lancer sans problème la seule limitation est que tu ne peux pas debug ton code sous VS, donc quand je dois le faire je bascule sous mono develop mais pour le code il n'y a pas photo entre les 2.

Tu as juste à changer l'external editor dans les preferences, il n'y a rien d'autre à faire.

['Az]

Citation :

Publié par eternite23

Les progrès sont donc modestes, mais quand je vois ce qu'il a fallu déjà écrire pour gérer une simple cueillette d'un fruit sur un arbre - et encore manque-t-il de nombreuses choses - je vois bien que l'aspect itératif du développement du projet s'impose.
Et pourtant c'est une action basique que l'on voit dans de nombreux MMO/RPG.
D'autres ont-ils été étonné de la "complexité" de cette simple action en mode Full Authoritative ?

Bienvenu dans le monde du multijoueurs Sans vouloir chercher à te démoraliser, une action de récolte est loin d'être ce qui a de plus difficile à gérer ^^'

Les plus gros soucis que tu rencontreras seront probablement liés aux problèmes de désynchronisation et de lags.

Le problème est complexe : Les joueurs ont rarement des connexions aussi fiables qu'on peut en avoir en réseau local et localhost. Du coup, la situation du jeu sur leur client est vite très différente de la vue du serveur. Si ton serveur est trop rigide et ne tiens pas compte de ces fluctuations (ex: quand le joueur a appuyé sur une touche, il n'est déplacé qu'après une validation du serveur), tes joueurs auront un sentiment de lag permanent.

Si ton serveur est trop flexible, les désynchronisation donneront naissance à des aberrations (téléportations, joueur intouchable à cause de son lag, etc...) Ces problèmes s'accentuent dès qu'on parle d’interactions entre plusieurs joueurs (combats), et les tricheurs pourront aussi en profiter pour se donner des avantages.

Tu ne te rendras généralement pas compte de ces problèmes avant le passage en prod, vu que tu vas tester ton jeu en réseau local, voir en localhost pour le debug. Il faut constamment avoir ces problèmes en tête en programmant, pour pouvoir en anticiper un maximum.

Quand on parle de MMO, se rajoute une difficulté supplémentaire : celle de la monté en charge. Ton jeu peut très bien tourner pendant tes tests, avec 5 joueurs. Et les performances s'effondrer lorsque tu en auras 100. Et on voit tout les types de cas de figures : quand les performances se réduisent petit à petit au fur et a mesure de la fréquentation de ton jeu, c'est pas bien grave, tu as le temps de le voir venir et de t'adapter.
Mais quand ton serveur passe d'un coup dans un état "je marche bien" à un état "je marche plus du tout" parce que "le joueur de trop" vient de se connecter, c'est déjà beaucoup plus compliqué à gérer ^^

[Farad77]

Selon son choix d'utilisation de Photon il pourra détecter ce genre de probleme assez tôt puisque l'utilisation classique se passe sur un cloud et donc avec un ping beaucoup plus conséquent qu'en localhost.

Idem pour les problemes d'autorités, il y a quelque mecanisme directement en photon pour aider sur ce sujet, après perso j'ai bossé recemment sur un jeu multi à 4 en coop pour une jam la mise en ligne a été atroce comparé à nos tests en local, je n'ose pas imagine un mmo a plusieur centaines voir milliers de joueurs!

Bonne chance en tous cas!