The design of Peggle-like dungeon crawler Roundguard

What if you made a Peggle dungeon crawler roguelite? That’s the premise behind Roundguard, “a bouncy dungeon crawler with pinball physics, lots of loot, and a randomized castle full of oddballs.”

In this very entertaining title, your character - a dungeon adventurer - plays the role of the Peggle ball, aimed at the start of each encounter. Other enemies on each map can attack you with ranged or close weapons as you bounce semi-helplessly around the level. Thankfully, you have a host of special powers and weapons to help you get through as you delve deeper into the dungeon!

The Wonderbelly Games and Quantum Astrophysicists Guild-created title just launched on Apple Arcade, Steam, Switch, Xbox One and PlayStation 4, and Wonderbelly co-founder and game designer Andrea Roberts was kind enough to go deep with Gamasutra into the nuance filled design of the entertaining title.

Gamasutra: So - 'it's a Peggle-style game, but a roguelite' is such a winning idea that it's surprising that nobody has done it before. Were you worried that the makers of Peggle would think it was too cheeky to bite their design style?

Roberts: When we first had the idea, we started looking around to see what other folks had already done, assuming there’d be tons of Peggle-likes already out there. We were shocked that barely anyone else has played with the Peggle mechanics in the decade plus since it first came out. Especially when you look at another classic PopCap game like Bejeweled -- it spawned a whole new genre of games with everything from Puzzle Quest to Beglitched.

Peggle has such a strong, satisfying foundation, with lots of room to mix in new ideas. We wanted Roundguard to honor that Peggle foundation, and we were pretty confident that the new ideas we wanted to add would make Roundguard a clear concept of its own.

That said, it's been extremely gratifying to get the blessing and support of several of the original Peggle developers. It was a high point for me when I showed the game to Jason Kapalka at GDC last year and he gave us a big thumbs up -- plus a bunch of very helpful feedback.

Did you use beta testers privately in addition to QA testers, and if so, at what points during the process? How did you capture their feedback?

We started a closed beta last June with around a hundred players, and we brought in another couple hundred right up until launch, mostly from folks we'd met at conventions. For bugs, we used an in-game button that captured some data and sent it back to us, but for feedback, we mostly used our Discord.

We had channels to discuss issues and strategy, and a feedback list where players could submit ideas and upvote others. We did polls along with our weekly patch notes. We even had (and still have!) a channel where players can build and submit their own board layouts. A lot of the most fun board ideas came from the community.

All in all, running a beta was a wonderful experience for us. It was a lot of work to maintain, but we got a ton of valuable feedback and testing from the community, and they kept us motivated and inspired to keep moving forward. Plus, they're a bunch of cool, funny people who kept me company through the long, long game dev hours.

The game has a refreshingly simple and understandable health and mana system. Was that how it originally started out, or did you tweak it over time?

It definitely morphed in the first few months before we landed on the right feeling. In the very first design notes, I had considered an even simpler health system when everyone's health would be expressed like one, two, or three hearts, with each heart representing one hit of damage.

I didn't want players to feel like they had to do a bunch of math before every shot. But ultimately, we found so much more design space when we used a more granular health bar for heroes and enemies, with more opportunities to make enemies and equipment properties feel unique.

Mana, on the other hand, started out more complex. Originally we planned on having skills that had different mana costs. But the player has to react quickly and improvise to use skills well, and there isn't enough time to do math while you're bouncing around. We eventually settled on the rule that all skills cost 10 mana, so that the player can do a very quick calculation to figure out how many skill uses they have left at any moment.

What were the other major design changes as the product evolved? What did you have to cut that people might be surprised about?

It’s not particularly surprising, but we have reams of fun ideas for new monsters, heroes, modes, and classic roguelike secrets that are still in the icebox. We’re planning to add more to the game post-launch, but there will always be ideas that never make it in. However, the biggest and probably most surprising design shift happened in the first couple of months.

When we first sketched out the original concept, it was not a roguelike, but instead a more traditional puzzle RPG like Puzzle Quest, with a campaign map and defined boards. At the time, though, we were playing a ton of roguelike genre mashups, like FTL and Enter the Gungeon, and the pull was strong. We were intimidated (rightfully) by the amount of work procedural generation requires, but designing systemic rules was a lot more exciting work than mapping out defined boards.

