Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

I Made a Free Browser-Based Lunar Lander Game—Could You Give Me 5 Minutes of Honest Feedback?

A topic by Impulsive_Solutions created 5 days ago Views: 353 Replies: 25
Viewing posts 1 to 12
(+1)

I made this game as a way to learn Godot. I wanted a manageable project where I could put my own spin on something familiar, so I decided to make a Lunar Lander–style game.

The game is mostly finished, and I learned a lot while making it. I think it turned out well, but what surprised me most was that I genuinely found it fun to play. Maybe I’m biased because I made it, but a few friends have enjoyed it too—and they’ve already asked whether I plan to add more levels.

That’s why I’d love some feedback from people who don’t know me. Only a handful of people have tested it so far, so I’d especially like to know:

  • Does it run properly on your device?
  • Is it fun to play?
  • Do you think it’s worth expanding?

It’s a free learning project, not something I’m trying to make money from. If people enjoy it, though, I’d love to add more levels, checkpoints, upgrades, and other features.

The game runs directly in your browser. If you can spare five minutes to try it and tell me what you think, I’d really appreciate it!

Play Pegasus Lander: https://impulsive-solutions.itch.io/pegasus-lander

(3 edits)

I played the web game on PC and it ran smoothly. It took me about 20 tries to successfully land for the first time—it's fairly challenging but still enjoyable. (I wasn't aware that the left and right arrow keys could be used for controls.) That said, I don't think it necessarily needs further expansion. I do wish the level selection and retry mechanics weren't quite so punishing.

(+1)

There is a disabled abort system in the game. On an abort press the lander seperates and the capsule is launched up, if you clear the screen you get a free retry. I disabled it because in my own playtesting I thought it made things too easy. I'm considering enabling it before I wrap this up. 

Thank you for taking the time to play it and the time to give me your thoughts on it. I appreciate it.

There's actually a more specific reason I missed the left/right arrows: I did go through the tutorial, but since English isn't my first language, it didn't naturally click for me that "←" or "→" meant additional controls.

Neat little game but level 3 caught me off guard, who puts a tank on the moon that tries to shoot you! What kind of 5000 dimensional mooninites greet innocent landers with anti-air fire!

The auto-level button and the left/right arrow keys are kinda too good, you generally don't need to use the thruster until landing to slow down.
If you want to add challenge, make the lander lopsided in terms of center of gravity (e.g. it tilts to the side more on side - like Desert Bus drift to the right).

The enemy sprites are small in game, but you can see on the report screen when you're shot down these are Soviet rovers. And I understand your point about RCS thrusters and the auto level button almost being too good. I just couldn't accept a moon lander without reasonable controls. Enemy fire is the mechanic I choose to make its so it's not too easy.

Thank you for playing and taking the time to let me know what you thought.

Nice work for a learning project! Are you planning to add more levels or challenges?

(+1)

I was considering eight additional levels with a new lander, new abilities, and a new enemy type. But between the feedback here and the fact I won't be learning anything new making those systems I don't think I'll be doing that. I'll just tighten it up to resolve some issues people pointed out and call the project finished.

Thank you for taking the time to try it out.

(+1)

Nobody has named the most actionable thing in this thread yet, and it is sitting inside nknknk3’s reply 🚀 — “I wasn’t aware that the left and right arrow keys could be used for controls.” That is not a small aside. That is somebody playing your whole game without knowing half the control scheme, and then reporting on how it feels. Worth treating as a bug rather than a note.

There are two candidate causes and they need completely different fixes, so it is worth finding out which one you have.

The first is discovery. Controls written on the itch page below the embed are effectively invisible: people click Play and start pressing things, and almost nobody scrolls down first. If the controls exist only in the page description, the safe assumption is that they were never read. Level 1 is the only place you can reliably teach them, and it teaches best by requiring them rather than describing them — a first level that simply cannot be completed without rotating forces the discovery in about five seconds and costs you no text at all.

The second is the itch embed keyboard trap, which produces this exact symptom, and I would rule it out before redesigning anything. Inside an itch iframe, arrow keys go to the page and scroll it until the canvas actually has focus. So a player can press left and right, watch the page move instead of the lander, and quite reasonably conclude that those keys do nothing. The fix is to focus the canvas on load and again on pointerdown, and to preventDefault the arrow set. It is cheap to test: open your own page, click Play, and press an arrow without clicking on the game area first. If the page scrolls, that is your answer, and it has already cost you at least one tester’s impression.

