What Early Playtesting Reveals: Lessons from Astro Burn

There’s a point in development when the game finally seems to behave.
You know where everything is, the tutorial seems clean to you, the controls feel natural, and the first level holds together.

It’s easy to look at all that and think the hard part is over. Some developers stop there. Others bring in players to make sure their impressions match reality.

The real change happens when you test not to confirm things are working, but to see what people aren’t understanding yet. It’s a small shift in thinking, though it can change the whole direction of a project.

That’s why we talked with Haz: a film maker who worked on major films like Hellboy II and The Dark Knight, now working full time as an indie game developer as "Beyond The Pixels".

He spent a lot of time watching people play his game, Astro Burn to pay attention to the quiet moments where confusion appears. We asked about how he approaches testing, what he looks for, and what might help solo devs who feel unsure about sharing their game with real players.

Here is the conversation that we had with Haz:

I often advise starting to test the game as early as possible to quickly find the parts that could stop players from connecting to it. In the case of Astro Burn, how early did you start testing parts of the game, and which parts?

I started playtesting as early as possible, as soon as I had a rough version with placeholder graphics, I started getting people to playtest mainly from a conceptual point of view, to see if this is going to be a fun game or not. This was around April, and I started early dev on the game in Mid-March.

Why did you decide to start testing your game at that point in development?

I’ve always believed that today’s audiences have more influence than ever over the entertainment they consume. In film and TV, that feedback loop is harder to integrate because once you lock the script, that’s it. But games are different; they thrive on player agency and constant iteration, and that naturally invites the community into the process. With Astro Burn, I wanted to fully embrace that.
Even in the early stages (placeholder art, wireframe menus, rough builds) I felt it was important to get the game into players’ hands as soon as possible.
Part of that is practical: I’m self-financing the project, so releasing a game into the world without validating the concept felt like an unnecessary risk. But it was also personal. I didn’t want to sit in a bubble, convinced my own idea was amazing without truly knowing how it landed with real players.
Early playtesting grounded me. It challenged assumptions, highlighted what resonated, and ultimately helped shape the identity of the game. Bringing the community into the journey from day one wasn’t just a strategy... it became one of the most rewarding parts of the development process.

When creating an interactive technology, we often have doubts about whether a design choice will be clear enough for a player. When you started testing, what were the parts or interactions you wanted to specifically observe, and what “worried” you about them? 

When it comes to user experience, my North Star has always been instant accessibility. With Astro Burn, I kept going back to the retro ’90s games I grew up with: where a D-pad and two buttons were enough to learn everything you needed within seconds. No manual, no long onboarding. That mindset shaped a lot of my early playtesting goals. Because Astro Burn is a side-scrolling shoot-’em-up, I didn’t want players bogged down by tutorials or confusing UI. Ideally, the first level is the tutorial teaching the core ‘stack your weapons’ mechanic simply by letting players discover it in action.
UI was deliberately minimal: health, score, time, and your current weapon. Clean, readable, nothing that competes with the chaos on screen. But the part that genuinely kept me up at night was the balance between arcade-style intensity and storytelling. A SHMUP is naturally a barrage of lasers, explosions, and constant movement, and if you’re not careful, players can hit “bullet-hell fatigue.” So during testing, I specifically watched for:

• Whether players understood the moment-to-moment flow without instruction
• Whether the chaos felt exciting or overwhelming
• How quickly they grasped weapon stacking
• Where their attention went during story beats

To counter fatigue, I design with rhythm in mind. Roughly every 30 seconds, something new happens: a fresh enemy behaviour, a visual switch-up, a small surprise. It keeps players curious, even mid-chaos. Then there are the short story interludes with Astro and AL for intentional micro-breaks. A moment for players’ brains (and fingers) to breathe before jumping back into the madness. That balance between intensity and narrative is the heart of Astro Burn. It’s not dodging lasers only, I wanted to give players a journey that felt alive, dynamic, and emotionally anchored.

It isn’t rare to look for answers about specific interactions and end up spotting issues we didn’t know existed. Is there something players revealed that you didn’t include in your research objectives?

