Flush Flood

I still don’t know when I’ll e’er be able to make “The Minus Touch”’s video, but a’least we have “Flush Flood”. Granted, I messed up a bit in editing it: @ the end it shows the gem score having been achieved, though the achievement o’ such is ne’er shown in-video. Would’ve been nice to show off, too, since it’s very hard to do. I have an inkling that I did it off-camera & didn’t want to have to try doing it ’gain.

I like the dynamic o’ this level’s difficulty: being outrun by the water doesn’t kill you itself, but if you let it get ’head too much, you’ll have no chance o’ catching up with the surface before drowning. It required a lot o’ fine-tuning to get right, & involved programming in a bit o’ rubber-banding on the water’s end. I don’t remember the exact #s, but it’s speed varies depending on its relative position to you, with a max & min so it can’t just race upward if you’re way ’head or doesn’t just stop if you’re too low.

’Cause you want to race ’head o’ the water, anyway, getting the time bonus isn’t too hard, as shown in the video. It’s getting all the gems that’s hard, since many o’ them are just slightly out o’ the way. Originally, they were all e’en mo’ out o’ the way, but I wanted to make as many o’ them as I could possible to get, while also keeping the level somewhat difficult e’en if not going for any gems, so I can’t allow the player to detour too much.

This level is where this code belongs

Curse o’ th’Ladder-Splayed Caves

Not much to say ’bout this level — other than maybe apologize for a sad pun. Like I said with “Milky Mountains”, not every level should be some wild, unique gimmick; e’en Donkey Kong Country 2 had straightforward levels like “Mudhole Marsh” & “Chain Link Chamber”. Technically, this level does have a gimmick, — maneuvering on ladders — but not 1 as big as “Value Valhalla” or “The Playing Railroad”’s, nor does it devour the entire level, as there’s also some weird train-dodging mechanic that blatantly just reuses assets from “The Playing Railroad”.

E’en then, I fiddled with the details quite a while & can still think o’ things that may warrant changing. ¿Is it the right difficulty? On 1 side, e’en the 1st spike dodging parts are somewhat tight; but this level also gives 2 hearts for such a short level. Also, the time requirement isn’t as tight as it could be: the video shows me beating it in 19 seconds out o’ the expected 25, without e’en damage boosting through the train. I’m still not sure ’bout the background: it seems to have too much distracting detail, & yet, ironically, also looks a bit plain. ( I thought ’bout adding wooden lines on it, like mines usually have, but could ne’er get them to look right ).

If anything, the most notable thing is something not directly related to this level: the fact that I increased the resolution. I did this ’cause I was sick o’ how much relative vertical space Autumn took up, making vertical movement, such as climbing up tall hills with falling dangers, such as in “Milky Mountains” & “Sleet Streets”. Now the screen’s vertical size is as much as an SNES game, which means Autumn shouldn’t take up any mo’ relative space than, say, Mario in Super Mario World ( actually, less, since she’s 8 pixels shorter than big Mario ), just much wider. I’m not sure why it took me so long to come up with this idea: I can’t imagine being ’fraid o’ some computer not being able to handle a humungous 400 x 224 resolution ( s’pecially since I already assume one’s computer has a 16:9 aspect ratio ).

Though most o’ the game automatically adjusted itself to the changed resolution simply ’cause everything referenced the same constants, some maps are jankily smaller than the screen, since many maps were made to fill up the smaller-resolution screen & no mo’, making them now have empty space with the background showing through under the ground & past a wall.

For instance, here’s how the small sewer room in the 1st level looks now:

In the main map o’ the same level, the starry background shows from ’hind the bottom o’ the skyline BG, since the skyline BG’s now too short to cover the rest o’ the screen:

Who knows when I’ll get to fixing these.

Source code is still messy & inefficient

Milky Mountains

I don’t remember if I mentioned before my decision to add a “mountain” theme to lighten “desert”’s load, but I did. This is s’posed to be the 1st mountain level, so hopefully it’s not too hard for what will the… ¿5th level? There are quite a few areas that are free, such as a few o’ the slopes & the upward slope @ the end ( it’s e’en easier if you don’t jump; I think you’re guranteed not to get hit if you just hold left ).

The most trouble I had with this level was coming up with ideas. It’s a rather plain level; but I don’t want every level to be a completely different gimmick or else the gimmick levels won’t feel fresh anymo’. Thus, this is just a normal level heading toward an end goal where most o’ the challenge is basic platforming & not getting hit by enemies. The 1 twist I allowed was having you spend most o’ the level going leftward, since I noticed most levels have you go from left to right, horizontally. Should probably add some mo’ verticality & s’pecially mo’ twisty paths. I did have an idea for a level where you start in the center & spiral out, but I’m not sure where I want to use it. Maybe “Hoot Chutes”.

