Comparaison des moteurs de jeu RPG : RPG Maker, Godot, Unity, Unreal et constructeurs dans le navigateur

Choisir un moteur de jeu RPG revient surtout à décider de trois choses : comment vos graphismes sont produits, qui doit écrire du code, et où le jeu terminé doit tourner. Les options se scindent nettement. RPG Maker MV et MZ sont des éditeurs 2D qui livrent les systèmes RPG déjà intégrés. Godot, Unity, Unreal et Phaser sont des moteurs généralistes que vous programmez. Ren'Py est un moteur centré sur le dialogue qui traite un jeu comme un script. Les constructeurs dans le navigateur éliminent complètement l'installation et l'étape de compilation.

Cette page compare ces voies sur ce qui décide réellement un projet : le coût et la licence, la nécessité de toucher au code, la 2D ou la 3D, ce que vous pouvez exporter, et le temps avant d'obtenir quelque chose de jouable. Là où un chiffre relèverait de la conjecture, le mécanisme est décrit à la place. Si vous voulez voir un monde tourner avant de vous engager sur un moteur, la section sans moteur vers la fin est celle à lire en premier.

Réponse rapide

Si le jeu est un RPG 2D en vue de dessus avec des statistiques, des objets et des boîtes de dialogue, RPG Maker MV ou MZ atteint le plus vite une scène jouable, car la base de données et le système d'événements modélisent déjà ces systèmes. Si vous voulez maîtriser le moteur de rendu et les règles sans payer ni l'un ni l'autre, Godot est la voie la moins chère qui ne vous enferme pas dans un format. Unity et Unreal se justifient lorsqu'une équipe, une soumission sur console ou un intergiciel sont impliqués. Phaser est la réponse quand le RPG est une page web et que vous écrivez déjà du JavaScript. Ren'Py est la réponse quand le jeu est surtout du texte et des choix ramifiés.

Le tableau ci-dessous couvre sept voies : RPG Maker MV/MZ, Godot, Unity, Unreal, Phaser, Ren'Py et un constructeur dans le navigateur dont le résultat est une page plutôt qu'un fichier compilé. Les colonnes sont le coût et la licence, le code requis, la 2D ou la 3D, la plateforme cible et le temps jusqu'à la première version jouable. Lisez cette dernière colonne comme le temps nécessaire pour afficher un personnage contrôlable à l'écran avec des collisions et un objet interactif, et non comme le temps de terminer un jeu. La plupart des projets RPG échouent sur les systèmes, pas sur le rendu ; considérez donc le tableau comme un filtre et les sections suivantes comme la décision.

Le tableau comparatif

Deux cellules de ce tableau méritent une mise en garde. La cible Web d'Unity fonctionne, mais une compilation WebAssembly, même d'un modeste RPG 2D, atteint couramment plusieurs dizaines de mégaoctets avant compression des ressources, et les compilations avec threads nécessitent des en-têtes d'isolation cross-origin (COOP et COEP) que beaucoup d'hébergeurs statiques n'envoient pas par défaut. Le symptôme est un canevas vide et un message dans la console à propos de SharedArrayBuffer, et non une erreur claire. L'export web avec threads de Godot a la même exigence d'en-têtes, ce qui est la raison la plus fréquente pour laquelle un projet Godot tourne en local et échoue sur un hébergeur gratuit.

L'export HTML5 d'Unreal a été supprimé aux alentours des versions 4.23 à 4.24 et il n'existe pas de remplacement pris en charge ; un RPG réalisé dans Unreal est donc distribué sous forme de binaire ou via une boutique en ligne. Si le lien est le modèle de distribution, cela élimine Unreal de la présélection avant même que vous écriviez la moindre ligne de code.

Le déploiement dans le navigateur de RPG Maker charge l'arborescence complète des ressources d'emblée. C'est acceptable pour un petit projet et pénible pour un projet à longue bande-son, car l'audio domine la charge utile bien avant les cartes. Considérez le premier chargement, et non la fréquence d'images, comme votre premier problème de performance.

Moteurs de RPG 2D ou 3D

Le moteur de rendu est la partie facile. Godot et Unity rendent tous deux la 2D et la 3D dans le même téléchargement, et faire passer une caméra de la perspective à l'orthographique se résume à une seule propriété. Ce qui change entre un RPG 2D et un RPG 3D, c'est tout ce qui précède le moteur de rendu : la façon dont les ressources sont créées, le nombre de personnes nécessaires et le temps qu'un changement met à devenir visible.

