Discussion :

[flasheur]

Bonjour...

J'ai envie de lancer un ptit débat qui pourrait éviter bien des pièges et des souffrances aux débutants.

On s'en rend pas forcément compte tout de suite, mais se lancer dans l'apprentissage de prog de jeux vidéo en solo c'est bien souvent du suicide. Avant de faire un truc basique (et sans aucune valeur aujourd'hui) comme super-mario, le milieu du jeu vidéo avait déjà une vingtaine d'années d'expérience derrière lui, et on découvre pas des techniques qui ont 20 ans de recherche derrière en claquant des doigts.

Ceux qui ont un tout petit peu d'expérience se sont pris en pleine gueule cette réalité cruelle mais réelle: développer des jeux ça s'apprend à un seul endroit, dans les boites qui fabriquent des jeux, et pas ailleurs. C'est eux qui connaissent les techniques de prog, et ils les donnent pas, ils vont quand même pas expliquer aux étudiants comment leur piquer leur place.
Et encore ça dépend des boîtes, j'exclus les boites pourries gérées par un patron laxiste qui n'ose pas faire la police, résultat, les anciens tirent les nouveaux vers le bas pour faire de la place autour d'eux, ils leur lâchent aucune technique et ils leur apprennent à faire des conneries, pour qu'ils se fassent virer.
C'est un peu sale et cruel comme réalité mais bah voilà, les codeux de jeux vidéo pro sont souvent des gars aigris (c'est un boulot dévalorisant, mal vu, parfois très mal payé), avec un égo enflé (problème propre à toutes les professions avec une touche artistique), et immatures (domaine de la prog pas vraiment très "adulte") qui en sont encore aux crasses de cour de récré et trop souvent se comportent comme des petites racailles de 12 ans.


Les infos les plus bidon qu'on trouve, d'après mon expérience, c'est d'abord dans les livres, parce que y'a strictement aucune intention philantopique derrière, c'est juste histoire de faire du fric. Ce genre de bouquins c'est chronophage à pondre, donc c'est très rarement des crack de la prog qui s'y collent (ils n'ont pas le temps), c'est plus souvent des commerciaux avec trois vagues notions de programmation. Tout ce que j'ai pu lire là dedans est bidon, et c'est normal, on apprend pas un métier juste en lisant un livre. Y'a peut-être quelques bouquins valables mais ça doit être rarissime.

Les tutoriels en ligne, c'est pas la gloire non plus, mais déjà un tout petit peu moins pourri, y'a, disons 1% de trucs filés par des codeurs généreux... le problème des tutos en ligne c'est que c'est souvent fait par des débutants qui n'y connaissent rien et qui vont répercuter leurs erreurs sur tout une communauté de développeurs. Même problème sur les forums.

Et le pire des pièges, dans ce terrain miné, c'est ces écoles de jeu vidéo privées bidon montées par des escrocs sans scrupules, qui vivent de la naiveté des jeunes, et à la sortie desquelles les diplômés sont même pas foutus de faire un pong. au mieux ils finissent level-designer ou testeurs de manettes (pour les plus chanceux qui savent pêcher le piston), au pire rmistes. (je comprends pas comment on peut foutre du fric dans ces trucs qui puent l'attrape-couillon...)


Personnellement les seules sources d'info où j'ai appris quelque chose d'un tant soit peu utile c'est:

1/ les cours de maths et d'algo, qu'on trouve sur les sites universitaires. (ou qu'on apprend à l'école...) ça file déjà les bases mathématiques pour comprendre quelque chose à ce qu'on fait


2/ les open-source (id software, 3d realms...). il y'a certes une indéniable intention publicitaire là derrière, mais au moins on sait qu'on a sous les yeux du code qui marche.
inconvénient: c'est toujours des technos dépassées... tant pis, pour un amateur et/ou indie on cherche pas à rivaliser avec les moteurs high-tech


3/ les documentations des consoles de jeux et le hacking de roms.

C'est personnellement là que j'ai appris le plus. Là on risque pas d'être piégés: la doc des machines c'est spécialement fait pour ceux qui développent dessus, et le hacking de roms c'est de l'info qui est prise directement par ceux que ça intéresse.
On découvre une foule de techniques toutes simples et qui marchent impec.

inconvénient: c'est des technos désuètes aussi...


Voilà voilà... apprendre ça tout seul dans son coin c'est donc un vrai parcours du combattant... car non seulement les infos sont cachées et il faut se démerder pour les trouver tout seul, et en plus on vous fout des bâtons dans les roues.


On voit tellement de débutants qui sont largués sur les forums, et des gens en face qui savent pas très bien quoi leur répondre, ( ou pire, des pros vicelards qui pourraient leur donner la solution mais qui font exprès de leur dire des conneries pour les induire en erreur ) si on pouvait tout de suite leur mettre un panneau de signalisation "danger terrain miné" ça leur éviterait de s'exploser les jambes en chemin.

quand je vois les ados qui se lancent dans des mmorpg alors qu'ils n'ont pas la moindre petite idée du parcours du combattant pour réussir à faire un pauvre tetris proprement... je sais même pas par quel bout les prendre pour leur expliquer tout ça.

une "technique" de pro qu'on pourrait leur filer pour déjà bien démarrer c'est de se caler sur la politique des petites boites de j.v qui font des petits jeux: réduction maximale du coût de fabrication. donc on tire parti au maximum du/de la plateforme/moteur/framework/midware choisi pour se faire chier le moins possible.

[Nollo]

J'aurais tendance à dire que ça dépend de l'objectif visé !

Les projets amateurs, tu en as de très bons, tu en as même qui deviennent des projets pro ! D'autres qui bossent sur des mods de jeux et qui sont embauchés plus tard. Bon c'est pas en France bien évidemment

