Faragiri

Apprendre le développement de jeux vidéola programmation

Ce que l'horloge impose : 16,7 millisecondes par image, un déplacement multiplié par le temps écoulé, et des commandes liées à la position d'une touche.

6Sections
7Min de lecture
2Profondeur

Une image, cinq réclamations

Cinq étapes qui font une seule surface, parce qu'elles partagent un seul budget

Elles se touchent parce que ce ne sont pas cinq métiers séparés. Ce sont cinq réclamations sur les mêmes 16,7 millisecondes, et l'une qui déborde met les autres en retard.

16,7 millisecondes
  • Lire l'entréeCe qui est enfoncé maintenant, par la position de la touche et non par sa lettre
  • Avancer le mondeMultiplié par les secondes écoulées, sinon le jeu tourne à la vitesse du matériel
  • Résoudre la physiquePar tranches fixes, sinon un objet rapide traverse un mur où il n'a jamais été
  • Décider ce qui est visibleLa plus grande partie du monde est hors de l'écran et doit ne rien coûter
  • DessinerLa seule étape que le joueur voit, et rarement celle qui est en retard
  • Lire l'entréeCe qui est enfoncé maintenant, par la position de la touche et non par sa lettre
  • Avancer le mondeMultiplié par les secondes écoulées, sinon le jeu tourne à la vitesse du matériel
  • Résoudre la physiquePar tranches fixes, sinon un objet rapide traverse un mur où il n'a jamais été
  • Décider ce qui est visibleLa plus grande partie du monde est hors de l'écran et doit ne rien coûter
  • DessinerLa seule étape que le joueur voit, et rarement celle qui est en retard

Elle ne dit pas quelle étape prend le plus de temps, parce que cela change à chaque jeu. Elle dit que le total est fixe, ce qui ne change jamais.

Inès Chevalier a apporté son jeu à une jam à Montpellier. Sur son portable il tournait à 60 images par seconde et se jouait bien. Sur la machine de l'organisation, à 165 images par seconde, le personnage traversait l'écran en un tiers du temps et chaque saut dépassait la plateforme. Et la moitié des gens qui se sont assis devant n'ont pas pu avancer du tout, parce qu'ils tapaient sur un clavier AZERTY.

Rien n'était aléatoire et rien n'était cassé. Elle avait écrit le déplacement en pixels par image, et c'est la machine qui décide du nombre d'images. Elle avait écrit les commandes en lettres, et c'est le clavier qui décide des lettres. Les deux fautes ont la même forme : une hypothèse sur du matériel, glissée dans du code qui n'en parlait pas.

Un jeu n'est pas un programme qui tourne puis se termine. C'est un programme à qui l'on demande, soixante fois par seconde ou davantage, à quoi le monde ressemble maintenant, et toutes les rubriques rangées ici découlent d'être sur cette horloge.

La boucle, et le budget qu'elle vous laisse

La boucle, c'est entrée, mise à jour, dessin, et elle tourne qu'il se soit passé quelque chose ou non. Lire la manette, avancer le monde d'une tranche de temps, poser une image à l'écran, recommencer. Un traitement de texte attend une touche. Un jeu n'attend rien, et une image pendant laquelle le joueur n'a rien fait coûte quand même un tour complet.

Ce tour a un plafond dur. Le budget d'une image à 60 images par seconde est de 16,7 millisecondes pour tout : la physique, les ennemis qui décident, le son, le dessin. Le dépasser rend l'image en retard, ce que le joueur ne lit pas comme un nombre mais comme un jeu qui accroche. C'est cette discipline qui fait de la programmation de jeu un sujet différent de la programmation ordinaire, où une fonction de 30 millisecondes est rapide. Les prix comptés dans les bases de la programmation sont exactement les mêmes, mesurés avec une unité soixante fois plus petite.

Les deux lignes qui ont réparé le saut

La réparation est l'une des idées les plus transportables du métier. Le temps delta consiste à multiplier chaque déplacement par les secondes écoulées depuis l'image précédente. Au lieu de déplacer le personnage de 4 pixels par image, on le déplace de 240 pixels par seconde et on multiplie par la durée réelle de la dernière image. À 60 images cela fait 4 pixels, à 165 cela en fait environ 1,45, et le personnage traverse l'écran dans le même temps sur les deux machines.

  • x = x + vitesse * dt où vitesse vaut 240 et dt la durée de la dernière image
  • À 60 images, dt vaut 0,0167 et la ligne rend 4,0
  • À 165 images, dt vaut 0,0061 et la même ligne rend 1,45
  • Input.is_key_pressed(KEY_Z) lit une lettre, donc dépend de la disposition
  • Input.is_physical_key_pressed(KEY_W) lit une position, donc marche en AZERTY comme en QWERTY

Il y a une seconde moitié, que les débutants rencontrent plus tard et douloureusement. La physique ne survit pas à des tranches de temps inégales : une image anormalement longue laisse un objet rapide traverser un mur, parce qu'à aucun moment du calcul il n'a été à l'intérieur. La réponse est un pas de temps fixe pour la physique et variable pour le dessin, en faisant tourner la simulation par tranches constantes et en laissant le rendu dessiner entre elles. C'est plus de machinerie qu'il n'y paraît, et c'est pourquoi les moteurs le font à votre place.

Le clavier français n'est pas un détail de traduction

La seconde faute de la jam est propre au marché et elle ne figure sur aucune page anglaise. La disposition par défaut des commandes de déplacement, WASD, forme un carré sur un clavier QWERTY. Sur un AZERTY français ces quatre lettres sont dispersées, le A occupant la place du Q et le Z celle du W, et le carré n'existe plus. Le joueur français attend ZQSD, qui occupe les mêmes positions physiques que WASD.

