DEV Community

Cover image for A Roguelike Has Two Progression Loops. Make the Boundary Visible.
Krishna Soni
Krishna Soni

Posted on Originally published at global.krizek.tech

A Roguelike Has Two Progression Loops. Make the Boundary Visible.

A sunlit forest path, an illustrative photograph rather than game footage

Illustrative photo by Maksim Shutov on Unsplash, not Ghost of Yōtei footage.

A perk chosen between enemy waves and an upgrade bought before the next run answer different player questions.

The first asks: What can I try right now? The second asks: What new possibilities have I earned for later?

That distinction is the most useful design idea in Sucker Punch's September 3 description of Ghost of Yōtei: Most Wanted. The announced single-player survival mode offers perks during runs and Mon that players can spend outside runs on techniques, weapon upgrades, charms and character unlocks.

I like this as a design reference because it connects a moment-to-moment combat decision to a longer-term reason to return. It also gives developers a very practical communication problem: make those two kinds of progress easy to tell apart.

Start with the announced mechanics

According to the studio, players select a bounty, fight waves and minibosses, and build toward that bounty's final boss. Perk choices help shape the run. Outside runs, Mon supports additional unlocks and upgrades.

The studio also says cosmetics earned in Most Wanted become available in the main game. That is a third relationship worth explaining: an unlock obtained in one mode can have value somewhere else.

These are announced features, not findings from my own playtest. Most Wanted is scheduled for October 1, with October 2 availability in some territories. The announcement does not document its save format, failure-recovery logic or every rule governing what persists. The engineering exercise below is a proposal for a small prototype, not a description of Sucker Punch's implementation.

Give each reward a lifetime

Imagine a wave-combat prototype with three deliberately simple reward types:

  • A temporary parry bonus selected during the current run.
  • A character unlock purchased between runs.
  • A cosmetic that can be equipped in both combat and exploration modes.

Before implementing the reward screen, write down its contract: when the effect begins, when it ends, where it can be used, and what the player should see after returning to the menu.

For the temporary bonus, the proposed rule might be "active until this run ends." For the character, it might be "available when starting any later run." For the cosmetic, it might be "owned once, selectable in either mode."

The important work is choosing those rules explicitly. A reward's name or rarity color does not explain its lifetime.

Let the interface explain the boundary

A reward card can show its scope alongside its effect:

  • This run: improve the current build.
  • Future runs: expand your starting options.
  • Across modes: add something you can use elsewhere.

Those labels are examples for the prototype, not proposed replacements for the announced game's terminology.

At the end of a run, show what the player earned and what changed in their persistent collection. Avoid one undifferentiated "progress" total if it hides the difference between a temporary combat effect and a lasting unlock.

This can support experimentation. A player may be more willing to try an unfamiliar build when they understand which choices are temporary. That is a design hypothesis to test, not a guaranteed retention improvement.

Test transitions, not just reward animations

For the prototype, I would test these transitions before adding a larger reward pool:

  1. Select the temporary bonus, finish the run, and start another. Confirm that its effect follows the stated lifetime.
  2. Buy a character unlock, return to the menu, and relaunch. Confirm that the selection screen matches the saved ownership state.
  3. Earn the cosmetic, change modes, and equip it. Confirm that ownership carries over without requiring a second purchase.
  4. Interrupt a save or receive the same reward event twice. Define the expected recovery behavior and verify that it neither loses nor duplicates the entitlement.

These are proposed QA cases, not reports of bugs in Most Wanted. Their value is making the promise inspectable before players have to guess.

The exciting part of a new survival mode is the build you have not tried yet. Clear progression boundaries help the player understand how to reach it.

Which reward boundary is hardest to communicate in your game: duration, ownership or cross-mode availability?

Primary source: Sucker Punch's Most Wanted breakdown on PlayStation Blog.

Full KRI ZEK State of Play roundup.

Download Altered Brilliance: https://play.google.com/store/apps/details?id=tech.krizek.alteredbrilliance

Global website: https://global.krizek.tech

Pre-register for Arzenal Human Health: https://play.google.com/store/apps/details?id=tech.krizek.arzenal

Join The Power Of Gaming: https://discord.gg/sbYSPcCqJn

Top comments (1)

Collapse
 
denshin profile image
Denshin Team •

duration, for us. we run seasons, and what resets vs what carries over has to sit on the card itself, a faq page nobody opens doesn't count. writing the lifetime down before building the reward screen is a good habit, rarity color really says nothing about it )