The promise of endless replayability -- of a game that could still surprise and entertain me after years of working on it -- was so huge, and it felt like the right call for the audience we imagined. I think the RPG game would have been easier in the end, but I had so much more fun making Roundguard than any game I’ve worked on in the past, so it’ll be hard for me to ever turn away from procedural design after this.

The concept that the enemies can hit your player while you're being shot around the levels adds strategy to the 'Pegglelike' formula. How did you communicate this to the player and balance it?

This concept is at the core of the game and was there from our very first prototype, but it was surprisingly difficult to communicate and took us many iterations to get to where we are now. The idea that when you hit monsters, they hit back was very much inspired by classic turn-based roguelikes.

We figured that monsters are inherently intimidating, so it should be intuitive that when you fling your hero's face into one, you're going to take a little beating. But in our first playtests, we repeatedly saw some players not understanding how they were getting hurt.

We started layering on more and more feedback. When the hero collides with a monster and they each damage each other, then a lot of things happen: they make an animation and yelp, the screen shakes and flashes red, damage numbers fly out, the controller rumbles, particles poof, the hero and the monster flash white, and the side banners for the hero and monster bounce on the side walls.

Each bit of feedback we added helped, but the step that finally fixed the problem was just making a stronger tutorial. Once we removed all other distractions and focused first on methodically stepping players through the concept that 1) you need to hit monsters and 2) they will hit you back, the communication problem disappeared.

I had resisted a heavy-handed tutorial for so long because I had the lofty goal that the game shouldn’t need one -- I wanted to get players quickly into the game where they could learn on the go. It was silly how much hair-tearing was caused by the problem when, in the end, I really needed to respect that some players just needed a couple of minutes of focus and clarity.

Roundguard also uses narrative in cute Ms. Pac-Man-style 'vignettes'. Why did you decide to include this? (Many roguelites dispense with narrative entirely.)

We knew we wanted the game to be a light-hearted experience that made you smile, and random encounters with cheeky NPCs was a great way to add more character and slip in a few silly jokes. I love funny games and I come from a background in narrative design -- working on the writing team for Fable III was one of my first jobs in the industry -- so it felt like a natural fit.

But it also gives the game a nice change in the pacing, where players can sit back for a minute, and then at the end of the conversation, they get a new quest or a trinket that propels them into the next room and makes them think about it in a new way.

Do you ever fudge gravity in the game, or is it 100 percent normal Earth gravity at all times?

We never change the gravity on you, but it is very much not normal Earth gravity. Tuning the gravity / mass / bounce restitution to get just the right feel was one of the biggest challenges of the game and we changed it several times on the way up to launch. We wanted the hero to have enough air time so that the player had adequate opportunities to respond with skills, but we wanted to keep bounces feeling solid and weighty.

Ultimately, we found that slowing down the simulation time was one of the more effective ways to dial in the right feeling, so the entire game actually runs at about 90 percent "real time" physics. We also found that there were some places where everyone feels like physics should act one way -- even when that's completely inaccurate. So we make some tweaks, like giving the side walls extra horizontal bounce impulse, to make it feel more like what people expect.

What's the most surprising thing you learned while developing this game, game design-wise?

I’ve always been a huge proponent for playtesting, but in the past, it’s felt like a slog to keep making fresh demos, reworking the first few minutes of gameplay over and over when there’s so much other work to do. For Roundguard, though, I was surprised at how well procedural design goals aligned with keeping a constantly fresh and functional demo alive.

Once we got to a truly procedurally generated demo, then our demo experience wasn’t just the few first minutes of gameplay -- there was a whole swath of possibilities that covered systems from across the game, so there was always something new to learn from every playtest.

And likewise, because every new element added to the game needed to interact systemically with everything else, I couldn’t just go off and work on something broken in the corner for months -- there was a constant pressure to iron out all the edge cases and fold it into the main system so that we could see it working at all.

Working on a procedurally generated game meant that we were always working with a living, playable game, and that meant that I always had something ready to show at a meetup or a convention.

I don’t think we ever went for more than a couple of months throughout the development process without getting a new set of fresh eyes on the game. It was a hugely valuable process -- it made the game stronger and it made me a stronger designer -- and it’s something I want to recreate on our next projects going forward.