Discussion :

[r043v]

salut

bon je vais me faire jeter n etant pas de vos avis

pour moi un jeux se fait en bas nivau, exit directx et autre lib
commence en c ou cpp a la limite, aprend l asm si possible
code sur de petite plateformes, gp32/ti89 ect ..
avec un pc boufant des milliard d instructions secondes, comment veut tu apprendre a optimiser ?

uml ne te servira a rien, un papier et un crayon suffise et tu apprendra a t en passer ac le temps

commence SIMPLE, par de la 2d en apprenant a tapper direct ds l ecran,
dabord un pixel au millieu de l ecran, ensuite tes propres routines de blit

ne vise pas trop haut au debut, un pong c deja bien

une fois que tu aurra reinvente la roue plusieurs fois, tu pourra passer au niveau superieur

apres au niveau du nombre de personne ds une team tout depend du projet
en tout cas, pour un projet amateur il vaut mieux avoir un graphiste
mais vu que tu as reinvente la roue, filler un ecran ac de belle couleurs c pas coñplique donc le graphiste n est pas forcement necessaire
de plus tu peut aussi ripper..
si tu as un musicien c un plus mais pas necessaire non plus, il y a des dizaines de miller de mod xm s3m ect dispo sur le net .. chaque fichier comporte pleins de sample donc niveau resources tu as ce qu il te faut

ripper c mal ?
bah il te suffit de rajoutter les nom des ayant droit a ton readMe
a la limite envois leur un mail pour demander, c tres rare qu ils refusent

et ne te decourage pas, procede par etapes, chaque projet te fera avancer un peu plus .. jusqu au jour ou tu pourra coder nimporte quoi :-)

[helmis]

Pensez à Delphi

http://www.developpez.net/forums/showthread.php?t=83075

[Sixissor]

Pour les bases, je dirais avoir un bon voir très bon niveau en algorithmique, connaître OpenGL et/ou DirectX, maîtriser le C++, avoir des bases solides en Maths.
Evidemment, il faut aussi connaître les techniques avancées: ça touche beaucoup aux Mathématiques, d'où avoir des bases solides, et parfois aussi à la Physique, donc à ne pas négliger.

Et le plus important: la volonté et la motivation
Car il n'est pas rare de travailler trop de temps sur un projet

[ash.ice.loky]

Je dirais simplement rester les pieds sur terre.

En QBasic tu peux faire des trucs sympa (pong, tetris, casse briques, ...), de meme qu'en C++ "tu" peux faire un FPS derniere generation.

C++ est un langage comme un autre, J'ai realiser des trucs sympa en JAVA comme en Python.

J'avais commencer egalement en Ruby/OpenGL qui est vraiment un tres bon langage.

Je dirais donc simplement, Choisir un langage a sa convenance et pianoter, pianoter, pianoter, ...

Le reste viendras tout seul.

[Invité]

Comme dit neo, dans le domaine de la 3D et de la plupart des JV, c'est le C/C++.
Le Java commence à s'ouvrir aux jeux vidéos, mais c'est pas encore ça pour plusieurs raisons :
- Pas de plein écran en java.
- Ca rame, donc pour afficher de la 3D temps réel un minimum complexe il faut une bonne machine.
- Pour les jeux Java que j'ai testé, les entrées (clavier, souris) sont bien moins réactives qu'en C++; mais ça vient peut-être des jeux et non de la machine virtuelle Java.
Par contre, le Java possède un grand avantage: c'est du pur objet et sans pointeurs donc si la conception est bonne la probabilité de trouver des bogues est moindre qu'en C++. Mais bon, ça dépends beaucoup des développeurs

Bonjour

Va donc voir jake 2! Le java ne rame pas plus que le C++ quand on programme bien. Utiliser java avec JOGL peut donner des résultats aussi bons voire légèrement meilleurs que C++. Pour les optimisations mémoire, il faut penser à utiliser les References, les pools d'objets et "forcer" quand cela est opportun le garbage collector à passer. Tu peux aussi modifier la taille initiale et finale du tas. Par conséquent, il n'est pas nécessaire d'avoir une bonne machine mais il faut vraiment bien programmer.

[Dev-FX]

Bonjour ,

Voici les étapes essentielles pour bien débuter dans le monde des JV :

1) Avoir une maîtrise complète du langage C .
2) Apprendre a utiliser la librairie SDL , orienté JV , utilisable en langage C , et permet de faire de très bon jeux même en réseau ,
mais reste a vous cassez la tête avec l'IA qui est un module a part et la gestion des collisions .
3) A ce stade , le langage C++ devient une étape obligatoire ,vous devez avoir pour lui aussi une maîtrise complète .
4) Ici , des notions mathématiques avancé sont obligatoires.....
5) Apprendre OpenGL , une librairie vraiment intéressante pour découvrir la 3D (c'est a base de celle-ci qu'on peux créer des moteurs 3D comme Ogre ou même créer le votre).
6) C'est le temps d'apprendre DirectX , l'API des jeux 3D par excellence , aussi trop complexe pour les débutants .
7) Apprendre le C# , c'est un copier/coller du Java , tellement puissant que tu peut l'utiliser avec DirectX , que du bonheur !!
8) Apres avoir fait ce tour dans le monde de JV , ce n'est que ici que tu peut utiliser des logiciels comme :

