Pourquoi je crée des jeux en C (oui, en C)

 (jonathanwhiting.com)
3 points par GN⁺ 2026-02-09 | 1 commentaires | Partager sur WhatsApp
  • Tous les jeux de ses projets personnels sont développés en « C pur », un choix devenu rare aujourd’hui
  • Les critères clés dans le choix du langage sont la fiabilité, la portabilité et la pérennité à long terme, sans dépendance à un OS ou une plateforme spécifique
  • Il accorde une grande importance à la simplicité et à la rapidité de compilation, ainsi qu’à un contrôle de types strict et un système d’avertissements puissant
  • Des langages alternatifs comme C++·C#·Java·Go·Haxe ont été examinés, mais jugés inadaptés en raison de leur complexité, du GC ou de l’imposition de l’OOP
  • Le C est dangereux mais simple et rapide, et reste selon lui le meilleur choix grâce à son large support des plateformes et à un écosystème de bibliothèques solide

Critères de choix du langage

  • La condition essentielle est la fiabilité et la stabilité, afin de ne pas perdre de temps sur des bugs qu’il n’a pas lui-même créés
    • Il a auparavant développé des jeux basés sur Flash, mais avec le déclin de Flash, il préfère se concentrer sur la création de nouveaux jeux plutôt que sur leur portage vers de nouvelles plateformes
    • Il privilégie la portabilité et le support de bibliothèques généralistes pour éviter toute dépendance à un OS donné et garder ouverte la possibilité de développer sur console
  • Parmi les critères souhaitables, il cite une syntaxe simple et une structure facile à retenir
    • Il veut éviter de devoir constamment rechercher des API ou des fonctionnalités du langage trop complexes
  • Il cherche à réduire les bugs grâce à un contrôle de types strict, des avertissements puissants et de l’analyse statique, et à faciliter leur détection avec un bon débogueur et des outils d’analyse dynamique
  • Il accorde une très grande importance à la vitesse de compilation
    • Les longues attentes brisent la concentration et réduisent la productivité
  • Il est sceptique vis-à-vis de la programmation orientée objet (OOP) et préfère séparer les données et le code pour les traiter selon le contexte

Évaluation des principales alternatives

  • C++
    • Il reste la norme dans le développement de jeux, mais il le juge insatisfaisant à cause de sa complexité et de sa lenteur à la compilation
    • Il offre de hautes performances et de nombreuses fonctionnalités, mais trop de fonctions non désirées s’y ajoutent, avec un coût élevé en complexité
  • C# et Java
    • Ils sont verbeux et complexes, et leur structure fortement centrée sur l’OOP réduit la liberté
    • Leur nature de langages de haut niveau masque la complexité, sans empêcher les problèmes de fond
  • Go
    • Il le voit positivement comme une réinterprétation moderne du C, mais son garbage collector stop-the-world le rend inadapté au développement de jeux
    • Il s’inquiète aussi du manque de bibliothèques pour le jeu et de sa pérennité à long terme
  • JavaScript
    • L’évolution rapide de l’environnement web et la fin de Flash lui donnent une impression d’instabilité
    • Sa syntaxe permissive le rend, selon lui, inadapté à l’écriture de logiciels de grande taille
  • Haxe
    • Il le considère prometteur pour le développement web, mais s’interroge sur sa pérennité en tant que langage relativement récent
  • Développer son propre langage
    • L’idée est séduisante, mais il la juge peu réaliste à cause de l’abandon des bibliothèques existantes et de la charge liée au maintien de la compatibilité

Pourquoi choisir le C

  • C’est un langage risqué mais fiable qui, grâce à sa structure simple, peut être utilisé de façon stable avec suffisamment de précaution
    • Il le compare à un « couteau tranchant » : difficile à manier, mais un outil puissant une fois maîtrisé
  • La compilation est très rapide, et les programmes peuvent tourner sur presque toutes les plateformes
    • Le portage est lui aussi relativement simple, ce qui en fait un choix durable sur le long terme
  • Le support des bibliothèques et des outils est solide et se maintient dans le temps
  • À titre personnel, il possède déjà une grande expérience avec du code en « C pur », ce qui le rend familier pour lui
  • Il ne recommande pas l’usage du C à tout le monde : c’est un choix personnel, optimisé pour ses préférences et sa manière de travailler

