Le conseil « fais un jeu, pas un moteur » existe pour une bonne raison. On peut passer deux ans à perfectionner un renderer, un système d’assets et un éditeur de niveaux sans jamais fabriquer le jeu qui devait justifier tout ce travail.
Elias Farhan part pourtant dans la direction opposée pour Soup Raiders. Il porte son jeu vers un moteur maison. Mais son argument n’est pas qu’un développeur seul devrait fabriquer un meilleur Unity. Il écrit explicitement que le but est de construire un moteur spécifique à ce jeu.1
Cette nuance change presque tout.
Un moteur maison peut être beaucoup moins qu’Unreal
Farhan utilise une définition assez pratique. Un moteur exécute la boucle du jeu, récupère les événements du système, appelle le gameplay, gère le rendu et charge les assets.1 Construire un moteur personnalisé ne veut pas forcément dire écrire chaque couche depuis zéro. Assembler SDL3 avec des bibliothèques d’import ou de rendu compte déjà comme une pile spécifique si l’équipe contrôle la couche qui relie le jeu au système.1
À l’inverse, étendre Unity avec des outils internes ne transforme pas soudain Unity en moteur maison. La frontière utile se trouve moins dans le nombre de lignes écrites que dans qui possède les abstractions principales.
Cela permet d’éviter un faux duel. Un moteur généraliste doit servir des milliers de jeux très différents. Un moteur spécifique peut refuser des possibilités dont son jeu n’a pas besoin. Pour Soup Raiders, Farhan explique par exemple qu’il ne cherche pas à reproduire toutes les options de rendu d’un moteur généraliste. Une décision sur les ombres peut être prise en fonction de cette direction artistique et de cette caméra précises.1
Le vrai achat est du contrôle, pas forcément du temps
Le billet insiste sur l’apprentissage. Fabriquer le moteur force à comprendre des choix que Unity, Unreal ou Godot prennent normalement à votre place : organisation des assets, compilation, rendering, mémoire, boucle de jeu, portage.1 Samuel von Stachelski décrit une motivation proche dans son propre retour sur un moteur personnalisé : moins de couches imposées et une compréhension plus directe de ce qui s’exécute.2
Mais ce contrôle n’est pas gratuit. Farhan reprend plusieurs mises en garde : construire l’outil prend du temps, une mauvaise architecture reste votre mauvaise architecture, et les ressources communautaires disponibles pour un bug très spécifique sont forcément plus petites.1
Le portage illustre bien le compromis. Avec un moteur établi, le support de plusieurs plateformes peut sembler presque magique. Avec une pile maison, chaque console ou OS supplémentaire devient du travail que personne d’autre ne fera à votre place.1
L’indépendance technique signifie donc aussi responsabilité technique.
Le moteur devient pertinent quand il épouse une contrainte réelle
Farhan finit par une règle plus utile que « moteur maison oui/non » : l’outil doit être spécialisé pour le jeu, sa direction artistique ou les contraintes de sa plateforme.1
Cela rapproche le moteur d’un outil d’atelier. Fabriquer son propre tournevis serait absurde si tous les tournevis existants conviennent. Cela devient moins absurde si la vis est inaccessible autrement et si ce geste revient assez souvent pour justifier l’outil.
Le reste de la série doit documenter le port natif de Soup Raiders et ses objectifs de performance sur Nintendo Switch.1 Ce sont encore des objectifs de développement, pas une preuve publiée que le port les atteint déjà.
C’est précisément là que le projet devient intéressant à suivre. Le moteur n’est pas présenté comme une œuvre autonome à admirer. Il doit réussir une tâche beaucoup moins glamour : faire tourner un vrai jeu, avec ses vrais choix graphiques et ses vraies contraintes, sans devenir lui-même le projet qui avale le jeu.