Je pense surtout que ton erreur est de partir sur un RPG 3D !
Le reste, c'est du pipo, on pourra te dire qu'il faut tel programme/moteur/engine/sac à patates pour avancer, tu ne peux pas réaliser un RPG 3D sans un minimum (et encore) de bases et de connaissances, couplé à de l'expérience...

Je ne veux pas te démoraliser, mais le nombre de sujets qui passent en coup de vent dans le genre, on est jeune ET TRES motivé, on veut faire un super jeu (MMO, RPG 3D, FPS de la mort qui tue, etc...), ça part aux oubliettes bien vite...

La motivation ne te permet pas de réaliser des assets 3D, de programmer avec unity, ça c'est de l'apprendtissage et de l'expérience...
Etre scenariste, team manager, community manager ou autre "métier" d'à côté pas forcément nécessaire lorsqu'on débute la création d'un jeu ne va pas faire avancer la création de celui-ci...

Je ne peux que te conseiller d'apprendre toi même Unity, et/ou de partir sur un petit jeu et d'apprendre avec. Ce n'est pas une perte de temps bien au contraire, ce n'est que partie remise...

Si jamais vous souhaitez tout de même tenter la grande aventure, faites donc un tour du côté du store de Unity qui propose moult modèles, textures, aide à la création, asset, etc...
https://www.assetstore.unity3d.com/en/

Bon courage

Bonjour,
Peu importe le moteur, l'essentiel est de savoir ce que ton équipe est capable d'utiliser. Unity & UE sont souvent cité parce que gratuit et très accessible. Après je ne sais pas quel est l'objectif de votre équipe. Peut être devriez vous commencez par recruter un développeur plus compétent, ou revoir les objectifs de votre jeu à la baisse pour que votre dev débutant puisse apprendre.
Et comme l'a très bien suggéré Sam, apprenez à utiliser le moteur par vous même. Être plusieurs à travailler sur le code comme sur l'aspect visuel est toujours intéressant et surtout permet de se rendre compte que c'est très complexe de développer (même avec Unity).

Du coup pas vraiment de réponse à ta question si ce n'est que tu peux essayer les plus connus avec la plus grosse communauté et bien sur gratuit Vous pouvez aussi faire des petits prototypes ou des GameJam pour voir votre travail en équipe etc.

Voilà, partez sur Unity, et commencer à apprendre aussi, y'aura forcément un moment ou tu auras assez d'assets graphiques mais que la partie code suivra pas, donc il faudra mettre les mains dans le cambouis! Si c'est votre projet tu ne pourras pas juste attendre que le pauvre dev se sorte des ennuis alors que toi tu ne fais rien.
Et effectivement, visez bas, dans un premier temps, partez sur un proto, faite quelque chose de jouable, puis améliorez par la suite, sinon vous ne verrez jamais une version jouable et la démotivation va vite arriver.

Salut Alistya,

Alors l'essentiel à déjà été dit par Sam, Leifer et Alkounet. J'aimerai juste insister sur 2-3 trucs :

Votre jeu est de toute évidence bien trop ambitieux pour vos capacités ! Un RPG c'est beaucoup de boulot, rien qu'en 2D. Un jeu 3D c'est beaucoup de boulot, déjà même quand il ne s'agit pas d'un RPG.

Si vous voulez avoir une chance de mener votre projet à bien, écrémez drastiquement vos ambitions ! Partez déjà d'une unique idée que vous souhaitez porter en priorité, définissez la clairement : un scénario qui vous tiens à cœur ? un système de combat qui vous parait apporter quelque chose d'innovant et d'intéressant ? L'aspect gestion/survie d'un voyage de longue haleine ? La découverte libre d'un univers au background fouillé ?...
Bref, dans toutes les idées que vous avez, choisissez en une et une seule, sur laquelle vous allez vous concentrer. A partir de là construisez votre jeu, avec comme unique objectif de parvenir à quelque chose de jouable portant ce principe clé. Et là vous verrez bien comment les choses se passent : est-ce que vous arrivez sans soucis à construire un jeu solide et fonctionnel ? (qui n'attendra plus qu'à être étoffer éventuellement de nouvelles fonctionnalités) Ou arriverez-vous à vos fins avec pas mal de difficultés ? (auquel cas inutile de chercher à en augmenter l'ambition, mais peaufinez l’expérience pour que, aussi simple soit-elle, elle soit réussie)

La 3D est vraiment une difficulté énorme qui complexifie tout projet et n'apporte généralement pas grand chose aux fondements d'un bon jeu. Elle ne se justifie que si le gameplay y est intrinsèquement et indissociablement lié (p.ex. pour un FPS ou pour un simulateur de vol), et n'apporte sinon quelque chose que si on a les moyens de mettre en œuvre une 3D exemplaire (ce qui est énormément de travail, et demande de GROSSES compétences, très spécialisées). Mais il faut mille fois mieux une belle 2D sobrement animée qu'une 3D grossière aux animations rigides, aux collisions approximatives, à la physique mal contrôlée, etc. Et c'est mille fois plus simple (techniquement) à réaliser (artistiquement après, c'est une autre histoire ;)).

