¿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.

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

Crying Lightning

No, I hadn’t taken a break — it just took this long to complete something. I think I’ve been hinting a few times in previous updates that I was s’posedly close to done with this level; & indeed, most o’ the general level layout had been completed, save adding in extra gems & a few extra crevices ( including the diamond, which I realized late in development I’d forgotten to put into this level ).

As usual ’twas the aesthetics that took the longest time. Foremost was that fancy treasure-chest-opening animation, which seems simple, but took a whole day off to accomplish. As always, this involved many silly hacky code that gives the illusion that this is a sane world. To keep my sanity & not gunk up the player sprite’s code with a bunch o’ code that 99% o’ the time is irrelevant, starting the chest-opening animation replaces the player sprite with a totally different sprite in the same place with the same direction. The rest is a series o’ moving the sprite round & changing its graphics frame. & ’course, the sequence o’ movements are handled the same way I code just ’bout everything else, a simple finite state machine switch statement.

The mo’ hacky part o’ this code is that, due to the limitations o’ polymorphism & being so cheap in memory that I didn’t want to waste precious frames on dynamic cast or extra variables, I use the treasure chest’s top_speed_ & start_speed_ members to handle how much the top half o’ the treasure chest is open & how high up the keycane is. Hey, they’re not used anywhere else; they might as well pull their own weight. Speaking o’ the keycane: it’s actually bigger than the bottom half o’ the chest, so I had to shrink it & make it grow as it rises till it reaches full height so its bottom doesn’t poke out from below the chest.

You’ll note @ the end o’ the time-score run that I was able to end the level before the animation finished. Though I do, indeed, want swanky animations so this game looks halfway professional, I insist on not having it slow gameplay too much as so many games do.

& then there was the sound effects, the last jingle being the only thing I crapped out in some MIDI player & still sounds weird — mo’ like eerie alien music than a celebratory jingle.

While making the treasure-opening animation, I implemented fade-ins & fade-outs ’tween game states, a long-awaited change, as the transitions before always looked abrupt & jarring.

I have mixed feelings ’bout this level’s difficulty, but I feel they balance themselves. The level’s short ’nough that I feel like it may be a bit too easy for a 3rd-cycle level ( actually, I originally planned to have it be a last-cycle level, but decided to switch it with “Hoot Chutes”, which will definitely be harder than this ). I considered trying to lengthen it, but it’s actually the length I generally aim for for these levels; it just seems short ’cause many levels, ’specially late-game levels, don’t end up that way for some reason. ’Sides, it feels complete the way it is.

Contrariwise, the gem & time scores are a pain to get. For the gem score, it’s ’cause you have to be in certain places, such as ’bove every fading-in-&-out cloud platform & in that tight space just to the left o’ the beginning, which doesn’t leave ’nough space to run ’way from the lightning. Meanwhile, you have to time jumps o’er the fading cloud platforms & the lightning, & unlike normal playthrough, you can’t wait for both to be aligned well. For some reason I insisted on making these scores as anal as possible: the time score is as quickly as I could possibly do, & the gem score requires you to collect every gem.

However, we could say these challenging scores balance the easy normal gameplay. & as I prove in this video, you can beat both the gem & time score without getting hit once ( which is better than some other levels I’ve made can say, such as “Mart Cart Madness”, which, I think, requires a hit just to beat it @ all ).

& despite these mixed feelings, in general I think this level has a solid gimmick, which surprised me, as I had misgivings ’bout it @ 1st. I was surprised by how fun ’twas to figure out how to get all the gems & get to the end without any delays while maneuvering round the lightning. You’d be surprised by how subtly different timing can make going into that left crevice @ the beginning go from a guaranteed hit to narrowly dodging the lightning. Unlike most gimmicks I lazily program, this one has no randomness, too: the lightning’s on & off durations are always the same length o’ time. I also like how the cloud monster’s momentum works: it’s faster than you, obviously, since otherwise you could just outrun it; however, it’s acceleration is worse than yours, so it takes a long time to turn round & chase back after you.

Looking @ it now, the only weakness I think this level has is that the diamond is in a rather lame place; but my other idea, having you get it by reaching some high place just left o’ the 2 rows o’ cloud platforms in the middle o’ the level from bouncing on a cloud, was e’en lamer. My logic for this hiding place was to hint @ it with the hiding place @ the beginning & the way you have to go through clouds squeezed together like that @ the rightmost end o’ the level. Also, it’s right @ the end as a way to “challenge” you not to be to hasty & grab the treasure chest being looking round.

The next level I’m almost done with is “Boskeopolis Underground” — which would complete all 4 sewer levels. However, that still needs a lot mo’ sprucing up. Also, I’m almost always wrong ’bout what level I’ll finish next, so expect a completely different level next.

Ice Box Rock

’Bout fucking time.

