+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    22 471
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 22 471
    Points : 155 218
    Points
    155 218
    Billets dans le blog
    9

    Par défaut Écrire un moteur de jeux vidéo en 2017

    É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
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  2. #2
    Inactif

    Homme Profil pro
    feignant
    Inscrit en
    mars 2015
    Messages
    300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : feignant

    Informations forums :
    Inscription : mars 2015
    Messages : 300
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par LittleWhite Voir le message
    [*]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.

  3. #3
    Membre confirmé
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    210
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 210
    Points : 552
    Points
    552

    Par défaut

    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...).

  4. #4
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    22 471
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 22 471
    Points : 155 218
    Points
    155 218
    Billets dans le blog
    9

    Par défaut

    Oui, Randy s'inspire pas mal de Handmade Hero (il le dit clairement).
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  5. #5
    Inactif

    Homme Profil pro
    feignant
    Inscrit en
    mars 2015
    Messages
    300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : feignant

    Informations forums :
    Inscription : mars 2015
    Messages : 300
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Guntha Voir le message
    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...

  6. #6
    Provisoirement toléré

    Profil pro
    Inscrit en
    juin 2003
    Messages
    368
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : juin 2003
    Messages : 368
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut ouais

    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...

  7. #7
    Inactif

    Homme Profil pro
    feignant
    Inscrit en
    mars 2015
    Messages
    300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : feignant

    Informations forums :
    Inscription : mars 2015
    Messages : 300
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut

    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 ?

  8. #8
    Provisoirement toléré

    Profil pro
    Inscrit en
    juin 2003
    Messages
    368
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : juin 2003
    Messages : 368
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut

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

  9. #9
    Membre émérite Avatar de yildiz-online
    Homme Profil pro
    Architecte technique
    Inscrit en
    octobre 2011
    Messages
    723
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : octobre 2011
    Messages : 723
    Points : 2 501
    Points
    2 501

    Par défaut

    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
    Yildiz-Engine an open-source modular game engine: Website
    Yildiz-Online a 3D MMORTS in alpha: Facebook page / Youtube page

  10. #10
    Provisoirement toléré

    Profil pro
    Inscrit en
    juin 2003
    Messages
    368
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations forums :
    Inscription : juin 2003
    Messages : 368
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut Je sais

    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 .

Discussions similaires

  1. Le moteur de jeux vidéo Torque 3D est maintenant disponible
    Par raptor70 dans le forum Moteurs 3D
    Réponses: 9
    Dernier message: 12/12/2011, 14h11
  2. Le moteur de jeux vidéo Unity devient gratuit pour la création de jeux indépendants
    Par Pat_AfterMoon dans le forum Développement 2D, 3D et Jeux
    Réponses: 10
    Dernier message: 04/11/2009, 10h20
  3. Réponses: 15
    Dernier message: 18/10/2009, 01h34
  4. Réponses: 0
    Dernier message: 15/10/2009, 13h04
  5. Le moteur de jeux vidéo Torque 3D est maintenant disponible
    Par raptor70 dans le forum Actualités
    Réponses: 0
    Dernier message: 29/09/2009, 12h47

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo