Un progetto iniziato nel 2021, ripreso oggi: cosa è cambiato, cosa stiamo sistemando, e dove stiamo andando
Medieval Minefield è nato nel 2021 come esperimento “serio ma piccolo”: prendere la logica del campo minato classico, spostarla su mobile, e vestirla con una UI a tema medievale, con regole chiare, tempi rapidi, e un ritmo da partita breve. Il progetto è rimasto pubblicato, ma per un periodo è stato fermo; nel frattempo Android, Unity e soprattutto le richieste di Google Play sono cambiate parecchio, e un gioco “vecchio” smette di essere soltanto vecchio: diventa fragile, perché basta un SDK obsoleto o una libreria non più compatibile per far saltare la build o degradare l’esperienza.
Negli ultimi mesi abbiamo ripreso lo sviluppo. Questa ripresa non è un “reboot”, è un lavoro di manutenzione e ricostruzione: riportare il progetto su basi solide, correggere bug, modernizzare alcuni sistemi, e farlo senza perdere la semplicità del gameplay.
👉 Puoi vedere l’evoluzione direttamente qui (versione sempre aggiornata):
https://play.google.com/store/apps/details?id=com.Develop4fun.MedievalMinefield
Cosa significa “Update 1.4” in pratica
Update 1.4 è stato un passaggio importante perché ha introdotto diversi miglioramenti che cambiano l’esperienza quotidiana, soprattutto su mobile, dove l’errore involontario è più frequente e dove molti giocatori vogliono un percorso di apprendimento meno punitivo.
Le parole chiave della 1.4 sono state: equità, qualità della UI, ritmo delle partite, persistenza.
1) First Click Safe
La prima cella cliccata non è mai una mina.
Sembra banale, ma su mobile fa una differenza enorme: elimina le partite “finite subito”, quelle che non dipendono da ragionamento o attenzione, e rende l’avvio più pulito, soprattutto per i giocatori che aprono il gioco per 2–3 minuti.
2) Lives System + Hint System
Abbiamo introdotto un piccolo sistema di vite persistenti (PlayerPrefs): le vite si possono usare in due modi.
- come hint, per rivelare una cella sicura, utile quando il giocatore è bloccato o quando l’errore sarebbe casuale;
- come “risorsa” per il revive (vedi sotto).
È un sistema semplice, ma aggiunge un livello di gestione leggera: non cambia la logica del campo minato, però riduce le partite “rotte” per un attimo di distrazione o per un input errato.
3) Revive System (seconda possibilità)
Quando colpisci una mina, puoi scegliere se:
- usare una vita,
- guardare un rewarded ad (se disponibile),
- rinunciare e chiudere la partita come game over classico.
Il revive è limitato a uno per partita, per non trasformare il gioco in un loop infinito e per mantenere la sensazione di rischio.
4) Stats e tracciamento locale
In 1.4 è arrivato anche un tracciamento più completo delle statistiche: partite giocate, vittorie, streak, best time, tempo totale, e dati per difficoltà (Easy/Medium/Hard). Non è una leaderboard globale, è una base locale: serve a dare un feedback chiaro a chi vuole migliorare, e serve anche a noi per verificare che le difficoltà “tengano” e non siano squilibrate.
5) Refactor della UI e dei panel
Una parte consistente del lavoro su 1.4 è stata dietro le quinte: i panel UI (win/lose/options/revive) sono stati uniformati con un sistema unificato di show/hide, con CanvasGroup e (quando presente) Animator, e soprattutto con un comportamento più robusto dopo scene load.
Questo tipo di refactor è poco “visibile” in video, ma è quello che riduce bug strani e disallineamenti grafici, specie quando apri/chiudi panel in sequenza, o quando il gioco deve recuperare riferimenti UI dopo un reload.
Architettura: perché abbiamo insistito sui manager “root”
Una cosa che nel tempo crea davvero problemi, in Unity, è la gestione dei singleton e dei DontDestroyOnLoad. Medieval Minefield oggi si appoggia su diversi manager (GameManager, AudioManager, AdsManager, StatsManager, InputBlocker, LevelLoader) e la loro posizione in gerarchia non è un dettaglio estetico: influenza ordine di inizializzazione, scene load, e reference validation.
Per questo nel progetto i manager devono essere GameObject root separati nella scena di partenza (MainMenu), e non figli uno dell’altro.
Motivo pratico: quando un singleton viene distrutto/ricreato o quando un oggetto “figlio” viene trascinato via insieme a un altro, l’ordine di Awake/Start e la gestione del lifecycle diventano imprevedibili; il classico caso è l’AudioManager figlio di GameManager, che sembra funzionare finché non fai refactor o non cambi scene order, e poi inizia a duplicarsi o a perdere reference.
La regola: root separati, tutti persistenti, e comportamento controllabile.
Android, Unity 6 LTS e “sopravvivere” al Target SDK
Un altro motivo reale per riprendere il progetto è la compatibilità con Google Play.
Oggi Medieval Minefield è su:
- Unity 6 LTS (6000.3.5f2)
- IL2CPP
- Target SDK 36 (Android 14)
- Min SDK 23 (con indicazioni più “conservative” per alcune build AAB: 25)
Questo lavoro non è “solo aggiornare un numero”: spesso significa togliere SDK obsoleti, rifare clean build, controllare manifest e gradle pipeline, e soprattutto non lasciare dipendenze vecchie che poi diventano alert nella Play Console.
In mezzo ci sono anche i sistemi pubblicitari: nel progetto usiamo Gley Mobile Ads con Unity Ads come provider, quindi ogni aggiornamento richiede attenzione anche lì, sia per compatibilità, sia per evitare comportamenti strani su device reali.
“Ci sono ancora problemini”: cosa intendiamo davvero
Quando diciamo che ci sono ancora problemi, intendiamo questo tipo di cose:
- bug piccoli ma fastidiosi legati a UI reference che saltano in scene load particolari;
- comportamenti non perfetti su dispositivi specifici (touch, scaling, font rendering, performance);
- edge case del gameplay (es. reset, restart rapido, panel che devono fermare timer e input in modo consistente);
- integrazione ads: disponibilità interstitial/rewarded che non è sempre immediata, e gestione dei callback.
La parte importante è che lo sviluppo è ripartito con un’idea chiara: ogni update deve ridurre instabilità, non introdurre features “solo per riempire”.
Dove siamo oggi (e cosa arriva dopo)
Dopo 1.4 è arrivata 1.5, che si è concentrata soprattutto su audio e performance (volume più naturale con curva logaritmica, stato mute persistente, restart più rapido senza reload di scena, miglioramenti a hint UI e reacquisition).
Ma la logica resta la stessa: piccoli passi, però continui.
Guardando avanti, la roadmap reale include cose sensate per questo tipo di gioco:
- Undo limitato
- Power-ups moderati (tipo rivelare una cella o rimuovere una mina in modo controllato)
- Daily challenges
- Feedback aptico
- No-Guess Mode (griglie sempre risolvibili)
Queste feature hanno senso solo se la base è stabile, quindi arrivano quando il comportamento core è affidabile su più dispositivi.
Link e info utili
Google Play (versione aggiornata):
https://play.google.com/store/apps/details?id=com.Develop4fun.MedievalMinefield
Contatto supporto: studio@itamde.com
Chiusura (senza promesse inutili)
Medieval Minefield è un progetto che ha avuto una prima vita nel 2021 e ora sta avendo una seconda fase, più adulta e più tecnica, perché oggi pubblicare su Android significa anche manutenzione, compliance, build pulite e refactor veri. Se lo stai riscoprendo adesso, l’idea è questa: gli update continueranno, qualche imperfezione può ancora saltare fuori, e la direzione è migliorare poco per volta, tenendo il gameplay semplice e leggibile.
0 commenti