Développer un jeu vidéo sans moteur de jeu (2025)

 (noelberry.ca)
33 points par GN⁺ 2025-05-21 | 5 commentaires | Partager sur WhatsApp
  • Il est tout à fait possible de développer des jeux de manière simple et amusante sans moteur de jeu commercial
  • La plupart des fonctionnalités des gros moteurs ne sont pas nécessaires, et écrire soi-même ses outils apporte davantage de souplesse et d’efficacité de développement
  • En s’appuyant sur C# moderne et des bibliothèques open source, il est possible de disposer d’un environnement de développement suffisant, quelle que soit la taille de l’équipe
  • En combinant des bibliothèques comme FMOD, SDL3, Dear ImGui avec ses propres outils, on peut construire un pipeline adapté à ses besoins
  • Du point de vue du développement cross-platform, de la maintenance et de la portabilité, un framework léger construit en interne est très avantageux

Préface : réflexions d’un développeur de jeux avec 20 ans d’expérience

  • En 2025, l’auteur développe toujours des jeux vidéo sans moteur de jeu commercial
  • Beaucoup de personnes autour de lui sont surprises qu’il n’utilise pas de moteur commercial
  • Les fonctionnalités de base des gros moteurs comme Unity ou Unreal sont moins satisfaisantes qu’une implémentation maison, et il faut souvent en reconstruire une grande partie au final
  • L’usage de moteurs commerciaux expose régulièrement aux problèmes causés par les changements de politique commerciale ou par les mises à jour
  • Créer soi-même de petits outils parfaitement adaptés à chaque projet est plus efficace et, à long terme, plus facile à maintenir

Choisir le langage de programmation nécessaire au développement de jeux

  • L’auteur utilise C# comme langage principal depuis longtemps
  • Le C# moderne s’est beaucoup amélioré par rapport au passé en matière de performances, de syntaxe et d’expérience de développement
  • Des fonctions de hot reload comme dotnet watch sont très pratiques pour modifier et tester le code en temps réel
  • Même les non-développeurs peuvent s’y mettre facilement, ce qui améliore la répartition des rôles et l’efficacité de la collaboration au sein de l’équipe
  • La fonctionnalité intégrée de reflection est un atout pour créer des éditeurs ou des outils

Bibliothèques cross-platform et implémentation du rendu et des entrées

  • Avec SDL3, l’auteur implémente toutes les fonctions de base : fenêtres, rendu, contrôleurs, support cross-platform, etc.
  • L’abstraction GPU de SDL3 facilite la prise en charge de différents environnements comme DirectX, Vulkan, Metal
  • Une couche C# écrite au-dessus de SDL (par exemple Foster) est utilisée comme utilitaire commun
  • FMOD reste le dernier outil audio commercial utilisé ; pour le reste, le pipeline repose sur l’open source
  • L’auteur a auparavant aussi implémenté directement OpenGL/DirectX, mais la stabilité de SDL constitue un avantage important

Méthode de gestion des assets

  • Lorsqu’on utilise son propre moteur, on charge simplement uniquement les fichiers nécessaires au jeu
  • Pour des assets de petite taille, comme dans un jeu en pixel art, tous les fichiers sont chargés d’un coup à l’initialisation
  • Dans les grands projets, seuls les assets nécessaires sont chargés à la demande, puis libérés de la mémoire lors des changements de scène
  • Lorsqu’une conversion est nécessaire, il suffit d’écrire un script de traitement automatique à la compilation

Éditeur de niveaux et outils UI

  • Il est facile d’intégrer les données d’éditeurs de niveaux open source comme LDtk, Tiled, Trenchbroom
  • En général, un éditeur sur mesure est implémenté directement pour chaque projet
  • Plutôt que d’écrire toute l’UI à la main, l’auteur utilise activement la GUI en mode immédiat de Dear ImGui
  • La combinaison de la reflection de C# et d’ImGui permet de visualiser en temps réel l’état des objets du jeu
  • Si nécessaire, des outils externes adaptés à l’objectif peuvent être mélangés avec des outils maison

Cross-platform et portabilité vers les consoles

  • Autrefois, les problèmes de portage sur console rendaient souvent le choix du C++ nécessaire, mais l’arrivée de C# Native-AOT a changé la donne
  • Des frameworks open source comme FNA étendent activement leur support des consoles
  • En exploitant la couche d’abstraction générique fournie par SDL3, il est possible d’utiliser la même base de code sur la plupart des systèmes

