Unity

Présentation

Unity est un moteur de jeu et une plateforme de développement en temps réel créée par Unity Technologies.

Il permet de construire des jeux 2D et 3D, des applications interactives, des expériences XR, des simulations ou des visualisations, puis de les déployer vers de nombreuses plateformes.

Sa force historique ne vient pas d’un rendu spectaculaire unique ni d’un outil réservé à un seul métier.

Elle vient d’un équilibre entre une architecture relativement directe, un langage largement répandu — C# — et un écosystème capable de s’adapter à des projets très différents.

Unity est particulièrement fort lorsqu’un même projet doit rester modulaire, programmable et portable entre plusieurs plateformes.

Une scène s’organise autour de GameObjects auxquels sont ajoutés des Components.

Un personnage peut ainsi réunir rendu, collision, physique, animation et scripts sans devenir un bloc monolithique.

Les Prefabs prolongent cette logique en transformant un objet configuré en modèle réutilisable dont les instances peuvent conserver certaines variations.

Cette architecture explique en grande partie l’accessibilité de Unity.

On peut commencer avec quelques objets et scripts.

Puis structurer progressivement les données, les scènes, les outils, les contenus distribués ou le multijoueur à mesure que le projet grandit.

Unity ne demande donc pas immédiatement de comprendre toute son architecture pour obtenir un premier résultat.

Cette progressivité reste l’une de ses grandes forces.

Elle possède aussi un revers.

Un projet peut très vite accumuler :

• scripts trop dépendants les uns des autres ;
• références cachées dans l’Inspector ;
• plugins ajoutés pour résoudre chaque problème ;
• packages dont personne ne maîtrise réellement le cycle de vie.

Unity facilite énormément l’assemblage.

Il ne remplace pas la conception logicielle.

Le moteur est également très modulaire.

De nombreuses capacités sont distribuées sous forme de packages : rendu, caméra, input, localisation, multijoueur, gestion de contenu, outils XR ou architectures orientées données.

Cette souplesse évite d’imposer chaque système à chaque projet.

Elle introduit aussi une vraie responsabilité :

choisir les bonnes briques et conserver leurs versions cohérentes avec celle du moteur.

Unity reste un produit propriétaire.

Le développement principal peut rester local, tandis que certains services de collaboration, build, multijoueur, analytics ou exploitation utilisent Unity Cloud et possèdent leurs propres conditions.

Cette séparation doit rester claire.

Utiliser Unity ne signifie pas utiliser tous les services Unity.

Et utiliser Unity localement ne signifie pas que chaque workflow associé au projet restera local.

Fonctionnalités

GameObjects, Components, Prefabs et données

Le modèle GameObject / Component constitue la base la plus reconnaissable de Unity.

Un objet reçoit des capacités en combinant plusieurs composants plutôt qu’en concentrant tout son comportement dans une seule classe.

Un personnage peut par exemple réunir :

• Transform ;
• Renderer ;
• Collider ;
• Rigidbody ;
• Animator ;
• scripts personnalisés.

Cette composition rend les comportements faciles à combiner.

Elle favorise aussi le prototypage.

Un nouvel objet interactif peut être construit à partir de briques déjà existantes au lieu de créer une architecture entièrement nouvelle.

Les Prefabs ajoutent un niveau de réutilisation essentiel.

Un ennemi, une porte, une interface ou un effet peuvent devenir des modèles dont les instances partagent une structure commune.

Les variantes et overrides permettent ensuite d’adapter certaines propriétés sans dupliquer tout l’objet.

Cette logique devient extrêmement productive pour les jeux composés de nombreuses familles d’objets.

Elle demande une bonne discipline lorsque les prefabs deviennent profondément imbriqués ou dépendants de nombreux scripts.

Les ScriptableObjects complètent cette architecture en stockant certaines données indépendamment des scènes et des instances.

Ils peuvent représenter des objets, statistiques, quêtes, dialogues, configurations ou autres données réutilisables.

Cette séparation aide à éviter que toute l’information du jeu soit enfermée dans des GameObjects actifs.

C#, outils et architecture du code

C# est le langage principal de Unity.

Les scripts pilotent gameplay, outils, données et interactions avec les composants du moteur.

