Tout d'abord bonjour tout le monde! ça fait pas mal de temps que je traine sur votre forum et la communauté à l'air bien sympathique en tout cas!

Une bref présentation ne fait pas de mal je pense et permettra a chacun d'entre vous de bien voir qui je suis 'réellement'

    Je suis un jeune étudiant de 20 ans en BTS informatique et réseaux dans l'industrie et les services (IRIS) et donc ma grande passion est la programmation. Cette passion est apparu à l'âge de 6ans quand j'ai un mon 1er ordinateur 'portable' (ordinateur pour enfant je vous rassure ) qui me permettait de créer de minuscule programme en 'basic'. Ensuite je me suis mis a l'informatique plus généralement (quoi que je ne suis jamais sorti du domaine de Windows.. donc jamais touché a Mac OS X ou a Linux..) donc software et hardware.

    Donc la ça fait pas mal de temps que je programme en C++.. On va dire que je m'y suis réellement mis depuis Septembre 2008 (j'avais auparavant fait des petits programmes mais par manque de temps j'avais pas pu m'initier sérieusement à la programmation)
    J'ai des connaissances correctes en matière de xHTML/CSS, bibliothèques Qt(fenetre/graphique 2d) et FMOD(son), et des connaissances moyennes en matière de C++ et je débute depuis 5 jours à Irrlicht..

-> Sur Irrlicht j'ai fais des petits programmes permettant d'afficher une croix a l'écran, d'implanter un mesh et l'attacher à la caméra (avec la notion parent/enfant), de créer une détection de Collision, de gérer le Bump Mapping (pas avec shader mais en m'inspirant de l'exemple 11), de changer le skin du curseur par défaut (le pointeur blanc de windows étant assez HORRIBLE).. bref des petites programmes basiques, sans parlé bien entendu des petites scène comment ça pour rigoler. J'ai bien compris la notion de SceneManager / Octree / arbre binaire

->J'ai déjà fait des 'MOD' et Map pour UT2004 donc touché au langage de script assez similaire a mon gout au C++ d'ailleurs pour ce qui est du langage de script de UT2004.

->J'ai des connaissances moyennes en matière de modélisation 3D, j'utilise 3ds Max 6 (ou 8 sa dépend des fois) et donc j'ai déjà créer des petites armes pour les importer sous UT2004.

->Niveau musical je fais de la musique dans un groupe (je vais pas faire de pub c'est pas spécialement l'endroit) et donc tout se qui touche au son je m'y connais moyennement on va dire. je touche a REASON 4, Adobe Audition 2 et à la guitare !

->Je touche un peu a photoshop aussi mais j'avoue que je suis loin d'être un as en matière de création de texture.



Alors voilà, ma présentation étant faite, j'ai une question qui semble un peu vague mais je vais m'expliquer :


La question étant : Qu'elle connaissance dois-je avoir pour créer des jeux en 3D avec Irrlicht?

Étant donné que j'ai des petites connaissances dans tout se qui touche au jeux vidéo (son, image, 3D, programmation), je me suis dit que je pouvais me mettre a réaliser un petit jeux type FPS pour voir comme ça, histoire de.

Et donc j'aimerai savoir qu'elle connaissance dois-je avoir de plus? (ici on parle juste programmation bien sur)



->Connaitre les matrices sur le bout des doigts?

