Bien sûr, c'est le cas de certains. On pourrait citer Blender Game Engine, même si clairement il n'est pas du niveau des équivalents propriétaires ça reste mieux que rien, libre et gratuit avec en prime l'intégration au modeleur.
Si le résultat importe peu et qu'on veut apprendre, employer OGRE ou carrément GLSL 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.
Hormis ton jugement envers Ogre que je trouve un peu dur (le rabattre au niveau de OpenGL) mais probablement justifié lorsqu'on le compare à des solutions telles que UDK, qui semblent avoir ta préférence, je ne vois absolument pas le rapport entre la problématique "OpenGL versus moteur de jeu haut niveau" et l'utilisation du GLSL.
Non, OGRE n'est pas au niveau d'OpenGL évidemment, OpenGL représente encore un énorme niveau au dessus en difficulté.
Pour GLSL : eh bien, je ne comprends simplement pas ce qui te gêne, mais mon manque de pratique avec ce langage m'excusera, je l'espère. Ce que je veux dire par là, c'est que ça a certainement un grand intérêt technique d'écrire soi-même ses shaders, mais qu'à mon sens c'est incompatible avec la vision d'ensemble qu'exige un jeu vidéo.
Je suppose qu'il y a un truc technique que j'ai zappé et qui te fait bondir mais je me demande si ça apporte grand chose au sujet (comme pour ta précédente intervention sur le SdZ).
Pour GLSL : eh bien, je ne comprends simplement pas ce qui te gêne, mais mon manque de pratique avec ce langage m'excusera, je l'espère.
Eh bien je pensais à créer ou personnaliser quelques effets graphiques en écrivant ses propres shaders, pour un post-process ou un effet particulier. Mon manque d'expérience avec les moteurs de jeu m'excusera, mais je suppose que ce n'est pas incompatible ?
Pour GLSL : eh bien, je ne comprends simplement pas ce qui te gêne, mais mon manque de pratique avec ce langage m'excusera, je l'espère.
Eh bien je pensais à créer ou personnaliser quelques effets graphiques en écrivant ses propres shaders, pour un post-process ou un effet particulier. Mon manque d'expérience avec les moteurs de jeu m'excusera, mais je suppose que ce n'est pas incompatible ?
Bah, ça dépend des moteurs. Pour UDK, tu as une abstraction graphique pour écrire le shader qui te donne accès à des modules haut niveau pour construire ton shader à partir de templates existants (Phong, translucent, unlit, etc), en pratique j'ai dû en utiliser à peine 5% depuis que j'apprends le moteur.
Tu n'as pas accès au code du shader lui-même, mais je serais là encore curieux de voir un exemple d'effet irréalisable avec l'éditeur graphique : il y a quand même quelques trucs disponibles. Tu dois pouvoir faire 99% de ce qui est possible en écrivant le shader à la main, mais sans avoir besoin de programmer ce qui est quand même un énorme avantage.
Il me semble que CryEngine adopte le même mécanisme, pour Source de mémoire ça se limite à deux ou trois paramètres d'un template, pour Unity je sais pas du tout.
va falloir updater la réponse semi auto qu'on fait en général sur les projet de jeux vidéo ratés
Si tu parles du truc fait par XpLoDWilD, c'est plus pour signaler un projet non pensé/baclé qu'un projet qui veut révolutionner le monde en OpenGL uniquement (quoique ça dépend du niveau )
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
Dans unity les shaders sont écrits en shaderlab+cg...avant il y avait la possibilité d'inclure du GLSL mais c'est bien fini...il y a d'ailleurs un gros business de shader sur unity,ce qui est dommage,car la bibliothèque de shader de base n'est pas assez fournie à mon sens.
Tout de même quelque chose de très interessant dans ogre3D (parce qu'on parle de shader),et l'import via blender: http://ogre3d.fr/
Il suffit donc de modifier le material en changeant les paramètres et/ou en les modifiants par système nodale au lieu d'écrire tout un shader,ce qui est assez intéressant quand on sait bien se servir de blender de ce côté
Bah, ça dépend des moteurs. Pour UDK, tu as une abstraction graphique pour écrire le shader qui te donne accès à des modules haut niveau pour construire ton shader à partir de templates existants (Phong, translucent, unlit, etc), en pratique j'ai dû en utiliser à peine 5% depuis que j'apprends le moteur.
Tu n'as pas accès au code du shader lui-même, mais je serais là encore curieux de voir un exemple d'effet irréalisable avec l'éditeur graphique : il y a quand même quelques trucs disponibles. Tu dois pouvoir faire 99% de ce qui est possible en écrivant le shader à la main, mais sans avoir besoin de programmer ce qui est quand même un énorme avantage.
Oh d'accord. Je connaissais simplement (un peu) les systèmes de Ogre et Crystal Space, qui sont grosso-modo similaires mais à un niveau d'abstraction plus faible. Je ne doute pas de la puissance et la flexibilité de l'éditeur que tu cites, mais j'ai un exemple concret pour lequel je serais curieux de savoir comment ça fonctionnerait :
Apparemment, ça ressemble à un plugin ; j'imagine qu'on n'aurait pas non plus trop le choix avec UDK. J'avoue m'éloigner totalement du sujet dans la mesure où la technique est trop évoluée pour n'impliquer uniquement que des shaders. Mais je serais intéressé de savoir comment tu ferais avec UDK. Je pose la question en restant conscient que UDK n'est sans doute pas une plateforme d'expérimentation de techniques obscures.
Pour en revenir à la partie que j'ai citée au début, tu sembles sous-entendre que GLSL est à un niveau d'abstraction inférieur à Ogre, ce qui n'a pas trop de sens (c'est un peu comme si je comparais une banane (GLSL) à un gâteau aux fruits (Ogre), et OpenGL ça serait les fruits du gâteau (dont la banane)). Tu pourrais simplement remplacer GLSL par OpenGL.
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.
Merci pour ta réponse, je vais aller jeter un œil aux moteurs que tu me propose (j'avais cherché un peu mais pas encore trouvé de truc potable). Je sais que XNA est un framework plutôt qu'un moteur mais il est suffisamment haut niveau pour pouvoir faire un jeu en très peu de lignes, et je préfère ça aux interfaces graphiques. De plus contrairement à la plupart des moteurs de jeux 3D XNA permet de faire des jeux commerciaux tout en étant gratuit, c'est pas forcément mon objectif mais je préfère ne pas me fermer de portes.
Oh d'accord. Je connaissais simplement (un peu) les systèmes de Ogre et Crystal Space, qui sont grosso-modo similaires mais à un niveau d'abstraction plus faible. Je ne doute pas de la puissance et la flexibilité de l'éditeur que tu cites, mais j'ai un exemple concret pour lequel je serais curieux de savoir comment ça fonctionnerait :
Oh, ça me rappelle ce que présentait quelqu'un sur progmod.
Côté technique c'est intéressant, comme défi. J'admets volontiers que c'est typiquement le genre de chose qui est particulièrement difficile à faire dans UDK qui est extrêmement statique par conception. Si je devais tenter quand même, néanmoins, je pense que je partirais sur une approche très différente (et clairement moins puissante) en générant en dehors de l'éditeur une collection de chunks modulaires. Oui, c'est tout pourri comme méthode.
Pour refaire un parallèle avec le sujet d'origine, tu as tout de même constaté toi-même que c'est possible sous Unity et c'est un peu ce que je veux faire comprendre par ce sujet : y'a pas non plus qu'un seul moteur, il y en a plusieurs et Unity semble pour moi l'alternative parfaite à UDK si celui-ci ne va pas : plus moderne, plus flexible même si le rendu peut être moins puissant.
Citation : Fabien Léménash
Pour en revenir à la partie que j'ai citée au début, tu sembles sous-entendre que GLSL est à un niveau d'abstraction inférieur à Ogre, ce qui n'a pas trop de sens (c'est un peu comme si je comparais une banane (GLSL) à un gâteau aux fruits (Ogre), et OpenGL ça serait les fruits du gâteau (dont la banane)). Tu pourrais simplement remplacer GLSL par OpenGL.
Merci pour ta réponse, je vais aller jeter un œil aux moteurs que tu me propose (j'avais cherché un peu mais pas encore trouvé de truc potable). Je sais que XNA est un framework plutôt qu'un moteur mais il est suffisamment haut niveau pour pouvoir faire un jeu en très peu de lignes, et je préfère ça aux interfaces graphiques. De plus contrairement à la plupart des moteurs de jeux 3D XNA permet de faire des jeux commerciaux tout en étant gratuit, c'est pas forcément mon objectif mais je préfère ne pas me fermer de portes.
Ca, c'est à toi de voir en fonction de tes besoins, de tes attentes, ambitions etc. Grosso modo, il y a trois choix possible :
- Utiliser au maximum les possibilités d'un moteur de jeu (Unity, UDK, CE3,...) avec l'avantage de la portabilité. Cela évite d'avoir recours aux sources du moteur sauf nécessité absolue ou quelques optimisations.
- Utiliser un framework (comme XNA) en combinant différentes technologies, méthodes (génération procédurale par exemple) mais cela requiert la production d'une quantité parfois plus importante de code (dépend des projets). De l'autre coté, tu as une liberté absolue quant à la structure de ton code, les possibilités au niveau du rendu, réseau mais ça nécessite aussi de très grosses compétences dans plusieurs domaines qu'il est relativement impossible à avoir.
- Ou enfin, une solution intermédiaire. C'est à dire concevoir et/ou utiliser un moteur de jeu qui offre une base générique et un accès aux sources permettant l'intégration de nouvelles technologies, méthodes. Par exemple, Torque 3D (même si, pour l'avoir essayé, je trouve l'arborescence des fichiers totalement foireuse et avec le peu de documentation disponible, ça aide pas). C'est aussi la voie que se permettent certains développeurs pros. C'est également le cas des moteurs que je t'ai cité précédemment, l'accès aux sources te permet de fignoler ça à ta guise.
C'est aussi cette voie que je choisis quand je désire tester l'intégration (notamment tout ce qui est génération procédurale, réseau et graphique) de techniques ou d'outils utilisés par les pros. Dans ce but, je développe depuis 4 ans (pas seul, j'ai eu de l'aide de plusieurs personnes au cours de ces années) un moteur de jeu où j'ai intégré par exemple Bullet, PhysX, HBAO, FFT Ocean en me basant notamment sur les travaux d'Eric Bruneton. Me concernant donc, la conception d'un moteur découle d'une volonté de recherche (c'était à la base un projet d'étude) plus que d'une volonté de conception d'un jeu.
Le problème est toujours de savoir, fondamentalement et selon les besoins, quand utiliser une solution et quand en concevoir une. Aujourd'hui, 98% des projets peuvent être aisément réalisés en utilisant des solutions comme UDK, pour des projets où il est nécessaire d'avoir à pondre plus de code ou pour des projets de recherche, généralement on se trouve dans les 2% qui restent. Bref, avant de concevoir son jeu, il importe de savoir quelles solutions s'offrent à nous, en fonction de quel besoin (nécessite un énorme contrôle sur le code réseau,...), etc. Ce sont les premières questions qui doivent être répondues. Une fois cela fait, on a déjà une meilleure idée, reste plus qu'à peser le pour et le contre et choisir la solution qui correspond le mieux.
Edit: Et c'est valable peu importe le projet quand on y regarde de plus près. Qu'il s'agisse d'un logiciel quelconque ou d'un jeu, réinventer la roue n'est généralement pas la solution.
Non. Epic Games ne prend rien du tout pour un jeu gratuit, demande 99$ de licence pour un jeu commercial sans autre condition, et au delà de 50 000$ de chiffre d'affaire (et pas de bénéfice), ils exigent 25%.
C'est de toute façon un détail. En France, il faut être une entreprise pour commercialiser un jeu vidéo, et entreprise implique salariés, charges et avec un salarié au SMIC, on dépense déjà plus chaque année que cette limite de chiffre d'affaire. En d'autres termes, si la boîte est rentable la limite sera de toute façon forcément dépassée.
Pour PS3/XBox, il faut contacter les éditeurs. C'est de toute façon réservé aux pros vu le coût de déploiement d'un jeu sur ces plateformes (accessoirement Sony ne fait du chiffre que sur la vente de jeux et pas sur le matériel, forcément ils prennent une commission).
On est obligés d'être une entreprise pour vendre un jeu? Même si on est seul à l'avoir fait, et qu'on héberge son site dans un autre pays?
D'ailleurs, on peut créer une micro-entreprise, non?
En France, pour faire du commerce il faut un statut légal et l'imposition qui va avec (c'est un peu ça, le but en fait). Ce que je cherche à rappeler, c'est que si vous vendez un jeu 10€, le client paye 11.96€, et vous percevez 10€ - 25% (UDK) - la commission de la distribution (Steam c'est dans les 30%), et que de ça il faut encore déduire les charges salariales et patronales, en plus des coûts de fonctionnement : autant dire qu'il faut en vendre des copies pour manger à la fin du mois parce qu'avec 50K de CA, vous n'avez pas de quoi payer un salarié trois mois.
Pour faire simple, c'est un détail cette limite, que vous soyez un particulier ou une entreprise vous n'êtes pas concernés, autant simplifier à "entreprise = 25%".
Gwenn, je ne sais pas si le topic convient, mais j'espère que oui
Voilà: je suis au début de ton tuto, quand tu explique comment fonctionne Kismet. Tu proposes de faire clignoter une lampe. Or j'ai bien suivi tes instructions, mais la lampe ne clignote pas. UDK m'indique que c'est parce que la lampe est "static". Comment la "déstatiquiser"?
Et la création de shaders sans code, la manipulation graphique des animations, les destructions dynamiques, le scripting visuel, les systèmes de particules...
OGRE est un moteur 3D, pas un moteur de jeu, et il lui manque ce qui est réellement important : un environnement 100% graphique pour les artistes.
Un moteur qui rend les artistes dépendants du code est inutilisable dans un projet sérieux.
Les shaders en visuel : vital. Aucun artiste n'est capable de programmer un shader, ce n'est pas son job, et à raison de 1 à 5 shaders par objet...
La manipulation des animations : quand tu vise avec la tourelle d'un tank, c'est une animation et pour des raisons évidentes, elle ne se fait pas dans Maya mais directement dans le moteur suivant le mouvement du joueur. Dans UDK, il y a un système très avancé de contrôle de l'animation bone par bone, en visuel, avec des contraintes, contrôles, etc, tous chainés... Là encore, pour réaliser un personnage, un tel système est indispensable
Les systèmes de particules : un FPS basique c'est une centaine de systèmes de particules au bas mot, la plupart avec une bonne vingtaine de paramètres dédiés. Il est parfaitement vital d'avoir un éditeur graphique temps réel pour ça.
Le scripting : un artiste ne sait pas programmer. Exit les langages textuels : tous les moteurs sérieux font du visuel.
Citation
Enfin je vois pas pourquoi ils coderaient ?
Avec OGRE, à chaque fois que tu fais quelque chose chose, l'artiste doit faire appel à un programmeur. C'est complètement stupide et antiproductif. Les outils que je cite ne sont ni anecdotiques, ni fournis avec OGRE. Il les faut, c'est une impérieuse nécessité, mais OGRE ne s'en occupe pas parce que c'est un moteur 3D, et pas un moteur de jeu.
La définition du moteur de jeu moderne, on l'aura avec Unreal Engine 4 : possibilité de créer un FPS jouable entièrement dans du code visuel. Bien entendu, ça ne suffira pas pour un vrai jeu, mais la possibilité est donnée aux artistes de travailler à 100% indépendamment des programmeurs.
Salut
Bravo pour ce topic vraiment utile .
Je ne suis par contre pas d'accord avec toi quand tu dis qu'un projet necéssite un webmaster et de quelqu'un pour le son .
Ces derniers sont à mon avis utile uniquement pour les gros projets .
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."