Accompanying music

Accompanying music

¿How long have I put off this post? I believe I was close to done with this level’s general design not long after my last post, & ‘pon just checking was surprised ‘twas only a month ago, e’en though it felt like much longer than that. Good: the longer life feels, the slower comes death. In fact, I distinctly remember I was finished before the end o’ that SGDQ thing. Thus, most o’ July was spent refining this level’s graphics, which always takes the longest, & irrelevantly creating options screens ‘cause I was getting tired o’ playing these levels with a keyboard.

As the video shows, this level is a rather long maze level¹ wherein you go back & forth ‘tween 2 rooms through sewer holes. As the maps below show, the sewer holes correspond to each other — using a sewer hole literally changes your map without changing your position @ all.

This time I didn’t bother editing the video, since it wouldn’t cut out much to be worth how awkward the abrupt cuts would look. ( The downside to my smoothing out the graphics &, ‘specially, adding audio is that it makes it harder to make clean-looking cuts: before the fade-outs & music, those message screens made cuts stupidly easy ). I tried to double-dip the 1st showing o’ the level with getting the gem challenge, but kept making mistakes grabbing gems, forcing me to go back round. Unlike most levels, I made this 1 force you to get every gem to beat the challenge. This is balanced by the level itself being calm & easy to beat, once you figure it out, ‘specially for what’s planned to be a 4th-cycle level. There aren’t e’en any enemies, so it’s literally impossible to die in this level. “Soupy Sewers” is harder ( ‘pon recently playing it & “Flush Flood” I’ve found that it’s harder than that level, too, which was less intentional ). I don’t mind it being a bit o’ a breather level before what I plan to be mo’ challenging levels following.

While I like how subtly winding most o’ the middle part o’ the maze is, I don’t know how to feel ‘bout the hidden key: it feels a bit cheap. The fake spike trap, too. Granted, it’s such an obvious hoax, since it’s the kind o’ trap that’s impossible to fall in accidentally; but making seemingly solid blocks act move-throughable as a puzzle always feels somewhat cheap to me.

Also, I feel like I might’ve made these rooms too rectangular. It’s not as if I didn’t have the sloped blocks already I could’ve used; the map’s just so packed together that I felt I couldn’t do it without having parts bump into each other. That said, looking @ it now, I could’ve had some o’ the vertical parts have sloped parts. I probably should’ve had that long block-climbing section have slopes ‘stead, since that part’s bland, anyway.

I love how I went all out to put all the moving water detail & the detailed background, only for much o’ it to be hard to see due to the darkness. Some may feel making things too dark is a cheap gimmick & that I should be deprived o’ a Twinkie, but this level has no serious platforming challenge, so it’s not much o’ a burden, & I actually despise Twinkies. A’least I added that pointless spotlight @ the last minute. I once planned on having a mines level with a “race to hit switches to keep the lights on” gimmick, but wisely decided that that gimmick is o’erused & obnoxious. “Blackout Basement” is 1 o’ the most bullshit levels in Donkey Kong Country.

This time I didn’t bother making a looping or tiling background, but just made a big image that fits each entire map. This made making the background easier in terms o’ logistics as I didn’t have to think ‘bout how to make it seamlessly repeat without being obvious that it’s repeating or do a bunch o’ complicated layers o’ backgrounds or create dozens o’ useless blocks to add li’l details like the posters & graffiti — ‘twas as simple as just drawing a picture, with no programming calculations needed @ all. I was surprised this level runs as smoothly as it does ‘cause o’ this. I’m not exactly sure how SDL’s textures work ( the downside to black-box encapsulation, as many stern C, & ‘specially assembly, programmers bemoan ), but I know the way the image files themselves work, by being PNGs with large parts o’ each image not being filled in ( parts ‘hind sold blocks ), the image files aren’t as heavy as they could be @ that size.

The graphics that took the most work was that sewer hole transition animation. Worse, it required me to add complex code that verges on entangling spaghetti. In my defense, I did try to isolate the code to the EventSystem class as much as possible; but I still had to add an otherwise needless render function to the EventSystem to be called by the LevelState every frame, though it’s only used in 1 level, & did had to add some extra code to the PlayerSprite class to take it into consideration. Also, now that I think ‘bout it, the EventSystem class is looking eerily like a God class. & as the wise programmer Bakhunin said, if there exists a God class, we’ll have to kill it².

On the other end, it did save me from having to painstakingly add every warp point to the level document: since I had to add an extra, heavily-reprogrammed version o’ the warp code to deal with all the differences, I could easily change it so that it just changed your map without changing your position. This also made warping smoother as your corresponding position in the other map is the exact same, by the pixel, rather than being a specific position in the middle o’ the corresponding sewer hole regardless o’ where you were position on the other side before warping.

