# [Devlog] We limited path visibility to "2 nodes ahead" to reduce fatigue—but players got lost. Here is how we're fixing it.

We are currently developing CIDER, a deck-building roguelike. Recently, we implemented a new "Map Selection Mode" and ran a user playtest on our initial prototype.

In this post, we will share our design philosophy, the feedback we received, and how we plan to improve our map mechanics based on what we learned.

1. Our Hypothesis: Eliminating "Route Analysis Fatigue"

In genre-defining games like Slay the Spire, players can see the entire map from the starting node all the way to the final boss.

However, we had some reservations about this classic layout:

• High cognitive load: Presenting the entire map right from the start introduces a lot of visual noise.
• Low payoff for high effort: Players often spend significant time agonizing over their routes, but (outside of specific mid-to-late game scenarios) these choices don't always feel impactful enough to justify the mental drag.

To tackle this, we designed a minimalist map system that only reveals up to 2 nodes ahead (Next Next). Our hypothesis was that restricting path choices would keep the game moving at a brisk, high-energy pace.

Here is what the current prototype looks like in-game:

• CURRENT ROOM (Already Cleared): Highlighted with a green border.
• BATTLE (Next Choices): Highlighted with orange borders (Selectable routes).
• FUTURE BATTLE (2 Nodes Ahead): Grayed out and marked as "Locked".

2. The Reality Check: User Playtest Feedback

We invited players from our target audience (gamers who play 10–20 hours a week and are familiar with deck-builders) to test the prototype. It quickly became clear that our minimalist design had created an unintended problem.

"I don't know where I am."

By stripping the map down to just two nodes ahead, we accidentally stripped away the players' sense of progression. Testers repeatedly noted that they felt "lost" or felt like they "weren't actually moving forward."

• The "CURRENT ROOM" Confusion The node at the bottom of the screen is labeled "CURRENT ROOM / Cleared Area." Players found this highly confusing—their mental model was, "If I cleared this room, shouldn't my character be standing on the next node?"
• Lack of Progress Transparency Because players couldn't see how many floors were left until the boss, they couldn't plan their deck-building trajectory. This lack of a clear goal quickly became demotivating.

3. Analysis & Our Next Steps

This test taught us an invaluable lesson: Players don't want to stress over long-term path planning, but they still need to know where they currently stand and how far they are from the goal.

We want to keep our core concept of restricting path branches to 2 nodes ahead, but we will make the following adjustments to restore a sense of progression:

Solution A: Visualizing Overall Progress (Roadmap UI)

While keeping the map's branching paths hidden beyond 2 nodes, we will introduce a progress bar (floor indicator) at the top of the screen. This will clearly communicate the player's exact position relative to the boss.

• Add a visual indicator like: FLOOR 1 / 10 [■□□□□□□□□□] BOSS.
• Remove the text "Locked" from the 2-nodes-ahead preview, replacing it with a simple, clean icon of the upcoming node type (e.g., enemy icon).

Solution B: Polishing the "Current Location" Representation

Instead of relying on text boxes like "CURRENT ROOM" to explain where the player is, we will place a distinct character avatar directly on the map node. When players choose a path, the avatar will physically move to the next node with a smooth transition animation, making progression feel tactile and intuitive.

4. Conclusion & Next Steps

Trying to reduce choice paralysis by hiding information backfired by creating progress anxiety. It was a humbling reminder of how delicate UI/UX design can be.

In our next update, we’ll show you our design mockups for the updated map system, complete with the new progress bar. We also plan to roll out visual updates, animations, and juice up our combat effects. Stay tuned!

Play & Join Our Community!

You can play the latest build directly in your browser for free:
👉 Play CIDER on Godot Games

We are also looking for feedback on our attribute mechanics and general combat feel! Drop by our Discord and let us know what you think:
💬 Join our Discord Server

---

[Behind the Scenes] Battling the Bugs Hidden Under the Map

While the map was our primary focus, our testers also uncovered several bugs and UX friction points in our core combat system. Here is a look at what we've been debugging behind the scenes:

① The "Empty Draw Pile" Game Freeze

• The Bug: "Playing Exploit Search when your draw pile has 0 cards softlocks the game."
• What Happened: We had a card search mechanic designed to pull cards from the draw pile. However, we forgot to write an edge-case handler for when the draw pile size was empty (deck.size() == 0). This caused the loop to search indefinitely or throw a null pointer, freezing the game. It’s a classic card game development oversight—we’ve patched this to fail gracefully.

② Corrupted Text & UI Alignment Glitches

• The Bug: "The search protocol dialog has corrupted characters/garbage text, and the select panel title is broken."
• What Happened: We ran into issues with font rendering and initialization timing on dynamic dialog UI panels. Specifically, the layout container was trying to render text before the component was fully active. We have restructured the UI lifecycle to ensure texts are parsed and rendered only after the parent containers are safely initialized.

③ Floating Hand Cards

• The Bug: "Cards in the hand occasionally overlap, glitch, or get stuck in the wrong positions."
• What Happened: Our cards are programmatically fanned out in an arc based on hand size. If a tester played cards too quickly, or if draw and discard animations fired simultaneously, our positioning logic got out of sync with the animation states. This left cards floating awkwardly in mid-air. We are refactoring the card-state manager to strictly sync state changes with visual positioning.

④ Non-Verbal UX Failures: "How Do I Play This?"

• The Bug: "I played for 30 minutes before realizing the number in the top-right corner of the card was its energy cost." / "Status effects like Void, Exploit, Bind, and Nullify are too hard to understand."
• What Happened: As developers, we look at our own UI every day, so we assumed "top-right = cost" was common knowledge. To a new player, however, it just looked like a decorative element. Similarly, our deep status effect system lacked on-screen explanations. To fix this, we are adding dynamic hover tooltips to explain advanced mechanics in plain text, and we are adding prominent visual effects whenever energy is consumed to clearly link cards to the resource bar.