Assemblage et mise à disposition d'un jeu fini sur Unity (Android) avec correction des bugs critiques, profilage et publication sur Google Play

Situation initiale : il existe un jeu mobile (casual 2D runner) presque terminé sur Unity 2022.3 LTS. Le projet a été hérité de l'équipe précédente, est désormais compilé dans Editor, mais est instable sur les vrais appareils Android. Le jeu comporte déjà des niveaux, une interface utilisateur, une localisation RU-EN, des analyses Firebase, des réseaux publicitaires (Unity Ads + AdMob via la médiation), des achats dans le jeu via Unity IAP et une sauvegarde de la progression. Il est nécessaire d'amener le projet à un état où il peut être publié de manière fiable sur Google Play.

Environnement technique et domaine : Unity 2022.3 LTS, URP 2D, C#, Addressables (partiellement), Android API 33-34, Gradle, IL2CPP, Firebase SDK, Google Play Billing v5+, Git. La construction est effectuée via Android Studio/Gradle, signée via la clé de téléchargement. Le projet est stocké dans un dépôt Git privé, nous vous en donnerons accès.

Ce qu'il faut faire (étapes) :
1) Audit du projet et reproduction des problèmes sur 2-3 appareils cibles (au moins un appareil faible avec 3-4 Go de RAM). Faites une courte liste des causes et un plan de correction.
2) Correction des crashs et des blocages : selon les journaux logcat/Unity/Android (généralement NullReference dans le flux de l'interface utilisateur, problèmes avec le cycle de vie des annonces, erreurs lors de la restauration des achats, ANR rares lors du chargement d'une scène).
3) Remettre en ordre de marche la monétisation : publicités interstitielles, récompenses, bannières - sans bloquer le contrôle et sans fuite des abonnements aux événements. IAP - traitement correct des achats et des restaurations, pas de frais en double.
4) Optimisation des performances : réduisez les chutes de FPS et les pics de mémoire lors du changement de scènes/niveaux. Utilisez Unity Profiler/Memory Profiler, éliminez les allocations explicites dans la mise à jour, la reconstruction lourde de Canvas, l'instanciation/la destruction inutile. Si nécessaire, configurez correctement les adressables ou remplacez les zones problématiques par un chargement plus simple des ressources, mais sans réécrire la moitié du projet.
5) Préparez une version de version : configurez les paramètres du lecteur pour Google Play (IL2CPP, architectures cibles, SDK min/target), corrigez les dépendances Gradle et les conflits AndroidX/Jetifier, vérifiez l'exactitude de l'autorisation. Construisez AAB, vérifiez l'installation/la mise à jour par rapport à la version précédente.
6) Contrôle de qualité final minimum : liste de contrôle pour terminer 10 à 15 minutes de jeu, vérifier les publicités, les achats, les sauvegardes, les changements de langue, le comportement lors du passage en arrière-plan et du retour.

Résultat spécifique : un projet Unity soumis dans le référentiel avec des correctifs, une release AAB pour Google Play et un court fichier RELEASE_NOTES.md décrivant les modifications apportées et les limitations connues.

Restrictions : vous ne pouvez pas modifier la conception du jeu, ajouter de nouveaux niveaux ou créer de nouvelles illustrations. Seules les modifications de code, les paramètres, les intégrations SDK, les optimisations et les correctifs sont autorisés. Vous ne pouvez pas connecter d’actifs tiers payants sans approbation. Toutes les modifications doivent prendre la forme de commits dans Git avec des messages clairs.

Critères d'acceptation mesurables :
- La version release (AAB) est installée sur Android 10-14 et ne plante pas au démarrage, dans les 20 minutes de lecture continue - 0 crash.
- Pas d'ANR lors du chargement des niveaux et du retour de l'arrière-plan (vérifier au moins 10 cycles de réduction-expansion).
- Publicité récompensée : affichage par bouton, délivrance correcte d'une récompense, pas plus d'1 impression infructueuse sur 10 tentatives avec une connexion Internet stable.
- Interstitiel : affichage à des points spécifiés, après la fermeture, le contrôle revient, l'interface utilisateur ne se fige pas.
- IAP : l'achat d'un produit test réussit, au redémarrage, l'achat est restauré, les frais ne sont pas dupliqués.
- Le FPS moyen sur un appareil faible n'est pas inférieur à 45 en gameplay (à l'exclusion des 3 premières secondes après le chargement de la scène), pas de gel régulier supérieur à 200 ms (estimé par Unity Profiler/Android frame timing).

Accès et matériel : nous fournirons un référentiel, des clés de test Firebase/AdMob/Unity Ads, une liste des appareils cibles et les étapes actuelles pour reproduire les problèmes. Il faudra maintenir des rapports intermédiaires courts sur les scènes.