Discussion :

[Acropole]

Êtes-vous satisfaits des moteurs de jeux que vous utilisez ?
Créer un jeu vidéo devient "le parcours du combattant" d'après un développeur


Témoignage :
J'ai commencé à étudier la création de jeux vidéo en 1999 avec l'éditeur de maps de Max Payne.

Je n'y connaissais rien à l'époque. Depuis j'ai appris beaucoup en essayant de modder/coder avec les moteurs d'Half Life, Quake, Unreal, Crysis, Neverwinter Nights, Torque, Irrlicht, Crystal Space, OSG, kjAPI, Qt, Unity (+ ceux que j'ai oubliés). J'avais même essayé de faire mon propre moteur avec les tutoriaux OpenGL de Nehe sur Gamedev.

Résultat, mis à part quelques maps ou modèles ici ou là et quelques scripts localisés, je n'ai jamais réussi à finir un jeu complet. Même si j'ai fait énormément de progrès grâce à Unity, je me retrouve confronté à des problèmes importants, voire insolubles comme la gestion de la physique en réseau.

Avec d'autres moteurs, les problèmes sont différents : manque de documentation, code fermé, trop spécialisé, etc.

Du coup, créer un jeu vidéo devient le parcours du combattant. Or je sais par expérience avec des outils comme Unity ou Neverwinter Nights qu'il y'a des concepts permettant de rendre la création de jeux vidéo extrêmement facile.
Malheureusement aucun outil à l'heure actuelle ne regroupe tous les meilleurs aspects de la création de jeux vidéo.

Et vous ?
Quel est votre avis sur ce constat ?

[Pat_AfterMoon]

Salut à toi

Moi j'ai commencé à tâter du middle-ware pour faire des jeux vidéo avec le modding Quake1, puis Quake2. Ensuite je suis passé par Torque (puissant mais trop complexe), Quake3, Doom3 et enfin Unity.

Aujourd'hui je suis plus que satisfait du moteur Unity. A vrai dire, après 20 ans de développement, je ne crois pas qu'un seul autre outils m'ai donné autant de satisfaction, que ce soit pour mes hobby (GameDev) ou au niveau Pro (Info indus).

Je n'ai encore jamais vraiment finaliser un jeu complet mais j'ai de l'espoir (cf ma signature). En fait je n'ai plus aucun problème en ce qui concerne les outils, ce qui me manque c'est de réussir à me raisonner suffisamment pour avoir un projet qui soit réalisable. Hé ça, même sans être un ado qui annonce qu'il va faire mieux que WOW, ce n'est pas si évident...

[MoDDiB]

Sujet très intéressant, je suis étonné de ne pas voir plus de retour.
De la même manière après plus de 10 ans je suis toujours à la recherche de l'outil adapté à mes besoins.
Voici mes retours sur les technos que j'ai pu manipuler :

-SDK Half-Life : très efficace, permet un travail en équipe dès le premier jour.
M'a permis de sortir un MOD à succès (WormsHL) en moins d'un an sans rien y connaitre à la base.
Malheureusement le côté propriétaire m'a fait partir sur d'autres voies.

-DirectX/C++ : surtout pour découvrir la technologie.
J'ai pu sortir un shoot m up ( fast and shootious ) en quelques mois.
Par contre j'ai essayé de réaliser de nombreux projets plus ambitieux incluant d'autres collaborateurs et ce fut une série d'échecs : le temps que prend la réalisation du moteur + les outils décourage tout le monde qui ne voit pas son travail intégré au jour le jour.

-Irrlicht : Idéal pour débuter la 3d, ça s'arrête là.
Je ne sais pas si il a évolué depuis mais il y a 6 ans il accusait déjà 5 ans de retard graphiquement + de nombreux bug et je n'ai jamais réussi à obtenir un ping correct en local en couplant Raknet avec.

-kjApi : le développement n'est malheureusement pas arrivé à terme ; donc impossible d'avoir les outils promis :/

-Ogre3D : très bon moteur, stable, performant, avec une communauté au top.
Mais c'est à ce moment que je découvre le C# et je comprends assez vite que développer du jeu amateur en C++ est une perte de temps.

-MOgre : wrapper .NET pour Ogre : pas vraiment au point lorsque j'ai voulu y toucher. Peut être que désormais il est enfin utilisable.

-Managed Direct X 2.0: Un wrapper intelligent et orienté .NET ( contrairement à la version 1.1) je réalise un snake 3d multijoueurs avec et celui ci a été abandonné par microsoft qui a poussé le vice jusqu'à inclure une "TimeBomb Exception" m’empêchant de lancer mon propre projet...
Tout ceci au profit de XNA..

-Brume Engine : moteur de jeu sympathique mais malheureusement tenu par une personne et dépourvu d'outils.
Je m'y implique tout de même pas mal en y apportant mon système de particules et développe un tower defense jamais finis car arrive....

-XNA : LA solution de microsoft au développement amateur.
Même si au final ce n'est ni un moteur graphique ni un moteur de jeu il y a beaucoup de bons points :
-Hiérarchie propre et soignée
-Communauté efficace
-De nombreux exemples
-Performant sur PC et XBOX à partir du moment où vous comprenez le fonctionnement du garbage collector.
Mais aussi de TRES mauvais point :
-Le content pipeline gênant.
-Le content pipeline inadapté au travail en équipe : ( un artiste doit avoir visual studio pour tester ces assets !?! )
- Le content pipeline génant pour la création d'outils.
- Des "blagues" pas amusantes : lors de chaque DrawIndexedPrimitive XNA vérifie si BeginScene a été appelé et l'appel si ce n'est pas le cas...
Ce n'était pourtant pas gênant de laisser cette tâche au développeur...
Donc au final rien de méchant, j'ai pu créer un moteur 3D, une suite d'outils et un jeu ( Chibis Escape ) en à peine 1an et demi.

Désormais comme j'ai moins de temps et beaucoup plus l'envie de créer que d'apprendre ce que je sais déjà, je vais essayer d'utiliser un moteur existant :
SunBurn Game Engine couplé au balbutiement de l'Indiefreaks Game Framework.
Pour le moment l'architecture me semble prometteuse mais l'IGF est encore en beta et je rencontre de petits soucis...la suite dans quelques mois.

Je n'ai pas utilisé Unity car il a tout pour plaire sauf la possibilité de bosser avec Visual studio en C# : bosser avec que des scripts sans architecture non merci....
EDIT : Il semblerait que je me trompe sur Unity et VS je vais donc tester à nouveau.

Sinon au niveau professionnel c'est du DirectX/C++ from scratch et j'en suis satisfait ça permet de tout maîtriser, mais c'est sur que pour réduire les temps de développement un middleware ne serait pas du luxe....

[Acropole]

Je n'ai pas utilisé Unity car il a tout pour plaire sauf la possibilité de bosser avec Visual studio en C# : bosser avec que des scripts sans architecture non merci....

Qu'est ce que tu veux dire par là ? J'utilise justement VC# en permanence.

[Pat_AfterMoon]

@MoDDiB : je te confirme ce que Acropole a écrit, même depuis que l'EDI monoDevelop est Livré avec Unity les fichiers projets Visual C# continuent d'être générés et updatés automatiquement par Unity. Je pense que de nombreux développeurs continuent d'utiliser Visual C# avec Unity (perso je suis passé à monoDevelop, je préfère les EDI plus épurés).

[MoDDiB]

Qu'est ce que tu veux dire par là ? J'utilise justement VC# en permanence.

@MoDDiB : je te confirme ce que Acropole a écrit

C'est donc avec plaisir que je vais tester à nouveau.
L'autre frein à Unity c'était le prix de la version Pro, mais celle ci ne semble pas nécessaire pour un projet amateur.

Merci !

[Thorna]

Oui, intéressant sujet que celui-là !
D'après mon expérience personnelle, du genre touche-à-tout, Mogre est intéressant pour ce qui se fait dans le domaine .NET, si on excepte les x pages à lire pour être certain d'avoir tout installé, tout au bon endroit, de savoir supprimer ce qui ne sert à rien, de conserver le nécessaire et d'éliminer le superflu... Un bon boulot dont la connaissance chèrement acquise disparait après quelques semaines de non utilisation !
Brume, j'avais testé il y a déjà plusieurs années. Très bien et clair mais, comme dit plus haut, dépendant d'une seule personne.
Unity me botterait, mais je ne sais plus quel souci j'ai rencontré qui me l'a fait mettre de côté...
Truevision avait le mérite d'être simple, peut-être trop.
Reste effectivement XNA qui, sans être un moteur de jeu ni un moteur 3D, est un ensemble d'outils intéressants, une fois qu'on en a compris la philosophie. Actuellement, tout ce que je fais tourne autour de ça. Reste que je trouve un peu dur à avaler d'être obligé d'importer un fichier FBX d'un demi méga octets juste pour afficher un cube avec des faces colorées : il manque la partie "objets habituels de géométrie simple". Même si je comprends bien qu'elle ne s'insère pas trop naturellement dans l'outil XNA, ce ne serait pas un gros effort que de l'y mettre. Mais, d'un autre côté, ce n'est pas non plus un trop gros effort que de la recréer, ou d'en trouver quelques exemplaires sur le site des développeurs xna ou en fouillant un peu partout.

[Inazo]

Bonjour à tous,

Pour ma part j'ai recommencé il y a peu a coder deux jeux Android et un autre projet que je réfléchie depuis un moment et que je vais essayer de concrétiser avec GameMaker.

Sous android le premier et a l'abandon le second je suis partie d'une base open source d'un jeux qui était pas mal mais qui connaissait des lacunes sur la plateforme.

Pour le jeu sous GameMaker (ah oui fait important je ne veux faire que de la 2D) j'ai peur d'être limiter dans mes capacités de développement de de devoir soit revoir à la baisse mes ambitions soit de devoir arrêter le dev et le reprendre sur une autre plateforme...

Par contre pour tous les moteurs & outils que j'ai pu essayer (RPG Maker aussi d'ailleurs) les documentations sont souvent trop peu nombreuses (et j’entends par là quel que soit la langue l'anglais ne m'effrayant pas)...