On whether it is worth expanding, I would read your own thread as “not yet”. Two of the three people who played it mentioned the retry or level-select loop being punishing, and one told you outright that it does not need expanding. More levels multiply a punishing retry loop rather than fixing it. In a precision-physics game the highest-leverage change is almost always making failure cost nothing but time: instant restart on a keypress, no menu round trip, no confirmation dialog, no watching an explosion you have already seen forty times. Get it to the point where a crash makes people say “again” rather than “ugh”, and then the extra levels are worth building, because then each one gets played instead of abandoned.

I should be straight that I am going off your page, this thread and your description rather than a play session, so weight the difficulty read accordingly — the two people above actually flew it and I did not.

One question: when a landing fails, how many inputs does it take to be flying again?

(2 edits) (+1)

Well, I suppose it was an oversight to assume that displaying the controls during the tutorial would get everyone up to speed. If someone skips the tutorial and jumps straight into the game, they have no way of knowing the controls.

The pessimist in me might say, “If you skip the tutorial and don’t know the controls, whose fault is that?” The realist in me knows the answer: it’s mine. I thought displaying the controls again during the first level would be redundant, but clearly it wouldn’t be.

It only takes one key press to start flying again after a crash. Six seconds from crash to starting another attempt. My ideas for expanding the game involved giving the player additional abilities in a new set of levels, with a checkpoint at that transition so they wouldn’t have to restart from level one. The game currently has eight levels, and I agree that simply adding more without changing the gameplay loop wouldn’t be very engaging.

I don’t think I’ll expand it further, but I’m glad to receive feedback that can help me make a few final improvements before calling it finished.

Thank you for taking the time to give me your impressions.

Spent some time testing it out—the core physics mechanics are functional, well built, and fun to play.

A quick breakdown of thoughts and observations from my test pass:

  • 🚀 Controls & Rotation: Navigating with main thrust and horizontal RCS feels good. I actually completed missions without ever needing to use the rotate mechanic, so tuning the level design to enforce rotational adjustments might give that input more purpose.
  • 📐 HUD Obstruction: The HUD elements in the top-left and top-right corners occasionally block the view of the lander during high-altitude or wide-angle flights. Adding slight HUD transparency when the ship passes behind it would fix this easily.
  • 🎵 Audio Atmosphere: A subtle background music track would add a lot to the atmosphere and keep the momentum going during long descent attempts.
  • 🧭 Onboarding Prompt: Players who miss the "Tutorial" button on the main menu might get thrown into the deep end. Adding a subtle "Try the Tutorial first!" prompt on first boot would make onboarding super smooth.

I logged full environment specs, input checks, and test cases in a Notion report if you'd ever like to check it out.

Awesome work on this build!

(+1)

I'm glad to hear the same thing from multiple people. These are all pretty easy issues to knock out.  I'll work on a final build this weekend with all this in mind. Thank you for your input and time.

Feedback exchange if you’re interested? :)

(+1)

Sure! I'll take a look this weekend.

Sounds good likewise!

One keypress and six seconds is genuinely good, so scratch most of my retry-loop worry 🚀 — that loop is not what is costing you. The only thing left in it is whether those six seconds include an explosion you cannot skip; letting the same keypress interrupt the death animation takes it to about two.

But I want to push back gently on the conclusion you drew, because the thread has since said something louder than the controls point, and you are about to ship a final build against the wrong fix.

Three people have now independently told you the rotation input is optional. nknknk3 finished the game without knowing left and right existed at all. iria-1342 said the auto-level button and the arrow keys are “kinda too good”, and that you generally do not need the thruster until landing. feramalli said it outright: completed missions without ever needing to use the rotate mechanic.

That is not a discovery problem. A control that nobody discovers and nobody misses is not undertaught, it is unnecessary. Adding a controls reminder to level 1 would make players aware of an input they still will not need, which reads as clutter rather than onboarding. The fix is in the level design, and feramalli named it: one or two landing sites that cannot be reached without rotating. That is a terrain edit, not a system.

