L'éditeur fonctionne, la compilation échoue : tracez les erreurs de console vers les références de scripts et de scènes avec Unity MCP

Les fils de discussion intitulés « Unity fonctionne dans l’éditeur, échoue sur l’appareil / la compilation » se ressemblent : Play fonctionne, puis une compilation Player / appareil passe au rouge, plante, devient noire ou lève NullReferenceException à l’entrée de la scène. Le moteur est rarement « cassé »—le chemin de l’éditeur a masqué des lacunes de références et de plateformes : scène absente de la liste de build, champs sérialisés None sur le disque, sensibilité de la casse des chemins, ou API UnityEditor fuitées dans un assembly runtime jusqu’au moment de l’empaquetage.

Ce post a trois axes (comme le titre) :

1. Console / pile → objets script et scène
2. Vérifier les Build Settings, les scripts manquants, les références sérialisées
3. Diagnostic en lecture seule dans Cursor via Unity MCP → correctif minimal après confirmation

Pas de tutoriel d’installation de plugin, pas de guide complet de publication sur le store. L’élimination IL2CPP et les plugins natifs restent en annexe.

Connexes :

• Installation de Unity MCP
• Unity MCP avec Claude Code et Cursor
• Connecter un HUD AI Studio aux événements de santé (câblage correct ; ce post est « comment trouver la panne »)

D’abord : quelle couche a échoué ?

