Unity

Présentation

Unity est un moteur de jeu propriétaire et une plateforme de développement en temps réel conçue par Unity Technologies.

Le logiciel permet de créer des jeux vidéo, applications interactives, simulations, expériences en réalité virtuelle ou augmentée, visualisations, outils pédagogiques et contenus en temps réel.

Il réunit dans une même application un éditeur de scènes 2D et 3D, un environnement de programmation C#, des systèmes de rendu, des outils d’animation, de physique, d’audio, d’interface, de navigation, de profiling et de déploiement multiplateforme.

Unity ne constitue pas seulement un moteur d’affichage.

Son écosystème comprend également Unity Hub, le Package Manager, l’Asset Store, Unity Cloud, Unity Version Control, Build Automation, les Unity Gaming Services, des outils multijoueur, des services LiveOps et des fonctions d’intelligence artificielle facultatives.

La version stable principale disponible lors de la dernière vérification est Unity 6.3 LTS, publiée en décembre 2025.

Cette version bénéficie de deux années de support, jusqu’en décembre 2027. Les abonnés Unity Enterprise et Unity Industry disposent d’une troisième année de support.

Unity distingue désormais les versions LTS et les versions Update.

Une version LTS privilégie la stabilité, les corrections et la compatibilité sur une période longue. Elle convient aux jeux en service, aux productions avancées et aux équipes souhaitant verrouiller leur environnement.

Les versions Update sont également considérées comme prêtes pour la production, mais reçoivent plus rapidement les nouvelles fonctions et la prise en charge des plateformes récentes. Elles restent prises en charge jusqu’à la publication de la version Update suivante.

Les versions Beta et Alpha servent à tester les fonctions en développement. Elles ne doivent pas remplacer une version de production pour un projet qui ne dispose pas de sauvegardes solides.

Unity fonctionne comme éditeur sur Windows, macOS et Linux.

L’installation et la gestion des versions passent principalement par Unity Hub. Cette application permet d’installer plusieurs versions de l’éditeur, leurs modules de compilation et les modèles de projets.

Plusieurs versions de Unity peuvent coexister sur le même ordinateur.

Cette possibilité est importante, car un projet reste généralement associé à une version précise du moteur et à un ensemble défini de packages.

L’éditeur Unity repose sur une organisation en fenêtres et panneaux.

La Scene View sert à construire le monde, la Game View affiche le résultat depuis les caméras, le Hierarchy présente les objets de la scène, le Project Browser contient les fichiers et l’Inspector expose les propriétés de l’élément sélectionné.

Une scène Unity est composée principalement de GameObjects.

Un GameObject est un conteneur auquel sont ajoutés des Components. Un personnage peut ainsi réunir Transform, Renderer, Collider, Rigidbody, Animator et scripts personnalisés.

Cette architecture par composants facilite la réutilisation et la combinaison de comportements.

Le composant Transform définit la position, la rotation et l’échelle de chaque GameObject.

Les scripts C# héritent généralement de MonoBehaviour afin de recevoir des événements du moteur comme Awake, Start, Update, FixedUpdate, OnEnable ou OnCollisionEnter.

Les Prefabs permettent d’enregistrer un GameObject et sa hiérarchie sous la forme d’un modèle réutilisable.

Une modification apportée au prefab peut être propagée à toutes ses instances, tandis que des overrides permettent d’adapter certains paramètres localement.

Unity prend en charge les prefabs imbriqués et les Prefab Variants.

Les ScriptableObjects permettent de stocker des données dans des assets indépendants des scènes et des instances.

Ils sont couramment employés pour les statistiques de personnages, objets, configurations, dialogues, inventaires et systèmes de données.

La programmation s’effectue principalement avec C#.

Unity fournit son propre environnement d’exécution et prend en charge plusieurs modes de compilation, dont Mono pour certains workflows et IL2CPP pour de nombreuses plateformes.

IL2CPP convertit le code intermédiaire C# en C++ avant la compilation native.

Cette méthode améliore la compatibilité avec certaines plateformes et les contraintes d’exécution anticipée, mais augmente le temps de compilation et impose des précautions avec la réflexion, la génération dynamique de code et le stripping.

Unity peut être utilisé avec Visual Studio, Visual Studio Code, JetBrains Rider ou d’autres éditeurs compatibles.

Les fichiers de projet et solutions peuvent être générés automatiquement pour faciliter la navigation, l’autocomplétion et le débogage.

Le Package Manager organise une partie importante des fonctions du moteur.

Des systèmes comme Input System, Cinemachine, Timeline, Localization, Addressables, Entities, Netcode, Visual Scripting ou les pipelines de rendu sont distribués ou mis à jour sous forme de packages.

Cette modularité permet de ne pas charger tous les outils dans chaque projet.

Elle crée également une dépendance entre la version de l’éditeur, les versions des packages et leurs éventuelles fonctions expérimentales.

Unity propose trois grandes familles de pipelines de rendu.

Le Built-in Render Pipeline est le pipeline historique. Il reste compatible avec de nombreux anciens projets et assets, mais reçoit moins d’innovations que les pipelines plus récents.

L’Universal Render Pipeline, ou URP, est conçu pour couvrir un large éventail de matériels : mobile, Web, ordinateur, console et XR.

Il cherche à proposer un équilibre entre qualité visuelle, flexibilité et performances.

Le High Definition Render Pipeline, ou HDRP, vise les ordinateurs et consoles haut de gamme, les visualisations réalistes et les projets nécessitant des fonctions graphiques avancées.

URP et HDRP reposent sur le Scriptable Render Pipeline, qui permet à Unity et aux développeurs de construire des pipelines de rendu programmables.

Le choix du pipeline doit intervenir tôt dans le projet.

Les shaders, matériaux, lumières et effets ne sont pas toujours directement compatibles entre Built-in, URP et HDRP.

Shader Graph permet de créer des shaders à l’aide d’un graphe de nœuds sans écrire systématiquement du code HLSL.

Visual Effect Graph est destiné aux effets visuels complexes calculés principalement sur le GPU.

Le système de particules historique, souvent nommé Shuriken, reste disponible pour des effets plus légers ou largement compatibles.

Unity 6.3 LTS améliore notamment Shader Graph, VFX Graph, les matériaux de terrain, les templates de shaders, le rendu hybride 2D et 3D et plusieurs workflows graphiques.

Les éléments 3D peuvent désormais être plus facilement combinés avec les règles de tri, lumières et masques employés dans les scènes 2D.

Unity possède un ensemble complet de fonctions 2D.

Il comprend sprites, Sprite Renderer, Sprite Atlas, Tilemap, Tile Palette, 2D Animation, 2D IK, Pixel Perfect Camera, 2D Lights et outils de physique 2D.

Unity 6.3 introduit également une API de physique 2D de bas niveau fondée sur Box2D 3, avec des objectifs de multithreading, de déterminisme amélioré et de débogage visuel.

Les fonctions 3D couvrent meshes, matériaux, lumières, caméras, terrains, niveaux de détail, occlusion culling, navigation et intégration avec des logiciels comme Blender, Maya ou 3ds Max.

Unity n’est cependant pas un modeleur 3D complet.

Les assets sont généralement créés dans Blender, Maya, Cinema 4D, 3ds Max, ZBrush ou un outil CAD, puis importés dans le projet.

Le package ProBuilder fournit des outils de construction et de blockout directement dans l’éditeur.

Il convient à la création de prototypes, niveaux simples et géométries de référence, mais ne remplace pas une suite de modélisation spécialisée.

Le système d’animation repose sur Animation Clips, Animator Controllers, state machines, Blend Trees, Avatars et différents types de rig.

Mecanim permet notamment de réutiliser des animations humanoïdes entre des personnages compatibles.

Timeline organise des animations, caméras, sons, événements et autres pistes sur une séquence temporelle.

Cinemachine fournit des caméras virtuelles, suivis, compositions, transitions, rails et comportements adaptés aux jeux et cinématiques.

Le package Animation Rigging ajoute des contraintes destinées à l’animation procédurale, à l’IK et aux ajustements effectués après l’animation principale.

La physique 3D s’appuie principalement sur NVIDIA PhysX.

Elle comprend Rigidbodies, Colliders, Joints, Character Controller, raycasts, casts de volumes et détection des collisions.

La physique 2D utilise une pile distincte fondée sur Box2D.

Les objets et composants 2D ne doivent pas être mélangés sans précaution avec les systèmes physiques 3D.

Unity intègre plusieurs solutions d’interface.

UI Toolkit constitue le système moderne recommandé pour de nombreux nouveaux projets et pour les extensions de l’éditeur.

Il s’inspire des technologies Web avec une structure visuelle, des feuilles de style USS et un modèle d’interface conservée.

Unity UI, souvent appelé uGUI, reste très utilisé pour les interfaces de jeu construites avec Canvas, RectTransform, Images, Buttons et EventSystem.

IMGUI est principalement employé pour certains outils d’éditeur et interfaces historiques.

Le moteur audio comprend AudioSource, AudioListener, Audio Clips, Audio Mixer, effets, snapshots et spatialisation.

Des plugins externes comme FMOD ou Wwise peuvent être intégrés lorsque le projet nécessite un workflow audio plus spécialisé.

Unity possède plusieurs outils de diagnostic et d’optimisation.

Le Profiler analyse le processeur, le rendu, la mémoire, la physique, l’audio et d’autres domaines.

Unity 6.3 ajoute notamment un module Highlights destiné à résumer certaines données et à orienter l’analyse.

Le Frame Debugger décompose les appels de rendu d’une image.

Le Memory Profiler aide à comprendre l’occupation mémoire des objets, textures, meshes et allocations.

Le Profile Analyzer compare et agrège plusieurs captures.

Des outils externes comme RenderDoc, Xcode Instruments, Android Profiler, PIX ou les outils des constructeurs de consoles restent nécessaires pour certains diagnostics de bas niveau.

Unity prend en charge le développement multiplateforme.

Un même projet peut cibler Windows, macOS, Linux, Android, iOS, le Web, plusieurs casques XR, téléviseurs, systèmes embarqués et consoles sous réserve des licences et SDK nécessaires.

Unity annonce plus de vingt plateformes d’exécution prises en charge.

Le déploiement sur PlayStation, Xbox, Nintendo Switch et d’autres plateformes fermées nécessite l’approbation du constructeur, l’accès à son SDK et généralement Unity Pro ou une licence fournie par le partenaire de plateforme.

Unity 6.3 introduit Platform Toolkit.

Ce package fournit une API commune pour des fonctions comme les comptes, sauvegardes, contrôleurs, réalisations et services propres aux plateformes.

L’objectif est de réduire la quantité de code spécifique nécessaire pour Android, iOS, Steam, Windows GDK, PlayStation, Xbox et Nintendo Switch.

Unity propose également des outils XR.

Le système XR Plugin Management organise les intégrations de plateformes.

OpenXR fournit une base commune pour plusieurs casques et runtimes.

AR Foundation permet de développer des expériences de réalité augmentée reposant notamment sur ARCore et ARKit.

Les fonctionnalités disponibles dépendent toujours du matériel, du plugin, du système et de la version de la plateforme.

Le multijoueur est organisé autour de plusieurs packages et services.

Netcode for GameObjects cible les projets reposant sur les GameObjects et MonoBehaviours.

Netcode for Entities est destiné aux projets utilisant Entities et une architecture orientée données.

Unity Transport fournit une couche réseau de bas niveau compatible avec les solutions Netcode.

Le Multiplayer Services SDK rassemble plusieurs services de sessions, Lobby, Relay et Matchmaker au sein d’une API plus cohérente.

Relay permet de connecter des joueurs sans exposer directement leur adresse et sans maintenir obligatoirement un serveur dédié.

Lobby organise la création, la recherche et la gestion de groupes de joueurs.

Matchmaker cherche des partenaires ou serveurs selon des règles configurées.

Vivox fournit des fonctions de discussion vocale et textuelle.

Unity propose également des outils de Dedicated Server, des modes de test multijoueur dans l’éditeur et des exemples prêts à être étudiés.

Les Unity Gaming Services couvrent Authentication, Analytics, Cloud Code, Cloud Save, Economy, Leaderboards, Remote Config, Cloud Content Delivery, Push Notifications et In-App Purchasing.

Ces services sont optionnels et peuvent être combinés avec des backends externes.

Ils simplifient certaines opérations, mais créent une dépendance commerciale, technique et juridique envers Unity Cloud.

Unity Cloud comprend également des outils de collaboration et de production.

Unity Version Control, anciennement Plastic SCM, est conçu pour les projets contenant de grands fichiers binaires et pour la collaboration entre artistes et développeurs.

Build Automation compile automatiquement le projet dans le cloud ou, selon les offres, dans des infrastructures contrôlées par l’entreprise.

Asset Manager organise et partage des assets volumineux.

Cloud Diagnostics collecte des crashs, exceptions et données de diagnostic.

