Tubboat Blues
I plan for this to be the 1st “pirate” level, e’en though it actually takes place in a bathtub.
I have mixed views ’bout this level. I put a lot o’ effort into it, — which is a way o’ saying ’twas a pain in the ass to make — but I don’t feel like it’s that great. It’s certainly worse than “Sleet Streets”. It’s janky, exacerbated by the fact that it’s a water level. The hitboxes for the Peanutbutterfish aren’t forgiving ’nough, caused by them being blocks ’stead o’ sprites ( you can’t specify hitboxes on block types ), & trying to jump out o’ water can be hard as Autumn sometimes just doesn’t want to. I think the problem is that I didn’t connect the difficulty o’ maneuvering through the Peanutbutterfish without getting hit & the problem o’ limited time underwater. You have to be careful to avoid hitting them, but you can’t afford to spend too much time being careful or you’ll drown. Deciding to make the lifesaver platforms ( which are obviously sprites ) bob up & down also bit me back as it makes them a pain to maneuver on, as the way they affect your height & whether you end up in water ( whch heavily affects how you move & jump ) is seemingly random, e’en though the code that determines how they move isn’t based on randomness @ all. & I held back when programming them, too: I originally made it so you could nudge them horizontally, but found that that was too janky.
In short, this video took a while to get right. It doesn’t help that the temperature is in the 90s Fahrenheit. The 1st time I tried recording I got so frustrated from the heat that I tossed my MP3 player ’cross the room & had to go looking for it the next day.
In fairness, you can ignore the underwater parts with the Peanutbutterfish if you’re not going for the gem challenge. The only reason they’re there is to discourage players from just swimming under the lifesaver sections ( originally there was a “Quadrapus” in the water that would chase you, making it so that being in the water too long would hurt you; however, I found that that made the underwater secrets too hard to get as it’d box you into those pipe sections ).
The visuals was where the most effort went, & is where I feel most mixed. I was proud o’ the “Peanutbutterfish” idea. I vacilated ’tween underwater mines, which seemed too boring & plain, & jellyfish, which seemed to be ripping off Super Mario Bros. 3 when I came up with this twist. E’en though I added the glowing outline to them to show that they’re electrified, I added spikes in the hopes that it’d better show that they’re dangers, as otherwise underwater jars look like benign items ( glowing isn’t sufficient to show danger, as that same glowing effect is on the presents in “Sleet Streets”, which are good ).
The water drops & faucet irk me — not the least o’ which how cliche a danger falling drops are. ¿Why does falling water drops hurt Autumn, but not whole bodies o’ it? I tried to make the water drops look like they’re splashing, but they just look like flattening paper. I also had to enlarge the water drop sprite sheet just so the flatter sprites don’t get resized uglily due to how crappy my sprite engine is, wasting extra memory.
The faucet’s janky, too. The handle & the water stream are actually 1 sprite: the sprite is the handle itself; it just has a custom graphics function to draw the stream based on how many hits the faucet handle has. The handle flashes when hit ’cause I couldn’t figure out how to show it twisting @ its current angle. I was glad I was able to get the effect, though I still feel the ending is abrupt, e’en if I made it wait almost a second after the water turns all the way off. Then ’gain, the normal effect o’ having the game just instantly flash “¡Success!” after touching the Keycane is e’en mo’ jarring. ’Nother downside to having the faucet stream be a ghost graphic with no collision box is that I wanted to have the stream push you downward ’pon touch. I could easily do that by simply having invisible blocks there, too; but making that affected only when the faucet is on would be mo’ complicated. The whole reason I tied the faucet stream to the handle was to make tying its animation to the handle’s “HP” simpler. I guess I could just make the stream its own sprite & just give it a custom type & just have the interaction code for the faucet handle check for type & change the stream’s graphics there.
I’m torn ’tween whether I think the background is too cluttered & distracting or too barren. I ran out o’ ideas o’ what to put there & just said, “I’m done. If it desperately needs mo’ detail, I can add it later”. I kept out the darkest gray color so that the background wouldn’t take too much attention & mesh too much with the foreground; but I still feel like the tiles can get mixed up in the pipes sometimes.
I do stand by the o’erall bathtub theme, & like how it works with that palette, which I think I stole from some Donkey Kong Land game. Those games have the best palettes, as they don’t use plain white & black for the brightest & darkest colors like most Super Game Boy palettes. The faucet gimmick’s just a gimmick that’s only different from a Keycane in aesthetics, & is overtly ripped off in conception from Wario Land II. The bathtub idea was ripped off from Cool Spot, which you’ll read ’bout in a week or so.
Other programming stuff that nobody cares ’bout
I programmed in controller support — & by controller support, I mean support for my particular controller. I still haven’t gotten round to doing an options screen wherein players can choose their controls. The other bonus is that this add-on causes Valgrind to say my program has a memory leak, & I have no idea why. I know exactly what causes it: the SDL_INIT_JOYSTICK code; I just have no idea why, since I close the subsystem before the program closes. It’s not a dire problem, though, since the leak doesn’t increase in memory loss o’er time — which means it’s not much o’ a “leak”, since it only happens right before that memory’s reclaimed by the OS, anyway. The anal-retentive part o’ me doesn’t like Valgrind not showing 0s, though.
In a bout o’ designer’s block I also fiddled with the sprite & block code to make it take up less memory. I found out that the Object class that’s parent to both blocks & sprites held a rectangle object for original position, e’en though only sprites use that. ’Twas easy to move down into the Sprite class, & saved the block class 16 whole bytes. I’d make a sarcastic remark, but considering how many blocks there are in each level & how oft they’re created & deleted, that could come in handy ( ’specially since I still toy with the idea o’ having every map just load every block & keep it like that, since it’d make blocks that can move mo’ feasible ).
Since most nonprotagonist sprites don’t use HP or invincibility ( I think just the faucet handle does, ironically ) or oxygen, I cut those out & put them in a separate class for that’s just used for the player. I tried to take out what I could for water physics in general, but couldn’t take out the “in_water” flag, since that is used by other sprites, such as the big ice blocks in “Frigid Frigates”. But I did slim down the sprite class a bit, which is good, as they’re quite big, & unlike blocks, they are all loaded per map in all levels.
I also programmed in oxygen & health upgrades & refined “Soupy Sewers” so that it works well with the oxygen upgrade ( without it getting winning the gem challenge is impossible & getting the diamond requires suicide ), but still haven’t programmed any way to actually get them. I plan to add some shop in the o’erworld where you can buy them sometime.
