It’s been a little over two weeks since the release of Michi-Suji Puzzle: Michi Connect. The launch sale has ended, and things are finally starting to settle down a little.

From the demo to the full release, I received reviews and feedback from many different people.
So, as one final part of wrapping up this launch period, I wanted to do a small public retrospective.
For the English version, I’ll use a simple retrospective format based on three questions:
This turned into another fairly long post, so if you don’t feel like reading the whole thing, feel free to jump straight to the summary at the end.
The core of Michi-Suji Puzzle could be explained fairly simply:
Move blocks and find a path for the light to reach the goal.
Post-release reviews also seemed to understand the basic rules and the fact that puzzles could often be solved in more than one way.
That made me realize that having a core idea that can be explained in one sentence is something I want to keep prioritizing, no matter what kind of game I make next.
The project didn’t stop at the idea or prototype stage.
I went through the full process: releasing a demo, preparing the Steam page, participating in events, launching the full game, and fixing issues after release.
There were many things I could only learn after actually putting the game in players’ hands.
So one thing I definitely want to keep doing is finishing what I start and getting it out into the world, rather than getting stuck chasing perfection forever.
One of the clearest pieces of feedback I received was that the cat shown in the capsule art looked different from the cat in the actual game.
I also received feedback that the design of the connection blocks didn’t clearly communicate what they were supposed to do.
Looking back, I agree.
Players usually see the capsule first, then check the trailer and screenshots. If those things feel too far apart visually, it’s understandable that they might feel confused or uncertain about what to expect from the game.
There was also a reason behind the connection block design.
Until shortly before the demo release, I was using a different symbol. During a final legal check, I was advised that it looked too similar to symbols used for things such as USB connections, so I changed it at the last minute.
Because the same design also appeared in capsule art and other assets, I needed something that could be replaced quickly and consistently.
Looking back, the first demo was released in February, when the game still had very little visibility. I probably had enough time before the full release to redesign it again and create something that fit the game world more naturally.
One review pointed out something that really stayed with me:
Even if a puzzle can eventually be solved through trial and error, the process itself can start to feel like work.
I had already tried to avoid making the core gameplay feel like simply moving blocks around.
But I hadn’t thought enough about another kind of repetition: replaying the same stage several times in order to earn a better medal.
In Michi-Suji Puzzle, players can earn Gold and other medals by solving stages in fewer moves. That was intended as an optional challenge.
For some players, though, repeatedly replaying the same stage for Gold could become tiring.
That made me realize something:
A game that players can finish and a game that players want to play again are not necessarily the same thing.
I don’t think this lesson is limited to puzzle games.
Whatever genre I make next, I want to test not only whether players can keep playing, but whether repeating the core actions still makes them want to continue.
During Steam Next Fest and after launch, several streamers played the game, and the game was also featured by external sites.
I genuinely enjoyed watching those streams, and I’m very grateful to everyone who spent their time with the game.
But looking back, I think I focused too much on being thankful that my game had been featured, and not enough on responding to what made their stream entertaining and unique.
There is another thing I learned as well: having the developer show up in a stream is not necessarily comfortable for every streamer.
It could make someone feel more cautious about criticizing the game or simply make them feel like they have to behave differently.
Next time, I would rather ask beforehand whether they are comfortable with me watching.
I also didn’t send press releases to media outlets around launch.
In other words, I relied too much on people discovering the game on their own instead of proactively giving them the information they might need.
Next time, I want to treat streamers and media not simply as “places to promote the game,” but as people doing their own work, and communicate with them more thoughtfully.
Next time, I don’t just want people to playtest the game.
I also want to show the store page and trailer to people who know absolutely nothing about the project.
I want to ask things like:
As the developer, I inevitably become too familiar with my own game.
Some first-impression problems can only be found by people actually seeing it for the first time.
Next time, I want to avoid going directly from “the game works” to “prepare for release.”
Instead, I want to reserve time specifically for reviewing:
Even when something works mechanically, it may still look unfinished or fail to communicate its purpose clearly.
So I want to add another question to the development process:
Not only “Is the game finished?” but also “Does it look finished to someone seeing it for the first time?”
Next time, I want to prepare more carefully for who I want to reach, when I want to reach them, and how.
That includes social media, wishlists, streamers, media outlets, and press releases.
With streamers, I want to confirm beforehand whether they are comfortable with me watching and make sure I respond not only to the game being featured, but to the stream itself.
With media outlets, I want to provide useful information and assets proactively instead of simply hoping they discover the game.
In other words, I don’t want promotion to end at “I posted something.”
I want to think about the entire process of actually getting the game in front of people.
Looking back, there were many things I could only understand after actually releasing the game.
Game development wasn’t only about making the game. It was also about how the game looks, whether people want to keep playing it, and how it reaches them.
What Went Well: I had a core idea that was easy to explain, and I managed to finish the project and release it.
What Didn’t Go Well: There were gaps between the game and its presentation, some repetition could become tiring, and I could have handled relationships with streamers and media more thoughtfully.
What I’ll Do Differently Next Time: I want to get first-impression feedback before launch, reserve time specifically for polishing the presentation, and plan how the game will reach people much earlier.
I’ll take what I learned from this release and use what I can, little by little, to make the next game better.
フォローすると、開発ログや新作ゲームの公開が通知されます