Addressables et AssetBundles facilitent le chargement différé et la distribution de contenus.

Cloud Content Delivery peut héberger les catalogues et bundles afin de mettre à jour du contenu sans publier immédiatement une nouvelle version complète de l’application.

L’Asset Store propose des modèles, animations, textures, sons, shaders, outils, templates, SDK et extensions.

Les assets peuvent être gratuits ou payants.

La majorité est créée par des éditeurs tiers et concédée sous l’EULA standard du Unity Asset Store.

Certains produits utilisent une licence non standard ou sont marqués Restricted Asset.

Une licence d’asset ne signifie pas que le fichier source peut être redistribué, vendu séparément ou partagé librement avec une autre organisation.

Unity propose un système d’intelligence artificielle intégré ou connecté à l’éditeur.

Les fonctions disponibles peuvent comprendre assistance au code, agents, recherche contextuelle, génération ou modification de contenu et connexions MCP.

Unity AI utilise une tarification, des crédits et des conditions distinctes. Il ne doit pas être confondu avec les fonctions fondamentales incluses gratuitement dans le moteur.

Unity est distribué selon plusieurs niveaux.

Unity Personal est gratuit et destiné aux jeux et applications de divertissement lorsque les revenus et financements applicables restent sous 200 000 dollars sur les douze derniers mois.

Unity Pro devient obligatoire lorsque ces finances dépassent 200 000 dollars, sauf règles particulières liées aux clients, partenaires ou plateformes.

Unity Enterprise devient obligatoire au-delà de 25 millions de dollars de revenus ou financements.

Unity Industry concerne les applications réalisées en dehors des jeux et du divertissement. Ce plan devient obligatoire lorsque les finances totales de l’entreprise dépassent un million de dollars.

Les utilisateurs travaillant pour un client doivent vérifier si les finances du client interviennent dans le calcul du niveau de licence.

Tous les utilisateurs d’une même organisation doivent employer un niveau de plan compatible. Le mélange de licences Personal, Pro et Enterprise est fortement encadré ou interdit.

Unity Pro est facturé par poste.

L’abonnement annuel prépayé coûte 2 310 dollars par utilisateur, tandis que la formule mensualisée coûte 210 dollars par mois avec engagement annuel.

Enterprise et Industry sont facturés sur devis.

Les services cloud, l’hébergement, les crédits d’intelligence artificielle, les assets, l’assistance et certains modules peuvent être facturés séparément.

Les frais Unity Runtime annoncés en 2023 ont été supprimés en 2024.

Les conditions actuelles permettent la distribution du Unity Runtime sans frais par installation, royalties ni partage des revenus pour les projets créés avec Unity 6 ou des versions antérieures, à condition de respecter les règles de licence et de niveau financier applicables.

Cette suppression n’empêche pas Unity de modifier les prix des abonnements, les seuils financiers ou les conditions pour de futurs usages.

Les projets, jeux et contenus créés restent la propriété de leurs auteurs.

Les droits sur les assets, plugins, polices, musiques, modèles et services tiers doivent cependant être vérifiés séparément.

Fonctionnalités

• Éditeur de scènes 2D et 3D : construction visuelle d’environnements et d’interactions.

• Scene View : navigation et manipulation des objets dans l’espace de création.

• Game View : aperçu du résultat depuis les caméras actives.

• Hierarchy : présentation hiérarchique des GameObjects présents dans une scène.

• Inspector : modification des composants et propriétés de l’élément sélectionné.

• Project Browser : navigation dans les fichiers et assets du projet.

• Console : affichage des logs, avertissements, erreurs et exceptions.

• Search : recherche d’assets, objets, scènes, commandes et données.

• Overlays : affichage d’outils contextuels dans la Scene View.

• Layouts personnalisables : organisation des panneaux selon le workflow.

• Plusieurs fenêtres : répartition de l’éditeur sur plusieurs écrans.

• Mode sombre et clair : choix de l’apparence générale de l’éditeur.

• Raccourcis configurables : modification des commandes clavier.

• Shortcut Manager : consultation et personnalisation des raccourcis.

• Commandes contextuelles : fonctions dépendant de l’objet, du composant et de la fenêtre active.

• Unity Hub : installation et gestion des versions de l’éditeur.

• Modules de plateforme : ajout des outils de compilation Android, iOS, Web ou desktop.

• Templates de projet : démarrage avec des configurations 2D, 3D, URP, HDRP ou spécialisées.

• Plusieurs versions simultanées : conservation de branches LTS et Update sur la même machine.

• Archives de versions : téléchargement d’anciennes versions compatibles avec un projet.

• Projets locaux : conservation des fichiers du projet sur le stockage de l’utilisateur.

• Unity ID : compte utilisé pour les licences, organisations, services et Asset Store.

• Organisations Unity : regroupement de projets, utilisateurs, abonnements et services.

• GameObjects : conteneurs principaux des objets d’une scène.

• Components : comportements et données attachés aux GameObjects.

• Transform : position, rotation, échelle et relation parent-enfant.

• Hiérarchie d’objets : création de structures parentales imbriquées.

• Activation des GameObjects : désactivation temporaire d’un objet et de ses composants.

• Tags : identification logique de catégories d’objets.

• Layers : filtrage du rendu, de la physique et des raycasts.

• Static Flags : indication des objets pouvant participer à certaines optimisations.

• Prefabs : création de modèles d’objets réutilisables.

• Prefab Instances : insertion d’exemplaires liés à leur prefab source.

• Nested Prefabs : inclusion de prefabs dans d’autres prefabs.

• Prefab Variants : création de variantes héritant d’un prefab principal.

• Prefab Overrides : modification locale d’une instance.

• Apply et Revert : propagation ou annulation des overrides.

• Prefab Mode : édition isolée d’un prefab.

• Scenes : organisation des niveaux, menus et environnements.

• Additive Scene Loading : chargement de plusieurs scènes simultanément.

• Scene Management : chargement, déchargement et changement de scènes par script.

• Multi-Scene Editing : édition de plusieurs scènes dans l’éditeur.

• Scene Templates : création de nouvelles scènes depuis une structure préparée.

• DontDestroyOnLoad : conservation de certains objets entre les changements de scène.

• ScriptableObjects : stockage de données sous forme d’assets.

• Serialization Unity : enregistrement des champs compatibles dans les scènes et assets.

• Custom Editors : création d’inspecteurs adaptés à un composant.

• Property Drawers : affichage personnalisé d’un type de données.

• Editor Windows : création de fenêtres supplémentaires.

• Gizmos : dessin de guides et repères dans la Scene View.

• Handles : manipulation visuelle de propriétés personnalisées.

• Editor Tools : ajout d’outils interactifs propres à un projet.

• C# : langage principal pour les scripts de gameplay et outils.

• MonoBehaviour : classe de base pour de nombreux composants programmés.

• Événements de cycle de vie : Awake, OnEnable, Start, Update, FixedUpdate et autres callbacks.

• Coroutines : exécution de routines réparties sur plusieurs frames.

• Events C# : communication entre systèmes à l’aide de delegates et événements.

• UnityEvent : événement sérialisable configurable depuis l’Inspector.

• Interfaces C# : définition de contrats entre composants.

• Generic Types : création de structures et systèmes réutilisables.

• Async et Await : programmation asynchrone dans les contextes compatibles.

• Assembly Definitions : séparation du code en assemblies.

• Assembly References : contrôle explicite des dépendances entre modules.

• Compilation conditionnelle : activation de code selon la plateforme ou la configuration.

• Scripting Define Symbols : définition de symboles propres au projet.

• Mono : backend d’exécution disponible pour certains environnements.

• IL2CPP : conversion du code intermédiaire en C++ et compilation native.

• Managed Stripping : suppression du code considéré comme inutilisé.

• Link XML : préservation de types nécessaires à la réflexion.

• Burst Compiler : compilation optimisée de code compatible.

• C# Job System : exécution de tâches parallèles.

• Native Collections : structures mémoire adaptées aux jobs et à Burst.

• Entities : implémentation moderne d’un Entity Component System.

• Entities Graphics : rendu d’entités et de nombreuses instances.

• Baking d’entités : conversion de données d’authoring en données ECS.

• Systems ECS : exécution de logique sur des groupes de composants.

• Queries ECS : sélection efficace d’entités selon leurs données.

• Netcode for Entities : réseau orienté ECS pour simulations multijoueurs.

• Visual Scripting : création de logique avec des graphes de nœuds.

• Script Graphs : représentation visuelle des opérations et événements.

• State Graphs : création de machines à états visuelles.

• Variables visuelles : données de graphe, scène, application ou objet.

• Custom Units : ajout de nœuds personnalisés.

• Package Manager : installation et mise à jour de packages.

• Package Manifest : définition des dépendances du projet.

• Packages embarqués : conservation d’une copie modifiable dans le projet.

• Packages locaux : chargement d’outils depuis le disque.

• Packages Git : installation depuis certaines URL Git compatibles.

• Scoped Registries : utilisation de registres de packages tiers.

• Samples de packages : import d’exemples et ressources pédagogiques.

• Version Locking : conservation de versions précises dans le fichier de verrouillage.

• Built-in Render Pipeline : pipeline historique du moteur.

• Universal Render Pipeline : pipeline adaptable à de nombreuses plateformes.

• High Definition Render Pipeline : pipeline destiné aux matériels haut de gamme.

• Scriptable Render Pipeline : fondation programmable pour les pipelines modernes.

• Custom Render Pipelines : possibilité de construire un pipeline spécifique.

• Render Pipeline Assets : définition des paramètres principaux d’URP ou HDRP.

• Quality Levels : réglages graphiques différents selon le matériel.

• Pipeline par niveau de qualité : utilisation de configurations distinctes selon la qualité.

• Forward Rendering : rendu direct adapté à différents types de scènes.

• Forward+ : gestion d’un plus grand nombre de lumières dans les configurations compatibles.

• Deferred Rendering : rendu différé adapté à certaines scènes contenant de nombreuses lumières.

• GPU Resident Drawer : réduction de certains coûts CPU liés à l’envoi des objets au GPU.

• SRP Batcher : regroupement d’appels de rendu compatibles.

• Dynamic Batching : regroupement de petites géométries dans certains cas.

• Static Batching : regroupement d’objets statiques.

• GPU Instancing : rendu efficace de nombreux objets similaires.

• Occlusion Culling : non-rendu des éléments cachés par d’autres objets.

• Frustum Culling : exclusion des objets hors du champ de la caméra.

• LOD Group : changement de modèle selon la distance.

• LOD Cross Fade : transition entre niveaux de détail.

• Mesh Renderer : rendu de meshes statiques.

• Skinned Mesh Renderer : rendu de personnages et meshes déformés.

• Sprite Renderer : affichage d’images 2D.

• Line Renderer : génération de lignes dans l’espace.

• Trail Renderer : création de traînées derrière un objet.

• Particle System Renderer : affichage des particules historiques.

• Sorting Layers : organisation de l’ordre d’affichage 2D.

• Sorting Groups : regroupement d’éléments pour le tri.

• Rendu 3D avec tri 2D : intégration d’objets 3D dans les règles d’affichage 2D.

• ShaderLab : définition des shaders Unity.

• HLSL : programmation de shaders personnalisés.

• Shader Graph : construction visuelle de shaders.

• Sub Graphs : regroupement de blocs réutilisables dans Shader Graph.

• Custom Function Nodes : insertion de code personnalisé dans un graphe.

• Lit Shaders : matériaux réagissant à l’éclairage.

• Unlit Shaders : matériaux indépendants de l’éclairage.

• Decals : projection de détails sur les surfaces.

• Terrain Shaders : création visuelle de matériaux pour terrains.

• Post-Processing Shaders : effets appliqués après le rendu principal.

• Shader Variants : versions compilées selon les fonctionnalités activées.

• Shader Variant Stripping : réduction des variantes inutiles lors de la compilation.

• Materials : liaison entre shaders, textures et paramètres.

• Material Property Blocks : modification de propriétés sans dupliquer systématiquement les matériaux.

• Render Textures : rendu d’une caméra ou d’un effet dans une texture.

• Custom Passes HDRP : insertion d’étapes personnalisées dans le rendu.

• Renderer Features URP : extension du pipeline URP.

• Render Graph : organisation et optimisation des passes de rendu compatibles.

• Ray Tracing HDRP : effets utilisant le ray tracing sur du matériel compatible.

• Path Tracing HDRP : génération d’images par path tracing dans les configurations compatibles.

• Indirect Ray Tracing : ajout GPU-driven de nombreuses instances dans Unity 6.3.

• Screen Space Reflections : réflexions calculées à partir de l’image visible.

• Screen Space Ambient Occlusion : occlusion calculée dans l’espace écran.

• Volumetric Fog : brouillard et volumes dans HDRP.

