|
SokoGhost: Unfinished Business is a small block-pushing puzzle game where you can pass through walls and boxes! Use your powers to solve 100 levels built around 'Aha'-moments with different pass-through mechanics!
The game spawned from the idea of building a game around the verb "Passing Through". As a concept it was not something I had seen done much before, and it stuck so well into my brain that I had to try and build it. I convinced my friend to tag along, and the two of us made the game over the course of 3½ months utilizing our weekends, late nights and holidays from our primary full time jobs. We successfully released the game on Steam on March 26th 2026, staying on track and never diverting from the plan we made when we started. Here you can read about how we did it. |
The game was made by a two-person team over the course of 3½ months, working in our spare time using evenings, weekends and holiday days from our primary full-time job.
My role in the project:
|
Challenge #1: How do you know the concept has enough depth to merit a full game?
The biggest uncertainty in the beginning was whether it would possible to even design enough levels around the concept.
The idea of making a block-pushing puzzle game where you can pass through walls had already came up at a game jam 6 months prior, but we decided against it because of we were uncertain if we could make enough content.
Before I could start building the game in Unity, I had to validate that we could make enough levels to merit a full game.
In order to verify it, I started building levels. First on my remarkable, which were great for quickly sketching out some raw ideas. Then I moved over to Miro, because I needed to add notes and annotations to the designs. It was great for describing the core fundamental gameplay elements.
Finally, when I had established the gameplay foundation in Miro, I started creating concept levels in Tiled, a tilemap editor, to test the limits of the design. Basically, how many levels could I make, before I felt the concept was exhausted of potential.
The idea of making a block-pushing puzzle game where you can pass through walls had already came up at a game jam 6 months prior, but we decided against it because of we were uncertain if we could make enough content.
Before I could start building the game in Unity, I had to validate that we could make enough levels to merit a full game.
In order to verify it, I started building levels. First on my remarkable, which were great for quickly sketching out some raw ideas. Then I moved over to Miro, because I needed to add notes and annotations to the designs. It was great for describing the core fundamental gameplay elements.
Finally, when I had established the gameplay foundation in Miro, I started creating concept levels in Tiled, a tilemap editor, to test the limits of the design. Basically, how many levels could I make, before I felt the concept was exhausted of potential.
Once I had made more than 30 concept levels, I was confident that it would be possible to build enough levels around the core design for a full game.
I had set a goal of 100 levels, which felt a lot more achievable after the initial exploration of the design space.
While most of the initial concept levels ended up being reworked and modified, there were a couple that made it all the way through to the final game.
I had set a goal of 100 levels, which felt a lot more achievable after the initial exploration of the design space.
While most of the initial concept levels ended up being reworked and modified, there were a couple that made it all the way through to the final game.
This is an example of a level that survived all the way through from concept level in Tiled to the published game.
Level Creation Time-lapse
This is a level creation time-lapse, using the build in level editor we used for the full game. It's a lot further in the production process, but I draw from the principles learned during the initial concept exploration phase.
Challenge #2: How do you make sure new features don't break old features?
While the fundamental of the gameplay were established, I still wanted to introduce additional puzzle elements like pressure plates and doors, to keep the gameplay varied and interesting.
However, a challenge emerged, as each new feature increased the complexity of the design. In addition, while an initial idea for a gameplay feature might seem interesting, it wasn't always clear how it would relate to the rest of the game.
To get a better understanding of this and to explore the depth of each feature, I created a Gameplay Synergy Matrix. I listed up every feature we were planning in rows and columns. Then I went through each cell of the matrix and described how these features would interact with each other in a meaningful way.
Sometimes it wasn't possible to find interesting synergies, but many times new ideas emerged from forcing two concepts together that I initially hadn't thought about combining.
This exercise also highlighted features that didn't have a lot of synergy with the rest of the game. Ultimately, these features would end up getting cut from the game, because they were too detached from the rest of the gameplay.
However, a challenge emerged, as each new feature increased the complexity of the design. In addition, while an initial idea for a gameplay feature might seem interesting, it wasn't always clear how it would relate to the rest of the game.
To get a better understanding of this and to explore the depth of each feature, I created a Gameplay Synergy Matrix. I listed up every feature we were planning in rows and columns. Then I went through each cell of the matrix and described how these features would interact with each other in a meaningful way.
Sometimes it wasn't possible to find interesting synergies, but many times new ideas emerged from forcing two concepts together that I initially hadn't thought about combining.
This exercise also highlighted features that didn't have a lot of synergy with the rest of the game. Ultimately, these features would end up getting cut from the game, because they were too detached from the rest of the gameplay.
Above is a screenshot of the gameplay synergy matrix. Notice how the features "Haunt Tiles" and "Possessable Objects" both have low synergy scores. These features both got cut from the final game. One exception to this is the feature called "Delivery Spots" that are still in the final game.
Challenge #3: How do you create a satisfying ending to a puzzle game?
|
We were reaching the final stage of production and were faced with a final challenge. How do you create a satisfying ending to a puzzle game?
Action-focused games would put the player face to face with the biggest and baddest monster imaginable. Story-heavy games would let all the narratives build together in a final moment of emotions and drama. But what about puzzle games? |
|
In the first versions of the game, the finale was just the most difficult level we had.
However, it wasn't a satisfying experience, to end the game on. We had to give the player something more. Throughout the game, there's an underlying narrative, and there's a natural progression up through the skyscraper. So we used that as a jumping off point for brainstorming. |
|
We wanted to create a final encounter, like a boss but it should fit into the puzzle-game context.
To help us, I defined some constraints:
|
The solution we went with was a boss level with puzzle elements. The player has to damage the head of the company by electrocuting him after solving puzzles. Each time the boss is damaged, the level shuffles and the puzzle difficulty increases.
This solution utilizes all the puzzle skills the player has learned through the game, is a narrative callback to the beginning of the game and introduces a new and exciting way to beat the level.
This solution utilizes all the puzzle skills the player has learned through the game, is a narrative callback to the beginning of the game and introduces a new and exciting way to beat the level.
Images from Production
I designed the Options interface for the game. We needed a design that we could reuse for future projects, so it had to be future proof and accommodate different device input types.










