Discussion :

[LittleWhite]

Écrire un moteur de jeux vidéo en 2017

On voit de plus en plus de développeurs se lancer dans la création d'un moteur de jeux vidéo. Parmi les membres de Developpez.com ont peut citer dragonjoker59 avec Castor3D ou encore zenux. Dans une vision plus large, il y a Banshee Engine, lumixengine et encore plein d'autres.
Bref, c'est une pratique courante ayant plusieurs raisons telles que :

• l'amusement de programmer un tel moteur ;
• l'expérience gagnée en le faisant et donc l'augmentation des opportunités de recrutement ;
• la connaissance parfaite du moteur pour la création d'un jeu et la création d'un moteur dédiée à un jeu précis.

Toutefois, la pratique peut aussi rapidement devenir démoralisante :

• c'est un projet colossal ;
• il existe des solutions reconnues (Unity, Unreal Engine, Godot, Game Maker...) ;
• la création d'un jeu est souvent mise au second plan et n'aboutit que très rarement.

Toutefois, le sujet d'aujourd'hui n'est pas les pour ou les contres d'une telle pratique, mais comment réaliser un moteur de jeux vidéo avec lequel vous aurez des facilités pour créer votre jeu. Sachant que nous sommes en 2017, les outils ont fortement évolué et permettent un meilleur rendement.
Randy Gaul décrit sur son blog une méthode où votre code devient l'éditeur de votre jeu. Ainsi, le C++ peut être perçu tel un langage de script. Pour que cela fonctionne, vous devez suivre quelques bonnes pratiques :

• mettre l'implémentation du jeu dans une DLL et ainsi permettre le rechargement à la volée de la logique ;
• garder des temps de compilation très bas ;
• réimplémenter le polymorphisme (le rechargement de la DLL provoquera une destruction de la vtable). Pour cela, vous pouvez utiliser un identifiant d'entité, qui sera utilisé comme indice pour votre vtable statique :
  

  Code cpp :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  enum EntityID
  {
      eDebugPlayer,
      // all other types here
   
      EntityID_Count
  };
   
  struct Entity
  {
      EntityID id;
      Entity* next;
      Entity* prev;
  };
   
  struct VTABLE
  {
      void (*Update)( Entity*, f32 );
      void (*Draw)( Entity* );
  };
   
  #define VTABLE_ENTRY( T ) \
      { \
          (void (*)( Entity*, f32 ))Update##T, \
          (void (*)( Entity* ))Draw##T \
      }
   
  VTABLE g_VTABLE[ EntityID_Count ] = {
      VTABLE_ENTRY( DebugPlayer ),
  };
   
  STATIC_ASSERT( ArraySize( g_VTABLE ) == EntityID_Count );
   
  void Update( Entity* entity, f32 dt )
  {
      g_VTABLE[ entity->id ].Update( entity, dt );
  }
   
  void Draw( Entity* entity )
  {
      g_VTABLE[ entity->id ].Draw( entity );
  }

• charger les ressources à la volée (et non juste le code). Pour cela, vous pouvez mettre en place un thread scannant les ressources afin de détecter les modifications ;
• le système Entity Component (ECS) est à bannir. Du point de vue de Randy, vous devez vous concentrer sur l'écriture du jeu et faire du refactoring que si nécessaire.

L'objectif global est de réduire les temps d'itération. Vous n'avez qu'à cliquer sur un bouton et le jeu est à jour. Même si vos valeurs sont dans le code, cela ne pose pas de souci tant que votre jeu fonctionne. Si ces valeurs doivent être disponibles pour un game designer, vous allez sûrement embarquer une bibliothèque pour lire un fichier XML (ou autre) et, chaque fois qu'il voudra tester le jeu, il devra recharger le fichier XML (souvent, cela est équivalent à recharger le jeu). De même, le fichier XML ne suffit pas toujours, car le designer voudra possiblement des changements dans les mécaniques de jeu, nécessitant une recompilation du moteur et un relancement du jeu. Cela prend du temps et encore plus si le designer (ou vous-même) devez peaufiner les valeurs. En faisant en sorte que le code devienne éditeur du jeu, ces temps sont réduits. Par contre, le designer devra avoir petite connaissance du C. Rien d'insurmontable pour des gains énormes de productivité.