It is also worth noticing what nknknk3 added after my post, because it kills my discovery theory as well as your tutorial-skip one. They did go through the tutorial. The problem was that the glyphs “left arrow” and “right arrow” sitting in an English sentence did not read as “press these keys” to a non-native English speaker. That is a third cause, and it is exactly why a level that requires rotation beats a written reminder: it is language-independent, and nobody has to read anything to learn it.

One knock-on, since you mentioned it earlier: your disabled abort system might be worth re-measuring afterwards. You judged it too easy against a version of the game where the hardest input is not load-bearing. Make rotation matter and the difficulty baseline moves underneath that judgement.

Good luck with the final build — landing it and stopping is a real skill, and plenty of learning projects never get that far.

(+1)

Thank you for taking the time to follow up with such a detailed response. You’ve raised several good points, so I’d like to address them individually.

On the retry loop: the six seconds include the crash animation, which currently can’t be skipped. Allowing the restart key to interrupt it is a good suggestion. It would preserve the crash effect for new players while letting returning players restart more quickly.

On rotation being optional: I’m not convinced that rotation is unnecessary. It’s useful for dodging enemy fire, particularly later in the game. The fact that some players completed missions without rotating may indicate that they didn’t play long enough to reach situations where it becomes valuable. What I still need to determine is whether they stopped because they became bored, frustrated, or simply felt they had seen enough.

I also think rotation belongs in this kind of game regardless. A maneuverable spacecraft being unable to rotate would feel strange. The question isn’t whether rotation should exist, but whether the game gives players enough reason and opportunity to learn how useful it can be.

The point about the tutorial symbols is helpful. I hadn’t considered that the arrow keys might be unclear to non-native English speakers, so the controls may need to be communicated more visually.

Thanks again for reading the other feedback and putting this much thought into your response. Your input has been great.

Playtime About 15 minutes

This is not really my genre or topic area, so I am definitely coming at this as a newer player rather than someone already familiar with lunar lander games.

  • Always glad to see more games built with Godot. This feels like a very clean, understandable project and honestly seems like a great example to learn from if someone wanted to study a focused physics-based game.
  • The basic concept was very easy to understand. Thrust, rotation, momentum, landing, and failure all communicate pretty naturally once you start moving.
  • I would make the instructions slightly more beginner-friendly. I understood the arrow controls immediately, but I had no idea what RCS meant going in. I was able to figure it out from context, but spelling it out as something like “RCS / attitude control thrusters” the first time would remove that little bit of friction.
  • I did encounter what appears to be a repeatable freeze on Chrome in Windows 11. At first I thought it was random because I could not consistently reproduce it, but after trying again it seems to happen when I spawn and press W. The game appears to get stuck or freeze at that point. I would definitely investigate that input path specifically.
  • The HUD and feedback are generally clean. I would still prioritize making the most important flight information and safe-landing requirements immediately readable, especially for people who do not already know the terminology.
  • I like the damage and failure presentation. Having the lander physically break apart gives unsuccessful attempts more personality than simply resetting the mission.

I also appreciate that it is playable directly in the browser. For small experimental games and playtests, being able to click and immediately start playing removes a lot of unnecessary friction.

Overall, I think this is a very clean and understandable concept and a strong focused project. It seems like the kind of game that could be especially rewarding for someone who enjoys mastering precise physics and improving their landings over repeated attempts. Personally, though, after about 15 minutes I felt like I had seen enough of the core experience and I probably would not come back to play it again. That is likely more about the genre not being for me than a major issue with the execution.

Reminder to give mine a try as well! https://barelyplayable.itch.io/blade-baes-brawl

When you circle back to mine, please do use the feedback link: https://forms.gle/fsJrAZDhJtP1CFXX8

Also feel free to drop your discord/contact info if you’d like to try the full build:)

(+1)

I'm going to take a look tomorrow. This weekend has spun out of control on me, and I haven't gotten to anything I've actually wanted to do yet.

No worries! Gotta take care of yourself and core responsibilities, I understand :)

(+1)

Just tried out Blade Baes. I’ll also submit through the feedback link, but I wanted to share some first impressions.

Great work! The menus and UI feel polished and responsive, and I love the overall visual style. As someone with a personal hatred of working on UI, I really respect the effort that went into it. This isn’t normally my genre, but I still got sucked into playing for about an hour.