* Blitz3D .
* 3D Game Creator .
* Game Maker.

Mais rien ne t'empêche de coder ton propre moteur 3D , mais la il faut vraiment une vraie équipe motivé pour coder un jeu 3D ,
rien que pour passer voici une liste non exhaustive des éléments essentiels pour coder un jeu 3D :

* Gestion de l'IA ( intelligence Artificielle ) : Le coeur de jeu .
* Gestion des collisions : Le réalisme du jeu.
* Le Game Play évolué : Le charme du jeu.
* La gestion des effets sonores .....
etc .....
je vais pas m'arrêter d'écrire.... faudra que j'écrive un tuto dessus . lol


Merci .

[Cheps]

Tout le monde parle de 3D, mais il ne faut pas oublier que beaucoup de jeux peuvent être très bons en 2D. La 3D ça en jette certe plus, mais ça rajoute pas mal de complications et de contraintes. Un bon jeu de plate-forme, RTS ou RPG en 2D ça peut le faire très bien.

Sinon je te conseil très fortement d'utiliser un langage orienté objet, c'est simplement ce qui se fait le mieux pour le côté conception du logiciel. Oublie donc tout de suite l'assembleur ou le C, utilise plutôt C++ (mon préféré ), Java ou C# (il y en a d'autres).

Ne te soucie pas trop des problèmes de performances du langage, une nouvelle fois à part pour les jeux 3D qui peuvent se montrer gourmands(et encore, souvent ils ne sont pas bien optimisés...), il faut pas oublier qu'on ne programme plus pour des Pentium 90 avec 16Mo de RAM.

Bref, mon conseil c'est d'apprendre un langage orienté objet, j'insiste beaucoup sur ça, mais programmer en procédural ou autre ça peut vite virer en spaghetti

[Mindiell]

Je plussoie Cheps : Pourquoi toujours de la 3D ?

Les meilleurs ventes PC :
[3D Simulation] The Sims (16 million)
[2D RTS] StarCraft (9.5 million, includes StarCraft: Brood War)
[3D FPS] Half-Life (8 million)
[3D MMORPG] World of Warcraft (7.5 million customers worldwide)
[2D ] Myst (6 million)
[2D Simulation] The Sims 2 (4.5 million)
[2D RPG] The Elder Scrolls III: Morrowind (4 million, including Xbox release)
[2D Simulation] RollerCoaster Tycoon (4 million for the original in North America alone)
[3D FPS] Half-Life 2 (4 million)
[2D RTS] Populous (4 million)

Le top pour chaque console :
[2D plateforme] Super Mario Bros. (40.23 million)
[2D plateforme] Super Mario World (17 million)
[3D Plateforme] Super Mario 64 (11 million)
[2D Combat] Super Smash Bros. Melee (6 million)
[2D Reflexion] Tetris (30 million)
[2D RPG] Pokémon Ruby and Sapphire (3.86 million in US only, Pokémon Ruby: 2.5 million in US only)
{2D Reflexion] Brain Age: Train Your Brain in Minutes a Day! (8.51 million)
[2D Plateforme] Sonic the Hedgehog 2 (6 million)
[2D Combat] Virtua Fighter 2 (1.70 million)
[2D Plateforme] Sonic Adventure (2.5 million)
[3D Simulation] Gran Turismo (10.5 million)
[3D Simulation] Grand Theft Auto: Vice City (13 million)
[3D FPS] Halo 2 (8 million)
[3D FPS] Gears of War (2 million)

Et enfin le top 10 console de tous les temps, toutes consoles ocnfondues :
Super Mario Bros. 3 (NES - 18 million)
Super Mario Land (Game Boy - 14 million)
Grand Theft Auto: Vice City (PS2 - 13 million)
Grand Theft Auto: San Andreas (PS2 - 12 million)(As of 2005)
Super Mario 64 (N64 - 11 million)
Gran Turismo 3: A-Spec (PS2 - 11 million)
Grand Theft Auto III (PS2 - 11 million)
Gran Turismo (PS1 - 10.5 million)
Super Mario Bros. 2 (NES - 10 million)
Gran Turismo 2 (PS1 - 9.34 million)

Alors maintenant, redites moi que la 3D c'est mieux ?

PS : j'ai fait ca vite, il se peut qu'il y ait quelques erreurs

[Skyounet]

PS : j'ai fait ca vite, il se peut qu'il y ait quelques erreurs

Ben oui t'a oublié Final Fantasy VII vendu a plus de 10 millions d'exemplaires.

Non mais quand même.

