> In order to jump for a second time you need to release it first.
Is that true? Mechanically it's true, but I don't know whether the game code actually knows this is true. It depends whether the N64, and the SM64 code specifically, tracks the button state and the events separately.
Compare the situation with Left + Right in TAS Mario 1. The TAS has no problem telling a console that both left and right are pressed, but obviously a real human player cannot press both directions, they're opposites. Nevertheless this does "work" in the game and so although no-right-plus-left is an interesting benchmark to compare against RTA where live human players couldn't do the trick, the TAS records allow both pressed at once.
Wow thanks for the pointer! That seems unfortunate, I wonder if there is a way to evaluate whether the extra jump is actually worth it, and whether this optimization could be allowed.
You got this far into writing a game...why would you ever make double tapping A/D be jump? It's like some kind of weird Andy Kaufman prank on your desired audience.
The jump algorithm I've used for a long time(and cribbed from an old co-worker) uses three variables, going to a second derivative: velocity, acceleration, and "power." The first two are pretty explanatory, the third is applied to acceleration and decremented each frame to a minimum of 0, and is instantly zeroed when jump is released early, allowing gravity to start pulling down acceleration. (Acceleration is also usually zeroed at release for a tighter top.)
Tuning these has let me reproduce pretty much any controllable jump arc - for example, the jump in Metroid has a lot of "float" to it at release time. This is doable by making acceleration at release equal to inverse of gravity.
This is also why 2D jump platformers like Megaman have triangular jump trajectories instead of parabolic trajectories. For snappy controls you leave the ground at the instant of the downpress and peak when you let go of the button. As the game can't know how high you intended to jump at the time the jump begins, the trajectory can't be parabolic. (At least, not on the way up.)
You could instead have the button downpress "charge up" energy and then begin the jump when the button press ends, which would allow for more realism, but also introduce a delay.
Please change your jump controls. Having the same keys for walking also jump when double-pressed makes twitchy platforming really difficult (especially given how loose the friction seems to be) and not in a good way.
Typically I've seen the spacebar, up button or W used for this. In terms of mechanics It's just adding y (or -y, whichever is up) to the player's velocity vector after a ground check.
Jumping "forward" is sort of built into Emacs with C-x C-SPC, pop-global-mark.
The objective and this command are fairly but not completely aligned, so it may require multiple presses of C-x C-SPC. To be clear, you only need to press C-SPC after the first invocation to repeat the command.
While the scrolling and animation is smooth, why not have a dedicated jump button? With the current controls, the character would jump when I was just trying to walk around normally. It's also really difficult to gauge how much of a runway is needed to make the jumps with double tapping
Slight variation (which may have been done before) where you tap instead of holding. Your upward bounce has a predetermined strength that makes minor course corrections impossible. It's definitely an added challenge.
Re: Asset store reskin, I have no idea. But FWIW I hadn't heard that accusation before.
I always kind of figured that the first pass would emit the most general form of a jump, then shorten it if possible, but I guess it works the other way around too.
In the blog post I mention using RS485 (or CANBUS) instead of the solution we went with, but on a 5 day timeline, and building on a set where I wouldn't be present (initially I was not planning on being there at all during the shoot), I didn't want to put in a solution someone else on staff couldn't at least wrap their mind around.
In hindsight... there's always a lot that can be done different :)
And regarding the debounce—I don't mention this in the video explicitly (for time), but there were three other 'modes' for the buttons that were implemented that were never ultimately used, for games like Simon (press colors to match a pattern), and timing-based games, so the debounce was actually critical to allow varying ages to press buttons sometimes in tandem and sometimes in sequence with certain timings.
Because of the issues we had (not the least of which was a weird bit of a drain on the 3.3v as you held down a button), I recommended against some of the challenge types. In the end, the only things that made it to the final cut of the 1-100 video was the 'yes or no' style votes on a challenge. Which, yes, are incredibly easy to debounce. Lock in the first button press and you're done ;)
0.5 is really about the idea of having an A press span multiple levels.
reply