Et encore on a pas parlé de design ni de graphisme

Cordialement,

[Freem]

Je ne m'y connais pas du tout en moteurs de jeux, donc je ne peux pas répondre à ce sondage, mais le sujet est intéressant et m'amène à me poser (enfin, à vous poser en fait ) quelques questions:

Pat_AfterMoon semble avoir utilisé plus des jeux déjà existants qu'il à moddé, est-ce que l'on peut vraiment considérer qu'il s'agisse de moteurs de jeux?
Si oui, j'imagine qu'ils ont des désavantages par rapport aux librairies (framework j'imagine?) que j'ai plus souvent vues citées comme Ogre3D ou Irrlicht. Lesquels? Perte de performance contre rapidité de développement?

Je pensais que DirectX n'était que d'un amalgame de moteurs 3D/son/entrée (DirectDraw, DirectSound, DirectInput) donc pas de gestion de physique...
Ogre3D, selon wikipedia, et comme son nom l'indique, semble ne gérer que la 3D. Et selon wikipedia, il s'agit d'une abstraction à DirectX ou OpenGL (selon l'os je présume).
Irrlicht semble être un concurrent direct d'Ogre3D et faire la même chose.

Le terme moteur de jeu désigne t'il juste l'un des moteurs utilisés par un jeu (physique, affichage 2D/3D, son, réseau?) ou un ensemble de ces moteurs?

