[mc salo]

Bonjour à tous,

J'envisage de commencer à coder un petit jeu moche et sans prétention pour essayer de me former en autodidacte.
Je n'apprécie pas particulièrement travailler avec des softs qui mâchent le boulot car je préfère travailler plus pour des résultats moins visibles, mais pour une meilleure compréhension.
Je compte faire çà en C++ pour me forcer à m'appliquer sur la gestion de mémoire.

Un moteur de jeu peut il se faire a partir d'un codeblocks tout simple ? Fait il partie intégrante de mon code ? Quelles sont les fonctions d'un moteur de jeu?

Je ne suis pas un expert alors si vous pouviez utiliser des exemples concrets, ça m'aiderait beaucoup.

Merci pour vos réponses !

[Meyleen Neoryl]

Tentes Unity moi je te dirais.

[Veilugarux]

Bah déjà, 2D ou 3D ?
http://fr.wikipedia.org/wiki/Moteur_de_jeu
Je m'y connais pas vraiment, mon moteur graphique permet juste d'afficher des images sur différentes couches et de charger les images de mon jeu en mémoire.
Un vrai moteur de jeu n'est pas nécessaire pour programmer un jeu vidéo. Un moteur va gérer tout les jeux de façon générique et utiliser des scripts afin de gérer les comportements.
Dans l'idéal, tu ne touches plus à ton moteur une fois celui ci fais même en changeant de jeu.
Si tu débutes tu ne va pas créer ton moteur de jeu, tu va programmer ton jeu.

[Nnayl]

Citation :

Publié par Meyleen Neoryl

Tentes Unity moi je te dirais.

Il précise bien qu'il se souhaite pas de soft qui mâche le boulot =)

Les réponses a t'as question vont m'intéresser, je vais suivre cette discussion.

