Constitution d'une équipe

[Folei]

• Présentation de l’Équipe :

Prénom : Julien
Age : 33 ans
Statut : Manager dans une société de service en informatique. Titulaire d'un DUT en informatique (bac +2).

Expériences :
Coordinateur de MMORPG (pendant 2 ans)
Management d'équipe (25 personnes au quotidien) avec suivi budgétaire

Ambitions : Pouvoir vivre de ma passion (sans pour autant être à la recherche de gloire et fortune) !

Compétences : Management - Programmation (C#) - Administration de base de données

Compétences non maîtrisés (et qui serait pourtant fort utile !) : Réseau.

Logiciels maîtrisés : Unity 3D - GDrive (et sa suite) - Excel

Description rapide :
Comme indiqué ci-dessus, je me prénomme Julien, 33 ans. Amoureux d'informatique et de jeux vidéos. Je souhaite lancer ce projet afin de fournir au plus grand nombre, un outil permettant de réaliser un MMORPG avec un minimum de connaissance technique. Avec la même méthode qui me permet de faire aboutir mes projets professionnels, je suis armé pour réussir ce projet personnel très (trop ? vos commentaires me le diront) ambitieux.

Présentation du Projet :

Nom du projet : FW (nom définitif à définir)

Type de jeu : MMORPG. 3D. Inspirations : The 4th coming / World of Warcraft.

Cible : 12+
Plateforme : PC

Univers du jeu : Heroic Fantasy.

Contexte du projet :
Ce projet a vocation de réaliser un moteur de MMORPG, et non un MMORPG à proprement parlé.
L'objectif : se positionner en tant que fournisseur à une équipe de game designer /fan souhaitant créer son MMORPG.

Plutôt que de rentrer dans de longues et fastidieuses explications, je vous propose de prendre un exemple. Dans une utilisation classique d'Unity, nous voulons créer une armée nommée "Dague du sang" (bonus : +5 en force / deg min : 1 / deg max : 3). Il faudrait donc créer l'objet de toutes pièces en indiquant chacun de ces paramètres avant de compiler le jeu et le mettre à disposition des joueurs.
Je souhaite arriver au résultat suivant : Dans Unity, utilisation d'un prefab arme avec les variables suivantes : nom, bonus en force, deg min, deg max). Dans un éditeur extérieur, nous pouvons créer une arme "Dague du sang" (bonus : +5 en force / deg min : 1 / deg max : 3). Cet éditeur enregistre ces informations dans une base de données. Cette même base de données est ensuite lue par le serveur (lors de son initialisation). En clair, cela signifie qu'on peut ajouter du contenu au jeu sans pour autant recompiler les sources de celui-ci.

Bien entendu, tout ne pourra pas être géré hors d'Unity (en terme de contenu). J'ai par exemple en tête, les skins et animations possibles. Pour revenir dans notre exemple, il faudra indiquer dans l'éditeur externe le skin souhaité de l'arme (parmi une liste finie).

Le synopsis du jeu sera différent en fonction des paramètres renseignés par le futur game designer. Libre à lui de choisir si il faut sauver le monde d'un dragon ou d'un roi-sorcier.

Présentation du GamePlay :
Système de Leveling et Caractéristique de Joueur :
La courbe d'expérience sera définie directement dans l'éditeur. L'expérience donnée pour chaque mort de montre également.
Caractéristique "active" de joueur :
[Force / Endurance / Intelligence / Sagesse / Dextérité
Caractéristique "passive" de joueur :
Points de vie, Points de mana, Chance, Classe d'armure, Encombrement, Point de crime, Point d'honneur, Puissances magiques (air, feu, terre, eau, nécro, lumière), résistance magiques (air, feu, terre, eau, nécro, lumière)

De plus, lors de la création du personnage, le joueur devra choisir le genre de son personnage (homme / femme). Humain quoi qu'il en soit.

A chaque niveau supérieur, le joueur aura 5 points à dépenser dans ces caractéristiques "actives" (exemple : Diablo). Il gagnera également 15 points de compétence à dépenser : sorts magiques, compétences actives (vol, attaque, archerie, esquive, coup critique, ...).

Gestion des classes de personnages :
Pas de gestion de classes. Ce sont les décisions du joueurs qui feront de son personnage un personnage unique.

Gestion des magies :
L'ensemble des magies seront définies dans l'éditeur : Nom, formule de dégât, effet de zone, sur le groupe, sur les ennemis seulement...
Il sera possible d'apprendre ces magies chez des PNJs ou via des éléments (livre de sort par exemple) trouvés en jeu.

Gestion des objets :
Chaque objet aura un certains nombres de pré-requis (en compétence, magie apprise, caractéristiques...) et des bonus (de même nature). Il sera également possible d'obtenir des bonus par le fait d'avoir l'objet dans l'inventaire sans pour autant l'équiper.
Il pourra également déclencher des "magies" lors de différents actions : Récupération, équipement, dés-équipement, suppression, en cas d'attaque, en cas de défense...

Gestion des canaux de communication / Discussion privée :
N'importe quel joueur pourra être en mesure de créer un canal de communication (publique ou privé). Il existera néanmoins des canaux de communication par défaut défini dans l'éditeur.
N'importe quel joueur pourra communiqué en privée avec un autre joueur en sélectionnant son nom ou en tapant son nom directement dans une fenêtre de discussion prévue à cet effet.

Gestion de la caméra :
Il y aura 2 scripts de positionnement de la caméra : Une caméra d’environnement extérieur, et une caméra d’environnement intérieur (à l'intérieur des bâtiments).

Seule la caméra extérieure sera mobile. La “cible” sera toujours le joueur. Celui-ci pourra l'orienter en cliquant sur le bouton “molette” de la souris. La molette permettra également de zoomer et de dézoomer.

Par défaut, le script de la caméra extérieure sera actif. Le script de la caméra intérieure se déclenchera lors de la détection avec un box collider dédié. Celui-ci sera créé et positionné via l’éditeur de map.

L’utilisation du script de l’asset “Third Person Camera” servira de base de gestion de la caméra.

Gestion de l'inventaire :
L'inventaire sera piloté par une variable d'encombrement (caractéristique du même nom). Chaque objet de l'inventaire (équipé ou non) aura un poids. Si le personnage est trop encombré, il ne pourra récupérer d'autres objets. Il pourra alors disposer ces objets dans un coffre, les détruire ou les vendre à divers marchands.

Il y aura une seule monnaie (pièces d'or). L'or n'aura pas de poids.

Joueurs contre Joueurs :
Il sera possible d'attaquer n'importe quel joueur (il n'y aura pas de "factions / camps") à la condition que l'écart entre le niveau des joueurs soit inférieur à celui définir dans l'éditeur. Par exemple : Si l'écart maximum défini dans l'éditeur vaut "5" : Un joueur niveau 50 ne pourra pas attaquer un joueur niveau 40 (et inversement) mais pourra attaquer un joueur niveau 45.

Cycle nuit/jour & Météo
La gestion des cycles jours/nuit ainsi que la météo seront gérés par l’utilisation de l’asset “Sky Master Ultimate”.
L’heure “en jeu” sera équivalente à l’heure réelle du serveur. Celle-ci sera identique quelques soit la scène en cours.
La gestion de la météo pourra être modifiée (de manière immédiate ou planifiée) par les outils d’administration GM. La météo pourra varier d’une scène à l’autre.

Outils d'administration GM
Une boite de dialogue devra être disponible pour permettre aux GMs du serveur de répondre aux attentes des joueurs. Vérification des informations sur le joueur, sanctions, organisation d'animation...

Quelques points clefs concernant le projet :
Ambitions :
Ce projet a pour ambition de couvrir les fonctionnalités évoquées ci-dessus. En résumé : Un personnage évoluant dans un environnement multijoueur, pouvant tuer des monstres ou des joueurs, apprendre des sorts, parler à des pnjs, récupérant des objets et pouvant réaliser des quêtes.
Oui, il n'est pas évoqué la notion de guilde, craft et tout ce qui peut être imaginé. Ce n'est pas une erreur.
Se lancer dans un projet trop important (dans un contexte non professionnel) est le meilleur moyen de ne pas atteindre ces objectifs. Je pense donc qu'il est préférable de viser moins de fonctionnalités, mais d'arriver à obtenir un produit fini. D'autres fonctionnalités pourront être largement envisagées une fois qu'une première version du projet sera abouti.

Comme vous pouvez le constater également, ce ne sont que les grandes lignes du projet. Avant de se lancer dans la réalisation de chaque fonctionnalité, le détail de celle-ci sera revue avec l'ensemble de l'équipe afin de se challenger mutuellement.

Architecture :
https://drive.google.com/open?id=1MkDMW ... hAJZFr-ht8

Recrutement pour le projet :
Rôles : Infographiste 2D (1 Place)
En charge de la modélisation des GUI / Modélisation 2D (depuis des modèles 3D) pour affichage dans l'inventaire.

Rôles : Développeur C#(1 Place)
En charge de la réalisation de l'éditeur de map.

Rôles : Développeur C#(2 Places)
En charge de la réalisation du jeu à proprement parlé.

Rôle : Chargé de Marketing / Communication
Tâches à accomplir : Faire des Veilles Technologiques sur les Crowdfunding, communiquer sur les Réseaux sociaux l'avancée du Projet.

L'ensemble des modèles 3D / Animations / Musique seront importées depuis l'Unity Asset Store. Photon sera utilisé afin de gérer la relation client / serveur. Je n'évoque pas ici les budgets, mais c'est bien sur prévu.

Rémunération de l'équipe :
En début de projet, avant de se lancer dans la réalisation, chaque fonctionnalité sera étudiée afin de lui attribuer un certain nombre de point. Le projet total valant 1000 points.
Chaque serveur mis à disposition aura une boutique propre (gérer par son propre coordinateur). 30% des revenus de chaque serveur ira à l'équipe en charge du jeu (l'équipe en cours de constitution). Sur ces 30%, la moitié seront réinvestis afin de mettre en place de nouvelles fonctionnalités, l'autre moitié sera partagée en fonction des points obtenus lors de la réalisation.
Ce point sera largement discuté avant de lancer véritablement le projet avec les membres de l'équipe.

Si vous êtes intéressés par l'un de ces rôles, vous pouvez soit me contacter par MP, soit par un message ci-dessous.

Gestion de projet :
L’ensemble de la documentation écrite du projet sera centralisée à travers un Google Drive (GDrive).
L’ensemble des discussions de fond sur le projet sera réalisée à travers un forum dédié. Cela permettra de partager avec l’ensemble des membres du projet les discussions en cours ainsi que de conserver les éléments qui auront permis d’aboutir à la décision finale.
Le suivi des bugs et tâches sera réalisé par l’outil Trello.
La gestion du planning projet sera réalisée par l’utilisation de “Ganter for google Drive”.

Merci pour votre lecture. Et en espérant pouvoir échanger avec vous rapidement !

Folei.

[NDrew]

J'ai cru comprendre que tu souhaitais des avis du coup je me permet.

Je trouve l'idée d'un éditeur de MMORPG intéressante, ou du moins amusante quand on voit la quantité de personne qui se lancent dans l'aventure de créer ce type de jeu.

Par contre, il y à un point très très nébuleux, qu'en est-il des serveurs? Il seront fournis ou chacun devra monter les siens? Et dans les deux cas, à tu pensé au fonctionnement de ces serveur, tu fixe un nombre maximum de joueur par serveur?

Donc pour répondre à la question d'une façon simple, oui je crois que c'est trop ambitieux.

Bon courage si tu te lance malgré tout.

[Folei]

Bonjour,

Bien qu'étant clair faible sur la gestion de la relation client/serveur, je me suis penché sur la question.

Si je résume :
L'idée est de fournir un support à la personne qui montera un serveur. Dans l'optique d'utiliser Photon, ça donne ça en terme de prix :
https://www.photonengine.com/en/PUN/Pricing#plan-20. En clair, plus tu as des joueurs, plus tu payes. La boutique en ligne de ton serveur doit être étudié afin de rendre ton serveur fiable financièrement parlant.

Et oui, il ne faut pas hésiter sur les avis / questions.

[NDrew]

Photon n'est pas acceptable comme solution pour un MMO comme il n'est pas fait pour avoir un système de serveur autoritaire. Avec photon, normalement c'est un des clients qui est serveur, dur d'imaginer un client qui puisse taper dans la base de donnée.

Si j'ai mal compris et que tu donnais l'exemple de photon comme solution de pricing seulement, alors tu vas quand même devoir créer une architecture de serveur et ça ya du boulot. Il te faut un expert, ou quelques années pour monter en compétence.

[Folei]

Bonjour,

Tu as parfaitement compris.

C'est exactement ce que je craignais avec Photon (l'absence de serveur autoritaire). Je suis complètement en phase sur le fait que le client ne doit pas taper dans le SGBD.

Pour avoir vu la charge de travail que représente la création d'une communication client / serveur sur un autre jeu, expert ou non, je vais réfléchir à une alternative. J'ai étudié (rapidement) la solution du projet UMMORPG (https://www.assetstore.unity3d.com/en/#!/content/51212). Je vais essayer de gratter un peu.

Quoi qu'il en soit, merci à toi pour tes remarques pertinentes.

[NDrew]

je ne vois pas comment un serveur avec unity peut tenir la charge dans un univers massivement multijoueur. Sinon si tu test l'asset en question n'hésite pas à faire un retour sur le forum. Je suis bien curieux de connaître le nombre de user concurrent qu'un serveur comme ca peut tenir (comme les communications de uNet sont exponentiel en fonction du nombre de client)

Je continue de suivre ton sujet pour avoir des retours

[Folei]

En mon âme et conscience, je ne pense pas qu'Unity puisse faire le job en terme de "Serveur pur et dur".

Se pose alors quelques questions et surtout une : Sera t'il possible de faire communiquer un client "Unity" avec un serveur autoritaire indépendant ? Ça me promet quelques belles soirées de tests ! Je vous ferai un retour.

[Alesk]

Yop !

Tu devrais contacter le membre "menfou" pour lui demander quelques conseils.
Il semble bien calé sur la question client/serveur : viewtopic.php?f=12&t=12751

[Folei]

Top ! Merci beaucoup.

Je vais le contacter par MP.
Il faut également que je fasse un peu de fouilles sur les différents forums.

[NDrew]

Personnellement j'ai une architecture ou le serveur est composé de node exécutant des processus c# pure.
Ces processus communiquent entre eux, et avec les clients du jeu, par un/des serveurs smartfox, qui peuvent être sur la même machine ou déportés.
Les données peuvent également être divisé sur N base de données, encore une fois déportés si nécessaire.

En gros, mon univers persistant n'a aucune idée que le client utilise unity pour afficher.

Sur l'année que j'ai de mis sur le projet, je dirais que près de la moitié aura été consacré à la création du serveur.