I don’t remember if I mentioned anything ’bout this level last November or December, since those months ne’er happened in 2017, & I’d like to keep it that way; but I’ve been working on this level since a’least November, with the hope that I’d finish it round January. I refuse to believe that it is April; that is unquestionably a temporal delusion.

So much went wrong with this level, all the way up to the end wherein trying to show off everything was a bitch & taught me that I made this level that’s s’posed to be for the 1st cycle too hard. In fact, many o’ this game’s level have janky difficulty caused by my becoming too practiced with them; ’ventually I’ll have to go back & ease some o’ them. Related to these issues: I don’t know if I’ve mentioned it yet, but I’m moving “Sleet Streets” to the 3rd cycle, as it’s way too difficult & long for the 1st cycle ( though most o’ its difficulty comes from being so long without checkpoints ).

Like many ol’ games whose programming I’ve read ’bout, this level is full o’ hacky, inelegant extra code just to twist it into behaving in the weird way I want it to. I wanted the spiked olives ( that’s what those are s’posed to be, by the way ) to be moving already by the time you get to them, so you can’t just jump ’head o’ the 1st 1 & not have a clear path onward, but since they obey gravity, I needed the blocks round them to be solid, e’en when they’re not onscreen. Making all blocks work, e’en offscreen, ( which is how “Rooftop Rumble” works ) was too slow, since this level has a lot o’ blocks; so I ’stead created an extra sprite which just holds a bunch o’ rectangles that it uses for extra collision, but doesn’t draw anything.

However, for months I still couldn’t figure out why the olives still weren’t interacting with them till I finally found a pathetic error in my sprite-interaction loop where I found that I only allowed the “PERMANENT” “CameraMovement” ( sprites only move & collide offscreen if they have “PERMANENT” set; most sprites have “RESET_OFFSCREEN_AND_AWAY”, which makes them act like most enemies in most games: don’t act offscreen, ’cept that they reset if they & their original position is offscreen ) value on the 1st o’ each pair, not the 2nd, so this collision code was ignoring it.

’Nother bug this caused was that, since the blocks round the olives were sprites, the icicles were bumping into them, ’cause while the icicles had their “interact_with_blocks” flag set to false, their “interact_with_sprites” flag had to be true so the player could interact with them. So I had to give icicles their own “SpriteType” value & used that to test them in the custom block sprite code to ignore them for collision detection.

The ice cube sprites also took fore’er to get working right, & they still have a slight glitch where they can eat your jump when you’re standing on them by making a tiny bit o’ space temporarily appear ’tween your feet & it, e’en though it’s s’posed to keep your Y position insync with it. In my defense, this same glitch happens in Super Mario World.

The graphics also took a while, which is the 1 thing I did expect — in fact, it took less time than I expected, which is opposite o’ my custom. Then ’gain, most graphics are just photographs kongcountrized, which is why they look so gaudy. This is where I seriously thought ’bout increasing the color limit to something like 16, as I’ve thought ’bout a few times before, since 6 is just as arbitrary a #, & I don’t truly care ’bout fitting any fake NES aesthetic it doesn’t fit, anyway, like a million other fauxretro games; but by now it’s too late, so 6 colors it shall stay.

In truth, I don’t like this level very much, which adds to my frustration with it. After almost a year & a half, I’ve become disenchanted with this game & its… utter lack o’ ambition. It’s just a generic platformer like a million others infesting Steam. I’ve known this the whole time, ’course, ’cause I intentionally picked an unambitious project idea to start with; but now I’ve hit the point where I debate tossing this crusty backward project for something newer & bigger or finishing it & not letting that year & a half work go to waste.

1 thing I think I’ll do is scrap the original “Spiral” idea & go ’head with the Zelda/Mario hybrid idea o’ having the world map act like a Zelda game ( but with bullets ’stead o’ a sword ). My reason for this decision is that the level themes are breaking apart, anyway, & my desire to work with weirder & weirder themes is causing it. ’Nother cause for my dissatisfaction is my love for fresh level themes in contrast to Boskeopolis Land’s generic forest, desert, cave, ice, water, themes. Meanwhile, I have levels like “Playing in the Background” & “Mart Cart Madness”, which don’t seem to fit in any theme.

In general, I feel like a hypocrite with this game. I’m a bit o’ a contrarian for video games, prefering games that accentuate exploration & giving players freedom o’er cliché pixel-perfect platforming challenges found in every fauxretro indie game out there ripping off Super Meat Boy. & yet, ¿what is Boskeopolis Land but ’nother “challenge” platformer that expects you to play every level the exact way the designer designed it or else fail?

There’s still ’nother game idea I planned on doing later — somewhat o’ a cross ’tween Wario Land 3, Super Metroid, & “The Great Cave Offensive” from Kirby Super Star. However, I fear my ambition may be too high for this. For 1, I’ve gotten kind o’ sick o’ pixel graphics; the problem is, I’m terrible @ animation & mediocre @ illustration, so I don’t think I could muster anything better. The truth is, I did pick pixel graphics for Boskeopolis Land simply due to the limits o’ what I have ( learning to become a better drawer sounds better in the abstract when one pretends that there exists infinite time ) — the same reason I have to use royalty-free music.

The good news is that, this project being commercial-free, there are no true standards one can force ’pon me, so people just have to accept what they can get. I mean, a’least it’s not those shitty Linux Mario bootlegs, “Super Tux Bros.”, or whatever they’re called, that come with Ubuntu.

Play in the Background

For some reason, whenever I claim that the next level I make will be something, that’ll turn out to be a lie.

This is a rehash o’ a gimmick from Legend of the Four Switches, ’cept half-competently implemented so that you can’t just jump on the switches themselves to bypass the whole gimmick.

I also gave this level a stageplay graphical theme, including checkered floor graphics that I later realized look a bit too similar to Super Mario Bros. 3’s… O well: I’ve seen plenty o’ commercial games outright steal the original Legend of Zelda staircase or Super Mario Bros.’s bricks far mo’ closely than my checkered ground.

Implementing the gimmick was simple: it just uses the on & off switches, having “on” be you in the background & “off” as you back in the foreground. Background blocks are set to only be solid when the switch is on, & foreground blocks are set to only be solid when it’s off. Also, foreground blocks have priority ( drawn o’er non-priority sprites ) when the switch is on & not when the switch is off.

Source code

Audio

I finally got round to adding sound to this game, after almost a whole year o’ silence. The music is all royalty-free songs offered to the public by Kevin MacLeod on Incompetech, which may be temporary, may not be. Since I have no musical skills, I can’t imagine how I’d make a decent soundtrack for this.

As for the sound effects, they’re made with various Flash programs online that randomly generate some wave patterns.

Honestly, it took mo’ time wandering MacLeod’s site & listening to hundreds o’ songs in search for the best song for each level — an exercise that brings me back to the Super Mario World romhacking days when I’d do that with user-submitted SPCs on Super Mario World Central, since in addition to having no musical skills, I couldn’t e’en figure out how to port already-composed video game songs into Super Mario World’s weird format.

Meanwhile, using SDL2’s music & sound libraries only required a couple hundred lines o’ code & a function call strewn in various places to tell the global Audio class to play some song or music. The most complicated thing was preventing sound effects from noisily o’erlapping each other, such as when collecting gems, without blocking sounds I do want, such as the sound for collecting a diamond, which I solved by dividing the sound effects into channels & stopping only that a sound’s channel when playing a sound. Thus, collecting multiple gems will interrupt other gem sounds, but not a diamond sound, since that’s on a separate channel.

But I can see there’s still some bugs with the way the sound works. As the video shows… well, 1, recording with sound causes slowdown, which ne’er happened before; but related to that, if slowdown does happen in-game, it’s separate from the music, leading to sync issues. The playthrough o’ “Warm Up” shows this: it’s timed so that the song ends right when the timer reaches 30 & the level ends; but ’cause o’ slowdown, the song ends early & loops awkwardly. That ne’er happened in any o’ my earlier test — only when finally recording & encountering slowdown.

& there’s probably hours o’ fiddling to be done. Different songs are all o’er the place in terms o’ volume. For instance, while the mines music ( officially, “Chillin Hard” ) is quiet, “Mart Cart Madness”’s ( officially, “Got Funk” ) is so loud, you can hardly hear the sound effects.

As the video also shows, I spruced up the level-select screen so that it’s not just plain black & white.

Lunacy

Beating the time challenge for this video probably took mo’ effort & time that designing this level. ’Cause jumping is so slow, any extraneous jump can fuck you o’er.

Part o’ me thinks this level may be too difficult, considering it’s s’posed to be a 1st-cycle level. On the other hand, the level’s deceptively easy: while the slowness makes beating the level quickly hard, just beating the level in general is easy, since you get plenty o’ time to land jumps. Thus, 1-block jumps you’d expect from late-game Super Mario Bros. levels are trivially easy. Similarly, e’en though the spike passages are tight, it’s not too hard getting through them without getting hit ( though I think you absolutely need to be holding the run button to get through some passages ).

My original plan for the graphics was to have crater moon graphics; but every time I tried drawing them they looked like crap. Then I came up with the idea o’ blocks shaped like Hershey chocolate bars, & went with that — which fits, since canonically in the Boskeopolis universe the moon’s surface is s’posedly made o’ white chocolate. I still think this level looks a bit too sparse; but I could spend eternity sprucing up the graphics in every level, so it’s best to let some levels look simple.

Next level will probably be a harbor level with “Rusty Bucket Bay” sludge water as a gimmick.

Source code

.

