This article is a record of reflections on the (post-release) development log of the iOS mobile game “Slashing Samurai,” released on the App Store on December 15, 2023. It explores areas for improvement and lessons learned during the development process.

Feel free to download “Slashing Samurai” for free from the App Store using the banner below if you’re interested.


Identification of Reflection Points

After completing the development of “Slashing Samurai” and reflecting on the process and outcomes, various points for improvement became apparent. To better utilize these reflections in future game development, I want to document them thoroughly.

Let’s start by summarizing specific points for improvement:

  • Overdoing
    • Too many stages
    • Excessive difficulty
    • Overemphasis on world-building
  • Too late
    • Implementation of plugins took too long
    • Testing on actual devices was too slow
    • Promotion preparation was too slow

I will provide detailed records for each of these.


Overdoing

Let’s begin by discussing the common pitfalls of the “overdoing it” category, which many novice developers, including myself, tend to fall into.


Too Many Stages

Rather than doing this with good intentions, I might have unconsciously avoided the struggles of subtraction. I prepared a total of 200 stages, with 20 stages and 10 levels each, thinking players would appreciate the abundance. However, for a casual game, very few players would commit to completing all those stages. It turns out that having an abundance of levels only reflected my self-satisfaction of wanting to drop everything under the guise of “increasing player satisfaction with more stages.” As I played the completed game, I realized that clearing one level took a considerable amount of time. The problem was exacerbated by the fact that the falling objects’ behavior changed with each level, resulting in a gradual and monotonous experience until reaching the next level.

In retrospect, adjustments could have been more reasonable by choosing one of the following approaches:

  • Keep the number of falling objects the same, increase the number of levels, and decrease the number of stages per level. Introduce more variations in the behavior of falling objects and carefully adjust the difficulty balance for each level.
  • Reduce the number of falling objects by half or a third. Instead, globally increase the difficulty. However, to maintain diversity when the number of objects is reduced, provide a unified theme for falling objects, such as restricting them to “electronic devices born after the 20th century.”

The latter option might have been more suitable.


Excessive Difficulty

I had the opportunity to receive a review of “Slashing Samurai,” and one feedback was about the high difficulty. It’s truly appreciated to receive honest feedback like this.

For indie developers, the problem lies in getting accustomed to and mastering the gameplay as they progress through development. When developers adjust the game’s difficulty based on their own sense, there tends to be an overall increase in difficulty.

“Slashing Samurai” requires reflexes and dynamic visual acuity, and games that involve these physical senses are particularly prone to becoming too easy for the developer. I am considering slightly lowering the difficulty in future updates.

When difficulty cannot be objectively assessed, it’s preferable to have individuals unrelated to the development play the game and provide feedback. However, if, like me, you don’t have friends who can do that (not lonely at all), it might be worthwhile to intentionally lower the difficulty.


Overemphasis on World-Building

In casual games, a detailed world-building is usually unnecessary. Players might find it annoying to have a world forced upon them when they just want to play casually. “Slashing Samurai” falls into the category of casual games where world-building was overemphasized.

Firstly, I named the player character a samurai “Yoichi.” I carefully considered various factors such as a name that is easy to read in English when romanized, a name with fewer characters in both romanized and kanji forms, and a name with a straightforward pronunciation in kanji. However, whether spending a considerable amount of time on this was meaningful is highly questionable.

The decision to name the samurai was mainly because specific nouns for the samurai were needed in the prologue and epilogue texts that appear on the start screen. The prologue is crucial in conveying the game’s world to the player. Initially intended to fill the idle time during game loading, it ended up being extensive. As the narrative unfolded, I got carried away, resulting in a situation where players, after reading the prologue, might think, “This is too long!” and assume the game itself is too lengthy, leading to unfortunate consequences of not being played.

Furthermore, I prepared a large number of lines for Yoichi, the samurai. This decision was made when there were already 200 stages prepared, driven by the desire to avoid player boredom due to volume. I implemented a feature to let Yoichi speak a few words at the beginning of each stage. These lines varied for each stage, and to prevent monotony upon retrying, I included a significant amount of random lines. Since it was a monologue and not a conversation, writing the lines was relatively easy. However, due to my excitement during development, some lines turned out to be redundant, and players might feel, “This is too long!” again. Recognizing this during development, I included an option to turn off the lines.

In summary, I couldn’t restrain my desire for expression. I am satisfied because my desires were fulfilled. I ask players for their understanding.

While I plan to incorporate some world-building in future games, I will be cautious about going overboard. If I start adding a massive number of items to the localization CSV file, I’ll question whether it’s really necessary. If I ever create an action game or RPG with a progressing story in the future, I intend to construct the world freely at that time.


Procrastination Woes

Now, let’s reflect on the tasks that were too late.


Implementation of Plugins Took Too Long

Plugins are incredibly useful, and hats off to the developers for creating them. In “Slashing Samurai,” I utilized two essential plugins.

Firstly, the DialogueManager . The other popular dialog plugin, Dialogic , was considered but deemed overkill for the casual in-game speech bubbles.

The second one was the Godot AdMob Plugin , simplifying the implementation of Google AdMob for game development funding. Without it, integrating Google AdMob would have been a daunting task.

While these plugins are incredibly handy and cover complex aspects that would take a significant amount of time to implement from scratch, integrating them into my project required a thorough understanding of the documentation. Since “Slashing Samurai” was already close to completion and in the refinement stage, adding code that I hadn’t written to an already complex codebase made me hesitate, resulting in wasted time before starting the work.