Randy propose une implémentation du rechargement à la volée de la DLL sur son GitHub.


Voir aussi

CppCon 2016 - Un moteur de jeux avec la bibliothèque standard et C++11
Compilation C++ à l'exécution


Votre opinion

Vous êtes-vous lancé dans la création d'un moteur de jeux vidéo ? Quel a été votre résultat ? Comment avez-vous perçu cette expérience ? Que changeriez-vous à votre démarche ?


Source

Le blog de Randy Gaul

[stopviolence]

[*]c'est un projet colossal ;

J'dirais que ça dépend de l'ambition du projet.

J'ai causé avec dragonjoker qui cherche de l'aide sur son castor3d, qui est pour l'instant à l'état de moteur d'affichage de polygones, j'aurais bien apporté ma patte pour y ajouter des trucs à moi histoire de commencer à transformer ça en moteur de jeu, seulement j'en aurais pour minimum 1 an de travail à plein temps.

Et si mes souvenirs sont bons je crois bien que ça fait presque 10 ans qu'il bosse dessus...

Le blème c'est que pour faire un moteur de jeu 3d faut les moyens des boîtes qui font ça, des millions de budget, une équipe d'ingénieurs, 5 ans de travail à plein temps... c'est clair que je me lancerais pas là dedans. Moi j'utilise des moteurs d'affichage déjà fonctionnels et si vraiment je dois tripoter un peu de bas niveau c'est juste pour y rajouter des outils qui manquent (et rien que ça c'est déjà une masse de taf).

Sinon je fais mes petits moteurs 2d dans mon coin et là ça va c'est de l'ordre du faisable pour un type qui code tout seul.

[Guntha]

On retrouve beaucoup d'idées de Handmade Hero/du Handmade Network là-dedans (désolé de refaire mon évangéliste :p): la recompilation et le rechargement de la DLL du jeu à la volée, réduire les temps de compilation au minimum, une aversion en général pour l'orienté objet :p

De mon côté, quand j'étais encore à l'école et quand je venais d'en sortir, j'essayais de faire un moteur "intelligemment" en utilisant de l'héritage à tout va, je me prenais la tête pour trouver la meilleure approche possible (quel que soit le jeu qui tourne en dessous :p ), et maintenant je code le jeu d'abord (quitte à avoir des appels OpenGL directement dans le code du jeu), pour ensuite remonter dans le moteur les fonctionnalités qui doivent l'être. Même si je n'ai pas beaucoup de temps pour ça, ça m'a permis d'en faire plus qu'avec l'ancienne "méthode" (et puis l'expérience pro aide beaucoup...).

[LittleWhite]

Oui, Randy s'inspire pas mal de Handmade Hero (il le dit clairement).

[stopviolence]

des appels OpenGL directement dans le code du jeu

Oo

Sans même penser "moteur", ni "poo", il me semble que pour faire un bête jeu tout seul, on sépare bien proprement la partie graphique de la partie mécanique de jeu. Il m'arrive de faire deux ou trois couches de code dans des librairies séparées pour ça. Une couche hardware qui s'occupe de donner les ordres à la carte vidéo, ensuite une couche plus haute qui donne des ordres à celle-ci, et éventuellement une 3ème couche qui va par exemple gérer les animations... et puis la couche mécanique de jeu par dessus, et enfin les règles de gameplay tout en haut du gâteau. Après si tu veux en faire un "moteur" en théorie y'a que cette dernière couche qui est tripotable par l'utilisateur.

Pour ceux que ça intéresse j'essaye d'expliquer avec un exemple plus simple de comment j'avais fait sur un vieux projet de jeu 2d,

- couche 1: une librairie graphique avec des classes qui manipulent des polygones et des shaders pour afficher des tilemaps et des sprites. Le tout emballé dans une interface de fonctions qui permette de s'en servir le plus simplement possible et faire abstraction de la mécanique de la routine d'affichage hardware (genre trace moi un sprite avec quad de format A, aux coords x,y avec échelle a et rotation b, ou mets la tuile d'index i sur colonne a et rangée b)
- couche 2: une 2eme librairie qui va s'occuper des mécanismes nécessaires à faire des jeux avec (scrolling, collisions, marching squares, destruction des tiles, etc)
- couche 3: les objets du jeu en lui-même (personnages, objets qui bougent)
- couche 4: freestyle dans une state machine, j'utilise tous ces trucs pour faire un peu ce que je veux avec dans les states de gameplay

Autre projet plus récent et plus "simple" en rendu software avec une couche graphique en plus:

- couche 1: deux triangles qui servent à afficher une texture dynamique
- couche 2: le moteur de rendu software où tout est calculé au pixel, et avec son interface de fonctions pour s'en servir facilement
- couche 3: mécanismes
- etc...

J'ai jamais codé de moteur 3d ensuite mais ceux que j'ai utilisés la logique est la même. T'as la lib graphique qui s'occupe de tout le bazar hardware, avec l'interface de fonctions qui permet de dire "affiche moi le maillage A avec la texture B et la matrice C". Ensuite en général y'a une 2ème couche en plus qui te prépare ça en liste d'objets dans la ram et t'as plus qu'à dire "translate la matrice de l'objet A sur le vecteur B", cette couche d'objets dans mes dev perso je m'en sers jamais je suis plus à l'aise avec la routine de tracé (vieilles habitudes de l'époque procédurale, j'aime bien séparer totalement l'objet logique de l'objet graphique, sachant qu'un objet logique peut très bien être affiché avec plusieurs objets graphiques), mais pour faire un moteur de jeu là tu vas pas y couper. Les moteurs comme unity & unreal, tu places les objets sur la scène et ensuite tu leur colles un script qui leur envoie les injonctions de mouvement physique, bref on a une abstraction complète des mécanismes d'affichage. Là on est très loin de l'instruction opengl directement dans le code de jeu...

[super_navide]

Moi j'ai créé mon propre moteur www.power-kube.com qui continue d'évolué ....
ajoute de la physique

ajout inteligence de deplacement (les enemies explore tous seul comme des grands )

Il est sur que mon premier jeux était pas terrible et était la juste pour tester le moteurs et les différents outils.
Mais la je bosse sur power kube 2 et je pense qu'il sera meilleur car le moteur est fini et que j'ai plus qu'a penser et a me focaliser sur le jeux en lui même.
En parallèle je me suis mis a godot que je trouve génial...

[stopviolence]

C'est super intéressant ton boulot super_navide (bravo pour la physique).

Tu utilises quel type de graph pour guider les paths d'intelligence artificielle ? Je suppose que tes maps sont structurées en octree ?

[super_navide]

j'utilise un octree pour gérer le path finding
sinon pour la physique j'y suis pour rien je réutilise jbullet

[yildiz-online]

jbullet a pas été mis à jour depuis des lunes (et le sera pas vu que l'auteur compte pas bosser sans être payé...)

Avec du JNI tu peux te débrouiller sur bullet natif, c'est assez simple, je l'ai fait sur mon moteur:

https://bitbucket.org/yildiz-engine-...physics-bullet

[super_navide]

Je sais qu'il n'est plus maintenu , mais j'ai le code source et il répond a mon besoin qui est juste de faire des explosions plus jolie.
Et puis tant qu'au niveau perf ça tient la route je reste en tous java .

[Invité]

Bonjour, désolé de déterrer ce blog mais jaimerais savoir, @super_navide si ton moteur de jeu est Open Source car j'aimerais créer le mien mais je suis lyceen et je ne sais pas en quel language ... donc voilà. merci de ta réponse
cordialement
syrotix

[dourouc05]

je ne sais pas en quel language ...

je reste en tous java .

[Invité]

ok dac merci mais quel est l'utilité du java car je ne l'ai jamais utilisé . que fait il ... ses limites... merci de vos réponses!

[Kannagi]

Si tu veux faire un moteur 3D , utilise le langage qui te plaît le plus , même si le C++ est le plus indiqué pour la tache (dans le sens où il est compilé donc assez performant).

[yildiz-online]

Si tu ne connais pas les possibilités des langages les plus communs, c'est un peu tôt pour vouloir créer un moteur de jeu.

Un jeu est une application complexe qui touche plusieurs domaines, un moteur de jeu est encore plus complexe vu qu'il doit pouvoir supporter plusieurs jeux, en simplifiant leur création.

Commence par faire 2 ou 3 petits jeux tout simples (tetris, pong, arkanoid) qui ne sont pas des clones les uns des autres pour avoir plusieurs cas de figures (et bien sur qui représentent le type de moteur que tu veux créer), et une fois ceci achevé, essaie d'en extraire les composants communs, et fais un nouveau jeu à partir de ces composants.

Si ça passe, tu es sur la bonne voie, continue comme ça jusqu'à avoir un framework/librairie de plus en plus complet, refactor tes premiers jeux pour utiliser le moteur et continue ce développement itératif.
En parallèle tu peux développer des outils pour simplifier l'utilisation du moteur(sdk avec interface graphique).

[Mat.M]

ok dac merci mais quel est l'utilité du java car je ne l'ai jamais utilisé . que fait il ... ses limites... merci de vos réponses!

l'avantage de Java c'est de manipuler des objets "astraits" indépendants de toute technologie, de tout matériel.

En manipulant un objet Graphics en Java on fait abstraction du matériel.

Cependant on peut faire la même chose en C++.

Mais comme il est affirmé souvent sur ce forum il vaut mieux prendre le C++ pour des questions de performances.
Surtout que pour optmiser du code et faire du code GPU sous Open GL ou D3D ça ne se fait qu'en C++ et HLSL.
Peut-être qu'il existe des classes Java pour faire ça mais ça risque d'être moins performant.

Maintenant comme l'écrit très bien Littlewhite dans le premier message cela ne présente pas d'intérêt de faire un moteur de jeu rien que pour ça, autant utiliser Unity ou Unreal Engine.
Pour faire un Unreal Engine il faut une équipe de plusieurs programmeurs chevronnés.

[yildiz-online]

Mais comme il est affirmé souvent sur ce forum il vaut mieux prendre le C++ pour des questions de performances.

Si c'est une question de perf, y a beaucoup plus de chances qu'un débutant mette le pc à genoux parce que ses algos sont mauvais, ses assets non optimisés, plutôt qu'à cause du langage.
Java reste très largement suffisant en terme de performance et c'est un langage bien plus productif que c++, tout comme kotlin est bien plus productif que java , et python plus que kotin etc, etc...
Bref, mieux vaut choisir quelque chose avec lequel on pourra bosser plutôt que de se mettre des limitations d'avances sur des assomptions peu probables.

Surtout que pour optmiser du code et faire du code GPU sous Open GL ou D3D ça ne se fait qu'en C++ et HLSL.
Peut-être qu'il existe des classes Java pour faire ça mais ça risque d'être moins performant.

L'optimisation ne se fait qu'à la fin, le temps qu'il y arrive il sera déjà à la 3e ou 4e itération de son moteur et aura sans doute changé de langage entre temps.
Le code HLSL (ou GLSL) est compilé par un compilateur indépendant, aucun impact du langage appelant.

[Invité]

merci pour votre aide , le seul problème restant est que après avoir fait des jeux comme pong., Pacman... j'ai mon idée de jeu (de ma vie professionnelle) mais le moteur de jeu serait seulement pour ce jeu et ces composés et ce jeu est en 3d . comment faire pour avoir les connaissances pour faire un moteur de jeu? savoir faire une appli? savoir programmer en tout les langages?... voilà les questions que je me pose car la première étape de ce jeu serait de faire le moteur

[Kannagi]

Si ton but est de faire un jeu alors utilise Unity ou Unreal...
Pour les connaissances bah un moteur de jeux vidéo reste un abus de langage , vu que c'est plus ou moins un framework assez spécialisé.
Et un framework est un ensemble de fonction/classes , avec une architecture précise.
Et ces ensembles de fonctions/classes sont fait pour faire un jeu , tu pourrais avoir que des fonctions pour le rendu mais ça serait un moteur de rendu et non un jeu , quand tu as un ensemble qui gère l'ensemble des besoins d'un jeux vidéo qui est le rendu , les collisions , le son , gérer le fenêtrage/les event , les script , les outils de façon unifié tu aura ton moteur de Jeux vidéo , pour cela qu'on le conseille pas au premier débutant...

[Invité]

ok dac kannegi je fais mon jeu sur unity et après, quand je serais prêt j'essayerais de faire ce moteur de rendu. Mais je veut seulement qu'il ne soit que pour ce jeu donc ok dac d'abord sur unity et après je verrais MERCI!