There was an early version o’ this level that was e’en lamer than this. Then I came up with the chicken enemies — or rather, found a character design that seemed interesting ’nough to not make me feel as bad ’bout ripping off Koopas. I don’t remember if I said this yet, but making enemies is hard when the Super Mario Bros. games already came up with all the good ideas.

Also, I don’t show it here, but there’s a glitch I don’t know how to fix: in the hidden alcove with the gems, if you jump with Autumn’s left side slightly under the ceiling, Autumn will pop up straight through the wall to the top o’ the level. Probably caused by the code that keeps Autumn’s movement gainst walls or floor smooth by making horizontal collision detection mo’ demanding for vertical collision & vice-versa.

Bonus

I wasted a lot o’ time trying to optimize things, since this code is hilariously inefficient ( as well as cumbersome ). This time I actually profiled & found that using hash maps with strings as keys is a big waste, probably ’cause comparing strings is slow, & it’s done every frame to get the texture for every sprite, block, background, & letter o’ text. So I tried replaced this with some complicated system wherein all graphics strings are replaced with IDs, which the renderer would use to directly index an array o’ textures & the renderer would only compare strings for the creation o’ any graphic object to find which ID to give it ( either by finding an existing index o’ a texture or creating 1 if 1 didn’t already exist ).

This caused memory leaks & problems somewhere, so I scrapped it all. But I did capture some videos showing some o’ the greatest hits o’ the errors caused in the making:

I wasted e’en mo’ time playing round with refactoring the entire project into code that’s less sludgy. Not surprising, I haven’t found a way to make the sprite code less cumbersome; but I still have that other code lying round & may return to it later — ’specially if I can figure out how to get the racer sprite’s sequence o’ inputs to match up with “Rooftop Rumble” so she doesn’t fall off due to the slightest o’ differences or something.

Levels I May Work On Next:

• A farm level ( ¿in the ‘mountain’ theme set? ) that challenges you to defeat all the chicken enemy in its various forms ( this video only shows 3 forms; there’s also diagonal & circling chickens ) — think an easier version o’ the “Playing Railroad” gimmick, but without the ability to shoot.
• “Lunacy”, with a gravity mechanic, which I’ve implemented already.
• A bunch o’ other levels like “Pepperoncini Pyramid” & “Hoot Chutes” that I’ve been saying I’d work on for months.

Here’s where the messy source code is

Playing Railroad

This level was a task, & you can see why with all the fun features I decided to include. This was a case o’ my artistic side o’erriding my careful programming self ( which, now that I remember what my code looks like, doesn’t exist ). I kept insisting that I must have some feature, e’en if it meant adding mo’ weird, rare conditions to my already-bloated code. It wasn’t ’nough to have the ability to shoot while standing, ducking, & being able to shoot upward & to have various enemies that do similarly; I insisted on having the level goal be “kill all the enemies”, since I found this level to be the 1 where killing enemies was the most fun. I had planned on having this level goal since the beginning, but my original goal would be that it’d be in a 1-map level, where I could simply test if the sprite vector is empty. But this level has multiple maps, & I definitely wasn’t cutting out my swanky roof section. This left a problem: only the current map’s sprites are loaded, & they’re reloaded ’tween maps, which causes any dead sprites to respawn. So I had to create a way to keep track o’ certain sprites I didn’t want to respawn & add some extra code to delete that sprite from the map’s sprite index vector so that when it respawned sprites that sprite’s flag would no longer be there ( similar to how blocks that disappear, such as gems, work ). ’Course, since I was lazy & didn’t want to keep manually counting how many enemies are in the level in total for the level goal, I had to create an extra function that loops through every map & looks for certain sprite IDs.

You may notice that the roof section has wind ( which makes the jumps — ’specially that spring jump — much harder than they seem ). This actually didn’t require hardly any reprogramming, since I already had the wind mechanic programmed for a level I plan to make later. The only reprogramming I had to do was some hacky fix to keep the springs ( which are sprites now ) from being affected by the wind. I actually mulled o’er whether I wanted to Cowpokers up on the roof to be affected by wind, as it messed up the arrangement I meant for the rightmost area ( wherein the Cowpokers are on crates ); but then I decided that having that the wind-based version is mo’ interesting.

The rest was was aesthetics, which is always surprisingly mo’ challenging & complicated than actual gameplay… & also required reprogramming. To allow that tunnel background, I had to fiddle a lot with the background image layer class to allow for a specific # o’ BG repeats ( before ’twas either infinitely or no repeat @ all ) & had to make it so that when the background goes too far left, it wraps back to the right ( which, to be fair, also would fix an unlikely — e’en with these fast-scrolling BGs it’d take 32-bit & higher computers a’least an hour or so for the int to reach the ~ -2 billion bottom limit — bug wherein the background movement X position wraps back to the int max value ). It still feels a bit janky, though — I particularly don’t like it when the tunnel appears right when you enter a map. Ideally it’d be rarer & take a’least a few minutes in a map to appear. Also, the tunnel doesn’t appear in the boss room ’cause its small map causes the tunnel to glitch out. Technically I could just enlarge the map & limit the camera ( the reason the boss room is in a different map — though you can see a decoy that’s just for show in the 1st map — is to keep the room on-screen, as I found the boss fight too janky with the boss offscreen ), but that felt wasteful.

The best part o’ these graphics is that I oft had to heavily readjust things when I decided to change things. For instance, the inner-train BG originally was just an image with repeat-x till I decided I wanted to have gaps ’tween train cars & show past the walls. Obviously having the background tile out into the outside o’ the train made no sense, so I had to break the image up into tiles & have them be a tile background layer, with no tiles in the outside parts¹. The problem with that is that I wanted those swanky translucent windows that appear ’hind that chair, which meant I needed a 2nd tile background layer. Now I changed it so that any layers in Tiled past 2 ( the sprite layer ) gets added as a tile background layer, allowing for theoretically infinite².

The window highlights, which were far harder to do than you might think, were ’nother example where I kept going back & forth. @ 1st I made animations for the train windows & the doors, only to realize I could just have consistent highlight graphics below all the graphics as a tile background layer & just have the windows be cut out with transparency… ’cept you sometimes go ’hind the windows, & they need to be in front o’ sprites, which is impossible with background tile layers ( they’re backgrounds, after all ). But the doors & front window don’t have this problem, so I finally settled with window highlights & solid highlights that go ’hind the doors & front window. & since you ne’er go ’hind the side window on the front car with the boss room, I just had those windows be in the background tile layer & added a block with a gray triangle in the top-right corner to make that angled window.

If you’re curious how the train graphics look so you can see the sheer weight o’ the window highlight tiles:

The used windows highlights take up a whole 480 tiles, as opposed to ’bout 128 for all the rest — almost 4 times the girth.

Note that you can also see remnants o’ the ol’ door-window highlight graphics, as I ne’er got round to reclaiming that space & using it for the inside background tiles.

Actually making all these tiles was much mo’ tedious than you’d expect. Basically, I created a GIMP file with the black BG, white highlights, & a hidden layer with a solid color for the size o’ the graphic & kept going back & forth, moving the highlights up by 1 pixel & cropping to the hidden layer & saving a png for a total o’ 32 to 48 frames total for each type. Then I just copied them all into some CSS sprites app to put them all together, as seen in the graphic.

& now thinking ’bout it, it’d probably be much mo’ efficient to replace the door & front window highlights with a single graphic that’s just moved & tiled a certain way. I could e’en do that with the background image layer already programmed in, too. That’d save a whopping 288 tiles & probably a couple KB on the tile graphic.

& since I was being anal-retentive, I got round to improving graphics from eons ago. For example, you’ll notice I added shine animation to the gems, which didn’t take nearly as long as the window highlights. I also made the springs sprites so I could add animation & was surprised @ how well I was able to make them work.

The worst thing is that I can still think o’ a bunch o’ things I want to add to this level, but I felt that there had to come a time when I stopped. Part o’ me wants to add mo’ frames to the shooting animations for “cowgirl” Autumn & the Cowpokers. Also, I feel like the edges o’ the tunnel look awkward. I tried to make it look smooth with a bit o’ gradient, but it still looks clunky.

Finally, I wanted to have the train jerk up & down, like the train stages in Wario Land II do, but that’d require being able to move every block — including those in the background tile layers — up & down & would probably require having all the blocks permanent to prevent the up-&-down motion becoming janky when you scroll the camera & replace the blocks. Also, it’d probably complicate the gameplay as well as all that & would require a lot o’ testing, & basically I didn’t think ’twas worth all the effort. Maybe later. I have been puzzling ’bout making the block code mo’ efficient so I could just load them all @ once, which may be mo’ efficient that constantly regenerating them whenever the camera moves, but I’m not sure if it’s truly worth it.

Funny ’nough, I got so focused on talking ’bout graphics that I ne’er talked ’bout the difficulty o’ this level. Part o’ me feels like I might’ve gone o’erkill; on the other side, I have found that the mo’ I played this level, the easier I found it. @ 1st I thought trying to beat the level quickly was ridiculous — ’specially with the randomness o’ all the enemies’ shooting — & made the time challenge 1:50, e’en though my earlier attempts gave me a best time o’ 1:45, only to pleasantly surprise myself while recording by my ability to beat it in the 1:30s in only 3 tries ( 1 failed attempts shown on accident due to incompetent video editing ) — & that’s on a run in which I take a safety heart & make many other li’l mistakes; someone actually good @ games could probably beat this level in the 1:20s a’least. Clearly I must’ve found the difficulty fun since I kept making myself make things harder, — ’specially the boss³, who I e’en considered giving 2 mo’ hit points & for whom I did crank up the shooting frquency — since I found it mo’ exciting. In particular, I changed the boss so that it also shot low since I quickly discovered I could just duck & cheese him without the possibility o’ getting hit otherwise ( it’s still much easier to duck & shoot @ it while jumping o’er low shots, as shown in the video ). In fairness, the level does also provide plenty o’ hearts, including an infinite-use full-heal block right before the boss.

All the death pits in the upper section don’t help, ’specially with the wind. As I mentioned, some o’ the jumps are trickier than they look thanks to the wind & how it messes up Autumn’s momentum, ’specially the spring jump.

The Future

I think I might do a beach level ( a pirate level ) next.

Porcelain Dreams

As the video shows, the main gimmick is faucet handles attached to thin air ( or thin water ) that raise or lower the water to their level — a blatant ripoff from Super Mario 64.

I’ve actually been working on this level for a while. I’m sure I’ve mentioned it in earlier updates, might’ve shown screenshots, & you would’ve seen the unfinished level if you looked @ the source code or paid attention during level select screens.

The problem I’ve had with this level was that I just felt like ’twas too small, too insignificant. Originally there were no enemies & it took ’bout 15 seconds to beat. You just hit a handle to move the water up so you could jump up some place, go down, get to the end so you can raise the water higher, & then reach the goal. For a while, I did have 2 enemies round where the eels are, but they were awkward spikes that jutted out & in & were impossible to dodge consistency due to their dicey hitboxes. The eels mostly fix that — their hitboxes can be questionable, but they leave a wider gap ’tween their runs through the pipes, so you’ll probably only hit them if you’re rushing & mismeasure them by a few pixels, rather than trying to guess which milliseconds in the spikes’ second-long pattern count as harmful or not.

Actually, I should admit that the video isn’t accurate to the current version o’ the level. If you pay attention you’ll note a subtle graphical glitch: sometimes the eels go past the end o’ pipes, popping back out. I fixed that by lengthening those pipe ends, but after I’d already recorded the video & o’errode the save. It’s probably better this way, since it saves evidence for the original flaw.

The future

I’m currently working on ’nother sewer level with 2 gimmicks: being able to warp to the other side o’ the screen from the sides, like Mario Bros., & constantly-rising water that you need to keep ’head o’ to avoid drowning. I’ve also been trying to draw graphics for a train level that’ll probably be the 2nd-cycle desert level. My planned gimmick for that level would be to make Autumn be able to shoot enemies & to have a bunch o’ enemies shooting @ you, forcing you to hide ’hind crates. Just thinking ’bout all that I’ll need to finish that level, I can already tell that it’ll take a’least a month.

I had the idea to have a space world, but that would require reorganizing the map, so I don’t know. Also, transitioning from sky to space to ice may be awkward. Plus, it may not be that creative an idea.

Download lame source code

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.

Sleet Streets

¿Remember when I said I was working on a snow level full o’ slopes in my last update? This wasn’t that. When I wrote that I had 2 ideas for snow levels: a mountainous snow level full o’ slopes & tricky jumps & a city / snow level wherein you had to collect presents. @ 1st I was going to have the former be a 1st-cycle level & the latter be a 4th-cycle level; but then I decided that the city / snow level seemed like it’d be much easier, so I switched them & ended up working on “Sleet Streets” ’stead.

There’s so much to talk ’bout, I don’t e’en know where to start. I actually had to program in quite a few things for this level — the presents & the corresponding goal being the most noticeable. ’Twas also the easiest: I simply had to add a variable, a function for adding to that variable, & a function for checking the value o’ that variable to the inventory; make a block component & goal that deals with adding & checking for presents; & draw to the inventory based on it. A change you may notice is that I got rid o’ the word “OFF” that was always there, e’en though it isn’t used in any level yet. I’m changing the inventory so it’s mo’ context-based, to minimize clutter. Hardly any levels will use on / off switches ( so far none do ), so there’s no point in putting there in most o’ them. Similarly, while not shown in the video, going into a different level won’t show the presents counter; only in that goal will it show them.

The main mechanic I added was the ability to create a block background layer, which is used all o’er in this level. If the tiled map file has a 3rd layer, the game makes a MapLayer that is a list o’ blocks like the normal blocks, but they’re drawn in the background ( though ’bove all other backgrounds ) & they can’t be interacted with. This made having the buildings on the slopes much easier & allowed me to make Autumn appear ’hind the snow on the slopes but still appear in front o’ the buildings.

The other big thing I added were the snowman & large snowboulder sprites. The former are wildly predictable & can be hard to dodge — ’specially when coming back out o’ the sewers. Originally I planned to have them throw their snowballs upward, arcing back down, but then I decided that was less fun to dodge, as ’twas mo’ likely that they’d just go o’er your head, anyway. The snowmen still have no animation, though, which I probably should’ve changed ’stead o’ wasting time adding animation to some background portrait. The snowboulders are incredibly simple: they just hurt you when they touch you & are affected by gravity & blocks, which on slopes make them naturally fall down. Their graphics are also simple: just a single image that rotates based on how fast they’re moving. Their collision is buggy, though: you’re s’posed to be able to stand on them safely, but a lot o’ the time you’ll get hit anyway, probably from scraping gainst the corner o’ their hitbox while going upward. Also, if they run into you when you’re to the left o’ them, they’ll oft smash you inside the ground blocks. It’s easy to pop out, though, & it actually makes a great effect.

A minor effect: background & foreground layers can now have alpha, which was done so I could have the transparent fog in the sewer section. I have concerns that it may be too hard to see down there, though.

Most o’ my time was probably spent making the graphics, as I wanted it to look nice. The problem is there are always mo’ details I can think o’ to add. Right now I remembered that I ne’er made wall scratches to add variety to the plain flat background o’ the inside sections.

I do wonder ’bout the placement o’ this level in the 1st cycle & its difficulty. It’s not too hard, but it can be quite easy to be killed by the snowmen, the penguins in the sewer section, or the falling snowboulders. The problem with the last is that you’re going uphill & the camera doesn’t leave much padding ’tween Autumn & the top o’ the screen when pushing gainst the camera limit simply ’cause there’s not much vertical space. Thus it’s easy to get ambushed by a snowboulder. My main tactic is to hold the W button to keep pushing the camera upward as I go up, but that’s awkward & sometimes my jumps don’t jump ’cause I can’t push on that key hard ’nough with my hand sharing Z & W.

While the level isn’t that hard — probably still easier than “Cotton Candy Clouds” just before it — it is so far the longest level, which makes death mo’ frustrating, & thus makes the level feel mo’ difficult, which is what matters. My goal was that it was s’posed to be mo’ an exploratory adventure than a challenge. Many o’ the challenges in this level, such as the trick floor in the 2nd building or the tree-climbing section, are meant to be safe to fail. However, I don’t think the snowmen & the penguins fit in, ’cause they’re actually quite dangerous. On the other hand, they add something to a level I fear may be a bit too empty. This is why I added plenty o’ health, including an infinite health box ’tween the 2 snowmen. My goal was that they would act as simply a training ground. I s’pose it still isn’t much harder than “Cotton Candy Clouds”, & it is near the end o’ the 1st cycle, so may a slight rise in difficulty isn’t too bad. I myself didn’t have too much trouble in my 2 runs, but keep in mind that I’ve been testing these levels o’er & o’er & have internalized much o’ it ( & died a lot mo’ when 1st playing ). The point is I want to avoid forcing players to redo a bunch o’ stuff repeatedly ’cause o’ simple mistakes. While I expect players to die a few times in the previous levels, my goal is for players to die a lot fewer times in this level, thus making the level length not so daunting.

An obvious solution that I’m sure someone would bring up is to add a midway point. I’ve still refused to add 1 to this game, not ’cause it’d be hard ( it’d be trivial ), but ’cause my goal is to have these levels be short like Super Mario Bros. 3, which also didn’t have midway points. The problem is that in practice I don’t think I’ve succeeded in that. I actually looked through Super Mario Bros. 3 maps as I’ve done a few times for ideas & was struck by how much shorter its levels are than I remembered — & how much shorter they are than my levels. ¿How long does it take to beat an average level in Super Mario Bros. 3? I know the average time for my levels is like 30 seconds to a minute. 30 seconds was what I targeted for the average, but a think many levels go higher than that. The 1st level takes a’least 40 seconds, & mo’ likely a minute ’pon 1st playthrough; “Mart Cart Madness” takes ’bout a minute, ’less you take the shortcut, in which it takes ’bout 30 seconds; & this level takes a’least a minute, & 2-3 seconds ’pon 1st playthrough.

Then ’gain, I also plan to have far fewer levels than Super Mario Bros. 3, — I plan to have ’bout 40 levels — so perhaps having longer, in-depth levels isn’t so bad. I think the reason why my levels tend to be longer is ’cause I want to mo’ deeply explore my level gimmicks, & I just find that impossible without taking the time. Super Mario Bros. 3 level design was simpler, so there wasn’t as much a need to explore mechanics like not being seen by enemies or a mine cart that can bounce back & forth.

I’ve also oft thought ’bout how midway points might affect gem & time scores. ¿Should I save what gems they’d collected or require players to beat the challenges without dying? ¿Do I save the time they had or find some other way to keep players from death abusing to easily get a lower time score? If I do make it so that players have to beat the level without dying to get a challenge, ¿how do I keep them from accidentally getting a midway point & having to beat the level normally just for ’nother try @ a challenge? I don’t want to make the challenges a specific level mode, ’cause I like being able to beat the challenges on 1st-playthrough; making players play a level multiple times e’en though they can accomplish everything the 1st time is annoying padding, & that’s the kind o’ cancer on modern gaming that I particularly want to avoid.

Trying to add a midway point to this level would be particularly troublesome since it’d have to keep track o’ what presents you collected, which meant either doing some hardcoded nonsense with the presents ’stead o’ the current method o’ using simple blocks or save every map’s block data for each level’s checkpoint ( which I’d have to do, anyway, if I decided to save gems collected ), which might be a memory burden. I know premature optimization is the root o’ all evil, but there’s a difference ’tween making messy code just to make a small time save that’s probably not needed vs. the instinctual aversion to messy code that has a likely potential to be immensely inefficient. I have a lot o’ lenience with this game, since it’s a very low-tech game for high-tech platforms, but that still doesn’t mean I have infinite memory; & I have run into slowdown problems. This is probably ’cause I haven’t been doing much premature optimization &, quite the opposite, this project is hilariously inefficient, not the least o’ which ’cause sprites are a messy clump o’ many variables that most sprites ne’er use — but still pay for.

Perhaps as a way to make up for “Sleet Streets” not fully succeeding @ being an easy going exploratory romp, I made the gem & time challenges much easier than most other levels. In the video on my 1st runthrough you can see I easily get the gem challenge; if you go everywhere in the level & don’t miss too many gems, you’re pretty much guaranteed to get it. Meanwhile, in the 2nd run, e’en though I make a bunch o’ mistakes, I still make the time limit with a few seconds to spare, as opposed to the very 1st level, wherein you have li’l room for error. I didn’t e’en have to edit this video, unlike some o’ the previous, ’cause I was able to do the 2 runs on my 1st try.

The Future

I may either do the “Sherbet Slopes” or the next level after “Sleet Streets”, the 1st pirate level, depending on what I feel like doing or what I have ideas for. I may end up working more on a bunch o’ graphics — I have no graphics for pirate levels yet, for instance — & take a while before I finish the next level I do.

Level Themes

For those curious, here’s the level themes I have planned:

1. City
2. Forest
3. Mines
4. Desert
5. Sky
6. Ice
7. Pirate
8. Sewer
9. Factory
10. Castle / Palace
S. Special

& these are the levels I plan to have for each theme ( levels completed highlighted in red ):

Steam Engeenius

		Cycles
		1	2	3	4
Themes	City	Blueberry Burroughs	Stormy Streets		Rooftop Rumble
	Forest	Wasabi Woods*	Bough Down	Freaky Forest	Windy Woods
	Mines	Minty Mines	Curse o’ the Ladder-Splayed Caves		The Minus Touch
	Desert	Dry, Drought Desert	Desert Dare	Pepperoncini Pyramid	Cold Comfort Canyon
	Sky	Cotton Candy Clouds	Value Valhalla	Hoot Chutes	Crying Lightning
	Ice	Sleet Streets	Frigid Frigates	Ice Mines	Sherbet Slopes
	Pirate	Ship-2-Ship Islands	Banana Beach
	Sewer	Porcelain Dreams	Soupy Sewers
	Factory			Warm Up
	Castle / Palace	Donut Dungeon		Golden Gear Solid	Castle Chamsby
	Special			Mart Cart Madness	Maybe I’m a Maze

* Now with the map I have in-mind, I’ve thought ’bout renaming “Wasabi Woods”: since the o’erworld doesn’t take place where Boskeopolis is ( which makes this game’s name a hilarious misnomer ), but in some other island, it doesn’t make sense to have a forest there names the same as the forest next to Boskeopolis. I’ve thought ’bout naming it Worcestershire Woods as a reference to some dumb series o’ microfiction I made for ¡Mega Microstories!

I wanted 10 ’cause that’s a nice even number, but as everything else, I’ll probably fiddle with it o’er however long I keep this project going. In particular, I thought ’bout having a mountain world, since the “mountain” theme is important to Boskeopolis Stories ( after Boskeopolis proper & Wasabi Woods, Mustard Mountains is probably the most prominent landmark ) & it’d make a smoother transition from desert to sky; however, I’m not sure I have many ideas for mountain levels. I did think ’bout making 1 desert level — “Desert Dare”, a level I’ve already made before but still haven’t bothered to put back in — a mountain level to leave mo’ room for a train level I wanted to do.

O yeah, I also wanted to do a volcano level. No, I think I could think o’ ’nough levels for a mountain theme. So the themes & levels I just listed are already outdated.

Other themes I might want, but don’t know if I have ’nough ideas or if I want them ’nough to include them ( I don’t want too many themes ):

• Carnival / Fun House / Amusement Park / Casino ( I’m seriously thinking ’bout this 1 )
• Space
• Laboratory
• Something Halloween-themed ( like the Pumpkin world in Super Mario Land II )
• ¿Swamp? ( Probably not )
• Toyland
• Basement / Attic
• Subway

O’erworld, Part II

What I’ve accomplished since the last update:

• This isn’t totally related to the o’erworld, but as I was fooling round with my program I noticed the game would crash. I love how on the very day I bashed the hell out o’ the most beloved video game on the internet I learn that my own magnum opus is a buggy pile o’ shit — & e’en the cool bugs, like letting you reach the Spirit Temple @ the beginning while still a kid. During my long, in-depth look @ my code I found a bunch o’ memory leaks — some deep into the graphics & game engines & the sprite code. Since I would check my program in valgrind now & then, I don’t see how these managed to stay so long — how I could go so long without realizing that SDL_GetBasePath needs to be freed.

  However, I found that what caused the game to crash wasn’t related to that @ all, but the o’erworld ( which ’splains why the crashes hadn’t happened till now ). ’Twas caused by the same problem that constantly strikes me: I forgot to initialize a member o’ a class. To be specific, I forgot to initialize the gfx_ pointer in the OWTile class for tiles that aren’t the animated water tile ( & thus don’t have any animated graphics ). I’m used to unique_ptr, which automatically initializes to nullptr; but these use a raw pointer ’cause the water tiles are s’posed to passively share a unique_ptr owned by OverworldState. Thus, half the time the check for nullptr would fail, e’en though the tile has no real animated graphics, leading to wacky undefined behavior. This ’splains why sometimes the map would become corrupted in random ways, such as when Spiral Island spontaneously flooded once.

  

  &, no, don’t tell me to use shared_ptr for, well, shared pointers, as that’s pointlessly wasteful o’ precious memory & not needed if you just have a designated owner. I need to save my wasted memory on better things, like dynamically loading everything & keeping STD strings everywhere. The true lesson is to check valgrind more oft. Thankfully, I have just now & am assured that there are no memory leaks, nor have I found any random crashes. These are the problems most dire, as they can literally make a game unplayable.

• Anyway, after all that, I finally got the o’erworld & level-select screens integrated. Now the level-select is accessed through a menu screen in the o’erworld that’s suspiciously similar to the in-level pause screen, as if I just lazily copied & pasted. & now, ’stead o’ giving you a list o’ all the levels, the level-select only shows levels you’ve been to, & selecting a level takes you to that spot on the o’erworld. My inspiration for keeping the level-select as an extra menu & having it warp you to the o’erworld spot was from the GBA remake o’ Super Mario World, wherein this mechanic was immensely convenient.

• Saving & loading are now compatible with them. All the loading code was cleared out o’ the level-select state, where it wasn’t needed, & ’stead the OverworldState was given it. In addition, I added data for which levels you’ve been to & the most recent level you’ve been to, so that when you reload the game your level-select isn’t glitched out ( “?????” for already-beaten levels, for example ) & so the game places you on the level tile for the last level you’ve been to ’pon loading the game.

The Future

Someday I’ll get round to programming in that shop.

Also, I’m working on a snow level with plenty o’ slopes that’ll hopefully go well. The slope physics are still awkward, though. 1 thing I’ve realized is how odd the speed-capping works: it’s a simple speed cap wherein if you go faster than the cap, your speed is set to the cap with no gradual slow-down ’tween the speeds, & your top speed is based on whether you’re running ( holding the run button ). So if you jump forward while running & then let go o’ the run button, you’ll suddenly go much slower ’cause the halved cap brings your speed suddenly down. This in itself isn’t too bad: after all, you can turn round & move back while in the air, & that’s completely unrealistic. What made Super Mario Bros. so revolutionary was the way it threw ’way all the rules o’ real-world physics to maximize fun. But this also applies to slopes: you’re sliding or falling down a slide, how fast you go relies on whether you’re pressing the run button or not, which, I dunno, feels awkward. That’s a case wherein I think the break from reality went too far.

Also, though I haven’t felt anything jarring ’bout it, I’ve noticed that the ice physics should make everything mo’ wonky than expected. See, all ice physics do is decrease traction so that you slow mo’ slowly when stopping. But this applies to all movement, including upward & downward movement & flying enemies, like the bees that move up & down ( but not the circling bees: their movement is some custom algorithm that completely ignores the typical sprite speed & acceleration variables ).

Download sloppy source code, ¡now with 100% fewer spontaneous segmentation faults!

The O’erworld

As you can see, we already have:

• Character movement, camera adjustment, & tile collision
• Level tiles wherein if you’re colliding with them you can press A to enter the level & hold B to see the challenge scores.
• Not only are you taken back to the map after leaving a level, you are taken back to the level tile.
• Palette changes by entering certain areas.
• Tile changes that happen ’pon beating levels, opening up access to other levels.

It may seem as if it’d be smart to reuse most o’ the code I already had, but what I already have for the levels is a mess, & I didn’t want to make it any messier, so most o’ the code is redone for the o’erworld, but with all the unnecessary stuff cut out. This has the advantage o’ making the code mo’ efficient, which is useful, ’cause the whole maps’ tiles ( 25,600 ) are all loaded @ once.

What I want to do in the future

• Finish the map ’nough so that you can access all the levels, duh.
• Show a visual o’ the map changing after beating a level, ’stead o’ justing having it already have happened ’pon returning to the map.
• Add a shop somewhere where you can buy health & oxygen upgrades.
• Add a bonus level, which can also be bought.
• Possibly add the aforementioned warp zones.
• O yeah: add a menu screen that allows one to quit the game. Also, possibly add an option to switch to a list o’ levels, but only list the levels opened so far.

Download sloppy source code

Dry, Drought Desert

& this time I show off 100% o’ the level.

Not much to say ’bout this level that isn’t already shown in the video. I already showed off this “Adventure Island / Land o’ Capitalism” gimmick in a much earlier post.

Actually, the hardest part ’bout this level, designwise, was balancing the # o’ gems it gives you so that varying rankings o’ success — merely beating the level, being able to reach the diamond, getting the gem score — have a certain ’mount o’ difficulty. I tinkered with adding a gem here & taking ’way a gem there as I practiced this level & found it too hard or too easy to do certain things. This is s’posed to be a 1st-cycle level, so I want it to be easy to beat, but mo’ challenging to get the gem & time challenges. Since you’re able to make it to the goal with barely mo’ than the 1,000 needed to get the gem challenge — but much mo’ than needed to beat the level normally — hopefully I succeeded.

As I show in the video, you don’t need the secret 1,000 gems in that alcove on the wall to beeat the gem challenge. In fact, it’s probably better to not go for it, since if you don’t you’ll probably beat the time challenge in the process, whereas going to get the secret gems takes extra time. You also don’t need it to get the diamond, since that’s easier than getting the gem challenge; I just wanted to use that run as a ’scuse to show off the secret gems. That’s meant simply as a way to reward those who take the risk to explore & make beating the level e’en easier, since it is s’posed to be a 1st-cycle level.

O’erworld

Since I don’t have much to say ’bout the level, maybe I could talk ’bout this, ’stead.

I haven’t programmed anything yet, but I have done some design:

As shown, the map cycles toward the center, cycling through the level themes: city, forest, mines … factory; city, forest mines … factory. I plan so far is that when you beat a level some event happens that allow you to proceed to the next — the most common being some solid tiles turning nonsolid.

There are still a few questions & problems I need to puzzle out. For 1, there’s the need to balance space: as the cycle goes farther in, the amount o’ space shrinks. That requires me to balance the inner cycle so it’s not too crowded gainst the outer cycle so it’s not too open. Already I think I’m having trouble with this since e’en with all the padding space used in the outermost cycle, I don’t think the city, forest, & mines sections go far ’nough. ( Remember, in all the levels in the 1st cycle must encompass the whole o’ the outer ring, since that’s where it transitions to the 2nd cycle. )

I’m still not sure if I want the level layout to be linear level-to-level. It seems ol’ fashioned & o’erly limited; but @ the same time, I do want to have some progression. 1 idea I had was to have “warp zones” in the form o’ secret exits in some levels that create paths farther down into the cycle.

Download sloppy source code