‘Nother boring detail: in order to minimize memory waste for this 1-level thing, I made the sewer hole code — it’s image information & such — a pointer to an object so it wouldn’t increase the size o’ the union it’s in too much. But for a while I messed this up in a subtle way, though easy to solve point: I made sure to clean up the pointer whenever the EventSystem object is reset, but forgot that sometimes it isn’t reset but straight-up eliminated through RAII when leaving a level ( the solution being the typical RAII solution o’ a destructor ). This is why it’s good to test with valgrind a lot.

Actually, valgrind brings the final point o’ my process: finally implementing the options screen. For the last year or so I’ve been focusing mostly on just completely the levels & planning to implement these other things when the main content was done, but I got sick o’ having to use a keyboard when playing all the time, & for some reason decided to make an options screen to remap keyboard & controller controls ( as well as save & load these mappings from a config file ), & before that a way to change screen resolution through options. I’ve been thinking o’ doing more o’ these other things to better use time wasted in designer’s block, as there’s still a bunch o’ things I want to implement, like shops in the o’erworld that sell things from extra hit points, bonus levels, improved oxygen, & other things. In fact, I’ve just thought it’d be fun if, after beating the game, you could buy Goldeneye 007 style cheats that could make you ridiculously faster or give you a double jump or other things ( which would disable getting time & gem scores when using them, ‘course ). You could say this ultimately comes from a transition in my expectations for this project: from a mindset that wants to ensure I stay focused & actually finish this project to an acknowledgement that I’m definitely finishing it @ this point & a desire to optimize the use o’ my time.

Actually implementing the joystick didn’t take too much time this time ‘cause I already did it before, I just commented it out ‘cause it causes a memory leak, a’least according to valgrind, that I can’t fix — it seems to be on SDL’s end, not mine. After wasting way mo’ time that I’m happy ‘bout trying to upgrade SDL on my computer, I’ve come to accept it. You could debate whether it’s a true memory leak, since it’s a single “loss” o’ memory that will ultimately be cleaned up by the OS when the program is closed. Memory leaks are only truly meaningful when they’re a repeated loss o’ memory, since that is what leads it to actually cause problems: creeping loss o’ memory till you ‘ventually run out.

However, the 1 serious problem is that I still need to watch out for my own memory leaks, which do still fall into this problem; but ‘cause valgrind is whining to me ‘bout SDL’s joystick code, it clouds my own memory leaks. My solution this time is simply to keep all joystick code ‘hind compiler codes so I can temporarily turn off joystick functionality when testing for memory leaks. The only downside is that for some reason I have to clean & recompile my whole project whenever I want to make this compiler change. You’d think just deleting the object files for the input & main files would suffice, since they’re the only files that acknowledge any o’ this code. All everyone else knows is some function that returns some entry to some array that is no mo’ tied to the joystick code to key presses, with the controls options knowing ‘bout some other functions that send some abstract enum value corresponding to an action to the input & taking in strings from input. No one else e’en knows that “joysticks” or “key presses” exist.

Below is a video demonstrating the new exciting options screen:

As usual, I had to remake this video many times ‘cause I kept noticing subtle aesthetic flaws like missing sound effects or not-perfectly-spaced text.

Anyway, all that matters in all this is that I 100% kept my promise & did “Boskeopolis Underground” next, & e’en kept it @ that name, though I did consider renaming it to something like “Septic Labyrinth” or “Gutterly Annoying”, since “Boskeopolis Underground” sounds rather bland & the reference will probably be lost on everyone. But those other names sounded e’en stupider, & the last thing we need is ‘nother alliteration name. I’ve gotten sick o’ those. Yeah, it’s a cute reference to Rare — but sometimes cute references just fall into laziness, ‘specially the “Food Place” pattern ripped off from Kirby. That’s a cute reference when you do it in literature; but in video games, then it just becomes incestuous. Honestly, I’m thinking o’ renaming a bunch o’ the levels I’ve already done with lame names like “Milky Mountains” or “Soupy Sewers”.

No promises for what’s next, though, as I’m working on a few new things simultaneously. However, close candidates are “Dark Sahara”, the 3rd-cycle desert level & last I need to develop, & “Good-Ship Lifestyle”, the 4th-cycle pirate level. For the former I’m still thinking ‘bout how I want it to end, & I’ll probably finish it 1st; the latter has the much mo’ arduous roadblock: I’m thinking o’ giving it a boss, which’ll involve a lot o’ complicated programming. Then ‘gain, I may separate the boss as a separate “level” — not the least ‘cause I don’t want a player to have to go through the whole level & boss in 1 life & would rather avoid adding midpoints just for 1 level. I still want to finish “Petrol Pond Place” & maybe “Mt. Volcocoa” this summer, but still haven’t figured out how I want them to be designed. With “Petrol Pond Place” I toyed with a tube you could move round in, but found trying to implement it difficult with this game’s rather rigid block-based collision detection that make walls thinner than 16 pixels infeasible ‘less I add or change a lot o’ code.

Acompanying music

Accompanying music

Accompanying music

This morn I saw a long thread o’ silk running down my bathroom mirror & saw on the wall ‘side that mirror a moth resting by a lit lightbulb.

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 blocks¹ 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 them². 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 promise³. 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