Illuminate the Dark Dungeon

In previous projects, I experienced Flutter app development, store releases, and user acquisition through advertising. In particular, through “SnapSlide Puzzle Game,” I confirmed that paid advertising could generate downloads, but I also learned that download count does not necessarily translate into sustained users.

For this project, I therefore focused not just on releasing an app, but on creating a game structure that users could play repeatedly. I initially planned a text RPG, but the development scope became larger than expected while implementing the foundation for login and data management. I then looked for an idea that could be built more quickly while still supporting repeat play, and shifted direction to an RPG puzzle game based on the intuitive rules of Minesweeper.

I chose this project for the following reasons.

The game I referenced was Daniel Benmergui’s Dragonsweeper. Dragonsweeper is introduced as a Minesweeper game that requires observation, and it is an HTML5 puzzle game tagged with Minesweeper and Roguelike [Daniel Benmergui - Dragonsweeper, itch.io]. Rather than directly copying that idea, this project expanded it by connecting Minesweeper-style rules with RPG battles and character progression.

Setting the Development Goals

The development goal of "Illuminate the Dark Dungeon" was to build a Minesweeper-based RPG puzzle game with Flutter, release it on Android and iOS, and implement a mobile game structure that includes login, data storage, ads, and in-app purchases.

This project required more than simply implementing game logic. It also had to handle user identification and progress data management. Since character progression, owned currency, stage progress, ad rewards, and in-app purchase products were all connected, the game needed a structure that could reliably manage each user’s play history and purchase rewards.

Data integrity was especially important in order to experiment with monetization through in-app purchases. Purchased currency had to be granted correctly, and each user’s progress and owned currency had to remain consistent. For that reason, I decided to implement account-based user identification as part of the project.

For login, I wanted to provide Google login and Apple login using Supabase Auth’s Social Login (OAuth), as well as Anonymous Sign-Ins for users who wanted to start immediately without an account.

The development goals for this project also included an experiment in fully controlled Cursor-based vibe coding. I personally determined the overall project structure, code placement, and feature-level design, while limiting the AI tool to the role of a coder that writes code within the predefined structure. When requesting features, I gave specific instructions about which code files should implement which functionality and content, and I directly modified small parts when the result was not satisfactory.

System Architecture

"Illuminate the Dark Dungeon" was structured as a mobile game app based on Minesweeper-style rules, where players reveal dungeon tiles, check surrounding information, find a key, and then move to the next stage through a gate. When the player selects a tile, the app checks the current dungeon state and shows information based on the number of nearby monsters and nearby object hints so the player can decide the next action.

Game progress centers on the state of the dungeon board. Each tile contains information for one of the following: monster, treasure chest, key, gate, or empty tile. Whenever the player reveals a tile, the flow branches into number display, hint display, battle, reward acquisition, key acquisition, or gate movement.

Core Implementation Flow

Login and User Data Management

In this project, I implemented login and data management together in order to store each user’s progress. This was necessary because the game needed to distinguish users in order to reliably manage stage progress, owned currency, and character growth information.

I built the foundation for guest login and social login using Supabase Auth, and created a structure that manages game progress data based on the logged-in user [Supabase - Auth]. Through this process, I confirmed that user identification and data storage design are more important in this type of project than in a purely local game.

Implementing Minesweeper-Based Dungeon Rules

"Illuminate the Dark Dungeon" was designed around a structure similar to Minesweeper: players reveal hidden tiles and decide their next action based on surrounding information. When the player selects a tile, the flow branches depending on whether that tile is empty, a monster, a treasure chest, a key, or a gate.

When an empty tile is opened, the game displays the number of monsters in the surrounding nine directions. I also added object hints that indicate whether a treasure chest, key, or gate exists nearby, so the player can infer both rewards and progression goals rather than simply avoiding monsters.

The goal of a stage was not to open every tile, but to find the key inside the dungeon and move to the next stage through the gate. This expanded Minesweeper’s inference rules into a dungeon exploration and stage progression structure.

Implementing Stat-Based Battle Logic

Monster tiles were designed not merely as obstacles to avoid, but as risk elements that can provide experience and currency through battle. Characters and monsters were given attack, defense, speed, and HP stats, and when a monster tile is opened, the battle result is calculated based on those stats.

Battles proceed with the character and monster attacking each other. Damage is primarily calculated based on attack and defense, while differences in speed can trigger attack and defense adjustments, evasion, or critical hits. This makes the battle outcome vary depending on the character’s current state, even against the same monster.