->Multithreading? (si j'utilise Irrlicht et un moteur physique tel que Newton, suis-je obligé de faire du Multithreading? si oui, qu'elle bibliothèque en C++ dois-je utiliser? J'ai cru voir Boost, pThread(qui est un librairie C donc pas utilisable ici, ou difficilement)

(peut être que d'autre question me viendront plus tard.. toujours est-il que pour le moment j'en ai pas d'autre ^^)

Je vous remercie d'avance pour votre aide!

Salut et bienvenu à toi.

J'ai déplacé ton post car il n'est pas vraiment lié directement à la programmation en C++ d'Irrlicht

Merci en tous les cas pour ta présentation.

Il semble que tu ai touché déjà à pas mal de choses, et très diverses qui plus est. C'est toujours un atout, surtout
lorsque l'on veut s'aventurer dans le monde de la création de jeux video.

La question étant : Qu'elle connaissance dois-je avoir pour créer des jeux en 3D avec Irrlicht?

Ben, déjà connaitre Irrlicht, ainsi que les base de la 3D tout simplement. Tu as déjà un peu de codage à ton actif
avec ce moteur, donc ton apprentissage à déjà bien commencé, il faut continuer, tout en t'amusant... et
orienter petit à petit tes codes vers le genre de jeux que tu souhaites créer.

Après, pour revenir sur la creation de jeux d'une manière générale, tout dépends aussi de tes ambition actuelles.
Créer un jeux, c'est vague, cela va d'un simple Tetris2D jusqu'au dernier produit les plus pointu techniquement
comme FarCry2 par exemple. Donc, pour ce qui te concerne, tout dépend de ton objectif du moment et à court termes.

Plus tu te fixera un objectif techniquement important, plus bien sûr les obstacles et le niveau requis sera
important, Lapalisse ne dirait pas mieux, n'est-ce pas...
Une des erreurs les plus souvent rencontrée chez les débutants, c'est souvent un barre placé trop haut, ce qui les
mènent dans une impasse, et fini par les dégouter... à toi de ne pas tomber dans ce piège...

Si tu débute dans la prog de jeux, alors mon premier conseil est de te fixer des objectifs accessible et en
rapport avec tes compétences. Au fur et a mesure, ton niveau va monter, et tu pourras te lancer au fil du temps
dans des projets de plus en plus pointu.
Je sais que l'on à tous des projet super en tête, maintenant il faut avoir la sagesse parfois d'attendre et d'en
passer par une phase moins glorieuse de l'apprentissage...
Les connaissances par exemple sur les matrices, ou encore le multithreading (vue que tu en parle) viendront alors
petit à petit d'elles même, mais aussi en fonction de tes besoins. Beaucoup de petit jeux amateurs n'ont nullement
besoin par exemple d'une programmation multithreading. Ca aussi c'est un piège fréquemment rencontré, beaucoup se lance
directement dans l'emploie des véritable bombes thermonucléaire juste zigouiller une malheureuse coccinelle...

Et puis, pour apprendre, il faut lire, les forum, ici ou le forum off, poser des questions, tirer partie de certains
codes trouvés de-ci delà, par exemple il n'y a pas de honte à reprendre un code existant, le modifier et en tirer partie..
C'est aussi comme cela que l'on apprend

Merci beaucoup pour ta réponse rapide, efficace et détaillée! (désolé pour le post au mauvais endroit)

C'est à peu près l'idée que je me faisais du développement de jeu quand on débute. Pour le moment je développe ce que j'appel des 'modules'. C'est à dire que je fais des petits bouts de code qui sont susceptibles de m'être utile par la suite dans un jeu.

Pour ma part, j'aimerai tout d'abord créer un FPS (il y a moins de contenu externe genre : mesh/texture/dialogue/ ect a mon gout) avec des textures en bump mapping, pas de moteur physique au début (parce que ça fait une autre bibliothèque à apprendre et c'est long avant de bien l'avoir en main), évoluant sur 2-3 niveaux juste pour dire (histoire de savoir charger des maps, charger/sauvegarder une partie...).

De plus, une fois le 'moteur du jeu' crée il me faudrait créer un petit 'mapEditor' pour pouvoir créer des map de façon graphique.. et ça c'est long a mon avis.. Ce qui me gène pas mal c'est comment sauvegarder la map, par quel méthode procéder.
J'avais en tête de sauvegarder le SceneManager (avec la position de chaque mesh, lumière et leur propriété, ect) dans un fichier, puis le charger par la suite.
Il existe peut-être déjà une méthode permettant de faire se que je viens de cité. Bref merci beaucoup pour ta réponse. Je suis encore loin de créer un jeu, je le sens!

Ton approche me parait bonne et sensée.

De plus, pour ce qui est de monter un petit FPS, Irrlicht possède tout ce qui faut, et c'est probablement
un des domaine ou il est le plus à son aise .
Donc tu devrais arriver à te faire plaisir avec très vite, et finalement c'est là le plus important, non ?

Bonjour,

Je suis dans un cas très similaire à sharksfh ^^.
J'ai commencé directement le FPS lorsque j'ai commencé à utiliser Irrlicht, il est vrai que je ne m'attendais pas à avoir si vite un personnage qui se déplace !

Je me pose donc les mêmes questions que toi, actuellement j'en suis à comment générer une map (il y a un ou deux tutoriels sur le net, mais rien de vraiment extra ordinaire pour un débutant).
J'ai utilisé le tutoriel officiel et mon personnage est bloqué dès le début et c'est très difficile de le faire bouger.

Enfin tout ça pour dire, sharksfh si tu veux que je te partage ce que j'ai déja fait, aucun problème (c'est un peu le bordel mais y'a peu de code).
Voila, j'hésite à poser mes questions sur les forums car j'ai l'impression que je vais passer pour un débile...

Bonne journée

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...

valholl :

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

Heuu, oui je crois en effet, mais ta tartine amène un éclairage supplémentaire et qui n'est pas vraiment souvent abordé, surtout par les
amateurs que nous sommes, et qui négligent souvent cet aspect 'organisationnel' .
C'est d'autant plus dommage que cela rendrais bien des projets, même modestes, bien plus limpide et donc avec une chance de les
voir aboutir bien plus élevé.