La SDL peut-elle être considérée comme un moteur de jeu? Et la SFML? En fait, quel est le niveau d'abstraction à partir duquel une bibliothèque deviens un moteur de jeu (d'affichage 2D/3D en l'occurrence)?

Les autres cités me sont totalement inconnus de nom comme de réputation (j'ai été voir wikipedia pour ogre et irrlicht au cas ou mes souvenirs étaient mauvais).

Par contre, j'ai entendu parler (enfin, je connais un projet qui utilise) d'un moteur physique, bullet. Je ne sais pas vraiment ce qu'il vaut, étant donné que le projet est en "pré-alpha" (openMW pour les curieux, une ré-implémentation de the elder scrolls 3 : morrowind).
Si quelqu'un l'a testé, je serai curieux de savoir ce qu'il vaut. OpenMW l'utilise en conjonction avec Ogre3D et, de mémoire (il me semble avoir vu, pas sûr donc) "mygui" pour l'interface utilisateur.

Et niveau moteur de son, il existe OpenAL qui n'a pas été cité, dont j'ai vu le nom au fur et à mesure de l'installation/mise a jour de ma machine linux. De même, je ne l'ai qu'entre aperçue, peut-être quelqu'un l'a t-il déjà manipulé?

J'ai aussi entendu parler de SFML qui se veut un concurrent direct de la SDL et ai été voir un peu sur leur site, histoire de voir ce que ça vaut pour un projet que j'ai entamé (une librairie C++ agnostique pour créer des UI de jeux, qui permet de changer de lib graphique sans modifier la moindre ligne de code.).
Si quelqu'un la connaît, peut-il dire si ça entre dans la catégorie des moteurs de jeux? Et si oui, si c'est bien foutu dans l'ensemble. (je suppose que ça n'entre pas dans la catégorie des moteurs, vu que c'est un concurrent direct et avoué à la SDL, qui est très bas niveau (mais dont l'intérêt réside dans la portabilité)...)