À lire aussi

1 commentaires

 
GN⁺ 2026-02-09
Avis sur Hacker News

  • J’écris principalement du code dans un style C, en n’utilisant des fonctionnalités C++ que lorsque c’est nécessaire
    Du coup, à première vue, ça peut parfois ressembler à du code Rust
    Ceux qui disent écrire des jeux en C détestent souvent les fonctionnalités de C++, mais finissent par implémenter eux-mêmes des interfaces virtuelles ou par faire d’énormes switch pour obtenir à peu près le même résultat
    Si on ne veut pas utiliser une fonctionnalité du langage, il suffit de ne pas l’utiliser ; se plaindre de son existence n’a pas vraiment de sens
    C++ ne compile pas lentement si on n’abuse pas des templates

    • En solo, oui, mais sur un projet maintenu sur le long terme par une équipe, la situation est différente
      Avec le temps, les membres changent, les responsables changent, et l’ensemble des fonctionnalités utilisées s’élargit progressivement
      Une fois cet ensemble étendu, il est très difficile de le réduire
      Et il faut parfois utiliser des bibliothèques qui emploient des fonctionnalités qu’on ne veut pas
      Par exemple, je n’aime pas les appels implicites (destructeurs, surcharge d’opérateurs, etc.), mais si une bibliothèque les utilise, on est obligé de suivre
    • Au moins, un switch reste lisible
      L’un des pires aspects de C++, c’est la quantité de code caché généré automatiquement
    • Le dispatch dynamique de C++ consiste à attacher une vtable à chaque type
      Même si l’essentiel du code manipule des types concrets (Goose, Duck, etc.), tous les objets trimballent un pointeur de vtable
      Rust, au contraire, n’utilise des vtables qu’aux endroits nécessaires, ce qui économise de la mémoire
      Les programmeurs C implémentent eux-mêmes uniquement les mécanismes dont ils ont besoin, et sont donc moins contraints par une structure imposée par le langage
    • C++ est lent même sans abus de templates
      Le simple fait d’inclure <vector> ajoute des dizaines de milliers de lignes de code
      Donc si on n’utilise pas la bibliothèque standard, on se retrouve avec l’éternel débat du « pourquoi réinventer la roue ? »
      À force de revoir ce débat sans cesse, revenir à C devient franchement plus simple
      J’ai moi-même basculé vers C vers 2017, et aujourd’hui encore, chaque fois que j’utilise une bibliothèque C++, ça me fatigue
      Dear ImGui fait exception, mais même là je préfère les bindings C
    • Il m’est vraiment arrivé d’écrire un fichier C++ sans utiliser la moindre fonctionnalité C++
      En changeant simplement l’extension en .c, le temps de compilation a été divisé par deux

  • J’aime le côté brut et simple de C, même si je déteste le préprocesseur
    C’est pour ça que Zig ressemble vraiment à un cadeau du ciel — plus simple que C, avec une conception du langage plus rigoureuse
    Par exemple, Zig distingue les pointeurs simples des pointeurs de tableau
    On peut importer des bibliothèques C et les rendre plus agréables à utiliser, ce qui est très utile en développement de jeux
    La plupart des bibliothèques C++ fournissent aussi des en-têtes C
    zig-gamedev contient beaucoup de ces bibliothèques C “zigifiées”
    À la place du préprocesseur, la fonctionnalité comptime de Zig est bien meilleure, et n’est au fond que du « code Zig exécuté à la compilation »

    • En pratique, il y a quand même beaucoup trop peu de bibliothèques C++ qui exposent des en-têtes C

  • Moi aussi, je comprends bien la position de l’auteur
    La principale raison pour laquelle on finit par aimer un langage, c’est sa simplicité
    C’est pour ça que je préfère des langages comme C, Go, Odin et Zig
    Mais il est aussi important d’avoir des langages qui gèrent élégamment la complexité nécessaire
    Pour du code réseau qui demande sûreté mémoire, concurrence et motifs fonctionnels, Rust est naturel
    À l’inverse, pour du code simple et rapide comme dans un jeu indé, C ou Odin conviennent très bien
    Odin donne l’impression de combiner la simplicité de Go et les performances de C, donc je le recommande
    Il est aussi facile de faire des jeux avec Raylib

    • Fait intéressant, j’ai tendance à décrire Zig comme un point intermédiaire entre Go et C
      Je me demande si tu penses qu’Odin correspond mieux que Zig à cette position
    • Pour info, le nom du langage est Go ; golang n’est que le nom de domaine

  • Le texte d’origine disait que Go manquait de support en bibliothèques de jeu, mais ça ressemble à un article datant d’environ 2015
    La situation a peut-être changé depuis

    • Il y a un snapshot de janvier 2016 sur la Wayback Machine
      On peut aussi y voir des captures d’écran des jeux réalisés à l’époque
      Par exemple, Knossu a un style 3D assez unique

  • En 2026, faire des jeux en C est peut-être un peu dingue, mais c’est aussi ce que je fais
    Par exemple, j’ai développé Chrysalis en C (avec GLFW3 et FMOD)

    • Cela fait 2 ans que je travaille sur le codebase de Jedi Academy (C & C++)
      C’est basé sur idTech3, et le système de combat est tellement précis que le moindre petit changement casse tout l’équilibrage
      Même ajouter un simple i++ change le timing
      Du coup, on utilise toujours exactement le compilateur d’il y a 22 ans
      Il existe des forks modernisés, mais ils ont perdu le feeling d’origine
      idTech3 est vraiment un moteur qui montre toute la quintessence de C

  • Des milliers de jeux ont été écrits en C, et les API graphiques comme OpenGL, Vulkan ou DX reposent toutes sur C
    Donc il n’y a là rien d’étrange
    La plupart des moteurs de jeu sont eux aussi écrits en C/C++

    • Les API Khronos sont en C, DirectX repose sur COM/WinRT en C++, et Metal mélange Objective-C et C++
      Pour les consoles, cela varie selon les générations
    • SDL3 est aussi écrit en C, et la dernière version de Box2D a elle aussi été réécrite en C
    • DirectX est en C++, et la plupart des moteurs de jeu aussi
      Contrairement à la programmation Linux, le développement de jeux est centré sur C++ depuis plus de 30 ans

  • Au fond, je suis quelqu’un qui aime C
    Je l’utilise bien depuis des décennies, mais gérer du code C en équipe devient de plus en plus douloureux
    Et par rapport aux langages modernes, la vitesse de développement est plus faible
    Malgré tout, l’attrait de la simplicité reste intact

    • Je me demande pourquoi un codebase C ferait plus souffrir en travail d’équipe
      D’après mon expérience, C était moins pénible que C++
    • « Dire moins pour signifier davantage » — autrement dit, la concision est essentielle
    • Rien qu’en 2025, 2 134 développeurs ont contribué au noyau Linux
      Ce fait affaiblit l’idée de limites de C en matière de collaboration

  • Dire que « personne ne fait de jeux en C » est une exagération
    Ce n’est plus dominant aujourd’hui, mais beaucoup de gens continuent d’en faire en C

    • Des formulations comme « personne » ou « tout le monde » n’ont généralement pas un sens absolu
      Tu es juste une exception, et la phrase reste statistiquement vraie

  • J’aime C
    On peut garder un contrôle total sur la gestion mémoire et obtenir un comportement prévisible
    C’est particulièrement utile dans des environnements qui imposent de la préallocation, comme avec les règles MISRA
    C est aussi bien adapté pour traiter directement les exceptions ou erreurs au niveau matériel
    Écrire des tests unitaires y est aussi simple

  • C a une faible barrière à l’entrée, mais une bonne compréhension de la gestion mémoire est indispensable
    En tant que développeur Java, quand j’ai dû fabriquer rapidement un connecteur avec seulement des fichiers .h et .so, j’ai choisi C plutôt que C++
    Si C est un couteau bien aiguisé, C++ ressemble à une colonne de couteaux en rotation — au moindre relâchement, on se blesse
    En revanche, la gestion des chaînes en C est tellement pénible que j’aimerais emprunter celle de C++

    • Le bon côté de C++, c’est qu’on peut ne pas utiliser les fonctionnalités qu’on ne veut pas