Discussion :

[Chubyone]

Eh bien bravo et bon courage cela fait plaisir de voir que ce n'est pas réservé qu'aux "mecs"
Tu verras les JV c'est très passionnant à programmer

Bof, elle est juste chef de projet du jeux amateur qu'ils développent (cf son site perso et le topic ouvert ici meme par mademoiselle), qui semble ma foi...
achtement bien foutu!

So chapeau, c'est pas un role facile à tenir, leader...

(en plus d'être une fille qui aime les jeux vidéo (et les faire), elle semble aimé le fondant au chocolat...Miaou ils ont de la chance les programmeurs...)


Sinon il y a pas mal de filles dans les jeux video et de plus en plus dans l'industrie...

Par exemple...

la productrice d'Assasin's creed!
http://img97.imageshack.us/img97/964...small507bt.jpg
http://www.canardplus.com/actus/5490...elle-et-le-jeu

[humour méchant inside]
Sinon ca parle de fille aussi "dans" les jeux vidéo :
http://cad-comic.com/comics/20070914.jpg
[/humour méchant inside]

[Bakura]

Sympa la productrice d'Assasin's Creed. T'es sur que c'est pas une babe d'Ubi ? :d

[Mat.M]

Bof, elle est juste chef de projet du jeux amateur qu'ils développent

Oui je souhaite bon développement pour le projet.
Simplement je persiste à recommender à cette personne de continuer dans l'informatique de gestion les perspectives sont plus grande.

[ac_wingless]

J'en suis à mon troisième projet lancé dans un contexte typiquement similaire à ce qu'on trouve dans ce forum (toute petite équipe, idée neuve, personnes motivées), avec quelques différences importantes au niveau de la propriété intellectuelle:
- dans mon domaine, les brevets sont très efficaces. Il est donc tout à fait possible de négocier très très bien son projet à la fin, à supposer évidemment que le résultat soit bon. Ce n'est peut-être pas le cas dans le monde du jeu, même quand le résultat est bon.
- il nous est facile d'évaluer la qualité du résultat, ce qui est moins évident dans le domaine du jeu (comment dire qu'un jeu est 12% meilleur qu'un autre?)
Cependant, ces différences concernent plus la valorisation que les difficultés de développement, qui sont vraiment comparables à celle d'un logiciel de taille d'un jeu vidéo.

Je vais me donc permettre de citer quelques une de mes expériences, en espérant que certaines difficultés seront mieux anticipées par les futurs aventuriers.

Les problèmes
- se tromper de business: le développement d'un JV n'a rien à voir avec le travail d'un éditeur! Si on veut exploiter soi même son JV, il faut penser service client, distribution, comptabilité, environnement juridique (licences, lois locales, brevets, etc), diversification du portefeuille de jeux, suivi des technologies, et j'en passe des tas qu'on retrouve dans toutes les entreprises même si elles distribuent des pizzas à domicile. Donc développer un JV, c'est faire un logiciel capable de convaincre un éditeur de vous filer un gros chèque, avec pourquoi pas à la clé des moyens et contrats à long terme pour créer un studio de développement plus pérenne. Ce n'est certainement pas faire une démo, et monter un site sympa sur ses pages perso
- attention à la solidité, la fiabilité, et à la solidarité de l'équipe. Tout le monde n'est pas un cinglé des nuits blanches, certains ont des enfants (si, si), des maisons à rembourser, des problèmes de santé... Tout le monde ne peut pas se passer de salaire pendant 15 mois, etc. Au bout d'un moment, des tensions vont inévitablement apparaître entre les associés. Mon meilleur conseil est de cadrer l'ensemble dès le départ: une petite SARL avec des parts, un contrat entre associés. C'est bien plus léger qu'on le pense au niveau administratif, surtout dans le cas où aucun chiffre d'affaire n'est réalisé. En cas de tension, le problème apparaît bien plus vite, ce qui permet d'encaisser quelques clashes sans remise en cause totale du projet. Aussi, très très important: trouvez un local, et bossez au même endroit. Outre la synergie des discussions, et malgré le risque de perte de temps équivalent au problème de la machine à café dans les entreprises, la contribution de chacun sera totalement visible, en heures de travail. Le plus sûr moyen de créer des tensions est de faire une équipe du genre "moi j'arrive avec les idées, et toi tu les programmes" et de se revoir toutes les semaines pour faire le point... Je ne dis pas que personne ne peut travailler comme ça, mais que quand l'équipe grandit ou bien quand tout le monde ne se connait pas personnellement, un bon cadrage contractuel et un suivi des contributions effectives évitent des frustrations, ou bien des cas ou un mec fait 80% du boulot et n'a que 25% de la propriété.
- syndrome de l'hélicoptère: peu de gens évaluent correctement la complexité de la moindre chose une fois qu'elle passe du brouillon dans le domaine réel. Un hélicoptère est une chose bourrée de tensions et torsions mécaniques, de parties mobiles à vitesse et positions variables, qui restent aisées à lister en quinze minutes, mais auxquelles on ne pense pas en voyant l'oiseau évoluer avec grâce. Eh bien c'est pareil pour un tas de choses dans un logiciel. Donc il faut assez tôt repérer la difficulté réelle des différentes étapes. Pas de "ah ben on va faire un noyau UDP, bien sûr" ou de "on fait les algos durs en C++ et l'interface en C#" et autres "au fur et à mesure que le zorglub monte de niveau, il se transforme en dragon". Ou plutôt: à chaque phrase comme ça, STOP. On s'arrête, et on liste les points durs.
- attention à la gestion de projet. Il faut bien sûr utiliser un outil de suivi, mais un projet créatif va typiquement exploser les outils standards (MS Project et clones) dans ses premières phases. Le suivi de projet n'est viable que quand le projet est vraiment lancé, et pourtant c'est avant le lancement qu'il faut savoir évaluer les phases critiques et les goulots d'étranglement. Pour ma part, je n'ai pas de solution à ce problème, qui est pourtant critique. A chaque fois, je souffre sur ce point, et pourtant je me considère un expert de MS Porject...


Les non-problèmes
- l'argent. Soyons sérieux: si on a comme ambition de faire un jeu video, et qu'on ne peut pas investir le prix d'une voiture, c'est que c'est en fait un hobby, et il faut l'accepter comme tel, à savoir une dépense d'argent dans un loisir amusant. Si par contre on y va pour de vrai, même avec un investissement de seulement ~10k euros sans salaire, l'argent n'est pas un vrai problème. On peut s'acheter des outils puissants (compilation, librairies, authoring), des ordinateurs à la hauteur, et louer un local suffisant.
- le projet mal défini: c'est inévitable, et pas grave si l'équipe est compétente. Il faut considérer les travaux des 3 premiers mois comme du jetable servant à ne pas se tromper sur l'essentiel.

Les atouts
- précisément parce que les projets lourds sont financés à coups de dizaines de millions d'euros, les petites équipes ont une chance. Si on arrive avec quelque chose d'assez propre et innovant chez un "gros", lui sait immédiatement évaluer combien il va économiser en vous achetant le tout, et ça se chiffre pour lui dans des zones très supérieures à ce que ça vous a couté. Donc il faut voir le développement indépendant comme un pari: on mise peu, on a toutes les chances de se planter, mais si ça marche, c'est le jackpot. Je parle en dizaines d'années de salaire, facile. Sans parler d'une référence qui rend les nouveaux projets infiniment plus faciles!
- intrinsèquement on a besoin d'une bien moins bonne qualité (et donc coût) de développement que les gros: comme la valorisation ne se fait que par un gros qui va tout refaire de toute façon, on peut court-circuiter un tas de choses comme la résistance aux hackers (MMOs), la performance fine des serveurs en ligne, la prise en compte des derniers shaders, le support multilingue, etc.
- en cas d'échec, on a surtout perdu du temps, mais peu d'argent au final. A comparer avec beaucoup d'autres domaines ou démarrer un projet coûte énormément plus.

Conclusion: ça vaut la peine d'y aller, si on a bien réalisé dans sa tête qu'on a dépassé le stade du hobby. Par contre, il faut toujours garder à l'esprit la forte possibilité d'échec, donc assurer une porte de sortie décente pour ne pas polluer définitivement le CV et ne pas planter le portefeuille de plus qu'une simple péripétie de la vie (ne LEVEZ pas d'argent pour votre premier projet... ce sera bien plus facile et moins risqué pour votre deuxième, si le premier est réussi).

