Bonjour, je viens raconter ma vie. J'ai suivi des études de prog, pendant lesquelles j'ai pas touché des masses a C++ mais suffisament pour au moins connaitre jusqu'aux pointeurs. Je voulais programmer des jeux. J'ai bien lu les avertissement sur les site genre siteduzero et autres qui conseillent de conseiller par le sempiternel mario sokoban et autre pendus et trucs ultra chiants, et j'ai décidé de les envoyer se faire voir et de commencer direct par un FPS 3D. En janvier 2008, j'ai débuté l'openGL, sous ubuntu. Sample de base, moches, etc. Trois mois plus tard, a un rythme plutot lent, j'avais déja une ville aléatoire composée de triangles de base colorés et j'ai décidé de lancer le projet Duke Noel 3D. Six mois plus tard, je créais ce topic:

https://www.jeuxvideo.com/forums/1-50-35128298-1-0-1-0-preview-duke-noel-3d.htm

j'avais un semblant de loader de fichier .obj pour la 3D, j'utilisais la SFML et je pouvais me déplacer dans ma ville, avec gestion des collisions et autres.

Plus tard, je filais une démo jouable. On avait plusieurs armes, je crois. j'ai un peu oublié certains trucs. Lorsque j'ai fini par abandonner le projet, par lassitude et parce que mes études avaient revues en un mois ce que j'avais appris en autodidacte en trois mois et qu'il etait temps de passer un level superieur, j'avais modelisé et implémenté un engin pareil dans le jeu:

http://s2.noelshack.com/old/up/mgk-46d356de46.png
http://www.noelshack.com/com/1/1/capture-da3d327018.png
http://s2.noelshack.com/oold/up/capture2-d3030c8578.png

On pouvait tirer sur les ennemis avec.

En tout, j'avais un environnement 3D, collisions, IA méga basique capable de contourner les batiments, un semblant de gameplay, quelque effets de particule de base. Je partais quasiment de rien.

Tout ce que j'ai fait dans ce jeu, tout ce que j'ai mis un temps fou a développer plus ou moins cradement me sert encore parfois aujourd'hui, lorsque je cherche un algo de base pour tel ou tel probleme (genre faire qu'un ennemi nous regarde tout le temps). J'ai jamais regretté de mener ce projet, même si ça n'a jamais été facile et j'ai appris enormément de choses, et j'ai tenu un an et demi dessus.

Tout ça pour dire quoi? Je trouve qu'un mario sokoban est chiant comme la mort et j'aurais lâché le coups bien avant si je m'etais emmerdé a le faire. je n'aime ni le sokoban, ni mario. Certaines personnes peuvent trouver qu'il est utile de passer par là, et je comprend leur opinion, mais vous n'etes pas obligés de le faire, ça n'est pas une fatalité. Vous pouvez aussi partir sur le champs de bataille avec votre bite et votre hache et partir sur un projet d'une difficulté hallucinante pour vous, tant que vous gardez conscience de ce que vous faites et que vous ne vous fixez pas non plus un but trop élevé. Ainsi, vous aurez toujours du travail a faire sur ce projet et un but a poursuivre, et pour peu que le sujet vous passionne, vous resterez motivé pendant un temps incroyable. Vous apprendrez enormément de choses, même si c'est pas le parcours habituel, et vous garderez peut etre des lacunes (j'aurais du mal a faire un pendu, je déteste manipuler des chaines de caractère et je fais toujours les mêmes erreurs de dépassement de tampon ou autre..) mais si c'est comme ça que vous préferez faire l'approche, vous en tirerez une enorme satisfaction. Gardez simplement courage et la tête froide.

je me suis trompé dans les dates, j'ai commencé l'openGL en janvier 2009, pas 2008. A une heure pareille je voit plus trop clair et je me gourre tout le temps a cette période de l'année, le passage de la nouvelle année etc.

C'est quoi un mario sobokan ?

C'est celui ci:

http://www.siteduzero.com/tutoriel-3-14130-tp-mario-sokoban.html