[gyhelle]

Du coup, créer un jeu vidéo devient le parcours du combattant.

Ouaich développer est un métier et pas seulement un passe-temps. Mais j'ai plutôt le sentiment que ça devient de plus en plus facile: moteur gratuit, documentation extensive, forums d'aide, communauté de modding pour se faire la main.

[seeme]

Bonjour,

Je pense que le problème général que tu soulèves vient du fait qu'un moteur de jeu (et encore plus les outils qui lui sont rattachés) n'est pas conçu pour être généraliste, et s'il l'est, c'est avec des contreparties généralement importantes.

Si tu prends par exemple le sdk source, il est possible de le transformer pour faire un jeu de voiture, mais il n'est pas conçu pour ça. Résultat, beaucoup de temps investis, des bugs extrêmement longs voir impossible à résoudre sans un refactoring pas toujours possible.

Il existe évidemment des middleware qui sont généralistes, mais soit ils seront d'assez bas niveau (ogre), soit ils auront des limites (unity3D), il y a toujours cette balance entre accessibilité et spécialisation du produit.

Un moteur et ces outils, c'est taillé pour faire de la performance et les algorithmes qui tournent derrière ne fonctionne pas pour tous les types de jeu ou toutes les plate-formes.

Le "problème" soulevé ici n'en est pas un, c'est un état de fait

[Acropole]

Je ne suis pas d'accord, seeme.
Je me disais la même chose que toi avant de découvrir unity et là je me suis aperçu qu'en réalité la difficulté vient de l'aspect historique du développement des jeux vidéos. Nombre de moteur en sont restés en grande partie à la vieille conception qui date de Doom pour lequel il fallait optimiser la moindre instruction à cause des limitations matérielles de l'époque.
Aujourd'hui ce n'est plus de mise. Les cartes vidéos peuvent avaler un nombre ahurissant de polygones, textures, shaders et font même la physique.
Quand on regarde les démos de la plupart des moteurs on voit bien que la course à la qualité de rendu est en train de se terminer. La qualité d'unreal ou de crysis se retrouve aussi bien dans unity qu'irrlicht ou torque pour peu que les graphistes soient bons.
Evidemment on peut toujours mettre une carte vidéo à genoux en lui envoyant 10 000 personnages à afficher en pleine jungle sous la pluie avec le feuillage qui bouge lors des collisions. Mais ce n'est plus vraiment du domaine du moteur.
Il y'a un nombre astronomique de moteurs de jeux proposant tous des rendus haute qualité avec des shaders. Les techniques sont connues et éprouvées.
Les moteurs se distinguent désormais par le nombre de fonctionnalités et leur facilité d'utilisation. Crysis et l'UDK par exemple sont largement plus complets qu'Ogre qui ne fait que de l'affichage, à la base.
Y'a qu'a voir la liste sur devmaster ou les démos sur gamedev.

[comboDev]

J'avais acheté une bouquins dans les débuts de DirectX : DX6, DX7 sans succès
trop de code.
J'ai utilisé Blitz3D que j'adorais et j'ai fait des outils ou mini jeux intéressants.
Ensuite je suis passé à 3D Game Studio, Torque 3D que j'ai essayé, plein de moteurs open source dont j'ai juste balayé les fonctionnalités ou juste essayé.
KJApi, était un bon moteur, dommage qu'il soit tombé dans l'oubli idem pour le super jeu qui était en réalisation (les développeurs étaient plus centrés sur le jeu que la communauté de game makers).