Swanky New Title Screen

I finally got sick o’ looking @ that basic white screen with plain black option text. Since I noticed many o’ the Game Boy Color games I used as inspiration, such as Wario Land 3 & Super Mario Bros. Deluxe, used slow scrolling backgrounds, I used it, too. The only problem is I haven’t finished the skyscraper part, which currently only has 3 buildings that repeat way too much.

As for the menu items, after a while o’ thinking o’ weird borders & background shapes ’hind the text, — since the text obviously wouldn’t contrast ’nough from a mo’ complex background — I took inspiration from web design & just made some flat-design button links. They e’en have a slight fade-in & fade-out — ’cept it required tacky switch statements rather than a simple “transition: all .5s”.

’Nother effect I’ve been thinking o’ adding for a while was a way to make mo’ interesting transitions ’tween message screens & the o’erworld & level — the goal message & the victory & failure messages. The idea I had was to have it fall downward, & then swipe sideways when it’s done: however, this’ll require some tinkering. For 1, I’ll need to make it so that it changes all lower states to the new state while keeping itself ’live ’long ’nough to swipe ’way ( falling in will be easy: just push the message state onto the previous state ’stead o’ replacing it ). Mo’ importantly, the goal message state will need to run while the o’erworld state is still there, which means the level state won’t initialize yet. The problem is that the goal message state needs the goal in order to get its message, & the goal is initialized in the level state. ( As it is now, the level state technically starts before the message state appears — the message state is simply added on in the 1st frame, before the level state has a chance to draw itself ).

Pepperoncini Pyramid

This is a level idea I’ve been thinking ’bout for a while. Inspired by Wario Land 4, — or, mo’ directly, a story from Boskeopolis Stories¹ — you go halfway through the level to collect a moon, which starts making the pyramid collapse, giving you only 45 seconds to roll round back to the start, where the door is now open ( & glowing somehow — but it’s a video game: doors always glow in video games with no explanation ).

Mo’ & mo’ I’m getting a habit o’ spending probably too much time on presentation — & there’s still stuff I ne’er got round to adding, such as cracks in the wall or hieroglyphs in the currently plain background. O well: there’s no law that says I can’t go back & add things later.

Some o’ the frivolous extras I think look good, such as the way the the block enemy’s eyes follow you when you’re near it, the flashing timer that bounces down & fades into the HUD when you collect the moon & the shaking camera & falling pebbles ( secretly just 5 pebbles that keep randomly changing size & position when they pass the bottom o’ the screen ) when the pyramid is collapsing. Other, such as the spinning moon… I’m less sure ’bout.

Time works weirdly here: despite what happens to the clock when you get the moon, the game still counts how many seconds you spent in total in the level before beating it, & that’s the score you get — beating the time challenge requires you to go just as quickly before the moon as after ( note: in addition to the clock not moving during the moon-get cutscene, the time spent in that cutscene doesn’t count toward your best time, as the level state doesn’t run @ all during it ).

Funny ’nough, though, the gem challenge is actually much harder than the time challenge. As the video shows, I could do plenty o’ sloppy playing & still make the time challenge; but the gem challenge gives you very few excess gems, & many o’ the gems are a 1-time-only grab while falling.

Source code

A 2fer this time.

The Minus Touch

No, I still couldn’t get OpenShot to work with this footage; but Kdenlive decided it wanted to start working ’gain for some reason.

Part o’ me feels like I went a bit too far with this level, as my long sequence o’ deaths show in the video. I believe it took me close to an hour to finally get a winning run. Then ’gain, I’ve done much worse in still-perfectly-sensible games & have been noticing that this game has been tending toward easy. Needless to write, this level is in the last cycle.

1 o’ the complications o’ this level was that something that was s’posed to be a bonus in any other level is a huge problem in this level: the hitboxes on the gems are way wider than their graphic. This made the parts where you have to squeeze ’tween gem walls & dodging the falling gems in the long ladder climb just after much harder than they should’ve been, since you have the squeeze tightly ’tween the blocks, but can’t see their boundaries, so you nudge just into 1’s hitbox, e’en though your character’s graphic is clearly outside o’ the gem’s graphic, making it deceptive & cheap. So for this level I made ’nother gem block, but added some custom block conditions that limit its hitbox so that it’s only its graphic.

I also think that drop @ the start is probably a waste o’ time that only makes the level’s difficulty mo’ frustrating than it should be. The fall’s s’posed to make you think you have to weave ’tween gems, which is technically possible, but not something I’ve e’er done, I don’t think. But as the video shows, you can just go a block left to the center & you’ll pass all the gems. I’m not sure if this is a way to reward clever players or a bullshit gotcha on the player that punishes them for not reading a walkthrough watching this video or reading this post.