• Cloud Layers et Volumetric Clouds : création de ciels et nuages dans HDRP.

• Sky Systems : ciels procéduraux, HDRI et environnements lumineux.

• Physical Sky : simulation de ciel physiquement inspirée dans HDRP.

• Lighting en temps réel : calcul dynamique des lumières.

• Baked Lighting : pré-calcul de l’éclairage dans des lightmaps.

• Mixed Lighting : combinaison de lumières calculées et dynamiques.

• Lightmapper : génération de lightmaps.

• Progressive Lightmapper : calcul progressif de l’éclairage.

• xAtlas Lightmap Packing : rangement optimisé des lightmaps dans Unity 6.3.

• Light Probes : échantillonnage de l’éclairage pour les objets dynamiques.

• Reflection Probes : capture de l’environnement pour les réflexions.

• Adaptive Probe Volumes : représentation volumétrique de l’éclairage indirect.

• Light Cookies : textures projetées par les lumières.

• Light Layers : contrôle des objets affectés par certaines lumières.

• Shadows : ombres dynamiques et calculées.

• Shadow Cascades : amélioration des ombres directionnelles à différentes distances.

• Contact Shadows : ombres de proximité dans les configurations compatibles.

• Post-processing : effets appliqués après le rendu.

• Bloom : diffusion lumineuse autour des zones brillantes.

• Tonemapping : conversion des fortes plages dynamiques vers l’affichage.

• Color Grading : correction et stylisation des couleurs.

• Vignette : assombrissement ou coloration des bords.

• Film Grain : ajout de grain visuel.

• Chromatic Aberration : décalage coloré inspiré des objectifs.

• Depth of Field : flou selon la distance de mise au point.

• Motion Blur : flou associé au mouvement.

• Lens Distortion : déformation optique simulée.

• Optimisations mobiles du Bloom : filtres Kawase et Dual dans Unity 6.3.

• Post-processing on-tile : effets optimisés pour les GPU mobiles et XR compatibles.

• Visual Effect Graph : création d’effets visuels calculés sur le GPU.

• GPU Events : déclenchement de systèmes VFX depuis d’autres effets.

• VFX Instancing : utilisation d’instances pour certains effets.

• VFX Templates : exemples et bases de systèmes visuels.

• Particle System : système historique de particules.

• Emission Modules : contrôle de la création des particules.

• Shape Modules : définition de leur zone d’émission.

• Collision Modules : interaction des particules avec la scène.

• Sub Emitters : déclenchement de systèmes secondaires.

• Particle Trails : création de traînées.

• Particle Lights : association de lumières aux particules dans les cas compatibles.

• Sprites : images utilisées dans les scènes 2D.

• Sprite Editor : découpe et préparation des sprites.

• Multiple Sprite Mode : extraction de plusieurs sprites depuis une image.

• Sprite Atlas : regroupement de sprites dans des textures optimisées.

• Sprite Atlas Analyser : analyse de l’utilisation des atlas dans Unity 6.3.

• PSD Importer : import de documents Photoshop avec leurs calques compatibles.

• 2D Animation : rigging et déformation de sprites.

• Sprite Skin : déformation d’un sprite par un squelette.

• 2D IK : cinématique inverse pour rigs 2D.

• 2D Pixel Perfect : maintien d’un affichage cohérent pour le pixel art.

• Tilemap : construction de niveaux avec des tuiles.

• Tile Palette : sélection et peinture de tuiles.

• Rule Tile : adaptation automatique d’une tuile selon ses voisines via les outils compatibles.

• Animated Tiles : animation de tuiles.

• Isometric Tilemaps : construction de scènes isométriques.

• Hexagonal Tilemaps : utilisation de grilles hexagonales.

• Sprite Masks : masquage de sprites.

• 2D Lights : éclairage de sprites avec le renderer 2D d’URP.

• 2D Shadows : création d’ombres dans les scènes 2D compatibles.

• Normal Maps 2D : réaction des sprites à l’éclairage.

• Sorting 2D et 3D combiné : intégration d’objets volumétriques dans une scène 2D.

• Physics 2D : simulation fondée sur Box2D.

• Box2D 3 Low-Level API : API multithread et débogable dans Unity 6.3.

• Rigidbody2D : mouvement physique d’un objet 2D.

• Collider2D : formes de collision 2D.

• CompositeCollider2D : fusion de plusieurs colliders.

• Joints 2D : liaisons physiques entre objets.

• Physics Material 2D : contrôle de la friction et du rebond.

• Raycast 2D : interrogation des colliders dans l’espace 2D.

• Effector 2D : zones appliquant des comportements physiques.

• Meshes 3D : géométries triangulées utilisées pour les objets.

• Mesh Filter : référence à la géométrie d’un objet.

• Mesh API : création et modification de meshes par code.

• Mesh Data API : accès performant aux données géométriques.

• Model Importer : import de FBX, OBJ et autres formats compatibles.

• Scale Factor : adaptation de l’échelle lors de l’import.

• Rig Import : lecture de squelettes et animations.

• Material Import : création ou liaison des matériaux depuis un fichier 3D.

• Texture Importer : configuration des textures selon leur usage.

• Compression par plateforme : formats et tailles différents selon la cible.

• Mipmaps : versions réduites d’une texture selon la distance.

• Texture Streaming : chargement des niveaux de texture nécessaires.

• Mesh Compression : réduction de la taille de certaines géométries.

• Read/Write Settings : conservation ou suppression des données CPU après import.

• ProBuilder : blockout et géométrie directement dans Unity.

• PolyShape : création de volumes depuis des contours.

• ProBuilder UV Editor : ajustement simple des UV.

• ProGrids historique : snapping et placement repris par les outils modernes.

• Terrain System : création de terrains.

• Terrain Sculpting : modification des reliefs.

• Terrain Layers : peinture de textures sur le sol.

• Trees et Details : placement de végétation et petits éléments.

• Terrain Holes : création d’ouvertures dans le terrain.

• Terrain Tools : outils supplémentaires de sculpture et d’import.

• Tree Editor historique : création de végétation simple.

• SpeedTree Integration : import et rendu de végétation compatible.

• NavMesh : représentation des zones praticables.

• AI Navigation Package : génération et mise à jour de surfaces de navigation.

• NavMesh Agent : déplacement d’un agent vers une destination.

• NavMesh Obstacle : obstacle dynamique dans la navigation.

• Off-Mesh Links : transitions comme sauts, échelles et téléportations.

• NavMesh Components : surfaces et volumes configurables.

• Physics 3D : simulation reposant sur PhysX.

• Rigidbody : mouvement physique d’un objet 3D.

• Colliders : Box, Sphere, Capsule, Mesh et autres formes.

• Triggers : détection de présence sans collision solide.

• Physics Materials : friction et rebond.

• Joints : Fixed, Hinge, Spring, Character et Configurable Joints.

• Raycasts : tests de collision le long d’un rayon.

• SphereCast et CapsuleCast : tests de volumes en mouvement.

• Overlap Queries : recherche de colliders dans une zone.

• Collision Matrix : définition des layers pouvant interagir.

• Continuous Collision Detection : réduction de certains traversés à grande vitesse.

• Character Controller : déplacement contrôlé d’un personnage sans Rigidbody classique.

• Cloth Component : simulation de tissu sur certains meshes.

• Wheel Collider : physique spécialisée pour véhicules.

• Fixed Timestep : fréquence de mise à jour de la physique.

• Manual Physics Simulation : contrôle du moment où la simulation est calculée.

• Animation Clips : stockage des courbes et keyframes.

• Animation Window : création et modification d’animations.

• Animator Component : exécution d’un Animator Controller.

• Animator Controller : machine à états d’animation.

• Animator States : états correspondant à des clips ou Blend Trees.

• Animator Transitions : passages conditionnels entre les états.

• Animator Parameters : booléens, triggers, entiers et flottants.

• Blend Trees : mélange de plusieurs animations.

• Animation Layers : superposition de plusieurs états d’animation.

• Avatar Masks : limitation d’une animation à certaines parties du corps.

• Humanoid Rig : retargeting entre personnages humanoïdes.

• Generic Rig : animation de squelettes non humanoïdes.

• Legacy Animation : prise en charge de certains projets historiques.

• Root Motion : déplacement fondé sur l’animation.

• Animation Events : appel de fonctions depuis une animation.

• State Machine Behaviours : scripts associés aux états de l’Animator.

• Inverse Kinematics Mecanim : ajustement des mains et pieds.

• Animation Rigging : contraintes procédurales supplémentaires.

• Two Bone IK : résolution d’un membre articulé.

• Multi-Aim Constraint : orientation vers une ou plusieurs cibles.

• Multi-Parent Constraint : combinaison de plusieurs références parentales.

• Rig Layers : activation de groupes de contraintes.

• Timeline : séquençage de pistes.

• Playable Director : composant exécutant une Timeline.

• Animation Tracks : animation de GameObjects.

• Activation Tracks : activation d’objets sur une période.

• Audio Tracks : placement de sons.

• Signal Tracks : envoi d’événements.

• Control Tracks : contrôle de particules, prefabs ou timelines secondaires.

• Custom Playables : création de pistes et comportements propres au projet.

• Cinemachine : système de caméras virtuelles.

• Virtual Cameras : caméras de composition sans multiplier les Camera Components.

• Camera Blending : transitions entre cadrages.

• Follow et Look At : suivi et orientation vers des cibles.

• Camera Noise : mouvements simulés.

• Confiner : limitation d’une caméra à une zone.

• Dolly Tracks : déplacement sur un rail.

• Target Groups : cadrage de plusieurs cibles.

• Impulse : réaction de caméra à un événement.

• Cinemachine 2D : suivi adapté aux jeux en deux dimensions.

• Cinemachine avec Timeline : réalisation de cinématiques.

• AudioSource : lecture d’un son dans la scène.

• AudioListener : point d’écoute principal.

• Audio Clips : fichiers sonores importés.

• Audio Mixer : mélange et traitement de groupes audio.

• Mixer Groups : organisation hiérarchique des sons.

• Mixer Snapshots : enregistrement d’états de mixage.

• Audio Effects : filtres et traitements intégrés.

• Spatial Blend : transition entre son 2D et 3D.

• Doppler Effect : modification de hauteur selon le mouvement.

• Audio Reverb Zones : ambiance sonore localisée.

• Native Audio Plugins : intégration d’effets natifs.

• FMOD et Wwise : intégrations tierces disponibles.

• Video Player : lecture de vidéos dans une scène.

• Render Texture Video : affichage d’une vidéo sur un matériau ou une UI.

• Timeline Video Workflows : synchronisation de vidéos dans une séquence.

• UI Toolkit : système moderne d’interface.

• Visual Elements : éléments de base de l’arbre UI.

• UXML : définition structurelle d’une interface.

• USS : feuilles de style inspirées du CSS.

• UI Builder : construction visuelle d’interfaces UI Toolkit.

• Data Binding : liaison de données dans les contextes compatibles.

• Runtime UI : interfaces affichées dans les jeux et applications.

• Editor UI : création d’outils et inspecteurs modernes.

• Runtime Debugging UI : interfaces d’outils intégrées à une application.

• Unity UI ou uGUI : interface fondée sur Canvas.

• Canvas : surface principale des interfaces uGUI.

• RectTransform : position et dimensions adaptées aux interfaces.

• Anchors : adaptation à différentes résolutions.

• Canvas Scaler : mise à l’échelle selon l’écran.

• Images et Raw Images : affichage de sprites et textures.

• Buttons : éléments interactifs.

• Sliders et Scrollbars : contrôles de valeurs et navigation.

• Scroll Views : affichage de contenus défilants.

• Layout Groups : organisation automatique d’éléments.

• Content Size Fitter : adaptation à la taille du contenu.

• EventSystem : gestion des entrées UI.

• TextMesh Pro : rendu typographique avancé.

• Signed Distance Fields : texte net à différentes tailles.

• Fallback Fonts : polices de secours.

• Rich Text : balises de mise en forme.

• Localization Package : gestion des langues et contenus localisés.

• String Tables : stockage de textes traduits.

• Asset Tables : variantes d’assets selon la langue.

• Smart Strings : chaînes dynamiques et variables.

• Pseudo-localization : test de la longueur et des caractères.

• Input System : gestion moderne des entrées.

• Input Actions : actions abstraites comme Jump, Move ou Submit.

• Action Maps : regroupement d’actions par contexte.

• Control Schemes : configurations clavier, manette ou tactile.

• Input Bindings : association d’une action à un contrôle.

• Interactive Rebinding : modification des commandes par l’utilisateur.

• Composite Bindings : axes et vecteurs composés de plusieurs touches.

• Player Input : gestion des entrées d’un joueur.

• Player Input Manager : création et association de joueurs locaux.

• Local Multiplayer : plusieurs périphériques sur une même machine.

• Touch Input : gestes et contacts tactiles.