My only criticism is that the top of the arena is obscured by the status panel. It took some getting used to, and I found it distracting enough to affect how I played. I started lining up my best shots near the bottom of the screen so I wouldn’t lose track of them behind the panel at the top. I’m not sure whether this is specific to the web build; I tried playing in full-screen mode, but the issue remained.

Despite that, I played much longer than I expected to, especially considering this isn’t normally the type of game I’m drawn to. If your main question at this stage is whether the game is fun and worth continuing, my answer is absolutely yes. It also runs great—any stuttering during gameplay would seriously undermine a game like this, but it’s smooth as butter.

(1 edit)

Holy shit, I am honored and grateful you played for that long! Thanks for giving it a go and including great feedback. Feel free to add me on discord @bladebaes, happy to playtest any of your games as well :)

EDIT: BTW I’m working on a 3D build of the game, would really appreciate your thoughts on it!

Also, don’t beat yourself up about UI. I come from web dev world but every game dev I know hates UI because UI sucks to dev in almost every game engine hahaha. That’s why I ran with Phaser + TypeScript for this game.

Two things landed in this thread after your last reply, and since your weekend has already spun out of control I want to make sure the first one does not get buried 🚀

Barely Playable Games reported a repeatable freeze on Chrome under Windows 11, happening when they spawn and press W. That is the only report in the thread that makes the game unplayable rather than imperfect, it is on the single most common desktop setup there is, and it arrived after you had already drawn up the final-build list. I would put it above the HUD transparency and the background music.

Their description also carries the useful half of the diagnosis. “At first I thought it was random because I could not consistently reproduce it, but after trying again it seems to happen when I spawn and press W” is the signature of something that happens once per page load rather than once per keypress. That is what first-use shader compilation looks like. In a web export the shader for a material or a particle effect is compiled the first time it is genuinely drawn, so if the thruster plume is the first effect that has never been drawn before, the compile lands on the exact frame where the player first presses W. After that it is cached, pressing W again does nothing unusual, and the whole thing looks random until you reload the page.

The test is cheap and it is decisive. Hard-reload, press W immediately, note the stall, then press W again without reloading. If the second press is clean it is compilation, and the fix is to draw every effect once behind the loading screen so nothing compiles during play. If it stalls every single time it is a logic bug in the thrust path and worth a real hunt. Either way you know which in about a minute, and only one of them is worth your weekend.

The other thing is that Barely Playable answered the question you said you still needed to determine. You wanted to know whether people stopped because they were bored, frustrated, or had simply seen enough. They said it outright: about fifteen minutes, felt they had seen the core experience, and put it down to the genre not being theirs rather than anything you did wrong. That is the third option, and it is much the least alarming of the three.

It does bear on the rotation argument, and I think it strengthens your side rather than mine. You said rotation earns its place later, for dodging enemy fire, and I take that. But if a real share of players are finished at around fifteen minutes, the payoff for your most interesting input is sitting past the point where they stop. That is not an argument for cutting it. It is an argument for moving one moment that needs it earlier.

If you do run the reload test, I would genuinely like to know which way it went — that one is useful to everybody shipping to the web.

I tested the game in Chrome on Windows 11 but was unable to reproduce the freeze when pressing or holding W as the player spawned.

I still looked into possible causes. Godot has a known audio issue in web builds that sounded somewhat similar, although it didn’t quite fit what was reported. Since I couldn’t reproduce the problem directly, I decided the safest approach was to prevent the game from accepting input until the scene had been drawn and everything had finished loading. Testing this change produced no noticeable delay, so I’m hoping it resolves the issue for anyone experiencing it.

I’ve now published a new build that includes this change and addresses several of the other issues raised in the thread.

My goal with this project was to learn how Godot works, implement features relevant to this style of game, and touch as many of its systems as possible along the way. Part of that process was releasing the game and making sure I ended up with a complete, working project in each of its intended formats.

With the fixes I’ve implemented, I believe the project is now objectively complete and fully playable, barring any further bug reports. I think it’s time to wrap this one up, call it finished, and move on to prototyping some of the other projects I’m interested in.

Thanks again for the thorough feedback—I really appreciate it. I wish I had a more definitive answer about the Chrome issue, but your input was genuinely helpful.