Boss recovery
Playtest feedback said boss fights felt too difficult because health could not be recovered during the fight.
The approved v2.3 plan added RECOVER pickups specifically to close that gap, and RECOVER exists in the current game.
Community / feedback
I want people to tell me when the game is not working.
Feedback is not a ceremonial form at the end of development. I use it to reconsider decisions, find problems I normalized while building the game and notice when something is less clear, less fun or less usable than I thought.
How I treat feedback
Useful input, not a public vote.
I listen closely, but I do not promise to implement every suggestion exactly as proposed. Repeated problems can change roadmap priorities when the evidence says something needs attention sooner.
Report what happened
A short description is enough. A bug report does not need to read like professional QA.
Add context when you can
Device, mode, stage, what you expected and what actually happened make feedback easier to act on.
Expect a decision, not a vote
Feedback can reveal a real problem without making its proposed solution the right one.
Keep the loop open
If a change misses the point, saying so is useful. Iteration is part of the process.
What is useful
You do not need to write professional QA.
Bug reports, gameplay impressions, UI/UX confusion, difficulty complaints, accessibility problems, mobile-control issues, content reactions and suggestions are all useful.
If you can include context — device, mode, stage, what you expected and what happened — it helps. If all you have is “this felt bad” or “I could not understand this screen”, that can still be worth hearing.
Positive feedback matters too. Knowing what already works helps me avoid “fixing” the part that should have stayed alone.
Documented changes
Feedback has already changed real systems.
These examples are backed by project history. The repository does not identify which individual supplied either comment, so I do not attribute them to a person.
Anchored aim stick
Playtest feedback said aim-stick mode needed an anchored base.
The requirement became an anchored stick origin with clamped movement, which is implemented in the current touch controls.
A stage that hurt to look at
The Win11 stage was reported as painfully bright: its field was blowing out to pure white at the centre.
Win11 became dark glass, and every stage theme is now measured against the dimmest entity on screen so a theme cannot blow out again.
Who already changed the game
People close to the project have already had an effect.
Kernel Panic has changed more than once because of people who had real contact with it: my boyfriends, some friends, people who tested the game, a friend of mine who also programs, and others in my social circle who played it, observed the project or talked to me about it.
Their comments have made me reconsider decisions, correct problems or change parts of the game. They may have pointed to gameplay, UI, UX, clarity, difficulty or content. Sometimes something simply was not working as well as I thought it was.
This is not a professional focus group, and I am not presenting these people as testimonials. They are people who actually encountered the project, and their feedback has affected what I develop.
Disagreement
Feedback can be right about the problem and wrong about the fix.
A suggestion is not automatically implemented because several people agree with it. I still have to protect the game's identity and weigh design, scope, maintenance, accessibility, platform constraints and the experience I am trying to build.
But disagreement is not a reason to ignore feedback. If three different solutions all point at the same confusion, the confusion is probably real even if none of those solutions is the one I use.
Accessibility / mobile
Please tell me when the interface gets in your way.
Touch controls, safe areas, target sizes, readability, focus, input assumptions and accessibility settings are especially hard to judge from one machine. Reports from real devices are valuable because they expose problems a desktop development setup can hide.