On the other hand, I like the shape o’ the level: how it’s a long plummet from the top to the bottom that goes quickly, followed by a long climb back up to the top that takes a lot longer. 1 technique I’ve devised to help me with designer’s block I’ve been having was creating simple shapes for levels, a pattern you’ll see in the next level.

The length was something I mired o’er quite a bit. I’ve mentioned quite a few times that I generally want to keep levels to 15 – 30 seconds average time, since these are s’posed to be short bursts without checkpoints. However, this is a special level & 1 that’s s’posed to be the hardest in the game, so having it be longer is a fair way to increase the challenge, so long as it’s not excessive. In this case, my time was ’bout 1:40, but if one’s rushing one could probably do it in ’bout a minute ( testing it with the “lose if you touch a gem” gimmick turned off, I found one could easily make it to the end within 50 seconds, e’en if mostly trying to avoid gems ).

The time challenge is 1:10, which is probably plenty if one’s going fast; but I’ve ne’er gotten it, since just beating this level is a problem for my meager skills. It’s probably mo’ lenient than any o’ the other levels, which is good: I want to have the harder levels have mo’ lenient challenges while giving the easier levels much stricter challenges to balance things. In contrast, the 1st level you have to do just ’bout perfectly to get the time score.

Part o’ the challenge o’ a micromanaging a level’s length is trying to ensure you don’t pad out the level by o’erusing ideas, but don’t neglect good ideas, complicated by the fact that ideas themselves can have multiple subideas within them; & then you have to make sure the length o’ each idea is right. In this case I had quite a few ideas, such as walking gem enemies, alternating falling gems ’bove a ladder, & gems rolling down a hill that I probably could’ve done mo’ with, but would’ve risked making the level too long & tedious. Better to leave players wanting mo’ than wanting less.

In particular, the walking gems could have been complicated in many mo’ ways beyond just having 2 guarding either end o’ a straight hallway. Then ’gain, part o’ me feels those sprites are a bit unfair: their movement is randomized & they move so quickly that it feels like luck whether you can get through them unscathed. They are unquestionably the worst part o’ this level.

Conveyor Slayer

This level used to be called “Steam Engeenius”, but then I realized it has nothing to do with steam @ all. Its current name still feels odd, though: it certainly focuses mostly on conveyor belts, but its a 1st-cycle level that’s quite easy, so the “slayer” part sounds hilariously inapt. It’s like calling “Yoshi’s Island 2” in Super Mario World “Chaos Corner”.

This is ’nother example o’ the “shape level” idea I mentioned before. While trying to design this level I kept envisioning twisty paths that go all o’er, & then back to the start, but I felt that ’twas, rather than being mo’ interesting or “complex”, just messy, & went in the other direction toward an elegantly simple & memorable shape. The original idea was that it’d be a circle, but I found that made actually moving through the level janky, so changed it to a rectangle. It actually looks better this way, since it’s a factory & should look boxy & artificial.

Getting this level to work right was mo’ burdensome in terms o’ programming, thanks to a bunch o’ li’l bugs that either got you stuck & made the level unwinnable or made it easy to cheese the level. The absolute worst, & yet something I found quite late, was my realization that collision detection had been wrong this entire time: the saved left o’erlap for something o’er something else ( a block o’er a sprite, for example ) actually uses the formula for o’erlapping from the right & vice-versa. This hasn’t hindered this game much since nothing has used the horizontal o’erlaps yet. However, there’s a glitch I think I mentioned earlier wherein you could jump under the corner o’ a block & jump through the wall, going straight up. In this case, that allows one to skip straight to the end, which is a problem.

The other problem was that if the conveyor shoved one into a wall, they’d get stuck fore’er, which forced me to check whether the player is right next to a wall & make the conveyor not work if so.

’Nother problem was the main gimmick: the goal is blocked off by a passage so short you have to be ducking with a conveyor going in the opposite direction. The only way to get through is to hit a switch & so the conveyor goes in the other direction. The problem is that Autumn can hop round while ducking, so she can skip right through, & I didn’t want to change that or make her move super slowly while duck jumping, since that’d mess up her movement in other levels; so I just added a patch that makes it so Autumn can’t jump while ducking on a conveyor belt.

Finally, there was the challenge o’ making block graphics change based on whether the switch is hit, which involved making ’nother subclass o’ the “SpriteGraphics” class & adding ’nother wasteful update virtual function specific for the block updates so the “EventSystem” can be passed to it without having to go through & edit all the update functions for every subclass o’ “SpriteGraphics” or something. The “SwitchGraphics” sublcass itself just holds 2 “SpriteGraphics” unique pointers, making its own data useless, which is also a waste. 1 thing I’ve learned in this project is to better separate interfaces with data: most polymorphism is just through “render” & “update” functions, nothing else. All the other “SpriteGraphics” subclasses used the vast majority o’ the same data, so it seemed right… but then “SwitchGraphics” comes round & proves you can’t be sure o’ anything fore’er.