Disons avec Unity 3D, il y a déjà tout ce dont on a besoin.
Pour la partie Réseau je conseillerai plus un moteur comme Esenthel 3D , qui est facile à programmer en C++ et vraiment pas mal du tout, dommage qu'il ne soit pas mis plus en valeur surtout avec le nouveau prix très "indie" quelques 150 Euros en gros !

Le problème de faire un jeu se situe bien plus au niveau des buts, des moyens
et de ne pas trop rêver. Un jeu prend énormément de temps, y compris les phases de pauffinage, ou des choses comme les effets spéciaux, les HUD,
le dialogue s'il y en a , un même un inventory system qui a eux seuls pourraient prendre des mois.

Unity 3D , sa force c'est son système de plugins, il y a sur Unity Store des plugins pour gérer les inventory, plugin jeux 2D , RPG etc ...
même un plugin Réseau est en train de voir le jour atuellement !
Pour le coté MMo certains existent avec Torque 3D qui est plus orienté réseau à la base, j'en ai vu un pas mal du tout (voir sur le site ou rechercher sur Youtube des jeux mmo !)

Il faut savoir choisir le style de jeu que l'on veut faire et comme toujours viser petit , plutot que énorme.
Combien veulent refaire un Modern Warfare ou un Wow ou un autre jeu, derrière c'est 100 et bien plus avec les indépendants qui sont des experts
avec des années d'expérience en modélisation/texturing, des animateurs, des
spécialistes des interfaces, d'auttres pour les outils etc .... on ne peut rivaliser avec leur travail.

Mon conseil faire petit, qui marche d'abord avec bon gameplay,addictif, ensuite paufiner les graphismes.
Puis peut être grandir ou ajouter de nouvelles fonctionnalités, gameplay , levels etc ...

Unity pour le "pas forcément réseau" me semble un très bon choix, il suffit d'aller sur leur forum et le Showcase pour voir le nombre de jeux qui sort en une semaine

C'est ça aussi qui permet de juger de la qualité de ce qui peut être fait avec un moteur 3D : le forum Showcase !
Quand y'a rien , on peut se dire, pas top du tout, quand y'a plein de trucs, on peut se dire : "les gens arrivent à l'utiliser et à créer de super trucs et qui tournent"

Autre sujet l'optimisation : très très grand sujet, plein de solutions y compris avec des moteurs indie tels que Unity 3D et autres !
le LOD est le premier pour ma part à prendre en compte, suffit de voir les jeux SKyrimou Oblivion où les objets apparraissent au fur et à mesure que l'on s'approche avec un effe tde fondu de transparence: on s'en rend pas compte ! Les ombres utilisent intensivement le CPU , de même que l'anti aliasing, la qualité de l'éclairage , etc ... etc ...

Si on vise un jeu "AAA" plus réalistic et plus gros ; là c'est plutôt une équipe qu'il faut et encore rien n'est gagné, derrière faut produire des quantités de textures, modèles et de qualité ! Dans la scène Indie c'est rare et certains utilisent plutôt le modding : E.Y.E sur PC justement d'une French team.

Le modding c'est l'autre alternative, certains moteurs tel que UDK étant déjà pleinement orienté FPS, mais il a servi à square/enix pour des RPG !

[comboDev]

J'ai envie de dire, bon nombre de gens sont satisfaits et arrivent à sortir des jeux, surtout avec la vague du mobile.
Pour ma part je vises plus la création 3D et la programmation style script ou légère avec commandes simples plutot que le coding intensif.
Si on est pas e néquipe il faut savoir de quel coté on est ?
Y'a pas mal de coders qui utilisent des Moteurs 3D, ou interfaces et ils ont tout à coder, y compris leur world editor, terrain editor, framework etc ...
du coup plein de finissent jamais rien.
Donc moi après avoir commencé comme ça, j'ai opté pour le coté où je peux importer mes modèles 3D via Fbx, textures, avoir un outil déjà pour le terrain, mettre de la végétation , sélectionner facilement les normal map ou shaders pour un modèle etc ...
Donc Unity est parfait pour ma part !
J'utilises aussi 3D Game Studio qui commence sérieusement à dater en termes d'outils ou Workflow mais que j'aime pour la rapidité de prototypage !
Et à moi de faire des compromis s'il y a lieu, mais je ne vises pas un jeu incroyablement complexe déjà !