Le langage constitue un avantage majeur parce qu’il reste relativement accessible tout en permettant de construire des architectures importantes.

Unity peut travailler avec différents éditeurs de code.

La vraie question ne se situe pas dans le choix de l’éditeur mais dans la manière dont le projet organise :

• responsabilités ;
• dépendances ;
• événements ;
• données ;
• tests ;
• modules.

Les Assembly Definitions peuvent notamment aider à séparer certaines parties du code et réduire les dépendances implicites.

Unity utilise également plusieurs mécanismes de compilation et d’exécution selon les plateformes.

IL2CPP transforme le code intermédiaire vers du C++ avant compilation native pour de nombreuses cibles.

Cette couche améliore la compatibilité avec certaines plateformes.

Elle peut également révéler des problèmes qui n’apparaissent pas de la même manière dans l’environnement de développement.

Une application doit donc être testée dans son véritable mode de build.

Unity possède enfin un système d’outils d’éditeur très extensible.

Inspecteurs personnalisés, fenêtres, gizmos et autres extensions peuvent transformer l’éditeur selon les besoins d’un projet.

Une équipe peut ainsi construire ses propres outils de placement, validation ou production.

Cette capacité devient particulièrement importante lorsque le même geste est répété des centaines de fois.

Rendu, matériaux et pipelines graphiques

Unity ne possède pas un seul pipeline graphique universel.

Le choix du pipeline fait partie des décisions structurantes du projet.

Le Built-in Render Pipeline représente l’architecture historique.

L’Universal Render Pipeline, ou URP, vise un large éventail de matériels et constitue souvent le choix le plus naturel pour les projets multiplateformes.

Le High Definition Render Pipeline, ou HDRP, cible davantage les machines haut de gamme et les besoins de rendu avancé.

Ces pipelines ne sont pas de simples profils de qualité.

Ils peuvent influencer :

• matériaux ;
• shaders ;
• lumières ;
• effets ;
• performances ;
• compatibilité de certains assets.

Changer de pipeline en cours de production peut donc coûter beaucoup plus qu’un changement de réglage.

Shader Graph permet de construire des shaders par nœuds.

Cette approche rapproche programmation graphique et art technique.

Elle facilite la création de matériaux spécifiques sans exiger que chaque effet soit entièrement écrit en HLSL.

Les graphes complexes restent néanmoins du code visuel.

Ils doivent être structurés, réutilisables et optimisés.

Visual Effect Graph pousse cette logique vers des effets principalement calculés sur le GPU.

Il devient particulièrement intéressant pour les grandes quantités de particules et effets complexes.

Le système de particules traditionnel reste souvent plus adapté aux projets modestes ou aux plateformes contraintes.

2D, 3D, animation, caméra et physique

Unity possède une vraie profondeur en 2D.

Sprites, Tilemaps, animation 2D, éclairage, physique et outils pixel art permettent de construire des productions entièrement dessinées sans utiliser un moteur séparé.

Cette spécialisation explique pourquoi Unity reste très présent dans l’indépendant, le mobile et les jeux 2D.

La 3D couvre scènes, meshes, terrains, matériaux, lumières, navigation, animation et physique.

Unity n’est cependant pas un modeleur généraliste.

Les personnages, décors et assets complexes sont généralement créés dans Blender, Maya ou d’autres outils spécialisés puis importés.

Des outils comme ProBuilder facilitent le blockout et les géométries temporaires directement dans l’éditeur.

L’animation repose sur clips, contrôleurs, Blend Trees, retargeting et autres systèmes destinés à organiser les mouvements.

Timeline ajoute une logique de séquençage.

Cinemachine organise les caméras virtuelles, suivis, compositions et transitions.

Ces outils dépassent la simple cinématique.

Ils sont également utiles pour le gameplay, les caméras dynamiques et la narration.

La physique 2D et la physique 3D reposent sur des piles distinctes.

Unity offre ainsi plusieurs niveaux de simulation sans transformer chaque projet en moteur physique spécialisé.

Interface, input, audio et expérience utilisateur

Une application temps réel ne se résume pas à ce qui se trouve dans la scène.

Unity possède plusieurs systèmes pour construire l’interface.