As for the frivilous extra update function, I should probably just make “EventSystem” a static singleton, since there’s only e’er 1 & I hate passing objects round a bunch o’ functions. Most people seem to say that’s better than having globals, but I’m starting to disagree. If anything, all this passing round arguments only couples things mo’ & makes no sense since it should’ve be any concern o’ anything that calls any update functions what other things that update function uses. My experience with making the “Inventory” class a static singleton has only been good. I haven’t had any glitches appear due to this “evil” global, but have gotten cleaner, easier to understand code. The same might apply to the “BlockSystem” & “SpriteSystem” — something I should look into. The only downside is that these static classes would always be using memory throughout the whole program, e’en in the title screen & o’erworld, where they’re not used ( the inventory, on the other hand, is used everywhere ). Then ’gain, the vast majority o’ your time takes place in-level, & it’s not as if the title screen or o’erworld map are begging for mo’ memory — they’re some o’ the most lightweight parts o’ the program.

Anyway, there’s much worst inefficiencies in this game’s half-assed code that it’s silly to point to an extra virtual function as the culprit ( the general o’eruse o’ polymorphism, which requires using pointers for collections & prevents taking advantage o’ data locality is probably a worse problem ).

& then there’s the graphics, which usually takes the bulk o’ development time. That upper-left gem cache made me start to think that I was wrong to make blocks just have a simple 16×16 block rather than 4 8×8 blocks, since I had to make a bunch o’ blocks that just copied scraps o’ other blocks, & these had to have their own 16×16 graphic block, while if I just had them be 8×8 blocks I probably could’ve just had them reference a bunch o’ already-existing blocks. Then ’gain, blocks wherein all 4 corners are different would’ve been much mo’ tedious to make, so I guess it’s a tradeoff. Still not sure which would be mo’ efficient: smaller graphical files or fewer draw function calls. Either way, it probably would’ve been tedious, & we should speak o’ it no mo’.

I mired o’er the shadows under the blocks, which are just 4 few gray rectangle blocks with slight transparency. I go back & forth o’er whether using transparency & blending is “cheating”, since it technically creates extra colors that aren’t in the “paletttes”. Then ’gain, the palettes don’t follow any real retro game system & I feel bad ’bout how o’erused emulating retro graphics is, too. If it wouldn’t make palettes mo’ tedious to make & wouldn’t probably make the graphics o’erly complicated, I’d probably increase the # o’ colors per palette, anyway — just so long as the hue is generally monochrome. Then ’gain, I don’t think I kept to that, either — certainly not in the o’erworld palettes. After trying out having manually-drawn shadows & seeing both how ugly it looked & also the sheer # o’ extra blocks I’d need, — 4 * the 9 blocks o’ the BG — I decided that creating extra work for myself & my program just to emulate a limitation o’ ol’ hardware that only existed to make things easier for limited hardware was the very definition o’ insanity ( though that doesn’t stop me from keeping the palette system ).

& then there’s the falling fist sprite, which looks silly. I’m OK with drawing in general, but awful @ animation. This wasn’t helped by the fact that I couldn’t imagine how those craning things move up & down & couldn’t e’en research it since I don’t know that “those craning things” are actually called. So ’stead we get this 1 image that just stretches out & in based on the sprite’s distance from its original Y position. It looks mo’ like paper than those craning things, ¿but who cares? I can always fix it later. Shit, I still haven’t fixed the interior maps o’ “Sleet Streets” so that they don’t look awkward in the newly resized resolution:

I’m still not halfway done with all these levels, by the way. I’d joke ’bout how I originally had an idea o’ finishing this project by the end o’ the year, but e’en when I said that I knew ’bout the “90-90” rule o’ programming, so e’en then I knew that was bullshit. This project will take 3 years — which means it’ll truly take decades.

Here’s the shitty source code ’gain

The 1st real¹ program I e’er remember writing was in what I thought was C++, but was closer to C. The header includes were C-style & none o’ my programs used classes ( though there is a C-style struct ) or STL. The only thing “C++” ’bout this program was that it had a CPP extention & didn’t put “void” in empty parameter lists. Nonetheless, I was confused by these 2, since I called this folder “C++” & remember reading a ( quite terrible )² book on C++ @ the time.

There was no particular inspiration. When I was a teen I’d oft check out wildly different nonfiction books from my local library. ’Twas in a songwriting book that I learned that imperfect rhymes are better than perfect, since they’re generally fresher ( none o’ that moon-june shit ); ’twas in a podcast book I learned ’bout Audacity; ’twas @ the end o’ an ol’ For-Dummies book ’bout YouTube that I got to read the writer pontificate ’bout how to survive in an apocalypse ( I think the For-Dummies books let writers write whatever the hell they wanted in the last few chapters ); & ’twas in Game Programming All in One that I truly 1st learned how to program, round the spring & summer o’ 2009, I think.

