Twinfold is a game of roguelike addition -- a battle against square foes as you double up numbers. It’s a mixture of multiple game styles, drawing from Threes!, the roguelike works of Michael Brough, and the clarity of information from Into the Breech. This mixture makes a compelling play style that draws players into its labyrinth of number-merging, mean-spirited cubes.

Gamasutra spoke with Kenny Sun, developer of Twinfold, to learn more about mingling several ideas to make a unique title, the importance of procedural generation to making Twinfold an appealing experience, and how testing and bouncing ideas off a friend can help make a game come together.

The inspirations for Twinfold’s mixture of genres

I think I came up with the idea after playing Into the Breach. Then, I stole a bunch of mechanics from Threes! and Michael Brough’s roguelikes.

I liked how Into the Breech provided perfect information to the player, turning what looked like a strategy game into kind of a puzzle game. So, I wrote "Into the Breach-style dungeon crawler” into my notebook, and then I made Twinfold. I don’t remember how the idea got kicked off. There isn’t usually a story behind how I come up with ideas -- it’s not really an important part of the process for me.

I took the number-merging and board movement mechanics from Threes! and the objective and wall shifting mechanics from Imbroglio. I figured the fact that both games are played on small grids meant that those mechanics would mesh well.

At first, combat was similar to Imbroglio or Cinco Paus, where if you were next to an enemy and slid towards them, you would only attack them instead of sliding the whole board. This felt unintuitive and didn’t really fit with the main mechanic. Then, my roommate Gabe came up with the idea that sliding enemies into walls would hurt them, and the whole thing clicked. Thanks Gabe.

I didn’t really think about [the design] as a simplification of those kinds of games. It was more of a matter of tying ideas together by overlaying new mechanics. A lot of the simplification work came from the games I stole from.

The complexity came naturally out of the main mechanic. Once I had the basic building blocks in, the complicated puzzle solving was already there.

On how Twinfold changed over the course of development

My first sketch of the game was already pretty close to the final product. I think the addition of the wall squashing mechanic was the only major discovery.

There were plenty of minor iterations on the design, though. At first, the numbers only added +1 to their value whenever they merged, which felt unsatisfying. You used to only be able to undo moves that caused a game over.

The enemies used to not get hurt when they ran into walls.  At one point, there was no cap to how much mana you could hold, which encouraged farming and felt grindy. The enemies used to spawn more frequently, to a point where you were constantly only thinking about how to deal with them without having a chance to merge. The danger meter used to be invisible to the player. Most of those changes came from playtester feedback, usually Gabe’s.

On designing the enemies for Twinfold

Most of them were created to counter a single gameplay mechanic. Gray enemies don’t move, blue enemies aren’t affected by walls, purple enemies don’t fall into pits, red enemies don’t get hurt when squashed against walls. Each of those enemy types requires the player to use a slightly different strategy to deal with them. My roommate Gabe came up with the green enemies that only go for the gold, and the evil twin enemies that move the whole board. Those two enemy types appear less often and are there to switch things up every once in a while.

On designing Twinfold’s various skills

To be honest, the skills were the part of the game that I put the least amount of thought into. I knew I had to make a lot, so I just added whatever came to mind as long as they made sense with the game’s mechanics and were easy to implement.

The importance of generated stages

I never considered designing stages for this game, so it wasn't really a conscious decision. I feel like procedural generation is a fundamental part of the experience, and the game wouldn't make sense without it.

I had to do a lot of work to make sure the generated layouts didn’t seem unfair. The biggest challenge I faced, which I didn’t actually end up solving, was figuring out how to keep solutions within a reasonable difficulty range. Between each wall setup, the variance in steps required to pull off a merge can be very high.

To fix this, it would’ve required a special pathfinding algorithm that I didn’t feel like implementing. It probably would've a better game if I'd spent the time to do it, but I don't think it would've been better enough to warrant the effort.

On whether its designs were affected by choice of platform

Yes. I’d never envisioned it as anything other than a mobile game, so it’s hard to say how design decisions were affected by the platform. The fact that most of its major influences were also mobile games probably had a big effect on things.

Things to consider when designing for mobile

I wanted to make sure it was easy to pick up and put down. So, it loads you immediately into the game without making you look at a title screen if you’re in the middle of a playthrough. I also wanted to make sure the game could be played with one hand -- that didn’t really require any extra work, though.