Voilà, je suis carrément pas d'accord avec cette phrase qu'un pote m'a sorti. Ajoutant que "les programmeurs qui tapent des lignes de codes ça se fait beaucoup moins" et "que maintenant ils ont pleins de de logiciels pour les aider"  
Donc moi je trouve ça abberant de dire ça ... mais a part lui repondre que c'était faux j'ai rien su lui dire pour lui "prouver" le contraire   ( ha si, j'lui ai dit qu'il fallait pas confondre le fait de faire un niveau de doom 2 avec un editeur de niveau et faire un jeu complet en partant de zero lol )
 
En même temps j'y connais que dalle en prog donc j'peux me tromper... et p'tet que faire un jeu "de maintenant" c'est vachement plus simple que faire un jeu super NES mais j'en doute fortement    
 
Donnez moi vos arguments pour le convaincre svp il est un peu borné !!!
 
ps: fais chier y a pas de bonne sous-cat ... j'ai mis dans "PC" mais ça concerne tout les jeux bien sur !

A mon avis c'est pas plus facile, étant donné qu'il faut d'une part faire avec une technologie beaucoup plus avancée et complexe. Les graphistes sont devenus des artistes, idem pour les musiciens. Quant aux codeurs, il faut qu'ils programment pour des machines qui sortiront dans 2 ans.

 
A mon avis, c'est beaucoup plus facile de faire un jeu techniquement parlant de nos jours qu'auparavant :
- Possibilité de coder en langage de haut niveau
- Librairies qui simplifient le travail, et qui font interface avec la technologie qui, elle, se complexifie de manière "transparente" pour le codeur (Direct X, EAX, ...)
- Exploitation de moteurs existants
 
Par contre, le gros du travail se situe chez les artistes maintenant

C'est justement là que se situe la difficulté. Quand tu vois que des moteurs comme ceux de HL ou Q3 sont encore massivement utilisés, tu peux te demander si c'est vraiment si facile de coder je pense

