This article is a record of the “Planning” phase of the (post-release) devlog of the iOS mobile game “Slashing Samurai,” released on the App Store on December 15, 2023.

Slashing Samurai is available for free download on the App Store. Just click the banner below to get this game!

Defining the Rough Specifications of the Game

The development process began by roughly defining the specifications of the game to be developed.

It was pre-determined that the game would be distributed globally on a specific platform. If aiming for global distribution, it was clear that it would require a certain level of quality to gain approval. Achieving this alone meant the game’s volume had to be kept small. For a game with a small volume, a casual game seemed appropriate. The essential element for casual games is user-friendliness. The most effective platform for maximizing user-friendliness is likely a mobile game. With devices that everyone carries, offering a small screen that serves as an input device, there seems to be no other platform that matches the physical convenience.

I have always loved RPGs. Naturally, I aspire to create an RPG with an exciting story and exhilarating battle system. However, for now, let’s stay grounded. RPGs are arguably in opposition to the casual game genre. Honestly, I wasn’t very familiar with casual games. However, seeing is believing. I downloaded several casual games on my phone and found them surprisingly addictive. Recently, the genre of “Hyper Casual” has been established, and it seems that there are quite a few people who enjoy playing such games. Convinced that “Casual games are not bad,” I decided to start my first mobile game development with the genre set as a casual game.

The overall user-friendliness demanded by casual games was considered. The following points were listed:

  • Intuitive gameplay
  • Simple controls
  • Pleasant playing experience
  • Quick retry
  • Ease of starting and ending

I believed that by addressing these points, the experience of playing a casual game could be established. I proceeded with development, keeping a close eye on these aspects.

Intuitive Gameplay

With the genre decided, the next step was to think about the specific content of the game. I pondered on whether there could be a play that doesn’t require much thought, is intuitive, and feels good. Suddenly, I recalled a game I played in my childhood with siblings and friends, picking up fallen branches from the ground and playing a game with the following rules:

  1. Hold out your hands in a handshake position forward.
  2. The opponent drops a thin stick or branch unexpectedly from slightly above.
  3. If you can catch the falling stick successfully, it’s a win.

Child Play

Intuitive, simple, requires concentration, tests reflexes, and even if you fail, you want to try again, and success brings a delightful feeling. This is good. I decided to adapt this to a mobile game. Specifically, I modified the rules of play for the mobile game as follows:

  1. Place the player character at the bottom of the screen.
  2. Place an object at the top of the screen.
  3. Set collision detection areas for each.
  4. Drop the object from the top of the screen
  5. Only when the collision detection area of the falling object overlaps with the player character’s collision detection area at the moment of contact, the collision detection is enabled.
  6. During the moment of collision detection, perform a specific screen operation to determine success; otherwise, it is considered a failure.

Play Image 1

This gave a feeling that intuitive gameplay could be achieved. Next, I worked on the “Simple Controls.”


Simple Controls

Since mobile games don’t have physical buttons, making controls more complex is challenging. Avoiding placing virtual buttons on the play screen is essential because, without the tactile feedback of physical buttons, players may not notice if their fingers slip off the virtual buttons. To prevent negative user experiences like “I pressed it, but nothing happened!”, I designed the basic operation of the game to accept input almost everywhere on the screen, with only touch and release gestures.

Next, I applied touch and release gestures to the previously determined basic rules of the game. Input is accepted simultaneously with the start of the object’s fall and is disabled after the first input. Between touch and release operations, the latter is expected to have less lag between the player’s input sensation and the smartphone’s input processing. Therefore, during the time when collision detection is active, a release operation is considered a success.

If the player character waits for falling objects at the bottom of the screen, the timing when collision detection becomes active will be the same every time, which may become less interesting. Therefore, I decided to make the player character jump with a touch operation. While keeping the touch, the player character rises to a certain height. This eliminates the need to waste the touch operation before release, killing two birds with one stone.

Play Image 1

Pleasant Playing Experience

The feeling of satisfaction when successful is a necessary element for a game. To express this satisfaction, I decided to incorporate typical expressions often used in manga or anime into the game.

Two opponents engaged in close combat both unleash their special moves simultaneously in the air as they pass each other, creating a moment of suspense and excitement when they land. Depending on the situation, there may be catchphrases, and the one who loses is defeated with blood spurting, being cut, or exploding.

To achieve this expression, I initially considered making the player character a swordsman and the object a monster. However, making a monster that only falls without attacking would result in a deceptive monster. This seemed likely to fail to meet the player’s expectations. So, instead of making the object a monster, I decided to simply drop something, which would satisfy the player’s expectations without raising them too much. Although it deviates slightly from the anime expression mentioned above, it avoids a grotesque impression, making it suitable for children to play comfortably.

I remembered a demonstration of a sharp knife during a live sales event, where after cutting vegetables, they appeared uncut. What if we make the player character a samurai, allowing them to cut everything with a sharp sword? Something like Lupin III’s Goemon Ishikawa comes to mind.

Upon successfully completing the first cut, the falling object is sliced by the samurai in mid-air. After both land on the ground, the object suddenly splits with a time delay, triggered by the sound of the samurai sheathing the sword. This seemed to create a satisfying play experience and was adopted as part of the gameplay.


Quick Retry

Ensuring that the time from game failure to accepting input from the player for a retry is not too long is crucial for keeping players engaged. Casual games, due to their accessibility, risk losing players if the tempo is even slightly off. As a benchmark for quick retry, the following games were considered:

In particular, the game Bacon served as a great example for casual game design. The sensation of being able to retry immediately and feeling compelled to play multiple times without giving up was highly valuable.

Ease of Starting and Ending

While the environment for playing mobile games varies from person to person, playing during commuting on public transportation is expected to be more prevalent than on other platforms. In such situations, the ability to end the game quickly upon reaching the destination or seamlessly end and start the game during transfers becomes crucial.

Players are concerned about game data, such as “I progressed to a good point, but the save point is still ahead” or “When I closed the app and tried to resume, the data loaded was from a while ago.”

To address this, I implemented an auto-save and auto-load feature to allow players to start and end the game almost anytime on their smartphones. I paid particular attention to the following points during implementation:

  • Save data frequently, aligning with the timing when save-targeted data, such as scores, has changed.
  • Load data at unobtrusive moments, such as game start or scene transitions, to minimize disruption to gameplay.

Conclusion

With this plan in mind, I proceeded with the game development. However, adjustments may have been made during development. The flexibility to update the initial plan anytime is a strength of individual game development, although it should be used judiciously to avoid endless development.

If you are developing games as a hobby alongside your day job, you may not need to create such a detailed plan. Moreover, a formal document to show someone is unnecessary. Sketching the game’s image or jotting down the plan in a notebook is sufficient as long as you understand it yourself.

I hope this development log serves as assistance for someone’s game development journey.

References