On peut créer des jeux avec les ressources sur le net, et avec les technologies actuelles, tu peux même arriver à des résultats très vite.

Par contre, peux tu après réutiliser ce que tu as fais en entreprise ? Là c'est carrément pas évident. En tant qu'amateur tu bosses sur un peu tout, programmation réseau, graphique, physique ... etc. Tu évites pas mal de phase d'analyse ou de paperasse pour pouvoir attaquer directement le code, et tu ne te préoccupes pas d'utiliser telle ou telle technique tant que ça marche un tant soit peu.

[gbdivers]

Je crois que tu vas te faire des amis

Je vais pas réagir sur l'ensemble du post mais juste sur 2 points en particulier :

Les infos les plus bidon qu'on trouve, d'après mon expérience, c'est d'abord dans les livres, parce que y'a strictement aucune intention philantopique derrière, c'est juste histoire de faire du fric. Ce genre de bouquins c'est chronophage à pondre, donc c'est très rarement des crack de la prog qui s'y collent (ils n'ont pas le temps), c'est plus souvent des commerciaux avec trois vagues notions de programmation. Tout ce que j'ai pu lire là dedans est bidon, et c'est normal, on apprend pas un métier juste en lisant un livre. Y'a peut-être quelques bouquins valables mais ça doit être rarissime.

Tu as lu quels livres ?

Perso, j'ai trouvé pas mal de livres intéressants, complet et très poussés pour la programmation de jeux : Livres sur le C++ (pour en citer que quelques uns : Stroustrup, Meyers, Alexandrescu, Abrahams , Vandevoorde, etc.), sur l'architecture des jeux (la série des Game Programming Gems en 8 volumes, Game Engine Gems, Game Design, AI Game Engine Programming, etc.), sur la 3D (GPU Pro, GPU gems, etc.)

Bien sur que les livres c'est pour faire du fric. Mais un livre rapporte plus s'il se vend bien donc s'il a de bonnes critiques donc s'il contient de choses intéressantes. Et les experts ne sont pas riches non plus au point de refuser d'écrire un livre et de gagner du fric dessus. Donc certains livre sont écrits par des experts dans leurs domaines (ou sont des recueils d'articles écrits par des experts) et contiennent des choses très intéressantes.

Les tutoriels en ligne, c'est pas la gloire non plus, mais déjà un tout petit peu moins pourri, y'a, disons 1% de trucs filés par des codeurs généreux... le problème des tutos en ligne c'est que c'est souvent fait par des débutants qui n'y connaissent rien et qui vont répercuter leurs erreurs sur tout une communauté de développeurs. Même problème sur les forums.

Un grand merci de la part de toute l'équipe de rédaction de Developpez

Il est vrai que le domaine de la programmation des jeux vidéos est tellement vaste que l'on pourrait avoir 10 fois plus de tutoriels sur Developpez que l'on ne couvrirait pas encore la totalité du domaine... Mais le nombre de ressources en ligne est tout simplement impressionnant (en comptant les ressources en anglais). Par exemple, quand on s'intéresse au GPU, la quantité d'information (et pas simplement de la doc technique de référence) que l'on trouve que le site de NVidia (par exemple, mais j'imagine que c'est pareil pour AMD) est très volumineuse. Perso, je n'ai pas encore fait le tour.

Si c'est ton cas, chapeau bas. Tu nous écris quand des tutoriels pour combler le manque dans ce domaine ?

Et il faut savoir qu'un grande partie des nouvelles techniques de rendu ne sont pas créées par les boites de jeux mais pas les constructeurs de cartes vidéo (certaines techniques que l'on trouve sur le site de NVidia ne sont même pas utilisable dans les jeux tellement elles sont trop puissantes... et gourmandes) ou les labos de recherche en info.

Bref, en utilisant les livres, les tutos et les ressources sur internet, je pense que l'on peut apprendre environ 99% des techniques utiles pour un développeur de jeux (et encore, ces 1% manquant n’intéresseront que 1% des développeurs de moteur de jeux... càd quelques centaines de personnes en France peut être)

A mon avis, ton post est très pessimiste


Remarque :

petites boites de j.v qui font des petits jeux (exemple pris au hasard, nintendo)

je suppose que beaucoup de boites aimeraient être aussi "petite" que nintendo

[flasheur]