• Sensor Input : accéléromètre, gyroscope et capteurs compatibles.

• Haptics : vibrations sur les périphériques pris en charge.

• Input Debugger : inspection des périphériques et événements.

• Legacy Input Manager : système historique encore présent.

• Accessibility APIs : fonctions destinées à améliorer l’accessibilité.

• Native Screen Reader Support : prise en charge du lecteur d’écran dans Unity 6.3 pour les plateformes compatibles.

• Color and Contrast Controls : adaptation possible de l’interface et du contenu.

• Subtitles et Captions : création par les systèmes UI et audio du projet.

• Platform Toolkit : API commune pour les services de plateformes.

• Account Management : abstraction de certains comptes de plateforme.

• Platform Save Data : interface commune pour les sauvegardes prises en charge.

• Controller Ownership : gestion du contrôleur principal.

• Achievements : interface commune pour les succès.

• Tests dans l’éditeur : simulation de certaines fonctions de plateforme.

• Android Google Play Services : intégration prise en charge par Platform Toolkit.

• iOS GameKit : intégration des services Apple.

• Steam : fonctions de plateforme sur Windows.

• Windows GDK : intégration des services Microsoft compatibles.

• PlayStation 5 : prise en charge sous conditions d’accès constructeur.

• Xbox One et Series : prise en charge sous conditions.

• Nintendo Switch et Switch 2 : prise en charge sous conditions.

• Build Profiles : configurations de compilation enregistrées.

• Profils par plateforme : paramètres distincts pour chaque cible.

• Player Settings : configuration du produit final.

• Quality Settings : niveaux de qualité graphiques.

• Graphics Settings : pipeline et paramètres généraux de rendu.

• Physics Settings : configuration de la simulation.

• Time Settings : fréquence et échelle temporelle.

• Audio Settings : fréquence et configuration audio.

• Package-specific Settings : paramètres propres aux packages.

• Build Settings historiques : interface conservée dans certains workflows.

• Windows Builds : création d’exécutables Windows.

• macOS Builds : création d’applications macOS.

• Linux Builds : création d’applications Linux.

• Android Builds : génération d’APK ou Android App Bundles.

• iOS Builds : génération d’un projet Xcode.

• Web Builds : compilation en WebAssembly et WebGL.

• Universal Windows Platform : création d’applications UWP dans les versions compatibles.

• Console Builds : déploiement sur plateformes fermées autorisées.

• Apple Vision Pro : création d’applications spatiales avec le plan compatible.

• tvOS : création d’applications pour Apple TV.

• Android TV : création d’applications Android adaptées.

• XR Builds : compilation pour casques et plateformes compatibles.

• Dedicated Server Builds : création de joueurs sans rendu pour serveurs.

• Headless Mode : exécution sans interface graphique.

• Command Line Arguments : automatisation de l’éditeur et des builds.

• Batch Mode : lancement sans interaction utilisateur.

• Execute Method : appel d’une méthode C# depuis la ligne de commande.

• Development Builds : compilation avec outils et symboles supplémentaires.

• Script Debugging : connexion d’un débogueur au Player.

• Autoconnect Profiler : liaison automatique d’un build au Profiler.

• Deep Profiling : instrumentation détaillée du code.

• Managed Debug Symbols : conservation des informations de débogage.

• Code Stripping : suppression de code inutilisé.

• Texture Compression par plateforme : adaptation des assets à chaque appareil.

• Managed Code Compilation : compilation des scripts C#.

• Incremental Builds : réutilisation de résultats intermédiaires.

• Build Cache : conservation de données pour accélérer les compilations.

• Build Report : analyse du contenu et de la taille du build.

• AssetBundles : regroupement d’assets chargeables séparément.

• Addressables : gestion de références et chargements asynchrones.

• Addressable Groups : organisation des assets distribués.

• Local et Remote Groups : séparation des contenus embarqués ou distants.

• Addressable Labels : regroupement logique de ressources.

• Addressable Profiles : paramètres différents pour développement et production.

• Content Update Workflow : mise à jour d’assets sans reconstruire toute l’application.

• AssetBundle Compression : LZ4, LZMA et modes compatibles.

• AssetBundle Variants historiques : mécanismes utilisés dans certains anciens projets.

• StreamingAssets : inclusion de fichiers conservés dans leur forme originale.

• Resources Folder : chargement simple mais difficile à optimiser dans les grands projets.

• Async Loading : chargement sans bloquer systématiquement la frame principale.

• Scene Streaming : chargement progressif de niveaux.

• Profiler : analyse des performances.

• CPU Profiler : mesure du temps processeur.

• GPU Profiler : mesure du temps graphique sur les plateformes compatibles.

• Rendering Profiler : statistiques de rendu.

• Memory Profiler : analyse de la mémoire.

• Audio Profiler : observation des voix et traitements audio.

• Physics Profiler : analyse des calculs physiques.

• UI Profiler : observation des interfaces.

• Network Profiler historique : analyse disponible selon les packages utilisés.

• Profiler Highlights : résumé statistique ajouté dans Unity 6.3.

• Profiler Markers : instrumentation de code personnalisée.

• Custom Profiler Modules : ajout de données spécifiques.

• Profile Analyzer : comparaison et agrégation de captures.

• Frame Debugger : inspection des étapes de rendu.

• Memory Snapshots : captures détaillées de la mémoire.

• Rendering Statistics : triangles, batches, SetPass et autres métriques.

• Editor Iteration Profiler : analyse de certains temps d’itération.

• RenderDoc Integration : capture d’une frame graphique.

• Crash Reporting : remontée d’incidents via les services compatibles.

• Cloud Diagnostics : collecte d’erreurs, exceptions et crashs.

• Log Files : journaux de l’éditeur et des Players.

• Stack Traces : affichage de la pile d’appels.

• Debug Class : logs et assertions par script.

• Assertions : vérification de conditions pendant le développement.

• Test Framework : création de tests Edit Mode et Play Mode.

• Edit Mode Tests : tests exécutés sans lancer entièrement le jeu.

• Play Mode Tests : tests dans un contexte d’exécution.

• Parameterized Tests : tests avec plusieurs données.

• Unity Performance Testing : mesures répétables de performances.

• Code Coverage : analyse du code parcouru par les tests.

• Build Automation Tests : exécution de tests dans une chaîne automatisée.

• Unity Version Control : gestion de versions adaptée aux fichiers volumineux.

• Branches : développement de variantes du projet.

• Changesets : groupes de modifications enregistrées.

• Smart Locks : verrouillage de fichiers binaires.

• Gluon Workflow : interface simplifiée pour les artistes.

• Merge Tools : fusion de scènes, prefabs et fichiers texte compatibles.

• UnityYAMLMerge : fusion spécialisée de fichiers Unity sérialisés.

• Git Compatibility : utilisation possible de Git avec réglages adaptés.

• Visible Meta Files : conservation des GUID dans le contrôle de versions.

• Force Text Serialization : stockage lisible de scènes et prefabs.

• Build Automation : compilation cloud automatisée.

• Build Triggers : déclenchement depuis une branche ou une modification.

• Cloud Build Machines : environnements Windows, Linux et macOS.

• Pipeline Automation : orchestration de processus cloud.

• Asset Manager : gestion centralisée de ressources 3D.

• Cloud Storage : capacité variable selon le plan et la consommation.

• Unity Gaming Services : ensemble de services backend.

• Authentication : identification anonyme, plateforme ou personnalisée.

• Cloud Save : stockage de progression et données de joueur.

• Cloud Code : logique serveur exécutée dans le cloud.

• Economy : monnaies, inventaires et achats virtuels.

• Leaderboards : classements configurables.

• Analytics : analyse des événements et comportements.

• Remote Config : modification de paramètres sans nouvelle version du jeu.

• Game Overrides : adaptation d’expériences à des segments de joueurs.

• Push Notifications : messages envoyés aux appareils compatibles.

• In-App Purchasing : gestion des produits et abonnements de boutiques.

• Cloud Content Delivery : hébergement de contenus téléchargeables.

• Triggers : lancement d’actions en réponse à des événements ou horaires.

• Environments : séparation des données de développement, staging et production.

• Service Accounts : authentification de processus et outils serveur.

• Dashboard UGS : configuration des services depuis le Web.

• SDK clients : accès aux services depuis un projet Unity.

• Web APIs : intégration depuis des backends externes.

• Multiplayer Services SDK : interface commune pour plusieurs services multijoueur.

• Sessions : gestion de groupes et connexions de joueurs.

• Lobby : création et recherche de salons.

• Relay : connexion entre joueurs sans serveur dédié exposé.

• Matchmaker : association de joueurs et serveurs.

• Multiplay Hosting : hébergement de serveurs selon l’offre disponible.

• Vivox : chat vocal et textuel.

• Friends : fonctions sociales entre joueurs.

• Unity Transport : couche réseau de bas niveau.

• Netcode for GameObjects : synchronisation de projets GameObject.

• NetworkObjects : objets possédant une identité réseau.

• NetworkVariables : données synchronisées.

• Remote Procedure Calls : appels entre clients et serveurs.

• Client-Server Authority : contrôle de l’autorité réseau.

• Network Prefabs : prefabs enregistrés pour le réseau.

• Netcode for Entities : réseau adapté à ECS.

• Ghosts : entités synchronisées.

• Prediction : simulation locale anticipant les données serveur.

• Interpolation : lissage des états reçus.

• Host Migration : poursuite possible d’une session après la perte de l’hôte dans les workflows compatibles.

• Dedicated Server Package : optimisation des builds serveur.

• Multiplayer Play Mode : test de plusieurs joueurs depuis l’éditeur.

• Multiplayer Tools : statistiques et simulation de conditions réseau.

• Network Simulator : latence, perte et instabilité simulées.

• Unity Building Blocks : composants prêts à adapter pour des fonctions courantes.

• Achievements Building Blocks : base d’intégration de succès.

• Leaderboards Building Blocks : base d’intégration de classements.

• Multiplayer Session Building Blocks : démarrage de sessions multijoueurs.

• XR Plugin Management : organisation des plugins XR.

• OpenXR : standard commun pour plusieurs casques.

• AR Foundation : abstraction pour la réalité augmentée.

• ARCore Integration : fonctions AR sur Android compatible.

• ARKit Integration : fonctions AR sur iOS compatible.

• XR Interaction Toolkit : interactions avec contrôleurs, mains et objets.

• Locomotion System : déplacement dans une expérience XR.

• XR Grab Interactable : objets manipulables.

• XR Ray Interactor : interaction à distance.

• XR Device Simulator : test partiel depuis l’éditeur.

• Hand Tracking : suivi des mains sur les plateformes compatibles.

• Spatial Anchors : ancrage de contenus dans l’environnement compatible.

• Passthrough : mélange de vue réelle et virtuelle selon le matériel.

• Apple Vision Pro Support : création d’applications spatiales avec un plan compatible.

• Android XR Support : intégration avec les appareils et packages compatibles.

• Asset Store : catalogue d’assets et extensions.

• Assets gratuits et payants : ressources sous différentes licences.

• Modèles 3D : personnages, décors, objets et véhicules.

• 2D Assets : sprites, tilesets, interfaces et effets.

• Animations : clips, rigs et contrôleurs.

• Audio : sons, musiques et plugins.

• Shaders et VFX : matériaux, effets et pipelines.

• Editor Extensions : outils ajoutant des fonctions à Unity.

• Templates : bases de projets et systèmes complets.

• SDK : intégrations avec des services externes.

• AI et ML Assets : outils et modèles proposés par Unity ou des tiers.

• Package Import : ajout d’assets téléchargés au projet.

• My Assets : bibliothèque liée au compte Unity.

• Publisher Tools : outils destinés aux créateurs d’assets.

• EULA standard : licence généralement appliquée aux assets.

• Licences non standard : conditions propres à certains éditeurs.

• Restricted Assets : ressources soumises à des restrictions supplémentaires.

• Seat Extensions : assets dont le nombre de licences dépend des utilisateurs selon leur type.

• Unity Learn : plateforme de tutoriels et parcours.

• Microgames : projets éducatifs prêts à modifier.

• Pathways : parcours guidés pour apprendre l’éditeur.

• Samples officiels : exemples de systèmes et bonnes pratiques.

• Unity Discussions : forum communautaire officiel.

• Documentation Manual : explications conceptuelles et guides.

• Scripting API : référence des classes, méthodes et propriétés.

• Package Documentation : documentation spécifique à chaque package.

• Release Notes : liste des modifications et problèmes connus.

• Upgrade Guides : instructions de migration entre versions.

• Unity AI : outils d’intelligence artificielle facultatifs.

• Agent IA : assistance contextuelle selon l’offre disponible.

• Unity AI Gateway : connexion avec des fonctions et modèles compatibles.

• Crédits Unity AI : quotas consommés selon les opérations.

• Connexions MCP : exposition d’outils ou contexte via Model Context Protocol.