(Y'a aussi FFX dans le top 30 lui ).

Pis tant que j'y suis.

http://athena-unlimited.aceboard.fr/...tous-temps.htm

On voit bien que dans les "meilleurs jeu de tous les temps" y'en a un paquet en 2D.

[Mindiell]

Les infos ont été récupérées depuis cette page de wikipedia : http://en.wikipedia.org/wiki/List_of...nd_video_games

Et FF 7 est en deuxième position sur Playstation : Final Fantasy VII (8.6 million)
donc je ne l'ai pas oublié
Par contre les chiffres ne sont pas forcément tout à fait à jour, c'était surtout pour donner une idée.

[blastou]

La 3D permet de faire plus que la 2D voilà pourquoi. Tu rajoutes une dimension. L'implémentation en 3D peut être tout à fait superflux (dans un tétris par exemple) mais qui peut le plus peut le moins.

Sinon il y a quand même quelques erreures d'apréciations au niveau des jeux :

[2D Simulation] The Sims 2 (4.5 million)
[2D RPG] The Elder Scrolls III: Morrowind (4 million, including Xbox release)
[2D Simulation] RollerCoaster Tycoon (4 million for the original in North America alone)

Les trois sont en 3D. Bref dans la ludothèque PC tu trouves que les vieux succès en 2D, pas les nouveaux. Pour la console c'est la même chose, la tendance est à la 3D. Les RPG en soit ils ne gagnent rien a passer en 3D (puisque les RPG console restent linéaires) pourtant ils le deviennent tous... Bref la liste que tu nous présentes n'est pas réellement à l'avantage de la 2D. Les seuls jeux en 2D passe en 3D : Starcraft => Warcraft III, populous => à la base c'est de la 3D isométrique quand même (fausse 3D certes) mais la suite sans succès était en 3D, Myst => 3D précalculé, je ne sais pas quel type de moteur ils utilisent.

[Mindiell]

Woups en effet, erreur d'appréciation pour ceux-là.

Je tentais simplement de faire comprendre à tous ceux qui ne parlent que de 3D sur 4 pages que la 2D vaut son pesant d'or quand il s'agit d'apprendre et qu'elle est loin d'être délaissée même de nos jours.

[Cheps]

Il y a aussi des jeux en 2D mais qui donnent une illusion de 3D, ainsi que des jeux en 3D mais où on a plus l'impression que c'est de la 2D. Un jeu 3D est-il un jeu construit en 3D, ou un jeu avec un résultat visuel en 3D

[darkvadr]

Salut, je suis nouveau, et je développe un jeu...
Si ca peut aider voici un peu le synoptique de ce que je dev.

1) Le jeu...
Il faut etre raisonnable, notre premier projet était un mega MMORPG ala Anarchy online. ABORTED

Equipe trop reduite, extremment chronophage, impossible de rivaliser avec le commercial, toujours en retard, bref...

Maintenant parlons du projet qui avance raisonnablement.

Equipe:
Moi, coder et musicien
Mon cousin, graphiste, scenariste et zicos.

Petite equipe DONC petit jeu... Et alors? Commencer petit c'est une très bonne chose.