['Az]

Oui mais il y a une différence entre faire un jeu, et faire un moteur de jeu.

Faire soit même un moteur, sans aucune expérience dans la programmation de jeu, c'est y passer un temps supplémentaire énorme, sachant que, comme pour n'importe quel projet de programmation, tu auras forcement sous estimé la tâche quand tu t'y es attelé.

Là où utiliser un moteur déjà existant permettra de prendre de bon réflexes, et déjà à comprendre comment un moteur est sensé fonctionner avant d'avoir à en faire un soit même.

Je conseillerai d'utiliser un moteur existant (qui dépendra de si le jeu est 2d ou 3d) pour le premier jeu. Puis, si la création d'un moteur t'intéresse, en faire un toi même pour un 2ième jeu en réutilisant l'expérience acquise.

[Neirdan]

Ca doit être le retour des vacances parce que j'ai rien compris à ce que veut l'OP.

Moteur graphique = affichage texte, 2D, 3D ? Gestion de la physique et des collisions ?
Je n'ai pas non plus compris la confusion faite entre
moteur graphique = rendu graphique
moteur de jeu = réseau, son 2D / 3D, graphismes, physique, entrées/sorties (au minimum)

Certains moteurs graphiques intègrent une GUI, de la physique de base et une gestion des entrées/sorties.

Unity est un mauvais moyen de démarrer. Ce n'est pas un bon outil pour les débutants.

Bref, que veut faire l'OP? Un jeu? Quoi comme jeu?

[Longwelwind]

Un moteur graphique, c'est tout ce qui va gérer l'affichage 2D/3D de ton jeu. Normalement, c'est une librairie à part
La meilleure solution, imo, pour que tu comprennes exactement les fonctions d'un moteur graphique, c'est d'en utiliser un pour voir comment ça fait d'en utiliser un de l’extérieur.
Dire qu'un moteur graphique "mâche" le boulot, c'est partir d'un mauvais pieds en matière de programmation. (Même chose pour les frameworks web)

Dans le jeu, ça se traduit généralement par une boucle infinie qui utilise les fonctions du moteur graphique pour afficher les éléments de ton jeu.

[mc salo]

Citation :

Publié par Neirdan

Ca doit être le retour des vacances parce que j'ai rien compris à ce que veut l'OP.

Moteur graphique = affichage texte, 2D, 3D ? Gestion de la physique et des collisions ?
Je n'ai pas non plus compris la confusion faite entre
moteur graphique = rendu graphique
moteur de jeu = réseau, son 2D / 3D, graphismes, physique, entrées/sorties (au minimum)

Certains moteurs graphiques intègrent une GUI, de la physique de base et une gestion des entrées/sorties.

Unity est un mauvais moyen de démarrer. Ce n'est pas un bon outil pour les débutants.

Bref, que veut faire l'OP? Un jeu? Quoi comme jeu?

[...]
Je pense que l'OP essaye juste de savoir si un moteur fait partie intégrante du code et quelles sont ces fonctions exactes. Je débute donc 2D only.
Bref, si tu te sens trop intelligent pour me répondre, abstient toi tout simplement...

Et merci aux autres pour leurs réponses normales et sympathiques...
Donc si je comprend bien un moteur graphique ce n'est pas un moteur de jeu.

J'ai connu un ingé info qui m'avait montré un petit jeu moche en 2D, il avait tout fait à la main. D’où ma démarche... Je vais retenter de me plonger dans la doc, ca va pas être facile.

[Neirdan]

Citation :

Publié par Keeth

Bref, si tu te sens trop intelligent pour me répondre, abstient toi tout simplement...

[Modération : ...]

[oscifer]

Tu as quasiment tout ce qu'il te faut dans le poste de Xotraz

J'ajouterai juste à "Si tu débutes tu ne va pas créer ton moteur de jeu, tu va programmer ton jeu" : et si tu es un bon programmeur, tu auras déjà quasiment ton moteur de jeu.

Si tu appliques les patterns GRASP ( http://en.wikipedia.org/wiki/GRASP_%...nted_design%29 ), tu te retrouveras tout naturellement avec un moteur une fois ton jeu terminé.
Tu as d'autres patterns utiles, mais rien qu'en utilisant bien ceux ci tu seras bien meilleur que beaucoup de programmeurs professionnels et tu seras capable de créer un moteur qui tient la route.

Petite astuce pour ton projet. Crée deux dossiers gameplay et GameEngine. Quand tu crées une classe, demande toi :
- Si elle semble être en bonne adéquation avec les patterns grasp ( en particulier faible couplage et forte cohésion ).
- Si elle répond à une logique de gameplay ou si c'est une base pour tout jeu ( réponse 1 direction gameplay, réponse 2 direction gameengine, tout simplement )
Ensuite assure toi qu'aucune classe se trouvant dans ton dossier gameEngine ne dépende d'une classe se trouvant dans gameplay.

Tu peux même ajouter une troisième granularité en fonction de ton type de jeu. Par exemple, si tu fais un mario, tu peux créer un dossier plateformer dans lequel tu mettras les classes communes entre tous les plateformers.

tu dois donc avoir une hiérarchie:
gameEngine <= GameType <= game

ou <= est une frontière à sens unique, c'est à dire qu'un membre se trouvant à gauche ne peut pas accéder à un membre se trouvant à droite, par contre l'inverse est possible.

Et pour ta question, non, le moteur graphique n'est pas un moteur de jeu, mais en est une partie. Un peu comme un écran n'est pas une télévision, mais une partie d'une télévision.

[mc salo]

[...]


@oscifer: Au top ! Ton explication et tes exemples m'ont tout a fait éclairé sur la méthode de travail que je devais adopter.

[MonsieurChance]

Bin, même si en général je n’apprécie pas le ton de Neirdan sur le forum, je trouve que sa question est pertinente.

Ça n'a guère de sens de se demander comment marche un "moteur de jeu", quelles sont ses fonctions et si c'est possible de faire un "petit jeu moche" en réalisant son propre "moteur de jeu"... tout cela sans préciser de quel jeu on parle.

Ça ne veut rien dire "moteur de jeu" quand il est question d'un petit jeu réalisé par une seul personne en 2D. Il existe des frameworks pour réaliser vite de petits projets, mais traditionnellement lorsqu'on parle de moteur de jeu on fait référence à des trucs genre : Unity, Unreal engine, le Source engine, le CryEngine, Quake engine, le Torque Game Engine, Reality engine, etc.

Avant de se demander comment réaliser son propre moteur de jeu, il faut déjà établir les fonctionnalités qu'on veut voir ce moteur prendre en charge. Si ton jeu repose juste sur un scrolling horizontal, des collisions avec des trajectoires simples et un affichage d'une poignée de sprites simultanés, ton moteur n'aura rien à voir avec celui qu'il te faudrait pour un jeu capable de gérer du pathfinding pour simultanément 50 entités différentes en temps réel, dans un environnement physique complexe avec des effets de gravité et tout cela en 60 fps.

Donc oui, les questions de Neirdan sont totalement pertinentes.



En général dans un "petit jeu moche" réalisé en solo, il est rare que les classes qu'on pourrait légitimement considérer comme composant le moteur du jeu soient clairement séparées du reste du code. Et même si ça a du sens de s'imposer un haut niveau de rigueur dans l'organisation du projet, pour un premier petit jeu ça me semble une contrainte plutôt pénible.

[Nnayl]

La pertinence y est forcement vu que l'OP pose des questions sur un sujet qu'il ne maîtrise pas... Ou a t on déjà vu quelqu'un poser les bonnes questions et dans les bons termes quand t il ne maîtrise rien du thème ?

J'attendais l'intervention de Neirdan, j'avais pas envisagé ça...
Ca se plaint et ca bash non stop quand un mec vient qu'avec des idées et qu'il veut refaire le monde, lui expliquant dans des termes associable qu'il doit d'abords commencer par les bases. Et visiblement ça bash aussi quand quelqu'un pose de simples questions pour un projet tout à fait modeste et sans prétention afin de commencer par (roulement de tambours) : "les bases".

Neirdan a prouvé par ses interventions qu'il maîtrise le sujet, qu'il s'y connait etc.. Mais au final le personnage a l'air tellement abject que je peux qu'approuver Keeth, il est pas indispensable quelque soit son savoir.

Perso j'y connais pas plus que toi, tout ce que je peux faire c'est te fournir quelques liens que j'ai pu trouvé à une époque concernant la prog de jeu.
http://jeux.developpez.com/tutoriels/jeux-video/
http://jeux.developpez.com/tutoriels/

Après je suis du même avis que les autres pour un jeu 2D première main ça serait bien de s'appuyer sur un framework existant pour en comprendre le fonctionnement et la logique, en tout cas c'est comme ça que je ferai.

[Neirdan]

Je savoure ma "mort aux rats", vois-tu.

Le mec n'a pas les bases, il n'a même pas le vocabulaire, il voit une nébuleuse sur laquelle il colle le mot "moteur".
De plus, un moteur "graphique" ca n'est pas que de la 2D ou de la 3D, y'a aussi le texte.
Tu peux faire un très bon jeu avec uniquement du texte.

Ensuite, sur le fait de coder un moteur de jeu vidéo, c'est de la connerie lorsque tu débutes parce que avec le temps ton ancien code devient obsolète.
C'est l'une des erreurs typiques que font beaucoup d'indés, qui a déjà été soulignée par des indés connus (entre autres, le mec de world of goo en parle dans une interview si je me souviens bien).

Ca ne sert à rien de commencer par faire un moteur de jeu, il faut commencer par faire un prototype où l'on intègre le minimum possible afin de tester le concept "fun" du jeu (cette règle ne vaut pas sur les gros projets, of course).
https://www.youtube.com/watch?v=ISutk1mauPM

http://www.gamesbrief.com/2013/08/co...die-developer/

http://scientificninja.com/blog/write-games-not-engines

Lol le tuto développez, c'est laid, pour plein de raisons que je ne vais pas développer.

Sinon, durant mes vacances, j'ai joué à Pong avec les manettes originales au musée des sciences de Londres, c'est une expérience.

[oscifer]

Citation :

Publié par MonsieurChance

En général dans un "petit jeu moche" réalisé en solo, il est rare que les classes qu'on pourrait légitimement considérer comme composant le moteur du jeu soient clairement séparées du reste du code. Et même si ça a du sens de s'imposer un haut niveau de rigueur dans l'organisation du projet, pour un premier petit jeu ça me semble une contrainte plutôt pénible.

Si deux débutants en construction viennent demander comment on construit une maison, on leur dit en général de commencer à faire un plan.

Réfléchir à l'architecture n'est pas pénible pour tout le monde. Si l'OP trouve ça pénible, il faut tout de suite qu'il change son idée, qu'il prenne un parpaing et monte son premier mur ( code son jeu "à l'arrache" ) . Il y arrivera peut être, mais pas de manière optimale. Le début sera fun. Il aura son premier mur en une journée, ce sera chouette. Mais il fera peut être la gueule quand il faudra l’abattre car il n'avait pas pensé qu'il fallait d'abord faire les fondations, mais si il est patient, au final il y arrivera.

Si il fait son plan, en étant débutant, il fera beaucoup d'erreurs. Mais il trouvera plus facilement des personnes qui pourront l'aider. Il n'aura pas son mur à contempler dès le premier jour. Mais il aura très probablement moins souvent besoin d’abattre un mur ou de percer une fenêtre ( même si ça lui arrivera )...

Chacun décide de ce qu'il préfère. La meilleur méthode est celle qui nous convient. Celle avec laquelle on arrive finalement à construire sa maison. Certains se découragent lorsqu'il faut planifier, d'autres quand il faut recommencer.

Citation :

Publié par Neirdan

Ca ne sert à rien de commencer par faire un moteur de jeu, il faut commencer par faire un prototype où l'on intègre le minimum possible afin de tester le concept "fun" du jeu (cette règle ne vaut pas sur les gros projets, of course).

C'est vrai, si le but est de faire un jeu.
A priori ici, l'OP veut apprendre. En se posant les bonnes question et en se familiarisant avec les bons concepts, il sera plus à même de comprendre d'ou viennent ses erreurs et donc de progresser en tant que programmeur.

[MonsieurChance]

Citation :

Publié par oscifer

Si deux débutants en construction viennent demander comment on construit une maison, on leur dit en général de commencer à faire un plan.

Oui donc pour toi, quand l'OP annonce vouloir faire un "petit jeu moche", tu penses que faire le plan c'est faire un moteur de jeu ?

Et ne pas commencer par coder un moteur de jeu ce serait donc ne pas avoir de plan en ce qui concerne ce dont il est question ici (à savoir un petit jeu réalisé en solo) ?


Pour moi, conseiller de réaliser son moteur de jeu dans ce contexte, ce n'est pas conseiller de faire un plan à quelqu'un qui débute dans la construction, mais de conseiller à ce débutant en construction d'étudier en premier lieu comment on construit des cathédrales.


Quand on veut s'essayer à la réalisation de jeux, on fait des jeux vite fait, genre un proto en moins de 10 heures de temps. On étudie là où on a atteint ses objectifs, là où on s'est raté, là où on peut s’améliorer. Et on recommence à faire un autre proto en moins de 10 heures de temps. Quitte à bazarder tout le code du premier proto au passage.

C'est ça la meilleure approche pour se lancer : Il faut mieux réaliser 10 jeux coup sur coup que de perdre ce même volume temps à tenter d'en réaliser un seul en appliquant des méthodes démesurées.

[mc salo]

Je rappelle juste que je débute et que par conséquent je ne connais pas forcément l'exacte signification des termes que j'emploie et leurs nuances.

J'avais déjà fait l'effort de corriger mon titre qui était moteur graphique et non moteur de jeu afin de ne pas contrarier la "Divinité" du code.

Je voudrais commencer par faire une simple merde :
1-Bouger un carré sur un écran et le faire voyager dans une map complètement vide à travers des pièces, vides elles aussi.
2- Et ensuite implémenter des carrés npc "méchants" attirés par mon carré joueur.

Je ne pense pas avoir les yeux plus gros que le ventre en commençant par çà.

Ma question se basait sur ce qu'était un moteur de jeu, comment il s'implantait dans du code parce que, pour moi, un jeu sans moteur de jeu ou moteur graphique , c'était pas possible. On ne peut pas plus logique comme raisonnement.

Une voiture sans moteur ça roule pas il me semble , donc lorsqu' un élève en mécanique demande comment fonctionne un moteur et comment il interagit avec le reste du véhicule, le bon prof mécano va pas vomir toute sa bile et son mépris pour montrer que lui, il sait. C'est complètement pathétique.

Bref, j'ai eu les réponses que je voulais, merci à la plupart d'entre vous pour votre pédagogie et votre humilité.

[Neirdan]

[Modéré par Gectou4 : il manque l'art et la manière ]

[oscifer]

@MonsieurChance:

Mais tout dépend de ce que recherche la personne.

Apprendre à faire un jeu et apprendre à programmer un jeu sont deux choses différentes !

Si le but est d'apprendre à faire un gameplay fun, je suis d'accord avec toi et Neirdan, il faut en faire le max possible, et pas grave si le code est pourri.

Si le but est d'apprendre à bien programmer, commencer par un moteur basique n'est pas compliqué et ça peut même être gratifiant.

Sinon je ne pensais pas forcément plan = moteur, mais j'avoue ne pas avoir très bien expliqué et mon analogie ne s'adaptait pas trop bien à ma pensée.

Pour moi, faire le plan, dans le cas de l'op, c'est déjà réfléchir à la cohérence de ses classes. Se demander si le calcul de la position d'un objet doit être effectué par ce même objet ou par une classe spécialisée par exemple.

Ce n'est pas obligatoire pour faire des petits jeux, mais ça l'est si on veut être un bon programmeur.

J'ai l'impression que pour toi, faire un moteur de jeu, c'est immédiatement recréer l'unreal engine.
Pour moi un moteur, c'est juste avoir une abstraction du code commun à tout jeu.
Si il n'a qu'un moteur de sprite et un système de gestion des inputs, il aura déjà un moteur de jeu, certes très incomplet. Faire juste ça, ça ne prend pas beaucoup de temps ( 2 semaines à tout casser pour un débutant ) et il peut le compléter au fur et à mesure qu'il progresse et fait de nouveaux projets.

Il peut commencer par faire un tetris dans lequel les blocs tomberont case par case. Il n'aura besoin dans son moteur de jeu que des deux features précitées. Tu avoueras que c'est pas la mort à faire non plus !

Ensuite il peut se dire que son tetris serait plus sympa avec un déplacement plus smooth, dans ce cas il pourra ajouter un moteur physique basique à son moteur.

Ensuite il pourra ajouter du son.

Maintenant qu'il a tout ca, il peut faire un petit shoot em up en ajoutant des collisions sphere/sphere, puis affiner avec des collisions aabb/aabb, puis ajouter une réaction à la collision ...

Ce ne sont a chaque fois que des features pas bien compliquées, facilement faisables de manière modulaire et réutilisables dans d'autres jeux.

Ca ne me semble pas insurmontable, même pour un débutant, mais je me trompe peut être.

Encore une fois, si son but est de réfléchir à du gameplay, ce que je viens de dire n'a pas un énorme intérêt et il vaudra mieux utiliser des petits moteurs existants qui sont parfaits pour le prototypage. Si il veut apprendre à bien programmer, essayer de faire un moteur de jeu n'est pas une mauvaise idée.

[Neirdan]

Selon le fait que son jeu soit en tour par tour ou en temps réel, ça change complètement.

Temps réel= AI threadée avec fréquence de calcul différente de la boucle de rendu.
Tour par tour = calcul de l'AI une seule fois

Et ça, c'est juste une chose.
On aurait été au début des années 90, j'aurai aussi dit que le dessin doit se faire uniquement sur la partie de l'écran où il y a de l'action et non l'intégralité de l'image, histoire de gagner du temps de traitement.
Maintenant ce genre de considérations n'existe plus que dans la pipeline 3D et dans les formats de compression vidéo.

De même, gérer un déplacement en temps réel, en 2D vue de dessus, ça nécessite de connaitre au minimum la normalisation d'un vecteur mouvement.

Gérer les collisions, ça nécessite de savoir si il faut faire ça "avant" ou "après" déplacement.

De même, on ne sait pas si il s'agit d'un side/top scroller infini (genre gauntlet) ou avec chargement de chaque pièce (genre zelda).

[MonsieurChance]

Citation :

Publié par oscifer

Pour moi un moteur, c'est juste avoir une abstraction du code commun à tout jeu.
Si il n'a qu'un moteur de sprite et un système de gestion des inputs, il aura déjà un moteur de jeu, certes très incomplet. Faire juste ça, ça ne prend pas beaucoup de temps ( 2 semaines à tout casser pour un débutant ) et il peut le compléter au fur et à mesure qu'il progresse et fait de nouveaux projets.

De mon point de vue, conseiller cela à un débutant est une mauvaise idée.

Un débutant ne parviendra pas à mettre en place spontanément un moteur de jeu réutilisable.

D'une parce que ce débutant va rapidement réaliser que les premiers éléments qu'il aura mis en place dans ce moteur seront rapidement devenus mal pensés et mal écrits.

Ensuite, parce que le débutant par nature est débutant, donc il aura tout intérêt à aborder son apprentissage par un chemin gratifiant. Réaliser des petits projets successifs sans penser en termes de réutilisation du code permet d'avoir régulièrement la satisfaction d'avoir des trucs fonctionnels sous les yeux tout en se perfectionnant, là où se lancer dans l'élaboration de classes capables de potentiellement un jour répondre à des besoins inconnus à ce moment là n'est pas du tout valorisant, je dirais même que c'est le contraire même.



A mes yeux, conseiller à un débutant de réaliser son propre moteur de jeu est le meilleur moyen de démotiver ce débutant.

Réaliser un moteur de jeu destiné à être utilisable sur de futurs projets, c'est une ambition de développeur très expérimenté qui a un intérêt à mettre en place ce genre d'outil.

Quelqu'un qui travaille en solo ou en team très réduite n'a pas l'usage de ce genre d'outil dans la très grande majorité des cas, selon ma propre expérience et ce que je peux voir autour de moi.

[kAzama<Off>]

Unity et Playmaker. J'en reviens pas de ce que j'arrive à faire
Le côté build et test direct aide beaucoup à ménager la motivation sur des projets persos qui peuvent s'étaler sur un-deux ans.

En ce qui me concerne, je conseillerais simplement à l'OP de commencer par suivre des tutoriels ou des livres sur le langage qui l'intéresse et la programmation de jeux. Le mieux étant d'avoir les deux en même temps, il doit bien y avoir des livres qui couvrent l'apprentissage de C++ sous l'axe de la programmation de jeux. Après ça, tout sera plus clair.

[Veilugarux]

Citation :

Publié par MonsieurChance

De mon point de vue, conseiller cela à un débutant est une mauvaise idée.

Je suppose qu'il peut par des petits jeux en 2D effectivement.
Puis comprendre comment fonctionne un moteur et enfin pourquoi pas en coder hein.
Après s'il ne connait pas son langage, il faut l'apprendre. Je conseil d'apprendre sans spécifiquement orienté lire quelque chose orienté jeu vidéo pour comprendre la mémoire, les fonctions, les objets puis les patterns.

[oscifer]

@Neirdan

D'ou l’intérêt de faire un code modulaire et donc d'avoir les bases d'un moteur.

Si on se plante dans la méthode de calcul du déplacement ou des collisions ou etc ...
On a juste à réécrire cette partie du code sans avoir à se retapper nos classes enemiOrc, enemElf, Joueur, fleche, bouleDeFeu ... Qu'on a jamais pensé à abstraire en juste quelques classes plus généralistes puisqu'on s'est dit à la base qu'on pouvait coder à l'arrache.



@MonsieurChance

Je pense qu'on a à la fois tous les deux torts et raison.
Cela dépend du profil de la personne.

Pour ma part, lorsque j'ai affiché mon premier triangle à l'écran, j'étais tout fou.
J'adore réfléchir à comment faire le meilleur code possible. Je trouve ça gratifiant, et je côtoie pas mal de personnes qui pensent comme moi. D'autres qui me disent que je suis fou...

Évidement qu'un débutant se trompera. J'ai jamais dit qu'il devait tout faire parfaitement du premier coup. Cependant je pense que si on ne se pose pas ce genre de questions dés le début, on risque par se dégoutter.
Programmer un pong "à l'arrache", puis un tetris à "l'arrache", c'est facile et à la portée de quasiment n'importe qui. Le problème c'est qu'en faisant les choses à l'arrache, on risque d'en prendre l'habitude et de se lancer sur un gros projet en utilisant la même méthode.
Et pourquoi pas puisqu'elle a déjà fait ses preuves. Le problème c'est qu'en procédant ainsi on risque de se lancer sur son gros projet et de se rendre compte au bout d'un an que dés qu'on change un comportement, tout le reste du jeu explose. Et pour le coup, perdre un an de travail, c'est à mon avis extrêmement décourageant.
Je ne dis pas qu'il doit immédiatement penser lorsqu'il fera son premier moteur à particule à faire gaffe à l'alignement des données ou que dans ses premiers pools d'objets, il doit faire gaffe à la cache. On s'en fout de ca. Par contre je pense que faire immédiatement attention à la taille de ses classes, à leur cohérence ne peut être qu'une bonne idée et que si on le fait bien, il n'y a même pas à se prendre la tête, un moteur de jeu va émerger tout seul.
Pas le meilleur du monde, je l'admet sans problème, mais est ce important ?

Et pour ce qui est du fait de ne pas utiliser ce genre d'outils en solo ou en petites équipes. Pour avoir toujours été dans de petites équipes ( seul ou jusqu'à 4 ), j'ai toujours eu à ma disposition un moteur, soit maison soit acheté ( sauf quand je faisais du portage ).

Par contre je ne connais pas le monde indie et je veux bien croire que ce ne soit pas la norme pour vous.