This was one of the most iconic — and honestly one of the scariest — moments of the entire project.
It was the point where I realised Astro Burn needed to shift from a traditional SHMUP into a full-on cute-em-up. That decision didn’t come from a design document; it came directly from the community… and a very insistent voice in my head saying, “Listen to the players. Give them what they’re actually responding to!”
What became clear through feedback was that players weren’t drawn in by the idea of another spaceship shooter. Steam already has plenty of those. They were downloading the demo because of the cat character on the thumbnail. But once inside the game, they felt a disconnect: the cat was just a character skin sitting on top of a very conventional sci-fi SHMUP.
That was the spark. I realised the game needed a stronger identity. Something that wasn’t just a lore choice, but a full creative direction. So I tested a theory: I swapped the original boss with a giant cute panda riding a mech, posted a screenshot on social media… and instantly people reacted. Likes, comments, double-takes... it was obvious I’d been playing it too safe.
Players wanted something unexpected, something joyfully weird, something that made them smile or go, “What the…?”. That pushed me straight back to my ’90s roots, remembering how Konami’s Parodius and Pop’n TwinBee made me feel. That wonderfully bonkers, anything-goes energy. From that point on, I committed. I brought on the incredible Japan-Canadian artist  Q Yoneda, who immediately understood the direction. Together we redesigned the entire look of the game starting with making Astro a cuter, more expressive cat, and replacing the player spaceship with a jetpack-strapped astronaut cat flying through chaos.
We swapped hard sci-fi explosions for rainbows, hearts, and joyful bursts of colour. The tone shifted from serious to fun. From mechanical to magical. From expected to delightfully unhinged. And honestly? The world could use a little more warm, fuzzy, joyful chaos. That’s exactly what players helped us discover, even before we realised it ourselves ☺.

When you watch someone else playing your game for the first time, what are the subtle behaviours or “moments of hesitation” you pay closest attention to?

When I watch someone play the game for the first time, I’m always looking for those tiny moments of hesitation: the places where their instincts don’t match what the game expects. The first public build I tested at a small indie event was a great example: players naturally pressed A to fire… but I had mapped shooting to X. The confusion was instant. I went home that night and immediately remapped the controls.
Story pacing was another big one. Players wanted to enjoy the dialogue and world-building, but also wanted the option to move through it faster. My first “Skip” button skipped the entire cinematic, which led to feedback like: “I wanted to read it... just faster!” So I added a proper fast-forward option instead.
Difficulty tuning is a huge area I pay attention to as well. In the early build, the game was brutally hard right from the start. I remember one player saying it was “frustratingly good but very annoying!” before walking away. At the time I didn’t know whether to laugh or cry, but it made something very clear: the difficulty curve needed to ramp, not spike.
These subtle player reactions are invaluable. They reveal design blind spots instantly and help shape a smoother, more natural experience.

Why would you say those matter more than - say - explicit feedback like “I don’t like this”?

Because those subtle behaviours tell you why something isn’t working. Explicit feedback like “I don’t like this” is too broad to act on, but observing hesitation, confusion, or unexpected behaviour gives you meaningful, actionable insight. It reveals sentiment -not just opinion-, helping you understand the underlying issue rather than the surface reaction.

Many solo developers fear sharing a rough or incomplete build, worrying that it will feel too unpolished. Why can early testing be more valuable than a smooth first impression?

I completely understand why many devs hesitate to share rough or incomplete builds. Online feedback can be brutal, and there’s always that fear of damaging your game’s reputation before it even has a chance. I was told many times, “Don’t show anything until it’s ready. First impressions matter.” And yes, that’s true… but only to a point.
What I’ve learned is that early testing is far more valuable than a perfectly smooth first impression. When you involve the community early, you give yourself time to fix issues before they become expensive or overwhelming. You get real insight, real reactions, and real opportunities to course-correct long before you’d ever want the wider world to judge your final game. But there’s something deeper too: early testing makes the process feel collaborative rather than isolating. As an indie dev, it’s easy to fall into the mindset of making a game in a bubble and hoping people will love it once it’s “perfect.”
In reality, bringing players in early helps shape a better game, and helps you feel like you’re building with a community, not just presenting something and crossing your fingers. For me, that connection and shared shaping of the vision is worth far more than a flawless first impression.

What’s the one main thing you wish solo developers understood about player testing?

Do it as early as possible!
And have a system in place to make the onboading of playtesters slick, for me I use Firstlook.gg which is fantastic and there is a free tier for indies!

💡Testing with players might be a little daunting

Nothing compares to see real people play your game note their reactions to your tutorial, menus and game progression.

Taking the first step towards improvement might feel overwhelming. So, to help you prepare your first player test here are 2 ways to level-up your Interaction Design skills: