Un projet commencé en 2021, repris aujourd’hui : ce qui a changé, ce que nous corrigeons encore, et la direction du développement
Medieval Minefield a vu le jour en 2021 comme un projet volontairement simple mais sérieux : reprendre la logique du démineur classique, l’adapter au mobile, et l’habiller d’une interface à thème médiéval, avec des règles claires, des parties courtes et un rythme adapté aux sessions rapides sur smartphone.
Le jeu est resté publié, mais le développement a connu une pause. Entre-temps, Android, Unity et les exigences de Google Play ont beaucoup évolué. Un projet ancien ne devient pas seulement « daté » : il devient fragile. Il suffit d’un SDK obsolète ou d’une dépendance non maintenue pour provoquer des problèmes de build ou dégrader l’expérience utilisateur.
Ces derniers mois, le développement a été repris. Il ne s’agit pas d’un reboot, mais d’un travail de remise à niveau : consolider les bases, corriger les bugs, moderniser certains systèmes, tout en conservant la simplicité du gameplay d’origine.
👉 L’évolution du projet est visible directement ici (version toujours à jour) :
https://play.google.com/store/apps/details?id=com.Develop4fun.MedievalMinefield
Ce que représente réellement l’Update 1.4
L’Update 1.4 a marqué une étape importante, car elle introduit plusieurs améliorations qui changent l’expérience au quotidien, en particulier sur mobile, où les erreurs involontaires sont plus fréquentes et où les joueurs attendent une progression moins punitive.
Les axes principaux de cette mise à jour ont été : équité, qualité de l’interface, rythme des parties et persistance des données.
1) First Click Safe
La première case révélée n’est jamais une mine.
C’est un détail en apparence, mais sur mobile il change beaucoup de choses : il élimine les parties qui se terminent immédiatement sans laisser place au raisonnement, et rend le démarrage plus agréable, surtout pour les joueurs qui lancent le jeu pour quelques minutes.
2) Lives System et Hint System
Un système simple de vies persistantes a été ajouté (via PlayerPrefs).
Ces vies peuvent être utilisées de deux façons :
- comme indices, pour révéler une case sûre lorsqu’un joueur est bloqué ;
- comme ressource pour le système de seconde chance (revive).
Ce système n’altère pas la logique du démineur, mais il réduit les parties gâchées par une erreur de manipulation ou un tap imprécis.
3) Revive System (seconde chance)
Lorsqu’une mine est déclenchée, le joueur peut choisir de :
- utiliser une vie,
- regarder une publicité récompensée (si disponible),
- abandonner et terminer la partie de manière classique.
Le revive est limité à une seule fois par partie, afin de conserver une vraie notion de risque et d’éviter un gameplay sans conséquence.
4) Statistiques locales
L’Update 1.4 a également introduit un système de statistiques plus complet : parties jouées, victoires, séries, meilleurs temps, temps total de jeu, avec un suivi par niveau de difficulté (Easy / Medium / Hard).
Il ne s’agit pas d’un classement global, mais d’un suivi local. L’objectif est double : donner un retour clair aux joueurs qui souhaitent progresser, et nous permettre d’évaluer l’équilibrage réel des niveaux.
5) Refonte du système de panels UI
Une part importante du travail a été faite « sous le capot ».
Les panels UI (victoire, défaite, options, revive) ont été unifiés via un système commun de gestion (CanvasGroup, animations optionnelles), avec un comportement plus fiable après les changements de scène.
Ce type de refactor est peu visible dans une vidéo, mais il est essentiel pour réduire les bugs intermittents, notamment lors des transitions rapides ou de l’ouverture/fermeture successive des menus.
Architecture : pourquoi les managers doivent être des objets racine
En Unity, la gestion des singletons et des DontDestroyOnLoad est une source fréquente de problèmes. Medieval Minefield repose aujourd’hui sur plusieurs managers (GameManager, AudioManager, AdsManager, StatsManager, InputBlocker, LevelLoader), et leur position dans la hiérarchie n’est pas un détail.
Tous les managers doivent être des GameObjects racine distincts dans la scène initiale (MainMenu), et non des enfants les uns des autres.
La raison est simple : lorsqu’un singleton est enfant d’un autre objet persistant, l’ordre d’initialisation, de destruction et de recréation devient imprévisible, ce qui entraîne des comportements instables (audio dupliqué, références perdues, callbacks manquants).
La règle adoptée est claire : objets racine séparés, persistance maîtrisée, et cycle de vie prévisible.
Android, Unity 6 LTS et la contrainte du Target SDK
La reprise du projet est aussi liée aux exigences de Google Play.
Aujourd’hui, Medieval Minefield utilise :
- Unity 6 LTS (6000.3.5f2)
- IL2CPP
- Target SDK 36 (Android 14)
- Min SDK 23 (avec des réglages plus conservateurs pour certaines builds AAB)
Mettre à jour ces paramètres ne se limite pas à changer des numéros. Cela implique souvent de supprimer des SDK obsolètes, d’effectuer des clean builds, de vérifier la pipeline Gradle, et de s’assurer qu’aucune dépendance ancienne ne déclenche d’alertes dans la Play Console.
Les systèmes publicitaires font également partie de cet équilibre : le projet utilise Gley Mobile Ads avec Unity Ads, ce qui nécessite des vérifications régulières pour garantir un comportement correct sur appareils réels.
« Il reste encore quelques problèmes » : ce que cela signifie concrètement
Lorsque nous parlons de problèmes encore présents, il s’agit principalement de :
- petits bugs UI liés à la récupération des références après certains chargements de scène ;
- comportements variables selon les appareils (touch, scaling, performance) ;
- cas limites du gameplay (restart rapide, reset, gestion du timer et des inputs) ;
- disponibilité et callbacks des publicités interstitielles ou récompensées.
L’important est que le développement a repris avec une ligne claire : chaque mise à jour doit réduire l’instabilité, pas simplement ajouter des fonctionnalités.
Situation actuelle et suite du développement
Après la 1.4, l’Update 1.5 s’est concentrée sur l’audio et les performances : gestion plus naturelle du volume (courbe logarithmique), état mute persistant, redémarrage plus rapide sans rechargement de scène, et corrections UI supplémentaires.
La logique reste la même : des évolutions progressives, mais régulières.
La roadmap actuelle inclut notamment :
- undo limité,
- power-ups mesurés (révélation de case, suppression de mine),
- défis quotidiens,
- feedback haptique,
- No-Guess Mode (grilles toujours résolvables).
Ces éléments n’ont de sens que sur une base stable, et seront intégrés progressivement.
Liens utiles
Google Play (version actuelle) :
https://play.google.com/store/apps/details?id=com.Develop4fun.MedievalMinefield
Support : studio@itamde.com
Conclusion
Medieval Minefield est un projet qui a connu une première vie en 2021 et qui entre aujourd’hui dans une phase plus mature et plus technique. Publier sur Android implique désormais maintenance, conformité, refactorisation et stabilité sur la durée.
Si vous redécouvrez le jeu aujourd’hui, l’idée est simple : le développement est actif, quelques imperfections peuvent encore apparaître, et l’objectif est d’améliorer progressivement l’ensemble sans dénaturer le gameplay original.
0 commentaires