I have not played it, so I cannot answer any of your three questions and I am not going to guess at them 🎮 What I did instead was go over the page and the metadata, because you said only two people have ever played it, and I think a chunk of that is fixable in about five minutes without touching the game.

Four filter surfaces you are currently opted out of.

itch’s browse sidebar filters on more than tags. It has Input methods, Average session length, Accessibility features and Genre, and each one is driven by a metadata field on your edit page rather than by your tag list. Your info panel currently shows Genre, Platforms and Tags — and nothing else. So:

Input methods is empty. There are Touchscreen and Smartphone checkboxes in that filter, and you have shipped a mobile-first touch game that does not appear under either. That is the single most on-target filter for your game and you are invisible in it.

Accessibility features is empty. Your own description says “one-thumb” and “drag anywhere to move”. There is a One button entry in that filter. Whether that is literally true for you is your call, but right now you are in none of the accessibility filters at all.

Average session length is empty. A survivor-like run is a few minutes, and “A few minutes” is a filter people genuinely use when they want something to play right now in a browser tab.

Languages is empty. You shipped ELEVEN languages, which for a solo browser game is remarkable, and a visitor looking at your page cannot tell. I could not find a language browse filter so I am not going to claim you are losing search traffic — but it is the most impressive fact about the build and the page does not say it anywhere itch renders it.

Your tags themselves are good, by the way — Arcade, Bullet Hell, Casual, html5, mobile, one-button, Roguelite, Survivor-like is an honest, well-chosen set, and you have two free slots. And you are currently #18 on Most Recent for the survivor-like tag. That is real, live visibility, and it is the shelf that expires, so the metadata above is worth doing this week rather than next.

Now two things about the game, from what you described rather than from playing.

The 18% dilution will come back, and a pity rule is what stops it.

You diagnosed that beautifully — the boss was not tanky, the card pool was diluted, so the main weapon never levelled. But you fixed it by fixing the pool, and pool composition is exactly what changes every time you add content. You have over 20 cards now. At 30 you will silently be back where you were, and stage 5 will break again without anyone touching stage 5.

The version that survives content patches is a guarantee rather than a ratio: force the main weapon’s upgrade into the offered set until it reaches level N, or run a pity counter that guarantees it if it has not appeared in the last K level-ups. Then adding cards can never re-break the early game, and you stop having to re-tune the pool every patch.

Airplane mode is a promise your storage may not keep.

A single HTML file with no external dependencies is a genuinely lovely piece of engineering, and it does mean the game keeps running once loaded. But your Candy Shop is meta-progression, which means the thing players actually accumulate lives in browser storage, and browser storage on a phone is not as durable as people assume — iOS in particular will evict script-writable storage for sites that have not been visited in a while, and a game running inside itch’s embed iframe is in a worse position for this than a normal first-party site, not a better one.

The reason this never shows up in testing is that testers play daily. The player who loses everything is the kid who comes back after two weeks, and they will not report a bug, they will just not play again.

Cheap fix, and it is the standard one in browser roguelites: an export/import save code. A blob of text on the results screen that the player can copy somewhere. It costs you a day and it converts a silent, unreportable failure into something a player can recover from.

One last small thing, since you are touch-first and on an embed: make sure the canvas sets touch-action so the itch page underneath cannot scroll or double-tap-zoom while someone is dragging. On a survivor-like where the whole input is a held drag, that one CSS property is the difference between good controls and unusable ones, and it only misbehaves on real phones, never in a desktop emulator.

Genuinely nice to see someone build no-gacha, no-ads, no-FOMO deliberately and say so out loud ⚡

Delighted, and one warning on the export/import save before you build it, because it is the part that usually gets shipped in a form that helps nobody 🎮

Nobody exports a save prophylactically. The player who loses everything is the one who did not think about it, which is by definition the one who never opened your settings menu. If the code lives behind Settings > Export, you will have built a feature that only rescues people who were never going to need rescuing.

So make the game hand it over unprompted, at a moment the player already feels good: finishing a chapter, the first weapon evolution, clearing stage 5. “Here is your save code, keep it somewhere” lands as a reward at a high point and as an ominous chore in a menu, and it is the same string either way. Offering it on a natural beat also means most players will have one before the two-week gap that eats their storage.

Two smaller ones while you are in the edit page:

Only tick One button if it is literally true. Your copy says one-thumb drag, which is a genuinely good accessibility fact, but “One button” in itch’s list means something fairly specific and it is the kind of claim a player checks. If drag-to-move is the whole input, that is arguably closer to Touchscreen plus a note in the description than to the One button entry. Your call, you know the input better than I do — I just would not want you filtered INTO a list by a claim someone disputes.

And on the eleven languages: the metadata field is worth filling in, but the bigger win is one line in the description saying it, because that is the half a visitor actually reads. It is the most unusual thing about the build and the page currently keeps it a secret.

Good luck with the pity counter — that one will quietly save you every content patch from here ⚡

1. Which stage did you stop at, and what made you stop — too hard, too repetitive, or just bored?: Stopped on stage 8. I just stopped to continue working on my game

2. Did the touch controls feel right on your device? (Which phone?): Played on computer, so can't answer this question. Computer controls felt right

3. Stage 5 is the first real boss. Does it feel fair now, or still unfair?: It feels fair.  However, on stage ~7, 2 bosses overlapped for a few seconds. 

I would like a popup about the shop with candy coins at the end of each level.  

For future reference, using "50 stages, no ads, no gacha, works offline" for promotion is too general.  The first sentence should basically be the title.

Balancing: Lv2 donut shield is op, the orbit weapon is far underpowered, the goo weapon is overpowered, and heart regen needs a light buff.  Heart chest should give gem overload at full hearts. For the first ~4 stages, damage buffs were almost useless, as every non-boss would be one hitted from the start. Upgrades on main weapon should show the increase in damage. There is no way I could complete stage 20 with the difficulty scaling. 

I also did not use nuke, as I could not reach for it on computer fast enough. Please make a button for the nuke.

"I'm building this to be something kids can play": This is successful at that.

"Happy to return the favour — drop a link to yours and I'll play it and write you something specific back.": I will come back next week for this, as I'm in active development of my next huge update.

General thoughts

I like the presentation, overall concept, and direction of the game. The mobile-first approach is clear, the UI is clean, and the progression structure makes sense for this kind of experience.

The biggest issue I ran into was the movement controls. I am not sure if I was misunderstanding how they are supposed to work, but movement felt strange enough that I could not always tell whether I was moving in the direction I intended or somehow steering against it. That made the core gameplay harder to read than I expected.

What I liked

• Clean, colorful presentation
• Clear mobile-friendly identity
• Simple progression concept
• I like the overall idea of a lightweight survivor-style game without ads, gacha, or unnecessary friction

What I would change

• I would prioritize making the movement feel immediately intuitive. If the current behavior is intentional, I would communicate it more clearly. If it is not, I would revisit the control feel.
• Keep the progression and upgrade information as easy to understand as the rest of the presentation.
• Continue leaning into the simplicity of the concept rather than adding complexity for its own sake.

Overall, I like the ideas and presentation quite a bit. The main thing holding the experience back for me was that I never fully felt comfortable with the movement, and since movement is such a central part of the game, I would probably focus there first.

Please consider giving my game a try, it’s browser based with a tight 2-3 minute game loop: https://barelyplayable.itch.io/blade-baes-brawl

Feedback form submissions preferred: https://forms.gle/fsJrAZDhJtP1CFXX8

Let me know if you’d like an invite to try the invite-only full alpha build :)