Vous reprenez un projet Unity ? Que vérifier avant de repartir de zéro.

01

Préserver le projet repris

Conservez l’historique du dépôt, le dernier build fonctionnel et les notes d’installation. Relevez la version de Unity Editor et la plateforme cible avant d’ouvrir le projet dans une autre version. Préservez l’original et menez l’examen sur une copie de travail séparée.

Le premier livrable utile est un build reproductible : une autre machine peut suivre les étapes documentées et produire une application qui fonctionne. En cas d’échec, relevez le blocage exact et la dépendance manquante. « Ne compile pas » est un constat à examiner, pas une preuve suffisante pour réécrire.

Unity recommande de sauvegarder avant les mises à niveau et d’évaluer si leurs bénéfices justifient l’effort. J’applique cette même discipline avant de modifier la base d’un projet repris.

02

Vérifiez les outils, services et comptes nécessaires au projet

Je vérifie la version de l’éditeur, le pipeline de rendu, les paquets Unity, les assets de l’Asset Store, les plugins natifs et les SDK externes. La revue couvre aussi les outils de build, les environnements backend, les accès de signature et la maîtrise des comptes nécessaires.

Pour chaque dépendance critique, établissez sa version, sa disponibilité, sa compatibilité et son responsable. Un plugin maintenu par des modifications locales non documentées exige un traitement différent d’un plugin installable sans modification.

Conservez le manifeste des paquets et le fichier de verrouillage avec le projet. Le fichier de verrouillage Unity consigne les dépendances résolues et doit être versionné pour reproduire le même ensemble de paquets sur plusieurs machines. Un service indisponible ou une source manquante peut déterminer le périmètre de reprise davantage que l’âge du code C#.

03

Testez les performances sur les appareils prévus

« Cela tourne bien sur mon ordinateur » ne démontre pas que le produit est prêt pour le mobile ou un casque. Je choisis du matériel représentatif et des scénarios reproductibles : démarrage, moment de gameplay chargé, transition de scène et session plus longue si pertinent.

Je recherche la pression CPU ou GPU, la croissance mémoire, les retards de chargement et les allocations récurrentes, puis je relie les constats à un problème visible par le joueur. Consignez l’appareil, la version du build, les paramètres et les étapes pour rendre les comparaisons pertinentes.

Unity recommande de profiler sur la plateforme visée. Le mode Play de l’éditeur partage ses ressources avec l’éditeur et ne reflète pas fidèlement les performances sur appareil. Les builds de développement permettent la connexion à Unity Profiler. Le profilage guide le diagnostic ; je vérifie aussi la correction proposée dans la configuration de publication prévue avant de considérer le problème comme résolu.

04

Vérifiez la progression sauvegardée, les achats et les outils d’analyse

Un lancement réussi n’est qu’un aspect de la compatibilité. Les joueurs existants peuvent avoir une progression sauvegardée, des contenus débloqués, des achats ou un état côté serveur.

Je retrace l’emplacement de ces données et teste des anciennes sauvegardes représentatives avec les changements proposés. Vérifiez les chargements interrompus, les données manquantes et les échecs de migration. Convenez de ce qui doit survivre, de ce qui peut changer et de la récupération avant de modifier les formats ou les identifiants.

Suivez ensuite un parcours de progression complet : démarrer, gagner ou débloquer quelque chose, sauvegarder, redémarrer et continuer. Vérifiez les événements d’analyse associés, leur sens et leur contexte de version. Si le suivi historique n’est pas fiable, la prochaine publication peut établir une référence de mesure ; elle ne prouve pas automatiquement une amélioration de la rétention.

05

Testez la principale inconnue avec un petit exemple fonctionnel

Avant d’estimer une modification importante du code ou une reconstruction, je conviens d’un petit test : la question à laquelle il doit répondre, la limite de travail et les critères de réussite.

Par exemple : un niveau représentatif peut-il charger une sauvegarde existante, accomplir une boucle de jeu, envoyer les événements attendus et respecter le budget de performance convenu sur le téléphone cible ?

Le test doit inclure les systèmes les plus susceptibles d’empêcher la sortie. Reconstruire un menu isolé renseigne peu sur la progression du joueur ou les services de la plateforme. Fixez la limite de travail à l’avance et notez ce que le test a établi, ce qui a échoué et ce qui reste inconnu.

06

Choisissez la prochaine étape à partir des constats.

La recommandation doit expliquer ce que l’examen a révélé, pourquoi cela compte et quel travail effectuer ensuite.

Terminer

Le cœur du jeu fonctionne et le travail restant peut être clairement listé et estimé.

Prochaine étape : Corrigez les problèmes qui empêchent la sortie et testez les fonctions convenues.

Refactoriser

Certains systèmes provoquent régulièrement des défaillances ou empêchent des changements nécessaires.

Prochaine étape : Améliorez une partie du code et vérifiez que les fonctions qui lui sont liées fonctionnent toujours.

Reconstruire

Le code existant ne peut pas raisonnablement prendre en charge les fonctions requises, même après l’examen de solutions de réparation réalistes.

Prochaine étape : Testez la solution de remplacement et prévoyez le transfert des données existantes des joueurs.

Un petit examen payant du projet peut vous aider à décider de la suite. Avant de commencer, nous convenons de la question, des accès nécessaires, de la limite de travail et des éléments à remettre. Vous recevez une version fonctionnelle ou une explication de ce qui l’empêche de fonctionner, une liste de constats par priorité et une proposition de prochaine étape avec des hypothèses clairement énoncées.

Pour un exemple concret de gameplay, sauvegardes et progression interconnectés, découvrez Polar Station Survival— un jeu avec de nombreux systèmes reliés, dont j’étais le seul développeur Unity.