• Essai limité : accès temporaire à certaines fonctions d’IA.

• Abonnement séparé : paiement nécessaire au-delà des accès inclus ou d’essai.

Cas d’usage

Créer un jeu mobile

Unity est particulièrement adapté aux jeux Android et iOS.

L’équipe peut partager une grande partie du code et des assets entre les deux plateformes, puis appliquer des réglages spécifiques aux contrôles tactiles, performances, boutiques et formats d’écran.

URP, les Sprite Atlas, Addressables, l’Input System et les outils de profiling facilitent l’adaptation à des appareils très différents.

Produire un jeu indépendant en 2D

Les sprites, Tilemaps, Physics 2D, 2D Animation et Pixel Perfect Camera couvrent une grande partie des besoins d’un jeu de plateforme, RPG, puzzle ou jeu narratif.

Le code C# permet de dépasser les fonctions visuelles et de construire des systèmes personnalisés.

L’Asset Store peut accélérer la création, mais une accumulation de plugins rend rapidement le projet difficile à maintenir.

Développer un jeu 3D multiplateforme

Unity permet de construire les niveaux, intégrer les personnages, programmer le gameplay et déployer le projet vers plusieurs systèmes.

URP convient à un large ensemble de matériels.

HDRP devient pertinent pour les projets visant les ordinateurs et consoles haut de gamme, mais demande davantage de ressources et ne couvre pas les mêmes plateformes.

Prototyper rapidement une mécanique

Les GameObjects, Components, Prefabs et scripts MonoBehaviour permettent d’assembler rapidement un prototype.

ProBuilder peut servir au blockout du niveau.

Le prototype doit ensuite être restructuré si l’architecture initiale ne convient pas à une production longue.

Participer à une game jam

Unity Hub, les templates et l’Asset Store permettent de démarrer rapidement.

La disponibilité de nombreux tutoriels facilite la résolution de problèmes courants.

Une version déjà installée et maîtrisée reste préférable, car le téléchargement des modules peut prendre beaucoup de temps.

Créer un jeu de plateforme

Le Character Controller, les Rigidbodies ou Physics 2D peuvent gérer le déplacement.

Cinemachine suit le personnage et adapte le cadrage.

Les Tilemaps, Prefabs et scènes additives facilitent la construction des niveaux.

Créer un RPG

Les ScriptableObjects peuvent représenter les personnages, objets, compétences et quêtes.

Les Prefabs servent aux ennemis, effets et éléments interactifs.

Cloud Save, Economy ou un backend externe peuvent conserver la progression et les inventaires.

Créer un jeu de stratégie

Les systèmes de navigation, UI, données et sélection peuvent être combinés avec des centaines d’unités.

Jobs, Burst ou Entities deviennent intéressants lorsque l’échelle dépasse ce qu’une architecture MonoBehaviour classique peut gérer efficacement.

Le passage à ECS exige cependant une conception différente et une expertise plus importante.

Produire un jeu multijoueur coopératif

Netcode for GameObjects peut synchroniser des joueurs et objets dans un projet classique.

Lobby et Relay facilitent la création de sessions sans développer immédiatement toute l’infrastructure réseau.

La logique critique doit rester contrôlée par une autorité fiable afin de limiter la triche.

Créer un jeu compétitif avec serveurs dédiés

Unity peut générer un build serveur sans rendu.

Matchmaker cherche une partie et un serveur disponibles.

Les coûts d’hébergement, la sécurité, l’observabilité et le déploiement doivent être planifiés avant l’ouverture au public.

Développer un jeu en service

Remote Config, Analytics, Cloud Code, Economy, Leaderboards et Cloud Content Delivery permettent de faire évoluer une expérience après sa publication.

Les environnements séparent développement, staging et production.

Cette approche augmente la complexité opérationnelle et la dépendance aux services cloud.

Déployer sur console

Unity Pro ou une licence fournie par le constructeur est généralement nécessaire.

L’équipe doit être approuvée par Nintendo, Sony ou Microsoft avant d’obtenir les modules, SDK et documentation confidentielle.

Le jeu doit respecter les contraintes de performances, stockage, contrôleurs, sauvegarde et certification de chaque plateforme.

Créer un jeu Web

Unity compile vers WebAssembly et WebGL afin d’exécuter le contenu dans un navigateur compatible.

Ce format convient aux démonstrations, expériences promotionnelles, jeux courts et contenus éducatifs.

La taille de téléchargement, la mémoire, le multithreading, les codecs et l’accès au système restent plus limités que dans une application native.

Réaliser une expérience de réalité virtuelle

OpenXR et XR Interaction Toolkit fournissent une base commune pour plusieurs casques.

L’équipe peut créer locomotion, saisie d’objets, interactions à distance et UI spatiale.

La fréquence d’images, la latence et le confort doivent être testés directement sur chaque appareil cible.

Créer une application de réalité augmentée

AR Foundation permet de partager une partie du code entre ARKit et ARCore.

L’application peut utiliser détection de plans, ancres, caméra, profondeur et suivi selon le matériel.

Les fonctions réellement disponibles diffèrent entre appareils et versions des systèmes.

Développer une application pour Apple Vision Pro

Unity Pro et les outils compatibles permettent de créer des applications spatiales.

Le projet peut combiner contenu volumétrique, fenêtres, interactions et environnement réel.

Un Mac, Xcode, le matériel approprié et les conditions Apple restent nécessaires.

Créer une visualisation architecturale

HDRP peut produire des éclairages, matériaux et réflexions adaptés à une visualisation réaliste.

Cinemachine et Timeline permettent de préparer une visite.

Unity n’est toutefois pas un outil BIM et doit recevoir des données nettoyées depuis Revit, Blender, 3ds Max ou un pipeline spécialisé.

Réaliser une simulation industrielle

Unity Industry cible les visualisations, configurateurs, formations et applications hors jeu.

Le moteur peut afficher des machines, procédures, données et interactions en temps réel.

Les entreprises dépassant le seuil financier doivent utiliser le plan Industry et vérifier les conditions propres aux données industrielles.

Créer un jumeau numérique

Des modèles 3D peuvent être associés à des données provenant de capteurs, API ou systèmes externes.

Unity affiche l’état d’un équipement et permet de simuler certaines interactions.

La précision dépend du modèle de données et des calculs scientifiques, pas uniquement du rendu visuel.

Produire une formation interactive

Unity peut présenter une procédure, vérifier les actions de l’utilisateur et enregistrer les résultats.

La même base peut viser ordinateur, tablette ou casque XR.

L’accessibilité, la sécurité des données et la maintenance des contenus doivent être intégrées dès la conception.

Créer une expérience pour un musée

Le moteur peut piloter un écran tactile, une projection, une installation immersive ou un dispositif interactif.

Les applications peuvent fonctionner localement sans exposer toute leur logique à Internet.

Une installation publique nécessite un mode kiosque, un redémarrage automatique et une surveillance du matériel.

Réaliser une cinématique en temps réel

Timeline, Cinemachine, Animation Rigging, HDRP et VFX Graph peuvent produire une séquence dans le moteur.

Les modifications de caméra, lumière ou animation sont visibles sans attendre un rendu offline complet.

Pour une image finale extrêmement complexe, Blender, Maya, Houdini, Unreal Engine ou un moteur de rendu spécialisé peuvent rester plus adaptés.

Construire une interface interactive

UI Toolkit ou uGUI peuvent créer menus, tableaux de bord et panneaux.

L’Input System permet de naviguer avec souris, clavier, manette ou tactile.

Unity reste plus lourd qu’un framework Web ou desktop pour une application essentiellement composée de formulaires et de texte.

Créer un configurateur de produit

L’utilisateur peut changer la couleur, les matériaux, les variantes et les accessoires d’un produit 3D.

Addressables permet de charger des options supplémentaires.

Le projet peut être déployé sur ordinateur, mobile, Web ou casque selon la complexité du modèle.

Produire une application éducative

Unity peut combiner texte, images, vidéo, son, simulation et interaction.

Les systèmes de scènes et prefabs facilitent la création de plusieurs chapitres ou exercices.

Un outil plus léger peut être préférable lorsque l’expérience ne nécessite ni rendu temps réel ni interactions complexes.

Créer un visual novel

Les ScriptableObjects, TextMesh Pro, Timeline et systèmes de données peuvent organiser dialogues, personnages et choix.

Des plugins de l’Asset Store proposent des frameworks prêts à l’emploi.

Le projet doit conserver ses scripts et données dans un format exportable afin d’éviter une dépendance complète à un plugin abandonné.

Développer un serious game

Unity permet de transformer une procédure ou un apprentissage en expérience interactive.

Les Analytics peuvent mesurer la progression et les difficultés.

Les règles d’évaluation doivent être validées par les spécialistes du domaine concerné.

Créer un jeu avec contenu téléchargeable

Addressables et Cloud Content Delivery peuvent séparer le programme principal des nouveaux assets.

L’équipe peut ajouter des niveaux, événements ou cosmétiques sans reconstruire toutes les données.

Les changements de code nécessitent généralement une nouvelle version distribuée par la boutique.

Publier un outil sur l’Asset Store

Un développeur peut créer un éditeur, système de gameplay, shader, modèle ou template.

Le package doit respecter les règles techniques, les licences des dépendances et les exigences de documentation.

Les assets sont concédés sous licence et non vendus comme une propriété transférée au client.

Intégrer un SDK externe

Unity peut recevoir des SDK de paiement, publicité, analytics, audio, réseau ou intelligence artificielle.

Les packages peuvent utiliser C#, bibliothèques natives et plugins propres aux plateformes.

Chaque SDK augmente les risques de conflit, de taille, de collecte de données et de maintenance.

Automatiser des builds

Le mode batch et la ligne de commande permettent de compiler sans ouvrir manuellement l’éditeur.

Build Automation exécute ces opérations dans le cloud.

Les versions de Unity, packages, SDK et secrets doivent être fixées pour produire des builds reproductibles.

Utiliser Unity pour Character Creator

Unity pourrait servir à afficher des personnages 3D interactifs, gérer des animations, expressions, comportements et environnements.

Il peut intégrer audio, lip-sync, conversations et interactions en temps réel.

Cette approche serait beaucoup plus lourde qu’un affichage d’images et de vidéos pré-générées et nécessiterait des modèles 3D, rigs et animations adaptés.

Préparer une application multiplateforme avec une seule base

Platform Toolkit réduit une partie du code nécessaire pour les comptes, sauvegardes et succès.

Les sections de gameplay peuvent rester communes.

Les interfaces, performances, contrôleurs, achats et règles de certification doivent néanmoins être vérifiés séparément sur chaque plateforme.

Avis PANACHES

Unity est l’un des moteurs de jeu les plus importants de l’histoire récente du développement indépendant, mobile et multiplateforme.

Sa principale force réside dans l’équilibre entre accessibilité, puissance et étendue de l’écosystème.

Un débutant peut déplacer des objets dans une scène, ajouter un script C# et produire un premier build sans devoir construire un moteur complet.

Une équipe expérimentée peut développer des systèmes complexes, créer ses propres outils d’éditeur, automatiser ses builds et déployer vers de nombreuses plateformes.

Cette progression relativement continue explique la place de Unity dans les écoles, formations, game jams et studios indépendants.

L’architecture GameObject et Component reste simple à comprendre.

Elle encourage la composition plutôt que des hiérarchies de classes trop rigides.

Les Prefabs ajoutent un système de réutilisation très efficace pour les personnages, objets, interfaces et éléments de niveau.

Cette souplesse peut cependant conduire à une architecture désorganisée.

Un projet peut rapidement accumuler des MonoBehaviours qui dépendent les uns des autres, des références cachées dans l’Inspector et des objets responsables de trop de fonctions.

Unity ne remplace donc pas la conception logicielle.

Les patterns, tests, conventions et frontières entre systèmes restent nécessaires.

C# constitue un avantage majeur.

Le langage est plus accessible que C++ pour de nombreux développeurs tout en permettant de construire des outils et architectures solides.

L’écosystème .NET facilite également l’intégration de bibliothèques, même si toutes ne sont pas compatibles avec les restrictions de Unity ou d’IL2CPP.

Le modèle d’itération reste l’un des atouts historiques du moteur.

Les designers peuvent modifier une scène et tester immédiatement le résultat.

Les valeurs exposées dans l’Inspector facilitent le réglage sans recompilation complète.

Les temps de rechargement de domaine, d’import et de compilation peuvent néanmoins devenir importants dans les grands projets.

Les Assembly Definitions, l’Enter Play Mode sans rechargement complet et une bonne séparation du code réduisent une partie de ces délais.

Le choix entre Built-in, URP et HDRP reste une source de confusion.

URP représente généralement le choix le plus équilibré pour un nouveau jeu multiplateforme.