[bob25]

merci pour ce post ac_wingless

ça résume bien les problèmes de lancement d'un premier projet...

[scepticimus]

Bonjour toutes et tous,

J'ai parcouru cette discussion jusqu'au bout et je me suis posé une question: mais comment faisaient les créateurs de jeux du temps des années 80 ... lorsqu'ils étaient seuls face à leur écran pour (pratiquement) tout faire: graphisme, son, code, musique, ... sans pour autant réaliser le jeu du siècle ! Un petit Robbbot, Crafton et Xunk, Mercenary, Tomahawk .... (euh, vous avez surement reconnu la bécane dont je parle )

[LLB]

Voilà qui pourrait t'intéresser : le Making of d'Another world.

Ce qu'il faut voir aussi, c'est que tout était plus limité à l'époque. La musique ou les graphismes étaient assez liés à la programmation, à cause des nombreuses contraintes (ils n'utilisaient pas de mp3 ^^), le programmeur pouvait alors quasiment tout faire.

Maintenant, pour une musique de qualité, il faut un vrai compositeur ; pareil pour les graphismes ou les modélisations. De plus, de part l'augmentation des capacités de stockage, les jeux sont plus complets. Il devient alors dur pour une personne de tout faire (1Mo, ça peut se remplir par une personne...).