Une voie 2D implique des planches de sprites et des tilesets. Un personnage qui marche dans quatre directions a généralement besoin de trois images par direction, soit douze images au total, dessinées en 16x16, 32x32 ou 48x48 pixels. Les réglages d'import comptent plus que le dessin lui-même : réglez Filter Mode sur Point (aucun filtre) et Compression sur None pour le pixel art, sinon le filtrage bilinéaire par défaut de l'éditeur floute chaque tuile et vous passez une soirée à blâmer l'artiste. L'itération est rapide, car une nouvelle tuile est dessinée puis déposée dans le dossier. Une carte de 100x100 à 32 pixels par tuile est une image de 3200x3200 pixels, ce qui représente un vrai coût en mémoire, mais un coût gérable.

Une voie 3D implique des maillages, des squelettes, des poids de peau et des clips d'animation. Un personnage a besoin d'un maillage, d'un squelette et, au minimum, de clips d'attente, de marche et d'attaque. Si vous ne prenez pas de licence sur une bibliothèque, cela représente du temps de modélisation avant même qu'un gameplay existe. L'itération est plus lente dans les deux sens : l'éclairage, les maillages à niveaux de détail et les formes de collision doivent tous être revérifiés quand un maillage change. Le gain, c'est une caméra capable de choses qu'une grille de tuiles ne permet pas, et une chaîne de production qui accepte des environnements scannés ou assemblés à partir de kits.

La vraie question n'est pas de savoir lequel est le plus beau. C'est le nombre de modifications de ressources que vous prévoyez après la première heure jouable. Un projet 2D absorbe des dizaines de changements à moindre coût. Un projet 3D en absorbe une douzaine, puis commence à vous coûter une semaine chacun.

RPG Maker vous cantonne à la 2D, et c'est un atout : l'éditeur de cartes, les autotiles et les ensembles de personnages présupposent tous une grille de tuiles, si bien qu'un tileset est le seul type de ressource que vous devez produire. Unreal vous oriente vers la 3D — Paper2D peut rendre des sprites, mais l'éclairage, la physique et l'outillage d'animation sont conçus autour des maillages, si bien qu'un jeu 2D y lutte contre le moteur.

Godot et Unity sont les deux qui vous laissent décider plus tard, mais à un coût. Faire passer un prototype des sprites aux maillages signifie reconstruire les collisions, réajuster la distance de caméra et reprendre chaque animation, car le nombre d'images d'une planche de sprites et la durée d'un clip d'un squelette n'ont rien en commun. Choisissez la dimension avant de construire le premier affrontement, pas après.

Faut-il coder ?

Non, jusqu'au moment où vous voulez quelque chose que l'outil ne modélise pas déjà. Le système d'événements de RPG Maker est une liste de commandes avec des conditions, des interrupteurs et des variables, et vous pouvez construire une chaîne de quêtes, une boutique et un combat au tour par tour sans taper une ligne de code. Le mur se dresse au niveau des mises en page de menus personnalisées et des formules de combat que la base de données ne peut pas exprimer ; à ce stade, vous modifiez des fichiers de plugins JavaScript et les enregistrez dans la liste des plugins, ce qui relève du travail d'auteur de plugins plutôt que du travail de débutant.

Les Blueprints d'Unreal sont ce qui se rapproche le plus d'un moteur généraliste doté d'une couche complète de programmation visuelle. Vous pouvez construire toute la logique d'un RPG sous forme de graphes de nœuds, et la différence de performance par rapport au C++ ne devient visible que dans le code exécuté image par image et acteur par acteur, comme les grandes boucles de foule ou de projectiles. La programmation visuelle d'Unity est un paquet plus des ressources tierces, et la plupart des tutoriels et des réponses de forum présupposent le C#. Godot n'a aucun graphe de nœuds de gameplay intégré ; GDScript est la voie à suivre, et sa syntaxe est délibérément proche de Python. Phaser, c'est du code dès la première ligne. Le format de script de Ren'Py se lit davantage comme un scénario que comme un programme, avec Python disponible pour les cas particuliers.

Il existe une quatrième option qui ne rentre pas dans l'opposition graphe de nœuds contre langage : décrire le jeu et laisser l'outil le construire. Le constructeur de jeu 3D de Neta Studio prend une description écrite et produit un monde Three.js qui tourne dans l'onglet. Vous apportez des modifications en les décrivant, plutôt qu'en ouvrant un fichier de scène et en cherchant le bon panneau d'inspection. C'est un piètre substitut à un graphe de nœuds lorsque vous avez besoin d'un contrôle au pixel près sur une formule de dégâts, et un très bon substitut aux deux semaines que la plupart des projets perdent en installation.

Ren'Py est le cas le plus clair. Un projet est un dossier de fichiers de script en texte brut ; vous pouvez l'écrire et le lancer depuis n'importe quel éditeur de texte accompagné du lanceur, et le seul rôle obligatoire du lanceur est de démarrer le jeu. Phaser est le deuxième cas : un projet est un dossier de JavaScript et un fichier HTML, et le navigateur fait office d'éditeur. Aucune des deux voies ne vous offre de peintre de cartes visuel, mais aucune ne vous demande d'installer un format de projet que vous ne pouvez pas lire dans un éditeur de texte.

