Skip to main content

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

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! 😜

(+1)

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!