On se fourvoie souvent sur ce qui constitue la programmation. Apprendre à "programmer", c'est en fait assez simple. Les bases de l'informatique tiennent à pas grand chose (les formats de variable, l'indexation, ...) et apprendre un langage c'est comme apprendre une langue qui aurait 20 mots de vocabulaires, 5 règles de grammaire, aucun accord ou conjugaison, aucune exception. Basique.
Le vrai enjeu en revanche se trouve dans la construction algorithmique : comment transposer ce que vous avez en tête en un ensemble de règles logiques parfaitement claires et efficaces.
Il faut vraiment remonter à la base de la base, c'est à dire ne pas penser "quand j'appuie sur le bouton [gauche] le perso se déplace vers la gauche" mais p.ex. "quand on enfonce le bouton [gauche] la variable 'déplacement_sur_x' prends la valeur -1 ; quand on le relâche la variable 'déplacement_sur_x' prend la valeur 0" (ce qui définit le comportement que "tant que je laisse appuyé sur bouton, mon perso se déplace, quand je lâche le bouton il s'arrête", en imaginant qu'à chaque boucle élémentaire de ton jeu les valeurs des variables 'déplacement_sur_x' et 'déplacement_sur_y' se voient ajoutées aux coordonnées x et y du personnage ; à noter qu'un tel système simplifié donne des déplacements très basiques, sans accélération/décélération, et qu'il entraine comme classique limite qu'on se trouve à se déplacer plus vite en diagonal qu'en ligne droite ; mais ça reste un système qui peut être bien suffisant selon ce qu'on cherche à faire). De même une question classique qu'il faut se poser, c'est "comment je code mes niveaux/ma carte du monde ?". Pour un jeu en 2D en top-down, le plus simple est de partir sur un bête tableau de valeurs, ou chaque case représentera une fraction du monde (les classiques "tiles"). Mais est-ce qu'une valeur par case (faisant référence au sprite à afficher) est suffisant ? Souvent ce n’est pas le cas, car outre l'aspect graphique, il faut coder tout ce qui à trait à l’interactivité : la case est-elle franchissable ? (cela peut-être implicite, si on fait en sorte de faire correspondre chaque sprite à un caractère franchissable ou non, voire à une hitbox spécifique ; on peut aussi coder une valeur en plus par case, comme une "couche" en plus, dédiée à cela, p.ex. un bête "0" ou "1" pour "on peut passer" ou "non", l'intérêt de séparer le sprite de son comportement obstructif ou non étant une grande liberté de construction des niveaux, permettant notamment de réaliser des passages secrets comme des murs traversables, et puis cela peut aussi simplifier le travail du moteur de jeu, mais en revanche peut-être plus facilement source de bugs car il faudra toujours que les deux couches soient parfaitement coordonnées ; il faut aussi que tu aies une "couche" qui définisse les éléments actifs surajoutés : monstre, objet, évènements spéciaux,... ; et tu peux imaginer tout ce que tu veux selon tes besoins, p.ex. une couche "évènements spéciaux" différente de la couche "monstre et objet" (conseillé en fat!), sinon un ennemi qui se déplace ne pourrait pas se superposer à une case contenant un évènement, car évoluant sur la même couche : le risque serait dés lors qu'il supprime purement et simplement le déclenchement d'un script en passant sur cette case :P). Bref, le plus gros enjeu de la partie "programmation" se situe sur ce genre de considérations, qui ne relève pas forcément de connaissances techniques particulières, mais de bon sens et d'une bonne capacité à rationaliser les problématiques. Au final, coder revient (grossièrement ;)) à traduire les algorithmes dans le bon langage, ce qui reste en soit assez trivial (enfin, grossièrement ;)).
A mon sens, le gros du travail se fait en amont, avec papier et crayon, et tout le monde peut y travailler, et doit en tout cas être impliqué dans le processus : un game-designer ne peut pas décréter vouloir implémenter telle ou telle fonctionnalité s'il ne comprend pas ce que cela implique derrière, et idéalement s'il n'est pas à même de proposer une ébauche d'algorithme qui réponde à ce qu'il a en tête ; un graphiste ne peut pas réaliser de sprites s'il ne comprend pas les tenant et aboutissants de leurs intégrations au moteur de jeu (comment sont gérés les animations ? les hitbox ? la luminosité ? etc.) ; un scénariste ne peut pas décider d'une trame narrative ou de dialogues s'il n'a pas une bonne compréhension de la façon dont est gérée la progression ou comment fonctionne le moteur de conversations.

