itch.io

People will complain about just about every bit of friction towards their desired playstyle, yeah. There's a certain point where you have to decide who you're actually going to listen to and how, because you just can't please everyone.

For my part though, I think my initial feedback wasn't super well phrased, as I'd be satisfied with just having the option to back out of the fight. It could be a pause menu button, or even require reloading the game entirely - just some way to leave the fight without losing all my other progress. I think it's fine to keep the default behavior throwing the player right back into the action, especially if you expect most players to be mainly here for the bossfights, since that's probably the thing that players are going to be wanting much more often.

What behavior you want very much does depend on the game though, yes. There's a reason I specifically said I don't like it for a metroidvania - in a fully linear game, it makes perfect sense to throw the player right back into the challenge immediately, since there might well be literally nothing else for them to do at that point in the game, but for something more open ended like a metroidvania, when a player gets stuck on a challenge, it's often preferable to leave and go check another path they haven't explored yet rather than continuously bang their head against a brick wall. Death systems that encourage or outright force the player to dive back into the same challenge punish this style of play and tend to hamper the focus on exploration that the genre is known for. Even outside of linearity though you do have to consider exactly what kind of tone and structure you're going for and what role the bosses play in that. Modern gaming culture has a tendency to hyperfixate on bossfights as the main event, a spectacle that can and should dwarf everything else in the game, and from that framing its easy for people to start seeing any amount of runback as a waste of their time. But, this simply doesn't have to be how bossfights are framed - for instance, putting the player back much earlier in the level on respawn forces them to master the level before they can start making progress on the boss, and emphasizes the boss as a capstone on the level rather than being the main spectacle in and of itself. Plenty of successful games use a mixture of these philosophies. The speed at which you get back into the action after a death also has a lot of implications for the tone and pacing of the game - forcing the player to take some extra time before they can jump back into the boss slows things down and can make things more careful and contemplative, though of course that same slowdown is exactly what can make a runback so frustrating after a particularly painful death. Adding any amount of friction towards getting into what the player perceives as the main action is always going to have that kind of tradeoff, no matter how well you design it - which is why eliminating runbacks entirely isn't totally without merit, but throwing the player immediately into action without even the choice to stop and reflect first is inevitably going to make the game much less cerebral, for better or for worse.

Basically like anything else in gamedev the presence and size of runbacks is going to depend a lot on the kind of game you want to make. If you want your games to be focused on high octane bossfights with the slower exploration acting mainly as just a palette cleanser in between, then great - you should keep going in the direction you currently are, and you'll find tons of players eager for exactly that kind of game. Don't worry too much about trying to please people like me along the way, because my tastes are just always going to lean in the opposite direction. (That said, don't completely ignore the advice of people who bounce of your games either, as they still might raise some points that'll make your game better for everyone :p)

For the parry, I actually agree the current length of the window is fine - what I'm suggesting is shortening just the animation slightly while leaving the actual mechanical window the exact same length. That way there's a little bit of a grace period as the knife disappears, so the window feels more forgiving even though the actual timing hasn't changed at all.

As for the jump... some of your comments there make me think I assumed you had more prior knowledge about variable jump usually works than was maybe accurate, so I'm gonna give the full spiel I was originally gonna write on that before I checked your earlier games, but to start by just explaining why I think the current jump feels so bad: Yes, I think a lot of it is just framing. The player looks like they're jumping, sounds like they're jumping, but does not move like they're jumping, and something about that fundamentally just feels wrong. If you were to visually frame the ability as more of an outright hover, or lean into the physical wrongness with some kind of narrative explanation, I think it would immediately feel much better. There would still be some awkwardness with the level design, however, where I think the big issue is with speed - it takes much longer for this pseudo-hover jump to reach its max height than an instantaneous jump would. This could potentially be fixed just by increasing the rate at which the player rises if you really want to commit to this style of jump.

That's all assuming you actually do specifically want a hover type move though, but your comment about wanting holding the jump button to feel meaningful makes me wonder if my first instinct was right about it being an attempt at just implementing variable jump height, to whit: that's not how variable jump works. In the vast majority of games that feature it, controllable jump height is achieved not by adding more velocity when the jump button is held but by reducing it when the jump button is released. This makes it so that you go higher when the jump button is held as expected, but while keeping the initial jump instantaneous. My go-to method for this is to cut the player's upwards velocity in half when the button is released, though this exact value isn't significant - multiplying the velocity by pretty much any number less than 1 will give a similar effect, as long as you're not cutting it straight to zero. Another common method is to increase the gravity after the jump button is released, but I've personally never liked how this feels. I was originally going to write out most of this in my initial review, but I wanted to check that you were actually new to platformers before giving this whole spiel, and found some games that seemed to already use this kind of more traditional variable jump in them that made me assume you were already fully familiar with all of this - if that's correct and you've heard all this before than I apologize for reiterating it all again, hopefully there was still something useful in my take on it.

I do note that in those old games of yours while the difference between holding and tapping the button exists it certainly isn't very large, so if the issue you're having is just making the variable jump feel actually impactful then I would encourage playing around with the parameters of it more before committing to switching to the hover jump. You mention the player not being able to stay above enemy attacks, and the jump feeling too short, but neither of those things have anything to do with which technique is used for the jump - lowering the player's gravity and increasing the velocity given by the jump will make the jump higher and floatier, and even make the difference between holding and tapping the jump much more significant, since the player will have a longer window during which to cut the jump. You could also try directly increasing how harshly the velocity gets reduced if the control's still not feeling impactful enough - either the instant cut method or extra gravity method give you a number to play with there.

All of that said, I do think a game with something more like a hover than a jump as the main way of gaining height could very much be interesting, I just think it needs to be presented as such so the player understands what to expect from the move's behavior, and it also sounds like that kind of gimmick wasn't necessarily the actual goal behind this game's jump design. And regardless of what you decide works best in the context of this game, I'd definitely encourage playing around more with the exact values you use for your older jump mechanic, as I think the usual way of implementing it has a lot more room for variety than you're giving it credit for.