A. Fenêtre de build rouge (échec de compilation / d'empaquetage)
        ↓
B. La compilation réussit ; l'appareil meurt ou devient noir au lancement
        ↓
C. Le jeu démarre ; une scène ou une fonctionnalité explose à l'exécution

Ce que vous voyez	Couche	Vérifiez d’abord ici
Échec de build, error CS… / type introuvable	A	Assembly runtime référençant UnityEditor, mauvais #if, asmdef
NRE / MissingReference sur la scène de démarrage	B/C	Scène dans la liste de build, script manquant, None dans l’Inspector
Échec uniquement sur Resources.Load / scène additive	C	Casse du chemin, asset dans le pack, scène réellement chargée

Unity MCP est le plus efficace sur un éditeur ouvert : Console, Hiérarchie, champs de composants. Les piles logcat / Xcode de l’appareil doivent être collées dans Cursor—ou livrez un Development Build et reproduisez avec la même scène de démarrage dans l’éditeur quand c’est possible.

Boucle de dépannage (manuel + MCP)

Ne sautez pas l’étape manuelle et ne demandez pas à l’IA de réécrire le Player.

Étape 0 : Figez la scène à la main (~2 min)

Avant Cursor :

1. Notez la version Unity et la cible (ex. Android / IL2CPP)
2. Effacez Window → General → Console, puis faites un Build ou un Development Build une fois
3. Copiez la première erreur pertinente (avec la pile)—pas un mur d’avertissements
4. Ouvrez File → Build Settings : la scène suspecte est-elle cochée ? L’index 0 est-il la scène de démarrage ?
5. Si vous avez modifié une instance de Prefab : avez-vous appliqué ? Les overrides non appliqués n’atteignent souvent jamais l’asset sur disque que vous pensez avoir livré

Étape 1 : Triage de la console en lecture seule via MCP

Résumez les erreurs de console liées à ce build / dernier Play (ignorez les Info).
Classez-les en : échec de compilation / script manquant / NullReference / chargement de ressource.
Listez le chemin du script, la ligne, le nom du GameObject par erreur quand présent.
Ne modifiez aucun asset.

Étape 2 : « Trio de références » manuel + MCP

Pour les NRE d’exécution (B/C), sélectionnez l’objet de la pile dans l’éditeur et recoupez avec MCP :

Manuel	Invite MCP
Liste des Build Settings (capture d’écran ou dictée)	« Liste les chemins de scènes des Build Settings et les drapeaux activés ; nomme la scène de démarrage. »
Inspector : script manquant / références None	« Dans la scène <Nom>, liste les scripts manquants ; vérifie les champs sérialisés sur <Objet>.<Composant> pour None. Tableau uniquement. Ne modifie pas. »
Asset Prefab vs instance de scène	« <X> est-il un asset Prefab ou une instance de scène ? Y a-t-il des overrides non appliqués si visibles ? Signale uniquement. »

Règle : Les packs utilisent les scènes/Prefabs sur disque. Les remplissages temporaires OnValidate qui « semblent corrects » dans l’éditeur ne comptent pas—faites confiance aux valeurs sérialisées de MCP/Inspector.

Étape 3 : Modèle de diagnostic, puis confirmation

[Contraintes]
- Diagnostique et propose un plan minimal ; attends mon accord avant de modifier
- Ne simule pas un correctif avec un Find massif de GameObject
- Touche uniquement aux scripts/Prefabs/scènes liés à cette erreur

[Scène]
- Play dans l'éditeur : OK / cassé (véridique)
- Plateforme / build : …
- Scène de démarrage des Build Settings : …
- Console / pile appareil (brute) :
<collez>

[Réponse]
1. Couche A / B / C
2. 1–2 causes racines principales (pas dans le build / réf None / script manquant / casse / API éditeur…)
3. Objets et noms de champs que je dois vérifier
4. Étapes de correctif minimal (ne les exécutez pas encore)

Étape 4 : Écriture minimale + revérification

Applique le correctif minimal confirmé : uniquement <objet.champ> ou les quelques lignes dans <chemin du script> pour cette erreur.
Enregistre la scène/Prefab.
Puis revérification en lecture seule : les champs sont-ils toujours None ? La même erreur est-elle toujours dans la Console ?

Exemple concret : pile → champ

Journal Player/appareil synthétique mais réaliste (remplacez les chemins par ceux de votre projet).

Journal

NullReferenceException: Object reference not set to an instance of an object
  at HudHealthView.HandleHealthChanged (System.Single current, System.Single max) [0x00000] in Assets/Scripts/UI/HudHealthView.cs:42
  at PlayerHealth.TakeDamage (System.Single amount) [0x00000] in Assets/Scripts/Combat/PlayerHealth.cs:28
  at DebugDealDamage.Update () [0x00000] in Assets/Scripts/Debug/DebugDealDamage.cs:15

Couche

• A atteint Update → pas A (compilation OK)
• Meurt sur les dégâts → C (exécution) ; suspectez les références UI, pas « réécrire le combat »

Manuel

1. La scène du HUD est-elle dans les Build Settings ?
2. Sélectionnez l’objet HudHealthView ; healthFill / playerHealth sont-ils None ?
3. Modifications du Prefab : appliquées ?

MCP

Lecture seule : ouvre la scène qui contient le HUD.
1. Trouve les objets avec HudHealthView
2. Signale si healthFill, playerHealth (et les pairs) sont None / manquants
3. Ne modifie pas
Si None : le plan minimal est de réassigner les références et d'enregistrer—pas de changer TakeDamage.

Correctif minimal (après accord)

• Glissez l’Image HUD_HealthFill → healthFill ; le PlayerHealth du joueur → playerHealth
• Enregistrez ; Development Build ; subissez à nouveau des dégâts

« Correctif » mauvais (à ne pas faire)

// Anti-pattern : Find masque None — casse toujours au renommage / chargement additif
healthFill = GameObject.Find("HUD_HealthFill").GetComponent<Image>();

Câblage correct : HUD → événements de santé. Ici : épinglez le champ depuis la pile, puis reconnectez.

Matrice des symptômes (axe)

Symptôme 1 : Build rouge — type introuvable / UnityEditor

Cause probable	Manuel	MCP
Script runtime utilise une API éditeur	Le fichier est-il hors de Editor/ ?	« Cherche UnityEditor. hors des dossiers Editor ; liste uniquement les chemins. »
#if inversé, types manquants dans le Player	Vérifiez que UNITY_EDITOR encapsule	« Quels types existent sous Editor vs Player pour ce fichier ? »
Lacune asmdef	Ouvrez le .asmdef en échec	« Liste les références asmdef ; laquelle manque ? »

Anti-pattern (API éditeur dans un assembly runtime → échec du build Player) :

using UnityEngine;
using UnityEditor; // Échoue le build si ce n'est pas un assembly Editor

public class BadBake : MonoBehaviour
{
    [MenuItem("Tools/Bad")] // dépendance supplémentaire à UnityEditor
    static void Run() { }
}

Correctif A : fichier entier sous Editor/

Assets/Scripts/Editor/BakeTools.cs   ← compilation éditeur uniquement

Correctif B : isolez dans le fichier (seulement si vous devez partager un fichier)

using UnityEngine;

public class RuntimeSafe : MonoBehaviour
{
    public void DoGameplay() { /* visible pour le Player */ }

#if UNITY_EDITOR
    [ContextMenu("Debug/Fill Refs")]
    void EditorOnlyFill()
    {
        // Éditeur uniquement — ne traitez pas cela comme des données runtime empaquetées depuis Awake
    }
#endif
}

Encore plus propre : scripts éditeur uniquement + asmdef pour que les assemblys runtime ne traînent jamais de références éditeur.

Symptôme 2 : NRE appareil à l’entrée de scène ; Play dans l’éditeur « semble correct »

Vérifiez dans l’ordre—pas de méga-réécriture en parallèle :

1. Scène absente des Build Settings ou mauvaise scène de démarrage
2. Script manquant / None sérialisé (y compris Prefab non appliqué)
3. Scène additive non chargée avant Find / accès
4. Casse du chemin Resources.Load (l’éditeur macOS est souvent insensible à la casse ; Android ne l’est pas)

1. Signale les scènes des Build Settings, les drapeaux activés, l'index de démarrage
2. Liste tous les scripts manquants dans la scène <X>
3. Vérifie les références publiques sur GameManager / Player / HUD le long du chemin de démarrage pour None
Signale uniquement ; ne modifie pas.

Dans l’éditeur	Dans le pack	Cause typique
Les références semblent définies	None à l’exécution	Overrides d’instance non appliqués ; mauvais fichier de scène modifié
Find fonctionne	Null sur l’appareil	Objet dans une scène non chargée ; nom différent
Resources.Load fonctionne	Null sur l’appareil	Casse du chemin ; asset pas sous Resources/

// Sur disque : Assets/Resources/UI/HealthBar.png
// Échoue souvent sur Android (casse différente) :
Resources.Load<Sprite>("ui/healthbar");
// Correspond au chemin sous Resources, ex. :
Resources.Load<Sprite>("UI/HealthBar");

Cherche les chaînes de chemin Resources.Load / Addressables.LoadAssetAsync ;
construis un tableau sensible à la casse vs les chemins relatifs réels. Ne modifie pas le code pour l'instant.

Symptôme 3 : Console inondée de scripts manquants

Scanne la scène <X> et le Prefab <chemin> :
Liste les chemins de GameObject avec script manquant.
Par élément : suggère de rattacher le script d'origine ou de supprimer le composant vide (d'après le nom/GUID restant si visible).
Ne supprime pas en masse automatiquement.