If the player wins a battle, they gain experience and currency. If the character’s HP reaches 0, the run ends. However, I allowed one revive using either crystals or a rewarded ad, so battle results would connect to character progression and currency usage flows.

Implementing Character Progression and a Repeat-Play Structure

To encourage sustained play, I structured battle rewards so they lead into character progression. Players earn experience and currency through battles, then use them to grow characters or purchase new characters.

Character progression was not simply a level-up feature; it was designed to give players a reason to challenge higher stages. Rewards gained from battle were connected to character stat enhancement, while gold and crystals could be used for character purchases and some progression elements.

Through this structure, I aimed to create a loop in which players repeatedly explore dungeons, collect rewards, strengthen characters, and then challenge higher stages again.

Implementing the Shop and In-App Purchase Flow

The shop was implemented as a structure that connects crystals, hearts, revives, and character progression elements. Users can purchase digital products such as crystals through real payments, and purchased crystals are granted as in-game currency.

Crystals can be used for heart refills, reducing heart refill time, revives, character purchases, and progression elements. In addition, when the character’s HP reaches 0, using crystals revives the character with full HP, while watching a rewarded ad revives the character with half HP. This connects paid currency and ad rewards within the same flow.

During this process, I applied both Google Play Billing and Apple In-App Purchase. Rather than ending with product registration, I implemented the full flow of checking payment completion and reflecting the purchased digital product in user data.

Applying Ads and In-App Purchases

Since the game was released as a free game, I applied both rewarded ads and in-app purchases. Users can watch ads to receive rewards, and they can purchase in-game currency such as crystals through in-app purchases.

On Android, I implemented the payment structure based on Google Play Billing, and on iOS, based on Apple In-App Purchase [Android Developers - Google Play Billing Library integration] [Apple Developer - In-App Purchase types]. Products such as crystals, which disappear when used and can be purchased again, were designed according to a consumable product structure.

Vibe Coding Approach

In this project, I wanted to apply Cursor-based vibe coding in a more controlled way than before. I personally determined the overall project structure, code placement, and feature-level design direction, and limited AI to the role of writing code within the defined scope.

When requesting work, I did not simply ask the AI to implement a feature. Instead, I specified the files to modify, the code to connect, and the behavior the result needed to satisfy. I also directly fixed small changes or unsatisfactory results so that AI would not disturb the overall project structure.

This approach was more advantageous than before for understanding and maintaining the code structure. However, because I had to divide tasks into small units and continuously review the results, the development speed did not improve as much as expected. For features I was trying for the first time, such as login, it was difficult to define the structure clearly enough in advance, and I eventually had to understand the entire flow again and make large-scale modifications.

As the project grew, the number of code files and the connections between features increased. Even when I gave instructions at the same level of detail, there were once again many cases where AI could not implement the requested requirements correctly in a single attempt. As a result, controlled vibe coding improved code quality and maintainability, but still had clear limitations in complex feature implementation and development speed.

Responding to App Store Review Issues

The Google Play Store release took longer than expected. Google Play requires new personal developer accounts to run a closed test before production release, and it states that at least 12 testers must participate continuously for 14 days before a production application can be submitted [Google Play Console Help - App testing requirements for new personal developer accounts]. This requirement delayed the Google Play release, so the app was released on the Apple App Store first.

The issue occurred later during Google Play’s production review. Google Play’s impersonation policy explains that app names, icons, descriptions, and in-app elements that could mislead users about a relationship with another app or developer are not allowed [Google Play Console Help - Impersonation]. Its intellectual property policy also states that apps that infringe others’ copyrights, trademarks, or other rights are not allowed, and proof of rights may be required in some cases [Google Play Console Help - Intellectual Property].

In this project, I did not use another person’s app name, images, resources, or descriptions. However, at the time of Google Play review, the App Store version that I had released first was already public, and when searched, the only similar-looking target was that App Store version. I therefore judged that the previously released same app may have been mistaken for a separate app or another person’s app during the Google Play review process.

At first, I aligned the app name, copyright notice, developer information, and email between the App Store and Google Play, and submitted the App Store Connect management screen, access video, business registration proof, and identity verification materials. However, this alone did not resolve the issue. Eventually, I prepared and submitted a separate rights verification document explaining that the app released first on the App Store was also the same app I had created, and that the Google Play release was being conducted by the same rights holder. Only after that was I able to proceed with the Google Play resubmission.

Store Release