Environnement de développement : un écosystème ouvert centré sur Linux

  • La plateforme de développement principale a été déplacée vers Linux, qui fonctionne très bien avec les toolchains open source
  • Il reste des liens avec certains logiciels commerciaux spécifiques (par ex. vscode, github), mais plus l’écosystème open source s’élargit, plus le support progresse
  • L’auteur met en place le même environnement de travail sur différentes plateformes basées sur Linux, comme le Steam Deck

Q&R supplémentaires et exemples

  • Question sur l’usage de Godot : si l’on souhaite développer autour d’un moteur open source, Godot est recommandé ; sinon, l’auteur préfère les outils personnalisés
  • Travail en 3D : les gros moteurs ont des avantages, mais pour des projets spécialisés de petite taille, un framework sur mesure suffit largement
  • Besoins techniques de haut niveau : selon les exigences, utiliser un gros moteur comme Unreal reste tout à fait valable
  • Changement de moteur à l’échelle d’une équipe : cette approche convient bien au développement solo ou en petite équipe, et même des studios de taille moyenne à grande se tournent de plus en plus vers des moteurs maison pour éviter les risques à long terme
  • Workflow des assets : les fichiers Aseprite peuvent être automatiquement convertis en animations en exploitant les tags et timings intégrés

Conclusion

  • Créer un jeu sans moteur de jeu commercial est un choix qui dépend avant tout des préférences et de la manière de travailler
  • Il suffit de choisir la méthode qui vous convient le mieux, en donnant la priorité à vos besoins et au plaisir de créer

À lire aussi

5 commentaires

 
assembler 2025-05-29

C’est une belle initiative.
J’ai fait partie de la première génération de développeurs de jeux.
Avant l’arrivée d’Unreal, il allait de soi que les studios
développaient leur propre moteur,
et c’était justement là leur avantage concurrentiel.
Le développement du moteur consistait en grande partie à créer des outils
à partir du core, du kernel, du rendu et des autres entrées/sorties.
À l’époque, j’étais en charge des outils de particules, de son, de couches et d’objets,
et notre équipe comptait 7 personnes, mais en réunissant tout,
je crois qu’on dépassait facilement la vingtaine d’outils.

Puis, à partir du moment où Unreal est arrivé et que les jeux produits à la chaîne
se sont mis à déferler, ils n’ont plus investi dans le développement de moteurs.
Je crois que beaucoup de gens se sont alors mis à leur compte et ont créé leur entreprise.
C’était il y a déjà 27 ans.

Moi aussi, j’ai pris de l’âge entre-temps et je travaille désormais sur autre chose que les jeux.

Cela me rappelle avec nostalgie cette époque où je faisais du travail bas niveau sur le core
en fonction de la carte graphique, avec des modes directx et opengl distincts.

Bon courage...
 
chanapple 2025-05-21

Dernièrement, comme je cherchais depuis longtemps un moteur pour créer un jeu de stratégie, je me suis dit qu’à ce compte-là il vaudrait mieux en fabriquer un moi-même ; voir un exemple de quelqu’un qui est passé à l’action et a réussi me redonne vraiment du courage.
 