Manuel : confirmez que le fichier de script existe toujours et que l’asmdef/GUID n’a pas cassé ; confirmez un par un avant de supprimer les vides.

Liste de contrôle d’acceptation

1. Les erreurs correspondantes ont disparu de la Console
2. Le Play dans l’éditeur parcourt le même chemin en échec (entrer dans le niveau, subir des dégâts, ouvrir l’UI…)
3. Un Development Build vers la cible (ou le Player local)
4. Revérification en lecture seule MCP : les champs suspects ne sont plus None / manquants
5. Le diff Git ne montre que le petit changement attendu de scène/Prefab/script—pas de refactor au passage

Revérification en lecture seule : y a-t-il des None ou scripts manquants sur <liste d'objets> ? Liste les exceptions. Ne modifie pas.

Lignes rouges des invites

À ne pas faire	À faire
« Fais juste marcher Play »	Couche A/B/C + épingle le champ depuis la pile
Find massif au lieu de références	Corrige les champs sérialisés ou l’injection explicite
Réordonner les Build Settings sans demande	Signale la liste actuelle et la scène de démarrage d’abord
« Il y a un NRE »	Colle les 20–40 premières lignes de pile

Limites du produit

• Unity MCP : Console éditeur, Hiérarchie, scripts, références—l’axe de cet article.
• AI Studio : structure UI dans le moteur ; reconnectez après ré-export selon le post de câblage—ne faites pas de Find UI depuis le gameplay.
• Certificats, stores, ROM OEM : collez le texte du journal dans Cursor pour de l’aide à la lecture ; hors de la portée de modification de scène MCP.

Annexe : courants mais hors axe

Éliminez d’abord l’axe de cet article :

Symptôme	Direction
Development OK, Release meurt	Managed Stripping / link.xml ; MCP : « Devine les types éliminés depuis la pile de crash ; propose link.xml ; n’écris pas encore de fichiers. »
Crash natif Android (non géré)	.so / permissions / Gradle ; collez logcat pour lecture
API Unity hors thread principal	Vérifiez que les callbacks asynchrones reviennent sur le thread principal

Ne fusionnez pas l’élimination et les scripts manquants en une « grosse réécriture ».

Résumé

1. Éditeur OK / pack cassé → traitez d’abord références / scènes dans le build / chemins / API éditeur
2. Gel manuel des Build Settings + première erreur, puis triage MCP en lecture seule
3. Pile → ligne de script → champ de composant ; reconnectez ou supprimez les composants vides après confirmation
4. Pas de Find ou de réécritures de gameplay comme faux correctifs
5. Acceptez avec un Development Build + revérification en lecture seule

Exécutez « geler → couche → trio de références → épinglez le champ comme dans l’exemple » et la plupart des bugs de références appareil se réduisent à un petit diff vérifiable.