Le graphiste doit avoir une parfaite maitrise (c'est le cas) d'un packs de logiciels (3Dsmax, photoshop, etc..)

Il lui faut aussi comprendre la difference entre du rendering realiste ala je suis un mega artiste et les limitations imposées par du rendering real time.

Le codeur doit comprendre un minimum ce que fait le graphiste... Qu'est ce qu'une scene, un eclairage, un referentiel 3D, une texture.

UN POINT TRES IMPORTANT: La communication entre le graphiste et le codeur.

Mauvais exemple: "le graphiste: Euuuh ton jeu tourne à 5 FPS
le codeur: Ben tu me livres tes modeles avec un polycount de 20.000 kes tu esperes
Le Graphiste: Ben je suis désolé mais sinon c'est moche alors on ne touche pas a mon oeuvre, t'as qu'a optimiser le code
Le codeur: va te faire f... mon code est clean mais j'ai pas une carte graphique à watt milliards d'euros"

etc...


Bon exemple: "le graphiste: Euuuh ton jeu tourne à 5 FPS
le codeur: Tes modeles sont un peu lourd, excellent comme artwork, mais difficile a utiliser realtime. J'essaye d'optimiser le code mais j'aurais des difficultés a atteindre les performance d'un moteur comme DOOMIII tout seul.
C'est trop de travail
Le Graphiste: Qu'est ce que je peux faire?
Le codeur: J'ai testé un reducteur de polygones, en divisant le polycount par 4 on obtient un resultat pas si mauvais... Seulement je perds les coordonnées d'uv mapping et les datas du skeletton
Le Graphiste: Arrrg mon beau modèle, ok je te fais plusieur modeles du plus leger au plus lourd, parce que j'aimerais bien qu'un gamer avec une carte à watt milliards puisse profiter de mon geni artistique
Le codeur: No problemo, j'implemente une routine qui choisit le modele a exploiter en fonction des perfs"

Bon pour le language, nous avons choisit Delphi7
la lib Gfx est la dernier version CVS de glscene... Compromis satisfaisant entre RAD et performance POUR CE JEU (c'est à voire en fonction du jeu)

Le rendu du jeu est en 3D

Mais la logique interne est dans une sorte d '"espace binaire" en 2D.

La logique du jeu est découplée de la visulisation. Autrement dit, le jeu tourne meme sans rendering... Si tu sais lire la maastricht dans le code, tu peux voire des bonhommes se deplacer en memoire et rencontrer ou non des bits qui declenchent ou non des evennements (genre boom t'es mort)

Pour cela Delphi connait les types enumérés qui permettent d'utiliser un mask de 256 bits. C'est pratique et assez performant...

On a donc des trucs du genre if piege in espace_binaire [i,j] then boom;

Toujours construire les outils d'abord et se servire très largement de la POO.
Exemple faire l'editeur de level en premier.

Un objet Tlevel est indispensable, son code pourra etre reexploité dans le jeu.

Level.loadfromfile est utile a la fois dans l'editeur et dans le jeu.

generaliser...

Le scenario? Nous on est sur du gameplay a l'ancienne entre boulder dash et spy vs spy.

Voila, c'est possible en restant modeste.

Si tu te lances seul dans un gros prjet, tu vas t'epuiser... Il m'a fallut plus d'un an pour me remettre du premier echec et accepter de recommencer... plus petit.


****************************
********rajout suite à edit*******
****************************

Après relecture de l'ensemble des posts.

Pour moi il est evident qu'un language orienté objet est une aide précieuse, sinon indispensable pour un jeu complexe.
Cela dit rien ne t'empeche d'utiliser du C ou de l'assembleur... Et vogue la galère...

Dire que le C++ ou le c# ou le C etc... Sont les seules solutions viables c'est completement fallacieux.

Ce qui importe c'est en grand (I) ta maitrise du language dans lequel tu codes.

(II) La qualité du compilateur.

Par exemple, je ne vois RIEN qu'on ne puisse faire en Delphi et qu'on puisse faire en C++ et avec (j'insite bien là dessus) les mêmes performances.

Cela dit, delphi n'est pas réputé pour être des plus portables alors que le c/c++ oui. Attention, c'est une vue de l'esprit dés que tu fais appel à une api spécifique à win32 par exemple... Ton code ne sera pas portable meme ecrit en c++.

DISCLAIMER: le c et le c++ sont de très bon language qui ont le merite de te rapprocher du proco (surtout le c)... Pas de troll c'est pas le but...

Donc très important aussi, le choix de tes libs/framework en fonction de tes objectifs (notemment la portabilité)...

La tâche la plus ardue AMHA, le saint graal du jeu video, c'est l'IA sans conteste...

1) ca peu être très mange cycle
2) il existe grosso modo une solution à trouver par probleme posé et aucune lib ne fait de l'ia... Tout simplement car son implementation dépend du scenario de ton jeu...
3)tout es permit dans ce domaine, simple empilement de if then, alogrythmes genetiques, scripts, reseaux de neurones formels, arbres decisionnels, IA orienté but, algo predateur/proie,logique floue en tout genre... Et très souvent, cela demande à la fois de grandes connaissances mathematiques, theoriques, et une grand patience pour tout casser et tout recommencer... L'IA c'est de l'empirisme +++ couplé a de la theorie +++

C'est pourquoi notre nouveau projet n'oppose que des humains. Lorsque ca fonctionnera du tonnerre de dieu, on apprendra à l'ordi à jouer... Et croit moi c'est possible d'apprendre des choses à un ordi... Mais un ordi c'est quand meme a la fois psycho rigide et autiste... Faut etre patient...

Bon voilà... Assez de bla bla.
Perso, pour debuter du tout debut...Et à ta place...
J'apprendrais un vrai language objet (c++, c# ou delphi) avec des projets simples qui n'ont rien à voire avec un jeu... Histoire de comprendre la logique du truc.

Et parallelement, je me ferais plaisir (c'est important pour garder le moral) avec un truc du genre DarkBasic (y'a une version d'essai je crois)...

Avec Dark basic, en 2 coups de cuilleres à pot tu vas faire de la 3D texturée avec shaders... Et tout le toutim... y'a plein d'exemples...
Mais dis toi bien que c'est la récréation quand tu fais ca...

Ha et aussi... C'est peu courrant comme conseil, pompe le code des autres, decortique le et analyse le... Pompe... pompe... pompe... Comme les shadoks, plus tu pompes plus tu progresses. A condition de tout faire pour comprendre ce que tu pompes bien sur.

Que dire encore... Décortique tout en problemes simples... Comment faire ce petit truc basic...

Et lit le bazaar et la cathedrale... He oui... Si tu debuttes, vaut mieux que tu fasses de l'open source... Comme ca tu fais bosser tout le monde avec toi.
Ca progressera plus vite.

Ouf... je suis bavard non?

re-edition...

Tu dois deformer to cerveau... il doit penser d'une certaine maniere... Joue à PacMan (je sais c'est enervant mais PacMan est à la base de tout... Sans PacMan tu n'es rien comme developpeur de jeu)

Alors?
Alors?

Quelle question te vient immédiatement à l'esprit?

Réfléchit...

Si la question qui te vient tout de suite immédiatement à l'esprit est "vais-je battre le hi score"... Alors t'es mal barré.

La question, evidente que doit se poser après 10 secondes de jeu est: "Comment font les phantomes pour me chasser?"

C'est ce qui m'a sauté immédiatement au cerveau dés ma première partie de PacMan!

Tout est là, dans cette question...

Et tu dois commencer à formuler des hypothèses (vraies ou fausses peu importe puisque il y a de nombreux codes de PAcMan et que tu pourras verifier par la suite)

Regarde comment doit marcher ton brain device (LooL):

10 secondes de jeu... Paralysie de tous tes muscles... Une question obsédante: Comment font les phantomes pour me chasser? et immédiatement, poussé par l'urgence d'avoir une réponse, des formules commencent à s'imposer à ton esprit...

Soit deux points P1(x1, y1) (disons les coordonnées du pacman) et P2(x2, y2) (disons les coordonnées d'un phantome) dans un repère cartesien, leur distance est exprimée par la formule suivante...

d=sqr( (x2-x1)2 + (y2-Y1)2 )

Suivit d'une autre question. Comment reduire cette distance?

Etc... etc...

Et ensuite il faut tester tes hypotheses et/ou les comparer avec la solution (perso... je vais aller chercher le code de PAcMAn vite fait bien fait car ca m'a mit le ravioli en ebullition!)

Cheeeeers

[super_navide]

L'important c'est d'avoir une bonne idée faisable et original .

Ensuite c'est de développé un prototype le plus rapidement
pour vérifier que l'idée est bonne...

Si elle est bonne alors on peut se plonger dans un tas d'améliorations
graphique sonore game play etc ...

Sinon coté langage c++ java c# python peuvent tous convenir avec pour chacun des limitations en terme de performence et temps de développement

[Kalith]

Salut,
Je me suis lancé dans la prog de JV depuis envirron 3 ans, comme passe temps.
Mes tous premiers pas, je les ai fait il y a encore plus longtemps, c'était en visual basic, le seul langage que mon père conaissait à l'époque : il pouvait m'aider un peu. Oh je suis pas allé bien loin, j'avais juste réussi a afficher une image en fond d'écran et à déplacer un petit tank si je me souviens bien Mais bon j'étais bien trop jeune (13-14 ans) pour faire de la programmation sérieuse et je ne comprenais pas la moitié des lignes que j'écrivais.
Puis j'ai commencé a faire du modding, en particulier sur Freelancer. Ca m'a vraiment passionné, et je le recommande à tous ceux qui veulent se lancer dans la prog de jeux. D'une part, on a pas à se soucier des allocations de mémoire, des pointeurs nuls ou des erreurs de link : c'est un peu comme si tu veux peindre un tableau et qu'un artiste te tends la palette avec les bonnes couleurs et les bons pinceaux. Ton rôle c'est juste de comprendre comment il faut prendre le pinceau et comment s'en servir pour étaler les couleurs sur la toile.
Mais, il arrive forcément un moment où tu te retrouve bloqué : "et si je veux dessiner au feutre ?" Ben l'artiste il a pas de feutres. Tu veux faire quelque chose qui n'est pas prévu par le code du jeu. Et c'est là que vient (ou revient) l'idée de programmer son jeu. Parcequ'on se retrouve vite limité. Mais c'est pas une raison pour faire l'impasse sur cette étape : c'est très enrichissant parceque même si tu n'a pas accès au code source du jeu, tu as pu "deviner" un peu ce qui se cache derrière les fichiers ini ou xml que tu as modifié. Et ça te servira sûrement pour la suite (si suite il y a ).
Pour reprendre le fil de ma petite histoire, j'ai voulu faire un clone de Freelancer : en gros ré-écrire entièrement le jeu pour rajouter les fonctionnalités qui lui manquaient auparavent. Je me suis renseigné un peu partout, en me posant plein de questions : "quel langage utiliser ?", "quel moteur graphique utiliser ?", "est-ce que je dois utiliser un moteur graphique, un moteur de jeu, ou pas de moteur du tout ?", ...
Au final j'ai abouti à ces réponses : pour le langage, le c++ semble le plus intéressant, pour une raison essentielle : il y a une quantité énorme de source disponibles sur le web, qu'on peut décortiquer, pomper. Une foi le langage choisi, j'ai pris ma décision sur le moteur : utiliser un moteur de jeu, c'est rapide, mais peu flexible. Ne pas utiliser de moteur du tout, c'est long, mais y a pas plus libre. Et enfin utiliser un moteur graphique, c'est l'équilibre entre les deux. Comme je me voyais pas ré-écrire directX, ni créer un jeu dans un environnement trop figé, j'ai opté pour le moteur graphique et j'ai craqué sur OGRE.
Seulement voilà, à l'époque j'avais strictement aucune connaissance sur le c++ et juste quelques vagues notions sur la programmation. Mais je me suis lancé quand même et j'ai commencé à lire tous les tutoriaux disponibles sur OGRE, tout en cherchant par-ci par-là des tutos sur le c++. J'ai fait une belle erreur en laissant un peu trop de côté l'apprentissage du c++ : je me contentais de recopier des morceaux de code qui venaient d'ailleur, sans trop comprendre l'utilité de certaines lignes. Puis j'ai été un peu démotivé pour je ne sais trop quelle(s) raison(s), sans doute une migration vers une version plus récente de OGRE qui foutais tout mon code en l'air (les tutos n'étaient pu à jour).
S'en est suivie une traversée du désert d'envirron 2 ans (WoW quand tu nous tient...). C'est une des raisons qui font que je ne suis pas enclin a travailler en équipe : la programmation doit rester un plaisir et non une contrainte. Parceque travailler à plusieurs, ca implique des responsabilités envers les autres et le projet, on ne veut plus coder, on doit le faire. Après, c'est un point de vue qui n'engage que moi Il y a des gens qui ne peuvent pas coder seul, sinon ils perdent trop vite leur motivation. Il faut de préférence savoir assez tôt dans quelle catégorie on se trouve : le freelance ou le membre d'un projet.
Puis, j'ai récemment recommencé à coder, en m'attaquant à plus simple (mais pas trop quand même, sinon où est l'intérêt ?) : un RPG/RTS en fausse 3d isométrique (longue vie à la 2d !), toujours en c++ et avec un moteur graphique (un peu de jeu sur les bords, mais juste ce qu'il faut, c'est à dire tout ce qui concerne l'input (clavier, souris,...)) bien sympatique
Du coup mon projet avance mieu que le premier (si jamais vous voulez jeter un oeil : Click).

Tous ça pour dire que, malheureusement quand on débute, on ne fait pas de la programmation en claquant des doigts. Poser des questions sur les forums c'est bien. Se poser des questions, expérimenter et découvrir par soi-même c'est encore mieu, parcequ'on s'approprie la connaissance et elle est donc bien plus simple à assimiler et à retenir
Les conseils que je donnerais (du haut de mes 18 ans ><) à quelqu'un qui veut faire de la prog de jeu :

- Essayer de programmer en utilisant un langage ou des librairies répandus pour avoir un maximum de références, de code source, de tutoriaux et de forums à sa disposition. Pour le choix du langage j'aurais tendance à conseiller le c++. Beaucoup disent qu'il est plus compliqué que les autres langages, mais d'après moi c'est simplement une question d'habitude. Quand je vois un code Delphi, ca ne m'évoque rien du tout, et je suppose qu'un développeur Delphi qui n'a jamais touché au c++ doit penser la même chose du c++.

- Faire des esssais d'abord seul, puis en équipe (une foi qu'on maîtrise un peu) si le besoin s'en fait sentir.

- Essayer le plus possible d'avoir des conaissances dans tous les domaines qui touchent à la programmation de jeux : la modélisation 3d, l'édition de textures 2d et (ca peut paraître idiot) connaitre beacoup de jeux et y jouer (de temps en temps) en analysant leur fonctionnement, parcequ'on apprend beaucoup des erreurs et des succès des autres "J'ai joué au jeu X et j'ai trouvé que d'avoir seulement 2 perso dans son équipe ça limite vachement les possibilités de combat" -> dans ton jeu tu ne referas pas cette erreur.

- Optimiser seulement quand c'est nécessaire. J'ai lu il y a quelques semaines un article plutôt intéressant sur ce sujet. En résumé, les optimisations il faut en faire le moins possible, contrairement à ce qu'on pourrait penser. Parceque dans la grande majorité des cas, elles complexifient beaucoup le code source et nuisent à sa compréhension. Du coup, dénicher des incohérences ou des erreurs qui échappent au compilo devient plus difficile.

- Apprendre l'anglais si c'est pas déjà fait ! Si tu ne sais pas ce que veulent dire "get" et "set" tu vas en chier... Pour progresser, y a une méthode simple et pas (trop) chiante : regarder des films/séries en VOST

- Toujours avoir une idée globale, même si elle est très floue, de ce que l'on veut faire. Si tu commences à créer un jeu et que tu n'as réfléchi qu'au moyen d'afficher un joueur à l'écran, c'est mal barré. Il faut essayer de penser à tout en même temps : "si je construi ma classe Arme comme ça, je pourrais pas faire des échanges d'armes, et puis il faudrait définir un point d'ancrage de l'arme pour tous les persos, est-ce que je pourrais le faire ou bien ca prendra trop de temps ?"
Mais ca veut pas dire qu'il faut tout faire en même temps ! Au contraire, tu commences à faire un truc, il faut le finir avant d'entammer autre chose, même si c'est pas une version définitive (il faut que ça marche en somme, tout n'est pas implémenté, mais ca marche). Parceque si tu modifies 4 classes en même temps et que ton programme plante, t'auras beaucoup plus de code à vérifier que si tu avais modifié tes classes unes à unes (même si le debugger peut aider, il ne résout pas tous les problèmes).
La meilleure organisation pour créer un jeu en solo d'après moi c'est une création "en spirale" : je créé les bases de la classe A, puis les bases de la classe B, puis j'améliore A, puis B et ainsi de suite. Ca permet d'avoir rapidement les grandes lignes du programme (plus facile d'avoir tout dans la tête une foi que c'est écrit) et en plus ca évite de laisser une classe de côté pendant longtemps pour se rendre compte plus tard que cette classe doit être améliorée mais que pour le faire on doit retravailler la moitié du code source (j'exagère mais c'est souvent l'impression que ça donne).
Un petit exemple : j'ai fait une fonction de pathfinding (recherche de chemin) assez tôt dans le développement de mon jeu. Elle était basée à l'origine sur des indices pour retrouver les nodes (je connaissais pas les pointeurs ) et des grands tableaux de valeur (longueur_de_lecran/precision * hauteur_de_lecran/precision, heureusement qu'à l'époque l'arrière plan était fixe...). C'était pas très flexible et ca mangeait pas mal de mémoire. Bien plus tard, j'ai fait la conversion des tableaux en std::map et std::vector et j'ai utilisé des pointeurs. Résultat : la fonction est clean et elle ne bug plus Mais ca m'a poussé a changer une bonne partie de mon code (puisque la fonction retourne maintenant un std::vector de points : changement de la fonction de déplacement des unités, modifications dans la classe de l'unité, ...). J'avais laissé la fonction au placard trop longtemps : les autres morceaux du code avaient trop évolué par rapport à elle et du coup j'ai dû modifier plus en profondeur les fonctions qui en dépendaient.

C'est tout ce qui me vient à l'esprit pour le moment
Désolé pour le pavé, j'espère que ca servira à quelqu'un !

[Garulfo]

salut
[...]
pour moi un jeux se fait en bas nivau, [...]
uml ne te servira a rien, un papier et un crayon suffise et tu apprendra a t en passer ac le temps [...]

Désolé mais tu es complètement à côté de la plaque.
Pour ceux et celles qui s'intéressent à savoir ce qui est nécessaire pour devenir développeur de jeux vidéos, je vous encourage à aller voir directement les demandes d'emplois de l'industrie comme UBISOFT Canada par exemple (plus de 1000 emplois à Montréal et Québec)

En général:
- une excellente maîtrise du C++ est demandé. Il n'est pas rare de voir des 6 ou 7 ans d'expérience pour un développeur de niveau intermédiaire ou supérieur. Les développeurs juniors ne commencent à peu près jamais sur les jeux directement mais travaillent plutôt sur les outils, les plans de tests, les bases de données etc.
- UML est souvent demandé ainsi que les connaissances de design patterns. En effet, de sérieuses connaissances en conception sont nécessaires pour permettent la gestion et la réussite d'un projet de plus de 30 ou 50 personnes.
- une connaissance des autres langages Java, .Net (comprendre C# souvent), python etc. En effet, ces langages sont très souvent utilisés pour tout ce qui est à côté du moteur et des niveaux eux-mêmes. Ce qui fait qu'il n'est pas rare de voir des connaissances de Corba, des RMI etc. Ils sont cependant rarement utilisés pour les jeux eux-mêmes dans l'industrie. Désolé pour les fans de Java: pas d'utilisation professionnelle réelle pour l'instant. Cependant j'ai déjà vu de nombreuses offres d'emploi de jeu pour des systèmes sur des cellullaires, Palm ou d'autres petits systèmes embarqués en Java.
- Un excellent niveau en mathématique. Surtout bien sûr quand vous travaillez dans la partie graphique.

Voici par exemple ce qui est demandé pour un développeur 3D

Required

• 6+ years of programming experience(Strong knowledge of C++)
• 3+ years in 3D rendering algorithms (Strong 3D math skills)
• Direct X and/or OpenGL
• Console development experience
• At least one major game title published as principal 3D programmer.
• Fluent in English

Assets:
Ex

• perience with fluid physics and modeling
• Unreal development experience
• Design patterns
• STL
• Boost
• Test-driven development experience
• UML

Attention, ce n'est pas un poste de chef... et pourtant on vous demande déjà d'avoir été le développeur principal d'un jeu 3D.
Voilà ce qui est requis pour un développeur en IA

• 2 to 5 years of experience programming C/C++.
• It is essential to have a good knowledge of path finding, finite state machines, new tendency, and basic concepts in AI.
• Has experience as an AI Programmer on a video game project.

N'oubliez donc pas vos cours d'info théorique.

Allez voir sur le site d'UBisoft (http://jobs.ubisoft.ca/en/jobs.php), et vous pouvez aussi regarder les sites d'EA Sport (http://jobs.ea.com/) ou Microsoft Games (http://mgsjobs.com/home.html).

L'industrie est en train d'investir dans les universités comme en témoigne le campus Ubisoft de Montréal. Si moi je n'y enseigne pas, plusieurs de mes collègues le font. D'ailleurs le Québec et Montréal en particulier est devenu l'une des villes les plus importantes dans l'industrie du jeu vidéo. Venez immigrer ici si vous voulez travailler là dedans .

Au passage - faisons nous mousser un peu - le chef de projet de Halo2 vient de notre université ^_^ (ça fait du bien à l'ego, même si c'est anecdotique).

[artiom]

Bon alors ce que tu dis la est tout a fait interressant.

Et je peux vous confirmer en effet que l'experiance et le niveau pour le jeu video exigé est assez allucinnant.

Savez vous s'il y a des societes serieuses de jeu video en france?

J'ai pas reelement l'impression apres avoir fait de vagues recherches...

Sinon je pense que ce que le post precedent voulait dire a propos de "bas niveau" c'est juste histoire de parler du C qui est dis bah niveau. (memoire oblige)

Bon et puis n'oubliez pas que l'UML2 est une methode d'analyse et n'est donc pas en lui meme un language de programmation. Donc l'UML2 peut trouver son utilité dans pratiquement toute sorte d'applications. En effet travaillant dans les logiciels de gestion, nous utilisons UML (un peu).
Dans le jeu ca peut s'avere une methode d'analyse tres efficace.

Cependant pour finir sur l'UML, attention a ne pas sortir le fusil a pompe quand un lance pierre suffirait. Car il est vrai que pour quelque chose avec relativement peu d'interractions ou alors des interractions tres simples, il ne sert strictement a rien d'utiliser UML, car cela peut vous faire perdre un temps precieux =)

[dolanor]

Bon alors ce que tu dis la est tout a fait interressant.

Et je peux vous confirmer en effet que l'experiance et le niveau pour le jeu video exigé est assez allucinnant.

Savez vous s'il y a des societes serieuses de jeu video en france?

J'ai pas reelement l'impression apres avoir fait de vagues recherches...

Sinon je pense que ce que le post precedent voulait dire a propos de "bas niveau" c'est juste histoire de parler du C qui est dis bah niveau. (memoire oblige)

Bon et puis n'oubliez pas que l'UML2 est une methode d'analyse et n'est donc pas en lui meme un language de programmation. Donc l'UML2 peut trouver son utilité dans pratiquement toute sorte d'applications. En effet travaillant dans les logiciels de gestion, nous utilisons UML (un peu).
Dans le jeu ca peut s'avere une methode d'analyse tres efficace.

Cependant pour finir sur l'UML, attention a ne pas sortir le fusil a pompe quand un lance pierre suffirait. Car il est vrai que pour quelque chose avec relativement peu d'interractions ou alors des interractions tres simples, il ne sert strictement a rien d'utiliser UML, car cela peut vous faire perdre un temps precieux =)

Meme pour des choses simples, UML, ca sert. Je vois ca dans mon projet.
Mon chef ne voulait pas se limiter a une technique de modélisation (merise, ou UML) face au client, mais il n'en a imposé aucune de notre coté, et n'ayant pas la totalité du logiciel a gérer, je me trouve a faire mon systeme avec un minimum d'interactions avec les autres.
J'ai un truc tout simple a faire, mais au final, meme en modelisant le peu de classes dont j'ai besoin de mon coté, je m'embrouille car cette absence de diagramme de classe pour toute l'appli me broute. On aurait du figer ca bien avant et faire patienter le client plutot que de developper des démos pour que le client soit content de voir qqchose qui "marche" mais qui derriere avance a pas de souris vu qu'on est le nez dans le guidon.

Bref, les projets qui se sont le mieux passé pour moi ont toujours été les projets ou une phase de conception préalable a permis de modéliser toute l'application ou presque. (2 au total). Et generalement, aucun retard notable au niveau du rendu final du projet.

J'espere pouvoir retomber dans un projet bien géré niveau UML la prochaine fois, car la ... Je suis un peu gavé.

[bob25]

mes ptits conseils à moi:

-ne jamais vouloir tout coder de A à Z ('est fini l'époque des atari), utiliser des API, des framework, voire pour les jeux à petit budget du midware (myst, in-memoriam ou siberia sont basé midware)

-faire des projets à la hauteur de ses moyens plutôt qu'à la hauteur de ses ambitions... oublier les mmorpg, commencer par des trucs simples: puzzle, finite state machine... les petits projets ont un énorme avantage: ils sont viables.

-commencer par de la 2d est souhaitable. ça permet de faire le tour des questions relatives au gameplay avec des maths élémentaires.



Les notions mathématiques indispensables: être incollable sur le partitionnement spatial (grilles minimum, et graphes et arbres pour aller plus loin...) à la base de tous les jeux.

pour faire des puzzle ou des finite state c'est suffisant.

pour faire des jeux d'action il y a les calculs de collision en plus à maitriser, et c'est généralement difficile et long à coder bien.

Même si vous utilisez des api qui vous machent partitionnement et collisions il faut comprendre ce qu'il se passe dedans pour s'en servir correctement.


et si vous voulez faire des trucs de folie comme un mmorpg, avant de commencer à travailler il faut d'abord trouver de quoi rémunérer une équipe de codeurs et de graphistes pendant un an.


pour les petits budgets les jeux online sont une bonne solution (langages interpretés uniquement, plus court à rédiger que du c++: js, c#, java, lua), un portail paye 500/1000 euro pour un simple license de droit de diffusion