[Invité]

Je regarderais la vidéo ce soir et éditerais en fonction de son contenu.

Par contre je ne suis pas du tout d'accord avec toi LLB (désolé).

Tu compares ce qui n'est pas comparable. Effectivement les jeux anciens semblent au regard des technologies actuelles plus simples; mais en fait c'est totalement faux parce qu'il faut replacer ça dans le contexte de l'époque.

Comparons ce qui est comparable:

Programmation orientée jeux vidéo :

Aujourd'hui :
- Présence de moteur graphiques/moteurs de jeux tout fait
- Capacité des machines exprimées en Ghz et multicoeurs pour les processeurs et en Go pour les capacités mémoire
- Présence de langages de haut niveau de plus en plus proche du langage humain
- Présence de système de base de données
- Présence de méthodes d'analyses performantes
- Débuggeurs graphiques
- Théories IA relativement évoluées

Dans le début des années 80:

- Obligation de se battre avec les interruptions des cartes graphiques à la mimine
- Capacité des machines exprimées en Hertz, pas de multiprocessus car OS balbutiants, capacités exprimé en Ko pour la mémoire et supports de stockages de 256~512 Ko max (les CD ne tournaient que sur les platines audio ou alors fallait être trèèèès riche).
- Choix de programmation : soit le C, soit l'assembleur (assembleur souvent préféré car moins gourmand en ressources processeur)
- Bases de données balbutiantes par fichiers
- Pas de méthodes d'analyse
- Pas de programmation Objet
- Pas d'études sur l'IA à proprement parler
- Pas de systèmes dominants (8086 vs CMOS d'apple vs ...)

Résultat : ce que tu fais en 1 semaine maintenant avec un bon moteur il fallait entre 3 et 6 mois et des sacrés connaissances en maths...


Graphismes:

Aujourd'hui :
- outils de modélisation et d'animation faciles d'utilisation
- outils de texturing et d'infographie faciles d'utilisation

Hier:
- pas de 3D
- outils de dessins balbutiant et pas de format de compression graphique
- coupes sombres dûes aux capacités limitées des machines
- y avait déjà des graphistes spécialisés à l'époque!!

Sons:

Aujourd'hui:
- super cartes sons méga top deluxe qui font limites papa maman
- outils de mixages et d'acquisitions


Hier:
- pas de véritables cartes sons avant un moment
- obligation de bidouiller à partir d'un synthé pour ensuite convertir les données en interruptions compatibles avec la machine
- Sound Blaster vs Hercule vs Yamaha vs...
- Les musicos savaient très bien se démerder et étaient entièrement spécialisés dans la musique orientée JV (akd se rapelle un reportage sur le sujet sur No life tv)!



Tout ça pour dire: nous sommes de sacrés assistés aujourd'hui.
Les seuls métiers qui sont apparus par la suite sont:
Les GD, les level designer, les infos 3D
tout le reste existant déjà.

Je pense que la vraie différence était au niveau économique et public:
- public plus restreint mais plus ouvert vers la nouveauté,
- à l'époque les boites informatiques commençaient dans un garage et il y avait une faible concurrence,
- ça se faisait entre potes IRL,
- le challenge technologique était la seule raison, l'agent passait ensuite,
- il suffisait de se faire connaitre dans sa région et de laisser faire le bouche à oreille.


Aujourd'hui, le public est éduqué et ronchon, les graphismes ne veulent plus bosser pour des nefles (la faute aux abus de certaines boites), la pub compte énormément et il faut produire le plus possible pour obtenir le plus vite possible un retour sur investissement et être déjà connu de longue date ça aide

D'où la différence.

[deadalnix]

Bien que la contrainte technique etait bien plus forte il y a quelques temps (obligé de declencher des IT a la "main", d'aller traffiquer de l'assembleur, etc . . .) faire un jeu n'est pas plus facile de nos jours.

En effet, un joueur veux de beau graphismes, un belle bande son, un moteur chiadé, etc . . .

Alors, on est des assistés, oui, mais on en demande aussi beaucoups plus !

[bob25]

il ya quand même quelques vieux principes des jeux des années 80 qui sont toujours appliqués

dans le making of d'another world le mec explique qu'il a d'un côté développé un moteur graphique vecto en assembleur ce qui a permis de faire tenir un jeu graphiquement très riche sur les 3 octets de ram des machines de l'epoque.
et pour abolir la redondance aussi au niveau gameplay, il a développé d'un autre côté un "langage" de script pour faire une règle du jeu qui changeait à chaque écran

il était en avance sur son temps...


et ce qui n'a pas non plus changé en 20 ans ce sont les base math et algo elementaires - qui restent toujours la partie la plus ardue des dev
un polygone s'encode toujours avec des vecteurs et des droites et des plans, on doit toujours se taper des calculs de projection, intersection, clipping, rastering, des parcours de grilles dans tous les sens, optimiser l'affichage...

ce qui a changé c'est que c'est plus compliqué (3eme dimension, données à traiter beaucoup plus complexes et lourdes) on commence un dev par traduire en code un bouquin de maths entier
à l'epoque le travail consistait surtout à tirer les perf optimales de la machine, aujourd'hui il y a des moteurs son/image qui s'en chargent

[scepticimus]

Il serait interessant d'avoir une idée en jour/homme par exemple du développement de tel ou tel jeux (en commençant avec les années 80 ) pour voir l'évolution, freeware compris, non ? Après tout, dans un projet, c'est normalement la seule donnée qu'on donne au chef de projet: vous aurez 1000 jours pour faire ce simulateur de F1, débrouillez-vous !
Il y a un petit jeu que j'aime beaucoup (car on peut ne pas y passer des heures, juste quelques minutes de détente): Pocket Tank (http://www.blitwise.com/). Fait par une personne en un an aux heures creuses (entendez par là hors boulot ).

[bob25]

another world a pris 1 an et demi de travail à plein temps je crois

aujourd'hui ça doit pouvoir se faire en 1 semaine avec les super moteurs d'affichage qui font tout

mais à l'époque, afficher 3 polygones en assembleur était un sacré défi... d'ailleurs ce jeu ramait pas mal

[Invité]

J'aimerais profiter de ce topic revival pour rebondir sur quelques points soulevés par bob25 précédement; le but étant de réfléchir à la différence entre ce qui se faisait avant et de nos jours.

la logique où l'on démarre à l'envers: on commence d'abord par imaginer un scénario de règle du jeu, et ensuite seulement on choisit les bons outils, les bons algo, etc, elle est possible aujourd'hui car la diversité des outils laissent une grande liberté.

dans le temps on pouvait pas faire ça car on était trop limité par des questions de performances et puis il fallait inventer et chercher pas mal de choses, on inventait les gameplays à partir de ce qu'on arrivait à faire avec les machines

Deux points à soulever à ce niveau:

1) pourquoi des méthodes d'analyses ont elles été mises en place dans le milieu de l'informatique de gestion justement pour permettre de partir de ce que doit faire l'application afin d'en définir sa structure?