HDRP offre davantage de fonctions graphiques haut de gamme, mais augmente les exigences matérielles et réduit la liste des plateformes adaptées.

Built-in reste utile pour la maintenance d’anciens projets, mais il devient moins pertinent pour une nouvelle production à long terme.

La migration entre pipelines n’est jamais totalement neutre.

Les matériaux, shaders et effets achetés sur l’Asset Store doivent être vérifiés avant de choisir un pipeline.

Shader Graph constitue une bonne passerelle entre art et programmation graphique.

Un artiste technique peut créer des effets sans écrire tout le shader.

Les graphes complexes restent toutefois du code visuel et doivent être structurés, commentés et optimisés.

VFX Graph permet de produire des effets très riches.

Il dépend davantage du GPU et ne convient pas à toutes les plateformes.

Le système de particules classique reste souvent plus prévisible pour un jeu mobile ou Web.

Les outils 2D sont désormais suffisamment complets pour de nombreux jeux.

Tilemap, Sprite Atlas, 2D Animation, Physics 2D et URP 2D évitent d’utiliser un moteur séparé.

Unity conserve néanmoins une organisation fondamentalement issue de la 3D. Certains moteurs dédiés à la 2D peuvent sembler plus directs.

L’intégration 2D et 3D améliorée dans Unity 6.3 est particulièrement intéressante pour les jeux mêlant sprites, décors volumétriques et éclairage.

L’animation est très complète.

Mecanim, Timeline, Cinemachine et Animation Rigging couvrent gameplay et cinématiques.

La multiplication des systèmes peut toutefois rendre difficile l’identification de la source réelle d’un mouvement : Animator, Timeline, script, rig, physique ou root motion.

Le profiling est indispensable.

Unity peut produire d’excellentes performances, mais ne les garantit pas automatiquement.

Une mauvaise gestion des allocations, lumières, textures, scripts Update, physique ou Draw Calls peut rendre un projet lent même sur un ordinateur puissant.

Les critiques communautaires concernant des jeux Unity mal optimisés reflètent souvent autant les choix des développeurs que les limites du moteur.

Cela ne signifie pas que le moteur est exempt de problèmes.

L’éditeur peut devenir lourd, les imports longs et certains systèmes présentent des régressions ou changements de comportement entre versions.

Une version LTS réduit le risque sans le supprimer.

Le support multiplateforme constitue l’un des plus grands avantages de Unity.

Le slogan consistant à créer une fois et déployer partout doit cependant être compris comme une base de code largement partagée, et non comme un bouton produisant automatiquement un résultat optimal sur toutes les plateformes.

Chaque plateforme possède ses contrôleurs, mémoire, API, magasins, règles de confidentialité et contraintes de certification.

Les builds doivent être testés sur les appareils réels dès le début.

Platform Toolkit représente une amélioration pertinente.

Une API commune pour les comptes, sauvegardes et succès réduit les couches de code propres aux consoles et boutiques.

Il ne supprime pas l’obligation d’obtenir les SDK et autorisations des fabricants.

Le multijoueur a longtemps été perçu comme une zone fragmentée de Unity.

La combinaison actuelle de Netcode, Transport, Multiplayer Services SDK, Lobby, Relay et Matchmaker offre un ensemble plus cohérent.

Elle reste composée de plusieurs packages et services possédant chacun leur cycle de vie.

Une équipe doit choisir rapidement entre un modèle client-host, serveur dédié, autorité serveur, GameObjects ou Entities.

Relay simplifie les premières connexions, mais ne remplace pas un serveur autoritaire pour un jeu compétitif.

Les Unity Gaming Services accélèrent la création d’un backend.

Authentication, Cloud Save, Economy et Remote Config évitent de développer immédiatement chaque brique.

Leur utilisation introduit des coûts variables et un verrouillage envers les API Unity.

Une abstraction interne reste utile pour permettre une migration ultérieure.

L’Asset Store est une force immense.

Il contient des outils capables d’économiser plusieurs mois de développement.

Il permet aussi de démarrer un prototype avec des modèles, sons, interfaces et systèmes existants.

La qualité varie fortement.

Certains assets sont maintenus pendant des années, d’autres cessent de fonctionner après une version de Unity.

Les utilisateurs doivent vérifier la date de mise à jour, les avis, le pipeline de rendu, les plateformes et le niveau de support.

Un projet construit comme un assemblage de dizaines d’assets peut devenir impossible à mettre à jour.

Les styles, conventions et architectures entrent en conflit.

L’Asset Store doit compléter un projet, pas remplacer sa direction technique.

Les licences des assets méritent une attention particulière.

L’EULA standard permet généralement d’intégrer une ressource à un produit, mais pas de redistribuer son fichier source comme une bibliothèque indépendante.

Certains outils sont concédés par siège.

Certains assets utilisent une licence non standard ou contiennent des composants open source marqués comme Restricted Asset.

La licence de Unity lui-même a profondément affecté la confiance de la communauté.

L’annonce des frais Runtime en 2023 a créé une inquiétude légitime concernant la possibilité de modifier les règles économiques après le choix du moteur.

Unity a finalement supprimé ces frais.

Les conditions actuelles précisent qu’aucun frais Runtime, royalty ou partage de revenus ne s’applique à la distribution du moteur.

La suppression ne fait pas disparaître l’historique ni le risque commercial.

Unity reste un produit propriétaire dont les abonnements, seuils et conditions peuvent évoluer.

Une entreprise doit conserver les conditions acceptées, versions utilisées, factures et preuves d’éligibilité.

Unity Personal est généreux pour un créateur de jeu indépendant sous le seuil financier.

La suppression de l’obligation d’afficher le splash screen dans Unity 6 a éliminé une différence visuelle autrefois très visible.

Le seuil de 200 000 dollars laisse une marge supérieure à l’ancien seuil.

Les règles deviennent plus complexes lorsque le développeur travaille pour des clients.

Les finances du client peuvent déterminer l’éligibilité au niveau de licence.

Un freelance ne doit donc pas considérer uniquement son propre chiffre d’affaires.

Unity Pro reste relativement coûteux pour une petite équipe.

À 2 310 dollars par poste et par an, cinq développeurs représentent déjà une dépense importante avant les services et assets.

Les abonnements sont généralement associés à un engagement et ne peuvent pas être réduits librement en cours de période.

Unity Enterprise ajoute support, accès en lecture seule au code source, options de build et LTS étendu.

L’accès en lecture seule ne transforme pas Unity en moteur open source.

L’équipe ne possède pas la même liberté qu’avec Godot, Stride ou un moteur interne.

Unity Industry sépare désormais clairement les applications hors jeu.

Cette segmentation peut être coûteuse pour les entreprises de visualisation, architecture, automobile, santé ou formation.

Le seuil d’un million de dollars concerne les finances totales de l’entreprise et non uniquement les revenus du projet Unity.

Unity fonctionne localement pour l’édition et la compilation de nombreuses plateformes.

Il n’impose pas de stocker chaque projet dans le cloud.

Cette caractéristique reste compatible avec une partie de la philosophie local-first de PANACHES.

Le compte Unity, l’activation des licences, les packages, l’Asset Store et plusieurs services créent néanmoins des dépendances réseau.

Unity est moins souverain que Blender ou Godot.

Unity Version Control est intéressant pour les équipes mêlant code et fichiers binaires.

Git reste possible, mais exige une configuration correcte des .meta, de la sérialisation texte et de Git LFS.

Une mauvaise gestion des GUID peut casser les références entre assets.

Les fichiers .meta doivent toujours être versionnés avec leur fichier associé.

Les services cloud Unity sont pratiques mais ne doivent pas devenir l’unique copie d’un projet.

Le dépôt source, les builds, assets achetés, packages internes et configurations doivent être sauvegardés ailleurs.

L’intelligence artificielle intégrée peut accélérer certaines tâches.

Elle ne doit pas introduire silencieusement du code non compris ou des assets dont la licence est incertaine.

Les conditions de traitement, la confidentialité et le coût des crédits doivent être vérifiés avant d’envoyer du code propriétaire ou des données de client.

Entities, Jobs et Burst permettent d’atteindre une échelle importante.

Ils exigent une architecture orientée données très différente du modèle GameObject traditionnel.

Leur utilisation ne doit pas être motivée uniquement par une promesse abstraite de performances.

Un jeu classique peut rester plus simple et suffisamment rapide avec des MonoBehaviours bien optimisés.

AlternativeTo classe Unity parmi les moteurs freemium propriétaires et met principalement en avant Godot, Unreal Engine et Stride comme alternatives.

Les retours communautaires y sont très partagés.

Les points positifs concernent souvent la facilité d’apprentissage, C#, la communauté, l’Asset Store et la publication mobile.

Les critiques visent la confiance envers l’entreprise, la lourdeur, les performances de certains projets, la fragmentation des systèmes et l’évolution des licences.

Un avis ancien sur les frais Runtime doit être replacé dans son contexte : ces frais ont été officiellement supprimés.

Unreal Engine constitue la principale alternative propriétaire pour les projets 3D haut de gamme.

Il propose une licence fondée sur des royalties dans plusieurs cas, un accès au code source et une forte intégration des outils artistiques.

Son éditeur et C++ peuvent être plus exigeants, même si Blueprints facilite le prototypage.

Godot est la principale alternative libre et open source.

Il est léger, transparent et particulièrement agréable pour de nombreux projets 2D.

Son écosystème, ses plateformes fermées et ses outils très haut de gamme restent moins étendus que ceux de Unity.

Stride est un moteur open source en C#.

Il peut intéresser les développeurs souhaitant rester proches de .NET sans dépendre de Unity.

Sa communauté et son Asset Store sont beaucoup plus petits.

GameMaker offre un workflow très direct pour la 2D.

Il devient moins adapté aux projets 3D complexes ou aux équipes recherchant un pipeline généraliste.

Pour PANACHES, Unity fournit plusieurs modèles d’interface intéressants.

La combinaison Hierarchy, Scene, Project et Inspector montre comment séparer structure, espace visuel, fichiers et propriétés.

Le système de Components est une référence pertinente pour construire des fonctionnalités modulaires.

Les Prefabs illustrent la différence entre une ressource réutilisable et ses instances personnalisées.

Les ScriptableObjects démontrent comment séparer les données du comportement et des scènes.

Le Package Manager montre l’intérêt d’un cœur extensible, mais aussi les risques de fragmentation et de dépendances incompatibles.

L’Asset Store peut inspirer une bibliothèque de modules, templates et ressources pour PANACHES.

La qualité de recherche, les versions, licences, dépendances et avis doivent être traitées comme des données essentielles.

Addressables constitue une référence utile pour différencier une ressource logique de son emplacement physique.

PANACHES peut s’inspirer de ce modèle pour gérer des médias locaux, distants, mis en cache ou téléchargés à la demande.

Platform Toolkit illustre l’intérêt d’une couche commune au-dessus de plusieurs fournisseurs.

Une abstraction comparable pourrait permettre à PANACHES de connecter différents modèles d’IA, systèmes de stockage ou services sans réécrire toute l’application.

Le Profiler rappelle qu’un logiciel modulaire doit rendre ses performances visibles.

PANACHES gagnerait à exposer consommation mémoire, temps de chargement, activité des modules et taille des caches.

Pour Character Creator, Unity peut devenir une plateforme d’avatars 3D réellement interactifs.

Il pourrait gérer animation idle, expressions faciales, lip-sync, caméra, environnement, audio spatial et interactions.

Cette piste exige cependant une chaîne complète de modèles 3D, rigging, retargeting, optimisation et rendu temps réel.

Le pipeline actuel fondé sur SDXL, WAN et vidéos pré-générées reste plus accessible sur le matériel disponible.

Unity ne doit donc pas être intégré uniquement parce qu’il offre une démonstration spectaculaire.

Il doit répondre à un besoin d’interaction temps réel que les images et vidéos ne peuvent pas satisfaire.

Unity mérite une place majeure dans l’annuaire PANACHES.

Il reste un moteur extrêmement capable pour créer rapidement des expériences interactives et les distribuer sur de nombreuses plateformes.

Son adoption doit néanmoins être accompagnée d’un choix de version stable, d’une architecture maîtrisée, d’une étude précise des licences et d’un plan limitant la dépendance aux services propriétaires.

Points d’attention

• Unity est propriétaire : le code complet du moteur n’est pas librement modifiable ou redistribuable.

• Accès au code source limité : Enterprise propose principalement un accès en lecture seule, avec d’autres options éventuellement facturées séparément.

• Unity Personal est limité par l’usage : il vise les jeux et applications de divertissement.

• Seuil Personal de 200 000 dollars : les revenus et financements applicables sont mesurés sur les douze derniers mois.

• Unity Pro devient obligatoire au-delà du seuil : l’organisation doit mettre à niveau ses licences lorsqu’elle n’est plus éligible.

• Les finances du client peuvent compter : un prestataire doit vérifier le niveau de ses clients, pas seulement ses propres revenus.

