Dev Blog #8 - A Dungeon That Feels Real

First of all, I wanted to share how happy we are that Deep Dish Dungeon has been part of some awesome events recently: the Level Up showcase in Las Vegas, the Raw Fury's Publisher Sale on Steam, and the Medieval Fest on Steam focused on medieval fantasy games. It's been amazing to see the game featured alongside so many great titles, and we're incredibly grateful for all the new players discovering the game.

For this blog post, I wanted to chat about game design and its associated challenges. As you probably know by now, one of the core pillars of Deep Dish Dungeon is exploration driven by curiosity, not some task-oriented UI. So, very early on we decided to design the whole dungeon and not give any map or compass to the players.

It's a bold choice, and it comes with a lot of design challenges, especially in a metroidvania-style game like ours, where players revisit areas multiple times, unlock new paths, and gradually build an understanding of how everything connects.

So what were the key elements for us while designing a game like this?

• First, every room needs a strong identity. If players can't rely on a map, they rely on memory. That means each space has to be visually and structurally distinct. Different silhouettes, landmarks, lighting, and layouts. There can't be too many corridors and labyrinth-style rooms. If two rooms feel the same, the player gets lost in a frustrating way, not a fun way.

• Second, readability is everything. Players need to subconsciously understand where they can go, where they've been, and what might change later. We use framing, lighting, and composition to guide attention. Subtle cues that help players orient themselves without explicitly telling them what to do. But keeping the "open world" vibe, because you'll have many possible paths right from the start of the game.

• Third, connections between spaces need to be meaningful. In a metroidvania structure, discovering a shortcut or a new link between two previously distant areas is a huge moment. Those connections need to feel intentional, so players can mentally "lock in" that knowledge and use it later.

• Another big consideration is backtracking. Since players will revisit areas often, those spaces need to remain interesting over time. This can come from unlocking new interactions, opening paths, or simply seeing a familiar place from a different angle or context.

• And finally, you have to trust the player. Designing without a map means embracing a bit of friction. Getting lost is certainly part of the experience. The goal isn't to eliminate that, but to make sure it feels engaging and rewarding instead of frustrating. But really, getting lost with your friends, is so much fun!

Given all those key elements of design, I also wanted to make one single interconnected dungeon. I didn't want portals or teleports. Also, not just a huge 2D space, like dungeons you see in a traditional tabletop RPG map, but one that would use the vertical space as well. I wanted it to feel real, as it was built in the real world. That decision made things so hard, not gonna lie.

On a personal note, working on the level design for this game has been incredibly fulfilling. I've always been passionate about architecture and interior design, and a lot of those instincts translated directly into how we built these spaces. Thinking about flow, composition, and how people move through environments has been a huge part of the process. Specially because it's a dungeon that was not build to kill you, it was once a real sanctuary that existed and made sense to people living in it.

It's also been amazing to see the reactions from our user testing and QA. Watching players slowly understand the spaces, recognize rooms, and create their own mental maps of the dungeon has been one of the most rewarding parts of development.

I hope you get to play soon, and experience the fun in getting lost and finding your way back to your camp!

Thanks again for all the support. <3 See you in the dungeon!

• Saulo Camarotti Creative Director, Designer and Coder of DDD