Je pense que justement le fait de partir sur du code sans définir les règles et savoir ce que doit faire le jeu est une grosse erreur de débutant conduisant irrémédiablement à "casser du code".

Le seul soucis aujourd'hui c'est que les pros qui ont développés les méthodes adéquates pour y arriver facilement ne transmettent pas ces méthodes (tout comme pour le game design on dirait que c'est un domaine ultra sensible secret défense et je trouve ça totalement idiot).

En gros on est resté sur l'état d'esprit des années 80 : je fais un truc qui marche et je laisse le ptit voisin se démerder pour comprendre comment j'ai fait en lui en lachant juste assez pour qu'il s'accroche au sujet si ça lui plait.

2) Dire qu'on inventait les gameplay à partir de ce qui existait est faux. Il faudrait que je vous retrouve l'interview d'un certain "game designer" dessinateur de talent de formation qui a eu l'idée d'un jeu "révolutionnaire" sur Z80.

Pour résumer en gros le gars avait lancé le projet sur Z80 et après 2 ans d'arrachage de cheveux de son pote programmeur a essayer d'optimiser dans tout les sens, ils avaient décidés d'attendre que les machines soient plus performante.

Au final le jeu est sorti en 1998-1999 et il s'agissait d'un bon gros jeu d'aventure action en 3D magnifique graphique mais à la limite d'être injouable (car graphismes trop lourd pour l'époque).

Donc je pense plutot que comme aujourd'hui celui chargé du Game Design tripait et les marmottes codeuses derrière se battaient pour que ça soit faisable quitte à couper des bouts.

mais maintenant on peut. alors bon c'est super on voit apparaitre des jeux de plus en plus scénarisés MAIS... (il y a un mais ça serait trop beau sinon) il faut déjà une solide expérience avant de travailler comme ça car pour choisir les bons outils il faut les avoir déjà utilisé avant séparément.

Ne jamais confondre scénario et game design. L'expérience du game design se forge en étudiant les mécaniques de jeu existantes.

L'expérience scénaristique c'est de l'imagination et un français correct.

On peut faire un jeu nul scénaristiquement et qui est une merveille en terme de game design (je pense par exemple à un RPG sur PSone : Legend of Legaia. Une merde scénaristiquement et graphiquement mais avec un gameplay a se damner pour l'époque).

donc cette methode de travail n'est pas pour les debutants, c'est reservé a des designer et des codeurs qui ont de bonnes années d'experience derriere eux. la société id software (je vous conseille de vous interesser a leur travail ce sont eux qui ont cree une bonne part des bases des jeux 3d) a passé des années à travailer sur des moteurs de shoot stupides sans scénario et avec toujours les mêmes règles basiques. leur premier moteur qui a permis d'introduire la notion de scénario et de généricité (je vous laisse deviner lequel) n'a pas ete leur premier projet. pareil pour Epic ils en ont fait des pacman avant de creer l'unreal engine...


il y aurait tellement d'autres choses à dire pour ceux qui débutent car il y a plein de pièges à eviter de de trucs à savoir...

On ne peut jamais se comparer à 20 ans d'expérience quand on est débutant.
Mais on peut toujours essayer de faire mieux que ce qui a pu être fait autrefois tant qu'on sait rester raisonnable et qu'on est capable de faire des coupes claires dans ses ambitions.

peut-etre que ce par quoi tout débutant devrait commencer c'est par développer une petit lib d'affichage mathematique pour bien tracer et débugger tous les calculs, un truc simple qui affiche des lignes, des points, des vecteurs, des cases, des polygones, etc... c'est à la portée de tous et ça permet de s'assurer qu'on maitrise les concept mathematique avant de les utiliser

Je pense que là il est faux de raisonner comme il y a 20 ans.

Aujourd'hui la spécialisation dans un domaine est obligatoire en informatique.
Commencer par faire un moteur d'affichage quand on veut faire un jeu n'est pas forcément la bonne méthode.

C'est une méthode parmi d'autres mais il est aussi possible de choisir de ne pas forcément réinventer la roue et de partir de moteur d'affichage ou de moteur de jeu existants pour gagner du temps et/ou se spécialiser sur le making pure du jeu et non le making des supports techniques de production du jeu.

On le voit bien avec le succès d'outils comme rpgmaker, gamemaker etc. ou de langages spécialisés (darkbasic...)

Après quand tu parles des mods de jeu justement sur ceux de CS, il y a quand même une grosse différence entre CS, Half Life et Natural Selection par exemple au niveau game design. On est loin des moteurs des années 90 comme par exemple celui de Lucas Art (a oublié le nom) qui faisait que tout les jeux étaient basés sur les même principes de jouabilités.

Et plus loin dans l'industrie il est de plus en plus courant d'acheter des moteurs de jeu et de faire sa tambouille. Les moteurs pros sont juste suffisement souples pour qu'on ne trouve pas de ressemblances.

[bob25]

On ne peut jamais se comparer à 20 ans d'expérience quand on est débutant.
Mais on peut toujours essayer de faire mieux que ce qui a pu être fait autrefois tant qu'on sait rester raisonnable et qu'on est capable de faire des coupes claires dans ses ambitions.

je ne sais pas... il ya tellement de choses à savoir (côté dev) que je conseillerais plutôt à un débutant d'apprendre à appliquer les vieux trucs classiques avant de vouloir innover

c'est la grande différence avec l'epoque... les débutants pouvaient faire de la recherche parce que tout était à faire, faire bouger trois pixels sur un atari était une incroyable aventure, la moitié des jeux sur micro étaient plein de bugs, ça marchait quand ça voulait, c'était des expériences pour voir ce que les machines pouvaient faire

maintenant tout ça est réglé, les débutants doivent surtout étudier ce qui a été trouvé plutôt que chercher

à l'epoque c'était un vrai boulot de spécialiste des machines
aujourd'hui toute la partie hardware est sous-traitée par des sociétés qui ne font pas specialement de jeu vidéo

les problèmes dont on s'occupe désormais c'est plutôt les maths et la logique que la programmation pure et dure, ces problemes ont pris sur le pas sur les vieilles questions du compte-goutte de hertz, bits et pixels
à l'époque il fallait beaucoup tester, on faisait du travail sur la machine avant de noter les observations sur le papier,
aujourd'hui il faut surtout beaucoup se documenter et c'est l'inverse on écrit beaucoup sur papier avant de taper du code

[Invité]

Je pense que ta remarque n'est pas dénuée d'intéret.

De là je me demande si on ne devrait pas distinguer 3 profils de programmeurs orientés jeux vidéo:

-> Ceux qui programment les moteurs "bas niveau" pour l'affichage (2D/3D) et le son avec une connaissance mathématique pointue et l'obligation d'avoir des connaissances techniques élevées.

-> Ceux qui programment les moteurs de jeu et qui doivent donc posséder des capacités d'analyse et de généralisations, des connaissances en graphes et en IA.

-> Ceux qui codent les jeux vidéos qui doivent être capable de mettre au point les mécaniques de jeu au plus près des règles définies par le GD en le faisant rentrer dans les petites cases prévues à cette effet par le moteur de jeu.

Ces trois profils se distinguent très nettement dans l'industrie et un peu moins en tant qu'amateurs mais on en est déjà là avec certains outils.

[deadalnix]

Si ca n'est que je dispatcherais l'IA entre les differents niveaux, on en est la.

En effet, le codeur bas niveau doit pondre tout un tas de structures de données super optimisées pour l'IA. Ensuite, une bonne ia doit etre adaptée au gameplay.

J'aurais nomé ces personnes differement :

1/ le technicien

2/ le mathematicien/algoritmicien

3/ Le codeur qui utilise les outils des deux precedents pour en faire un jeu.

[bafman]

-> Ceux qui programment les moteurs "bas niveau" pour l'affichage (2D/3D) et le son avec une connaissance mathématique pointue et l'obligation d'avoir des connaissances techniques élevées.

ca s'appel, dans le petit monde du jeu video, un developpeur 3D

-> Ceux qui programment les moteurs de jeu et qui doivent donc posséder des capacités d'analyse et de généralisations, des connaissances en graphes et en IA.

celui la s'appel judicieusement developpeur IA

-> Ceux qui codent les jeux vidéos qui doivent être capable de mettre au point les mécaniques de jeu au plus près des règles définies par le GD en le faisant rentrer dans les petites cases prévues à cette effet par le moteur de jeu.

et le dernier, le developpeur gameplay...

donc effectivement, il existe globalement plusieurs categorie de developpeurs, et on retrouve cette segmentation dans toutes les boites un minimum organisée et de taille suffisante pour imposer ca.
bien entendu, dans une petite boite, on a généralement des touche à tout, mais dès que la boite grossie, si elle ne spécialise pas ses emplyé un minimum, elle va directe dans le mur...

[scepticimus]

Je pose ma question après ces quelques réponses:
Pour une seule personne (qui ne sera pas moi ), connaissant un minimum de code C++ (genre faire une application Windows Forms, voire savoir créer un fenêtre DirectX avec un cube 3D qui fait pouet pouet quand il tourne par exemple), combien faut-il de temps en moyenne pour commencer à maîtriser un moteur 3D genre Ogre, interfacé avec un moteur physique free (là, j'ai pas d'exemple en tête) et des sons/musiques basiques piquées dans les biblio gratuites (pas très jolis mais au moins, ça fonctionne et pas de redevance ) ? Ah oui j'oublais, les textures et modèles 3D sont déjà fournis (là se serait plus moi )

PS: sur Win uniquement, désolé !

[Invité]

D'après ce qu'on m'a laissé entendre sur le sujet Ogre + ODE : 3 à 6 mois pour maitriser l'ensemble.

Donc je dirais qu'en 6-8 mois tu dois pouvoir faire à peu près ce que tu veux.

Par contre le droit d'auteur s'applique aussi bien sur les images que le son si l'auteur n'en a pas totalement cédé les droits (cad si c'est pas du free 100% certifié conforme).

Y a beaucoup de musicos intéressés par les jeux vidéo. A mon avis vous pourriez plutot taper par là ça sera bien plus intéressant.

[bob25]

savoir créer un fenêtre DirectX avec un cube 3D qui fait pouet pouet quand il tourne par exemple

il y a encore du boulot

même une fois que tu maitrises un moteur 3d et un moteur physique il reste encore le plus dur à faire: développer le moteur du jeu

ce qui peut prendre plusieurs mois
surtout si tu n'as jamais codé de jeux, accroche-toi...

pour un premier jeu je ne conseille pas la 3d.
les jeux 3d utilisent exactement les mêmes principes que la 2d (visibilité-activations-collisions) mais avec des calculs cent fois plus compliqués