Pensez à rédiger avant toute chose un "game design document", c'est à dire un document qui précise de façon très concrète tous les mécanismes que vous comptez intégrer à votre jeu : interface, contrôles et déplacements, quelles données doit contenir la carte, quelles sont et comment se déroulent les interactions, quelles sont les caractéristiques des ennemis et du personnages (stats), comment fonctionnent les combats (et du coup les règles et calculs qui y sont rattachés), quel mode d'évolution du personnage, scénario, univers, etc., etc. Cette étape, c'est une des plus importante, elle doit impliquer tout le monde, et ne nécessite rien d'autre que crayon, papier et des neurones bien éveillés. (je dis "crayon/papier, mais naturellement les choses seront formalisées au propre dans un document texte :P)
NB : à noter qu'à ce stade, on n'est pas encore dans l'algorithmie, même si elle découlera ensuite de là ; on définit de façon explicite toutes les règles et mécaniques ; et on les définit clairement et en détail, il ne s'agit PAS d'une liste de "bonnes intentions" (du genre "jeu type monde ouvert"), c’est du concret ("le monde est divisé en x zones de x sur x cases ; chaque case correspondant grossièrement à une dimension de 1m sur 1m ; les zones correspondent respectivement aux régions de ...., .... et .... et au monde des ténèbres (voir scénario), elles possèdent chacune certaines caractéristiques propres et sont détaillées plus loin ; outre ces grandes zones, le jeu possède des donjons surajoutés codés sur de plus petites zones de x sur x cases et les intérieurs de bâtiments codés sur de toutes petites zones de x sur x cases (les grands intérieurs complexes correspondant à des donjons) ; ...).

Pour ce qui est du moteur de jeu, Unity est très bien, même pour la 2D, mais impose de coder beaucoup de choses (ce qui en soit n'est pas forcément un mal en fait) ; d'autres existent qui offrent plus de facilités pour débuter, mais aussi plus de limites si vous avez des idées déjà très précises ou qui sortent des sentiers battus.

Nous savons ce que nous faisons, je voulais être juste sûre de mon choix d'engine. Le reste, on gère.

Je vous le souhaite, mais vue la teneur de tes postes, ça parait pas très clair (rien que venir ici poser la question du moteur, pour quelqu'un "qui gère", ça me parait un peu bizarre : si tu as bien compris les enjeux que représente le développement d'un jeu, comment ne pas trouver toi-même la réponse en regardant, sur leurs sites dédiés, ce que chaque moteur propose?)

Et les croquis, la carte (si c'est juste la dessiner, et pas la formaliser dans un format adapté à son exploitation par le moteur de jeu), le scénario, le background, ... c'est juste une base qui guidera la réalisation du contenu, mais rien qui ait trait à la concrétisation technique de votre jeu.

Enfin, bon courage.

En espérant qu'on ait des nouvelles de votre jeu au fur et à mesure qu'il prendra forme.

Tes réponses me paraissent immatures et me font demander quel âge tu as ?
Toute personne sensée et réfléchi accepte les remarques qui le font avancer... Ce n'est pas ton cas, et si tu es si sûr de toi, tu n'as qu'a nous montrer tes avancés au fur et à mesure, mais lorsque tu réaliseras que tu ne pourras pas faire le jeu de tes rêves, ne viens pas pleurer en cherchant du réconfort...

Des messages comme le tien, y en a des tas tout les jours sur les forums de ce genre, et TOUS ces "studios" ou jeunes ultra mega giga hypra motivés, mais qui n'ont pas beaucoup de réelles connaissances, abandonnent leur projet du jour au lendemain...

Maintenant, quand tu auras assimilé ceci, alors tu avanceras...