Bonjour à tous et bienvenue au(x) nouveau(x),

Question super intéressante et qui à mon avis dépasse le simple fait des connaissances techniques... donc je vais me lancer dans un sujet que j'adore, la gestion. Bon je vous rassure je ne vais pas faire une longue tartine

Je reprendrai le post de tmyke qui je pense a fort bien résumé l'idée (comme d'habitude d'ailleurs), en y ajoutant que gérer un jeu c'est comme gérer sa liste de courses (j'aime bien cette comparaison: ben oui, en général tu prends les surgelés en dernier, et les trucs lourds style bouteilles en premier pour ne pas écraser les oeufs ou les fraises qui finissent au-dessus). Un jeu c'est pareil: crée un planning "technique" (et automatiquement temporel) en fonction de ce que tu penses faire comme jeu et ordonne les éléments dont tu as besoin (BSP, terrain, mouvement de camera, collisions, meshes mobiles, etc.). Cela te permettra de voir à quelle partie du moteur tu dois t'attaquer en premier et donc d'apprendre "dans l'ordre".

Tu verras qu'en faisant un plan les choses vont s'organiser, et au fur et à mesure que tu attaqueras un point du plan, tu trouveras d'autres éléments à y ajouter. Chaque élément sera d'abord vague (exemple: terrain) puis de là tu partiras en sous-catégories (heightmaps ou mesh? blending? alpha? textures géantes ou petites? et les connaissances pour savoir les générer et les utiliser) et tout cela appelera à t'intéresser à un domaine ou l'autre. Déjà rien que comme ça tu avanceras très vite, de manière itérative (c'est le schéma de développement du moteur), et tu auras l'impression d'avancer (et pas de stagner au milieu de nulle part avec des connaissances un peu partout mais sans moyen de tout lier au final).

Technique payante: le graphe technique. Quel que soit le chemin que tu prends un moment, même si cela ne te mène pas ou tu veux (ou ne te mène nulle part), note-le (une description en quelques mots suffit). Ensuite, incorpore-le dans un graphe et lie-le à ses parents (dépendances) et ses enfants (débouchés). Enfin, quand ton graphe aura plusieurs éléments interconnectés, tires-en dehors un plusieurs arbres: chaque arbre te mènera d'un élément racine vers un type d'aboutissement qui saura te convenir au moment X ou Y. D'ailleurs, tu parles de développer des modules: c'est une excellente chose (d'abord pour la réusabilité), mais aussi parce que cela rentre parfaitement dans le concept de graphe/arbre technique. Et quand tu seras bien rôdé, chaque élément de ton graphe ou de tes arbres sera un module que tu auras développé. Et le grand plaisir de pouvoir tout interconnecter aisément viendra alors. A noter que le graphe indique le type d'élément à utiliser (dépendances), pour ce qui est du besoin technique (exemple: j'ai besoin d'un truc qui fasse ceci ou cela) c'est du ressort du code design (voir après).

L'architecture est un autre nom du graphe, mais parfois le niveau de design est aléatoire en fonction de la personne à laquelle cela s'adresse. Aussi faire du "code design" au fur et à mesure: voir tout ce dont tu as besoin en termes de technologies avant de commencer (exemple: tu veux retenir des positions d'éléments? utilise du XML. Oui mais pour ça il faut un parser. Et un validateur - c'est toujours plus sûr, histoire que la sémantique et la syntaxique ne fassent pas exploser ton moteur. Donc tu auras besoin d'une lib XML avec parser et validateur - mais tu noteras que le graphe technique dira simplement pour ce point: charger coordonnées de l'objet depuis XML).

Enfin voilà, je te souhaite bonne chance, en espérant que ces quelques conseils (peut-être un peu éloignés de ta question initiale) pourront servir.

valholl

PS: et m**** j'ai encore fait une tartine...