DukeNoel3D, tout d'abord bravo pour ton projet, je ne le connaissais pas car je ne traine plus sur fdj. J'aimerais foutre personnellement mon poing dans la gueule à tout ceux qui t'ont répondu "euh comment dire..." "moche..." quand on sait le travail que ça représente et que le graphisme finalement... c'est optionnel quand on code, si ton objet fonctionne peut-être importe sa tronche normalement (après bien sûr arrive l'optimisation et le low-level shader programming).

Ton parcours me fait juste penser que t'as ça dans le sang et dans les trips. Ce n'est pas le cas de tout le monde, je suis pareil que toi "si ce n'est pas dur ça ne m'intéresse pas", mais je ne suis pas sûr qu'on soit capable de faire ça dans toutes les matières du monde (à moins d'être un surhomme). Le plan que je donne est un modèle moyen mais qui tient la route en terme de finalité selon moi.

Bonne continuation sur ton jeu en tout cas

Merci J'avais voulu partir radicalement a contre courant,(sans partir attaquer des moulins quand même) pour ce projet. Ca m'intéressais.. T'avance par étape, et pour chaque chose que tu veut rajouter, tu te pose la question "comment faire?" et tu cherche des réponses. C'est du concret! programmer des logiciels de gestion de tableur pour se skiller avant le grand saut, ça me paraissait assez peu engageant

Maintenant que t'en parle, des détracteurs, j'en ai eu quelques uns, c'est assez etonnant de voir les gens qu'on arrive a attirer quand on se lance dans un truc. lui, particulierement:
https://www.jeuxvideo.com/forums/1-50-35128298-9-0-1-0-preview-duke-noel-3d.htm#message_35143666

L'archétype du mec qu'est contre ton projet, tu sais pas pourquoi, mais il t'aime pas. Enfin, il avait pas l'air d'avoir quelque chose a mettre sur la table pour appuyer ses propos donc j'y ai preté aucune attention. j'ai bien conscience que j'allais pas refaire crysis, mais j'ai adoré ce que j'ai fait sur ce jeu.

Bon, je l'ai laissé tomber car ça restait une grosse démo technique qui avait evolué de maniere désordonnée, le code etait imbouffable et malgré une refonte, il a "périmé" et je voulais passer a autre chose. Bonne continuation a toi aussi

Coelacanthe a répondu pour moi, ce mec a sérieusement un problème, vraiment.

Ouais j'ai lu ton code.
C'est en effet très mal architecturé et les fonctions de 200 lignes en veux tu en voilà mais.... merde ça marche quand même après tout non ? Nous sommes d'accord.
Ca me fait juste dire que N'EMPECHE suivre le petit plan que je viens de dire te permet d'acquérir amha la partie non sauf négligeable d'un vrai code : la réutilisabilité. Clareté, élégance, LISIBILITE, anglais anglais anglais, etc. Tous ces petits trucs qui font que quand t'arrives sur un forum les gens prennent la peine de lire ton code, que tu gagnes toi aussi en performance d'écriture en ayant bien concaténé et séparé ce qu'il y avait à séparer.

Bonne continuation l'ami. Tu bosses dans quoi du coup actuellement ?

Cela dit je crois pas avoir mis le sdz dans mon plan pédagogique au passage

"Ca me fait juste dire que N'EMPECHE suivre le petit plan que je viens de dire te permet d'acquérir amha la partie non sauf négligeable d'un vrai code : la réutilisabilité. Clareté, élégance, LISIBILITE, anglais anglais anglais, etc."

pas besoin d'un plan pour ça, on l'apprend tout seul quand on relit son code et qu'en fait, on n'y comprend plus rien alors que ca fait une semaine seulement qu'on l'a laissé.

je me rappelle, au début j'indendais même pas.

c'est venu tout seul, comme une nécéssité

Là, je bosse dans l'informatique généraliste, mais je continue de coder des jeux pour moi je voulais que ça reste un plaisir, pas que ça devienne un travail, même si travailler dans le JV m'aurait plu..