• Unity Enterprise devient obligatoire au-delà de 25 millions de dollars : le tarif est personnalisé.

• Unity Industry concerne les projets hors jeu : les applications industrielles suivent des règles distinctes.

• Unity Industry devient obligatoire au-delà d’un million de dollars : le seuil porte sur les finances totales de l’entreprise.

• Unity Personal n’est pas destiné aux applications industrielles : même une petite équipe doit vérifier les conditions applicables.

• Une licence par utilisateur : chaque personne utilisant l’éditeur doit posséder un siège autorisé.

• Pas de partage de siège : un même compte ou abonnement ne doit pas circuler entre plusieurs utilisateurs.

• Pas de mélange libre des plans : les utilisateurs d’une organisation doivent employer un niveau compatible.

• Vérifier les organisations Unity : les sièges et projets doivent être associés à la bonne entité.

• Unity Pro coûte par poste : le coût augmente directement avec la taille de l’équipe.

• Engagement annuel : le paiement mensuel de Pro ne signifie pas nécessairement un abonnement annulable chaque mois.

• Absence de remboursement général : les contrats d’abonnement peuvent rester dus jusqu’à la fin de l’engagement.

• Pas de réduction immédiate du nombre de sièges : les changements à la baisse peuvent attendre le renouvellement.

• Prix affichés hors taxes : TVA, devise et région modifient le montant final.

• Enterprise et Industry sur devis : des minimums de sièges ou de dépenses peuvent s’appliquer.

• Services facturés séparément : cloud, hébergement, IA, support et assets peuvent augmenter fortement le coût.

• Frais Runtime supprimés : aucun frais par installation n’est actuellement appliqué.

• Pas de royalties actuellement : la distribution du Runtime est autorisée sans partage de revenus sous les conditions actuelles.

• Respect permanent du niveau de licence : l’absence de frais Runtime ne supprime pas les seuils financiers.

• Les prix peuvent évoluer : Unity applique des ajustements d’abonnement lors des achats et renouvellements.

• Les seuils peuvent évoluer : surveiller les annonces et conditions avant chaque renouvellement.

• Conserver les conditions acceptées : archiver la version du contrat associée à l’éditeur utilisé.

• Unity 6 exige les conditions récentes : les anciennes conditions ne permettent pas nécessairement d’utiliser une nouvelle version.

• Anciennes versions et anciennes conditions : vérifier précisément les droits avant de rester sur un éditeur historique.

• Ne pas se fonder sur des articles de 2023 : les frais Runtime annoncés à cette période ont été annulés.

• L’historique reste un risque de confiance : une suppression passée ne garantit pas l’immuabilité future des offres.

• Les créations appartiennent à leurs auteurs : cela ne couvre pas automatiquement les ressources tierces.

• Vérifier chaque asset externe : modèle, texture, musique, police et plugin conservent leur licence.

• Les assets sont concédés sous licence : un achat ne transfère pas nécessairement la propriété intellectuelle.

• EULA standard du Asset Store : la majorité des produits suivent les conditions communes de Unity.

• Licences non standard possibles : leur présence doit être indiquée sur la page du produit.

• Restricted Assets : certaines ressources contiennent des composants imposant des restrictions supplémentaires.

• Assets par siège : certains outils d’éditeur nécessitent une licence pour chaque utilisateur.

• Assets d’art généralement intégrables : ils ne doivent pas être redistribués comme fichiers sources indépendants.

• Ne pas revendre un asset isolé : le produit final doit apporter une création réelle.

• Ne pas partager librement les packages achetés : une autre organisation peut devoir acheter sa propre licence.

• Vérifier les droits des sous-traitants : tous les collaborateurs doivent être couverts par la licence adaptée.

• Conserver les factures de l’Asset Store : elles permettent de prouver l’acquisition de la licence.

• Télécharger les packages importants : un asset peut être retiré de la boutique.

• Archiver la documentation d’un asset : les guides en ligne peuvent disparaître.

• Vérifier la date de dernière mise à jour : un package ancien peut ne plus fonctionner avec Unity 6.

• Vérifier le pipeline graphique : un shader Built-in n’est pas automatiquement compatible avec URP ou HDRP.

• Vérifier les plateformes annoncées : un plugin desktop peut ne pas compiler sur mobile, Web ou console.

• Vérifier IL2CPP : certains plugins fonctionnent avec Mono mais échouent lors d’une compilation AOT.

• Vérifier les architectures natives : Windows x64, Apple Silicon, Android ARM64 et consoles utilisent des binaires différents.

• Examiner les DLL incluses : elles peuvent introduire des vulnérabilités ou licences incompatibles.

• Les extensions exécutent du code : installer uniquement des éditeurs et sources fiables.

• Un package peut modifier l’éditeur : sauvegarder le projet avant l’import d’un outil important.

• Les dépendances peuvent entrer en conflit : deux assets peuvent exiger des versions différentes du même package.

• Limiter l’accumulation de plugins : chaque dépendance augmente le coût de maintenance.

• Éviter les frameworks abandonnés : un système central non maintenu peut bloquer une migration.

• Conserver le code métier séparé : réduire la dépendance à l’API d’un asset tiers.

• Tester la suppression d’un asset : vérifier qu’il ne laisse pas de références ou scripts cassés.

• Unity Hub est fortement recommandé : il gère les versions et modules de compilation.

• Vérifier la version exacte de l’éditeur : 6000.3.x peut contenir des différences entre patchs.

• Utiliser une version LTS pour verrouiller la production : les versions Update apportent davantage de changements.

• Une LTS ne signifie pas absence de bugs : lire les problèmes connus et patch notes.

• Ne pas mettre à jour automatiquement un projet critique : tester chaque patch dans une branche séparée.

• Sauvegarder avant toute migration : Unity modifie parfois les fichiers et données lors de l’ouverture.

• Une migration peut être irréversible : une ancienne version ne sait pas toujours relire un projet enregistré récemment.

• Conserver l’ancienne installation : plusieurs versions peuvent coexister.

• Archiver les modules de plateforme : une ancienne version peut devenir difficile à réinstaller.

• Fixer les versions des packages : une mise à jour indirecte peut modifier le comportement du projet.

• Examiner packages-lock.json : il décrit les versions réellement résolues.

• Éviter les packages Preview en production : leurs API et données peuvent changer.

• Vérifier le statut Released ou Verified : la compatibilité dépend de la version de Unity.

• Lire les guides de mise à niveau : certaines fonctions nécessitent une migration manuelle.

• Choisir le pipeline de rendu au départ : une conversion tardive affecte matériaux, shaders et éclairage.

• Built-in reçoit moins d’innovations : il reste surtout pertinent pour la maintenance et certains assets historiques.

• URP est le choix généraliste : il doit malgré tout être configuré selon chaque plateforme.

• HDRP vise le haut de gamme : il n’est pas adapté à la plupart des mobiles et navigateurs.

• Les pipelines ne sont pas visuellement identiques : le même matériau produit des résultats différents.

• Les shaders personnalisés doivent cibler le pipeline : vérifier le code et les passes utilisés.

• Shader Graph peut générer de nombreuses variantes : surveiller le temps de compilation et la taille du build.

• Réduire les variantes inutiles : configurer le stripping sans supprimer des shaders nécessaires.

• Tester les shaders dans un build : l’éditeur peut utiliser une variante absente du produit final.

• VFX Graph dépend du GPU : tous les appareils ne prennent pas en charge les mêmes fonctions.

• Prévoir un fallback mobile : un effet haut de gamme peut nécessiter une version simplifiée.

• Ray tracing limité au matériel compatible : fournir un rendu alternatif.

• Path tracing ne convient pas au gameplay temps réel classique : il sert surtout aux rendus et prévisualisations haut de gamme.

• Le post-processing consomme des ressources : mesurer chaque effet sur le matériel cible.

• Bloom et transparences peuvent saturer le fill rate : problème fréquent sur mobile et XR.

• Les lumières dynamiques sont coûteuses : limiter leur nombre, portée et ombres.

• Les ombres augmentent fortement le coût GPU : adapter résolution et distance.

• Le baking d’éclairage prend du temps : prévoir les calculs dans le planning.

• Les lightmaps utilisent du stockage et de la VRAM : surveiller leur résolution.

• Adaptive Probe Volumes demandent une préparation : les volumes et scénarios doivent être configurés correctement.

• Reflection Probes doivent être organisées : trop de captures augmentent mémoire et coût de rendu.

• Static Batching augmente parfois la mémoire : mesurer le compromis.

• Dynamic Batching possède des limites : ne pas supposer qu’il résoudra tous les Draw Calls.

• GPU Instancing exige des matériaux compatibles : une modification peut casser le regroupement.

• SRP Batcher exige une organisation de shaders compatible : contrôler avec les outils de profiling.

• Occlusion Culling nécessite un bake ou une configuration : elle n’aide pas toutes les scènes.

• Le LOD doit être préparé dans les assets : un seul modèle très détaillé ne s’optimise pas automatiquement.

• La taille des textures domine souvent la mémoire : adapter résolution, compression et mipmaps.

• Une texture 4K n’est pas toujours nécessaire : tenir compte de la taille visible à l’écran.

• Les textures non compressées sont coûteuses : utiliser les formats propres à chaque plateforme.

• Read/Write double certaines données en mémoire : désactiver l’option lorsqu’elle n’est pas nécessaire.

• Les meshes très denses ralentissent l’import : effectuer la retopologie avant Unity.

• Unity n’est pas un modeleur complet : conserver Blender ou un DCC dans le pipeline.

• Les modifications d’un FBX réimportent les dépendances : organiser les fichiers sources.

• Ne pas modifier directement un asset importé : utiliser prefabs, materials et données séparées.

• Vérifier l’échelle des modèles : une unité incohérente affecte physique, lumière et navigation.

• Appliquer les transformations dans le DCC : éviter les échelles négatives et rigs incorrects.

• Les matériaux importés demandent souvent une conversion : vérifier les maps et canaux.

• ProBuilder convient au blockout : il ne remplace pas une topologie finale optimisée.

• Le Terrain peut devenir lourd : contrôler résolution, végétation et distances.

• Les arbres et détails génèrent de nombreuses instances : profiler leur rendu.

• Les NavMeshes doivent être recalculés : une modification de niveau peut invalider la navigation.

• Les agents de tailles différentes nécessitent des réglages séparés : rayon, hauteur et pente changent.

• La navigation dynamique a un coût : éviter les mises à jour complètes trop fréquentes.

• PhysX n’est pas parfaitement déterministe entre plateformes : prudence pour les simulations réseau synchronisées.

• Box2D 3 améliore certains comportements : tester les projets migrés depuis l’ancienne physique 2D.

• Ne pas mélanger Rigidbody et Transform sans stratégie : les déplacements directs peuvent perturber la simulation.

• Utiliser FixedUpdate pour la physique : ne pas dépendre uniquement du framerate.

• Le timestep influence stabilité et coût : une fréquence élevée augmente les calculs.

• Continuous Collision Detection est plus coûteux : l’activer uniquement lorsque nécessaire.

• Mesh Collider dynamique est coûteux : préférer des formes simples ou convexes.

• Les collisions par layer doivent être limitées : réduire les paires inutiles.

• Les raycasts fréquents ont un coût : regrouper et filtrer les requêtes.

• La physique ne remplace pas une animation contrôlée : choisir le système selon le gameplay.

• Root Motion peut compliquer le réseau : décider où se trouve l’autorité du déplacement.

• Animator Controllers volumineux deviennent difficiles à maintenir : séparer les responsabilités.

• Les transitions doivent être contrôlées : trop de connexions créent des états imprévisibles.

• Animation Events dépendent des noms de méthodes : ils sont fragiles lors des refactorings.

• Timeline peut prendre le contrôle des mêmes propriétés que l’Animator : éviter les conflits.

• Cinemachine dépend de l’ordre et des priorités : documenter les caméras virtuelles.

• Animation Rigging ajoute une étape de calcul : mesurer le coût des contraintes.

• Le retargeting humanoïde n’est pas parfait : vérifier les proportions et orientations.

• Les blendshapes consomment de la mémoire : limiter les formes inutiles.

• L’audio compressé réduit la taille mais utilise du CPU : choisir les réglages selon la durée.

• Decompress On Load augmente la mémoire : éviter pour les longues musiques.

• Streaming sollicite le stockage : tester sur mobile et consoles.

• Un seul AudioListener doit généralement être actif : plusieurs listeners provoquent des erreurs.

• Le spatial audio dépend du plugin et de la plateforme : tester avec le casque ou système cible.

• FMOD et Wwise ajoutent une dépendance : synchroniser leurs versions avec Unity.

• UI Toolkit et uGUI sont différents : choisir selon le projet et l’expérience de l’équipe.

• UI Toolkit ne remplace pas toujours uGUI : certains workflows de jeu restent plus simples avec Canvas.

