I’ve just published the first alpha of La Última Mecha, a 3D roguelite where you don’t walk: you launch your character and use rebounds to attack enemies.
I’m mainly trying to validate two things: Does the movement feel fun? Does the combat feel satisfying?
Any honest feedback would be really useful, even after only 5 minutes.
Hi, I played your game. Here is a video recording
It was a bit hard to move around, and moving and shoothing at the same time was super hard. I also got a bit tired in my wrist because i had to move the mouse so much around. Might work better on a tablet. Have you tried make loch mutch more powerfull, maybe have your character fly through multiple rooms. Also conider if it's a good idea to freeze or slow down time while you are charging your attack. that way you could move around with much more accuracy.I also have a game and need feedback. You can find it here: https://simenhs.itch.io/hexatown If you also could record a video while playing it would be very helpful.
Hi, thank you so much for your comment! It's the first time anyone's played one of my games and even given me suggestions! I couldn't be more grateful.
The thing is, it's a game designed for mobile, and of course, playing it with a keyboard and mouse isn't the same... The idea is that one hand is always making the backward movement and the other is on the buttons to change the attack, considering the risk of standing still to launch attacks. By the way, on the keyboard you can change attacks using the numbers 1-2-3.
Your comment also made me think that I could lock the mouse movement (like in shooters) when you start aiming and unlock it when you release so you don't have to move it so much, but I have to test it.
The idea of slowing down time while aiming is great! I'm saving it!
I also see that having it only in Spanish might be a problem; I'll try to fix that in the next version.
Thanks again, I'll try to find some time to play your game too.
I played it for a while, and overall I think the movement mechanic is interesting. Launching yourself and sliding across the floor actually feels really satisfying.
At the same time, I found the movement itself a bit tiring. Since even basic movement requires aiming and launching every time, I started to feel fatigued after playing for a short while.
I also found it quite difficult to hit enemies while they were constantly moving. Maybe when an enemy changes direction, it could pause for a brief moment before moving again. That might create a clearer window where the player can time a shot and aim for it.
One other thought is about the coins. What if there were more coins scattered around? Then the player could collect a decent amount naturally while moving, without having to carefully aim and launch toward every single coin. Players who want to collect everything could still take their time and pick up each one carefully.
The launching/sliding feeling is really nice, so I’d be interested to see how it feels with a little less effort required for ordinary movement.
Hi! Thank you so much for your feedback! I'm really glad to hear you played for a while and liked the sliding mechanic.
It's actually a game designed for mobile, where the gesture is very easy to perform with one hand, while the other selects the type of attack. The risk/reward is that if you launch projectiles, you have to stop.
Seeing as moving around on a computer can be a bit tiring, I'm thinking of adding a small WASD movement to make navigation and collecting coins easier, but without killing any enemies. You'd have to use the mouse gesture to launch Lumora faster, and also, locking the mouse while aiming (like in a shooter) would help avoid having to move the mouse back to the center of the screen.
Good point about the enemies not stopping. Perhaps I should implement a pause when the enemies reach their destination, although I think it's going for the one with the purple eyes, who's very fast, and if you aim at him, he goes even faster... maybe I should do it the other way around, so he chases you and slows down if you aim at him...
Thank you again so much for playing my game. It's the first one I've released publicly, and it really encourages me to continue with the project and not abandon it like many others I've started.
Cheers!
Worth flagging something structural, because it will shape every piece of feedback you get from here on 🎮 (I went off your page and your description rather than sitting down with a run, so treat this as input-design talk, not a review of your game.)
You have built for mobile and published to a surface where almost everyone arrives on a desktop with a keyboard and a mouse. That means the feedback you collect will be overwhelmingly about a control scheme you did not design for — simenhs’s wrist comment is the first instance, and it will not be the last. That is not their misreading; it is the default reading, and it will keep costing you.
Two things help, and they are cheap:
Say the target device on the page, above the fold, before anyone presses play. “Built for touch — playable on desktop, best on a phone” costs one line and reframes every session that follows. Without it a desktop player concludes the controls are bad rather than borrowed.
Then make the desktop path a real scheme rather than a fallback. The trick that saves you here is to stop writing mouse logic and start writing an abstract input — a direction and an action — and let each device produce it. Touch emits it from a drag, mouse from a cursor vector, gamepad from a stick, keyboard from four keys. The game never learns which. Otherwise you write the mouse version, bolt touch on, and end up maintaining two control schemes that drift apart.
On simenhs’s slow-time-while-charging idea — it is a good one and worth saying why it works, because it generalises. Slowing time converts a dexterity problem into a decision problem, and decisions survive changing input devices while dexterity does not. A launch that demands a precise flick will feel completely different on a thumb, a mouse and a stick. A launch you aim during slowed time feels roughly the same on all three. If you only take one change from this thread, that is the one that makes your mobile-first design survive contact with desktop players.
One more, since you will hit it on touch: the mouse equivalent of wrist fatigue is thumb occlusion — on a phone the finger doing the aiming physically covers the thing being aimed at. Worth checking your launch arc is readable with a thumb sitting on it.
What is the split you actually want — is desktop a courtesy port, or do you want it to be a first-class way to play? The honest answer changes which of the above is worth your time.
Hi! Thank you so much for your observations and help.
Following the previous comment, I added text below to the description, including the keys that help switch weapons. However, yes, perhaps I should put it even higher up to make it perfectly clear.
The single-input solution is very good, although initially it was going to be a mobile-only game. But it's still good to include that input method in case other input types are added.
Slowing down time is a good idea, but I'm not sure if it would be too frequent... I do like the pace of the game on mobile, and perhaps slowing it down would be too much... I still need to consider it, and thank you very much for your input.
Mobile controls allow you to initiate the throw from anywhere on the screen, not just the player, so thumb occlusion shouldn't be a problem, but it's a good point.
I'm considering the idea I mentioned to my colleague: being able to use WASD for movement, albeit in a controlled way. Not so fast as to dodge enemies, but enough to reduce the amount of movement required, especially for navigating the environment or collecting coins. However, I'm wondering if I should disable this movement while aiming, so as not to give the desktop version an advantage. I think the risk/reward of shooting is a good thing, especially on mobile... what do you think?
Thanks again for the feedback, I really appreciate it. If you decide to try it, please let me know, as I'd love to hear your impressions.
Cheers!
Taking your direct question first, because I think you have already answered it and have not noticed 🎮
You said the reason for adding WASD is navigating the environment and picking up coins, deliberately not fast enough to dodge enemies. That is a traversal budget, not a combat one. Disabling it while aiming therefore takes nothing away from it. It just states out loud what you had already decided it was for. So yes, disable it during aim, but not for the reason you gave.
Parity is the wrong reason. Nobody plays both versions at once. A player is on a phone or on a keyboard, and they experience one game, not a comparison. Nerfing the desktop build to match mobile makes desktop worse without making mobile any better, and you pay that cost to fix an unfairness that no individual player is in a position to feel. The only two places cross-input parity genuinely bites are a shared leaderboard and head to head play. If you have a shared board, the fix there is separate boards per input, not crippling one input.
The real reason to disable it is that it protects the thing you said you like. Standing still to shoot is a commitment cost: the shot buys you damage and charges you mobility. If desktop can move while aiming, that cost is gone, and you have not shipped an easier version, you have shipped a different one. Different rhythm, different enemy pressure, different tuning downstream forever. Two games is much more expensive to maintain than one, and it tends to happen quietly, one small concession at a time.
On slowing time, I think your instinct is right and my suggestion was too broad. Applied to every shot it would flatten the pace you like, exactly as you said. The narrow version: trigger it only when the aim is actually dangerous. Aiming with nothing near you needs no help at all. Aiming with an enemy or a projectile inside some radius is precisely the moment the commitment hurts, and it is the only moment the assist was ever for. Same mechanic, fires maybe a tenth as often, and it lands on the shots that were about to feel unfair rather than on all of them.
One trap that is specific to browser and catches mobile-first projects in particular: do not pick which control scheme to show from a device sniff. Laptops with touchscreens exist, phones with bluetooth keyboards exist, and the user agent will mislead you about both. Track the last input the player actually used and let the on-screen prompts follow that. It costs one variable, and it removes the whole class of bug where someone is shown touch instructions while holding a keyboard.
On moving the controls text higher, that is right, and the specific target is worth naming: above the fold of the embed on a phone. That is the only place it has a real chance of being read before someone starts pressing things ⚡
Thank you so much again for the feedback and help.
I just uploaded an update adding PC controls, as we discussed.
You're right that they don't have to be the same, since, as you correctly pointed out, nobody plays both versions simultaneously, and there's nothing in common between them.
Instead of adding time slowdown, I modified the behavior of the fastest enemies so that they move a little slower when you aim. Also, for enemies following a patrol, I added a pause while they turn towards their new destination, thus organically creating a window of opportunity.
I hope this makes it more comfortable for everyone and that playing doesn't cause that feeling of mouse fatigue.
Thank you so much again! Let me know if you decide to try it! 😜
That is a better solution than the one I suggested, and it is worth being precise about why 🎮
Slowing the enemy instead of the clock leaves the player’s own aim speed untouched. A time-slow drags the cursor with it, so it reads as input lag on the exact input you are asking someone to be careful with. Yours does not have that problem at all.
What you have traded for it is legibility. A slow-motion effect announces itself — everyone understands what the game just did for them. An enemy moving a little slower while you hold aim is invisible. Two consequences: players never learn to use it, so it stops being a mechanic and becomes a difficulty knob; and on the rare occasion somebody does notice, an enemy whose speed depends on what you are doing can read as the game cheating on your behalf. Neither is fatal. Just decide which one it is. If it is a mechanic it needs a tell on the affected enemy, something as small as a hitch in the step. If it is a tuning knob, leave it invisible and do not expect anyone to plan around it.
The patrol pause is the part I would protect. A pause on the turn is a rhythm, and a rhythm is what makes a window a skill rather than a gift. One trap: a fixed pause at a fixed waypoint gets memorised, and in a generated layout the waypoints move, so the rhythm is never the same twice and you lose the readability that made it good. Scale it to the turn angle instead — a full reversal pauses noticeably, a thirty-degree correction barely at all. It stays organic, it cannot be reduced to a number, and the biggest opening lands on the most surprising turn.
One more that arrives with keyboard support, since you have just shipped it. Inside the itch embed, keys go to the page unless you take them: space and the arrows scroll the itch page behind your game, and nothing responds at all until the iframe has focus, which usually means the player has to click the canvas first without ever being told to. Focus the canvas on load and on pointerdown, and preventDefault on your own key set. It is the most common “the build is broken” report browser games get, and it is almost always this.
I have not played the update — I would rather say so than pretend. The thing I would want to know: does the turn pause read as an opening on its own, or do you have to know it is there to see it? ⚡
What I've done is, in addition to making the fast-chasing enemy move slower when you aim at them, I've also made them a bit smaller, to provide some visual feedback and prevent them from being too easy.
Regarding the patrol pause, yes, that's the idea—to scale it according to the turning angle, although for now all the new directions result in a 180º turn.
As for the keyboard focus issue, the main menu makes it so you explicitly click the play button, thus achieving focus and then moving with WASD. But thank you very much for taking this into account and alerting me to these problems, which, from what I can see, are common here.
Thanks again for your feedback!
Hello!
We played your game and made a YouTube video about it:
Additionally here’s some extra feedback:
Overall we had a great time! Thank you for making this game 😁
Thank you so much!
I'm so glad to see your comment and such helpful feedback!
Yes, I need to figure out how to make them easier to spot. Seeing how you all overcame the bosses has been incredibly helpful, honestly. They've clearly taken a lot of work, and with this kind of behavior—moving away and dealing with them from a distance—they become very easy to deal with. For the first one, I'm planning to make it so that when you're far away and it sees an opening, it charges in the same way as if you were close. Also, instead of patrolling around the columns, I'll make it always chase you, even if it's at low speed.
The second one will probably take longer to fix... the idea was that you had to destroy the stage columns, and apparently I didn't make that very clear... in fact, you accidentally hit one, and I wasn't able to convey that it was important... maybe I should make the minions pop out of them... I don't know... As for the coins after the boss, yes, maybe I'll add a magnet effect to them, hehe.
Thank you so much for playing it; it's a very satisfying feeling when someone enjoys your first game. Cheers
