3 mois il faudrait avoir de forte connaissance dans les systèmes équivalents.
6 mois en travaillant beaucoup sur ton temps libre pour avoir un début d'embryon de quelque chose de sympa. Pour faire un vrai jeu, beaucoup plus à mon avis.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
3 mois il faudrait avoir de forte connaissance dans les systèmes équivalents.
6 mois en travaillant beaucoup sur ton temps libre pour avoir un début d'embryon de quelque chose de sympa. Pour faire un vrai jeu, beaucoup plus à mon avis.
si c'est pour un projet petit budget il y a des moteurs tout faits avec déjà des morceaux de gameplay dedans mais je n'en connais pas de gratuit
google is your friend
Un moteur 3D gratuit (pour générer des produits gratuits) ?
Je transfère une information lue sur un autre forum :
http://www.havok.com/content/view/582/53/
Peut-être que cela vous aidera. Manifestement beaucoup de jeu (console et PC) l'ont utilisé. L'info date du 20 février 2008. Au regard du dernier post, c'est peut-être une nouvelle qui n'existait pas avant.
J'en dis pas plus, je suis qu'un nouveau de passage sur ce forum ^^. Et puis le moteur 3D ça m'a passé ... La 3D fait tout et surtout oblige à faire beaucoup de boulot supplémentaire pour faire des maps, des personnages, du calcul.
Bonne journée à tous !
kéké.
en l'occurrence, ce n'est pas un moteur 3D mais un moteur physique
* Il est infiniment plus simple de faire rapidement un code qui marche que de faire un code rapide qui marche
* pour faciliter les recherches, n'oubliez pas de voter pour les réponses pertinentes
Mes articles
De plus, comme dit bob25 il n'y pas beaucoup de moteur de jeu gratuit, sauf peut être XNA avec ces "starter kits".
Si on prend l'Unreal Engine ou Source, qui sont 2 moteurs de FPS, il n'existe rien d'équivalent, en gratuit. Bien que j'ai pu louper un moteur de jeu complet et gratuit (et récent ^^, on a pas forcément envie de coder un jeu à la Doom 1).
D'ailleurs, à défaut d'utiliser un moteur tout fait (qui sont donc assez rares ou pas adaptés à notre type de jeu), on doit coder le sien. Et je ne sais pas vous, mais j'ai extrêmement de mal à trouver de documentation ou de tutos sur la création de moteur de jeu "pur", sur l'engine design. (Y'en a, mais pas souvent complets).
Par contre on trouve à foison des tutos concernant OpenGL, DirectX, SDL, l'utilisation de moteurs physiques... mais ne serait-ce pas la partie la moins importante du jeu vidéo ?
C'est vrai, développer le moteur graphique avant de faire le moteur du jeu, c'est risquer d'avoir un moteur graphique pas adapté à ses besoins... et faire les 2 à la fois devient impossible pour un projet un minimum ambitieux (surtout quand on est seul)
Alors qu'une fois le moteur de jeu fini, on sait exactement l'interface que devra prendre le graphic core et il ne restera plus qu'à l'implémenter.
Bon, tout ça pour dire, c'est bien beau d'avoir sur le net des centaines de tutoriaux qui explique comment faire des effets de fou avec OpenGL, mais ce serait bien que l'explication du "comment faire un jeu" (d'abord de façon générique puis plus spécialisée) soit plus mis en avant.
Attention un moteur de jeu (si on peu dire ça comme cela) est une agrégation d'un ensemble de moteur et d'outils permettant la conception d'un jeu, donc le moteur graphique est une partie du moteur de jeu. Il n'y a aucune relation d'avant/après entre eux.
Par contre il est vrai que la plus part des développeur amateur ce focalise sur l'affichage et en parle comme de leur jeu. Il suffit de voir le nombre important de jeu sans outils. Juste des maps codé en dur dans de XML et basta.
Lorsque j'étais dans ma précédente boîte j'étais à la section moteur et outils, j'ai bossé un moment sur le moteur d'affichage, quelques optimisations et des updates sur les compressions de textures mais la ou je me suis vraiment amusé c'est lorsque j'ai bossé sur le moteur de script. J'y ai passé 3 mois, mais je me suis fais vraiment plaisir ... et pourtant c'est une partie rarement cité dans les jeux vidéo ...
Alors je ne parle même pas des moteur d'IO et de network, quant je pense au nombre de projet MMORPGRTSFPS ... qui montre tatatata des dessins au crayon et 2 cubes opengl tiré d'un tutos. Mais a aucun moment je ne vois apparaître une ligne ou une question sur les protocoles réseaux, les infrastusture distribué, ...
La distinction entre moteur graphique, moteur de jeu et moteur de rendu n'est pas acquise pour la plupart des gens qui se lancent dans la conception d'un tel projet...
La plupart focalisent sur le moteur de rendu... mais oublient que si y'a rien à "rendre" alors inutile d'avoir suivit tout les tuto du monde sur OpenGl...
Le développement d'un jeu, même en se basant sur des moteur physique et de rendu existant, reste une tâche fastidieuse... Je crois que ce concept échappe à pas mal de jeune motivés, rapidement démotivés...
La notion de "pas à pas" échappe aujourd'hui aux concepteurs ambitieux qui se lance dans la conception de leurs propre moteurs sans même savoir précisément ce qu'il faut comme connaissances pour s'atteler à une telle tâche.
Cependant, et nous l'avons vu ici, certains y arrivent. Un grand bravo à ces courageux et talentueux développeurs.
Comme l'a bien dit ash.ice.loky, il y a autour de ça encore bien des tâches à réaliser... scripting, éditeurs, réseau, IA, ... Ne foncez donc donc pas tete baissée sur l'impulsion du moment...
Par contre ceux qui savent ce qu'il veulent et ce qu'ils font, alors n'hésitez plus... rien de tel qu'un projet d'une envergure comme celle ci pour acquérir des compétences !
"le langage C permet de tout faire, y compris se tirer dans le pied. Le langage C++ permet de tout faire, y compris se tirer dans le pied - et réutiliser la balle"
Ce serait très intéressant d'ailleurs d'écrire un tutoriel sur l'intégration d'un moteur de script dans un moteur de jeu. J'ai un peu honte de le dire, mais je n'ai jamais encore compris vraiment l'intérêt d'intégrer du scripting, les rares explications que j'ai eues étaient trop succinctes/trop théoriques, quand à comment les intégrer dans un moteur, il existe encore moins de ressources (notamment, faut-il penser le scripting avant l'élaboration du moteur, ou est-ce une partie facilement intégrable "après coup" ?).Envoyé par ash.ice.loky
Je te donne deux raisons simples :
- cela permet à des équipes différentes de travailler sur le projet. La partie scripting est en général plus simple, cela permet à une équipe pas forcement spécialiste en C de travailler là dessus.
- et surtout, cela permet d'éviter la recompilation du projet (quand une petite modification demande 5min, 10min voir 30min de compilation, c'est profitable d'avoir du code que l'on peut modifier et relancer directement le jeu (voir ne pas le relancer si il y a un mode pour relire les scripts à chaque coup
Je ne répondrai à aucune question technique en privé
HA le scripting !!!
En gros faut voir ça comme la différence entre une map codée dans le code et une map importer d'un XML ou mieux avoir un éditeur de maps.
D'un coté du doit réouvrir ton éditeur, faire ta modif (plus ou moins facilement) et tout recompiler.
Un autre avantage est de pouvoir donner certaine tache a des "non-programmeur".
Pour ce qui est de la conception je me suis rendu compte que ca ne changeais pas grand chose. Un moteur n'est généralement qu'une façade. Ensuite tu link le langage de scripts à la façade. Bon c'est une vision simpliste, mais c'est quand même pas loin de la réalité.
EDIT: doublé
Ok pour le coup de la compilation.
En fait, moi, le scripting, je vois ça toujours comme une "simplification". Par exemple, disons que je souhaites faire apparaître un monstre lorsque le joueur passe un checkpoint, ça me donnerait quelque chose comme ça (bon, j'imagine que cette syntaxe n'existe pas :d) :
Et ainsi créer des dizaines de petits scripts comme ça, par exemple un tel script pour chaque checkpoint, ou alors faire en sorte de faire apparaître un bonus lorsqu'un ennemi meurt.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Mais ce que j'ai du mal à visualiser, c'est déjà comment interfacer le code pour que ça marche (si effectivement ça fonctionne comme je le pense), et secondo, qu'est-ce qui nous empêcherait d'effectuer ça en code réel. Par exemple, avoir une fonction dans le code C++ dans une classe Checkpoint qui permette "d'attacher" un événement (ou pas), et qui serait appelé dès que par exemple le joueur passerait ce checkpoint.
Rien n'empêche d'avoir ce type d'éléments directement dans le code. Mais il faut voir que outre la compilation, déporté une partie de la mécanique de jeu dans des scripts permet d'ouvrir le jeu à des modifications externes effectué par des joueurs sans avoir à leur fournir les sources du jeu et les obliger à des manipulation complexes.
Pour l'interfaçage, pas mal de langage de script (comme le lua) permettent de manipuler directement des objets contenu dans le code du jeu
Détrompe toi, tu peux aussi faire un langage de script qui soit de cette syntaxe:
SI checkpoint==Vrai => CreerMonstre
En fait il existe des interfaces C++ (c'est celui que tu utilise?) avec ruby, python, lua, ..., mais rien n'empeche que tu créés ton langage.
Ensuite libre a toi d'inventer la syntaxe de ton choix et d'y incorporer les fonctions et bibliothèques de ton cru.
regarde du coté de ANTLR, SPIRIT, BISON, FLEX, YACC, LEX, ...
Ca semble en effet intéressant, dommage qu'il n'y ait que si peu de ressources sur le sujet...
il existe sur gamedev un article sur l sujet, mais il n'a jamais été fini.
Il existe aussi un court ici sur la conception d'un interpréteur:
http://cui.unige.ch/DI/cours/CompInterpretes/
Mais c'est vrai que c'est un domaine peu utilisé dans le monde du jeu amateur.
Comme j'ai eu à étudier pas mal ce domaine, je me rapelle d'une époque lointaine où je me suis faite baffer (sur un autre forum) pour avoir parlé dans un post de présentation de mon projet de RPG de scripting.
La mécompréhension venait du fait que je parlais d'un langage de scripting adapté à mon jeu pour certains éléments particuliers et non d'un langage de script tel LUA ou Python.
Pour reprendre ce que j'ai posté sur ce sujet sur GameCorp (d'ailleurs je dois toujours faire une vraie présentation de la question sous forme de tuto... >_>"):
Il y a deux aspects dans le scripting:
-> Le scripting comme extension du code source:
C'est celui dont vous parlez le plus et qui nécessite un langage de scripting relativement étendu.
Son objectif est de rajouter des fonctionnalités externes au code sans recompilation.
Personnellement je pense que les principaux intérets sont les IA de créatures et des éléments qui peuvent être amenés à être modifiés lors des alpha/beta tests du jeu (shaders, formules de sorts pour un RPG...)
L'un des langages les plus utilisés pour ça actuellement est LUA
-> Le scripting pour décrire la "base de données du jeu":
Pour moi peut être considéré comme base de données tout les éléments du jeu constituant l'affichage, les interfaces et le gameplay (pour un RPG: fiche de créatures, description des sorts et des objets, maps....)
Hors pour les jeux vidéos on est bien d'accord qu'on ne va pas monter une bdd mysql chez le client (faut pas être fou non plus). On en revient donc aux Databases pré-sgdb relationnel sous la forme de fichiers plats.
Et c'est là dessus que ca avait coincé. En effet un langage de script tel LUA ou Python est totalement inadapté pour ca (prenez un pieu pour faire de la microsoudure; ca revient au même). J'avais donc pensé à l'époque à un langage de script maison inspiré par ce que j'avais pu voir dans les scripts d'un émulateur de serveur d'un mmo (dont je ne citerais pas le nom ici).
Après moult modification et parce que le premier programmeur sur mon projet était feignasse (et moi aussi), nous avons fini par passer de ce système "propriétaire" à un système à base de script XML.(donc l'interpréteur se fait "tout seul" en C# et en C++ avec Boost)
Ceci, lié à un peu de serialisation pour les sauvegardes constituent les scripts de chargement du jeu.
Le LUA est aussi utilisé pour la description de données dans certains jeux sans que cela pose de problèmes particuliers ...
C'est vrai; mais comme je dis; c'est comme utiliser un pieu pour faire de la microsoudure.
C'est possible mais vu le niveau de complexité de LUA par rapport aux besoins réels c'est utiliser un gros outils pour pas grand chose (je dirais même ca frise le ridicule puisque après tout LUA est un langage de programmation comme un autre si ce n'est qu'il est interprété; donc c'est limite comme si tu hardcodais mais sans à avoir à te soucier de la compilation).
En plus l'avantage du XML par rapport à LUA c'est que des outils sont déjà disponibles sans avoir à programmer pour créer tes structures de scripts et les contrôler. Donc tu injectes dans ton jeu des scripts dont tu es sur à 100% de la validité.
Après ce sont les choix personnels des développeurs.
Salut, je ne comprends pas la différence entre le moteur graphique et le moteur de rendu, y en a-t-il une ?La distinction entre moteur graphique, moteur de jeu et moteur de rendu n'est pas acquise pour la plupart des gens qui se lancent dans la conception d'un tel projet...
Vive les roues en pierre
Je dit peut-être des bêtises,mais pour moi il n'y en a pas.
tutoriel Ogre:
http://gusgus.developpez.com/Ogre/
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager