Un jeu vidéo fonctionne rarement sur un seul morceau de technologie

Lorsqu’un personnage traverse une pièce, plusieurs systèmes travaillent en même temps. Le moteur doit afficher le décor, déterminer si le personnage touche le sol, jouer son animation de marche, positionner ses pas dans l’espace sonore, vérifier les collisions avec les objets, exécuter la logique du gameplay et mettre à jour les personnages contrôlés par l’intelligence artificielle. Tout cela doit rester suffisamment synchronisé pour que le joueur perçoive une seule expérience continue.

C’est précisément le rôle d’un moteur de jeu, ou game engine. Il fournit une infrastructure commune à des problèmes que presque tous les jeux finissent par rencontrer, afin que chaque équipe n’ait pas à reconstruire depuis zéro un système de rendu, un moteur physique, un gestionnaire audio, une architecture d’animation ou des outils d’édition.

Un moteur de jeu est moins une machine qui “fabrique un jeu” qu’un ensemble de systèmes et d’outils qui permettent à une équipe de le fabriquer.

Cette distinction est importante. Unreal Engine, Unity, Godot, Frostbite ou RE ENGINE peuvent fournir une quantité considérable de technologies, mais aucun d’eux ne décide des règles du jeu, de la qualité d’un niveau, du rythme d’un combat ou de l’identité visuelle d’un projet. Le moteur rend ces décisions exécutables.

Ce qu’un moteur prend réellement en charge

Le mot moteur peut donner l’impression qu’il désigne principalement la partie graphique. Historiquement, le rendu a effectivement occupé une place centrale, mais un moteur moderne rassemble beaucoup plus de responsabilités.

Les documentations actuelles d’Unreal Engine, Unity et Godot couvrent toutes des systèmes de rendu, de physique, d’animation, d’audio, de scripting, d’interface, de navigation et d’outillage. Unreal organise par exemple sa documentation autour de la construction de mondes, du rendu, des effets visuels, du gameplay, des Blueprints, de l’animation, de l’audio, des interfaces et du pipeline de production.

Système	Rôle principal	Exemple concret
Rendu	transformer la scène en image	afficher un personnage, des matériaux, des ombres et des effets
Physique	simuler collisions et mouvements	faire tomber une caisse, gérer un véhicule ou détecter un contact
Audio	jouer et spatialiser les sons	placer des pas derrière le joueur ou mixer une ambiance
Animation	contrôler les mouvements	passer de la marche à la course puis à une attaque
Scripting / gameplay	définir les comportements	ouvrir une porte, déclencher une quête, gérer une arme
IA et navigation	organiser certains comportements autonomes	permettre à un ennemi de trouver un chemin ou de réagir
UI	construire les interfaces	HUD, inventaire, menus, dialogues
Outils d’édition	créer et modifier le contenu	placer des objets, régler une lumière, construire un niveau
Pipeline de ressources	importer et préparer les fichiers	transformer modèles, textures et sons en données utilisables
Build et plateformes	produire le programme final	générer une version PC, mobile ou console

La liste varie selon les moteurs. Certains intègrent directement de nombreuses fonctions tandis que d’autres reposent davantage sur des extensions, des bibliothèques ou des outils externes. La frontière entre « moteur », « éditeur » et « écosystème » est donc devenue beaucoup moins nette qu’elle ne l’était autrefois.

Une architecture faite de couches

Godot permet d’observer assez clairement cette logique dans sa propre architecture. Sa documentation distingue notamment une couche de scènes utilisée pour structurer le jeu, des serveurs chargés de sous-systèmes comme le rendu, l’audio ou la physique, puis une couche plus basse qui dialogue avec les API graphiques, les systèmes audio et les plates-formes.

On peut simplifier l’ensemble ainsi :

Projet et scènes
       ↓
Gameplay / scripts / composants
       ↓
Rendu · Physique · Animation · Audio · Navigation
       ↓
GPU · CPU · système audio · système d’exploitation
       ↓
PC · console · mobile · web…

Le joueur ne voit évidemment jamais cette architecture. Il voit un personnage qui saute sur une plate-forme. Pour le moteur, ce saut implique pourtant plusieurs couches qui doivent échanger des informations au bon moment.

Avant les moteurs généralistes, chaque jeu fabriquait davantage sa propre technologie

Les premiers jeux n’étaient pas développés avec un grand éditeur universel offrant un bouton pour ajouter une lumière, une caméra ou un corps physique. Le code était souvent beaucoup plus directement lié au jeu et au matériel ciblé. Une équipe construisait les fonctions dont son projet avait besoin, parfois en réutilisant des morceaux de technologie issus d’un titre précédent.

Cette réutilisation finit naturellement par prendre de la valeur. Si plusieurs jeux utilisent les mêmes besoins de rendu, de collision, d’animation ou de gestion des ressources, il devient intéressant de séparer ces systèmes du contenu spécifique à chaque titre.

Un moteur apparaît réellement lorsqu’une partie suffisamment importante de cette technologie devient réutilisable. Le programme n’est plus seulement le jeu : il existe désormais une couche technique capable d’accueillir différents jeux.

Cette logique reste visible dans les studios actuels. Un moteur interne peut commencer autour des besoins d’un titre ou d’une franchise, puis devenir une base partagée entre plusieurs équipes. EA explique ainsi que la première génération de Frostbite a été développée en lien avec Battlefield: Bad Company avant de devenir une technologie commune à de nombreux studios du groupe.

Un moteur 2D et un moteur 3D ne résolvent pas exactement les mêmes problèmes

Parler de moteur « 2D » ou « 3D » ne revient pas simplement à distinguer un petit moteur d’un gros moteur. Les deux types de projets manipulent des représentations et des contraintes différentes.

En 2D, le moteur doit notamment gérer les sprites, les tiles, les couches, les caméras orthographiques, les collisions 2D, le scrolling, les animations de sprites et parfois des systèmes d’éclairage spécifiquement conçus pour un plan. Godot possède par exemple un renderer et un moteur physique 2D dédiés, ainsi que des outils pour les TileMaps, les particules et l’animation 2D.

En 3D, il faut ajouter la profondeur, les caméras en perspective, les maillages, les matériaux, les lumières, les squelettes, les systèmes de visibilité et une physique travaillant dans trois dimensions. Les besoins en performances et en gestion des ressources augmentent généralement avec la complexité des scènes.

Les moteurs généralistes modernes peuvent couvrir les deux domaines. Unity se présente explicitement comme une plate-forme de développement pour des expériences 2D et 3D, tandis que Godot regroupe également les deux approches dans une même interface.

2D et 3D ne forment donc pas une progression où l’une remplacerait l’autre. Elles correspondent à des manières différentes de représenter et d’organiser un espace de jeu.

Le moteur de rendu transforme les données en image

La partie graphique reste l’un des sous-systèmes les plus visibles du moteur. Elle reçoit une description de la scène — géométrie, textures, matériaux, lumières, caméra, effets — et doit produire l’image finale dans le temps très court disponible avant la frame suivante.

Comme nous l’avons vu avec l’évolution des graphismes, ce rendu peut aujourd’hui réunir plusieurs méthodes : rasterisation, calculs d’ombres, éclairage précalculé ou dynamique, post-traitement, reconstruction temporelle et éventuellement ray tracing. Un même moteur peut également proposer plusieurs chemins de rendu afin de s’adapter à des machines très différentes.

Godot 4 illustre cette logique avec plusieurs renderers destinés à des usages différents, tandis qu’Unreal Engine regroupe dans son système graphique l’éclairage, les ombres, les matériaux, les textures, les effets visuels et le post-traitement.

Le moteur de rendu ne définit cependant pas l’apparence du jeu à lui seul. Il fournit un ensemble de possibilités et de contraintes que la direction artistique va utiliser. Deux jeux construits dans le même moteur peuvent ainsi ne presque rien partager visuellement.

La physique ne cherche pas toujours à reproduire parfaitement le réel

Un moteur physique répond à des problèmes comme les collisions, la gravité, les forces, les articulations ou les corps rigides. Il permet par exemple de déterminer si un personnage entre en contact avec un mur, si une caisse tombe ou si deux véhicules se percutent.

Cela ne signifie pas pour autant qu’un jeu cherche systématiquement à reproduire la mécanique réelle. Une voiture d’arcade peut utiliser des comportements volontairement simplifiés, un personnage peut modifier sa trajectoire pendant un saut et une explosion peut projeter des objets de manière exagérée parce que le résultat est plus lisible ou plus amusant.

Unity expose par exemple un module physique dédié aux propriétés globales, collisions et corps simulés, tandis que Godot propose des systèmes physiques distincts pour les environnements 2D et 3D.

Le moteur fournit donc des règles de simulation. Le game design décide jusqu’où elles doivent ressembler au monde réel.

Animation et audio : deux systèmes profondément liés au gameplay

L’animation ne consiste pas seulement à lire un fichier produit dans Blender ou Maya. Dans un jeu, elle doit réagir en permanence à l’état du personnage : vitesse, direction, sol, arme utilisée, action en cours ou événement déclenché.

Unreal Engine utilise notamment les Animation Blueprints pour construire visuellement des comportements complexes, mélanger des animations et déterminer la pose finale d’un personnage à chaque frame.

L’audio répond à une logique comparable. Un son doit souvent être déclenché par le gameplay, positionné dans l’espace, atténué selon la distance et mélangé avec les autres éléments sonores. Unity permet par exemple à une source audio d’être traitée comme un son 2D ou complètement spatial en 3D selon sa configuration.

Ces systèmes montrent pourquoi un moteur fonctionne comme un ensemble intégré. Une animation peut déclencher un bruit de pas ; le matériau du sol peut déterminer quel son doit être joué ; la position du personnage influence sa spatialisation. L’intérêt du moteur vient précisément de la capacité de ces composants à communiquer.

Le scripting transforme les systèmes du moteur en règles de jeu

Un moteur peut savoir afficher un personnage et calculer sa collision sans savoir ce que ce personnage est censé faire.

La logique du jeu vient du code ou du scripting développé pour le projet. C’est elle qui décide qu’un coffre contient un objet, qu’une porte exige une clé, qu’un ennemi change d’état lorsque le joueur entre dans une zone ou qu’un niveau se termine lorsque certaines conditions sont réunies.

Les moteurs proposent différentes manières d’écrire cette logique. Unity s’appuie principalement sur C# et l’écosystème .NET. Godot propose notamment GDScript et C#, tandis qu’Unreal combine la programmation C++ avec son système de scripting visuel Blueprints.

Blueprints illustre bien l’évolution des moteurs vers des outils destinés à plusieurs métiers. Epic le décrit comme un système de scripting visuel basé sur des nœuds, capable de créer de la logique de gameplay sans écrire directement du code textuel. Les programmeurs peuvent construire les fondations techniques en C++, puis exposer certaines fonctions aux designers qui les assemblent visuellement.

L’objectif n’est pas de supprimer la programmation, mais de rendre certaines parties du système plus accessibles et plus rapides à modifier.

L’intelligence artificielle est elle aussi un ensemble de services

Lorsqu’un ennemi contourne un obstacle ou cherche le joueur, on parle facilement de « l’IA du moteur ». Cette expression regroupe en réalité plusieurs problèmes différents.

Il faut parfois représenter l’espace navigable, calculer un chemin, sélectionner un comportement, détecter des stimuli ou organiser différents états. Le moteur peut fournir une partie de ces briques, mais les règles qui donnent une personnalité particulière à un ennemi restent propres au jeu.

Un garde furtif, un pilote de course et un groupe d’unités dans un jeu de stratégie n’ont pas les mêmes besoins. Le moteur peut leur fournir des outils communs de navigation ou de décision, mais leur comportement final dépend du travail des programmeurs et des game designers.

Cette nuance sera particulièrement importante dans notre prochain article consacré à l’intelligence artificielle dans le jeu vidéo : disposer d’un système de navigation ou d’un arbre de comportements ne suffit pas à créer un adversaire intéressant.

L’éditeur compte presque autant que le moteur qui exécute le jeu

Une partie essentielle des moteurs modernes ne fonctionne pas chez le joueur. Elle existe uniquement pour les personnes qui fabriquent le jeu.

L’éditeur permet de placer les objets dans une scène, modifier leurs propriétés, déplacer des lumières, construire des niveaux, créer des animations, éditer des scripts ou tester directement le projet. Godot regroupe par exemple dans son environnement un éditeur de code, un éditeur d’animation, des outils de TileMap, un éditeur de shaders, un debugger et un profiler.

Unreal pousse également très loin cette logique avec des outils dédiés au world building, à l’animation, aux effets visuels, au son, aux interfaces et à l’automatisation du pipeline. Ses Blueprints peuvent même servir à construire des outils internes agissant directement sur les ressources et l’éditeur.

Cette partie est moins spectaculaire qu’une démonstration graphique, mais son influence sur la production peut être immense. Si placer cent objets prend cinq fois moins de temps grâce à un bon outil, ce gain se répète sur chaque niveau et pour chaque personne qui effectue cette tâche.

Le moteur possède donc deux visages

Chez les créateurs	Chez le joueur
éditeur de niveaux	monde final
outils d’animation	personnages animés
profiler	performances
système d’import	assets prêts à être utilisés
visual scripting	comportements du jeu
outils de build	programme installé
debugging	expérience normalement débarrassée de ses bugs

Une grande partie de la qualité d’un moteur se mesure ainsi à ce que le joueur ne verra jamais directement.

Unreal Engine : un moteur devenu environnement de production

Unreal Engine représente aujourd’hui l’un des exemples les plus complets du moteur généraliste transformé en environnement de production. Epic regroupe dans le même écosystème des outils de rendu, de création de mondes, d’effets visuels, d’animation, de gameplay, d’audio, d’interface, de programmation et de gestion du pipeline.

Son positionnement reste fortement lié aux productions 3D ambitieuses, même si son domaine d’utilisation dépasse largement le jeu vidéo. Les systèmes de scripting visuel Blueprints permettent en outre de répartir une partie de la logique entre programmeurs et profils plus orientés design.

L’intérêt d’Unreal ne réside donc pas seulement dans la qualité de son renderer. Il tient à l’intégration d’un très grand nombre de systèmes dans un environnement commun où un niveau peut être construit, éclairé, animé, scripté et testé.

Cela apporte énormément de possibilités, mais aussi une complexité importante. Un moteur riche demande du temps pour comprendre son architecture et apprendre à ne pas utiliser chaque fonction simplement parce qu’elle existe.

Unity : une logique généraliste et multiplateforme

Unity repose sur une autre histoire et une autre philosophie d’usage, mais poursuit le même objectif général : fournir une base réutilisable permettant de produire des expériences interactives pour de nombreuses plates-formes.

Unity présente aujourd’hui son moteur comme un environnement capable de créer des expériences 2D et 3D dans des styles très différents et sur une grande variété de machines. Il intègre notamment des outils de rendu, d’animation, d’audio, de scripting C#, de physique et d’analyse des performances.

Cette polyvalence explique une partie importante de sa diffusion. Le même environnement peut être utilisé pour un petit jeu 2D, un projet mobile, une production 3D ou une application interactive qui n’est même pas un jeu.

Son architecture s’appuie également beaucoup sur un système de composants. Un objet de scène reçoit différentes fonctions en fonction des composants qui lui sont attachés : renderer, collider, source audio, script ou autre comportement. Cette approche encourage la composition plutôt qu’une organisation où chaque objet devrait être programmé comme un cas entièrement particulier.

Unity montre ainsi qu’un moteur généraliste ne correspond pas nécessairement à un type de jeu précis. Sa valeur vient surtout de la capacité à fournir une base assez flexible pour accueillir des projets très différents.

Godot : un moteur ouvert où la 2D et la 3D coexistent

Godot propose une troisième approche intéressante parce qu’il est libre et open source, développé sous licence MIT et porté par une communauté ainsi que par la Godot Foundation. Sa documentation le présente comme un moteur multiplateforme destiné à créer des jeux 2D et 3D depuis une interface unifiée.

Le moteur repose fortement sur les notions de nodes et de scenes. Un personnage, une caméra, un élément d’interface ou un système audio peuvent être organisés en nœuds, puis réunis dans des scènes réutilisables. Cette structure permet de composer progressivement des objets complexes à partir d’éléments plus petits.

Godot possède également une particularité importante : sa prise en charge de la 2D ne se limite pas à placer des sprites dans un environnement pensé d’abord pour la 3D. Il dispose de systèmes de rendu et de physique spécifiquement conçus pour les projets 2D.

Son caractère open source change aussi le rapport à l’outil. Une équipe peut consulter le code du moteur, le modifier ou développer des extensions plus profondément intégrées à son architecture. Cette liberté représente un avantage pour certains projets, mais elle ne supprime évidemment pas le coût humain nécessaire pour maintenir des modifications importantes.

Unreal, Unity et Godot répondent au même problème avec des philosophies différentes

Comparer les moteurs uniquement en demandant lequel est « le meilleur » conduit rarement très loin. La question réellement utile concerne le projet, l’équipe et les contraintes.

	Unreal Engine	Unity	Godot
Positionnement général	environnement 3D très complet et fortement intégré	moteur généraliste multiplateforme	moteur généraliste libre et open source
2D / 3D	principalement associé à la 3D, outils 2D disponibles	2D et 3D	systèmes dédiés 2D et 3D
Scripting courant	C++ + Blueprints	C#	GDScript + C#, extensions natives possibles
Éditeur	très vaste ensemble d’outils intégrés	éditeur extensible basé sur composants et packages	interface unifiée autour des scènes et nœuds
Accès au code moteur	code source disponible selon le cadre d’utilisation	moteur propriétaire avec possibilités d’extension	code source ouvert sous licence MIT
Type de projet	productions diverses, forte présence dans la 3D haut de gamme	très grande variété de projets et de plates-formes	projets 2D/3D, indépendants et équipes recherchant un moteur ouvert

Ce tableau ne constitue pas un classement. Les trois environnements évoluent régulièrement, leurs fonctionnalités se chevauchent et des projets très différents peuvent être réalisés avec chacun d’eux.

Le moteur le plus approprié est celui qui correspond au mieux au pipeline réel de l’équipe, et pas celui qui possède la plus longue page de fonctionnalités.

Pourquoi certains studios continuent-ils à fabriquer leurs propres moteurs ?

Avec des outils aussi complets disponibles publiquement, maintenir un moteur interne peut sembler inutilement coûteux. Pourtant, certains grands studios choisissent toujours cette voie parce qu’un moteur peut être conçu autour de leurs méthodes de travail, de leurs franchises et de leurs contraintes techniques.

EA présente Frostbite comme une plate-forme technologique partagée entre plusieurs de ses studios. Son ensemble de workflows couvre notamment l’audio, l’animation, les cinématiques, le scripting, la physique, la destruction, le rendu et les effets visuels.

Capcom suit une logique similaire avec RE ENGINE. Dans son rapport intégré 2025, l’entreprise décrit un moteur interne multiplateforme utilisé pour ses titres et adapté à son propre processus de production, depuis le rendu jusqu’à l’édition, aux tests et au contrôle qualité. Capcom souligne aussi la possibilité de partager des ressources entre plusieurs productions.

Cette approche permet d’adapter profondément la technologie aux besoins du studio. Une fonction peut être conçue exactement pour un pipeline interne, les outils peuvent correspondre aux habitudes des équipes et les améliorations apportées pour un jeu peuvent bénéficier aux suivants.

Le prix à payer est considérable : développer un moteur signifie aussi maintenir son renderer, ses outils, ses systèmes de build, sa compatibilité avec les plates-formes et une quantité importante de technologie qui serait autrement prise en charge par un fournisseur externe.

Construire son propre moteur ne supprime pas une dépendance technologique : cela signifie décider de la prendre entièrement en charge soi-même.

Un moteur interne peut devenir un investissement à long terme

RE ENGINE offre un bon exemple de cette logique. Capcom explique que son moteur a été développé pour répondre à la complexité croissante de ses productions et aux besoins spécifiques de ses créateurs. L’entreprise indique aujourd’hui l’utiliser pour des jeux aux directions visuelles très différentes et continuer à faire évoluer cette base technologique.

Le moteur devient alors une forme de mémoire technique du studio. Les outils, optimisations et connaissances accumulés lors d’un projet peuvent être réutilisés dans le suivant. Les équipes ne recommencent pas exactement au même point à chaque production.

Cette continuité peut devenir un avantage important lorsque plusieurs projets partagent des besoins similaires. Elle peut aussi devenir une contrainte si le moteur vieillit mal ou si de nouveaux types de jeux exigent des fonctions très éloignées de celles pour lesquelles il avait été conçu.

Un moteur interne doit donc évoluer presque comme un produit à part entière, avec sa propre équipe, sa roadmap, ses tests et ses utilisateurs — les développeurs du studio.

Choisir un moteur revient à choisir une partie de son pipeline

