Closed Kawtious closed 3 months ago
Hi! Sorry for taking a while to get to this. Remember that you can request a review from members of the team using this section:
It gives you some suggestions of who you could request a review from, if you don't know who would be appropriate.
Regarding the change itself, I'm conflicted. While I agree this makes the movement more responsive, it's worth considering that the purpose of a backflip is to send you backwards. That means you're likely to be holding the direction opposite to the one you're facing. Consider this case:
https://github.com/GTcreyon/SM63Redux/assets/67928545/63dfa0e9-a37f-4bd3-b5d1-cda28dc2b0b5
I want to backflip backwards. With this new change, I have to hold back after I backflip. If I do it before, I get turned around, and my backflip is all messed up.
I'd like to hear what others have to say. My vote is currently on "no", but I'm not super convicted on it.
I want to backflip backwards. With this new change, I have to hold back after I backflip. If I do it before, I get turned around, and my backflip is all messed up.
I did plenty of planning and gameplay testing for this PR, yet still this is something I completely forgot to consider.
Personally I'm someone who holds the opposite direction after doing a backflip in Mario games; but I understand your point and I will try to think of a solution for both cases.
Holding the opposite direction to gain more distance from the backflip seems to be the most common reason players do it. I'll keep that in mind.
I'll be calling the action of holding the opposite direction before doing a backflip a "long backflip" in this comment.
After some testing, I noticed that the difference in distance gained by a long backflip seems considerable (duh), especially if the player adds a spin. I suppose the full extra distance could still be achieved with the changes, but that'd require almost, if not truly, frame-perfect precision.
Unfortunately, I think this is another problem that probably has thousands of solutions; but I do have one solution in mind that might keep the best of both worlds:
The delay should be just long enough to let the player comfortably, but quickly, perform a long backflip. After the delay, the player would be able to turn around while crouched. Turning around while crouched could re-apply the delay, in case the player wants to turn around and then do a long backflip.
I don't have a demo video for this just yet, but I imagine it might look like how it works in 3D Mario games. I'll see if I can work on a rough implementation for that just for demonstration purposes.
Adding a short delay before being able to turn around after crouching
The delay should be just long enough to let the player comfortably, but quickly, perform a long backflip. After the delay, the player would be able to turn around while crouched. Turning around while crouched could re-apply the delay, in case the player wants to turn around and then do a long backflip.
This sacrifices a bit of the responsiveness that the previous changes provide, but I think this is a good middle ground. There is now a short (although decently sized) window where the player can input a long backflip without instantly turning around.
https://github.com/GTcreyon/SM63Redux/assets/75398915/7549011b-d1dd-4a4b-8da2-f1bee0244306
I was informed that the player code is undergoing a major refactoring, so I thought I'd make this flowchart to better describe the logic behind this little mechanic; in case the code in this PR becomes obsolete or lost:
I like your proposed solution, I think it's a great quality of life addition.
The issue is indeed the player re-write, but I see no harm in merging this before that time. Even if it were for a reference implementation. Thanks for the flowchart by the way!
Opinions @GTcreyon @Koopa1018 ?
I like your proposed solution, I think it's a great quality of life addition.
The issue is indeed the player re-write, but I see no harm in merging this before that time. Even if it were for a reference implementation. Thanks for the flowchart by the way!
Opinions @GTcreyon @Koopa1018 ?
I don't think there's much of a reason to merge this as-is. I think the PR should be closed, personally.
However, I do like the alternative implementation, and the flowchart was actually very helpful. I think I'll close this PR, but I'll look into implementing it when doing the rewrite.
Description of changes
Allow turning around while crouching by adding the crouching state to the list of valid cases that allow turning around.
Quoting myself from #284:
However, even though this is but a tiny change in code, I do think that this could be a slightly major change that will impact movement tech; and I think it'd be appropriate to discuss about it before making these changes... unless I'm overthinking it. I'd appreciate some feedback regardless.
Let me know about any suggestions, and if there should be any balancing that should be done beforehand.
Issue(s)
Closes #284