UI Toolkit représente une approche moderne pouvant servir aussi bien aux outils d’éditeur qu’à certaines interfaces runtime.

uGUI reste très présent dans les projets existants et dans de nombreux workflows de jeu.

La profondeur de ces systèmes devient surtout importante lorsque le produit doit fonctionner sur plusieurs tailles d’écran et périphériques.

L’Input System abstrait les actions du joueur des périphériques physiques.

Une même action peut correspondre à :

• clavier ;
• manette ;
• tactile ;
• contrôleur XR.

Cette abstraction facilite le multiplateforme.

Elle ne supprime pas la nécessité de concevoir une interaction réellement adaptée à chaque contexte.

Une interface pensée pour souris et clavier ne devient pas automatiquement confortable sur mobile ou dans un casque.

Unity intègre aussi audio, spatialisation et mixage.

Pour des productions très exigeantes, des solutions spécialisées comme FMOD ou Wwise peuvent compléter le moteur.

Contenu, Addressables et production à grande échelle

Plus un projet grandit, plus la question devient :

qu’est-ce qui doit être chargé, quand, depuis où et dans quelle version ?

Addressables aide à organiser les ressources afin qu’elles puissent être chargées de manière plus souple.

Certains contenus peuvent rester locaux.

D’autres peuvent être distribués séparément.

Cette architecture devient utile pour :

• jeux en service ;
• contenus téléchargeables ;
• grosses bibliothèques d’assets ;
• applications dont toutes les ressources ne doivent pas être chargées immédiatement.

Le principe est puissant.

Il ajoute aussi une nouvelle couche à comprendre : groupes, catalogues, versions, chargement asynchrone et distribution distante.

La gestion de contenu ne doit pas être ajoutée uniquement parce que le package existe.

Elle devient intéressante lorsque le volume ou le modèle de distribution le justifie réellement.

Multijoueur, services et cloud

Unity fournit plusieurs briques pour le multijoueur.

Netcode for GameObjects reste proche de l’architecture classique GameObject.

D’autres approches sont destinées aux architectures orientées données.

Des services comme Lobby, Relay ou Matchmaker peuvent aider à organiser les sessions et connexions.

Le moteur peut également produire des builds de serveurs dédiés.

Cette profondeur donne une base importante.

Elle ne rend pas le multijoueur simple.

Un projet réseau doit encore traiter :

• autorité ;
• latence ;
• prédiction ;
• sécurité ;
• triche ;
• hébergement ;
• observabilité.

Les Unity Gaming Services ajoutent d’autres briques facultatives : authentification, sauvegarde cloud, économie, analytics, configuration distante ou contenu distribué.

Ces services réduisent la quantité d’infrastructure à construire soi-même.

Ils augmentent la dépendance à l’écosystème Unity Cloud.

La décision doit donc porter autant sur le produit à long terme que sur la vitesse du prototype.

Performance, DOTS et déploiement multiplateforme

Unity peut cibler desktop, mobile, Web, consoles et XR selon les modules, licences et autorisations disponibles.

Le même projet peut partager une grande partie de sa logique entre plusieurs cibles.

Cela ne signifie pas qu’un build unique fonctionne partout sans adaptation.

Les différences concernent notamment :

• mémoire ;
• GPU ;
• shaders ;
• contrôles ;
• taille de téléchargement ;
• codecs ;
• services de plateforme ;
• certification.

Le Profiler, le Memory Profiler, le Frame Debugger et d’autres outils permettent d’analyser les performances.

Cette couche est essentielle parce qu’un projet temps réel doit respecter un budget permanent.

Ce qui compte n’est pas seulement la vitesse moyenne.

Il faut conserver une expérience stable sur la cible réelle.

Pour certaines simulations ou projets très massifs, Unity propose également une architecture orientée données avec Jobs, Burst et Entities.

Cette approche peut permettre de traiter efficacement de grandes quantités d’objets ou de données.

Elle représente un modèle mental différent du GameObject classique.

Adopter DOTS uniquement parce qu’il promet de meilleures performances peut ajouter énormément de complexité sans bénéfice réel.

L’architecture doit être choisie en fonction du problème mesuré.

Cas d’usage

Créer un jeu indépendant multiplateforme

