GDquest, c'est assez étrange en te lisant mine de rien, de voir qu'en fait tu donne l'impression de ne pas aimer du tout Contruct 2 , et ca devient un peu lassant de suivre cette conversation Joyeux
Du tout, je donne uniquement mon avis de sorte à participer à la discussion. À aucun moment j'ai conseillé aux participants ici de ne pas utiliser Construct 2 - il me semble. EDIT: en fait l'idée, c'était juste de dire que la programmation événementielle ou le code sont tous deux de la programmation. Ce n'est pas un jugement de valeur.
A partir du moment que tu utilise un des soft ou moteur sus cité , tu es dans ce cas la.
À partir du moment où l'on utilise un moteur, on travaille de façon scolaire, sans persévérer, sans se poser de questions? As-tu pris mes propos pour une insulte à l'égard des autres membres? Le on c'est indéfini, et oui cela m'inclue. Dans tous les cas pas de soucis, si mes réponses ennuient je m'arrête ici.
Je suis tout à fait d'accord avec toi Anata pour les deux points que tu as évoqué :
C'est comme toute chose, on ne peut faire quelque chose de correct sans en apprendre le fonctionnement. On ne peut dire de vouloir faire un type de jeu sans se pencher sur la question de faisabilité avec tel ou tel soft, ou tel langage de programmation.
et
Pour finir, il ne faut jamais chercher a voir trop gros des le départ, voir petit est beaucoup plus gratifiant et instructif , que de vouloir partir sur un gros projet sans rien connaitre des outils.
Si je me souviens bien, le jeu "the next penelope" est réalisé avec Construct ? http://www.the-next-penelope.com
Il y avait même eu un tutoriel d'initiation sur le site du développeur ?
De façon évidente, les logiciels à utiliser dépendent d'énormément de facteurs qu'il faut se fixer avant de démarrer son projet de jeu, tels que la taille et l'ambition du dit jeu, la taille de l'équipe, les compétences disponibles et celles à acquérir ainsi qu'évidemment les délais disponibles, la volonté de portages, la flexibilité ou encore l'objectif de ce jeu (apprendre à faire du code, apprendre à faire du game design, s'amuser, objectif pro à long terme...).
Ce qu'essaye de dire Nathan, il me semble, c'est que si Construct 2 permet en effet de démarrer sur des projets relativement modestes, de petite ou moyenne taille, il ne correspond pas à certaines configurations de projets : par exemple le travail de deux développeurs. Ainsi, quelqu'un se spécialisant dans Construct 2 arrivera à faire des choses de mieux en mieux avec le temps, mais il risquera de se heurter avec le temps à une incapacité à faire des projets plus ambitieux à partir d'un certain stade (jeu 3D, jeu plus gros, plus de membres dans l'équipe...).
Si Construct 2 est plus abordable et fera "moins peur" au néophyte, il faut néanmoins se demander jusqu'où on voudra aller dans son apprentissage car à temps égal d'apprentissage et avec la volonté d'aller plus loin, il est probable que mieux connaître un moteur plutôt que Construct 2 permettra une plus grande flexibilité, là où Construct 2 permet au contraire de réaliser de modestes projets rapidement avec des résultats visibles immédiats.
En gros, les moteurs sont plus durs à utiliser sans connaissance et mettent du temps à fournir quelque chose, mais ils permettent d'aller très loin lorsqu'on les maîtrise, là où Construct 2 permet de faire beaucoup de choses rapidement mais aura quelques limites si on finit par vouloir faire de gros projets ou qu'on a un objectif professionnel (chercher du boulot en tant que connaisseur Unity ou Unreal Engine sera plus vendeur).
Encore une fois, chaque type de projet a des outils adaptés. Si c'est un jeu pour découvrir un peu le domaine de la création sans connaissances en code et faire un petit jeu (très) modeste, Construct est très bien.
Et arrêtez de vous prendre le choux sur cette éternelle bataille de clocher.
N'oubliez jamais ceci: "Qu'importe le flacon, pourvu que l'on ai l'ivresse"!
*Faites des jeux, pas la guerre. Ou alors des jeux de guerre.*
Merci Seldell, c'était effectivement l'idée. Pour la petite histoire, j'ai ma licence C2, j'ai fait des tutoriels et j'aide encore des membres de la communauté - d'ailleurs c'est l'outil que je conseille le plus souvent aux hobbyistes, mais aussi aux étudiants en game design par exemple. La discussion est centrée sur C2 parce que c'est le moteur qui a été pris en exemple au départ, mais on peut discuter autour de n'importe quel outil.
Soit dit en passant, j'ai commencé avec RPG maker XP, puis j'ai utilisé Multimedia Fusion, qui m'a permis de rencontrer mon ancien associé. Associé que j'ai ensuite tanné pendant des mois pour que l'on passe sur construct 2, qui est une référence aujourd'hui dans sa catégorie. Ce sont des outils que j'aime beaucoup! Et j'utilise toujours C2 pour la création de prototypes.
Faites votre chemin comme vous le sentez! Ce qui compte, c'est avant tout de prendre du plaisir en apprenant. Exactement comme le dit papi Kami:
N'oubliez jamais ceci: "Qu'importe le flacon, pourvu que l'on ai l'ivresse"! Joyeux
D'ailleurs Kami, tu participes à la LD ce week-end?
Dans tous les cas pas de soucis, si mes réponses ennuient je m'arrête ici.
Mais non, mais non, tu n'ennuies personne !
D'ailleurs, si tu avais envie de critiquer Construct 2, qui t'empêche de le faire ? C'est libre ici
Sinon, bien sûr, comme le dit Seldell, apprendre un langage, c'est quand même généralement mieux. Un langage permet de faire ce que tu souhaites. De plus, tu peux l'utiliser dans bon nombre de logiciels, librairies, etc. Alors que le VS de Construct, tu l'utilises que dans Construct.
Si on veut pouvoir faire tout ce qu'on veut, il faut quasi-tout le temps passer par un langage de programmation.
Tu le résumes très bien :
Si Construct 2 est plus abordable et fera "moins peur" au néophyte, il faut néanmoins se demander jusqu'où on voudra aller dans son apprentissage car à temps égal d'apprentissage et avec la volonté d'aller plus loin, il est probable que mieux connaître un moteur plutôt que Construct 2 permettra une plus grande flexibilité, là où Construct 2 permet au contraire de réaliser de modestes projets rapidement avec des résultats visibles immédiats.
Mais non on ne parlait pas de ce qu'une façon de faire permet par rapport à une autre, mais plutôt de l'apprentissage. Ce que tu dis ici :
En gros, les moteurs sont plus durs à utiliser sans connaissance et mettent du temps à fournir quelque chose
est totalement vrai, et c'est CA le problème ! Plus les résultats arrivent lentement, plus on peut se décourager.
Bien sûr, pour certaines personnes, ça ne pose aucun problème de persévérer, mais ce n'est pas le cas de tout le monde. Moi par exemple, j'ai essayé, et j'ai rapidement abandonné. Heureusement, l'année prochaine, je vais apprendre le python en cours, et donc avec un professeur. Et à partir du moment où je connais les bases d'un langage, ce n'est pas difficile d'apprendre celles d'un autre.
Et enfin, pour mettre fin à ce qu'on dit tous :
Oui, il faut commencer par des petits projets, et non pas des gros. Je pense que tout le monde est d'accord avec ça, dans ce topic c'est le cas.
Et merci Kami pour ta citation, ça résume plutôt bien
Je rajouterais que nombre de jeux sont fait sans moteur en utilisant des framework. Les moteurs de jeux sont roi dans la 3D quand refaire un moteur 3D demande une tonne de connaissance.
j'espère avoir quelques réponses et voir avec ces personnes ce que l'on pourra viser en fonction des compétences de chacun
J'ai tendance à penser qu'il est illusoire de vouloir mener à bien un projet si on ne sait même pas au tout départ, avec un minimum de clarté, quel projet on veut concrètement mener... Et je ne parle pas de réunir une équipe, ce qui demande de fédérer, autour d'un projet justement, enfin à mon sens en tout cas.
Un jeu-vidéo est un processus complexe (pas forcément compliqué en revanche! mais forcément complexe), où un ensemble d'éléments distincts (affichage, controles, gamedesign, graphismes, scénario...) se retrouvent en interactions permanentes dans le résultat final, chacun de ces éléments et interactions étant "simple" pris indépendamment, mais le tout étant complexe pris dans son ensemble. Arriver à un résultat satisfaisant requiert je pense d'avoir une vision très structurée de la façon dont tout cela s'articule. Ce qui revient à ce que disait The_Icehouse sur l'importance que chaque membre de l'équipe ait des connaissances qui débordent de son simple domaine de compétences. Même si on ne lui demandera pas en pratique, sur le projet, de faire autre chose que ce pour quoi il est là, il ne pourra le faire de façon adapté que s'il a une bonne compréhension de la façon dont son travaille sera implémenté au sein du projet final.
(on pourrait faire un parallèle avec un designer automobile: il ne suffit pas de savoir "dessiner de belles carrosseries", il faut avoir de solides connaissances en mécanique auto, en aérodynamisme, en ergonomie... parce qu'au final, la carrosserie, elle devra contenir tout un tas d'éléments dont l'agencement sera déterminé par d'autres contraintes que celles de l'esthétisme, permettre un écoulement de l'air pertinent par rapport à ce qu'on attend du modèle, ou encore permettre aux conducteur et passagers une vie à bord la plus agréable possible)
Et au final, cette complexité, qu'il est donc à mon avis bon de comprendre et appréhender d'autant qu'on a des idées ambitieuses et/ou spécifiques, est en partie gommée par les "facilités" qu'offrent des logiciels comme Construct 2, et à l'inverse, on se la prend de plein fouet si on décide de coder de toute pièce son moteur de jeu.
Pour autant, l'avantage à mon avis indéniable de "faire l'effort" d'apprendre à coder un minimum, c'est que le code impose de structurer sa pensée, en adéquation avec les enjeux que représentent la conception d'un jeu-vidéo. Vouloir passer outre cet "effort", c'est au final concéder avoir des lacunes dans la compréhension des enjeux sous-jacents, et donc se trouver beaucoup plus facilement "bloqué" à un moment de la conception, parce qu'on ne sait p.ex. pas comment implémenter concrètement telle idée, ou résoudre tel problème.
Il y a donc évidemment un équilibre à trouver, entre facilité de mise en oeuvre et contrôle du processus. Un meilleur contrôle ayant quand même comme avantage indéniable une plus grande probabilité d'arriver à ses fins.
@Avorpal
J'ai une énorme envie de me lancer dans un projet un jour mais à vrai dire, je ne veux pas avoir à apprendre du code ou à prendre des cours de dessin pour faire un jeu. Moi ce qui me motive, c'est de concrétiser un scénario, de donner vie à un univers créé à partir du papier. Et pour cela, je ne voudrais pas être "parasité" dans le travail que je pourrais accomplir par des obligations techniques.
Bah malheureusement, si on a envie de mener a bien un projet, il faut se donner les moyens de ses ambitions. Créer un jeu-vidéo ça demande autre chose que la capacité à faire vivre une histoire sur le papier. Pour ça, il y a l'écriture justement . Si tu veux passer à un niveau supérieur en y intégrant de l'interaction, tu ne pourras pas à mon avis te passer des connaissances techniques que cela sous entend. Je pourrai caricaturer en "j'aimerai mette en image ce que j'ai en tête, mais sans avoir à apprendre à dessiner ou peindre, sans être parasité par les considérations techniques que cela représente" ...bah c'est juste pas possible...
Je pourrai reprendre aussi l'exemple du designer auto: "mon rêve serait de dessiner des voitures pour un grand constructeur, mais je n'ai pas envie de devoir apprendre le fonctionnement mécanique qu'il y a derrière, d'être parasité par des considérations techniques"... bah là encore, c'est pas possible...
Je pourrai reprendre aussi l'exemple du designer auto: "mon rêve serait de dessiner des voitures pour un grand constructeur, mais je n'ai pas envie de devoir apprendre le fonctionnement mécanique qu'il y a derrière, d'être parasité par des considérations techniques"... bah là encore, c'est pas possible...
Oui et non. La différence dans un jeu, c'est que même si la carrosserie de la voiture est imparfaite, elle marchera quand même, puisque ce n'est pas mécanique, mais plutôt des animations.
Bien sûr tu ne cites qu'un exemple, et tu n'as pas vraiment tort en disant qu'il est impossible de mettre une image ce qu'on imagine sans dessiner.
Pas vraiment, parce qu'il est toujours possible de décrire ses idées au graphiste, qui les interprétera à sa façon, mais en gardant le concept initial. Après, bien sûr, ça dépend de ce que tu as en tête. Si tu imagines un lieu par exemple, avec des arbres au pied d'une falaise, séparés par une cascade, il suffit de décrire un petit peu. En revanche, si tu imagines que tes arbres forment une certaine courbe, ou des détails bien plus précis, c'est évidemment plus complexe. C'est toujours faisable, mais ça demandera beaucoup de temps.
Sinon, je suis d'accord avec The_Icehouse, sur le fait qu'il faut "toucher un peu partout". Je pense que ce n'est toujours pas forcément nécessaire, mais en tout cas beaucoup plus productif et plus rapide.
Avorpal, ce que je peux te conseiller de faire, c'est d'écrire un GDD (Game Design Document), si tu as déjà une idée en tête. Avec un GDD bien complet, tu peux probablement trouver des gens, pour peu qu'ils soient intéressés par ton jeu.
Et même si ton GDD ne te sert pas pour l'instant, il peut te permettre de garder ton jeu, et, qui sait, le retrouver plus tard, quand tu auras une équipe avec toi.
Si tu ne sais pas ce que c'est, c'est grosso modo un fichier (pdf, word) dans lequel tu "décris" ton jeu. Tu y écris tout ce qui te passe par la tête, que ce soit dans le style de musique que tu imagines avec telle scène ou une spécificité de gameplay.
Tu y rajoutes des éléments, plus ou moins précis (par exemple tu dis que ce mur de ce niveau sera gris, pour permettre telle chose), et petit à petit, ça va former un jeu, qui sera plus ou moins détaillé.
Bien sûr, dedans, tu parles aussi de ton histoire, de l'histoire de l'univers, tu présentes tes personnages, etc.
Tu peux te faire une idée de ce qu'est un GDD en en cherchant sur internet (la plupart sont en anglais).
Du tout, je donne uniquement mon avis de sorte à participer à la discussion. À aucun moment j'ai conseillé aux participants ici de ne pas utiliser Construct 2 - il me semble. EDIT: en fait l'idée, c'était juste de dire que la programmation événementielle ou le code sont tous deux de la programmation. Ce n'est pas un jugement de valeur.
À partir du moment où l'on utilise un moteur, on travaille de façon scolaire, sans persévérer, sans se poser de questions? As-tu pris mes propos pour une insulte à l'égard des autres membres? Le on c'est indéfini, et oui cela m'inclue. Dans tous les cas pas de soucis, si mes réponses ennuient je m'arrête ici.
Je suis tout à fait d'accord avec toi Anata pour les deux points que tu as évoqué :
et
Si je me souviens bien, le jeu "the next penelope" est réalisé avec Construct ? http://www.the-next-penelope.com
Il y avait même eu un tutoriel d'initiation sur le site du développeur ?
De façon évidente, les logiciels à utiliser dépendent d'énormément de facteurs qu'il faut se fixer avant de démarrer son projet de jeu, tels que la taille et l'ambition du dit jeu, la taille de l'équipe, les compétences disponibles et celles à acquérir ainsi qu'évidemment les délais disponibles, la volonté de portages, la flexibilité ou encore l'objectif de ce jeu (apprendre à faire du code, apprendre à faire du game design, s'amuser, objectif pro à long terme...).
Ce qu'essaye de dire Nathan, il me semble, c'est que si Construct 2 permet en effet de démarrer sur des projets relativement modestes, de petite ou moyenne taille, il ne correspond pas à certaines configurations de projets : par exemple le travail de deux développeurs. Ainsi, quelqu'un se spécialisant dans Construct 2 arrivera à faire des choses de mieux en mieux avec le temps, mais il risquera de se heurter avec le temps à une incapacité à faire des projets plus ambitieux à partir d'un certain stade (jeu 3D, jeu plus gros, plus de membres dans l'équipe...).
Si Construct 2 est plus abordable et fera "moins peur" au néophyte, il faut néanmoins se demander jusqu'où on voudra aller dans son apprentissage car à temps égal d'apprentissage et avec la volonté d'aller plus loin, il est probable que mieux connaître un moteur plutôt que Construct 2 permettra une plus grande flexibilité, là où Construct 2 permet au contraire de réaliser de modestes projets rapidement avec des résultats visibles immédiats.
En gros, les moteurs sont plus durs à utiliser sans connaissance et mettent du temps à fournir quelque chose, mais ils permettent d'aller très loin lorsqu'on les maîtrise, là où Construct 2 permet de faire beaucoup de choses rapidement mais aura quelques limites si on finit par vouloir faire de gros projets ou qu'on a un objectif professionnel (chercher du boulot en tant que connaisseur Unity ou Unreal Engine sera plus vendeur).
Encore une fois, chaque type de projet a des outils adaptés. Si c'est un jeu pour découvrir un peu le domaine de la création sans connaissances en code et faire un petit jeu (très) modeste, Construct est très bien.
Trop de stress pour un si petit renard.
+1 Seldell
@GDquest <3
Et arrêtez de vous prendre le choux sur cette éternelle bataille de clocher.
N'oubliez jamais ceci: "Qu'importe le flacon, pourvu que l'on ai l'ivresse"!
*Faites des jeux, pas la guerre. Ou alors des jeux de guerre.*
Merci Seldell, c'était effectivement l'idée. Pour la petite histoire, j'ai ma licence C2, j'ai fait des tutoriels et j'aide encore des membres de la communauté - d'ailleurs c'est l'outil que je conseille le plus souvent aux hobbyistes, mais aussi aux étudiants en game design par exemple. La discussion est centrée sur C2 parce que c'est le moteur qui a été pris en exemple au départ, mais on peut discuter autour de n'importe quel outil.
Soit dit en passant, j'ai commencé avec RPG maker XP, puis j'ai utilisé Multimedia Fusion, qui m'a permis de rencontrer mon ancien associé. Associé que j'ai ensuite tanné pendant des mois pour que l'on passe sur construct 2, qui est une référence aujourd'hui dans sa catégorie. Ce sont des outils que j'aime beaucoup! Et j'utilise toujours C2 pour la création de prototypes.
Faites votre chemin comme vous le sentez! Ce qui compte, c'est avant tout de prendre du plaisir en apprenant. Exactement comme le dit papi Kami:
D'ailleurs Kami, tu participes à la LD ce week-end?
Mais non, mais non, tu n'ennuies personne !
D'ailleurs, si tu avais envie de critiquer Construct 2, qui t'empêche de le faire ? C'est libre ici
Sinon, bien sûr, comme le dit Seldell, apprendre un langage, c'est quand même généralement mieux. Un langage permet de faire ce que tu souhaites. De plus, tu peux l'utiliser dans bon nombre de logiciels, librairies, etc. Alors que le VS de Construct, tu l'utilises que dans Construct.
Si on veut pouvoir faire tout ce qu'on veut, il faut quasi-tout le temps passer par un langage de programmation.
Tu le résumes très bien :
Mais non on ne parlait pas de ce qu'une façon de faire permet par rapport à une autre, mais plutôt de l'apprentissage. Ce que tu dis ici :
est totalement vrai, et c'est CA le problème ! Plus les résultats arrivent lentement, plus on peut se décourager.
Bien sûr, pour certaines personnes, ça ne pose aucun problème de persévérer, mais ce n'est pas le cas de tout le monde. Moi par exemple, j'ai essayé, et j'ai rapidement abandonné. Heureusement, l'année prochaine, je vais apprendre le python en cours, et donc avec un professeur. Et à partir du moment où je connais les bases d'un langage, ce n'est pas difficile d'apprendre celles d'un autre.
Et enfin, pour mettre fin à ce qu'on dit tous :
Oui, il faut commencer par des petits projets, et non pas des gros. Je pense que tout le monde est d'accord avec ça, dans ce topic c'est le cas.
Et merci Kami pour ta citation, ça résume plutôt bien
Je rajouterais que nombre de jeux sont fait sans moteur en utilisant des framework. Les moteurs de jeux sont roi dans la 3D quand refaire un moteur 3D demande une tonne de connaissance.
@GDquest Non je ne participerais pas à la LD ce week end. Il me faut plus de temps pour pondre un truc (et pour dormir). Je me fais vieux.
@TeBow2160
J'ai tendance à penser qu'il est illusoire de vouloir mener à bien un projet si on ne sait même pas au tout départ, avec un minimum de clarté, quel projet on veut concrètement mener... Et je ne parle pas de réunir une équipe, ce qui demande de fédérer, autour d'un projet justement, enfin à mon sens en tout cas.
Un jeu-vidéo est un processus complexe (pas forcément compliqué en revanche! mais forcément complexe), où un ensemble d'éléments distincts (affichage, controles, gamedesign, graphismes, scénario...) se retrouvent en interactions permanentes dans le résultat final, chacun de ces éléments et interactions étant "simple" pris indépendamment, mais le tout étant complexe pris dans son ensemble. Arriver à un résultat satisfaisant requiert je pense d'avoir une vision très structurée de la façon dont tout cela s'articule. Ce qui revient à ce que disait The_Icehouse sur l'importance que chaque membre de l'équipe ait des connaissances qui débordent de son simple domaine de compétences. Même si on ne lui demandera pas en pratique, sur le projet, de faire autre chose que ce pour quoi il est là, il ne pourra le faire de façon adapté que s'il a une bonne compréhension de la façon dont son travaille sera implémenté au sein du projet final.
(on pourrait faire un parallèle avec un designer automobile: il ne suffit pas de savoir "dessiner de belles carrosseries", il faut avoir de solides connaissances en mécanique auto, en aérodynamisme, en ergonomie... parce qu'au final, la carrosserie, elle devra contenir tout un tas d'éléments dont l'agencement sera déterminé par d'autres contraintes que celles de l'esthétisme, permettre un écoulement de l'air pertinent par rapport à ce qu'on attend du modèle, ou encore permettre aux conducteur et passagers une vie à bord la plus agréable possible)
Et au final, cette complexité, qu'il est donc à mon avis bon de comprendre et appréhender d'autant qu'on a des idées ambitieuses et/ou spécifiques, est en partie gommée par les "facilités" qu'offrent des logiciels comme Construct 2, et à l'inverse, on se la prend de plein fouet si on décide de coder de toute pièce son moteur de jeu.
Pour autant, l'avantage à mon avis indéniable de "faire l'effort" d'apprendre à coder un minimum, c'est que le code impose de structurer sa pensée, en adéquation avec les enjeux que représentent la conception d'un jeu-vidéo. Vouloir passer outre cet "effort", c'est au final concéder avoir des lacunes dans la compréhension des enjeux sous-jacents, et donc se trouver beaucoup plus facilement "bloqué" à un moment de la conception, parce qu'on ne sait p.ex. pas comment implémenter concrètement telle idée, ou résoudre tel problème.
Il y a donc évidemment un équilibre à trouver, entre facilité de mise en oeuvre et contrôle du processus. Un meilleur contrôle ayant quand même comme avantage indéniable une plus grande probabilité d'arriver à ses fins.
@Avorpal
Bah malheureusement, si on a envie de mener a bien un projet, il faut se donner les moyens de ses ambitions. Créer un jeu-vidéo ça demande autre chose que la capacité à faire vivre une histoire sur le papier. Pour ça, il y a l'écriture justement
. Si tu veux passer à un niveau supérieur en y intégrant de l'interaction, tu ne pourras pas à mon avis te passer des connaissances techniques que cela sous entend. Je pourrai caricaturer en "j'aimerai mette en image ce que j'ai en tête, mais sans avoir à apprendre à dessiner ou peindre, sans être parasité par les considérations techniques que cela représente" ...bah c'est juste pas possible...
Je pourrai reprendre aussi l'exemple du designer auto: "mon rêve serait de dessiner des voitures pour un grand constructeur, mais je n'ai pas envie de devoir apprendre le fonctionnement mécanique qu'il y a derrière, d'être parasité par des considérations techniques"... bah là encore, c'est pas possible...
Oui et non. La différence dans un jeu, c'est que même si la carrosserie de la voiture est imparfaite, elle marchera quand même, puisque ce n'est pas mécanique, mais plutôt des animations.
Bien sûr tu ne cites qu'un exemple, et tu n'as pas vraiment tort en disant qu'il est impossible de mettre une image ce qu'on imagine sans dessiner.
Pas vraiment, parce qu'il est toujours possible de décrire ses idées au graphiste, qui les interprétera à sa façon, mais en gardant le concept initial. Après, bien sûr, ça dépend de ce que tu as en tête. Si tu imagines un lieu par exemple, avec des arbres au pied d'une falaise, séparés par une cascade, il suffit de décrire un petit peu. En revanche, si tu imagines que tes arbres forment une certaine courbe, ou des détails bien plus précis, c'est évidemment plus complexe. C'est toujours faisable, mais ça demandera beaucoup de temps.
Sinon, je suis d'accord avec The_Icehouse, sur le fait qu'il faut "toucher un peu partout". Je pense que ce n'est toujours pas forcément nécessaire, mais en tout cas beaucoup plus productif et plus rapide.
Avorpal, ce que je peux te conseiller de faire, c'est d'écrire un GDD (Game Design Document), si tu as déjà une idée en tête. Avec un GDD bien complet, tu peux probablement trouver des gens, pour peu qu'ils soient intéressés par ton jeu.
Et même si ton GDD ne te sert pas pour l'instant, il peut te permettre de garder ton jeu, et, qui sait, le retrouver plus tard, quand tu auras une équipe avec toi.
Si tu ne sais pas ce que c'est, c'est grosso modo un fichier (pdf, word) dans lequel tu "décris" ton jeu. Tu y écris tout ce qui te passe par la tête, que ce soit dans le style de musique que tu imagines avec telle scène ou une spécificité de gameplay.
Tu y rajoutes des éléments, plus ou moins précis (par exemple tu dis que ce mur de ce niveau sera gris, pour permettre telle chose), et petit à petit, ça va former un jeu, qui sera plus ou moins détaillé.
Bien sûr, dedans, tu parles aussi de ton histoire, de l'histoire de l'univers, tu présentes tes personnages, etc.
Tu peux te faire une idée de ce qu'est un GDD en en cherchant sur internet (la plupart sont en anglais).
Pages