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 ;)
I really don't get why debouncing is such an issue in this situation.
Like it only occurs when somebody has hit the button no? So if somebody hits "Accept Challenge" and then because of bounce it triggers "Accept Challenge" multiple times why does it matter?
Afaik, either you can (1) trivially lock them into their first choice, (2) send the extra bounce choices (which will be a noop on the server), (3) prevent changing choices in <50ms. Any of which don't require spending 12h.
I've been following your progress with these games and there are several I really like, most of which is I think #5 with the cube jumping. I can't sing you enough praise on posting these as inspiration to others and sticking with the one game per week timeline. The motivation alone is inspiring.
That said, this one is frustrating. I feel the keys are off. I like to run before I jump and in some areas, it's not possible because the responsiveness of the keys just isn't there. It takes too long for my guy to jump after I press up. Also, it seems like you're possibly doing your left/right code in a way that gives left priority. If I press both left and right, my guy goes left. I feel like he should stay stationary in that situation.
Other than that, I like the gameplay, tutorial text that's part of the scene, the sounds and music. I really like the cube slanting to show motion, too. Clever.
So, tell me something: How do you adapt to not receiving an event?
The only choice is to do something completely different, but I can't think of anything that doesn't profoundly change the nature of the game (continuously jump makes a completely different game, use upward motion to jump will have a lot of false positives) and is basically an admission that a game that involves two buttons like this is simply impossible. And that's an unreasonable outcome.
(The continuously jumping game has interesting potential, but it is a different game. Plus I've think I've seen it way back in the day and it's very visually tiring.)
>this rolling technique allows clicking buttons much more quickly than you normally can but they're still a long way from the 30Hz strobe the hardware itself will accept
This is actually false! Top players can actually roll faster than 30hz if they want; however, the game won't recognize this as all distinct inputs, so it really is the hardware that's limiting us. Check out this video to see how precise some players can be: https://www.youtube.com/watch?v=K81CjNo4B_Q
(incidentally, i made a romhack of nes tetris that supports polling multiple times per frame, effectively removing this limit. i talk about it here https://www.youtube.com/watch?v=n9vKMNu5JWo)
I think my comment has been validated by the dozens of comments here complaining about broken inputs. I didn't say it was impossible; the basic trick only works in simple cases and the edge cases are numerous. If I implement a feature and it causes even one person to bounce, it's a failure.
"With the Addams Family game for example, Fred just couldn't locate where the game stores the lives or any useful value - the only thing he managed to do was lock the jump button on, so your character was permanently and uselessly leaping about the level. We submitted this to Codemasters QA as 'unlock pogo stick mode', and they accepted it."
> 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.
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.
> (I don't know what to do if another change interrupts the first but it's a rare case and can probably be handled imperfectly.)
This kind of lerp trick, while imperfect, is useful in exactly these sort of situations. It allows you to smooth movement even if the target point is changing at at arbitrary intervals (note too that it works okay generalised to multiple dimensions). And the statelessness is very useful too - I don't think the feel is great and it's not very controllable, but being able to just add some damping to the movement without having to track animation states or anything like that is super useful.
I went back to that part of the article several times, because like you, I found it a bit odd that there was no option to stand still.
The first part of the article definitely seems to give the impression that the choice is between UP or DOWN every frame.
But then a bit further on it was a bit more ambiguous and I could also interpret it as giving a probability for UP and a separate one for DOWN. Then it could also choose neither. But then it also could choose both, and you need a conflict resolution procedure (do neither, pick the one with highest probability, maybe just roll again?). Unless the actual game also has two buttons and you can just do whatever the game engine will do if you press both.
Another possibility might be to model the output a bit more like a human player would do it. First I'd change it into a series of timings + note-on/note-off commands (like MIDI), then perhaps add jitter to the timings (making sure the note-off doesn't jitter before the corresponding note-on). I've read that adding this kind of noise to a NN tends to improve its robustness, so that might help?
Most of those changes would happen as transformation step between the output layer and the simulation input, so I presume the learning algo itself can mostly stay the same. But there's probably a few snags to that as well.
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.
It's an impressive achievement, but it does seem to get stuck at times, like from around 1:35 to 2:10 and 3:45 to 4:30 (irritatingly on the edge of two screens), but that second time actually resulted in a new key showing up, which the article says was a flaw in the emulation that it was exploiting.
Interesting that their approach didn't work for Pitfall (never played Gravitar).
It was quite serendipitous how although Rocket jumping was "incidental" to Q1 most levels still played extremely well using that feature. Still level-designers who later knew about it and designed for it managed to (ab)use it even more. I designed a level where the entire layout was optimized around rocket-jumping being possible (and encouraged) as much as humanely possible, great fun!
For a specific example of something like this being important, remember the (very impressive) Watch for Rolling Rocks in 0.5 A presses video from a couple years ago? https://www.youtube.com/watch?v=kpk2tdsPh0A (For the uninitiated, this video presents a TAS of Super Mario 64 which beats the level Watch for Rolling Rocks without pressing the A button outside of keeping it held from entering the level.) It turns out that the route presented in the video actually fails console verification, since the crazy things he does trigger some annoying FPU crashes on console, but not on emulator. There is a happy end, though: a fixed route was published after this was discovered, and it passes console verification just fine (assuming the inputs dont desync over the 13 hour run)
That's true, it requires a bit of memorization and configuration. I've put the shortcuts similar to character movements: CMD + j,k,l (jump over, jump out, jump in).
You are supposed to 'tap' to one of 3 spots, basically (left, right, middle), from what I can tell. That at least lets me avoid things a bit.
The opening animation shows a smooth hand gliding around, which would indicate some sort of dragging motion as the input mechanism, but it's not at all drag-based. Took me a good 3-4 minutes to figure that out, and it was frustrating. It's only because I was reading some stuff here of other people saying it was fun that kept me going.
Personally, I think it's too fast to start with. Add better instructions, slow things down a tad for the first few obstacles, and this would be 'hook' material for more players. As it stands, I think the 'game over in 1 second' factor will keep it from being recommended more.
But... great job on getting something out so quick!
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 ;)
reply