La règle qui règle les deux cas d'un coup est de lier les commandes à la position physique de la touche et non au caractère qu'elle produit. Le moteur lit alors un code de balayage, la même touche répond en AZERTY, en QWERTY et en QWERTZ, et la carte des commandes n'a plus besoin d'être traduite. Une entrée liée aux lettres oblige à tenir une carte par pays, et personne ne la tient.

La même erreur revient dans les polices. Un atlas de caractères construit sur un jeu anglais ne contient ni É, ni Ç, ni œ, et la version française affiche des carrés vides ou laisse tomber l'accent au milieu d'un dialogue. Le texte français occupe en outre plus de place que sa source anglaise, donc une bulle dimensionnée sur l'anglais déborde. Les deux se corrigent en cinq minutes au début d'un projet et en trois semaines à la fin, ce qui est la raison de le dire ici plutôt qu'ailleurs.

Quatre pièces

Quatre pièces, et un jeu auquel il en manque une est une démonstration

Ce ne sont ni des étapes ni des services. En retirer une ne fait pas un jeu plus petit, elle fait un jeu inachevé.

  1. Les systèmesLes règles, la boucle, et le code qui a 16,7 millisecondes pour les faire tourner
  2. La raison de continuerCe que le joueur décide, et pourquoi la minute suivante vaut la peine
  3. Les ressources, au budget8 000 triangles plutôt que 80 000, décidé par l'arithmétique avant le goût
  4. Les dix derniers pour centMenus, sauvegarde, options, clavier AZERTY et build de boutique, soit la moitié du calendrier

Elle ne dit pas dans quel ordre les prendre, parce qu'elles avancent ensemble. Elle dit que la quatrième est celle que tout le monde sous-estime, et la seule des quatre dont la durée soit prévisible.

Ce à quoi sert un moteur, et le budget qu'il impose

Un moteur n'est pas un raccourci vers un jeu. C'est la réponse à tout ce qui, dans un jeu, n'est pas le jeu : la fenêtre, la manette, le mixage du son, la chaîne des ressources, la physique, l'export vers cinq plateformes. Les moteurs de jeu portent ce nom pour cette raison précise. Ce qu'un moteur ne fournit pas, c'est la raison pour laquelle quelqu'un joue, qui est tout le contenu du game design.

L'horloge atteint aussi les images. Chaque ressource a un coût payé à chaque image, et c'est le moteur qui fixe le budget, pas l'artiste. Un personnage à 80 000 triangles et un à 8 000 se ressemblent à la taille où le joueur les voit, et l'un des deux coûte dix fois plus des 16,7 millisecondes. C'est pour cela que les graphismes de jeu sont rangés sous un sujet de programmation : la contrainte est arithmétique et elle arrive avant toute décision de goût.

Où l'on cale, et l'argent qui existe en France

Le blocage est l'ampleur, et il est presque universel. Le premier jeu est une idée qui demanderait quatre ans à un studio, et il est abandonné au moment où la partie intéressante est finie et où le reste est fait de menus, de sauvegarde, d'options, de réglages de son et de quatorze choses qui ne sont pas amusantes à construire. Ceux qui livrent sont ceux dont le premier projet était assez petit pour que la partie ennuyeuse dure deux semaines et non deux ans. Elle a sa rubrique, la sortie d'un jeu, parce qu'elle est la moitié du calendrier.

La moitié française du sujet est financière. Le CNC administre deux dispositifs pour le jeu vidéo, le fonds d'aide au jeu vidéo, qui est une subvention sélective, et le crédit d'impôt jeu vidéo, qui porte sur 30 % des dépenses éligibles. Un studio français a donc, à la différence d'un studio américain, un guichet public à connaître, assorti de conditions de fabrication en France et d'un examen du contenu. Ce n'est pas une raison de commencer un jeu, c'est une raison de savoir compter : le premier projet reste petit, le second se monte autrement.

Le second blocage est de croire que le moteur choisi est réversible. Changer de moteur plus tard n'est pas un portage, c'est une réécriture de tout sauf l'art et l'idée, parce que le moteur décide de l'organisation du monde en mémoire, de ce qu'est une scène, et de l'endroit où passe la couture entre votre code et le sien.

Ce qu'on ouvre en 2026

Godot est l'option gratuite sans condition de recettes, son code est ouvert, et il a pris une large part du travail en deux dimensions depuis 2023, l'année où son principal concurrent commercial a annoncé puis retiré une redevance par installation. Unity reste l'option la plus large par le nombre d'offres et par les plateformes couvertes, et il est gratuit sous un seuil de recettes. Unreal est la réponse pour la trois dimensions haut de gamme et prend une redevance au-delà d'un seuil plutôt qu'un droit de licence.

Les trois ont remplacé le fait d'écrire un moteur, ce que voulait dire un projet de jeu avant 2010 environ et qui est aujourd'hui un choix délibéré plutôt qu'une obligation. Les trois s'installent depuis la France, gratuitement pour commencer, et les trois savent lire une touche par sa position. Le langage suit le moteur et non l'inverse, ce qui fait de ce sujet l'un des rares où le choix traité dans les langages de programmation est déjà fait pour vous. Pour un premier jeu, le bon choix est presque toujours celui qui mène le plus vite à quelque chose de jouable.

Reste ce qu'aucun de ces outils ne tranche, savoir si la chose est bonne. Cela ne se raisonne pas, cela se regarde, dans une salle, par-dessus l'épaule de quelqu'un, sans rien dire. La question suivante est plus prosaïque : sur quel appareil ce jeu sera joué, ce qui change la boucle, le budget et les commandes toutes les trois, et qui est le sujet du développement mobile.

À côté

Au-dessus