gb> excuse jme suis mal exprimé, je pensais aux petites boites qui faisaient des trucs pour la gameboy ou la nes (j'ai cette époque en référence, parce que les développements de maintenant sur la gamecube c'est pas vraiment à la portée des amateur/indé - si on excepte les pong avec des jolies particules pour faire rêver les jeunes codeurs pigeons)... je me suis mal exprimé, tant pis (j'ai rectifié le post)

Pour te répondre de façon concise, les tutoriels, les bouquins (y'en a surement quelques uns de bien certes certes), tu auras beau y mettre toutes les techniques intéressantes que tu veux, ton lecteur ira nulle part en passant 3 jours à lire des livres ou des tutos alors qu'il te faut plusieurs années d'études et/ou expérience en entreprise.

Pour répondre de façon moins concise,

Ton rapport de 99% je le réduirais à 10%. Si tu vires les sources/hacks/docs pro et que tu gardes juste les tutoriels, tu peux baisser à 1% voir 0%.

Les livres et les tutos c'est un peu comme si tu voulais apprendre à un mec à construire une maison avec un tutoriel qui explique comment coller deux briques avec du ciment. Quand en plus dans le tas t'en as une floppée qui t'enseignent une technique qui marche pas ou mal et qui aboutirait à une maison qui s'écroule au premier coup de vent, il est mal barré ton apprenti-maçon.

L'apprenti-maçon qui se lance là dedans en autodidacte, s'il veut avoir une chance de pouvoir construire au moins un bungalow, va bien falloir qu'il étudie le procédé de construction de A à Z, et y'a qu'en regardant sur le terrain comment s'y prennent les pros qu'il va pouvoir y'arriver.

C'est pour ça que les sources de boulot de pro, les docs faites pour les pros et les hacks de boulot de pro, c'est quand même un peu plus fiable qu'un tutoriel pour planter un clou écrit par un mec qui vient juste d'apprendre à planter un clou. Et encore je suis gentil, voire qui n'a jamais touché un marteau de sa vie, on voit vraiment des escroqueries lamentables dans ce genre de bouquins (dont certains coutent la peau du derche en plus). Des bouquins valables ça doit se compter sur le doigt. Déjà tous ceux qui ont un titre qui contient une expression du type "programmation de jeux" tu peux être sûr que c'est une arnaque. Un bouquin sérieux ça peut au mieux t'apprendre à faire UN seul type de moteur, et un moteur simple. Un bouquin intitulé "faire un clone de mario avec sdl" à la limite ouais. Mais c'est pas vendeur. Et faudrait montrer le programme terminé déjà pour valider le truc, et j'ai jamais vu un vrai jeu de pro dans ce domaine, que des tech-démo toutes pourries. Si un bouquin est vraiment fiable t'as bien un mec qui va mettre en ligne le résultat (si j'étais l'auteur c'est ce que je ferais) je parie une bouteille de champagne que tu trouveras pas un lien de ce type.

Si c'est ton cas, chapeau bas. Tu nous écris quand des tutoriels pour combler le manque dans ce domaine ?

Tu m'as compris à contresens on dirait bien... j'ai émis l'idée que les tutos ça sert à peu près à rien pour apprendre à dev des j.v. Les tutos ça sert à démarrer sur un langage de prog ou des formules de math élémentaires, ça va pas plus loin.

Je peux faire un tuto pour les débutants qui veulent faire un mario-like, qui explique comment blitter des tiles avec la SDL (comme il en existe déjà une tonne), mais le noob qui lit le tuto il est vachement avancé après ça... il lui reste à apprendre comment encoder et sauver des maps sur le disque, comment les construire intelligemment sans passer des semaines à faire le truc bêtement brique par brique, une tonne de formules de collision, une grosse routine générale qui gère toutes les sous-routines dans le bon ordre (impulsions, collisions dynamiques/dynamique, dynamique/statique, renvoi d'info, culling/generation/destruction, affichage de tous les plans et tous les sprites, events sons...), comment gérer la generation et destruction d'objets dynamiques, comment gérer le blitting des spritesheets, comment structurer son bazar en states, comment récupérer l'interrupt clavier, comment faire des routines finies ou des fsm sur ses bonhommes, comment gérer les events de scenario, comment gerer les scores, les bonus, les levels, la musique, les textes, gérer une foule de comportements différents, comment mettre des piles et des queues d'events, et puis comment maintenir et débugger tout le cirque, et comment gérer le bordel sur des écrans qui sync tous à des vitesses différentes... (tout ça pour aboutir à un vieux truc style années 80)... bah le mec il va y passer sa vie s'il compte juste sur des tutos ou des livres... alors que quand on connait les bonnes techniques le développement de ce genre de jeu c'est expédié en 2 mois (voir moins).

Il a quand même plus de chances de s'en sortir en fourrant son nez dans de la doc pour pros, des sources de pros, et des hacks de boulot de pro.

Et puis s'il apprend ça en entreprise (bon la sdl c'était un mauvais exemple... disons un framework pour jeux sur tel mobile), il ira encore plus vite et en plus il sera payé à le faire et il va pas claquer tout son temps libre en autoformation.


Bon bref faire des tutos ça me botte pas trop. Si je devais faire un article utile pour aider les noobs je leur expliquerais plutôt comment faire le jeu. Mais j'en ai au moins pour 2 mois à plein temps, je peux pas faire ça gratos. Quand à en faire un bouquin c'est pas intéressant vu que ça se vendrait pas: quand on apprend sérieusement on verse beaucoup de sueur pour des résultats modestes, c'est pas vendeur... ce qui est vendeur c'est de faire croire aux jeunes qu'ils vont rivaliser avec blizzard sans fournir aucun effort, c'est pour ça qu'il y'a plein de bouquins bidon et d'écoles de jeux vidéo bidon: on vend du rêve, parce que le rêve ça se vend mieux que le long et douloureux apprentissage d'un métier qui se révèle chiant et pas intéressant quand on commence à le maitriser un peu (je ne bosse quasiment plus sur des jeux et je m'en porte pas plus mal, c'est meilleur pour le moral de bosser sur des trucs plus utiles à la société et moins dénigrés) et ce genre de vérité il vaut mieux la cacher pour pas faire fuir le client.


Sur les forums on voit un décalage monstrueux entre les ambitions des djeunes (je veux faire world of warcraft 2 avec mes copains) et le niveau des questions techniques (comment faire tourner ma caméra). Je veux construire un château mais je sais pas planter un clou, je cherche des livres et des tutoriels pour apprendre à planter plein de clous. Aïe.

Et puis tiens puisque tu me parles des techniques de rendu hardware, on est toujours dans ma métaphore du plantage de clou. Sur les forums on voit plein de gars qui se ruent sur la 3d parce que c'est beau c'est chouette c'est tape à l'oeil, ça cause des super effets de shaders directx10, on a fait un super tutorial pour afficher un joli objet en 3d plein d'effets spéciaux... et puis quand on commence à aborder des bribes de bases algorithmiques élémentaires et indispensables pour appréhender le dev de jeux 3d, tout le monde est largué.

Donc c'est qu'y a un problème.

Alors je sais que je dis peut-être les choses de façon un peu "hyperbolique" mais c'est toujours moins hyperbolique que le décalage astronomique entre les ambitions et les moyens de mecs qui veulent apprendre à coder des jeux avec les forums/tutos/bouquins alors que la seule façon d'apprendre c'est de fourrer son nez dans le boulot des pros. Ca sera moins douloureux pour eux de lire mon post désagréable plutôt que de laisser leur jeunesse et leur santé dans des projets infinissables, comme tous ceux qui tombent dans le panneau.

Il est pas pessimiste mon post, je donne les bonnes pistes et je mets en garde contre les pièges.

Nollo > si tu veux faire un 65421654ème clone de pong, ou autre genre de bricolages rigolos qui sont plus proches du démomaking que du jeu vidéo, ouais...

[gbdivers]

Ton rapport de 99% je le réduirais à 10%. Si tu vires les sources/hacks/docs pro et que tu gardes juste les tutoriels, tu peux baisser à 1% voir 0%.

Ok, c'est un problème d'estimation. Comme je ne suis pas expert, il est possible que je me trompe. Mais je reste convaincu que la majorité des informations sont disponible ailleurs que dans les entreprises ou les hacks.
Faisons une expérience : dis moi des techniques que tu aurais trouvé dans les hacks et je rechercherai si ces techniques sont dispo dans un livre ou un tutoriel.


Pour le reste, si je résume :

va bien falloir qu'il étudie le procédé de construction de A à Z, et y'a qu'en regardant sur le terrain comment s'y prennent les pros qu'il va pouvoir y'arriver.

tu distingues le savoir (ce que l'on apprend dans les livres et autres) et le savoir faire (que l'on apprend en pratiquant, seul ou accompagné)

Quand en plus dans le tas t'en as une floppée qui t'enseignent une technique qui marche pas ou mal

tu pointes du doigt le problème que l'information pertinente est perdu au milieu d'autres informations fausses, incomplètes ou mal faites.

ton lecteur ira nulle part en passant 3 jours à lire des livres ou des tutos alors qu'il te faut plusieurs années d'études et/ou expérience en entreprise.

Ici, tu abordes le problème de l'apprentissage en général : il faut du temps et du travail pour apprendre.


Je ne peux être que d'accord avec ces points (ce n'est d'ailleurs pas spécifique aux développement de jeux).
Finalement, les problèmes que tu soulèves sont que les débutants veulent aller trop vite (faire directement un super mmo qui tue wow) sans prendre le temps d'apprendre (ils veulent le faire en 3 jours parce qu'après ils seront passé à autre chose) et qu'ils ne savent pas comment et où trouver les informations nécessaires (et je rajouterai à ça qu'ils ne savent pas non exprimer correctement leurs problèmes quand ils demandent sur un forum).
Le corollaire est qu'ils peuvent du coup se laisser berner par des offres accrocheuses pour un livre ou une formation.

En bref, le problème n'est pas l'existence ou la disponibilité des informations mais bien les erreurs faites par certains débutants (pas tous, d'autres, un minorité c'est vrai, écoutent les conseils, prennent le temps d'apprendre et d'y aller progressivement)

Il est pas pessimiste mon post, je donne les bonnes pistes et je mets en garde contre les pièges.

L'intention est louable. Sauf que tu es parti sur une attaque contre les livres, les tutoriels et les entreprises alors que le problème (comme tu le dis toi même dans ton second post et dans ton post sur La vérité sur la conception de jeux amateurs) vient avant tout des personnes. On (je ?) ressent un peut d'amertume dans ton premier post.

Peux tu préciser quel est ta formation et ton niveau d'étude, ton domaine de travail, ce que tu as développé comme jeux, etc. ? Pour avoir une idée du contexte dans lequel tu places tes remarques (juste pour situer, je travaille pas moi même dans le développement de jeux)

Sur les forums on voit plein de gars qui se ruent sur la 3d parce que c'est beau c'est chouette c'est tape à l'oeil, ça cause des super effets de shaders directx10, on a fait un super tutorial pour afficher un joli objet en 3d plein d'effets spéciaux...

J'aime bien les effets kikoulol de la mort qui tue en 3D moi...

[DarkHerumor]

Je vais me limiter à un seul commentaire, parce que je suis sur que ce thread va mal partir

Quand je lit ça, pour moi, c'est un coup de gueule d'un gars qui vient d'avoir une mauvaise expérience, ou une forte désillusion, le tout remplit de mauvaise foi... Je ne lis aucun argument concret... Les livres, forums, tutos, même s'ils ne sont pas du niveau des grand studio du JV, n'en ont jamais eu la prétention, et sont d’excellent points de départ.

Ce forum lui même est excellent point de départ. Il faut évidemment des bases à minima en algo et en math. Mais tout s'apprend, et pas nécessairement en cours ou en boite. Quelqu'un de motivé y arrivera, avec le temps, mais il y arrivera.

Et enfin, une chose que je comprend pas, tu dis "il faut apprendre dans une boite" mais du démonte derrière le travail en boite à cause d'une mauvaise mentalité du métier...

[Invité]

Par exemple, quand on s'intéresse au GPU, la quantité d'information (et pas simplement de la doc technique de référence) que l'on trouve que le site de NVidia (par exemple, mais j'imagine que c'est pareil pour AMD) est très volumineuse.

C'est marrant, au contraire l'information qui est vraiment utile (quels bugs sur quels cartes avec quels drivers) est secrète. Il faut les troller méchant pour même commencer à en entendre parler...

Perso j'ai bossé sur des jeux en pro et en amateur mais jamais dans une vraie boite de jeu... je me suis vite rendu compte que les boites de jeux ne t'accordent pas de crédibilité si t'es pas déjà de ce milieu. Dommage il y a des industries aussi fauchées avec des méthodes similaires. Au final c'est pas mal de bosser dans une autre branche où les gens veulent bien payer pour le logiciel.

[screetch]

@Flasheur: tu es très amer et il semble que tu as eu une (en fait, beaucoup) de mauvaises experiences?

[Invité]

Heu non je ne suis pas aigri Au contraire je suis très content de mon travail actuel. J'essaie d'informer dans pas mal de threads les gens sur le fait qu'OpenGL est une API bien en théorie et dangereuse en pratique, ça doit me donner ce côté aigri.
(EDIT: ah ok tu as édité)

[screetch]

oh pardon je répondais a flasheur dans son premier post du débat, qui me semble amer!

[gbdivers]

C'est marrant, au contraire l'information qui est vraiment utile (quels bugs sur quels cartes avec quels drivers) est secrète. Il faut les troller méchant pour même commencer à en entendre parler...

Oui, NVidia est une entreprise, pas une oeuvre philanthropique. Et parler des défauts de ses produits n'est pas très efficace sur le plan commerciale. Donc, comme on est des gens intelligents, on sait que :
- s'il y a des bugs, ils seront pas communiqués, sauf défaut majeur qui nécessite le retour massif des produits vendus
- les tests et benchmarks présentés par les constructeurs sont forcement valorisants (non pas que les chiffres soient faussés mais les tests ne mesurent pas tout ; exemple classique, ce sont les tests de CUDA qui mesurent que le temps d'exécution et pas le temps de transfert de données)
- les techniques présentées sont forcement valorisantes (si une autre technique existe mais qu'elle est plus performante sur les cartes de la concurrence, on risque de ne pas en entendre parler sur le site du constructeur)
- etc.
Bref, pas de grandes surprises dans ces pratiques. On est assez grand pour avoir le recul nécessaire.

Mon message se basait surtout sur le fait que c'est dans l'intérêt des constructeurs de GPU qu'un maximum de techniques soient diffusées (cf les livres et ressources publiés par/avec NVidia) et même aller jusqu'à développer de nouvelles techniques (cd les labos NVidia et leurs publications). Idem pour les laboratoires de recherches publiques en mathématiques appliquées/informatique, dont le boulot est justement d'inventer de nouvelles techniques et de publier dessus.

Et enfin, une chose que je comprend pas, tu dis "il faut apprendre dans une boite" mais du démonte derrière le travail en boite à cause d'une mauvaise mentalité du métier...

Effectivement, on a un peu de mal à savoir du coup ce qu'il faudrait faire : aller dans une boîte ou non ?
De plus, j'entends souvent des personnes dirent qu'elles ont beaucoup appris en autodidacte, durant leurs formations ou dans leurs boulots. Donc, concrètement, c'est quoi la différence entre apprendre dans une boîte ou sans être dans une boîte ?

Pour parler de ma propre expérience (pas dans le domaine de jeux vidéos mais je pense que le problème est plus généraliste) :
- quand je dois former quelqu'un, je lui donne des tutoriels (ou de la doc interne, c'est la même chose, sauf que c'est publique... d'ailleurs, travaillant dans la recherche publique, une bonne partie des docs produits finissent en tutoriels ici )
- je lui donne des livres (ou plus précisément des parties de livres : "tiens, on a implémenté/tu dois implémenter tel algorithme, tu trouveras une description dans tel chapitre... par exemple Numerical Receipe pour les algos classiques)
- je lui indiques les sites internet que je trouvent pertinents/intéressants
- je lui donne des exercices simples ("tiens implémentes moi un petit programme gérant une connexion TCP serveur")
- je cadre/recadre le travail, pour éviter qu'il perde du temps sur de détails ou de mauvais choix (mais je laisse aussi faire ses choix, en demandant de les justifier, et en le laissant se planter si ça lui fait pas perdre non plus 3 mois de boulot)
Bref, je lui explique où trouver les informations (parce que trouver les informations que l'on a besoin fait partie du savoir faire indispensable à toutes profession), à être autonome (parce que je n'ai pas le temps de rester derrière son épaule pour corriger la moindre virgule), à ne pas rester bloqué sur un problème, à apprendre à découper ses problèmes complexes en petits problèmes simples, etc.

Tout ça, ce sont des choses que n'importe qui peut apprendre en autodidacte, de chez lui, avec internet. Ca prend juste un peu plus de temps.

L'intérêt d'avoir un contact direct (ie que la personne travaille avec moi) doit correspondre à moins de 10% du temps de travail (ie le reste du temps, la personne pourrait apprendre seule) et à moins de 1% de "l'expertise" que je lui apporte.


<digression>

OpenGL est une API bien en théorie et dangereuse en pratique

Pour ma culture personnelles (j'utilise que OpenGL), tu peux préciser pourquoi dangeureuse ?
</digression>

[nouknouk]

Amha, le débat pourrait -en théorie- être intéressant ... encore faudrait-il éviter l'approche totalement dichotomique (tout noir ou tout blanc) et les exemples beaucoup trop caricaturaux pour apporter un quelconque intérêt à la discussion.

- Oui, un projet de MMORPG 'comme WoW mais en mieux' lancé par un ou deux ados n'a pour ainsi dire aucune chance d'aboutir à quoi que ce soit.

- Même chose si une équipe d'indépendants cherche à rivaliser avec n'importe quel jeu 'blockbuster' édité par un studio pro qui engouffre habituellement un budget équivalent à celui d'un film.

- Et enfin, oui: ce genre de présentation et de doux rêve revient régulièrement dans les forums.


Ca n'en fait pas pour autant une vision objective et représentative de l'univers du jeu vidéo indépendant. Et ça ne rend pas pour autant vrai l'idée qu'en dehors d'un studio pro il n'est pas possible de faire autre chose qu'un jeu in-intéressant.


Il y a 'jeu' et 'jeu'. Et il existe d'innombrables projets amateurs qui sont parfaitement viables, intéressants et qui le prouvent tous les jours, notamment dans le présent forum et sans pour autant qu'on retombe dans les ultra classiques comme mario ou tetris.

Là est toute la nuance qui fait totalement défaut dans le post initial. Si c'est pour pondre un n-ième sujet qui ne sera de toute façon jamais lu par les fameux 'ados rêveurs' et dont le seul intérêt est peu ou prou d'offrir une tribune à son auteur, l'intérêt est selon moi nul.

D'autant qu'il exite déjà un sujet pour ça ("La vérité sur la conception de jeux amateurs").

My 2 cents.

[LittleWhite]

Je vais tenter d'apporter mon point de vue ...

Les livres:
Comme la dit gbdivers, il existe de tres bon livres. Alors oui, ils ne sont pas en Francais. Et oui les livres francais sont assez bas dans le niveau. Mais les livres anglais, je peux vous dire qu'il y en a des bons, et meme des sites anglais ( http://aigamedev.com/ par exemple).
Les GPU Gems (ce sont des vraies bijou, et je crois qu'ils sont online sur le site de NVidia).
Les Games Programming Gems qui expliquent aussi des choses tres pousses.
Les classiques livres sur le C++ ecrit par Andrei Alexandrescu ou autre Guru du C++ / template et autre.
Donc, si ils existent des livres tres bons, et le decompte sur mes doigts ne permet pas de tous les enumerer.

Ou trouver les derniers techniques ?

On peut trouver les dernieres techniques utiliser dans Rage (ID Software), Starcraft 2 (Blizzard), Crysys 2 (Crytek) ...
Ou ?

GDC ! Games Developers Conference ! Les slides de la GDC sont souvent libre et on peut voir comment implementer les dernieres techniques. Recemment, je regardais une slide de GDC 2007 pour calculer des particules tout en GPU. C'etait tout juste un peu avant la sortie de DirectX 10 et la naissance du GPGPU. Donc c'etait vraiment d'actualite. Preuve -> http://www.2ld.de/gdc2007/Everything...ectsSlides.pdf

Mais ils n'y a pas que GDC. Il y a aussi toute les autres conferences oriente plus ou moins sur le graphismes ou l'IA ou les jeux videos.
Mais il n'y a pas que les conferences. Regardez du cote de Google Scholar, ou un site de papier de recherche (mon universite me donne acces aux derniers papiers de ce genre). Et oui, vous allez trouver les informations, plus ou moins recente sur des techniques et leurs evolutions. Que ce soit du graphisme, du reseau, de l'IA...

Cela ne ressemble plus du tout a un tuto comme l'on voit sur le net, avec un code tout pret sans qu'il n'y ai besoin de reflechir. Et oui, ce genre de papier sont en anglais (j'en ai jamais vu un dans une autres langues.) et en plus, ils sont pour un certain public qui se doit d'avoir deja des connaissances sur ce quoi on parle.
En plus, il ne donne pas vraiment le code, juste la theorie, et son algorithme.

Voila pour ou trouver l'information, car il ne faut pas croire qu'un chercheur, une fois qu'il a trouve son truc, il va le cacher.
(La technique des mega texture developpe par ID Software pour son dernier jeu est aussi disponible ... le jeu n'etant pas sorti ... )

Maintenant, un petit tour sur les universites. Alors oui, cela vend du reve parfois. Pourtant l'universite ou je suis (University of Teesside, je ne veux pas faire specialement de la pub ... ), ils m'ont appris le reseau (pas juste faire un petit chat, mais aussi la prediction des mouvements, la gestion du lag, les techniques pour eviter les tricheurs et j'en passe), l'IA (meme si ce n'etais pas assez oriente jeux videos pour moi (je ne citerai pas toute les techniques, mais on y retrouvera les classiques: Logique flou, algorithme evolutionnaire (la traduction doit etre fausse), Finite State Machine, Search algorithms ....). On m'a aussi appris la 3D (deferred shading, Bump mapping avance). On m'a appris a lire les articles (le truc dont j'ai parle avant). On m'a appris a programmer avec une machine limite (une console). On m'a appris les optimisation (Quad tree , Octree , Frustrum culling et autre). Le memory management, tracing , Systeme de messages.
Certes ce n'est pas les techniques de derniere generation, que l'on voit dans Crysys 2, mais d'apres moi, ce sont des grands calssique qu'il faut mieux connaitre. Apres on utilise des trucs encore plus avance si on a un reel besoin (je ne vais pas mettre en place un algorithme qui m'ajouterai des bugs, si je n'en ai pas besoin).
Donc, moi je pense que les universites peuvent fournir un bon tremplin (surtout que l'univ ou je suis a des liens avec Ubisoft Newcastle , Eutechnix, ...).
L'universite apprend des bases du JV, et surtout ouvre une porte pour aller en entreprise. Alors oui, dans le JV, il est dommage qu'il faille commencer par coder le "Zora et les pokemon rose "chez Ubisoft France sur NDS ... mais une fois que l'on a un peu de vrai experience, on peut monter les echelons.
Par contre les ecoles prives, je n'ai jamais trop eu confiance ... mais bon ... c'est aussi pour autre chose.

Alors oui, les universites donnent des bases, mais il faut aussi savoir que tout demande de la recherche. On apporte pas les solutions sur un plateau d'argent. Nos universites, nous apprenent a reflechir (en theorie) et a faire des recherches dans les differents papiers. Il faut etre motive, sinon on progresse peu, c'est vrai. Il faut savoir y mettre du temps apres les cours, c'est vrai, mais je trouve (je suis passionne) que cela en vaut le jeu.


Oui, sur le forum, on voit les classiques post: Je veux faire un WoW2 avec tout en mieux. Oui, il y a des gens comme cela, et ce n'est pas que sur DVP, et ce n'est pas que pour les Jeux videos (qui n'a pas vu le gars qui veut faire mieux que Linux avec le support des jeux windows ... ou a un algorithme de compression mieux que tout)
Moi je trouve cela drole, et je pense qu'il faut le prendre avec humour. Apres s'etre bien marre dix minutes, on ecrit un message pour expliquer a la personne comment demarre, comment faire pour arriver a un but ultime, ou avoir l'information. Mais il est dommage de le renvoyer directement dans la tome en disant qu'il est debile.


A propos des tutos. Alors oui, il y a plein de tutos pour afficher 3 sprites avec la SDL. Serieusement, sur DVP on a des tutos un peu plus haut niveau. Avec le tuto que j'ai relu sur DVP on apprend a utilise les spritesheet, a faire des collisions.

Il faut commencer par un endroit, et autant commencer par quelque chose de facile. Je vaus vous dire, moi maintenant, la SDL je peux vous en dire des choses dessus (des gestions chaotique de certains point, des fonctions qui ne reagissent pas sur la GP2X, des optimisations a faire, des ...). La doc, elle est toujours avec moi. Donc les tutos "pour noob" et bah c'est tres bien lorsque l'on est noob. Pour la suite, oui c'est moins bien et il faut se pencher sur la doc et du coup on apprend a lire la doc et on voit les problemes en programmant.
Et oui ... mon premier jeu etait un Mastermind console , puis apres, avec une surcouche SDL. Oui mon premier jeu, je ne pourrais pas relire le code sans me suicider (tout dans le main.c). Oui j'ai commence avec des tutos de noob. Mais j'ai appris a lire la doc, j'ai appris a me sortir du petrin moi meme, et la derniere fois que j'ai voulu approcher une technologie (EGL), et bah il y a aucune information a par la specification de Khronos. Donc, il faut savoir qu'il y a 1000 noobs, 100 qui peuvent ecrirent un tuto pour noobs, et 10 qui peuvent aller beaucoup plus loin en lisant la doc. Les tutos pour noobs sont un tremplin, les tutos avances sont une continuite.
Si vous voulez ecrire des tutos avances faites le, nous vous acceuillons les bras ouverts afin de former les 90 personnes a devenir dans la partie "elite".
Mais comme vous l'avez dit, cela prend du temps et vous aimeriez etre paye ... moi aussi je l'aimerai ... et c'est pourquoi on trouve beaucoup moins de tutos.


Note que j'ai oublie: Les livres sont toujours un peu en retard avec les technos, car ils mettent au minimum 2 ans a sortir -> 1 annee pour l'ecriture ; 1 pour la relecture. Pensez y, lorsque vous voyez un livre que vous critiquez comme depasser. Il y a certain processus pour faire de la qualite qui ne sont pas franchissables (nous sommes des humains).

Vous avez peut etre remarque que j'ai ecrit un article (un petit). Vous remarquerai que j'ai ecrit une partie pour savoir lire la documentation officielle sur les extensions OpenGL (qui est vraiment mal presente, non acceuillante mais tres pratique).
Il y a deux processus -> Donner le poisson ou montrer comment le pecher. (je ne connais plus la formule efficace)

Et finalement, on apprendra a coder toujours un jeu hors entreprise, vu qu'une entreprise ne nous embauchera pas "sans experience"

Et aussi, les techniques des jeux pour sauvegarder dans les fichiers (et d'autres techniques que vous citer) ... je ne vois pas en quoi il faut un article car cela fait partie de la programmation generaliste, et que c'est realisable avec un peu de bons sens. Au troisieme essai, on devrait avoir une solution raisonnablement efficace (meme si les deux d'avant fonctionne ).

[gbdivers]

Merci LittleWhite pour les liens

@nouknouk
oui, partie "je vide mon sac pour me défouler" ne sera pas très intéressante. C'est pour cela que je réagissais qu'à la partie "on ne peut pas trouver d'informations intéressantes"

@flasheur
Au final, comme j'ai commencé l'informatique sur des machines équipés de processeurs 8 bits, 32k de RAM et stockage sur cassettes et qu'internet n'existait pas à l'époque, ça va être difficile de me convaincre que les débutants d'aujourd'hui n'ont pas assez de ressources disponibles pour pouvoir apprendre seul. On pouvait déjà apprendre seul il y a 25 ans (difficilement) sans internet, alors maintenant... c'est le pied pour tous geek qui se respecte

[Invité]

Oui, NVidia est une entreprise, pas une oeuvre philanthropique. Et parler des défauts de ses produits n'est pas très efficace sur le plan commerciale. Donc, comme on est des gens intelligents, on sait que :
- s'il y a des bugs, ils seront pas communiqués, sauf défaut majeur qui nécessite le retour massif des produits vendus

Oui, enfin pour les consommateurs ça se comprend. Mais les constructeurs ne te diront jamais à toi (développeur sur leur produits !) ce qu'ils savent, te laissant dans une situation délicate où tu passes un temps fou pour la portabilité à débugger leurs drivers à l'aveugle. Ces infos sont disponibles pour les gros développeurs, mais pas les petits.

Pour ma culture personnelles (j'utilise que OpenGL), tu peux préciser pourquoi dangeureuse ?

Parce que les constructeurs ne communiquent pas sur leur bugs, ne lisent pas tes bugs reports et ne te prennent pas dans leur programme de béta-test si tu ne fais pas du AAA. Après tu as dit que tu fais de la Recherche, ces problèmes ne te concernent pas vraiment.
(EDIT: désolé d'avoir fait diverger le topic)

[gbdivers]

Parce que les constructeurs ne communiquent pas sur leur bugs, ne lisent pas tes bugs reports et ne te prennent pas dans leur programme de béta-test si tu ne fais pas du AAA.

Ok, donc le problème n'est pas spécifique à OpenGL, non ?
Que ce soit Microsoft (pour directx) ou Nvidia ou AMD (pour OpenGL), tu n'auras pas forcement de retours de bugs ni de corrections.
Et puis je suis enregistré chez NVidia comme beta tester pour CUDA/OpenCL. C'est pas très compliqué (juste un formulaire à remplir)

(AAA ? c'est quoi ?)

Après tu as dit que tu fais de la Recherche, ces problèmes ne te concernent pas vraiment.

J'utilise le GPU pour la visualisation de données et le calcul HPC. Donc en terme de besoins (et de problèmes), j'ai les mêmes que la partie GPU d'un jeu. Peut être plus même. A priori.

[LittleWhite]

(Hors sujet ... mais bon)

Les jeux AAA sont les grands block busters du monde video ludique. Les projets qui se comptent avec des millions de dollars. Genre Crysis 2, Battlefield 2 ... et tout autre grosse production du genre.
Par exemple, pour l'Unreal Engine (Epic Games) il sont enregistres aupres de Khronos et participe plus ou moins a l'elaboration d'OpenGL (y a pas qu'eux).

Pour le probleme d'OpenGL c'est que Khronos est beaucoup trop moins stricte que Microsoft sur DirectX.
Les deux ont un banc de tests afin de dire que telles ou telles implementation de la bibliotheques est conforme, mais ceux de Khronos sont beaucoup moins etendus que ceux de DirectX. Du coup, les drivers OpenGL se retrouvent avec beaucoup de bugs (juste des bugs de drivers en theorie ...).
De plus, implemente OpenGL est beaucoup moins interessant que DirectX, sachant que le marche est surtout sur les jeux videos et le support de DirectX (plus Microsoft qui doit surement jouer financierement la dessus )
Du coup, comme pince l'a dit, OpenGL c'est legerement dangereux

EDIT:
Et comme les tests OpenGL sont moins stricte, les differences entre les differentes cartes / constructeurs sont tres frenquentes ce qui pose encore plus probleme pour les petits gens comme nous qui les utilisent ...

[billynirvana]

J'apprends en solo à coder des jeux amateurs hors entreprise et je peux vous dire que je suis assez satisfait de mes résultats!

J'ai réussi à réaliser une quinzaine de petits jeux. Ce sont des remake, rien d'original, tous en 2D. Des technos dépassées mais un jeu qui plait ne nécessite pas forcément d'utiliser les technos les plus récentes....

J'ai commencé à coder en C++ et j'ai même fini à tous les faire passer en JAVA!!

Mon seul projet qui s'est cassé la gueule c'est mon Tower Defense. Mais je n'y renonce pas, je reviendrai dessus coute que coute pour le corriger/finir (même dans 10 ans pas grave!).

J'espère que mon intervention arrivera à vous convaincre qu'il est tout à fait envisageable de coder des jeux intéressants hors entreprise.

[Invité]

J'utilise le GPU pour la visualisation de données et le calcul HPC. Donc en terme de besoins (et de problèmes), j'ai les mêmes que la partie GPU d'un jeu. Peut être plus même. A priori.

Et aucun de tes utilisateurs n'a eu de problèmes ? Parce que mes jeux, des gens ont essayé de les faire tourner sur Intel, sur GeForce 4 même, et il a fallu en downgrader pour nécessiter moins de features. J'ai fini par passer à Javascript pour ne plus faire que ça, et maintenant le software rendering me fait rêver.

Là où c'est spécifique à OpenGL (pour moi) c'est que DirectX impose des tests pour les cartes graphiques compliant, alors qu'avec OpenGL j'ai l'impression qu'il n'y a tout simplement rien (EDIT : ah LittleWhite dis que si plus haut). Windows + OpenGL ne marchent pas bien, et c'est pourtant ce que pas mal de gens choisissent ici...

[gbdivers]

C'est là effectivement que ma propre expérience ne peut plus être transposée aux domaines de jeux vidéos.

Et aucun de tes utilisateurs n'a eu de problèmes ? Parce que mes jeux, des gens ont essayé de les faire tourner sur Intel, sur GeForce 4 même, et il a fallu en downgrader pour nécessiter moins de features. J'ai fini par passer à Javascript pour ne plus faire que ça, et maintenant le software rendering me fait rêver.

En fait, cette activité est relativement récente (2 ans max) et les ordinateurs fournis par le service informatique ne sont pas adapté. Donc obligation d'acheter des ordinateurs dédiés... avec pour conséquence un parc informatique, pour cette activité, très homogène.
Et comme pour le moment, c'est utilisé qu'en interne, le problème ne s'est pas encore posé.

Je note pour plus tard : prendre un stagiaire pour s'occuper du déploiement en externe

Là où c'est spécifique à OpenGL (pour moi) c'est que DirectX impose des tests pour les cartes graphiques compliant, alors qu'avec OpenGL j'ai l'impression qu'il n'y a tout simplement rien (EDIT : ah LittleWhite dis que si plus haut). Windows + OpenGL ne marchent pas bien, et c'est pourtant ce que pas mal de gens choisissent ici...

De même, du fait que le parc informatique (pour le calcul HPC) est homogène, je n'ai pas eu (encore) ces problème. Pour la partie 3D, qui est utilisée sur d'autres ordinateurs, le parc est moins homogène. Mais j'ai alors aussi des PC sous win 2000, win xp, win 7, etc. Donc directx ne sera pas plus simple à utiliser (sauf à diminuer les features, comme tu l'as indiqué)
Et dans ce cas, ce n'est pas les bugs qui sont limitant pour moi mais les capacités du PC tout simplement.

Ça présage rien de bon pour l'avenir ça