I used to have this idea that a simple “enemy chases you & hurts you if it touches you” was the best simple game idea to do 1st. I think I got the idea from reading ’bout Atari founder, Nolan Bushnell’s, 1st program on some ancient computer, which I read ’bout in yet ’nother nonfiction book, The Ultimate History of Video Games, by Steven L. Kent, a hefty 600+ page book that I highly recommend. Thus, this was the gameplay o’ my 1st game, “Nihilly the Nihilist”… or “Nilly”. I was ne’er consistent on that part. Also, I always pronounced it “Nilly” till I finally learned the proper way to pronounce “nihilist”. You were chased by somewhat KKK-looking guys with white bandanas wrapped round their faces & deep black holes for eyes called “Fucksters”. You can see that this was an immensely edgy fox-&-chicken game worthy o’ Edmund McMillen.

That’s ’bout it for art design. I couldn’t comprehend such arcane concepts as programming backgrounds ( I think I was so paranoid ’bout resource use for some reason that I feared redrawing so many graphics every frame or something — I don’t know. I also thought objects were resource intensive & should only be used for “big” things, whatever those were, for some reason. You can probably see that I still thought o’ computers as some magic too powerful to use without discretion ); therefore gameplay was played o’er plain purple. Not sure what that purple was s’posed to represent — other than a way for hackers to figure out how to steal my passwords, ’course. The title screen was just whatever font Allegro decided, apparently, o’er blue background — presumably inspired by ol’ Final Fantasy games. Maneuvering menus was programmed through a bunch o’ lock integers acting as booleans ( & global, to boot, for some reason ) so that 1 button press wouldn’t cascade through all the options.

If you look @ the linked code, you’ll see that I had a strange method o’ indention. Interestingly, I still used the Allman for braces, though conditional statements & function calls would randomly fall out o’ this pattern. Mo’ importantly, you’ll notice that I didn’t quite understand functions very well. I seemed to view them as simply a means o’ dividing game states, & nothing mo’, while blissfully copypasting large chunks o’ code. Also, for some reason I made every function return an int, e’en though none o’ them are used for anything. Each frame o’ each sprite is just it’s own graphic file plopped right into the big “gameplay” function. @ the time, I certainly didn’t know what the “*” next to the “BITMAP” type was for, but I dutifully copied & pasted it there as the book told me to do.

As a larf, I downloaded Allegro 4 & compiled this program. Unsurprisingly, it’s utterly broken. Content stretches far past the end o’ the screen & everything runs ridiculously fast, like a 90s game that comes free with Cap’n Crunch cereal. I guess that’s to be expected when I was too naive to understand the whole complexity o’ framerate maintenance & I test my software on a 169MB-RAM laptop that was mo’ than a decade ol’ e’en back when I had it ( how I miss you, Grape Faithful ). Also, Valgrind told me it had 16 whole bytes o’ leaked memory, which is, oddly, less than an empty program programmed in D, apparently — a’least on my computer.

As part o’ my nostalgic research, I actually tracked down the book I learned from, which is apparently on GitHub. There I learned that the writer said he was writing his code as C++ projects with mostly plain C to keep his code from sucumbing to C++’s object infection, STDs, & colon cancer. I also learned that apparently the GameCube & Game Boy Advance SDKs, or whatever, used GCC. He also hilariously recommends readers to actually learn C before starting, which I didn’t do.

There were a few other programs I made round this time, too. In my language arts class @ the time I had to memorize the work, the chapter, & the speaker of certain quotes from works like Macbeth & The Waste Lands, so I made some quiz program that showed my amazing understanding o’ functions by having each question have its own function — there was no fucking way that version o’ me would understand the complexities o’ passing string pointers & concatenating them with the parts o’ the question that didn’t differ ’tween questions. I think I did figure out how to have tree tiles based on multidimensional arrays in 1 program. But none o’ it went anywhere, & I soon lost interest & didn’t come back to programming till 2014.

View e’en worse code than Boskeopolis Land.

Freaky Forest

Well, a’least OpenShot worked ’nough for me to be able to make this video… But then YouTube decided it didn’t want to understand how to process videos anymo’, & also decided that it should just completely erase the uploaded video, too ( wouldn’t e’en show up in “Video Manager” as a “…” video, like usual ).

Part o’ me wanted to do mo’ with this level, but then ’nother part o’ me reminded myself that these levels are s’posed to be 15 – 30 second romps without midway points. As the video shows, the speed challenge is 22 seconds, but if one goes after all the collectibles ( the gem challenge for this level requires you to get all o’ them ) & messes up the final part a million times like I embarassingly did the 1st recording, one can take as long as a minute & 40 seconds or so. I s’pose that’s a good balance.

