Medieval Minefield – Update 1.4 (Devlog)

Article published on January 29 2026

Itamde is also an online programming school.

A project that started in 2021, now picked up again: what has changed, what we are fixing, and where we are going

Medieval Minefield started back in 2021 as a small but serious experiment: bringing classic minesweeper gameplay to mobile, focusing on clarity, short sessions, and a medieval-themed interface, without overcomplicating the core rules.

The game remained published, but for a period development slowed down. During that time, Android, Unity, and Google Play requirements evolved significantly. When a project stays untouched for too long, it does not simply become “old”: it becomes fragile. SDK updates, deprecated libraries, and build pipeline changes can easily break stability or compliance.

Over the past months, development has been actively resumed. This is not a reboot, and not a redesign from scratch. It is a process of maintenance, refactoring, and gradual improvement, aimed at making the project solid again while preserving the original gameplay philosophy.

👉 You can follow the evolution and download the latest version here:
https://play.google.com/store/apps/details?id=com.Develop4fun.MedievalMinefield

What “Update 1.4” really means

Update 1.4 represents an important step because it introduced several changes that directly affect everyday gameplay, especially on mobile devices, where accidental input is more common and frustration can quickly push players away.

The key ideas behind version 1.4 were fairness, UI reliability, match flow, and persistence.

1) First Click Safe

The first cell you tap is never a mine.

This may sound simple, but on mobile it makes a significant difference. It removes instant failures that depend purely on chance and ensures that every game actually starts as a logic problem, not a coin toss.

2) Lives System and Hint System

A lightweight persistent lives system was introduced using PlayerPrefs. Lives can be used in two ways:

  • as hints, revealing a safe cell when the player is blocked or unsure;
  • as a resource for the revive system (see below).

This does not change the logic of minesweeper, but it smooths out frustrating edge cases caused by touch input or unavoidable guesses.

3) Revive System (second chance)

When a mine is triggered, the player can choose to:

  • use one available life,
  • watch a rewarded ad (if available),
  • or give up and end the game normally.

The revive is limited to one per match, ensuring that risk and consequence remain part of the experience.

4) Local statistics and tracking

Version 1.4 also introduced more complete local statistics: games played, wins, streaks, best times, total play time, and per-difficulty data (Easy / Medium / Hard).

This is not a global leaderboard system. It is meant to provide clear feedback to players who want to improve, and useful data to evaluate balance and difficulty progression.

5) UI panel refactor

A large part of the work in 1.4 happened behind the scenes. All main UI panels (win, lose, options, revive) were unified under a single show/hide system using CanvasGroup and optional Animators.

This kind of refactor is not flashy, but it dramatically reduces UI bugs related to scene loading, panel stacking, and inconsistent input blocking.

Architecture decisions: why managers must be root objects

One recurring source of issues in Unity projects is improper singleton and DontDestroyOnLoad management. Medieval Minefield relies on several persistent managers (GameManager, AudioManager, AdsManager, StatsManager, InputBlocker, LevelLoader), and their hierarchy placement is not cosmetic.

All managers are required to be separate root GameObjects in the initial scene (MainMenu).

The practical reason is simple: when singletons are nested or destroyed indirectly, initialization order becomes unpredictable. A common example is AudioManager being a child of GameManager: it may work initially, but later break during refactors or scene transitions.

Keeping managers as independent root objects ensures stable lifecycle behavior and predictable initialization.

Android, Unity 6 LTS, and staying Play-Store compliant

Another key reason for resuming development was long-term compatibility.

Medieval Minefield is currently built with:

  • Unity 6 LTS (6000.3.5f2)
  • IL2CPP
  • Target SDK 36 (Android 14)
  • Minimum SDK 23 (with more conservative constraints for AAB builds)

Reaching this point required more than changing version numbers. It involved removing obsolete SDKs, performing clean builds, reviewing manifests and Gradle settings, and updating ad integrations.

Advertising is handled via Gley Mobile Ads with Unity Ads, which also requires careful testing on real devices to avoid initialization and availability issues.

“There are still some issues”: what that actually means

When we say that some issues remain, we are referring to concrete, realistic problems such as:

  • minor UI reference issues after specific scene transitions;
  • device-specific behavior related to scaling, touch input, or performance;
  • edge cases during fast restarts or panel interactions;
  • ad availability timing and callback handling.

The important part is that development is now active again, and updates focus on reducing instability, not on adding features prematurely.

Current state and next steps

After version 1.4, version 1.5 focused mainly on audio and performance improvements: more natural volume handling, persistent mute state, faster restarts without full scene reloads, and additional UI robustness.

Looking ahead, the roadmap is intentionally conservative and coherent with the genre:

  • limited undo functionality,
  • controlled power-ups,
  • daily challenges,
  • haptic feedback,
  • no-guess mode with always-solvable grids.

These features only make sense once the core experience is stable across devices.

Links and resources

Google Play (latest version):
https://play.google.com/store/apps/details?id=com.Develop4fun.MedievalMinefield

Support contact:
studio@itamde.com

Closing notes

Medieval Minefield is a project that had a first life in 2021 and is now entering a more mature phase. Today, maintaining an Android game means dealing with SDK updates, platform requirements, and technical debt as much as gameplay.

If you are discovering or rediscovering the game now, this is the context: development is ongoing, imperfections may still appear, and the direction is to improve the game step by step while keeping its logic-focused, classic foundation intact.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

You might be interested in…

What is Game Dev?

What is Game Dev?

Game development, often shortened to gamedev, is one of those terms that feels familiar even if you’ve never opened a game engine or coded a line in your life. The word carries an air of creativity, technology, and culture all at once. But what does it actually mean,...

3 horror mechanics that make a game terrifying

3 horror mechanics that make a game terrifying

Horror games live and die by the ability to evoke fear, unease, and tension. The best titles don’t just rely on jump scares or grotesque imagery; they create a psychological grip that lingers long after the screen goes dark. True horror stems from an intricate dance...