Le moteur intervient très tôt dans la fabrication d’un jeu, mais ses conséquences se prolongent jusqu’à la sortie. Il influence les formats de fichiers, les langages utilisés, la structure des scènes, les outils de level design, les systèmes d’animation, les méthodes de profiling et la manière de produire les builds.

Le choix dépend donc de critères beaucoup plus larges que la qualité graphique.

Parmi les questions réellement utiles

L’équipe connaît-elle déjà le moteur et ses langages ?
Les plates-formes ciblées sont-elles correctement prises en charge ?
Les outils correspondent-ils au type de jeu produit ?
Le projet a-t-il besoin d’un pipeline 2D spécifique, d’une 3D très avancée ou des deux ?
Les performances attendues sont-elles compatibles avec l’architecture choisie ?
L’équipe doit-elle modifier profondément le moteur ?
L’écosystème de plugins et de ressources apporte-t-il une vraie valeur ?
Quel sera le coût de maintenance du projet sur plusieurs années ?

Un prototype réalisé en quelques jours peut tolérer certaines limitations. Un jeu destiné à être maintenu pendant dix ans n’a pas les mêmes besoins.

Le bon choix technique dépend toujours du contexte.

Le moteur ne remplace ni le game design ni les compétences de l’équipe

Les démonstrations techniques peuvent parfois laisser croire qu’un moteur moderne suffit presque à fabriquer un jeu spectaculaire. Il peut effectivement produire rapidement une lumière avancée, simuler des milliers d’objets ou fournir un personnage animé, mais ces fonctions restent des matières premières.

Un moteur physique ne sait pas si un saut est agréable. Un renderer ne sait pas si une scène est lisible. Un système d’IA ne sait pas si un adversaire est intéressant à combattre. Un éditeur de niveau ne sait pas où placer une porte pour créer une bonne progression.

Les outils réduisent certains coûts techniques et permettent aux équipes de consacrer davantage de temps à d’autres problèmes. Ils ne suppriment pas ces problèmes.

C’est d’ailleurs l’une des raisons pour lesquelles deux jeux construits avec la même technologie peuvent obtenir des résultats radicalement différents. Le moteur fournit une infrastructure commune ; ce sont les choix de production, d’art, de programmation et de design qui construisent finalement l’expérience.

Le moteur moderne devient progressivement une plate-forme de création

Les moteurs actuels dépassent largement le simple programme chargé d’afficher un jeu. Ils intègrent des éditeurs, des outils de profiling, des systèmes de scripting visuel, des pipelines d’import, des outils de terrain, de cinématique, de VFX, d’audio, d’animation et parfois des services destinés au multijoueur ou à la production.

Cette évolution rapproche le moteur d’un environnement de travail partagé entre plusieurs métiers. Le programmeur y développe des systèmes, l’artiste technique construit des shaders et des outils, le level designer organise le monde, l’animateur règle ses comportements et le sound designer vérifie ses événements.

Le moteur devient alors l’endroit où les différentes disciplines décrites dans notre article sur le pipeline de production finissent par se rencontrer.

C’est probablement la meilleure manière de comprendre sa place : il n’est ni le jeu lui-même, ni seulement la technologie cachée sous ses graphismes. Il constitue le terrain commun sur lequel le projet est assemblé.

Du moteur graphique à l’infrastructure d’un monde interactif

Les premiers moteurs réutilisables répondaient à un besoin relativement évident : ne pas reconstruire la même technologie pour chaque jeu. Avec l’augmentation de la complexité des productions, cette logique s’est étendue jusqu’à englober une grande partie du processus de création.

Aujourd’hui, un moteur peut gérer l’image, les collisions, les sons, les animations et les scripts tout en fournissant les outils avec lesquels une équipe construit ses niveaux, importe ses ressources, analyse ses performances et prépare ses différentes versions.

Unreal Engine, Unity et Godot montrent trois manières de proposer cette infrastructure à des créateurs très différents. Frostbite ou RE ENGINE montrent l’autre voie, celle d’entreprises qui investissent dans leur propre technologie afin de l’adapter étroitement à leurs productions.

Derrière ces différences se trouve pourtant la même idée : séparer les problèmes techniques communs de ce qui rend chaque jeu particulier.

Un moteur sait comment afficher un monde, calculer une collision ou jouer un son. Il reste ensuite à l’équipe à décider quel monde mérite d’être construit, quelles règles doivent l’animer et ce que le joueur aura envie d’y faire.