• uGUI peut générer des rebuilds coûteux : séparer les Canvas dynamiques et statiques.

• Layout Groups peuvent recalculer fréquemment : éviter les hiérarchies trop complexes.

• Les interfaces doivent s’adapter aux ratios d’écran : tester smartphones, tablettes et moniteurs ultralarges.

• Safe Areas mobiles : éviter les encoches et zones système.

• La navigation manette doit être testée : une interface souris n’est pas automatiquement utilisable au pad.

• TextMesh Pro nécessite des atlas de glyphes : prévoir les langues et caractères.

• Les polices possèdent leurs propres licences : vérifier l’embarquement dans le jeu.

• Les langues augmentent la taille des textes : prévoir davantage d’espace dans l’interface.

• Le pseudo-localization doit être utilisé tôt : il révèle les éléments trop courts ou non traduits.

• Les écritures de droite à gauche demandent une validation : les plugins et versions ne couvrent pas tous les cas de la même manière.

• Input System et ancien Input Manager coexistent : éviter une migration partielle non maîtrisée.

• Les noms de manettes varient : utiliser des actions abstraites plutôt que des touches codées en dur.

• Prévoir le rebinding : les utilisateurs doivent pouvoir modifier leurs commandes.

• Les périphériques peuvent être déconnectés : gérer leur changement à l’exécution.

• Le tactile ne se résume pas à une souris : adapter gestes, taille des boutons et précision.

• Les vibrations diffèrent selon les appareils : prévoir un réglage désactivable.

• L’accessibilité doit être conçue : une API de lecteur d’écran ne rend pas automatiquement le jeu accessible.

• Ajouter des sous-titres et réglages visuels : taille, contraste et vitesse doivent être contrôlables.

• Tester sans son : les informations importantes ne doivent pas dépendre uniquement de l’audio.

• Tester les daltonismes : ne pas utiliser uniquement la couleur pour transmettre une information.

• Platform Toolkit ne supprime pas les SDK constructeurs : il fournit une abstraction, pas une autorisation.

• Les consoles exigent une validation développeur : Unity Pro ne garantit pas l’accès.

• Les SDK consoles sont confidentiels : respecter les NDA et espaces de travail sécurisés.

• La certification peut prendre du temps : prévoir plusieurs soumissions.

• Les sauvegardes doivent respecter la plateforme : taille, quotas et profils varient.

• Les succès doivent être testés séparément : les identifiants et règles diffèrent.

• Les contrôleurs ne possèdent pas les mêmes boutons : adapter les glyphes.

• Apple exige un Mac pour plusieurs étapes : un PC Windows ne suffit pas à publier directement sur iOS.

• Android nécessite SDK, NDK et JDK compatibles : utiliser les versions fournies ou recommandées.

• Les règles des boutiques évoluent : API cible, confidentialité et facturation changent régulièrement.

• Les achats intégrés doivent être validés en sandbox : ne pas tester uniquement dans l’éditeur.

• Le Web impose des limites mémoire : une scène desktop ne fonctionne pas automatiquement dans un navigateur.

• Les builds Web peuvent être volumineux : compresser et charger progressivement.

• WebAssembly ne prend pas en charge toutes les API .NET : tester les bibliothèques externes.

• Le multithreading Web dépend du navigateur et des headers : configurer correctement le serveur.

• Les codecs vidéo Web varient : prévoir des formats compatibles.

• Les navigateurs mobiles imposent des restrictions audio : une interaction peut être nécessaire avant la lecture.

• Le stockage local Web peut être limité : ne pas supposer qu’il équivaut à un système de fichiers.

• Les applications mobiles peuvent être suspendues : sauvegarder l’état lors des interruptions.

• Les appareils bas de gamme doivent être ciblés tôt : ne pas optimiser uniquement à la fin.

• La température réduit les performances mobiles : tester des sessions longues.

• Le fill rate limite souvent les interfaces et particules : surveiller les transparences.

• La batterie est un critère de performance : réduire les calculs et la fréquence lorsque possible.

• XR exige une fréquence stable : les chutes de frames peuvent provoquer un inconfort.

• Tester directement sur le casque : l’éditeur ne reproduit pas la latence et l’ergonomie réelles.

• Prévoir plusieurs méthodes de locomotion : téléportation, déplacement continu et rotation configurable.

• Éviter les accélérations de caméra non contrôlées : elles augmentent le mal des transports.

• Les interactions de mains varient : tous les casques ne possèdent pas le même suivi.

• AR Foundation masque seulement une partie des différences : certaines fonctions restent propres à ARKit ou ARCore.

• La détection de plans dépend de l’environnement : lumière et texture influencent le suivi.

• Les ancres peuvent dériver : ne pas supposer une précision industrielle sans validation.

• Les données caméra sont sensibles : appliquer les règles de consentement et de confidentialité.

• Le multijoueur ne s’ajoute pas à la fin : l’architecture réseau doit être prévue dès le départ.

• Choisir l’autorité réseau : client, hôte ou serveur dédié changent la sécurité et le coût.

• Netcode for GameObjects n’est pas universel : certains projets préfèrent Mirror, FishNet, Photon ou une solution interne.

• Netcode for Entities demande ECS : il ne s’intègre pas comme un simple remplacement dans un projet MonoBehaviour.

• La prédiction est complexe : elle nécessite rollback, correction et interpolation.

• Tester la latence et la perte : une connexion locale parfaite masque les défauts.

• Relay n’est pas un serveur de gameplay : il transporte les connexions sans exécuter toute la logique autoritaire.

• Un host peut tricher : le modèle client-host n’est pas adapté à tous les jeux compétitifs.

• Host Migration possède des limites : tester les données réellement conservées.

• L’hébergement serveur coûte en continu : calculer le coût par joueur et par région.

• Les services multijoueur possèdent une facturation propre : vérifier les quotas gratuits et tarifs actuels.

• Prévoir la fermeture d’un service : documenter une solution de migration ou fonctionnement dégradé.

• Ne pas placer de secrets dans le client : un joueur peut inspecter le build.

• Valider les actions côté serveur : ne pas faire confiance aux valeurs envoyées par le client.

• Limiter les RPC : les appels fréquents augmentent bande passante et charge.

• Compresser et quantifier les données : synchroniser uniquement ce qui est nécessaire.

• Utiliser des identifiants stables : éviter de dépendre d’objets créés dans un ordre imprévisible.

• Protéger les API Web : utiliser authentification, quotas et validation.

• Cloud Save n’est pas une base générale illimitée : il stocke principalement de petites données de jeu.

• Cloud Code ajoute de la latence : ne pas appeler une fonction distante à chaque frame.

• Economy doit être contrôlée côté serveur : éviter les achats et monnaies modifiables par le client.

• Remote Config peut casser une expérience : valider les configurations avant publication.

• Séparer les environnements : ne pas tester directement avec les données de production.

• Analytics implique des données personnelles ou pseudonymes : informer les utilisateurs et respecter le consentement.

• Minimiser les événements collectés : ne pas envoyer de données inutiles.

• Prévoir la suppression des données : répondre aux droits RGPD et réglementations locales.

• Push Notifications nécessitent un consentement : ne pas harceler les utilisateurs.

• Les services Unity créent un verrouillage fournisseur : isoler leur API derrière une couche propre au projet.

• Les prix cloud sont variables : estimer le coût avec une croissance réaliste.

• Les quotas gratuits ne garantissent pas la gratuité à l’échelle : configurer des alertes budgétaires.

• Cloud Content Delivery nécessite un plan de versions : un ancien client doit recevoir des bundles compatibles.

• Addressables demande une discipline stricte : catalogues et groupes mal configurés provoquent des erreurs difficiles à diagnostiquer.

• Ne pas mélanger Resources et Addressables sans stratégie : éviter les duplications dans le build.

• Tester les contenus distants hors ligne : prévoir un cache ou message clair.

• Les catalogues doivent rester accessibles : une panne distante peut bloquer le chargement.

• Conserver une copie des bundles publiés : permettre le rollback.

• Unity Version Control n’est pas une sauvegarde unique : conserver des copies et politiques de restauration.

• Git exige les .meta : leur absence casse les GUID et références.

• Ne jamais régénérer volontairement tous les .meta : les scènes et prefabs perdraient leurs liens.

• Utiliser Force Text : faciliter les diffs et certaines fusions.

• Les scènes restent difficiles à fusionner : répartir les responsabilités et utiliser plusieurs scènes ou prefabs.

• Git LFS est utile pour les gros binaires : surveiller ses quotas et coûts.

• Verrouiller les fichiers non fusionnables : PSD, Blender, audio et certaines scènes nécessitent une coordination.

• Définir une convention de branches : éviter plusieurs versions divergentes des mêmes assets.

• Les builds doivent être reproductibles : fixer Unity, packages, SDK et variables.

• Build Automation dépend du cloud Unity : prévoir une solution locale ou alternative.

• Les minutes cloud sont limitées ou facturées : surveiller la consommation.

• Les machines macOS coûtent généralement plus cher : planifier les builds iOS.

• Les secrets de signature doivent être protégés : ne pas les stocker en clair dans le dépôt.

• Conserver les certificats et keystores : leur perte peut bloquer les mises à jour d’une application.

• Le Profiler ajoute parfois du coût : comparer Development et Release Builds.

• Deep Profiling est très intrusif : l’utiliser sur des captures courtes.

• Profiler dans l’éditeur n’égale pas le Player : mesurer sur l’appareil cible.

• Les performances de l’éditeur peuvent masquer celles du build : tester les deux.

• Le Garbage Collector provoque des pics : limiter les allocations par frame.

• Éviter LINQ dans les boucles critiques : il peut créer des allocations et coûts supplémentaires.

• Mettre en cache les références de composants : éviter des recherches répétées.

• Limiter les méthodes Update : centraliser ou désactiver les comportements inactifs.

• Utiliser le pooling : éviter de créer et détruire continuellement des objets.

• Les coroutines ne sont pas des threads : elles s’exécutent principalement sur le thread principal.

• Jobs exigent des données compatibles : les objets managés ne peuvent pas être utilisés librement.

• Burst n’accepte pas tout le C# : vérifier les types et API pris en charge.

• ECS augmente la complexité : ne l’utiliser que lorsqu’il résout un problème réel.

• Les conversions GameObject-Entity demandent une stratégie : définir la frontière entre authoring et runtime.

• Les systèmes hybrides peuvent devenir difficiles à déboguer : documenter les flux de données.

• Visual Scripting ne supprime pas la logique : un graphe volumineux peut être plus difficile à maintenir que du code.

• Versionner les graphes visuels : leurs diffs sont moins lisibles que ceux du C#.

• Créer des unités réutilisables : éviter la duplication de graphes.

• Tester le stripping IL2CPP : il peut supprimer des types accessibles uniquement par réflexion.

• Préserver les types sérialisés : utiliser les attributs et fichiers de liaison nécessaires.

• Les builds IL2CPP sont plus longs : prévoir le temps dans la CI.

• Les erreurs natives sont plus difficiles à lire : conserver les symboles de débogage.

• Les plugins natifs peuvent planter le Player : isoler et tester leurs appels.

• Le code provenant d’une IA doit être relu : vérifier API, version et coût.

• Unity AI utilise des crédits : surveiller la consommation et l’abonnement.

• Ne pas envoyer de code confidentiel sans vérification : lire les conditions de traitement des données.

• Les générations peuvent produire des licences incertaines : vérifier les droits sur les assets créés.

• Un agent peut modifier plusieurs fichiers : utiliser le contrôle de versions avant son intervention.

• L’IA ne connaît pas toujours la version du package : vérifier la documentation officielle.

• Les API Unity évoluent : un exemple trouvé en ligne peut viser une ancienne version.

• La documentation est répartie : Manual, Scripting API, package docs et services utilisent plusieurs sites.

• Les traductions automatiques peuvent être imprécises : consulter la version anglaise en cas de doute.

• Les tutoriels anciens restent visibles : vérifier leur date et la version de l’éditeur.

• Les exemples Asset Store ne représentent pas toujours les bonnes pratiques : auditer leur architecture.

• La communauté est immense mais hétérogène : comparer plusieurs sources avant une décision importante.

• Unity Learn est utile pour commencer : une production professionnelle demande davantage que les parcours débutants.

• Comparer avec Unreal Engine pour la 3D haut de gamme : son rendu, ses outils et son accès au code répondent à d’autres priorités.

• Comparer avec Godot pour le libre et la légèreté : il réduit la dépendance à un fournisseur.

• Comparer avec Stride pour C# open source : son écosystème reste nettement plus petit.

• Comparer avec GameMaker pour la 2D rapide : son workflow est plus spécialisé.

• Choisir Unity pour l’équilibre général : il excelle lorsque C#, le multiplateforme, le mobile et l’écosystème constituent des critères centraux.