Depuis maintenant quelques années que je fréquente ce forum, j'ai croisé très régulièrement de nombreuses idées reçues sur les moteurs de jeu, ces environnements facilitant la création d'un jeu vidéo. On peut citer parmi eux :
Unreal Engine (UDK), un des plus anciens et connus, toujours le leader ;
Source Engine, le moteur des jeux Valve, enseigné depuis longtemps sur le SdZ ;
Unity 3D, un moteur générique plus récent ;
CryEngine, le moteur de Crytek ;
Et bien d'autres encore.
J'ai décidé de me lancer dans cette sorte de grande FAQ car ces technologies sont finalement assez méconnues, et souvent délaissées par les amateurs au motif qu'ils seraient "trop simples". Ce sujet cherche à tordre le coup à quelques idées reçues et à donner quelques conseils sur la création de jeu vidéo en général.
Je prendrais régulièrement l'exemple d'UDK car c'est le moteur que je connais le mieux : ne prenez pas ça comme de la publicité. Les concurrents cités au dessus sont parfaitement utilisables.
Idée reçue N°1 : les jeux vidéo, c'est impossible
La création de jeux 3D, c'est un grand classique, notamment sur le Site du Zéro. Qui n'a jamais rêvé de créer son jeu ?
Souvent, la première des remarques qui arrive sur un tel sujet, c'est
Citation : Message typique
Tu n'arriveras jamais à faire un jeu 3D. Il faut une équipe de 200 personnes et dix ans de travail.
Mais pourtant, c'est faux ! Aujourd'hui, il y a des outils de développement adaptés qui permettent en quelques mois, à une équipe réduite de développer un FPS basique, comme un clone de Counter-Strike par exemple. Bien entendu, ça demande un travail acharné et des compétences solides en programmation, en design, en modélisation, en son et c'est la vraie difficulté : aucune solution technique ne fera le boulot à votre place.
En revanche, pourquoi implémenter le N° moteur de rendu 3D de la planète ? C'est un problème ancien qui a déjà été résolu des centaines de fois. Le principe d'un moteur de jeu est de centraliser les problèmes les plus courants pour faciliter le travail :
Rendu 3D
Code réseau
Gestion du son
Importation 3D
Création de niveaux
Pour autant, un moteur de jeu typique vous proposera une démo, et un code très basique qui ne gèrera probablement rien de plus qu'un personnage et une arme. C'est encore à vous de créer votre jeu vidéo : simplement, au lieu d'assembler des bibliothèques plus ou moins complètes et compatibles, vous utilisez un environnement intégré.
Idée reçue N°2 : un jeu vidéo, c'est facile, il suffit de motivation
Citation : Message typique
On est motivés, c'est sûr qu'on va réussir.
Malheureusement, c'est aussi faux que l'extrême précédent. Il faut des compétences tellement variées qu'il est essentiel de se regrouper pour créer un jeu 3D. Listons donc les postes critiques d'un tel projet, sur le plan technique :
Programmeur(s)
Modélisateur(s) 3D, level designer
Artiste son / Compositeur
Webmaster (eh oui...)
A ces compétences techniques, se rajoute la tâche difficile de gérer le projet. Un tel poste n'est pas concevable sans une expérience basique de tous les domaines cités : ça ne s'improvise pas, ce n'est pas le poste de celui qui ne sait rien faire, ce n'est pas le poste du glandeur, ce n'est pas non plus le chef qui décide de tout. C'est un poste difficile.
Attention à votre recrutement : ne recrutez pas vos amis proches parce qu'ils sont motivés, là tout de suite sur le coup. Recrutez sur la base de l'expérience, de la compétence, des travaux réalisés par le passé : ne recrutez jamais quelqu'un qui n'a jamais fait quelque chose de sérieux avant, de lui-même !
Idée reçue N°3 : il faut des outils payants pour créer un jeu vidéo
Citation : Message typique
J'ai besoin de 1000€ pour acheter Photoshop.
Dans l'absolu, ce n'est pas complètement faux. La suite Adobe au grand complet peut se révéler un allié de poids, les logiciels 3D de grandes entreprises également. En revanche, surtout si vous débutez, sachez découvrir les solutions gratuites voire libres.
Par exemple, il est parfaitement possible de développer un niveau de jeu vidéo moderne avec Blender et GIMP dans un moteur de jeu tel qu'UDK, qui est lui-même gratuit pour un usage non commercial.
Attention tout de même : ne soyez pas sectaires non plus. Vous vous apercevrez bien vite que ce qui compte, c'est la vitesse de développement et la qualité du travail plus que l'outil lui-même : choisissez avant tout ce qui vous convient !
Idée reçue N°4 : avec un moteur de jeu, on ne programme pas
Citation : Message typique
UDK/Unity/.. c'est pour les nuls, on ne fait pas de vraie programmation.
C'est probablement le propos le plus courant sur les moteurs de jeu : c'est aussi le plus faux.
Prenons l'exemple d'Unreal Engine ou UDK : son projet d'exemple est constitué d'environ 400 000 lignes de code. Si vous lisez ces lignes, il y a fort à parier que vous avez déjà programmé, mais quelle quantité de code avez-vous écrit dans votre vie ? Si vous êtes programmeur de métier, probablement plusieurs milliers ou dizaines de milliers... Imaginez dix fois cette quantité : oui, il faut réellement programmer avec un moteur de jeu, et pas qu'un peu.
La même critique est souvent faite sur les langages employés dans ces moteurs, parfois considéré comme des scripts sans complexité technique. Il n'en est rien, voici une liste des langages employés par chaque moteur :
UDK : UnrealScript, un clone de Java optimisé et réduit
Source Engine, Cry Engine : C++
Unity3D : C#, ou Javascript au choix
Ne voyez pas un moteur de jeu comme un logiciel pour créer votre jeu, voyez-le comme un environnement de développement, un laboratoire en quelque sorte, remplis d'outils pratiques.
Idée reçue N°5 : les moteurs de jeu sont limités
Citation : Message typique
Si tu veux faire un jeu original, il faut tout programmer soi-même avec OpenGL.
Là encore, c'est une erreur courante. Vous avez, plutôt que des limitations, des choix techniques déjà faits à bas niveau qui ne vous laissent pas la liberté de les modifier. En revanche, ces choix n'interfèrent pas avec le gameplay, le développement du jeu vidéo en lui-même, pour plusieurs raisons.
D'abord, un moteur de jeu est un environnement de développement et pas une machine à faire des jeux : il ne prend pas les décisions à votre place.
Le code d'un moteur ne s'attaque jamais au gameplay, ce n'est pas sa mission : il s'attaque à des problèmes de bas niveau et implémente des mécanismes basiques comme par exemple la notion de joueur, d'équipe, de score, mais sans jamais en fixer les règles : c'est à vous de les choisir et le moteur ne le fait pas pour vous.
Plus généralement, le moteur s'arrête à relativement bas niveau. Si vous souhaitez faire de la classe "Joueur" du moteur un véhicule ou un bâtiment, rien ne vous en empêche ! C'est le principe.
Enfin, si vous vous sentez limité par un aspect du moteur, souvenez-vous que bien souvent il permet de faire appel à du code extérieur, par exemple si vous souhaitez gérer Kinect...
En d'autres termes, ce qui est essentiel c'est de comprendre que vous aurez encore énormément de travail, même avec un moteur de jeu et rien qu'en programmation. Ce n'est pas une solution de facilité : c'est une solution réaliste.
Certains tendent à catégoriser les moteurs de jeu comme un outil automatique pour faire un clone de Call of Duty. Ne vous y laissez surtout pas prendre, c'est une vision particulièrement erronée de la réalité. En particulier, un moteur comme UDK ou Unity ne vous force pas à faire un type de jeu particulier, la seule limite est d'être en 3D : que ça soit un jeu de course, un FPS, une simulation, c'est possible et pas moins adapté dans un cas que dans l'autre.
Idée reçue N°6 : le moteur de jeu fournit du contenu gratuit, on n'a pas besoin d'en créer soi-même
Oui et non. Effectivement, un moteur tel qu'UDK propose une base de travail très conséquente et suffisante pour créer un jeu basique. Mais vous ne devez surtout pas vous en tenir là, ce n'est pas l'objectif ! Il faut voir ces éléments comme des démonstrations, des aides au développement pour créer votre propre contenu.
Le style visuel, c'est ça qui décide de la personnalité de votre jeu
Un jeu vidéo, ce n'est pas juste un programme, c'est une œuvre artistique et ludique et vous devez être bien conscient qu'en utilisant des éléments créés par d'autres, vous enlevez toute âme à votre création. C'est bien dommage !
Prenez le temps de développer votre contenu, recrutez d'autres créateurs pour vous appuyer.
Idée reçue N°7 : on peut faire aussi bien qu'avec un moteur de jeu, en faisant tout soi-même
Citation : Message typique
On peut faire aussi bien avec OGRE donc on va le faire.
C'est un discours ambitieux, et malheureusement irréaliste. En pratique, il faut réellement des années de développement pour créer un jeu vidéo si on ne s'appuie pas sur un environnement existant, et à ma connaissance les projets 3D amateur réalisés de la sorte ont un taux d'échec particulièrement dramatique.
Le plus grand piège, c'est de vous imaginer que ça sera facile avec un moteur de jeu, et que pour avoir du challenge, il faut faire tout soi-même. C'est une erreur terrible, et souvent fatale à des projets qui autrement auraient pu fonctionner. Même avec un moteur, vous avez encore des mois de travail devant vous, à plusieurs.
Souvent, les moteurs de jeu intègrent des solutions propriétaires, fermées et que vous ne trouverez pas ailleurs. Le choix de travailler avec vous appartient, mais leur statut de leader est bien souvent mérité : compression vidéo, génération de verdure, interfaces ou optimisation, ce genre de domaine d'expertise demande énormément de travail. Sachez mettre à profit un outil existant plutôt que de tout refaire vous-mêmes.
Mais alors, OpenGL ou OGRE, ça sert à rien ?
Non, évidemment, ces outils ne sont pas inutiles. Ils permettent eux aussi, dans l'absolu, de réaliser un jeu vidéo et ils ont un très grand intérêt pédagogique. Il existe d'ailleurs quelques projets fonctionnels basés sur ces technologies, sans moteur de jeu. Mais il faut bien voir deux éléments distincts :
l'aspect pédagogique de son travail, ce qu'on va apprendre ;
l'aspect objectif, ce qu'on va réaliser au final.
Ces deux aspects s'opposent dans une certaine mesure : on ne peut pas gagner sur l'un sans perdre sur l'autre, pour un temps donné. Quand on réalise un site Web, on peut faire les deux sans que ça prenne des années, mais dans le cas d'un jeu vidéo c'est une toute autre histoire au vu du travail considérable.
Si le résultat importe peu et qu'on veut apprendre, employer OGRE ou carrément OpenGL est une excellente idée, mais nuit considérablement aux chances de succès sur le plan du jeu lui-même tel qu'un joueur le percevra, ainsi qu'à sa qualité technique : rendu, performances, fiabilité... A vous de choisir votre objectif : n'espérez cependant pas concilier les deux.
En conclusion...
Il n'y a pas de solution garantie pour réussir un jeu vidéo 3D. Mais il y a une solution très fiable pour échouer, testée et désapprouvée avant vous par des centaines de passionnés et cette solution pour un échec, c'est de tout faire soi-même en comptant faire aussi bien. Vous avez encore un doute ? Parcourez les archives du Site du Zéro pour y retrouver des projets de jeux 3D...
N'hésitez pas à commenter dans ce sujet, à donner votre avis, à réagir. C'est aussi le but.
Merci d'exposer vos avis avec argumentation posée et construite, donnez des exemples.
Je suis tout à fait d'accord avec toi au niveau des moteurs, c'est très utiles et permet de faire des jeux vidéos plus rapidement mais n'oublie pas pour autant la programmation.
Le moteurs permet de faire les bases du jeux (qui sont déjà trèèès longue à faire) après c'est à nous de vraiment commencer à bosser avec les outils proposés.
Après il y aura toujours des personnes qui resterons à la bonne vieille méthode comme l'openGL, c'est leur choix, et c'est un risque.
En C++ il y a aussi SDL et SFML (je ne sais pas si c'est compatible avec d'autre langage), ce ne sont pas des moteurs à proprement parlé mais plus une "aide au développement" ça permet de simplifier le code et donc de travailler plus vite, mais ça serai plus conseiller pour la 2D je pense, même si on peut s'en servir pour la 3D.
Sinon bonne idée ce topic, il est incroyablement complet.
Salut
Avant toute choses justes deux petites corrections de rien du tout:
-Il me semble que ut a oublié la gestion de la physique dans les rôles du game engine.
-Il est aussi possible de programmer en Boo sur unity...bien que très rare
Bref,venons en aux faits Je suis globalement d'accord avec toi,pour avoir déja fait deux jeux sur unity,je sais qu'un projet ne se limite pas à quelques lignes de code sur un game engine.Le fait est aussi que souvent,les personnes ambitieuses pensent pouvoir réussir tout sans game engine car c'est "trop facile".
Cependant,en tant que grand défenseur de l'open source,je dois avouer que j'ai beaucoup aimé bosser avec ogre,rien que pour regarder dans son code source ^^.
Tout à l'heure j'ai dit qu'il y avait un manque de flexibilité dans les moteurs de jeu,je me suis mal exprimé.En effet,j'ai toujours été frustré par mon incompréhension par ce qui se passait en interne,c'est pour cela que j'ai beaucoup aimé ogre,il m'a permis de comprendre comment fonctionnait la bête Cependant,en étant réaliste,on voit bien que ce que l'on peut faire en 1 ans avec unity (ou UDK),met 10 ans sur Ogre...
Je suis d'ailleurs heureux que tu défende les programmes gratuits,trop souvent mis à part,j'entends beaucoup cette idée recue "blender c'est gratuit donc nul,faut utiliser Maya ou 3ds"... Oui,mais le fait est qu'à par le rendu et le support,blender n'a pas grand chose à envier à ces homonymes payants,et quand bien même il aurait de grands défauts,les équipes amateurs n'ont p-e pas les moyens de se payer du autodesk chez eux
Bon sujet qui m'a permis de remettre en place mes idées afin de m'exprimer(j'espère)de manière plus claire qu'au milieu d'un sujet qui n'avait rien à voir
Je suis d'ailleurs heureux que tu défende les programmes gratuits,trop souvent mis à part,j'entends beaucoup cette idée recue "blender c'est gratuit donc nul,faut utiliser Maya ou 3ds"... Oui,mais le fait est qu'à par le rendu et le support,blender n'a pas grand chose à envier à ces homonymes payants,et quand bien même il aurait de grands défauts,les équipes amateurs n'ont p-e pas les moyens de se payer du autodesk chez eux
J'ai personnellement toujours employé Blender et je pense qu'en dehors des soucis d'exportation dans certains formats fermés, il est très adapté au jeu vidéo. Impossible de ne pas le conseiller, au moins au début.
Citation
Cependant,en tant que grand défenseur de l'open source,je dois avouer que j'ai beaucoup aimé bosser avec ogre,rien que pour regarder dans son code source ^^.
Notons que Blender Game Engine, si il n'est pas aussi avancé que les outils que je cite, est fonctionnel, libre et gratuit. Je pense que c'est encore une solution préférable à OGRE et consorts, qui a le mérite d'être portable et libre, même si je ne le conseille personnellement pas.
Je dirais que pour faire un jeu vidéo, il faut aussi avoir des compétences en jeu vidéo (oui ça a l'air bête). Avant de se lancer dans un projet qui va prendre des mois, il faut avoir un scénario, un univers et surtout un gameplay intéressants qui tiennent la route. Quoi de plus inintéressant qu'un clone diminué de CoD...
Un jeu, surtout un jeu purement amateur, est fait pour être joué et apprécié ; s'il s'agit juste d'une démo technique du moteur avec 2-3 assets en rab et un univers débile, c'est pas tellement la peine de se lancer à mon avis.
Je trouve qu'on devrait épingler ce topic, ça aiderait encore plus de monde. Très beau boulot de ta part, comme d'habitude.
Comme je t'ai dit gwenn,je conseil quand même ogre à tout ceux qui veulent comprendre le fonctionnement interne d'un moteur,car il a l'avantage d'être véritablement bien foutu et clair.Si tu relis mon post,tu verra d'ailleurs que je n'en ait parlé que pour ca
J'ai bien entendu ton propos Raidtal. Mais je tiens quand même à séparer deux éléments :
l'aspect pédagogique, ce qu'on va apprendre
l'aspect objectif, ce qu'on va réaliser
Ces deux aspects s'opposent dans une certaine mesure : on ne peut pas gagner sur l'un sans perdre sur l'autre, pour un temps donné. Quand on réalise un site Web, on peut faire les deux sans que ça prenne des années, mais dans le cas d'un jeu vidéo c'est une toute autre histoire.
Si le résultat importe peu et qu'on veut apprendre, employer OGRE ou carrément GLSL est une excellente idée. Je tiens uniquement à souligner que ça nuit considérablement aux chances de succès sur le plan du jeu lui-même tel qu'un joueur le percevra.
un échec, c'est de tout faire soi-même en comptant faire aussi bien. Vous avez encore un doute ? Parcourez les archives du Site du Zéro pour y retrouver des projets de jeux 3D...
Excellente initiative, histoire de tordre un peu le cou aux idées reçues, il faut vraiment voir les moteurs de jeux actuels comme des frameworks, le but est vraiment de donner une base de travail, pas de le faire à la place du programmeur.
Par contre je ne peux que conseiller avant de se lancer dans l'apprentissage d'un moteur de passer par la création d'un minuscule jeu 3D (un tetris, un pong, n'importe quoi...) via OpenGL/Direct3D. C'est à mon avis (qui vaut ce qu'il vaut) essentiel afin de comprendre les principes et les enjeux qui se cachent derrière ces moteurs.
Par contre je ne peux que conseiller avant de se lancer dans l'apprentissage d'un moteur de passer par la création d'un minuscule jeu 3D (un tetris, un pong, n'importe quoi...) via OpenGL/Direct3D. C'est à mon avis (qui vaut ce qu'il vaut) essentiel afin de comprendre les principes et les enjeux qui se cachent derrière ces moteurs.
C'est aussi une idée, oui. Une autre chose que je conseille est de se tenir au courant de ce que qui se fait, comment les moteurs fonctionnent, c'est important aussi pour construire un jeu vidéo. Ce qui est crucial, c'est de choisir un outil adapté à ce qu'on souhaite et aux moyens qu'on a.
Citation : Nicoreda
Tien, je me sens visée
Je ne vise personne, le but n'est pas de descendre des projets ou quoi que ce soit hein. Je veux juste encourager l'usage de solutions plus adaptées, encourager les gens à s'associer pour réaliser des projets, et en finir une bonne fois pour toutes avec cette opposition qu'on imagine entre programmation et moteur de jeu. De la programmation il en faut. Beaucoup. Vraiment.
C'est un peu HS, mais j'ai une question: peut-on faire un jeu de stratégie au tour par tour (en 3D) avec un moteur de jeu tel que UDK?
Sinon, je pense que ce topic est une excellente idée. Tu devrais en mettre le lien au début de ton tuto
C'est un peu HS, mais j'ai une question: peut-on faire un jeu de stratégie au tour par tour (en 3D) avec un moteur de jeu tel que UDK?
Que ça soit Unity3D, CryEngine, UDK ou un autre c'est possible : comme je l'explique au point 5, un moteur propose des concepts abstraits voire aucun concept de gameplay tout court.
Par exemple dans UDK, la classe représentant un personnage, "Pawn", est directement au dessus de la classe "Vehicle" dans l'arbre d'héritage parce que sur le plan technique, un véhicule et un piéton finalement, c'est un objet visible, mobile, animé et contrôlable par un joueur, autant dire la même chose : au final un Vehicle, c'est un Pawn qui peut en contenir d'autres et a un modèle physique plus avancé.
Et si toi tu décide de faire un RTS, tu peux décider que la classe Vehicle ne sert à rien parce que dans ton jeu un véhicule est une unité normale, et utiliser uniquement Pawn avec autant de sous-classes que de types d'unités. C'est à toi de le décider, comme moi j'avais décidé pour mon tower-defense zFortress que chaque tour était un Pawn, par simplicité. Ces classes sont très abstraites, au sens littéral du terme : les choix imposés sont techniques et pas stratégiques.
C'est toute la subtilité et toute la difficulté de l'exercice pour les développeurs de moteurs : implémenter le maximum de mécanismes, sans jamais restreindre les possibilités. Démonstration avec deux jeux utilisant le même moteur : qui pourrait s'en rendre compte sans le savoir ?
Quoi de plus inintéressant qu'un clone diminué de CoD...
Mince alors, c'est pourtant un jeu si intéressant...
@Gwenn: Je pense que tu pourrais inclure
Citation : Gwenn
l'aspect pédagogique, ce qu'on va apprendre
l'aspect objectif, ce qu'on va réaliser
Ces deux aspects s'opposent dans une certaine mesure : on ne peut pas gagner sur l'un sans perdre sur l'autre, pour un temps donné. Quand on réalise un site Web, on peut faire les deux sans que ça prenne des années, mais dans le cas d'un jeu vidéo c'est une toute autre histoire.
Si le résultat importe peu et qu'on veut apprendre, employer OGRE ou carrément GLSL est une excellente idée. Je tiens uniquement à souligner que ça nuit considérablement aux chances de succès sur le plan du jeu lui-même tel qu'un joueur le percevra.
directement dans le premier post, histoire que les gens qui - comme moi - font des jeux en OpenGL pour la maitrise et non pour l'objectif, ne se sentent pas agressés
PS: le message "J'ai besoin de 1000€ pour acheter Photoshop." a réellement été posté ici.
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
PS: le message "J'ai besoin de 1000€ pour acheter Photoshop." a réellement été posté ici.
Tous les messages que je cite dans le post, à la formulation près et encore ont été vus sur le SdZ, c'est justement ce qui me fait écrire ces lignes. Pas pour se moquer, pas pour caricaturer mais parce que ce sont réellement des discours qu'on trouve un peu partout.
Je rajoute le paragraphe au début, l'objectif n'est en aucun cas de critiquer ou rabaisser le travail de quiconque, merci de la remarque.
PS : voilà qui est fait.
Excellente initiative et excellent post, y'a plus qu'a prier pour qu'il passe en post-it (avec ou sans en tout cas on pourra se contenter d'un lien vers ce post dès qu'un zéro absolu viendra poser une question sur comment faire un jv =P)
Très bon post, qui mériterais de figurer en post-it. On vois beaucoup de projets qui n'utilisent pas de moteurs et qui du coup n'avancent pas, alors qu'ils auraient pu très bien réussir sinon. D'ailleurs ça m'étonne pas du tout puisse que je pensait la même chose une fois fini mes premiers tutos du SDZ, et qu'il m'a fallu moult déboires avant de me rendre compte de mon erreur.
D'ailleurs petite question, XNA est-il un choix valable comparé aux moteurs cités ci-dessus? Sachant que je ne vise pas des graphismes au top de la technologie, sans être simplistes non plus, et que je n'ai pas besoin d'éditeur de map (génération procédurale).
J'ai ici quelque chose qui pourrait donner de l'eau au moulin de certains étant indécis concernant le moteur à choisir http://devmaster.net/devdb/engines
D'ailleurs petite question, XNA est-il un choix valable comparé aux moteurs cités ci-dessus? Sachant que je ne vise pas des graphismes au top de la technologie, sans être simplistes non plus, et que je n'ai pas besoin d'éditeur de map (génération procédurale).
Je n'ai jamais utilisé XNA, je ne peux que difficilement conseiller là-dessus...
Citation : Raidtal
J'ai ici quelque chose qui pourrait donner de l'eau au moulin de certains étant indécis concernant le moteur à choisir http://devmaster.net/devdb/engines
Les critiques m'ont semblé justes
Merci pour le lien. Attention, il y a des trucs très variables, des projets pas du tout sérieux également et j'ai l'impression que les commentaires sont rédigés par les développeurs des moteurs... Méfiance. Dans l'absolu, l'idéal est d'en discuter sur le forum Mapping & Modding qui est dédié à ça pour avoir des retours d'expérience, en particulier pour les moteurs classiques et bien connus dont je parle plus haut : Source, UDK et Unity sont bien connus ici, je pense que pour un projet sur le SdZ choisir un de ces trois-là est une bonne idée côté support.
pour programmer son jeu dans le moteur unreal engine 4 qui sortira surement cette année, ça sera en unrealscript ou c++ ! Et apparament le kismet sera encore plus puissant ! http://gameindustry.about.com/od/trend [...] irst-Look.htm
Je suis à la fois d'accord et pas d'accord avec toi (et là je m'arrète là )
Bon, j'ai aussi vu le début du débat sur l'autre topic. Je te rejoint sur certain points: il est vrai qu'utiliser un moteur de jeu permet d'économiser du temps sur pas mal d'aspects techniques.
En revanche, j'ai déjà fait une démo de jeu avec OpenGL (enfin, LWJGL) proposant un gameplay que l'on retrouve rarement, et lorsque j'ai voulu porter ce que j'avais fait sur un moteur (jmonkeyengine) je me suis cassé les dents.
Pourquoi ? Parce que, en plus d'avoir intégré une utilisation facile du moteur de rendu (ce qui est une bonne chose), le jme a aussi intégré un moteur physique (ce qui est une bonne chose me direz vous). Sauf que le moteur physique est buggé et ne correspond pas à mes attentes.
Pour résumer les problèmes qui m'ont fait fuir:
1. La classe de collision d'un character (le controleur qui ne subit pas de force) ne gère pas la gravité qui n'est pas verticale.
2. Toujours cette même classe passe au travers des vertex trop grand. (eh oui)
3. Toujours cette même classe entraine un bug lorsqu'elle se collisionne en phase montante).
Vous allez me dire que ce n'est qu'une classe, mais il faut quand même savoir que cette classe est assez importante. Bref, j'ai aussi rencontré deux trois bugs intéressants lorsque j'ai un peu poussé les capacités du moteur physique (vitesse extrème, poids extrème).
Cela ne vient pas du moteur de rendu, mais du moteur physique. Mais quand j'utilise un moteur de jeu, j'attend tout de même que les gestions des collisions soient mathématiques et pas approximatives.
De plus, j'ai également découvert des problèmes lorsque j'ai voulu mettre une skybox: la nécessité d'avoir opengl2 en support sur la carte graphique (alors que lorsque je travaillais avec l'opengl directement j'avais réussi à avoir la skybox sans problème par mes propres moyens).
jme n'est pas un moteur si jeune, mais après avoir été enthousiasmé par ses exemple (et par le faible nombre de lignes de codes nécessaires pour les réaliser) j'ai été très déçu par ses bugs et ses incohérences.
Je ne sais pas si tous les moteurs de jeu sont ainsi, mais je ne l'espère pas.
Enfin, je dirai surtout que le débat moteur de jeu/moteur de rendu +mimine est un faux débat. Le principal problème des jeux, c'est l'abscence d'analyse du travail à faire.
J'ai déjà exprimé ce problème dans un autre post, et j'ai commencé à rédigé un "article" dessus. Pour faire court, les devs passent de l'étape "je créé un logiciel en ligne de commande" à "je créé un logiciel fenếtré" et pensent que le temps qu'ils ont mis à franchir cette étape est le même que celui qu'il vont mettre pour l'étape "logiciel fenêtré" => "jeu video".
C'est complètement faux.
Dans un jeu, on retrouve deux choses: le moteur et les ressources.
Par ressources, j'entend:
1. les ressources graphiques.
2. les ressources audios.
3. les ressources vidéos.
4. les maps.
5. les effets spéciaux.
6. les animations.
7. les dialogues.
8. les capacités (armes pour les fps, sorts pour les rpg).
Et en fait, toute chose qui a la propriété d'avoir un cout "linéaire" (si on met dix fois plus de temps/de personne, on en a dix fois plus ou presque).
Le piège quand on développe un jeu, c'est de ne penser qu'au noyau (comme on l'a fait quand on est passé de la ligne de commande à la fenètre).
Les ressources sont des choses très chronophages, mais on peut prévoir le temps que l'on va mettre à les faires. Sauf que ce travail n'est jamais fait, ou lorsqu'il est fait on se rend compte qu'on y arrivera jamais.
A tous les joueurs du linux qui se plaignent de ne pas avoir de jeu solo (jeu multi+ia =/= jeu solo. jeu solo=jeu avec histoire ("halo", "turok", "ff6" etc.)), ne cherchez pas plus loin.
Parmi les ressources que j'ai cité, certaines sont simple à avoir (car elles peuvent être pompées sur internet, malgré les droits, que l'on oublie), mais d'autres non. Typiquement, on peut récupérer beaucoup d'image et de musiques, mais on ne peut pas récupérer des dialogues, ni des maps, ni les vidéos.
C'est pour ça qu'on retrouve souvent des jeux multi qui se passent en arène: la map est petite (si si), il n'y a pas de dialogue ni de vidéo...
Bref.
J'ai pas vraiment le temps de tout vous citer. Pensez juste à l'exemple "rpg maker xp" et à tous les jeux sortis dessus dont la durée de vie n'excède pas le quart d'heure (sauf à faire un tel gap de difficulté entre les zone qu'il faut farmer des heures). Ce "moteur de jeu" propose tout, on peut le personnaliser. Et là, au pied du mur, on voit les projets tomber les uns après les autres. On voit des gens perdrent leur temps à chercher des ressources, on voit des gens passer des heures pour avoir l'animation qu'ils veulent (en ajustant), puis à faire des dialogues, puis à faire des scripts pour des évènements pour au final ... finir le tout en dix minutes.
Le débat "moteur de rendu" vs "moteur de jeu" est intéressant, je ne dis pas. Mais en fait, il faut déjà avoir une équipe, et avoir planifié combien de parties contient le jeu, combien de ressources (et donc de temps) contiennent chaque partie et avoir fait la multiplication des deux (oui: préparer à l'avance cette planification évite d'avoir un début prometteur (riche) et une fin en carton (cf rpgmxp comme toujours)).
Ah oui, la conclusion de l'article était: développez des jeu contenant un principe innovant et n'essayez pas de faire un jeu type "commercial" (j'explique aussi pourquoi les jeux récents sont aussi répétitifs même si de plus en plus beaux etc).
Bon, j'ai aussi vu le début du débat sur l'autre topic. Je te rejoint sur certain points: il est vrai qu'utiliser un moteur de jeu permet d'économiser du temps sur pas mal d'aspects techniques.
En revanche, j'ai déjà fait une démo de jeu avec OpenGL (enfin, LWJGL) proposant un gameplay que l'on retrouve rarement, et lorsque j'ai voulu porter ce que j'avais fait sur un moteur (jmonkeyengine) je me suis cassé les dents.
Attention à ne pas généraliser les défauts d'un moteur très peu utilisé industriellement à tous les moteurs. Les problèmes que tu as rencontré n'existent pas dans les moteurs modernes. Si je prends l'exemple d'UDK, la physique est assurée via PhysX notamment, difficile aujourd'hui de faire beaucoup mieux.
De plus, j'ai également découvert des problèmes lorsque j'ai voulu mettre une skybox:
Même remarque, la notion de skybox est obsolète depuis plusieurs années, aujourd'hui on modélise un environnement et le sky n'est qu'un mesh parmi d'autres. Là encore, tu as choisi le mauvais moteur.
Très franchement, aujourd'hui déployer un jeu vidéo sans moteur de jeu qui implémente un mécanisme impossible à reproduire dans un moteur de jeu puissant, c'est extrêmement rare.
On ne m'a encore jamais proposé un concept de jeu 3D qui ne soit pas reproductible dans UDK par exemple : c'est là encore une idée reçue sur les moteurs. Si le moteur ne permet pas de faire votre idée, passez à Unity / UDK et il y a fort à parier que vous n'aurez pas le problème.
C'est un peu HS, mais j'ai une question: peut-on faire un jeu de stratégie au tour par tour (en 3D) avec un moteur de jeu tel que UDK?
Que ça soit Unity3D, CryEngine, UDK ou un autre c'est possible : comme je l'explique au point 5, un moteur propose des concepts abstraits voire aucun concept de gameplay tout court.
Par exemple dans UDK, la classe représentant un personnage, "Pawn", est directement au dessus de la classe "Vehicle" dans l'arbre d'héritage parce que sur le plan technique, un véhicule et un piéton finalement, c'est un objet visible, mobile, animé et contrôlable par un joueur, autant dire la même chose : au final un Vehicle, c'est un Pawn qui peut en contenir d'autres et a un modèle physique plus avancé.
Et si toi tu décide de faire un RTS, tu peux décider que la classe Vehicle ne sert à rien parce que dans ton jeu un véhicule est une unité normale, et utiliser uniquement Pawn avec autant de sous-classes que de types d'unités. C'est à toi de le décider, comme moi j'avais décidé pour mon tower-defense zFortress que chaque tour était un Pawn, par simplicité. Ces classes sont très abstraites, au sens littéral du terme : les choix imposés sont techniques et pas stratégiques.
C'est toute la subtilité et toute la difficulté de l'exercice pour les développeurs de moteurs : implémenter le maximum de mécanismes, sans jamais restreindre les possibilités. Démonstration avec deux jeux utilisant le même moteur : qui pourrait s'en rendre compte sans le savoir ?
Merci
Mais en fait, ma question était plutôt: peux-t-on faire du tour par tour?
C'est-à-dire que l'ennemi ne joue pas tant qu'on a pas appuyé sur le gros bouton rouge
Et une autre question: j'ai lu que UDK gérait l'IA. C'est vrai jusqu'à quel point? Je suppose qu'on peut (et qu'on doit un minimum) la coder?
Ben encore une fois, même réponse : le moteur n'a aucune influence sur le gameplay. A toute question du type "peut-on avoir ça dans le gameplay" je te répondrais systématiquement que oui puisque le moteur ne s'occupe juste pas du gameplay, c'est à toi de le développer.
C'est pareil pour l'IA, tu as quelques trucs proposés de base mais rien n'est décidé pour toi puisque ça restreindrait ta liberté. Il faut bien comprendre cette limite au rôle du moteur, c'est fondamental : le moteur ne touche PAS au gameplay, de près ou de loin.
Très bon post, va falloir updater la réponse semi auto qu'on fait en général sur les projet de jeux vidéo ratés. Sinon le moteur de jeu à une influence sur le rendu, mais elle est très faible voir négligeable selon les cas, mais on ne peut nier que chaque moteur à sa signature de part ses choix techniques. Mais il faut voir aussi, que dans le cas où le jeu est une fin et non pas un moyen la partie intéressante est le jeu lui même pas l'optimisation bas niveau. Et ce jeu occupera bien assez quand on vois le temps et l'argent nécessaire à faire un jeu AAA sur un moteur comme l'unreal engine 3 lancé en 2006 et source de dizaines de jeux, un moteur donc rodé avec lequel les développeurs sont habitués.
De plus il ne faut pas négliger les outils livrés comme les outils de mapping à la udk ou hammer qui sont indispensable dans la plupart des cas, donc développer sur son moteur c'est aussi prévoir créer son éditeur ce qui est une autre paire de manche. Enfin pour la qualité graphique des jeu il est nécessaire d'avoir des shaders et c'est aussi un travail très complexe & assez mal documenté dès qu'on sort des shaders les plus basiques surtout si on veut nos propres shaders adaptés, ça reste un travail important mais par exemple l'udk facilite la chose avec un système nodal ce qui est un argument de poids( il existe aussi un éditeur nodal pour source un peu plus bas niveau mais sympathique).
Tiens, bonne idée Gwenn. J'avais en tête un topic similaire expliquant en quoi il était moins avantageux dans 98% des cas de concevoir son propre moteur en lieu et place de l'utilisation d'une solution déjà disponible, je préparerai un post plus tard expliquant tout cela (il sera assez long à mon avis).
Citation : Thêta tau tau
D'ailleurs petite question, XNA est-il un choix valable comparé aux moteurs cités ci-dessus? Sachant que je ne vise pas des graphismes au top de la technologie, sans être simplistes non plus, et que je n'ai pas besoin d'éditeur de map (génération procédurale).
Qu'on soit bien clair, XNA n'est pas un moteur de jeu (en tout cas au sens entendu ici).
Par contre, si tu désires des moteurs utilisant cette "technologie", regarde du coté de PloobsEngine, DeltaEngine, XNA FINAL ENGINE (ils disposent tous d'un éditeur mais étant open-source, réadapter ces solutions peut répondre à tes besoins). Petit point en plus pour DeltaEngine qui dispose d'une petite communauté solide et d'une bonne documentation.
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."