"Our Roguelike Became a Puzzle Game: Vision-Safe Pivots"

From Dungeon Crawl to Mind Bender: How We Reinvented Our Game

We started with a vision: a brutal roguelike dungeon crawler. Players would navigate procedurally generated dungeons, battle hordes of monsters, and desperately try to survive. We had the procedural generation humming, the combat system was crunchy, and we were ready to build out content.

And then we played it. Really played it.

The Wall We Hit

The core gameplay loop wasn’t fun, not in the way we wanted. The procedurally generated dungeons felt same-y after a short time, even with variations. Combat, while initially engaging, became repetitive and ultimately unsatisfying. We were pouring time into content generation, but the underlying experience wasn’t improving.

We fell into the common trap: focusing on features instead of feeling.

The initial vision hinged on the assumption that procedural generation plus challenging combat equals engaging gameplay. Wrong. We needed a stronger core mechanic. The core gameplay loop lacked a compelling player verb – something players could reliably and consistently do that felt meaningful.

The Puzzle Emerges

The problem with our roguelike wasn’t just a lack of fun; it was a fundamental disconnect between what we thought the game was and what it actually was. The dungeon crawling felt less like exploration and more like navigating a series of increasingly complex rooms. The combat felt less like tactical decision-making and more like pattern recognition.

We realized we were inadvertently creating a puzzle game dressed up as a roguelike.

This realization was gradual. It began with tweaking enemy AI, making them more predictable but also more strategically placed. Then, we started limiting the player’s resources, forcing them to carefully consider each action. We were, unknowingly, introducing puzzle-like constraints.

For example, we initially had a wide range of enemy types. We found that players quickly defaulted to a few optimal strategies against each type. We simplified the enemy roster to a few core types with predictable behaviors, but then introduced spatial arrangements that forced players to consider their movement and attack order. This was the genesis of the puzzle aspect.

Embracing the Pivot

Acknowledging the shift was the hardest part. We had spent months building a roguelike. To abandon that was scary. But the more we leaned into the puzzle elements, the more engaging the game became.

We started designing levels with specific solutions in mind. We introduced mechanics like limited moves, environmental hazards, and resource management that explicitly challenged the player’s ability to solve spatial problems.

One key change was shifting the perspective from top-down to isometric. This improved clarity when viewing potential paths and enemy placements. We also toned down the emphasis on randomness. Procedural generation became less about creating totally new environments and more about arranging pre-designed puzzle elements in unique configurations.

The combat system became less about brute force and more about clever positioning and timing. Instead of simply attacking enemies, players had to manipulate their environment to create opportunities for attack. For example, pushing an enemy into a pit or triggering a trap.

Addressing Initial Limitations

The pivot directly addressed the issues we faced with the roguelike design. The repetitive nature of combat was replaced with a focus on strategic planning and problem-solving. The same-y dungeons were replaced with handcrafted puzzles or curated random configurations designed to test the player’s skills.

The lack of a compelling player verb was resolved by giving the player a clear goal in each level: solve the puzzle.

Vision limitations forced a change of scope. Building vast procedural dungeons proved inefficient, but curating specific puzzle challenges was more manageable. The shift also narrowed our target audience to puzzle game enthusiasts, which made marketing and design choices easier.

Testing and Validation

Before committing fully, we ran a series of playtests focusing on puzzle mechanics. We created several small, self-contained puzzle levels and observed how players approached them. This allowed us to iterate on our design and refine the puzzle mechanics without having to build out an entire game.

We focused on metrics like:

• Completion rate: How many players could solve the puzzle?
• Solution time: How long did it take players to solve the puzzle?
• Hint usage: How often did players rely on hints?
• Qualitative feedback: Did players find the puzzle fun and engaging?

This data helped us fine-tune the difficulty and identify areas where the puzzles were unclear or frustrating.

The biggest mistake we saw other developers make was clinging to the initial vision despite the data. Be willing to let the game tell you what it wants to be.

Managing Expectations

Pivoting is emotionally taxing. Team morale can suffer. To mitigate this, communicate clearly and transparently about the reasons for the change. Emphasize the potential benefits of the new direction and involve the team in the decision-making process.

Another key aspect is to manage your own expectations. The pivoted game may not appeal to the same audience as the original concept. This requires a shift in marketing strategy and potentially a re-evaluation of your target market.

The final build will not look like the initial mock-ups. This is normal. Allow the project to grow organically without rigid adherence to dated ideas.

Actionable Advice for Developers

• Prototype early and often: Don’t wait until you’ve built a substantial game before testing your core mechanics. Prototype the core gameplay loop as quickly as possible and get it in front of players.
• Listen to your players (and the game itself): Pay attention to how players actually play your game, not how you think they should play it. If players are consistently using your game in a way you didn’t intend, consider embracing that behavior.
• Don’t be afraid to iterate: Game development is an iterative process. Be willing to experiment with different ideas and mechanics, and don’t be afraid to scrap features that aren’t working.
• Manage your scope: Be realistic about what you can achieve with your available resources. It’s better to create a small, polished game than a large, buggy one.
• Communicate openly: Keep your team informed about your progress and any changes to the project. This will help maintain morale and ensure everyone is on the same page.
• Test frequently and broadly: Continuous testing is essential for validating design choices and identifying potential issues.

Pivoting is not failure. It’s an opportunity to create something even better than you initially imagined. It’s a testament to flexibility and understanding what your strengths are.