Une même base peut cibler plusieurs systèmes tout en conservant gameplay, scènes et grande partie des assets.

Produire un jeu 2D

Sprites, Tilemaps, animation 2D, physique et rendu dédié permettent de construire une production entièrement 2D.

Prototyper rapidement une mécanique

GameObjects, Components et Prefabs permettent d’assembler une interaction avant d’investir dans une architecture plus lourde.

Développer un jeu mobile ou Web

URP, gestion des inputs et profiling permettent d’adapter le projet à des appareils et contraintes très différents.

Construire un jeu multijoueur

Les systèmes Netcode et services associés peuvent fournir une base pour sessions, connexion des joueurs et exploitation.

Réaliser une expérience XR

OpenXR, AR Foundation et les outils d’interaction permettent de cibler plusieurs environnements immersifs.

Construire une simulation ou une application interactive

Unity peut être utilisé hors du jeu vidéo lorsque temps réel, interaction et portabilité comptent davantage qu’un rendu linéaire.

Développer un jeu en service

Addressables, contenu distant, analytics et services backend peuvent accompagner un produit qui continue d’évoluer après sa sortie.

Conclusion

La modularité est sa vraie identité

Unity donne rapidement l’impression que presque tout est assemblable.

Components, Prefabs, packages et assets partagent cette même philosophie.

Cette souplesse fonctionne très bien lorsque l’équipe conserve une architecture lisible.

Elle devient beaucoup moins confortable lorsque chaque problème reçoit un package supplémentaire.

La modularité n’est utile que si le projet sait encore expliquer de quoi il dépend.

C# et la progressivité restent des avantages majeurs

Le langage rend Unity accessible à de nombreux développeurs sans imposer immédiatement les contraintes du C++.

Le moteur permet également de commencer avec une architecture relativement simple puis d’introduire davantage de structure lorsque le besoin apparaît.

Cette progression explique sa place durable dans l’apprentissage, le prototypage et les petites équipes.

Le multiplateforme est une force, pas une garantie

Unity réduit énormément le travail nécessaire pour maintenir plusieurs cibles.

La dernière partie du chemin reste spécifique à chacune d’elles.

Un projet sérieux doit tester tôt sur son appareil le plus contraignant plutôt que découvrir ses limites au moment de publier.

« Exporter vers » et « être correctement conçu pour » sont deux choses différentes.

Son écosystème accélère autant qu’il fragmente

L’Asset Store et les packages peuvent faire gagner des semaines.

Ils peuvent aussi produire un projet dépendant de plusieurs couches dont personne ne maîtrise vraiment l’évolution.

La sélection des dépendances fait donc partie de l’architecture.

Un plugin central doit être évalué presque comme une bibliothèque de code essentielle.

Unity convient particulièrement aux projets qui privilégient la portée

Face à Unreal Engine, Unity paraît souvent plus naturel lorsque le projet met l’accent sur C#, la 2D, le mobile, la variété des plateformes ou une architecture relativement légère.

Unreal offre une intégration artistique et technique plus massive autour de productions 3D ambitieuses.

Unity reste souvent plus facile à adapter lorsque le projet doit voyager entre de nombreux appareils et formats.

Cette différence compte davantage qu’une comparaison interminable de fonctionnalités.

Points d’attention

• Unity est propriétaire et son code complet n’est pas librement redistribuable.
• Le choix de version doit être stabilisé pour une production longue.
• Les packages peuvent introduire des incompatibilités lors des migrations.
• Le choix du pipeline de rendu doit intervenir tôt, car matériaux et shaders ne sont pas toujours interchangeables.
• Le multiplateforme exige des tests sur chaque cible importante.
• Les services Unity Cloud sont optionnels mais augmentent la dépendance à l’écosystème.
• Les assets et plugins possèdent leurs propres licences.
• Le coût réel peut inclure abonnement, services cloud, assets et outils tiers.
• Les projets multijoueurs ajoutent des contraintes de sécurité, hébergement et exploitation.
• Une architecture orientée Entities demande une approche différente du modèle GameObject classique.
• Les conditions de licence et seuils commerciaux doivent être vérifiés au moment du projet.
• Une scène fonctionnant correctement dans l’éditeur doit encore être profilée et testée dans un build réel.