GN⁺ 2025-05-21
Avis Hacker News

  • Après avoir développé seul un moteur de jeu 2D pendant 5 ans, tout en faisant des missions rémunérées liées à ce sujet, je veux expliquer un point important que les gens connaissent mal
    Le moteur, c’est la partie facile
    Ce qui compte vraiment, c’est le tooling autour du moteur, le contenu et le pipeline d’assets
    Importer des textures, de l’audio, des modèles (gltf, fbx, animations, etc.) depuis diverses sources et formats de données
    Dans l’application d’édition, fournir les fonctions d’édition de base comme couper, copier, coller, annuler, rétablir, enregistrer et supprimer
    Des visualisations et des fonctionnalités permettant aux développeurs de créer et manipuler de vraies données avec l’éditeur (entités, animations, scènes, graphe audio, prise en charge du scripting, etc.)
    Le packaging et le prétraitement des données, comme le baking de géométrie statique, la compilation de shaders, le rééchantillonnage et l’empaquetage de textures et d’audio, ou encore la création de packs d’assets de contenu de jeu
    Une fois tout cela terminé, la partie runtime proprement dite (c’est-à-dire la boucle principale du jeu et les sous-systèmes) n’est qu’une petite partie de l’ensemble
    C’est pour cela que dans les studios de jeu, il y a peu de personnes affectées au moteur et une majorité de programmeurs qui fabriquent des outils
    Moteur detonator : https://github.com/ensisoft/detonator

    • Il est important de se concentrer sur la création d’un moteur adapté à son propre jeu plutôt que de viser un moteur généraliste
      L’UI, la compression, etc. peuvent être gérées avec des bibliothèques et des frameworks
      Le fait que l’OP utilise de petites bibliothèques comme imGUI en est un bon exemple
      Comme il ne s’agit pas de créer un moteur pour tous les jeux, cela supprime en pratique beaucoup de travail inutile

    • Un moteur n’est qu’un petit runtime greffé à un pipeline d’assets
      De nos jours, même les compilateurs de shaders deviennent progressivement plus importants que les API 3D
      Les parties intéressantes se concentrent dans le compilateur de shaders, tandis que l’API 3D se limite à exécuter les shaders et transporter les données

    • Quand les gens parlent de moteur, ils ont souvent tendance à inclure aussi le pipeline d’assets et l’éditeur
      Un moteur moderne, ce n’est pas seulement une boucle principale + quelques fonctions d’API 3D
      Même quand on utilise un moteur comme Unity, très peu de développeurs n’écrivent que du code de rendu
      Bien sûr, utiliser Unity ou Unreal ne veut pas dire qu’on n’a jamais besoin de créer soi-même des outils d’assets

    • En ayant récemment réécrit le moteur pour une suite, je suis tout à fait d’accord avec ça
      Comme je l’ai écrit dans mon post-mortem, quand on parle de moteur, la plupart des gens pensent au code inclus dans l’exécutable du jeu, mais en pratique je pense que la part la plus importante, c’est le code non distribué avec le jeu, comme l’éditeur de niveaux, le pipeline de contenu, le débogage/profiling et le workflow de développement
      Le développement d’outils est un travail plus ennuyeux et plus épuisant que le développement du moteur
      C’est pour cette raison que tant de développements de jeux sur moteur custom s’arrêtent en cours de route
      Post-mortem : https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • Construire un éditeur depuis zéro représente un travail considérable
      Quand c’est possible, j’utilise des éditeurs existants
      Par exemple TrenchBroom (éditeur Quake) + func_godot, ou Tiled pour la 2D
      Pour gérer les données de jeu, il y avait aussi CastleDB, désormais intégré à Hide (un véritable éditeur 3D)
      Après avoir construit les outils, il reste encore l’étape majeure de la conception du jeu et de la création du contenu

  • Il y a quelques années, avec SDL2 et un peu de C++, j’ai créé une classe simple de sprite et ajouté quelques fonctions basiques comme les collisions
    Si je devais vraiment appeler ce que j’ai fait un moteur, c’était plutôt une sorte d’assistance de vélo électrique
    Le point important, c’est que le « moteur » finit souvent par diriger l’ensemble du projet/jeu
    On se retrouve souvent à adapter le jeu au moteur, ce qui est la raison pour laquelle j’évite toujours d’utiliser de gros moteurs comme Unity
    Ces moteurs finissent par produire toujours la même structure de jeu, seuls les assets changent
    Personnellement, au lieu de perdre du temps à apprendre un moteur, je peux commencer avec SDL grâce à une courbe d’apprentissage courte, et SDL peut aussi servir à d’autres projets cross-platform en dehors du jeu
    Mon jeu : https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • On dit que créer son propre moteur prend longtemps, mais combien de temps faut-il pour vraiment maîtriser Unreal ou Unity au point de pouvoir transformer immédiatement une idée en jeu ?
    Au final, une fois mon moteur terminé, j’aurai directement ce niveau d’expertise, donc c’est un gain de temps sur le long terme
    Plus on a d’expérience comme ingénieur, plus fabriquer soi-même devient avantageux du point de vue du temps
    Plus le jeu est unique ou de niche, plus le choix du développement maison est pertinent
    Passer des mois à se perdre dans l’UI complexe d’Unreal pour découvrir que ce qu’on voulait est pratiquement impossible dans un moteur généraliste, c’est inefficace
    En revanche, pour un RPG open world photoréaliste, le faire soi-même n’est pas un bon choix
    Les contraintes d’un moteur custom peuvent au contraire stimuler la créativité, et produire des jeux plus originaux, même sans atteindre le plus haut niveau technique

    • J’ai déjà construit mon propre moteur
      Au début, cela m’a pris environ un an, avec d’innombrables essais-erreurs et impasses
      J’y ai implémenté presque tous les sous-systèmes qu’on voit dans un jeu : rendu 3D, UI adaptative, animation squelettique, fichiers de sauvegarde, smart objects, pathfinding, scripting, audio, physique, etc.
      J’ai notamment implémenté moi-même une fonction de rembobinage (comme le système de Braid)
      Ce type de fonctionnalité exige le support de tous les sous-systèmes du moteur (scripts, physique, etc.)
      Je connais chaque partie du moteur que j’ai créé, ce qui me donne une énorme liberté pour développer des fonctions supplémentaires
      Mais après un an de développement, le burnout s’est installé peu à peu et j’ai perdu la motivation

    • Je ne connais pas Unreal, mais avec Unity on peut développer plus de 10 fois plus vite qu’en codant tout soi-même
      Ajouter de la physique prend 1 minute, alors qu’avec un moteur maison rien que l’intégration d’une bibliothèque externe peut prendre un ou deux jours
      Les fonctions de visualisation interne montrées par Noel dans Unreal sont aussi intégrées à Unity
      L’édition de choses comme les bounding boxes est fournie de base
      Et si le comportement de base du moteur ne suffit pas, on peut facilement l’étendre avec ImGui ou un moteur CSS basé sur Yoga
      Le moteur offre aussi un éditeur de particules avancé, des shaders dont la complexité est déjà absorbée, du data streaming modulaire, et bien d’autres fonctions
      En théorie j’aimerais tout faire moi-même, mais au final la question est celle du temps, donc priorité à terminer

    • Le temps nécessaire pour apprendre Unreal ou Unity au point de pouvoir implémenter directement une idée de jeu, et le temps nécessaire pour créer son propre moteur, ce sont deux questions différentes
      Donnez-moi une petite idée, et je peux produire un prototype jouable en quelques heures
      Avec Unity, au départ il suffit juste de programmer, et avec Unreal on peut aller presque jusqu’à la sortie du jeu en utilisant seulement les blueprints
      Voir cette vidéo où un prototype de jeu style Super Hexagon est réalisé en 10 minutes : https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      Dans Unity, l’élément vraiment spécifique est surtout le prefab, le reste relève de concepts généraux du développement de jeux
      Du point de vue d’un développeur Unreal, je pourrais faire un prototype similaire sous Unity en moins d’une heure

    • L’hypothèse même du « après avoir terminé le moteur » est peut-être irréaliste
      Même une action simple comme GameObject.Instantiate demande des ressources énormes si on doit l’implémenter soi-même dans le moteur
      Il faut tenir compte de la complexité de la physique 2D/3D, des shaders, du support des plateformes, etc.
      Si l’objectif est le moteur, faites un moteur ; si le but est le jeu, faites le jeu lui-même

    • Si vous avez déjà assez de connaissances en développement de jeux pour construire un moteur de jeu
      une journée suffit pour apprendre Unreal ou Unity au point de faire un prototype
      Atteindre une maîtrise parfaite prend longtemps, mais le temps pour sortir le prototype du jeu voulu est sans commune mesure

  • Faire un jeu sans gros moteur « qui fait tout » est plus facile, plus amusant et parfois plus efficace
    Cela dit, quand on creuse certaines fonctions spécifiques du moteur (par exemple l’IK d’Unreal ou l’animation blending), on se dit aussi « heureusement que je ne me suis pas infligé 2 ou 3 semaines de travail pour refaire ça moi-même »
    Le minimalisme ou la lutte contre le bloat sont importants, mais si ces moteurs sont si populaires, c’est aussi parce qu’ils prennent en charge le gros du travail difficile

    • Avant, j’étais moi aussi dans cette approche
      Quand j’ai voulu faire mon premier jeu 3D, j’ai tout implémenté moi-même : input, gestion des objets, culling, chargement de modèles, bibliothèque mathématique, graphismes, normal maps, SSAA, etc., et au final l’avancement réel du jeu était de 0 %
      En revanche, pour mes projets 2D hobby, je continue encore à développer sans dépendances avec juste le canvas du navigateur
      En pratique, c’est le navigateur qui joue le rôle du moteur

    • À propos du « heureusement que je ne l’ai pas fait moi-même »
      si on pense à sa carrière d’indé sur le long terme, même si cela prend quelques semaines, une compréhension profonde du sujet + la possession à 100 % du code source et sa valeur de réutilisation ont davantage de valeur

    • Mon mémoire de fin d’études portait sur le portage vers Windows 95/Visual C++ d’un moteur de particules basé sur NeXTSTEP/Objective-C (OpenGL, avec un exemple utilisant marching cubes)
      Aujourd’hui, ce genre de thème n’est plus qu’une petite partie d’une fonctionnalité qui tient en une ligne dans les moteurs modernes

    • Utiliser un moteur fait avancer le projet bien plus vite et évite de dépenser son temps à développer l’infrastructure
      Réinventer la roue n’est pas particulièrement amusant pour la plupart des gens

    • Des fonctions comme l’IK ou l’animation blending
      si elles sont au cœur du jeu, alors cela vaut la peine de les implémenter ; sinon ce sont juste des pièges techniques inutiles

  • Je fais mes jeux à ma manière avec Lua & Love2D
    Le fait même de s’imposer ses propres contraintes est au cœur du plaisir
    Quand le développement cesse d’être amusant, c’est le signe que quelque chose ne va pas, donc il faut chercher une meilleure façon de faire
    Mon jeu YOYOZO est minuscule, 39 KB, mais il a figuré aux côtés de grosses productions dans la liste des meilleurs jeux de 2023 d’Ars Technica
    https://news.ycombinator.com/item?id=38372936

    • Je me souviens de ce jeu
      Des années après avoir acheté une Playdate, j’ai enfin commencé à jouer avec le SDK, et j’apprends aussi Lua pour la première fois
      J’aimerais davantage de typage fort et de sécurité dans le langage, mais c’est suffisant dans ce contexte
      Pour l’instant je n’ai fait qu’une petite démo technique où du texte tourne dans un faux espace 3D selon la manivelle
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      Ce projet m’a fait réaliser qu’après une longue carrière dans le CRUD et les web apps, j’avais presque tout oublié de la trigonométrie
      Le meilleur aspect du développement sur Playdate, c’est cette sensation libératrice d’avoir un canvas fixe : une fois les pixels placés, ça fonctionne tel quel sur tous les appareils
      Après des années passées à ne faire que des UI responsives, c’est une expérience très nouvelle pour moi

  • Chaque fois que j’essaie de créer quelque chose avec un moteur de jeu (Godot, Unity, Unreal, etc.), je finis toujours par me battre contre le moteur
    Au final, j’ai l’impression d’empiler des assets sur une forme de jeu prédéfinie, ce qui rend difficile la création du jeu que je veux vraiment
    Si on compare au développement web, cela ressemble à un produit fini comme WordPress
    Quand la configuration de base ne correspond pas à l’intention, cela exige énormément de hacks et de contournements

  • L’auteur (Noel) a créé le jeu Celeste, vendu à plus de 3 millions d’exemplaires
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • Je suis largement d’accord moi aussi, et je construis un framework de jeu C# orienté code (héritier spirituel de XNA/Monogame, utilisant Sokol plutôt que SDL)
    https://zinc.graphics/
    Les points forts du C# moderne : cross-platform, compilation NativeAOT, hot reloading natif, reflection, etc.
    Personnellement, j’y ai aussi ajouté des source generators
    L’image négative du passé subsiste, mais les progrès de CoreCLR et du langage ces 5 dernières années sont remarquables
    La seule chose qui me manque vraiment, ce sont les Union Types, actuellement proposés et que j’espère voir ajoutés l’an prochain
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • Je me demande s’il existe des ressources à consulter pour débuter en C# dans ce type de projet
      Je n’ai utilisé C# que sur Win32 ou dans Unity, et même si j’ai des connaissances bas niveau côté moteurs en C/C++, je pensais que C# était impossible pour du cross-platform comme les consoles de jeu
      Je réalise maintenant que je me trompais

  • Pour n’importe quel logiciel, je préfère partir de zéro au début
    Pour quelqu’un qui a de l’expérience sur de gros projets, cela peut sembler lent, mais au stade startup c’est au contraire plus rapide
    On implémente seulement le strict minimum, puis dès qu’une abstraction apparaît, la vitesse d’ajout de nouvelles fonctions augmente
    La productivité dans un gros logiciel d’entreprise et dans un mini-moteur écrit soi-même n’a rien à voir
    Le code qu’on a écrit soi-même se coupe et se refactore immédiatement, donc on va beaucoup plus vite
    C’est pour cela que je préfère les microservices et les petites équipes
    Quand on construit soi-même, il faut forcément passer par des tâtonnements et un champ de mines de choses qui cassent, et il faut aussi des années pour vraiment comprendre la nature du langage ou de la plateforme
    Mais au final, tout ce processus devient une vraie force accumulée pour le développeur
 
kissdesty 2025-06-10

Plutôt que d’utiliser un moteur, je me demande ce que ça donnerait de s’en tenir à un framework du niveau de MonoGame~
 
lazyhack 2025-05-23

« Le processus en lui-même finit par devenir la vraie maîtrise du développeur » : je suis tout à fait d'accord.