Fortune Beach
( Formerly “Banana Beach” ).
The logical process I went through to come up with this level: 1st I used the idea o’ secret passageways in the sand that fade into view when you touch them, ripped straight off from Wario Land 4. However, I quickly figured out that basing an entire level on hidden passageways that fade in isn’t interesting. Since I had the gimmick, though, & due to the laidback nature o’ beach levels, I decided to focus this level on exploring & collection. Since having just 1 goal @ the end didn’t fit that well, I though o’ having multiple collectables that all had to be collected to beat the level — most likely in treasure chests. However, I already did that for “Sleet Streets”. So I ripped off that Zelda level in Super Smash Bros. Melee & had only 1 random chest out o’ all o’ them have the goal, while the rest just had money. Then, finding that still not ’nough, I decided to tack on water currents just to hide goals. Maybe I should actually use these in a mo’ developed way in ’nother level ( where, I have no idea, since it wouldn’t fit into the other water levels I have planned, a harbor & a pirate level ).
The fading-in passageways & water currents were simple to implement. Technically, I already implemented the former in “Mart Cart Madness” to hide a shortcut there, but that was implemented in a completely different & hacky way with just a specific custom sprite. This level uses a much mo’ flexible foreground layer that just checks if the player is touching any o’ its blocks & either fades in toward max opacity if not & fades out to absolute transparency if yes. The water currents just subtract a certain # from your character’s X position & does some other stuff like changing that # or also killing your X velocity depending on whether you’re ducking or on the ground based on playing round trying to break it. I’m sure some clever speedrunner could still figure out how to break it, but trying to perfectly prevent that kind o’ glitching is both futile & no-fun-zone. My philosophy has always been that if someone finds a way to break through my rudimentary tests, then they deserve that victory. There’s already still that glitch where you can zip up certain solid blocks if they’re a short height ’bove the ground & you jump into the leftmost edge, which I found could be used to cheat & get a diamond early in ’nother level I’m developing & will probably show off when I get to that level.
As always, the random chest mechanic was taped on. Then ’gain, I did have to get rid o’ that whole “using variables for something else” thing for the treasure chest sprite used in the last level I made, “Crying Lightning”, since in order to reuse the chest-opening code, I had to move that code to a treasure chest sprite that they both inherit, rather than in that weird treasure-opening player sprite. Handling the random selection o’ treasure chests is through a dumb static variable, which is probably a waste o’ memory, since I think that variable will take up space throughout the whole game. An improvement would be to use 1 o’ EventSystem’s miscellaneous variables used for the boss gate in “Reading Railroad” & the moon timer in “Pepperoncini Pyramid”; but I would have to make up ’nother variable for the other. Plus, I would have to change that variable to make it work, & that would mean changing the boss gate & moon sprites & recompiling them, & I don’t feel like doing that now, so that’ll be for later. This is, like, #2515901 down the list o’ most useful optimizations.
Actually, speaking o’ glitches, through the development o’ this level I stumbled ’pon an astounding glitch — most astounding in how long it’s been here without my noticing. For some reason, Autumn would regain oxygen when in that left corner o’ the underwater area with the chest & in that hidden underwater gem cache just ’bove it. ’Ventually I narrowed it down to a single mistyped letter: “X” ’stead o’ “Y”. The code for determining whether Autumn’s mouth was below the surface o’ the water for water blocks wasn’t using her Y value, but her X value. @ 1st this befuddled me how this didn’t completely screw up oxygen in levels with water, but then I realized that every other level with water blocks1 was far mo’ horizontal than vertical & had water far ’nough ’head that the bottommost blocks were guaranteed to be less than your X value, making them essentially just make you lose oxygen if you’re touching them2. Since the difference ’tween touching a block & having your face ’bove the water is subtle, it’s a lot easier to see why I ne’er noticed.
This was a fun level to make. Many o’ these levels are simple, short, & linear, which most o’ the time better fit this game’s simple gameplay; but I generally prefer mo’ open-ended levels with multiple paths, & this mechanic gave me a perfect ’scuse to do so. Though I find it amusing that such a wide-open level can be beaten in 5 seconds, if you’re lucky.
Which brings me to what I wouldn’t necessarily call the worst o’ this level, so much as the part that makes me feel guilty: as the video shows, have fun getting the time score for this level. Thanks to this gimmick, you have a 1 / 5 chance o’ it being possible, & you still have to not play too sloppily, ’specially if you want to avoid getting hurt @ all. But a’least they’re short, quick failures, & these failures likely won’t lose you gems like actual deaths. An idea I entertained was changing the chosen chest from being ultimately based on C’s rand function to being based on something like the animation frame on the water in the o’erworld, but that’s an minute detail for later — & anyway, I plan to change how the water animation is programmed later for optimization reasons, so that would be a complete waste o’ time to do it now.
The gem challenge was harder than I expected, thanks to all those gems down there in the underwater section & Autumn’s impatient lungs. Part o’ this is how long it takes, with such a big level with so many gems scattered round — in the video it takes me nearly 2 minutes; & I know where everything is. Actually, that’s not true: hilariously, as I was playing this, I forgot ’bout a cache o’ 1,000 gems ’hind the rightmost chest, in that hidden cave wall. Thanks to that, the gem challenge is mo’ lenient than I expected, which counteracts this gem challenge’s difficulty.
I’m still thinking ’bout where I want this level. I think currently the plan was that “Tubboat Blues” would be a Cycle-1 level & this a Cycle-2 level, but I’m thinking o’ switching them round. “Tubboat Blues” has many mo’ threats in the form o’ the many Peanutbutterfish infesting the waters; but “Fortune Beach” is bigger & requires mo’ exploration, while “Tubboat Blues” could be beaten in a straight path. On the other side, “Fortune Beach”’s difficulty is primarily its gem & time challenges, while just beating it could, if one’s lucky, require just a few hops o’er blocks, chomps, & 2 crabs to the left. So most likely, this will be a Cycle-1 level & “Tubboat Blues” will be moved to the 2nd Cycle.
I’m almost 100% certain the next level I show off will be “Boskeopolis Underground”, ’less I rename that level, in which case technically I’ll still be breaking my promise3. That level’s already done, in terms o’ basic structure; I’m just sprucing up its graphics ( the most time-consuming part for the kind o’ person afflicted with the perfectionism o’ wanting their game to look as good as, say, Kirby’s Adventure or the Mega Man games, but doesn’t quite have the skills to actually pull it off ).
Also, I’ve just realized as writing this that I keep forgetting to show that link to the Github where this code is kept. That’s OK: it’s probably unreadable by this point. I have this ironic problem where I generally don’t write comments ’cause it’s better to have the code be self-explanatory, & then don’t make the code self-explanatory, completely killing the ’scuse I had for not writing the comments.
Read this game’s unreadable code