Moreover, concerning the Google AdMob Plugin, I had to apply for Google AdMob usage before using the plugin, involving document submissions and address verification procedures, taking about a month. It’s advisable to handle this process promptly. Personally, obtaining a proof of residence document from the local tax office proved to be more cumbersome than expected. Despite my research suggesting a quick acquisition at the tax office, the staff misunderstood the necessary documents, causing delays and requiring two visits.

In conclusion, the lesson learned was to try unfamiliar things at the experimentation stage, as even seemingly straightforward tasks may have hidden complexities.


Testing on Real Devices Took Too Long

Although the goal was to create a mobile game, I didn’t start debugging on a smartphone until the latter stages of development. I typically used a MacBook Air with an M1 chip for development, a machine with excellent performance. This led to a false sense of the game’s smooth performance while debugging directly in Godot. However, when testing on an actual smartphone, issues such as stuttering movements and memory leaks emerged, causing considerable panic. Honestly, I thought the game was almost finished.

I encountered some pitfalls during Android remote debugging. Enabling “Debug” > “Small Deploy with Network Filesystem” in Godot with a low-spec smartphone like my Rakuten Hand5G, purchased cheaply on Mercari, significantly slowed down the game’s performance on the phone. It took a while to realize this setting was the cause. On the following morning, with a refreshed mind, I identified the issue. Unfortunately, an old Xperia with Android 9.x borrowed from a colleague crashed on the first scene switch, attributed to compatibility issues with the OS, leading me to abandon further investigation.

Next, onto iOS. Since I use an iPhone in my private life, I used it as a test device. Debugging on iOS is tricky because Godot doesn’t support direct debugging; Xcode is used for that, requiring a Mac. Thanks to the official exporting for iOS documentation , exporting and debugging from Xcode were not as challenging as initially anticipated. Following the steps in the “Procedure to link the Godot project folder to Xcode” at the end of this article eliminated the need to export every time.

However, there was still a pitfall. The final export for App Store submission must be performed at the end. I made the mistake of building the App Store version directly from Xcode with the Godot project folder referenced. A few days later, after passing the review, I tried downloading “Slashing Samurai” from the App Store to my iPhone, only to receive an alert stating the size was too large and asking if I wanted to download it without Wi-Fi. To my surprise, the game’s file size exceeded 500 MB. I spent the night reducing it to around 160 MB and submitted version 1.1. Linking the Godot project folder from Xcode is convenient during development but increases the game’s size significantly—something to be cautious about. Also, building directly from Xcode with the referenced Godot project folder causes errors due to added Android-specific .class and .zip files from plugin installations. In my case, I forcefully excluded these files when building.

While the App Store account acquisition for Apple went smoothly, obtaining a Google Play Developer account was painfully slow. To distribute a mobile game on various platforms, Developer accounts for Apple and Google are necessary, incurring expenses. I delayed creating a Google Developer account, and this resulted in facing newly updated rules just when I was ready to release. These rules were particularly challenging for solo developers.

For Google Play, passing a closed test is mandatory before publishing an app. To clear this closed test, developers need more than 20 testers to play the game continuously for 14 days. For someone developing a game independently while working full-time (like me), finding 20 friends or acquaintances who can playtest without a day off for two weeks is nearly impossible. Despite developing robust Android support, I had to give up at the last moment. If the rules improve or a service allowing developers to request tests from each other is created (I briefly considered creating one out of frustration but realized I lacked the necessary skills), I’d like to submit to Google Play at that time.


Promotion Preparation Was Too late

While placing my game on sales platforms was a goal, once the App Store submission passed, I felt as if everything was complete. However, realizing that the game might go unnoticed without any promotion efforts, I decided to undertake some promotion within my personal capacity.

Although I didn’t fully understand the ins and outs of promotion, I attempted the following:

  1. Tweeting announcements on X.
  2. Creating accounts on Instagram and TikTok for posting short play videos.
  3. Establishing a YouTube channel and uploading promotional videos.
  4. Requesting press releases and review articles to be featured on game-related media.

Posting on social media, such as X, should ideally be done consistently from the development phase to increase visibility. However, as is common among developers, when things are progressing well, there’s a strong desire to immerse oneself in the work. Interestingly, when I did post during productive times, exciting things tended to happen. This was particularly evident in my case—I always wanted to code for one more second. As a result, I unleashed a mobile game on the world without anyone noticing.

If I had spent more time editing and creating a more impactful and visually appealing promotional video for YouTube, I believe more people would have taken an interest, especially if released early.

Sending out press releases was done a few days after the release. Still, it would have been more effective to announce it beforehand for pre-release publicity. Despite the formalities, I managed to have press releases and review articles featured on the following six media outlets, and I would like to express my gratitude here:

As mentioned earlier, despite the somewhat formal nature, I attempted promotional activities. However, “Slashing Samurai,” released on 2023/12/15, has a total download count of an impressive 14 as of 2024/1/9. I consider this a fantastic result. The game has been downloaded by 14 people worldwide—this is a miracle, considering it’s not zero. Subtracting the media downloads and my iPhone downloads, it’s 7. I am filled with gratitude for the seven curious individuals worldwide.


Conclusion

In this devlog, I’ve detailed the reflections on the shortcomings of “Slashing Samurai.” Let’s summarize once more.

Several aspects of the game took longer than anticipated due to overdoing things during development. The game ended up significantly behind the initially planned release timeline, leading to a sense of urgency in the latter stages of development. Consequently, tasks other than game development, such as Developer account applications, AdMob-related paperwork, and promotional activities, ended up with a “too late” outcome.

In the future, I’ll strive to avoid falling into the same pitfalls and be more attentive. I hope this development log serves as a helpful guide for someone involved in game development.