Quel est ton style de jeu ?
quel est on gameplay ?
as tu faits des dessins 2D de concepts, des designs ?
est ce juste par loisir et passion ?
ou comptes tu le vendre ? sur quelle plateforme ?
Penses tu qu'il va attirer les gens ?
As tu pensé à faire un prototype, des cubes peuvent remplacer les personnages dans un premier temps si on peut les faire bouger/sauter etc ... ?
Et est tu vraiment motivé ?
est ce que tu serais prêt à viser plus petit dans un premier temps à et à finir quelque chose qui "tourne ?"


Je crois que ce sont les questions à te poser avant de décider de t'y mettre vraiment ou de dire qu'il n'y a pas de solution ?

J'avais légèrement participé à un test de MMo fait avec Unity avec des petits gars de la France , le truc super indie, graphismes pas top , mais pas trop pourris, un mini mmo basique : la connexion et réseau marchaient.
Mais là c'était une petite équipe, y'avait même un coder dédié à tout le code réseau et logins / compte.
Après la physique et le réseau , peut être tu vises haut et c'est des spécialistes il te faut ?? ou des forums plus dans le style GameDev et autres.

C'est vrai y'a aucune solution parfaite, des fois il te faut faire des compromis ou ajouer des briques toit même ou quelqu'un de ton équipe si tu es en team !

Après si tu vises de créer un truc meilleur que BAttleField 3 , avec meilleurs graphismes, meilleure physique et réseaux : on ne peut rien pour toi

[seeme]

Je ne suis pas d'accord, seeme.
Je me disais la même chose que toi avant de découvrir unity et là je me suis aperçu qu'en réalité la difficulté vient de l'aspect historique du développement des jeux vidéos. Nombre de moteur en sont restés en grande partie à la vieille conception qui date de Doom pour lequel il fallait optimiser la moindre instruction à cause des limitations matérielles de l'époque.
Aujourd'hui ce n'est plus de mise. Les cartes vidéos peuvent avaler un nombre ahurissant de polygones, textures, shaders et font même la physique.
Quand on regarde les démos de la plupart des moteurs on voit bien que la course à la qualité de rendu est en train de se terminer. La qualité d'unreal ou de crysis se retrouve aussi bien dans unity qu'irrlicht ou torque pour peu que les graphistes soient bons.
Evidemment on peut toujours mettre une carte vidéo à genoux en lui envoyant 10 000 personnages à afficher en pleine jungle sous la pluie avec le feuillage qui bouge lors des collisions. Mais ce n'est plus vraiment du domaine du moteur.
Il y'a un nombre astronomique de moteurs de jeux proposant tous des rendus haute qualité avec des shaders. Les techniques sont connues et éprouvées.
Les moteurs se distinguent désormais par le nombre de fonctionnalités et leur facilité d'utilisation. Crysis et l'UDK par exemple sont largement plus complets qu'Ogre qui ne fait que de l'affichage, à la base.
Y'a qu'a voir la liste sur devmaster ou les démos sur gamedev.

Je ne suis personnellement pas un grand fan d'unity, mais bref

Si je prend la vidéo présentée en galerie sur le site d'unity, je trouve qu'en ce qui concerne les rendus non réalistes, unity s'en sort bien mais sur le réaliste, clairement.. non. Pour moi unity prend une orientation développement web et tablette (prototypage aussi), ils ne cherchent pas à se positionner face à des monstres comme l'udk que tu citais (si je suis méchant je dirais aussi que même sur le non réaliste, y a de la marge par rapport à un little big planet par exemple).

L'argument sur la technologie d'aujourd'hui est faux. Aujourd'hui encore (et à mon avis pour encore très longtemps), on optimise au mieux, il arrive encore que l'on doive passer par des petits tweaks en assembleur (ok c'est rare, mais ça arrive). On ne peut pas faire des choses pas/peu/mal optimisées au prétexte que le hardware suit, ça ne fonctionne pas et c'est la mort de l'innovation.

Un studio qui réfléchis comme ça ne pourra jamais s'en tirer sur le marché des poids lourds (PS3, 360, PC) à moins d'un concept béton et aujourd'hui, même s'il existe des exemples (minecraft en tête), ils sont plutôt rares.

