|
Citation :
Le mec sait pas de quoi il parle. Qu'il mette les mains dans le cambouis et commence par faire quelques jeux. Il aura une idée bien plus précise de ce qu'est un moteur et de ce dont il a besoin pour en réaliser un. C'est bien plus formateur que de partir directement sur un moteur à l'aveugle. Citation :
Et suivant la généricité du truc, soit tu te retrouves avec un moteur utilisable sur un certain type de projet soit tu te retrouves avec un truc moins bien que les produits pro. Bref, se lancer sur le dév d'un vrai "moteur" c'est déjà d'une utilité plus que discutable, mais en tant que débutant c'est clairement pas du tout un bon plan, que ça soit pour le résultat ou pour la montée en compétences. Pour rappel, l'OP en est à galérer sur la gestion de la mémoire hein. |
29/07/2014, 00h50
|
[Moteur de jeu] Comment ca marche ?
| Suivre |
|
|
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
|
|
Alpha & Oméga
|
En fait c'est déprimant de poser une question dans cette section... D'une simple question d'un néophyte ça part sur un grand débat.
Neirdan, en gros tu remplace chaque mot "classe" par "bibliothèque" et t'as la plupart (voir toutes) des couches d'un jeu ? |
|
29/07/2014, 01h12
|
|
Roi
|
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
|
|
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
|
|
Roi
|
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
|
|
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
|
|
Alpha & Oméga
|
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
|
|
Alpha & Oméga
|
Citation :
@Dessous : Certes. Dernière modification par Xotraz ; 29/07/2014 à 15h19. |
|
29/07/2014, 14h57
|
|
Roi
|
Oui donc une intervention où il conseille à un débutant de structurer son projet autour notamment d'un game engine perso destiné à être réutilisé sur de futurs projets...
Bon sur ce je laisse tomber, à ce stade là la mauvaise foi semble avoir des vertus hallucinogènes. |
|
29/07/2014, 15h12
|
|
[P.H.]
Alpha & Oméga
|
L'OP à l'air de vouloir faire les choses proprement, sans brûler les étapes.
Je respecte le choix, même si j'ai plutôt tendance à conseiller aux gens qui veulent se lancer dans le dev de jeu à commencer avec des outils tout fait où l'utilisation de la programmation est le plus localisé possible, comme flash, unity, game-maker, pour ensuite approfondir sur le tas en fonction de leurs besoins : C'est plus motivant, et beaucoup plus formateur, d'enchaîner les petits jeux vite-fait mal-fait que de passer des mois à apprendre des bases en programmation pas forcement très fun à apprendre avant de pouvoir entrer dans le vif du sujet (si la motivation est toujours là, ce qui est pas gagné !) Mais oscifer, commencer à parler de design-pattern à quelqu'un qui en est à l'apprentissage de la gestion de la mémoire, là c'est carrement contre-productif, anti-pédagogique. Comment quelqu'un qui en est au tout début de l'apprentissage de la POO pourrait réussir à comprendre et assimiler des concepts qui sont là pour maintenir en place des projets complexes, fortement structurés, et qui ne révèlent bien souvent leur intérêt réel qu'à travers le boulot en équipe et uniquement pour anticiper les multiples refactos qui viendront par la suite ? Le MVC en particulier, dans le cadre du jeu vidéo, dans bien des cas c'est le meilleur moyen pour perdre du temps et générer du code tentaculaire là où il n'y en a bien souvent pas besoin. Et pour savoir quand il y en a besoin, et quand il n'y en a pas besoin, c'est l'expérience. Beaucoup d'expérience. L'opener à tout à gagner à commencer sans, pour mieux comprendre quand il faut les utiliser, et quand il ne le faut pas, lorsqu'il commencera à avoir le niveau pour les étudier. |
|
29/07/2014, 16h40
|
|
Empereur / Impératrice
|
Citation :
Alors que ce que je propose est de développer un jeu, mais de réfléchir lors de ce développementà comment avoir des classes indépendantes qui vont former petit à petit un moteur de jeu. Dans tous ce que j'ai dit : seule cette phrase pourrait porter à confusion: "Si le but est d'apprendre à bien programmer, commencer par un moteur basique n'est pas compliqué et ça peut même être gratifiant." Je peux comprendre que l'on soit pas d'accord avec cette affirmation, il n'y a pas de problème, mais ce n'est pas ce que je préconise non plus ! Je dis juste que c'est une possibilité. Je reprend de l'article que tu trouves si intéressant: "Once you have made one game, make another. Then another. Each time you start a new project, you should identify functionality that could be used and pull it out into a common library of base code. You’ll probably have to refactor some of your code to remove explicit dependencies on other code or data that is game specific, but this is a good thing. It will help you generalize what is generalizable in a way that you can still test the generalized functionality against your finished game and confirm that it still works (obviously you might have to modify some game-specific code to adapt to the increased generality, as well). If you repeat this process long enough, after a few games you’ll have the beginnings of a solid collection of reusable functionality that has been proven to have practical applications. You’ll also have a set of far more interesting demonstration applications that could also double as test harnesses for your engine. This method of growing an engine" N'est ce pas ce que je propose ?? Dans son article, il dit : ne programmez pas qu'un moteur de jeu. Il ne dit pas de coder à l'arrache sans penser à la possibilité de réutiliser son code. On pourra me sortir la phrase : "You’ll probably have to refactor some of your code to remove explicit dependencies on other code or data that is game specific" qui peut sous entendre qu'on a déjà fait un jeu avant. Mais il dit bien : "Each time you start a new project" et non pas aprés quelques projets. Il dit également: "You’ll probably have to refactor some of your code to remove explicit dependencies". C'est qu'il sous entend qu'on a pas non plus fait n'importe quoi. Sinon il ne suffit pas de "probablement refactoriser un peu de code" @Keeth Houla malheureux ! Code proprement oui, mais surtout n'essaie pas d'optimiser dés le début. Là pour le coup c'est perdre son temps pour rien. 1 - parce que tu vas optimiser du code qui n'a pas besoin de l'être, donc perdre du temps 2 - parce qu'optimiser veut souvent dire détériorer la lisibilité et la réutilisabilité du code. 3 - parce que tu ne sauras pas le faire. Mon lead dev qui donne des confs dans des conventions comme la GDC dit lui même que c'est extrêmement compliqué et que souvent quand on ne s'y connait pas, on empire plus les choses qu'on ne les améliore. Si tu codes proprement, ton code sera suffisamment optimisé. @'Az Effectivement le MVC n'est pas le design pattern le plus intéressant pour un débutant, voir même dans la programmation de jeu tout court. Mais dans le lot, t'en as quand même qui sont extremement importants (creator, high cohésion, low coupling, polymporphism ) qui sont compréhensibles par un débutant. Bien sur qu'il ne les utilisera pas correctement du premier coup. Mais avoir été familiarisé avec ces notions ne peut franchement pas faire de mal et d'essayer de les utiliser non plus. Tu me demandes: "Comment quelqu'un qui en est au tout début de l'apprentissage de la POO pourrait réussir à comprendre et assimiler des concepts qui sont là pour maintenir en place des projets complexes, fortement structurés" Je répondrais deux chose. Si on apprend pas à appliquer les designs patterns sur des projets simples, je ne vois pas comment on arrivera par magie à les appliquer quand on aura un projet complexe. Un jeu peut très rapidement devenir un projet complexe. Tu ajoutes : " qui ne révèlent bien souvent leur intérêt réel qu'à travers le boulot en équipe et uniquement pour anticiper les multiples refactos qui viendront par la suite ?" Pour moi c'est plus une analyse style UML qui permet ça, mais effectivement, elle se base lourdement sur les designs patterns. J'ajouterais que je suis bien content de pouvoir réutiliser du code entre mes projets persos, que je suis bien content lorsque je retire une classe de ne pas avoir à passer une heure à changer tout mon code, que je suis bien content d'avoir un code relativement lisible quand je reprend un projet après quelques mois de pause. Tout ça, et entre autres, c'est grâce aux designs patterns. Sinon l'OP dit qu'il va faire attention à la gestion de la mémoire. De ce que je comprend avec cette phrase, c'est qu'il a réfléchis déjà à quel langage utiliser. Que dans sa réflexion il a lu ou entendu que le C++ c'est le plus performant mais qu'il faut faire attention à la mémoire ( c'est ce qu'on lit dans quasi toutes les réponses à la question : je veux faire un jeu vidéo quel langage je dois utiliser ? ). Du coup, il a dit probablement dit ça pour donner de la consistance à son poste. A mon avis, ça ne va pas plus loin que ça. J'ai dans l'impression que malgré ça, l'op n'est pas complétement débutant. Je le vois bien avoir touché à un peu de java, du C dans ses études, ou un truc dans le genre. Je pense qu’après avoir fait rien que quelques programmes, on est en position de ressentir l'importance des designs patterns. Bien sur, à moins d'être un génie on arrivera pas à les exploiter pleinement dés le premier essai ( peut on réellement y arriver un jour même ), cependant la programmation, c'est comme le sport. Il vaut mieux prendre les bons réflexes dés le début. |
|
29/07/2014, 19h42
|
|
Dauphin / Dauphine
|
J'en profite pour rebondir sur ce post, vu que l'op a d'après lui eu ce qu'il voulait, et que ma demande est dans le sujet.
Je suis totalement débutant en programmation de jeu (j'ai un peu d'expérience en prog industrielle : 1 an de c++ et 1 an de cobol), et je m'y essaie un peu pendant mes temps libres quand j'ai le courage. Donc pardonnez d'avance si je dis des conneries dans ce que je vais écrire  . J'ai dev un prototype basique d'un jeu en java, une sorte de moba sur une map de la taille de l'ecran, pas de scrolling donc pour l'instant, et en 2D, en m'attardant surtout sur le gameplay, les sorts, etc, pour tester le fun du concept. J'ai fait une gestion des collisions basique mais qui me suffit pour l'instant, et pour l'affichage j'ai utilisé swing. J'en arrive donc aux étapes suivantes que j'aimerai ajouter à mon proto, qui sont : - L'aspect réseau, pour tester le concept à plusieurs (si c'est pas trop brouillon, si je dois passer à un scrolling car map trop petite, etc.). Là je sais pas trop comment ca fonctionne, si ca va me demander un gros refactoring ou pas, etc. Je veux vraiment le truc le plus basique possible, pas besoin d'un truc sécurisé, qui tient les attaques DDoS ou autre comme j'ai pu lire sur divers blogs. J'ai un peu cherché, et j'ai l'impression que la plupart des librairies recommandées sont trop poussées pour ce que je veux faire (Netty, Kryonet, SpiderMonkey pour celles qui ressortaient le plus). - Un moteur graphique. C'est surtout ce point là qui m’intéresse. Il me faudrait notamment rajoute une notion de profondeur (pour des raisons de gameplay), donc j'aimerai bien passer à une vue isométrique. J'ai vraiment pas envie (au contraire de l'op) de dev ça moi-même, et je voudrais un truc assez simple d'utilisation. De ce qui ressortait sur la majorité des forums, c'était Unity, mais j'ai peur que ce soit trop compliqué à prendre en main pour mon besoin. J'avais pensé également à utiliser Flash, d'après ce que j'ai pu lire, c'était notamment la techno utilisée pour The Binding of Isaac, mais les développeurs en avaient pas l'air très satisfaits (pour l'aspect mémoire notamment, mais les perfs ne sont pas trop mon souci pour l'instant, donc ca ne me concerne pas à priori). Donc voila, pour résumé, qu'est-ce que vous pouvez me conseiller comme librairies/moteur pour l'aspect réseau et graphique, en sachant que c'est pour un proto afin de tester l'aspect gameplay, donc pas besoin d'un truc qui tient la route sur le long terme ou autre. |
|
29/07/2014, 23h39
|
|
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
|
|
Roi
|
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
|
|
Dauphin
|
Pour coder un jeu en 2D moche en C++, sans utiliser de GameEngine, il faut au minimum avoir une librairie graphique.
Une librairie graphique ça permet facilement d'ouvrir une fenêtre et d'y colorer des pixels (voir même d'y afficher des images !). Pour faire un truc rapide en C++ j'utilise personnellement la SFML (parce qu'elle fait plus que simplement du graphique, tout en restant bas niveau). Après un tuto ou deux sur la librairie graphique, tu saura afficher un sprite et le bouger avec le clavier (ton premier objectif de ce que j'ai lu). A partir de là, tu saura gérer le clavier, t'occuper de l'affichage, et tu pourra coder ton jeu comme il te plaira (soit en te fixant des principes de POO très lourds pour des premiers essais, soit en te lâchant et en faisant du code itératif). Je ne peux que te conseiller de réfléchir à l'avance à la conception si tu es déjà familier avec la POO (c'est toujours des lignes de gagnées de faire des Abstract classes) en pensant bien à n'appliquer un principe Orienté objet que s'il a un intérêt pour ton projet (Découper des features comme la sauvegarde et le chargement en 15 classes, c'est possible, mais as-tu besoin d'autant de modularité pour un snake ?) |
|
30/07/2014, 02h14
|
|
|
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
|
|
Dauphin
|
Citation :
Si tu veux déjà avoir une bonne structure et que tu as des connaissances en POO, commence peut-être par ça. C'est toujours cool pendant le dev de pouvoir se reposer sur un document que tu as fait pour avoir une vue d'ensemble de ton code. |
|
30/07/2014, 14h33
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|