Tu devrais, selon moi t'as ça dans le sang mais bon.

"pas besoin d'un plan pour ça, on l'apprend tout seul quand on relit son code et qu'en fait, on n'y comprend plus rien alors que ca fait une semaine seulement qu'on l'a laissé."

Moins certain que toi. Le design pattern je suis pas sûr que ça soit forcément un réflexe inné. Il y a des choses qui s'apprennent on ne peut pas passer outre... Et si personne ne t'en a parlé ça m'étonnerait pas oui que tu puisses passer quelques temps avant de t'y plonger.

not' bon prof de programmation avancée m'en a parlé, du design pattern, il disait que c'était naze.

cet homme travaillait pour l'industrie de pointe, domaine dans lequel de petites maladresses (genre: utiliser un entier signé au lieu d'un entier non-signé ) peuvent coûter des vies

et n'ayant pas eu l'occasion de développer de grosses applications dans une optique de développement rapide et fiable, j'ai suivi aveuglément son opinion, et préfère la programmation simple et efficace, celle où on n'aligne pas les DLL pour les moindres petits trucs.

Le design pattern repose en grande partie sur la POO. Si ton prof était un anti-POO on ne pourra malheureusement pas faire grand chose pour le faire changer d'avis.

Mais là pour moi, désolé, tu es en train de me dire qu'on peut faire de la POO propre sans avoir aucune notion de design pattern et là je dis non.

Développement rapide c'est une chose, fiable c'en est une autre, et bien différente (pour pas dire contradictoire) !
Tu ne peux pas à l'heure actuelle faire une grosse application en POO sans aucune notion de design pattern sans passer pour un rigolo. Tout framework qu'il soit open-source ou non qui sort repose sur une architecture faite d'un conglomérat (plus ou moins intelligent) de pattern propre à une utilisation précise. Je ne parle pas d'assembleur ou de Cobol là, je parle de C++, du software du "vrai" au sens où on l'entend dans l'informatique. Je ne parle précisément pas de VDHL ou de la programmation micro-contrôleur.

Je ne vois pas du tout en quoi le design pattern est contradictoire avec une programmation simple et efficace. Mon expérience d'ailleurs me fait dire que plus je fais un travail de post-analyse plus le processus de développement pur devient agile et limpide.
Un bon programmeur doit savoir adapter le degré de granularité de son architecture avec la complexité de son application finale, là-dessus nous restons d'accord. Si tu dis toi-même que tu n'as jamais été enrollé dans le développement d'une grosse application ta manière de travailler peut effectivement sembler encore un tantinet judicieuse... Mais est-ce une raison pour en faire une loi générale à tous les ordres hiérarchiques ?
Qui plus est quel est le rapport entre l'utilisation d'une librairie externe et du design pattern ?

"pré-analyse"

"
Tu ne peux pas à l'heure actuelle faire une grosse application en POO sans aucune notion de design pattern sans passer pour un rigolo. Tout framework qu'il soit open-source ou non qui sort repose sur une architecture faite d'un conglomérat (plus ou moins intelligent) de pattern propre à une utilisation précise. Je ne parle pas d'assembleur ou de Cobol là, je parle de C++, du software du "vrai" au sens où on l'entend dans l'informatique. Je ne parle précisément pas de VDHL ou de la programmation micro-contrôleur. "

et tu parles de la programmation débutante, là?

là, tu me sors des exemples d'applications qui sont utilisées en entreprise, celles qui doivent être développées assez rapidement et de manière fiable (d'où l'utilisation de langages tels que c# en lieu et place du c++ qui nécessite quelques précautions d'emploi qui font peur à nombre de programmeurs actuels, genre: détruire les objets soi-même ), pour lesquelles on doit allouer du temps pour en travailler l'ergonomie, etc.

toutes les applications, et plus encore celles qu'on développe seul, ne sont pas soumises à ce genre de cahier des charges.

on ne peut faire de POO propre sans design pattern, c'est un fait. surtout pour les grosses applications, celles qu'on développe à plusieurs, celles qui doivent avoir un code prétendument lisible (va comprendre un code truffé de patrons de classe )

"Un bon programmeur doit savoir adapter le degré de granularité de son architecture avec la complexité de son application finale, là-dessus nous restons d'accord."

'granularité'?

"Si tu dis toi-même que tu n'as jamais été enrollé dans le développement d'une grosse application ta manière de travailler peut effectivement sembler encore un tantinet judicieuse..."

les débutants ne le sont pas forcément non plus.

"Qui plus est quel est le rapport entre l'utilisation d'une librairie externe et du design pattern ?"

c'est une forme de programmation qui a tendance à faire oublier qu'au départ, l'informatique, c'est une affaire de 1 et de 0

optimiser son code devient un art qui a tendance à se perdre, et s'orienter vers une forme de programmation toujours de plus haut niveau peut poser problème le jour où on est censé revenir un peu en arrière

"Mon expérience d'ailleurs me fait dire que plus je fais un travail de post-analyse plus le processus de développement pur devient agile et limpide. "

y a une autre approche, qui consiste à adapter ses besoins au fur et à mesure. celle-ci offre l'avantage de permettre de réagir aux différentes contraintes imprévisibles et aux changements des besoins

Mon esquisse de guide pédagogique partait plutôt sur l'optique de partir d'un néophyte total pour arriver à un bon programmeur professionnel débutant dans le métier.
Si tu relis ce que j'énonce ça prend un sacré bon bout de temps à faire (je dirais 5 ans minimum puisque ça concorde à peu près au cycle universitaire de toute façon) donc on ne peut plus prétenduement parler d'une pédagogie s'adressant uniquement aux débutants. Je n'ai jamais prétendu qu'un débutant devait apprendre d'emblé le design pattern... Je pense que c'est effectivement risqué et très vraisemblablement démotivant.

Je ne base pas du tout mes raisonnements sur les logiciels d'entreprises en interne privilégiés des SSII lambda à coup de C#.
Quand je te parle de ça j'ai au contraire en tête de vraies chef d'oeuvre de la programmation (par exemple Bullet Physics), et en aucun cas un autre langage que le C++ pour être franc.
L'avantage dans la partie C# de mon plan c'est d'une : de l'apprendre parce que ça me paraît inévitable aujourd'hui. D'apprendre aussi un autre langage car il est tout sauf bon de ne se spécialiser que dans un seul langage dans sa période de formation. Et de profiter des puissants outils de MVS et du framework Windows Form pour pratiquer et comprendre progressivement l'architecture MVC.

Là par contre je suis d'autant plus perdu. Je vois pas le rapport entre de l'assembleur, les DLL, et le design pattern :s.

"y a une autre approche, qui consiste à adapter ses besoins au fur et à mesure. celle-ci offre l'avantage de permettre de réagir aux différentes contraintes imprévisibles et aux changements des besoins"
C'est exactement ce que je dis.
Adapter la granularité de son code aux besoins de son logiciel final.
Revenir sur l'analyse c'est justement le principe des méthodes agiles. C'est très important de pouvoir refactorer son code c'est tout sauf une raison pour se jeter dedans sans pré-analyse c'est un très mauvais réflexe, très mauvais et donc très répandu.
Comme disait mon prof pour le coup, le code ça commence sur papier, sans syntaxe ni point virgule, juste des jolis dessins qui s'emboîtent.
On peut revenir en arrière, c'est un aspect essentiel indéniable, c'est pour ça que je critique les méthodes waterfall et Cie qui sont d'un non-sens total et ne s'adapte pas du tout au processus de développement d'un logiciel.

Je suis actuellement entouré de 5 brouillons manuscrits à côté de moi.
Les deux premiers sont des dessins, le troisième est un semblant de diagramme de classe, et les deux derniers sont du pseudo-code C++.
Il m'arrive en effet fréquemment de revenir grifonner un nouveau dessin quand j'écris le pseudo-code, de finalement rajouter une nouvelle classe ou modifier ses attributs. Uniquement après tout ça je code, et la partie débuguage commence (ben ouais on se trompe souvent malgré tout hein ).