RPG Maker ne remplit pas ces conditions, car la base de données, les cartes et les pages d'événements vivent dans le format de projet de l'éditeur. Un constructeur dans le navigateur va dans l'autre sens : la description est le projet, et l'éditeur est un champ de texte que vous avez déjà sous les yeux. Si votre raison d'éviter un éditeur est que vous ne voulez pas en apprendre un, cette distinction compte plus que la liste des fonctionnalités.

Export et publication

Ce que vous exportez détermine ce que votre joueur doit faire avant de pouvoir jouer. RPG Maker déploie des compilations Windows et macOS via NW.js, le déploiement sur navigateur et mobile dépendant de la version et d'outils communautaires. Un déploiement dans le navigateur, c'est un fichier HTML, un environnement d'exécution JavaScript et les dossiers d'images et d'audio du projet — hébergeable sur n'importe quel serveur statique, mais les ressources se téléchargent avant que l'écran-titre n'apparaisse.

Godot exporte via des préréglages stockés dans export_presets.cfg. Un export web produit une coquille HTML, un binaire .wasm et un fichier .pck contenant les données de votre projet. L'export web avec threads de Godot 4 a besoin de SharedArrayBuffer, ce qui exige que l'hébergeur envoie les en-têtes COOP et COEP. Sans eux, soit vous livrez la compilation mono-thread, soit la page ne démarre jamais. La compilation Web d'Unity passe par IL2CPP et produit du WebAssembly plus un ensemble de données, avec la même exigence d'en-têtes pour les threads et la même conséquence si on l'ignore.

Les deux problèmes web concrets d'Unity sont le chargement initial et la mémoire. Une scène qui charge tout au démarrage se fige à la première image ; les ressources adressables et le découpage des scènes sont la solution, pas une compilation plus légère. Unreal exporte des binaires natifs pour ordinateur et console et n'a aucune cible navigateur prise en charge. Phaser n'exporte rien, car les fichiers sont déjà des fichiers web — le déploiement consiste à copier un dossier. Ren'Py produit des distributions par plateforme à partir de ses réglages de compilation, y compris une compilation web, et empaquette les ressources avec l'environnement d'exécution.

Si vous publiez sur un hébergeur statique, testez les en-têtes avant de tester le jeu. Un serveur local qui définit COOP et COEP masquera un problème d'hébergement qui n'apparaît qu'en production.

L'option sans moteur

Il existe une voie où rien de tout ce qui précède ne s'applique, car il n'y a aucun moteur à installer, aucun dossier de projet et aucun préréglage d'export à configurer. Le constructeur de jeu 3D de Neta Studio prend une description écrite et produit un monde rendu avec Three.js dans l'onglet du navigateur. Le résultat est une page. Vous envoyez un lien à quelqu'un et le monde s'ouvre ; il ne télécharge pas d'archive, ne lance pas d'installateur et n'a pas à décider s'il fait confiance à un exécutable.

Cela change la forme du travail. Il n'y a aucune étape de compilation à relancer après une modification et aucun export spécifique à une plateforme à maintenir. Vous décrivez le terrain, l'angle de caméra, l'éclairage, les personnages qui existent et ce que le joueur peut faire ; le constructeur assemble le graphe de scène et Three.js le dessine. Agent Sprite Forge couvre le cas où un personnage ou un accessoire est nécessaire avant qu'un artiste n'existe, et Mini World et The Cyclops' Island sont des mondes jouables que vous pouvez ouvrir pour voir la caméra, le sol et les déplacements déjà fonctionnels.

Ce n'est pas un remplacement de Godot ou d'Unity pour un grand RPG. Les systèmes aux exigences numériques précises — une formule de dégâts, un format de sauvegarde que vous devez garder compatible entre les versions, une machine à états de combat avec une douzaine de statuts qui interagissent — réclament toujours une véritable couche de script. Ce que cela supprime, c'est la phase qui précède, où le monde n'existe pas encore et où vous ne pouvez pas dire si la caméra est lisible ou si l'échelle semble fausse.

Comment choisir en dix minutes

Parcourez-les dans l'ordre et arrêtez-vous à la première ligne qui tranche. La plupart des projets se décident dès les deux premières.

Entrez dans le monde auquel il appartient

Une comparaison de moteurs reste un tableau tant qu'une ligne ne tourne pas. La ligne du navigateur est celle que vous pouvez tester sans rien installer : ouvrez un monde décrit en une phrase et exporté sous forme de page. Voilà ce que donne réellement la dernière ligne du tableau.