Like usual, the main gimmicks are ripped off from ’nother game — in this case, both are from Wario Land 3: dodging & hopping off birds is from “Forest of Fear” & the ghostly fading in & out is basically just the fading in & out clouds in this game’s “Cotton Candy Clouds”, which came from Wario Land 3’s “Above the Clouds”¹, though I’d say “Ghostly Grove” ( which is a much better name than “Freaky Forest”, but I didn’t want to be too much o’ a thief ) from Donkey Kong Country 2 was mo’ an inspiration.

I do kind o’ like the pathway this level goes through. Looking through my other levels, I was shocked by how oft they are just straight horizontal lines going from left to right. Though, now that I recall, I think I used this same general pattern o’ going right a li’l & then going leftward the rest o’ the way in “Milky Mountains”. I think I originally planned to have a key up on that cliff to the left & then have you come back down & go farther right past the underground hole to use the key, perhaps to enter a mansion or something, but decided that’d o’ercomplicate the level. I also had the idea o’ having rapidly spawning zombies like in Ghosts ’n Goblins, but rejected that for the same reason. There are a lot o’ things I could do with a halloween theme, & I’m still thinking ’bout making it its own theme, if not for the fact that I already have too many themes.

Finalizing the art for what are s’posed to be crow enemies was odd. As mentioned, they’re clearly based on Wario Land 3’s bird enemies, but I didn’t want to ripoff their entire graphics, too, so I looked @ other sources, including real crows, & in doing so I noticed how bizarre it is to have birds just floating in air, without e’en flapping their wings ( 1 thing I did ripoff from Wario Land 3 is that the crows raise their wings to indicate that they’re going to charge forward ). So I added a li’l 2-frame propeller ’bove the crows’ backs, which I found somewhat amusing — winged, flying animals that also have redundant propellers.

The ghosts in the underground section, which are basically just larger Eeries from Super Mario World, are based on a creature from Boskeopolis Stories: a “kappa-obake”, which is a pun off kasa-obake. While the latter is a 1-eyed umbrella ghost with a large tongue & a human foot, “kappa-obake” is the same, but a raincoat ( 合羽, pronounced “kappa”, is an archaic word for “rain cape” or any similar clothing one wears in the rain ) ’stead o’ an umbrella ( ’cept I forgot the foot ).

I have mixed feelings ’bout the background. You can tell it’s handdrawn by how tacky it looks. I also think I resized them a bit, which probably didn’t help. Then ’gain, they have a kind o’ Commodore 64 look to them that I like. I also thought ’bout filling in with black the outlines & inside o’ the trees so that the flashing lightning doesn’t show through them or the farther-back trees don’t show through the nearer trees; but then, I also kind o’ like the look o’ the flashing background going all the way into the trees.

The flashing background involved a li’l code change that was surprisingly easier than I expected. Originally, the flashing backround was some hardcoded thing for any map that had a bg_color # o’ 7; now I changed it so that there’s some mathematic formula used on any bg_color 7 or larger, allowing for flashing ’tween any 2 colors o’ the palette. So bg_colors 7 – 12 have color 1 as the background, but flashes to colors 1 – 6, 13 – 18 has color 2 as the background & flashes to colors 1 – 6, & so on. Or something like that; ’twas actually a while since I changed it. I believe getting these 2 backgrounds colors from that 1 # uses the same 2 formula I usually use: “x = n % w” & “y = floor( n / w )”, ’cept “x” is the 2nd background color & “y” is the 1st, & “w” is the color limit ( 6 ). So 13 would flash from color 2 ( round down 13 / 6 to 12 / 6, 2 ) to color 1 ( since 12 / 6 evenly, 13 leaves 1 remainder ). That sounds ’bout right. Color 0 should be ignored, since it’s always just transparency.

An extra graphical detail ( you could call it a hack ): in the underground section, the bottom-most ladder block isn’t actually a ladder block, but uses a BG block with a ladder o’er the rocky background so that the grass block can go o’er it. That way the grass still goes o’er Autumn, but the ladder is still ’hind her. This works fine since it’s impossible for Autumn to grab a ladder without standing, so she has to be touching the block ’bove that, too, & thus will always be interacting with the ’bove block when touching the bottom block & able to climb.

Speaking o’ the rocky background, you’ll probably notice that that’s just a copy o’ the inside rock walls o’ the mine tileset, but with only 2 colors.

1 final interesting note: the tall tombstone @ the very end is actually a sprite, simply ’cause ’twas both easier for me to make & mo’ efficient. It’s easier since it meant I just needed to make 1 immensely simple sprite class, rather than 24 block types; mo’ efficient not only ’cause it doesn’t bog down any other woods levels with 24 extra block types only used for this 1 particular level, but also ’cause 1 sprite is mo’ efficient than 24 blocks.

Your blood will curdle @ how inefficient & buggy this horrifying code is