Je ne discuterait pas de l'interet d'utiliser des "design patterns". Mais je pense qu'il est important de les apprendre. De facona comprendre les problemes que l'on peut rencontrer et quelles sont les facons classiques de les resoudre.

Les design patterns sont (a mon humble avis) avant tout un outils d'apprentissage. La vrai vie ne se passe jamais comme dans les livres. La plupart ne serotn donc pas directement applicable. Mais dans l'ensemble ca aide de les connaitre.

Bonjour,

Je viens soutenir le parcours de DukeNoel3D. Mon parcours est plus ou moins similaire.

J'ai toujours été passionné par l'informatique. Je ne joue que très peu mais les jeu m'ont toujours fascinés. Je voulais faire un FPS. J'ai cherché sur de nombreux site comment faire. Et là, on vois de tout et n'importe quoi. Surtout de n'importe quoi d'ailleurs.

Parmi le n'importe quoi il y a tout les gens sur les forums qui n'ont jamais rien créé et qui disent qu'il est impossible de créer un FPS tout seul, qu'il faut avoir un grosse équipe.

Pourtant, beaucoup de jeunes se lance dans la création d'un jeu vidéo tel qu'un FPS en commençant à recruter 2 programmeur, 2 designers, des modeleurs, des compositeurs... Ces jeunes embarquent beaucoup de gens dans leur projet mais ne créent rien de leur vie. Il ne fout pas entrer dans ce piège.

Je pense qu'il est important de se fixer des objectifs, même ambitieux et de chercher à les atteindre, même s'il prennent du temps.

Pour en revenir à mon projet, je développe un FPS assez similaire à celui de DukeNoel3D. Et pour montrer au maximum de personne qu'un tel projet n'est pas irréalisable par une personne seule, je publie régulièrement de nouveaux chapitres pour mon tutoriel portant sur la création d'un FPS. Il s'agit de montrer à tout le monde qu'il est possible d'y arriver. Pour y parvenir, je privilégie systématiquement la simplicité.

Régulièrement, je reçois des messages de mes lecteurs qui me disent : "En fait c'est vrai que ce n'est pas si compliqué". Mon objectif est alors atteint : le message est passé.

Pour ceux qui serait intéresser par le développement d'un simple FPS, je vous conseil alors mon tutoriel. Je sort de nouveau chapitre assez régulièrement. Il vous permettera de revivre l'aventure de la création de mon FPS. Le côté "recherche" est déjà un peu prémaché. Il devrait pour propulser plus rapidement vers le développement de jeu vidéo que si vous deviez commencer de rien.

Mon tutoriel sur la création d'un simple FPS 3D en C++ :
http://www.jeux-libres.com/tutoriaux/sommaire-3-creation-un-jeu-video.php

Je vous souhaite une bonne lecture.

PS : N'ayez pas peur de vous lancer.

Bonjour a toi Davidlouiz,

Merci de ton retour d'experience sur la creation d'un FPS. Je ne me rappelle pas t'avoir vu par ici, donc je pense que tu n'as pas bien lu les conseils et retour d'experience des gens par ici.

Je pense que personne ici ne pense qu'il faut autant de temps pour faire un FPS basique, en partant du principe que l'on est deja un developpeur a peu pres competent. D'ailleurs ton tutoriel commence par dire qu'il suppose que l'on connait le C++. Si on ne le connait pas, l'apprendre prends 6 bon mois.

Ensuite les gens ne viennent pas nous dire qu'ils veut faire un FPS basique. Ils viennent dire qu'ils veulent faire un FPS meilleur que <inserer ici le dernier FPS sortie cette annee qui a battu tous les record de qualite>. Et un tel FPS, necessite une equipe entiere pendant un temps non negligeable.

bonne journee a toi,

Erik

L'obsession du c++ est un truc que j'ai du mal à comprendre à titre personnel.