ça dépend. c'est plus facile car on est un peu aidé. tu veux faire tourner un cube en 3D t'as plus besoin de coder le cube et la routine 3D: tu dessines ton cube dans 3dsmax (enfin... pour un cube c'est pas nécessaire mais bon... c'est pour l'exemple) et tu le fais tourner grace à une fonction DirectX.
 
pour ça, oui c'est effectivement plus facile, maintenant, il n'empêche qu'il faut quand même programmer tout le reste et que les langages sont un peu plus complexes que le Locomotive Basic de l'Amstrad CPC.
 
et puis à l'époque tu pouvais faire un jeu tout seul dans ta cave, ce qui n'est plus trop possible maintenant car pouir tout faire sois même ça prend du temps et le temps que tu finisses ton jeu il est totalement dépassé par ce qu'on sorti les grosses équipes bourrées de fric

Ils sont aidé mais d'un autre côté faut faire plus qu'avant donc ça reste grosso modo la même chose, stout.

C'est moins une question d'outils que de budget, je pense. Avec le bon budget t'as les outils adéquats, et des outils forcément plus performants qu'il y a 5/10/15 ans (logique). Après les jeux sont quand même devenus beaucoup plus complexes : moteur 3D, gestion réseau, cinématiques, musique, etc, ça demande un travail d'intégration assez important. En ce qui concerne les programmeurs eux-mêmes, savoir s'il sont plus aidés par les logiciels actuels, sûrement, est-ce que c'est plus facile, je sais pas
 
Prodigy

Donc sur seulement certains points c'est plus facile ? Mais je comprends pas que ça soit plus facile dans la globalité. Même simplifié la charge de programmation est décuplée depuis ces temps anciens ... non ?
J'dis par exemple en comparant F-zero snes et F-zero GX    

  au contraire, sur ce point là c'est beaucoup plus simple. direct3d simplifie énormément la programmation de moteurs 3D, tu veux balancer une cinématique, plus besoin de coder un format propriétaire, tu enregistres en avi ou en mpeg et tu la fait lire par les fonctions de windows, pareil pour les musiques, plus besoin de routine maison pour la création et la lecture: enregistrement direct à partir de n'importe quoi en wav, mp3, ogg ou ce que tu veux et lecture par windows.
 
mais bon... je ne veux pas faire croire que ce que je dis est une science je ne suis qu'un anti-nintendo qui n'y connait rien

là il y a peu de différence car F0 snes utilisait déja le principe de code actuel à savoir qu'il n'y a pas à se faire chier pour créer le circuit petit à petit au fur et à mesure de la progression.
 
pour la version snes, le circuit est une map entièrement dessinée à l'avance et "3difiée" par le mode 7, sur gc (à priori) le circuit est entièrement dans un soft de 3D avant d'être balancé tel quel dans le jeu et l'illusion de mouvement est donné en déplaçant une caméra sur ce circuit.
 
pour ça c'est effectivement beaucoup plus imple maintenant car les machines ayant progressées, on peut largement stocker tout un niveau dans la RAM alors qu'il fallait avant l'afficher par blocs et donc créer une routine spéciale pour l'affichage

 
Je partage cet avis. A l'époque des 16 bits, les programmes étaient majoritairement codés en assembleur, et il fallait coder ous ses outils dans ce langage proche du langage machine.
 
Maintenant, il "suffit" de dire "affiche-moi ça" à telle librairie graphique, de dire "Hum, considère qu'il y a un mur là et que le son vient de là" à l'interface audio, et hop, on a le résultat. A la limite, on n'a presque plus besoin de savoir sur quelle machine on bosse. Ca permet en contrepartie de s'intéresser plus profondément (en théorie) à l'aspect gameplay.

Bien dit !
 
Prodigy

Donc dans les jeux 3D avec effets speciaux a profusion et animations de guedins, y a moins de lignes de codes que pour les jeux plus simples d'avant ?
J'suis sur le cul là quand même.

Tres simple, tu ouvre l'editeur d'UT2003, view->show actor class broswner, dans la fenetre qui s'ouvre file->export all scripts.
Ensuite tu fait une recherche sur tout les *.uc du repertoire d'UT 2203.
Ce sont les sources unreal script de UT2003 donc seulement la partie visible de l'iceberg.
 
Pour la difficulte je ne sais pas si c'est plus dur maintenant qu'avant c'est different c'est sur.

 
Bah si c'est standardisé (DX et compagnie), ben t'as pas besoin de réinventer l'eau chaude à chaque fois

oui enfin, tu peux toujours t'amuser à tout coder, mais bon... ce sera plus long, pas focémment mieux et si t'as de la chance ça marchera très bien sur ton pc mais pas sur celui du voisin qui n'a pas exactement les mêmes composants

Surement pas  

 
Y a plus de lignes de code (il suffit de voir la taille des exécutables pour se faire un idée grossière), mais c'est des lignes de code plus simples à interpréter. Je vais essayer de te faire un exemple concret et j'édite
 
Edit : Nan, finalement, ça te dira rien, et c'est trop compliqué pour moi

C'est d'ailleurs pour ça qu'il nous faut des mahines de plus en plus puissantes

Je ne suis pas entièrement d'accord : Ok les API simplifient une bonne part du travail (et honnêtement elles simplifient la partie bien lourde, répétitive et inintéressante) mais il reste encore énormément de choses à faire c'est juste que le gros du boulot s'est déplacé. Si on s'en tiens à balancer des polys mappés là aucun problème n'importe qui ayant quelques bases en OpenGL ou DirectX peut le faire mais ce n'est pas avec ce genre de choses que le jeu va impressionner.
 
Comme les tâches fastidieuses sont gérées par les API les programmeurs peuvent maintenant se concentrer sur des algorithmes plus intéressants : ombres temps réel, éclairage au pixel près etc etc... Je ne connais aucune API qui automatise ça et c'est un gros travail
 
Ensuite les programmeurs doivent avoir une connaissance assez énorme du pipeline graphique qui devient d'une complexité impressionnante alors que faire un moteur à base de tile n'était quand même pas sorcier surtout avec des machines trés adaptées.
 
Bref plus facile ou moins facile c'est dur à dire mais différent assurément

en tout cas, ce qui est sur c'est qu'il faut quand même savoir un peu programmer pour faire un jeu. même si certaines fonctions sont déja toutes faites, si on ne sait pas les utiliser ça revient au même et c'est pas avec des trucs style "klik & play" qu'on peut faire de vrais jeux

 
Au passage intégrer tout ce dont tu parles grâce à DirectX, très bien, encore faut-ils les faire
 
Prodigy

tout à fait. ça n'en devient pas un jeu d'enfant mais certaines choses sont plus simples à faire.
 
si tu te souviens de mon superbe ( ) émulateur Gamecube, tout est en 3D et je l'ai codé en 2 jours alors que je n'y connais pas grand chose en calculs 3D

 
Voilà, y a tellement d'intermédiaires qui simplifient le travail qu'il faut bien que ça se paye.
 
Sinon, pour en revenir à ce que dit Zeross, c'est pas faux de voir que dès que l'on dépasse les spécifications d'une API, on doit bricoler et vraiment revenir au codage à l'ancienne. D'ailleurs on revient un peu à l'assembleur pour coder les puces "programmables" comme les chips de pixel shading, etc...
 
Bref, c'est différent, ça c'est sûr. Mais il est plus simple de créer un jeu "de base" actuellement (de mon point de vue) que par le passé (encore que certains parlent assembleur couramment, j'en connais).
 
Tout ce que je dis n'est pas parole d'évangile non plus, hein

 
moi ske j'trouve aberrant c de n'y rien connaitre ds un sujet et de pourtant vouloir avoir raison, t'aurais dû répondre à ton pote ke tu savais pas et ke t'allais te renseigner au lieu de lui dire k'il a tt faux sans aucun argument...

bon, d apres mon experience (j ai travailler chez lexis numerique et participer au develeppement de papyrus 3)
 
il est vrai que dans l ensemble la programmation s est allégée,
il existe des softs tout prêt à s occuper de la gestion graphique, audio, de l adressage memoire.
 
mais cela s adresse surtout aux equipes qui developpent avec des outils deja existants. je m explik :
 
chez lexis numerique, la plupart des jeux sont fais avec macromedia director ( c pas un secret c dans les credits a la fin des jeux ). si vous connaissez le programme vous verrez que la seul programmation qu il y a faire, c est le game play et le moteur du jeu( a ne pas confondre avec le moteur graphik ou physik ).
 
d un autre coté pour les jeux en 3D, souvent les equipes "recuperent" des moteurs graphiques ou physiques (en fait ils achetent la licence d utilisation et de distribution. par ex : renderware (GTA 3 et autres titres connus) coutent 2 millions de francs), mais la, on obtient des jeux préformatés, comme dans le cas de macromedia director, car les jeux sont limités à la puissance du moteur qu ils utilisent.
C'est de la que l on voit toute une génération de jeux utilisant les memes moteurs, et se ressemblant beaucoup. (je parle bien sur sur les aspects visuels).
La seule innovation de ses equipes, est le game play et l utilisation des ressources des outils qui ont achetés. pourquoi certains jeux semblent plus réalistes que d autres alors qu ils ont le mem moteur ? la maitrise de l outil.
 
maintenant, il y a les equipes innovantes dans les moteurs graphiques ou physiques. vous serez d accord que HL et different de Quake3 et qui est different de UT2003.  
la difference est que les programmeurs ont tout simplement repenser les moteurs pour les faire evoluer. comme kelkun la dit precedemment, les technologies graphiques ne cessent d evoluer et de se complexifier. il n est pas aussi facile qu avant d utiliser toutes les capacités des machines d'aujourd hui.
 
donc, personnellement, je dirais qu'il est plus difficile qu'avant de créer des jeux innovants ou dit de nouvelle génération. Car il faut repenser et reprogrammer les moteurs graphiques. A l heure actuelle, on voit de plus en plus de moteurs physiques que de moteurs graphiques (c'est plus réaliste quand on voit un perso d'UT2003 se casser la gueule qu'un perso de duke nukem 3D).
 
je dirais que la complexité s'est déplacer avec l apparition d'outil pour la programmation, mais maintenant l'IA a beaucoup évoluer et génère beaucoup de travail pour les programmeurs.
 
pour conclure, il est facile aujourd hui de creer un jeu interessant, mais il devient extremement difficile de creer un jeu innovant ( et je ne parle toujours pas de game play).

 
J'l'ai pas dit exactement comme ça, pas d'affolement, c'est une mauvaise transcription écrite... j'ai voulu faire court.
 
Par contre, ton opinion sur le sujet du topic pourrait être interessante si tu l'exposais !

 
ne m'y connaissant pas assez, je ne participerai pas au débat, j'passais juste faire un peu la morale      
A part ca, j'trouve le sujet très intéressant, dommage k'il n'y ait pas + d'avis de gens bossant ds la profession, le post de DocWario étant très constructif

Hey les gars faut arretter de raconter n'importe quoi parceque Nvidia vous bacine avec le Cg et ATI avec render monkey.
Les jeux, depuis des lustres c'est du C/C++. Donc la tache de programmation elle est pas moins lourde. Alors vous allez me dire ouais avant ils codaient en assembleur. Ouais et toujours maintenant lorsqu'ils sont à la pointe. Le gars qui a codé les effets de pixel shaders de morrowind, il s'est tapé de l'assembleur.
De plus c'est bien beau de dire OpenGL ou DirectX il te fait tourner le cube tout seul. Bien sur et encore heureux parceque ça vous suffirais pas un cube qui tourne pour jouer.
Je vais prendre l'exemple de Doom III. Déja c'est de l'OpenGL donc plus souple mais plus complexe que DirectX. Bon deja la gestion des texture... 3-4 textures sur chaque élément du décor voire plus sur les personnages. Juste ça codé par n'importe qui ça rame. Je parle bien sans la map les éclairages et tout mais juste les persos et les textures qui vont dessus. Bon là on as rien donc on vas rajouter une belle map. Bon là les derniers PCs sont à genoux 1 fp minute. Et il n'y as meme pas l'éclairage.  
Donc oui les API font beaucoup de travail mais des que l'on est un peu à la pointe...c mort.Faut y aller à la main dans le camboui. Deja faut faire des purs calculs bien optimisés pour calculer seulement les polygonnes necessaires. Ca deja c de la bonne programmation mais c'est asses faisable (ça a été fait de manière exeptionnelle par J Carmak pour Quake III).
Bon maintenant on vas passer à l'éclairage. Et là on rigole, la technique d'éclairage utilisée dans doom III avec une lumière,un cube, un cone et un sphère correcte c'est environ 30 fps sur une tres bonne config. Pour arriver au resultat de Doom III il faut faire des instructions directement en assembleur pour calculer les lumières seulement ou il faut. Bon enfin c'est hyper complexe. Je dis pas que c'est plus complexe qu'avant mais que la difficulté n'est pas partie. Et elle ne partiras pas pour ceux qui restent à la pointe comme J Carmak. Pour HL² c'est très différent car techniquement c'est nettement en dessous de Doom III meme si d'un point de vue visuel c'est pas flagrant?

pas la peine de t'emporter comme ça, on généralisait  
biensur que tu as toujours des gugus qui programment comme des porcs à longueur de journée, biensur que c'est toujours du C ou de l'assembleur ou autres, biensur qu'un cube qui tourne ne fait pas un jeu.
ça n'empêche qu'auparavant les seules fonctions "cablées" c'était: afficher un texte, tracer une ligne en 2D, dessiner un cercle ou un rectangle et c'était à peu près tout alors il fallait vraiment tout coder et si tu voulais faire de la 3D tu avais interet à sortir les bouquins de maths et de physique.
 
et puis ton exemple de Morrowind, tu aurais pu trouver mieux, hein parceque ils ont ptet codé un ou 2 trucs en asm mais tout le reste est fait avec les pieds

 
 
juste pour dire que les amateurs ne se drébrouillent pas mal non plus, suffit de voir tenebrae :-)

j'ai pas lu la dscution mais je vous file ça :
http://www.cs.kun.nl/~clean/About_ [...] _games.htm

 
l'avenir de cg me semble compromis, et rendermonkey c'est jamais qu'un outil pour aider a la conception de VS/PS.....Et largement ameliorable
 
 

 
oui enfin entre ecrire un VS et un jeu, y'a une marge.
Si l'assembleur x86 etait aussi souple que l'asm VS/PS programmer en asm serait du bonheur
et avec les HLSL ci et ca (cg, dx9, et maintenant ogl) l'assembleur VS commence deja a reculer
 
 
FEt il n'y as meme pas l'éclairage.  
Donc oui les API font beaucoup de travail mais des que l'on est un peu à la pointe...c mort.Faut y aller à la main dans le camboui.  
 
le camboui, c'est l'api. Tu descenderas pas plus bas a moins de faire ton propre driver de carte graphique. Interet ?
 
 

 
Qu'est ce que ce ramassis de conneries ? Pourquoi de l'assembleur ?

 
vas y mollo, c'est un forum de gamers là    
 

 
Boaf. Tu sais, la 3d une fois projeté, c'est de la 2d, donc la tu ressors ta routine de tracage de tri et en avant (enculons pas les mouches sur la correction de texture s'il vous plait )
 
Pour le taf j'ai du me retaper tout ca en java (pas de la 3d mais de la 2d). Peux te dire que le niveau en math a pas besoin d'etre stratospherique, surtout des matrices....
 
C'est plutot maintenant qu'un niveau en math est necessaire, les methodes d'eclairage se complexifient (nos amies les sphericals harmonics, ou meme les phenomene de diffusion de la lumiere pour les paysages, avec des coefs dans tous les sens), connaitre des ruses de matheux permet de s'affranchir de certaine limitation (absence d'instruction sin/cos dans les vs1.1 par ex), quand a la physique j'en cause pas, c'est pas trop avant qu'on y faisait gaffe mais plus maintenant (et plus ca va et plus avoir un monde physiquement coherent va etre important)
 
c'etait evidemment pas de la rigolade car la puissance brute etait pas bien haute, mais j'imagine que c'etait plus une question de connaitre la machine sur le bout des doigts que d'etre un expert en math.
 
 
(mon avis)
 
(et n'oublions pas l'IA)

 
mouais mais ca m'enerve de lire des phrases faites visiblement au pipotron

si si j'insiste, c'est très important  
 
 

 
Roh pinaise, c un mec qui lit le .plan de Carmack et les articles de PPC sur la 3D et qui apprend la vie au forum ça
 
Dis moi, c pas avoir les mains dans le camboui que de se taper l'API ?  
Et à moins qu'il soit très très bête, Carmack fait de l'assembleur que pour les choses qui nécessitent une grande vitesse d'execution et qui reviennent souvent  

 
jvais essayer de ramener 1 ou 2 brutasses