Aller à la page... |
[Moteur de jeu] Comment ca marche ?
Suivre Répondre |
|
Partager | Rechercher |
Alpha & Oméga
|
Citation :
-un singleton ou "god object" game -une classe pour tous les objets: gameItem -une classe fonctionnant dans un thread à part pour écouter les évènements et les traiter Eventuellement: -une classe caméra -une classe base de données -une classe pour la physique/les collisions -une classe pour le son -une classe réseau/serveur (et dans ce cas on code beaucoup de traitements côté serveur, le côté client ne servant qu'à faire de l'affichage graphique) -une classe GUI -faire des enfants à la classe gameItem: gameCharacter/gamePlayer et gameStaticItem -classe settings Ca, c'est la base. C'est pas un game engine et ça traite la plus part de ce qu'on peut rencontrer dans un jeu vidéo. MAIS les notions sus-citées nécessitent de connaitre le fonctionnement d'un langage objet, de comprendre pourquoi un singleton ou un god object c'est pas mal dans certains cas, etc. Et surtout ça nécessite de comprendre comment fonctionne une boucle de rendu, qu'est ce qui peut/doit être threadé et ce qui ne peut/ne doit pas l'être. Et tout un tas de notions qui font arriver à la conclusion suivante: un débutant ne doit pas faire de moteur de jeu, il doit faire des jeux et s'améliorer en fonction des difficultés rencontrées. La pire connerie que j'ai pu faire sur un projet c'était d'intégrer ma bibliothèque de physique trop tard (et de mal l'intégrer), pourtant ca ne m'a pas obligé à réécrire mes 7000 lignes de code et mon prototype marchait bien et me permettait de "tester" le fun. Par exemple, j'ai fait un pseudo-voxel engine (simplifié pour faire uniquement de la 2D) maison parce que le résultat en utilisant polyvox ne me plaisait pas (trop de triangles et donc performances merdiques): http://i.imgur.com/mn3VR2O.jpg (polyvox) / http://i.imgur.com/m4LgRcK.jpg (maison) - 700 lignes de code, soit 10% du code total de mon proto. Est-ce que je peux réutiliser ça dans un autre jeu ? Oui, si il s'agit d'un side ou top scroller (orthogonal ou non). Est-ce qu'il s'agit d'un bout de game engine ? Clairement non. Dernière modification par Neirdan ; 29/07/2014 à 01h58. |
29/07/2014, 01h08 |
|
|
Je peux me tromper, mais j'ai vraiment l'impression que tu mélanges le fait de structurer son code et le fait de réaliser un moteur de jeu. Un moteur de jeu c'est un outil réutilisable sur de futurs jeux auquel on a pas encore pensé. Structurer un projet, ça ne veut pas dire qu'on met en place un moteur de jeu réutilisable, ça veut juste dire qu'on réalise un jeu de manière efficace. Moi aussi je conseille d'être efficace et de penser son projet correctement, mais structurer son code ça ne veut pas dire qu'on élabore un moteur de jeu. |
29/07/2014, 01h15 |
|
MonsieurChance |
Voir le profil public |
Trouver plus de messages par MonsieurChance |
Alpha & Oméga
|
La question de base parait simple mais ne l'est pas, on parle de l'architecture du programme là.
Concernant la confusion classe/bibliothèque, http://fr.wikipedia.org/wiki/Wrapper_%28informatique%29 Et ca n'existe pas une classe "objet dans le jeu" par contre un objet du jeu contient des informations propres au jeu, des informations propres au moteur de rendu (modèle/texture), des informations propres au moteur physique, d'autres au moteur son, etc... Et de toute manière, un jeu c'est grossièrement: (démarrage) -Le main se contente de lancer la classe game -La classe game setup le tout (evènements, GUI, base de données, physique, settings, etc...) (jeu) -Une fois le setup terminé on entre dans une boucle de rendu -Il faut faire le choix de soit traiter les évènements dans le thread principal (rendu) soit dans le thread évènements (décalage avec le rendu) (fin) -Lorsqu'on quitte le jeu il faut vider proprement la mémoire Et le mec ne sait pas "où" placer un moteur de jeu. J'appelle pas ça une question basique. http://irrlicht.sourceforge.net/foru...hp?f=4&t=47760 < ces types là sont bien plus expérimentés que moi, CuteAlien a bossé en tant qu'indé et pour des grosses boites entre autres. Dernière modification par Neirdan ; 29/07/2014 à 01h54. |
29/07/2014, 01h37 |
|
Empereur / Impératrice
|
une des raisons de structurer son code est justement d'avoir du code réutilisable. Comme en atteste le titre du livre du GOF: Design Patterns: Elements of Reusable Object-Oriented Software Selon moi ( Neirdan n'a pas l'air d'être d'accord ) avoir une classe qui gère l'affichage de sprites est une des bases d'un moteur de jeu. Et si on structure bien son code, on en arrive à avoir ce type de classes. C'est pourquoi je dis que si il réfléchit bien à ses classes, il en arrivera à avoir un moteur de jeu presque par magie. Si je me trompe et qu'effectivement un sprite manager ne fait pas partie de la base d'un moteur de jeu, désolé de vous avoir embarqué dans un faux débat. Mais j'ai l'impression que notre différence vient surtout du fait que pour moi, des classes réutilisables ( et ayant une spécialisation spécifique aux jeux ) sont déjà un moteur de jeu et si je ne me trompe pas, pour vous un moteur de jeu sous entend soit d'avoir également des outils à disposition des game designer soit qu'il soit complet. Je crois que si on veut continuer ce débat, il faudrait déjà définir ce qu'est un moteur de jeu. Pour moi ton voxel engine peut très bien être une feature d'un moteur de jeu. Ce n'est pas parce que tout le monde n'utilise pas le code réseau de l'unreal engine que ce code réseau n'est pas un bout de l'engine. |
29/07/2014, 01h56 |
|
Alpha & Oméga
|
http://en.wikipedia.org/wiki/Game_engine
La définition est relativement claire, un game engine intègre tout ce qui attrait à un jeu (IA, réseau, son, rendu, inputs, langage de script, etc...) mais comprend également des outils (éditeur de scène, éditeur de GUI, moteur de particules, etc...) ainsi que du code tout fait. |
29/07/2014, 02h05 |
|
Empereur / Impératrice
|
dans les refs de l'article, tu as ce lien :
http://www.gamecareerguide.com/featu...is_a_game_.php Engines offer reusable components that can be manipulated to bring a game to life. Loading, displaying, and animating models, collision detection between objects, physics, input, graphical user interfaces, and even portions of a game's artificial intelligence can all be components that make up the engine Ils peuvent être la et non pas doivent An SDK is a collection of libraries, APIs, and tools that are made available for programming those same operating systems and services Quand t'as des tools avec, ca devient plus un SDK. D'ailleurs : https://www.unrealengine.com/products/udk The Unreal Development Kit is the free edition of Unreal Engine 3 that provides access to the award-winning 3D game engine and professional toolset used in blockbuster video game development, architectural visualization, mobile game development, 3D rendering, digital films and more. Ils font bien la différence entre le moteur et les outils. M'enfin bref, je crois qu'on est à peu prés d'accord sur le fond. Il est bien de structurer son code. Sauf que moi j'encourage un débutant à le tenter dés le début ( sans qu'il s'attende à le faire parfaitement ) quand vous préconisez d'apprendre par l'erreur. Après, est ce que ça donne un moteur de jeu ou pas, je crois qu'on s'en cogne un peu |
29/07/2014, 02h26 |
|
|
Citation :
Un moteur de jeu, sa fonction est de permettre à des concepteurs de jeux de se concentrer sur le contenu du jeu en se reposant sur le moteur pour le traitement informatique. Donc sur ce sujet, quand autant de gens (dont c'est le gagne pain de faire des jeux pour certains) argumentent sur le caractère démesuré d'une telle entreprise et donc sur le mauvais conseil que d'encourager un débutant dans cette voie, ces gens le font en ayant en tête cette définition de ce qu'est un moteur de jeu. Bien entendu que lorsqu'on réalise des jeux on peut reprendre des morceaux de code d'un projet à l'autre, mais ces morceaux de code seront toujours refactorisés et adaptés profondément aux besoins de chacun des projets. Reprendre du code ce n'est pas avoir à sa disposition un moteur de jeu générique. Donc encourager des gens à bien penser leur code pour éventuellement pouvoir envisager d'en reprendre la logique sur un autre projet, nous sommes d'accord. Mais conseiller à un débutant de penser un moteur de jeu, non, nous ne sommes pas d'accord. L'un des liens conseillés par Neirdan est vraiment à lire : http://scientificninja.com/blog/write-games-not-engines Pour situer, Josh Petrie qui actuellement travaille chez 343 Industries qui réalise des jeux de la licence Halo, était auparavant lead tools designer chez ArenaNet sur Guildwars 2. Son propos dans cet article est justement d'expliquer en quoi il faut réaliser des jeux et pas un moteur de jeux. Edit pour en dessous : comme c'est commode comme intervention... L'article illustre parfaitement le propos concernant l'erreur d'essayer de réaliser un moteur de jeu plutôt que de juste faire des jeux, démarche qui est plus formatrice et productive. Nous avons eu cette discussion du fait que tu as exposé que viser la réalisation d'un moteur de jeu était la base de la planification en matière de développement de jeu, et lorsque visiblement tu n'as plus d'argument à opposer pour défendre ton point de vue, tu fais une pirouette m'invitant moi à relire mieux l'article que je t'encourageais à lire... Bravo Dernière modification par MonsieurChance ; 29/07/2014 à 11h43. |
29/07/2014, 02h30 |
|
MonsieurChance |
Voir le profil public |
Trouver plus de messages par MonsieurChance |
Empereur / Impératrice
|
Citation :
|
29/07/2014, 07h49 |
|
Alpha & Oméga
|
Citation :
http://makegames.tumblr.com/post/113...nishing-a-game |
29/07/2014, 08h43 |
|
|
En lisant le topic et en relisant la question de départ je pense que ça dérive tout de même.
Je pense que Keeth connait un peu le C++, un peu les jeux vidéo. Et c'est tout. Il aimerait donc un "hello world" à ça sauce avec tout les déboires possibles, car c'est en faisant des erreurs et en les solutionnant qu'on progresse. Mais il n'est pas donné à tous de savoir les résoudre, et encore moins de la meilleur façon qui soit. Il semble vouloir avant-tout apprendre à gérer la mémoire. En général maitriser les outils d'un moteur existant requiert bien souvent de regarder comment fonctionne concrètement ce derniers afin d'en tirer le meilleur potentiel. Ce qu'il ne dit pas c'est son projet final, est-ce un jeu jouable au quel cas veux t'il apprendre à faire programmer gameplay. Il parlait à la base de rendu, veux t'il apprendre ce qu'est concrètement le rendu ? Il existe nombre d'implication et de spécialité. Tenter de faire un projet de A à Z lui montrera bien vite ce qui lui plait, et ce qui lui déplais. Il pourra alors focalisé sur ses lacunes dans le domaines qui semble lui plaire le plus. Keeth essaye de suivre les quelques liens ici et là de se topic. Commence par voir simple et savoir ce que tu veux réaliser concrètement à la fin, "un jeu moche" ne dit pas si tu veux savoir géré son rendu, son aspet, son gameplay, son réseau, son IA etc... De là et dans une démarche purement pédagogique, commence par prendre plusieurs moteur, si possible open source, et tente de réaliser cet aspect final tout en regardant comment le moteur fonctionne si c'est là ton intérêt. En parallèle, fait toi un petit programme tentant de créer cet aspect final avec le minima. Dans tous les cas les Math n'ont pas intérêt à te faire peur. Sache juste que maintenant on ne peux guère faire tout tous seul, à moins que ça soit de tout petite chose très spécifique Essaye de reproduire des jeux de bases très simple (tetris, pong) ajoute une composante multijoueur si tu veux faire du réseau) fait un scène 3D si tu veux apprendre ça après un simple rendu 2D, intègre des modèles, de la lumière, etc... Vas y progressivement tu verras très vite tes limites. Je peux te conseiller une approche par les tuto de NeHe qui part des bases de plein de choses. http://nehe.gamedev.net/ Mais ne part pas dans l'idée de faire un jeu direct, ou alors très simple Du style bouger un carré d'un rectangle à un autre. Ensuite test différents moteurs et tu les modifieras légèrement pour coller à tes besoins u peu plus ambitieux et tu progresseras itérativement. |
29/07/2014, 10h04 |
|
|
Je connais effectivement le C++ (pour des applications industrielles) et je suis un passionné de jeux vidéos. Mais il ne suffit pas de coder du PIC pour se prétendre capable de faire un jeu. Finalement cette discussion m'a apporté tous les éléments de réponse dont j'avais besoin. Les mots que j'ai choisi n'ont pas forcément été les bons, la tournure de l'OP peut être pas la meilleure, mais je suis finalement content de voir que ma démarche a été, dans l'ensemble, comprise. Je vais donc essayer d'aborder les choses de la manière la plus simple possible en faisant abstraction des gros mots comme ... moteur. Visiblement, je me projetais déjà trop en avant. Je vais néanmoins me concentrer sur l'optimisation et la propreté de mon code avant de vouloir exiger du résultat "visible". Merci pour vos conseils, vos points de vue et vos link. |
29/07/2014, 13h29 |
|
MonsieurChance |
Voir le profil public |
Trouver plus de messages par MonsieurChance |
Alpha & Oméga
|
http://jmonkeyengine.org/
A savoir qu'il y a bien plus de choix en c++ qu'en java. Sinon, y'a facebook qui par l'intermédiaire d'oculus rift a racheté raknet et l'a foutu en opensource: http://www.jenkinssoftware.com/ Par contre c'est du très haut niveau, y'a même un team balancer. |
30/07/2014, 00h20 |
|
|
L'article ne fait que dire qu'à force de faire des jeux on devient capable d'identifier quels morceaux de code d'un vieux projet peuvent être repris pour un nouveau projet. L'article explique clairement que ces éléments de code seront ré étudiés, ré adaptés, qu'on en ôtera toutes références à ce vieux projet, et qu'il s'agira donc de code refactorisé et profondément adapté au nouveau projet. Cette approche que l'article expose n'a rien à voir avec la conception d'un moteur de jeu qui lui suppose par principe de ne pas réclamer de refactorisation des éléments le constituant d'un projet à l'autre. Aussi, on va en rester là. Car visiblement ce que tu veux absolument, c'est tourner un article dont le titre est expressément " faites des jeux, pas un moteur de jeu" en un texte qui irait exactement dans le sens que toi tu veux qu'il ait, c'est à dire un article qui dirait précisément le contraire de son contenu. |
30/07/2014, 00h36 |
|
MonsieurChance |
Voir le profil public |
Trouver plus de messages par MonsieurChance |
|
J'ai cru voir quelqu'un parler d'UML. Je connaissais cette méthode pour de la BDD mais ca m'interesserais de savoir comment on procède dans le cas d'un jeu.. Finalement, mon topic n'aurait pas du introduire des notions comme moteur de jeu ou moteur graphique au vu de mon statut de débutant, mais je voulais juste connaître le principe avant de prendre une mauvaise direction. |
30/07/2014, 08h25 |
|
Alpha & Oméga
|
Ca parle MVC, pas UML.
|
30/07/2014, 08h48 |
|
Dauphin / Dauphine
|
Citation :
|
30/07/2014, 10h08 |
|
Suivre Répondre |
Fil d'ariane
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|