Une autre notion capitale que tu abordes est la course à la qualité. Oui, on peut faire des choses très bien avec ogre ou irrlicht, mais si tu dis à un graphiste tu as 100 poly pour me faire le personnage principal, c'est pas la même que si tu lui dis t'en as 100 000 (à toi d'optimiser derrière).

Concernant la partie sur la carte à genoux, je ne vois pas en quoi ce n'est pas du domaine du moteur. Si l'on prend un moteur de jeu en général, si, c'est carrément son domaine de faire en sorte que tout soit affiché correctement, que le netcode tourne bien, que la mécanique de jeu est respectée etc.. Si on s'attache uniquement à l'aspect rendu, c'est au moteur de faire ce qu'il peut avec le budget qu'on lui donne (le jv, c'est comme le cinéma, c'est du carton pâte, on essaye de donner l'illusion, mais en gros dès qu'on s'éloigne du point de vue, il n'y a plus grand chose à voir...).

Les shaders, c'est (souvent) du blingbling, si ton moteur, tes algorithmes et tes structures de données qui sont derrière sont mauvaises, c'est mort, et ça, c'est un métier

Un moteur de jeu général se distingue par le fait que ce qu'il fait, il le fait bien. Un moteur, c'est par essence spécialisé (ou alors compromis cf mon post précédent), pas par le fait qu'il fasse le café. On fera particulièrement attention à cet art subtil qui est que tout ce petit monde fonctionne ensemble, de manière cohérente et dans les budgets temps/mémoires alloués.

[Freem]

Cette discussion m'a amené à fouiner un peu sur le sujet (principalement sur wikipedia) et il semble que justement, un moteur de jeu soit à différencier de ses composants.

En fait, il semble qu'un moteur de jeu soit la réunion d'un moteur physique/collision, un moteur de rendu/affichage (2D ou 3D), d'un "moteur" d'IA, d'un moteur de script, d'un moteur de son, et d'un moteur réseau dans le cas des jeux multi-joueurs. (d'ailleurs, suis tombé sur PAL pour la physique, qui est en fait une couche d'abstraction pour changer de moteur physique sans toucher le code, si ça intéresse quelqu'un...)

Donc il s'agit de quelque chose qui n'est pas spécialisé, de ce point de vue.

Par contre, les moteurs semblent spécialisés dans un type de jeu: FPS, simulation, RPG... il y à donc une importance de l'optimisation.

Pour la physique par exemple, la gestion des collisions sera beaucoup moins importante dans un RPG ou MMO RPG que le système de scripts et/ou d'IA.
De même, selon le réalisme que l'on veut, les algorithmes semblent radicalement différents, idem pour le rendu visuel.

Conclusion:
Il semble que l'optimisation reste encore et toujours d'actualité. C'est la même raison qui fait que les jeux commerciaux sont encore très codés en C/C++, et pas en JAVA ou C# (ceux pour lesquels j'ai vérifié en tout cas)

Sur ça, et aussi sur le fait que les dev croient la performance évolutive à 1000%. Les jeux sont développés pour être vendus, et rapporter de l'argent, souvent. Donc ils doivent cibler un maximum de gens, les joueurs ne sont pas tous prêts à s'acheter une nouvelle console/machine à chaque sortie d'un jeu.

En plus, négliger l'aspect performance d'un jeu, ça implique qu'il faut plus de temps pour débuguer le programme. Une compilation en debug est excessivement plus lente qu'une compilation en release, car moins optimisée.
Si la debug est trop lente, elle deviens inutilisable, et donc, non débugable. (et débuguer un programme en release, sans correspondance entre le code source et le binaire, c'est juste une gageure. C'est bon pour les gurus et les crackeurs qui ciblent un truc très précis et qui sont rôdés à des outils très spécifiques)

Un exemple qui me viens en tête au sujet de ces optimisations:
Nexuiz2 ne fonctionne pas sur mon netbook (4 images/s, peut-être?), alors que openarena lui fonctionne. Et un autre jeu, très moche et limité, lui, comparé aux deux autres, rame.
Le même phénomène se retrouve avec d'autres types de jeux, STR notamment.

Par contre pour ces points:

Quel est ton style de jeu ?
quel est on gameplay ?
[...]
As tu pensé à faire un prototype, des cubes peuvent remplacer les personnages dans un premier temps si on peut les faire bouger/sauter etc ... ?
Et est tu vraiment motivé ?
est ce que tu serais prêt à viser plus petit dans un premier temps à et à finir quelque chose qui "tourne ?"

Ce sont effectivement des questions vitales, mais elles ne se limitent clairement pas qu'aux jeux: pour les 1ères, il s'agit de réfléchir avant de coder, et les autres correspondent d'assez près à K.I.S.S. qui est une philosophie.
On peut faire de choses de grande ampleur, mais il faut être réaliste sur le fait qu'elles ne se font pas en 2 jours ni 2 mois.

[Acropole]

Je me suis surement mal exprimé. L'optimisation est importante, en effet, mais quelle est la différence de qualité entre Rage sorti en 2011 et Crysis sorti en 2007 ?
La perte en optimisation est négligeable face au gain apporté par un système générique. Même en "rabaissant" la qualité au niveau de Crysis 1 la qualité reste largement suffisante.

[patmaba]

C'est la jungle.
Voilà pourquoi c'est difficile d'être satisfait.

Ces listes non-exhaustive vous donne le tournis.
http://en.wikipedia.org/wiki/List_of_game_engines
http://devmaster.net/devdb/engines

[seeme]

Je me suis surement mal exprimé. L'optimisation est importante, en effet, mais quelle est la différence de qualité entre Rage sorti en 2011 et Crysis sorti en 2007 ?
La perte en optimisation est négligeable face au gain apporté par un système générique. Même en "rabaissant" la qualité au niveau de Crysis 1 la qualité reste largement suffisante.

Pour toi probablement, mais regarde à la fnac ou chez un revendeur de jv, combien de kikoolol achète un jeu juste parce qu'il va leur permettre de faire un concours de stoukettes carte graphique avec leurs potes ...

En plus, négliger l'aspect performance d'un jeu, ça implique qu'il faut plus de temps pour débuguer le programme. Une compilation en debug est excessivement plus lente qu'une compilation en release, car moins optimisée.
Si la debug est trop lente, elle deviens inutilisable, et donc, non débugable. (et débuguer un programme en release, sans correspondance entre le code source et le binaire, c'est juste une gageure. C'est bon pour les gurus et les crackeurs qui ciblent un truc très précis et qui sont rôdés à des outils très spécifiques)

Un exemple que j'ai eu récemment à un entretien, on me donne un extrait asm, l'état des registres et on me dit "qu'est ce qui a planté". Ça m'a surpris mais ils m'ont avancé cet argument imparable: "et quand ça plante chez le client, t'es en debug ou en release gros malin :p "

[comboDev]

Il semble que l'optimisation reste encore et toujours d'actualité

Bien sûr , et Crysis en use mais largement , il suffit de voir les LOD , ou les personnages qui au loin utilisent plus le même shader et ont bien moins de polygones.Distance affichage des structures, de l'herbe etc ...
Après il y a l'optimisation au niveau des structures , affichage du terrain ect ... il y a mille et une façon et sans ça , ça tournerait difficilement même avce une très bonne carte.
Il y a même l'optimisation coté level design , les gars vont pas placer 36 Sources de lumières influant les mêmes objets et shaders au même endroits :
beaucoup trop de calculs !

Mais même avec des moteurs un peu vieux : somme Source Engine,
avec un lightmapping de grande qualité on arrive à un coté très réaliste !
Comme quoi y'a pas que le moteur , la technique utilisée peut grandement jouer !


Second sujet , le monde des Indies est varié et on a pas pour but de faire de gros jeux rivalisant avec des boites ayant plus de 200 personnes derrière gérant le level design, gameplay, animations, musique, marketing etc ...

Une bonne règle c'est de choisir le moteur en fonction de ce que l'on sait faire
(coding, 3D art) et du type de jeu !
Un codeur qui n'y connait pas grand chose en modeling/sculpting/animations/texturing/uv ça risque être dur , sauf s'il achète des packs 3D et textures ou fait appel à un 3D artist dans son équipe.
Et des petits projets qui réussissent en équipe il y en a pas mal et qui échouent aussi !

Les technologies, moteurs 3D sont là, des jeux sortent et sont vendus avec.
Il suffit de fouiller , voir ce qui te correspond le mieux et que tu penses pouvoir arriver à utiliser et y aller !


La question n'a pas trop de sens pour moi, mais est intéressante du fait de partager des avis.
Je dirais plutot :
"dis nous quel type de jeu tu veux faire, à quelle dimension et on essaierai de te guider si on a des idées " !