I Can Go with the Flow

Here’s a level I’ve been working on for a while. It’s actually a level I apparently wanted so much ’twas the primary inspiration to add the rather recent “swamp” theme to this game ( well, that & my desire to use this level’s music ). This level’s main gimmick is also 1 o’ the many I ripped off from the Wario Land games, but with this game’s oxygen mechanic & the need to aim for bubbles to keep Autumn from drowning as an extra challenge.

The reason this level took so long to finish that 2 other swamp levels were finished before it was simply that I had many 2nd thoughts ’bout this level. ¿Is it truly fun or just annoying? The current mechanic doesn’t work as well with Boskeopolis Land’s Mario-style swimming as Wario Land’s, where you’re actually swimming without gravity constantly dragging you downward, rather than constantly bopping upward in water, as in this game. I also wasn’t sure if the direction the currents are going are easy ’nough to see & whether the path to the end isn’t too obscure. As a developer it’s always important to keep in mind that actually playing a map, where the camera is only showing narrow pieces o’ the map round you @ a time rather than showing the whole map in its entirety before you, is harder than navigating in a map program. While playing the level I was surprised by how much I myself got lost in the maze.

On the other hand, the level is easygoing, with no enemies in the river itself to worry ’bout. I debated adding enemies, but figured the player doesn’t have ’nough control in the currents to make that fair & figured ’twas better to err on being a bit too easy & fair being preferable to frustrating cheap deaths. As a compromise & a way to give the level mo’ variety, I added sections @ the beginning & end with the hopping frog enemies from the 1st swamp level. Anyway, this is only a 2nd-cycle level, so it shouldn’t be that hard, anyway, & I think the threat o’ drowning is ’nough. I also added a small loop o’ currents going down & up ( but ultimately still linear ) round an otherwise unpassable wall @ the top as a tiny unspoken tutorial before immediately throwing the player into the big maze. This expanded the level a bit without making it too long: if one doesn’t make any wrong turns in the main maze, it’ll take the player ’bout 20 seconds. This is ’cause the big maze isn’t all that big, which I consider a +, since a gimmick like this with the risk o’ becoming annoying should err on the side o’ not o’erstaying its welcome.

’Cause the current physics are somewhat janky, I made the time & gem scores somewhat lenient. The time score offers plenty o’ time so long as you don’t take any wrong turns @ all, which is a fair challenge in itself. While the gem score is 1 o’ the highest score requirements in the game so far, @ 40,000₧, there are gems all ’long the current tunnels ( which I just now realized has the advantage o’ showing players paths they’d already taken ). I avoided having hidden tunnels in walls with gems & kept collectibles, like the collectible card, to some branching paths near the bottom middle o’ the level, which are tricky to get to, or in side cliffs in the out-o’-water sections, as expecting players to just ram gainst every wall while struggling thru currents would just be annoying, neither challenging nor fun.

As an arguably irrelevant addendum, to help me create the o’erworld events shown when beating this level ( as well as the previous level’s event, so the level isn’t just floating on water & inaccessible ), since ’twas getting tedious @ this point, I crapped together a quick JavaScript script to generate the event files from specially made Tiled map files. This will be specially useful, since I plan to heavily redesign the o’erworld map ( which means all o’ the events I’ve already made will have to be remade ), not the least ’cause I’ve thought o’ yet ’nother new theme I may add…

This video almost kept in a serious graphical error, like almost all my previous videos, in which 1 o’ the currents was missing most o’ the moving current tile graphics. Howe’er, this was so jarring & this video was relatively quick to record that this time I went thru the whole trouble o’ rerecording & reuploading to YouTube ( yes, it took that long to find, e’en tho I watched the video before uploading ). Howe’er, there is still ’nother bug shown in the video that I still haven’t fixed: you can clearly see the toad enemies hop thru the player from ’neath, hurting them rather than getting bonked. I think this only happens during a high hop, caused presumably by them moving so quickly upward that they pass the bonk collision threshold within a single frame, causing the player to get hurt ’stead.

Learn mo’ ’bout Boskeopolis Land @ https://www.boskeopolis-land.com/.

Read this code as tortuous as this level’s currents.

Cometropolis

This level started with just the idea o’ a neon palette, the implementation o’ which probably did take the bulk o’ the time I spent on this level. The “palette changes” as they seem to be in the actual game use completely different coding, bending this game’s flimsy ’scuse for a palette system e’en farther. Unlike ol’ consoles & computers, wherein changing palettes was much quicker than changing tiles that many ol’ games would cycle palettes to create the illusion o’ animation, changing the palette in this game requires regenerating textures, which is much slower than just animating tiles. Theoretically it’d be possible to do it rather quickly using shaders; howe’er, SDL doesn’t allow shaders, & it’s much too late in development to switch o’er to the much mo’ complex & much less intuitive OpenGL. What I did do to create the illusion o’ a cycling palette is take advantage o’ 2 caveats to this problem: 1. I can render a rectangle o’ any color that covers the whole screen in no time; 2. SDL allows me to apply the equivalent to Photoshop’s “multiply” blending mode to textures, which, when used with a white & black image makes whate’er is ’hind show through the white while still concealing what’s ’hind the black.¹ Thus, I just set whate’er palette entries I want to show the shifting rainbow color ( which are dark gray & black ) to white while everything else is black.

I had originally planned to use the city theme for this palette, since I felt the city would look nice in neon, but since I had all 4 city slots filled, I ’stead considered making a space level, since that theme has the fewest slots filled & it would fit there, too. I think I played with the idea o’ focusing on dodging horizontally-moving sparks on wire or something; howe’er, none o’ this felt fun, so I shelved it for a while. I don’t remember where my mind went from there, but as some point I came up with the idea o’ dodging falling stars, — probably from the 1 memorable level from New Super Mario Bros., the 1 wherein lava rocks fall from the sky — & then decided to move “Sleet Streets” to the “domestic” theme ( since it’s mo’ ’bout homes than the city ) & make this a city level. Then, finally, I decided to make this a space level ’gain, despite keeping the city graphics, & would just say this was a city on ’nother planet. It’s not as if I haven’t been blending themes together & sticking them into whate’er slot was most convenient, & if any theme deserved to dip into other themes’ slots, it would be the city theme.

The falling stars are just a bit mo’ complicated than just randomly placing them round. To ensure the player could not outrun stars in either direction & that there was a steady supply, I made it so that every time it generated a falling star it not only placed it on the current screen, but also on the next & previous. & to decrease the chance so’ stars congregating in 1 area I made it so that it had to spawn the next star a few blocks ’way from where the last spawned.

Recording the time & gem scores were surprisingly smoothly. I made the time score somewhat lenient to make up for the delays falling stars can sometimes force on the player when they form walls. E’en then, I still couldn’t help myself from just running thru stars when I knew a heart was close ’head, which I try not to do, since I want these challenges to be possible without taking any hits. Shockingly, I was able to record the gem score on my 1st try, which I always found very hard to get during practice. Then ’gain, here you can see me moving as carefully as I can. I should point out that this will definitely replace “Stop & Go Space Station” as the 4th-cycle space level, pushing “Stop & Go Space Station” down to the 3rd cycle, as it is much mo’ difficult.

Learn mo’ ’bout this project @ boskeopolis-land.com.

“I will multiply thy bugs as the stars o’ the heaven…”.

Don’t Touch Me, I’m a Real Live Wire

This level’s main gimmick, electric walls that could only be deactivated with switches in ’nother area, forcing the player to race from the switch to the electric walls, was originally going to be a space level, but I felt it would be better to use this mechanic to spice up an attic maze level idea I’d been toying with, since I feel exploring a maze just to find a keycane or collect a certain # o’ gems had already been done ’nough in this game. This gimmick also helps set this level apart from the attic levels in Cool Spot whence this level takes perhaps a bit too much inspiration otherwise.

I’m mixed on the size o’ this level. I insisted on constructing the maze so that all space is used for something, with no large chunks o’ solid wood ( which the Cool Spot levels also do ). While I feel like I did a rather good job o’ that, I do worry that the level might be too big. Then ’gain, a maze needs to be large ’nough to get lost in & have plenty o’ dead ends to offer any challenge, & players who know their way will be able to beat the level within less than a minute. Still, part o’ me can’t help feeling like some pieces — specially the lower left section — feel like filler that exists just to collect gems.

I like the proportions ’tween the pre-1st-wall & after-1st-wall sections, with the early section being much smaller & having fewer dead ends, acting as a subtle training wheels before the boost in trickiness for the 2nd half. This 2nd half immediately starts with 1-way sections down. If you fail to make it to the 2nd electric wall before the switch runs out, you have to go up a longer path round where you went do to fall back down to where the switches are.

If you’re wondering why there’s switch blocks right after the 1st electric wall with switches on either side, this was just a way to force players to reset the switch after the 1st electric wall. E’en with the warning telling you outright that the switches are timed, I can imagine players rushing & forgetting to reset the switch on their own, which will almost guarantee that the switch, which would be getting low just after passing the 1st electric wall, would turn off long before the player gets close to the 2nd electric wall, which felt too much like a frustrating gotcha to let stand.

The time score is so easy I was able to do it 1st try when recording. I intentionally made it less demanding, since players needed to remember the path they needed to take & ne’er take wrong turns to have a chance to make it in time. The gem score was much harder for me & required an embarrassing # o’ tries. As the video shows, this level has the largest gem score o’ any level so far, requiring 40,000₧, which is 400 individual gems. If you pay close attention to the video, you’ll see that there are many gems hidden ’hind the foreground pipes ( 1 o’ the many elements I ripped off from Cool Spot’s attic levels ). Howe’er, there are so many gems in this level, I doubt you need to collect any. I didn’t go too out o’ my way to collect them & e’en flub up collecting the large star formation o’ gems in the top area, falling down a 1-way area before collecting most o’ them. Howe’er, by that point I’d already reached the required 40,000₧.

I was planning on having this released in September, but was delayed by major programming renovations. Graphical layering glitches in this level, specially when someone dies, was the last straw for this game’s unbelievably naïve layering system inspired by Super Mario World under the mistaken belief that code aimed for a 90s game console would work well for modern computer architectures. This scheme used dumb boolean flags on all blocks & sprites & looping o’er all blocks & sprites twice ’tween map backgrounds & foregrounds, 1st blocks & then sprites without priority, & then blocks & then sprites with priority. To draw sprites ’bove the foreground, I resorted to some hacky virtual function that did nothing for the vast majority o’ sprites.

I completely o’erhauled all this, removing all traces o’ “priority” flags. I replaced this with 17¹ layers o’ lists o’ generic renderable objects, which can render blocks, sprites, or map layers, which are simply all looped o’er every frame. This allows blocks, sprites, & map layers to be on any layer & to be easily moved to any other layer.

To better fit this new mo’ generic system, I also o’erhauled how maps & level files are read: explicit “backgrounds” & “foregrounds” are replaced with generic “layers”, which can be set on any o’ the 17 layers ( tho to make it convenient for me, they default to the default “background” layer & their “layer” can be set to “foreground”, which will put it on the default “foreground” layer ). I also changed the map tile layers to use generic types like “Blocks”, “Texture”, “BlocksTexture”, “Tiles”, & “Fade”, followed by a # that represents which layer it should go on or the strings “BG”, “BG1”, “BG2”, “FG”, “FG1”, “FG2” to simply put it into those default layers so I don’t have to remember their #s. I also changed it so that the BlocksSystem has multiple blocks lists to accommodate this mo’ generic scheme. Since the priority flag is completely ignored now, blocks that should be drawn ’bove the player should be put on a 2nd “Blocks” layer set to “FG”. This new scheme also allows for mo’ opportunities for rendering optimizations. For instance, both block & tile layers ( tile layers are drawn but cannot be interacted with ) can be made textures, wherein they are all combined into a single texture, simplifying them into a single draw call @ the cost o’ not being able to be animated or affected by level events.

There are also some subtler changes I made. For instance, I fixed a glitch that may have seeped into earlier videos wherein the “GAME START” text on the title screen would randomly spread onto 1 or 2 lines. ’Ventually I found out this was caused by a mistake in the look-’head code for the autoline code that would read 1 character beyond the end o’ the list o’ characters, which would be random data. In hindsight, the fact that this clearly involved randomness should’ve clued me in that there was garbage data being read; for some reason, I was stuck for a while on the hypothesis o’ a rounding error in some division or float-to-int conversion. The fact that this only e’er seemed to affect the “GAME START” text & ne’er caused segmentation faults, despite this error technically occurring everywhere there is text, astounds me.

A mo’ noticeable change is that the diamond has been replaced by a spinning card ( I think I also fixed a bug that would cause already-collected cards to still appear when re-entering a level & would only disappear if the player went near them due to optimizations in the block-collision code ), which was a change I had planned for a while, but for some reason had trouble getting the animation right before. Someday I plan on implementing a way to view each level’s card from the o’erworld menu.

Learn mo’ ’bout Boskeopolis Land @ boskeopolis-land.com

Look @ this project’s eldritch code

I Wanna Be Your Vacuum Cleaner

Accompanying music

I’d been toying with the idea o’ a “race ’head o’ the screen” type level ( distinguished from typical autoscroll levels by the ability to go as quickly ’head as you want, rather than locking you back & forcing you to wait, which I hate ) since near the beginning o’ this project. As that article shows, the original idea was a basic saw. Howe’er, not only is that idea cliché, ’twould also use a factory level, & I already have all 4 o’ that theme’s slots filled, while the new domestic theme has plenty o’ slots to fill.

Having decided this, I for some reason came up with the idea o’ a giant cat chasing you, but then realized that that would be far too difficult to animate, so I changed it to a vacuum, which I could just slide forward without any animation. & ’cause I was extra lazy & too unskilled an artist to draw a tolerable vacuum, I just used a photo o’ my vacuum. I actually like how it looks in all its sloppiness: it’s like the indie video game version o’ a B-movie monster — a B-video-game monster.

Ironically, I would then waste far too much time drawing & tinkering with all the other graphics, including the spinning fan, which the player will barely see, since they’re racing past it just to survive.

Beyond that, the trickiest task was pacing out the level. As I try to show in the video, I paced out the level just so that the player wouldn’t have to e’er stop, which is a philosophy I like to take with level design, inspired by Donkey Kong Country 2. That’s tricky to follow for this level, as the main challenge is s’posed to be holding the player back so they’re @ risk o’ being devoured by the vacuum. When I 1st designed the level, I designed it just like that, with jumps & falls tightly packed in horizontally so that the player couldn’t help but bonk into walls if they didn’t stop. Feeling that that was just annoying, I spread them out a bit, so that it’s possible to not bonk into walls while going straight forward, but in some cases ( such as the staircase midway thru the level ), it requires tight jumping, as there’s li’l space.

Part o’ me still worried that some parts may be unfair for those who aren’t familiar with the level, such as the optimal pattern o’ running under the 1st bouncing ball, jumping o’er the 2nd ball, & then holding the jump button just long ’nough that you can reach the top o’ the block just after & run under the 3rd bouncing ball. On the other hand, I didn’t originally design this setup this way, I just figured it out as I played this o’er 100 times in the process o’ testing & developing it, & I wouldn’t be surprised if a speedrunner could find a better way to beat the score. Indeed, tho this video shows 32 as the score requirement, I lowered it to 30 afterward, as it seems you’re almost guaranteed to get 32 if you’re not intentionally lagging ’hind. & yet I’m just as worried that this level may be too trivial to beat normally. It’s very rare that the vacuum has e’er been able to catch up to me when not intentionally letting it or going for the diamond. This & the fact that the attic level I’m working on may prove to be too complex for the 2nd level o’ the game, I may move this level down to the 1st cycle, rather than the 2nd cycle it’s in now.

I also feel like the diamond isn’t in the most creative place. Howe’er, I wanted to keep the whole level within the screen vertically, so that left nowhere to hide the diamond, other than past the keycane, which is a trick I already used for “Brier Flier”. Anyway, the ease o’ finding the diamond is balanced by how hard it is to grab it without the vacuum catching up to the player — tho this is balanced back by the fact that you don’t have to beat the level to keep the diamond, so you can just grab the diamond & let yourself die. Unfortunately, by balancing the vacuum’s speed to allow you just ’nough time to grab the diamond, this makes it easy to reach just the keycane before the vacuum catches up, as stated earlier. But maybe this all works better if I go ’head with making this the 2nd level.

Read this source code that should be vacuumed up
Learn mo’ ’bout this project @ boskeopolis-land.com

Cascade Parade

I particularly liked this level’s gimmick o’ log platforms moving leftward o’er deathly water & the player needing to hop from platform to platform rightward gainst the tide. Tho I can’t imagine a gimmick similar to this has ne’er been done before, it’s rare ’nough to feel fresh, & yet also feels nature, simple, & integrates with the game’s core gameplay well. I’ve been conscious o’ the risk o’ breaking too far out from this game’s core gameplay with level gimmicks, which can be mo’ alienating than interesting, specially if the gimmick isn’t truly original, just different. ( This is why I canceled a shmup level I was working on. )

The way the logs are programmed isn’t how they seem. The normal way one would expect, with each log being its own sprite & a log-spawner sprite @ the end, would not only create a lot o’ sprites, but since these sprites need to always be in-sync with each other, they have to always be updating & always have to move vertically when they should, which, if they did so by interracting with the water tiles, would require the whole map to be running & interactive. All o’ this seemed like it might go slowly, so ’stead I had all the logs be 1 sprite with 4 or 5 rectangles for drawing the logs & hit detection, which are updated based on the sprite’s x position, which constantly moves left, & the camera position. While this is much mo’ efficient, the downside is that it makes making the logs interactive with the water not work… so I just cheesed it manually programmed their vertical positions in their update code, based on their x positions. The downside to this is that in order to change the map layout, one has to reprogram the sprite code; but the upside is that I didn’t have to add extra code to the water blocks to make the logs interact with them differently & made it simpler to make the logs halfway into the water blocks.

Due to the difference o’ going rightward gainst-stream & leftward downstream, I couldn’t resist applying Wario Land 4 style “folded design”; granted, the way back is easier, ’less the player insists on jumping from log-to-log backward to save time for the time score, which can be e’en harder than going rightward.

’Twas tricky trying to get the difficulty & length right, & I’m still not sure if I shouldn’t have added some space after & ’tween the 2 poorly-drawn dragonflies. Just jumping from platform to platform by itself is surprisingly tricky to get used to, specially when going up waterfalls, so I made the 1st area just platform jumping, followed by a waterfall, before gradually introducing extra obstacles like walls, dragonflies, & axe-throwers.

1 thing I’d thought o’ doing with this level was having a hidden alcove, perhaps where the diamond would be, ’hind the final waterfall @ the end. There were 2 reasons I nixed this idea. 1, I thought it unfairly broke the rules this level set out: the level goal message clearly states that the water is deadly & you should ne’er touch it. The 2nd, mo’ important reason, is that jumping from log to log with waterfall in front o’ you making it impossible to see would be effectively luck-based. I guess I could’ve put solid ground where the waterfall is — perhaps e’en have a piece o’ ground jutting out from both sides as an extra hint that there’s something there — & just ignore the fact that logs are magically going through ground. But I already found a cleverer, less cliché hiding place for the diamond ’bove the wooden cage holding the axe-throwers.

Graphically, this level was me @ my weakest. I’ve already mentioned my failure @ animating the dragonflies — to the point that I should’ve just used the Pollos ’stead. We also have yet ’nother background that’s just a photo saved with a limit palette & dithering without e’en making the background tile horizontally, so I had to just make it lay stationary where’er you scroll. I had worked on a custom-drawn rocky cliff background with waterfalls, but it was looking much worse than this for the effort ’twas taking me to draw it, so I nixed it. Perhaps ’ventually I’ll improve the graphics in this level, but for now I need to move on so I’m not still making this game when I’m in my 40s.

Learn mo’ ’bout Boskeopolis Land @ https://www.boskeopolis-land.com.

Look @ its sloppy source code @ https://github.com/jjwmezun/boskeopolis-land.

I didn’t finally give up on this immense waste o’ time ( though a sane person would’ve years ago ); I’ve just been implementing a bunch o’ things — all @ once ’cause implementing 1 form tore apart the code in other parts, so that the game was in a broken form till I finished most o’ it.

We have a lot to go o’er…

New Title Screen

As the video shows @ the beginning, the basic animation I had before has been replaced by a “trainer” like @ the beginning o’ Super Mario World. I don’t know why I didn’t think to do this till now, since the ol’ animation I had was rather generic & I clearly had autoplaying on my mind way back when I made “Rooftop Rumble”. Maybe I just hadn’t had the confidence yet.

Codewise, the TitleState instance just includes an instance o’ LevelState, but uses a slightly different update function & has a camera with different dimensions. The player character uses the same input component “Dagny” does in “Rooftop Rumble”. In the code as it stands now, the title screen randomly cycles through “Blueberry Burroughs”, “Wasabi Woods”, “The Amazon Jungle”, & “Rooftop Rumble” — though for this video I hacked the code so that it showed the same levels in the exact sequence I wanted so I could show off multiple without the risk o’ repeats.

’Cause I actually quite liked the building animations, I kept them in a shortened form @ the top o’ the screen ’hind the title. The curtains, which are flagrantly inspired by Super Mario Bros. 3 ( though they look mo’ like the curtains in Super Mario Bros. 2 USA ) I already drew for “Play in the Background”.

I probably spent mo’ time trying to record good-looking movement for each level. I didn’t spend ’nough time on “Blueberry Burroughs”, which is why it’s good that I skip it in this video. ¡But look @ that movement in “Wasabi Woods”! ¡That’s some dancing there! Actually, if you compare this to an earlier video you’ll see that I edited the level a bit, making it easier ( I always thought ’twas way too hard for the 3rd level o’ the game — still do, actually ) & making it so that you can play through the level without stopping, as shown in this video.

For those wondering who “Nasrin” is & why I’ve been stealing credit for their hard work till now, it’s referential humor that won’t make much sense now, since none o’ the relevant stories have e’en been published yet. Nasrin is a character who is a programmer & learns “programmagic” in some stories & also plays an authorial role in some stories. This is also a pun off the “Programmed by Nasir” message found in Final Fantasy & other Square games Nasir Gebelli worked on. The immense similarity ’tween their names & professions was too good to pass up, e’en if the joke will only make sense to anyone who doesn’t read this explanation decades from now.

Localization

When adding Muertoween-themed messages to that stupid marquee @ the bottom o’ the screen for “Mind Your Manors”, I discovered how limited my then implementation o’ text was. It just used basic C++ strings as basic arrays, which is… wrong. Calling bytes “chars” is 1 o’ the many lies C & C++ tell you.

Actually, to truly handle all kinds o’ unicode characters well you need a full-fledged character library; but that library probably wouldn’t work with the way I handle drawing characters, so I stuck with the next simplest solution: using u32strings. Using fixed-sized UTF-32 characters is simpler & probably mo’ efficient than using variable-sized UTF-8 characters as I can just worry ’bout converting from UTF-8 to UTF-32 once & then treat the new string as a basic array ’gain. On modern computers using mo’ memory to save running complicated conversion code code repeatedly is probably faster, ’specially since on most computers UTF-32 characters would be the size o’ a basic word. But I would still prefer it e’en if ’twere slower.

I’m quite sure the new text format still has flaws. While it can handle multiple character frames for a single character, such as used for “…”, it can’t handle combining characters, so Arabic translation would be problematic. Also, characters are pretty much hard-coded to being 8×8 pixels ( technically, I could change 1 constant to change that size for the WTextObj class; but many places where spacing has to be managed precisely would basically break if the character size changed; & since many screens try to squeeze as many characters as they can, I don’t e’en know how I could fit larger characters ). In order to implement Japanese, as shown in this video, I replaced most kanji with hiragana ( as many ol’ Japanese games did to save memory ), which is simpler. But I have no idea how one would implement the complex characters o’, say, Chinese, which have no simpler characters to fall back on, in only 8×8 pixels. But if you want to play the game in French, Japanese, or Russian, you’re golden… so long as you find someone to make the translations, as mine rely heavily on Google Translate & are probably as good as the English found in Ghost ’n Goblins. Also, none o’ the localizations are finished, since this simple platformer has a lot mo’ text than I would’ve imagined ( & it still doesn’t include error text yet ).

As I was implementing this, I cut out all text that is localized into separate JSON files, 1 for each language, & load the text from here. Changing the language changes what loaded text to use. To make a localization, one only needs to copy ’nother localization file & replace all the values with different values. If that language uses a different character set, just make a new image, put it in assets/img/charset ( & make sure it’s an indexed png with a’least 7 colors or 6 colors & transparency ), & put that filename into charset->image o’ the JSON file.

There are still many limits, though. As mentioned, some screens have limited space, which works for the English translation, but may not be ’nough space for some translations. Since starting this I have tried to make spacing dynamic to the text if I can or leave extra space just in case. Also, setting key bindings & typing filenames ( which will be relevant in the next section ) still use only basic alphabet letters.

I completely rewrote the code used for drawing text to the screen so that it’s much simpler & much mo’ dynamic. Rather than running half-hearted but complex code every time it drew text, the new version runs complex code @ the start to generate a simple list o’ lines, which each hold a simple list o’ character frames with character coordinates & position. This makes handling centering or right-aligning or changing specific characters in text much simpler. Now gradually appearing text doesn’t need to embed itself in the code that generates the frames but can just work on the frames afterward.

In addition to the centering & autoformatting in the ol’ text code, WTextObj instances can now have autopadding, which only applies if there is extra space. This makes working with text that may spill into multiple lines in other languages simpler. For instance, as the video shows, when “Empieza el juego” spills out into 2 lines, it still fits in the box, just with less padding ’tween lines.

Save Files

For the longest time I knew allowing only 1 save would be embarrassingly lame & that no serious video game made in the 21st century would have such a ridiculous limit¹, but I was ne’er quite sure how I wanted to implement it. I also knew that I didn’t want to limit the player to only 3 or 4 saves, either; the player should be able to have as many saves as their hard drive can hold.

The way most computer games would handle multiple saves would be to have the player directly save a file to their hard drive & directly load it from the computer. Howe’er, including window system interaction in my game would heavily complicate my game’s ability to be crossplatform. The main platform I work on, Linux, doesn’t e’en have a single window system, but probably hundreds.

Finally, I compromised by allowing the player to create any # o’ files ( so long as they have the space for that extra 800 bytes ) by selecting the “New Game” box @ the bottom & having all files ’bove it. Each save file needs to be given a unique name. The player can also copy & delete saves ( when you copy a save, you have to give the copy a new name, which defaults to “[original name] copy”.

Technically, this system isn’t finished. While it all works well in terms o’ pure behavior, I haven’t implemented any scrolling, so if you have too many saves, they go past the bottom o’ the screen, hiding the “New Game” box & crowding into the options boxes.

I also implemented a basic backup system: whene’er you save it also creates a copy o’ that file with the “bak” extension. When loading, if the game e’er finds a save file missing or corrupted, it tries to replace it with the backup.

Hilariously, I figured out a way to simplify saving to a file as simple as a 1-liner. All this time I’ve been using some long code that manually plugs values into an external file. Now I realized I could just memcpy the save file’s data directly to & from the external file & it works just the same.

New O’erworld

I basically reprogrammed the o’erworld, as the ol’ version was hard to change & was sluggish. I have since learned that drawing hundreds o’ small tiles every frame is much slower than generating a few textures every rare update & drawing those few textures every frame, so I do that ’stead. Since terrain collision is just solid or not solid, it’s just a list o’ booleans for every tile & uses your position & some simply math to index into that list.

I completely revamped the event system, which I made way back when I 1st made the o’erworld, but ne’er used ’cause ’twas too clunky to edit. Now, like almost everything else in the game, it’s all separated out into JSON files. Furthermo’, now ’stead o’ just silently changing the map, we have a cutscene that moves to a chosen tile & starts changing tiles frame by frame.

Just a few days ago I decided to add a frame round the o’erworld — ’nother idea I stole from Super Mario Bros. 3.

In addition to normal level tiles, we have a new tile type…

Shop

I’ve been planning to implement this for years. I knew that if I gave the player tons o’ money, they would need somewhere to spend it.

This is 1 o’ those things that took way mo’ time to design than program. In terms o’ programming, it’s just a list o’ objects that set inventory values when you buy them. Howe’er, figuring out how to fit all o’ the info well into a single low-resolution screen was tricky. Luckily, my day job is web development & design, so I’m used to it².

Speaking o’ web development, I made the shop work mo’ like an online shop ( & real shops ) wherein you select the items you want to buy, & then pay & get them all @ once when you select checkout. This admittedly made designing the screen harder, as it forced me to include a “Checkout” box, a box for shopping what products you have in your cart, & total price @ the top right. But it saves the player having to go through confirmation & “Thank you” boxes for every product.

I’d be happy if you could ignore the fact that the store is much bigger than Autumn — so that either Autumn has been shrunk to the size o’ a mouse or the store was made for giants.

Currently, there is only 1 shop that sells just an “Extra Aorta”, which increases the player’s max health by 1 hit on normal difficulty; an “Iron Lung”, which increases the amount o’ time you can spend underwater; & the 1st cycle’s bonus level, “Play in the Background”. As the video shows, beating it doesn’t unlock anything other than 100% ( which will be necessary to unlock something special ). All o’ these I have been planning for years. I ’ventually plan to implement a’least 2 mo’ shops later in the o’erworld, as well as the other 3 cycles’ bonus levels. I also thought ’bout implementing alternate costumes, characters ( making Edgar & Dawn playable ), & a way to unlock normal levels without beating the level before them ( essentially level skips without actually giving you credit for beating those levels ).

New Level Select

It looks nicer & is divided by cycle now.

New Levels

The video foreshadows 2 levels I’m working on: an attic level & a bayou level. I sort o’ worked on these in the midst o’ working on the other stuff, so I couldn’t show them off beforehand. Anyway, neither is totally done — though “Bayou Jupiter” is almost.

Ol’ Levels

If you compare some o’ the levels shown in the video to their originals, you’ll noticed I updated them a bit, usually to spruce up their graphics, but also sometimes to better balance their difficulty.

The most changed level is “Minty Mines”, which has now been renamed “Blind Mice Mines” & replaced its minty green with teal. I felt having a green level right after ’nother green level would be too repetitive.

While I technically redesigned the level from the ground up, I kept most o’ the general theme: go right, then down, then left, get a key, & loop back to the beginning o’ the level to open the chest. The diamond is still locked ’hind a locked box a li’l before you get the key, forcing a bit o’ backtracking. I just cut out some o’ the awkward challenges, like the spikes on the stairs downward, which are hard to see, while adding mo’ basic jumps & falling spikes that fall too slowly to e’er hit you.

The main changes were the darkness gimmick & the secret exit. The darkness gimmick was something I implemented a long time ago for an aborted level — though I had to hack the rendering functions to allow the light switches & spikes to still be bright ’bove the darkness. I aborted the other level ’cause I felt “make the level hard to see” was unfair & not fun. But then inspiration struck: ¿what if I implement darkness on an early-game level & just not make it challenging? A level can’t be unfair if there’s hardly any risk o’ death. But the darkness & light switches do spruce up what was otherwise a boringly easy level. Early-game levels are always hard to make exciting without the ability to make them actually challenging. Darkness without real threats is a good way to fake it where it can’t truly exist.

Secret exits were something I’ve been wanting to implement for a long time. I always felt that with this game’s level sequence spiraling back round to the same areas repeatedly, secret exits that opened up paths to skip a cycle — as warp zones, effectively — would fit perfectly.

I already mentioned “Wasabi Woods”, but “Cotton Candy Clouds” was also made much easier. Since “Value Valhalla” was easier than this level, I almost switched them; but I wanted to keep the other “collect x # o’ gems” level farther from the 1st & felt like it’d be much mo’ interesting if I make the “Value Valhalla” level harder & the “Cotton Candy Clouds” level with its far less inspired gimmick ( stolen from Wario Land 3, ’course ) easier. I shortened the level by cutting out the weakest parts & added much mo’ space to the area under the brambles where you collect the diamond. The staircases where you go down & up while avoiding Pufferbees were awkward with the camera, & the 1st iteration, going down, was way harder than the ending iteration going upward. The final challenge pushing you to jump up 3 fading platforms @ once is far mo’ relevant to the gimmick. But to keep from the gimmick o’erpowering the level ( a typical rookie mistake & a commonly cited reason for why many people prefer Donkey Kong Country 2 o’er Donkey Kong Country 3), I added a section where you have to jump up thin platform without hitting the Pufferbee moving left & right & then jump out o’ the way before the Pufferbee comes back. This is much mo’ manageable for players still getting acclimated to the game.

I also spruced up the level’s graphics, taking advantage o’ the background & foreground layers that I hadn’t implemented yet when I 1st designed the level to eliminate cutoff, such as with the ladders gainst the cloud fringes. Most notably, I replaced the big cartoony brambles with the simpler bramble tiles found in “Brier Flier”. This was a hard decision to make, as I felt the older graphics were mo’ visually appealing & made it less obvious that the they were a grid o’ tiles. On the other hand… they made it less obvious that they were a grid o’ tiles, & thus harder to tell what parts were harmful & which not. I decided that keeping gameplay solid was mo’ important than visuals.

I moved “Chillblain Lake” to the 1st cycle, swapping with “Ice Box Rock”, which is now in the 2nd cycle. I debated this change, ’long with the “Cotton Candy Clouds” / “Value Valhalla” switch, but this time I went through with it. I still have qualms with having ’nother key & chest level so soon after “Blind Mice Mines” — to the point that I almsot considered making “Blind Mice Mines” have just a regular keycane goal if I didn’t think exploring the dark level for the key was an important part o’ that level’s challenge. Howe’er, I feel dodging the spiky olives in “Ice Box Rock” was far harder than anything in “Chillblain Lake”, & I feel making that challenge easier would ruin its fun, while this level doesn’t need to be harder than a 1st-cycle level to make its gimmick fun. Plus, with “Value Valhalla” still in the 2nd cycle & the 2nd cycle also having “The Amazon Jungle”, we already had ’nough pink levels in the 2nd cycle.

I made 1 change when I moved “Chillblain Lake” to the 1st cycle: I replaced the fish enemies with spikes on the walls. I felt the fish were too unpredictable to be easy ’nough for such an early level, while the spikes are frivilous: just stop in the center & swim straight up.

Other levels received mo’ minor updates:

• I updated “Porcelain Dreams”’s pipes to replace most o’ the odd blocks on their corners with cornered pipes & added edge lines to the brick walls so there wasn’t so much cutoff. I plan to redesign much o’ this level, as I feel its gimmick is underutilized; but I ran into designer’s block & decided to wait till later.
• For “Foul Fowl Farm” I removed a tricky Noko no Pollos.
• For “Lunacy” I added extra space ’tween the spike shafts, which previously required far mo’ precise timing than I was comfortable with for a 1st-cycle level.
• Finally, I added a diamond to “Gravity, Hypocrisy, & the Perils o’ Being in 3-D”, which I’m shocked I’d forgotten to add this whole time. I also increased the player’s speed, since I was actually kinda bored as I was playtesting it.

The Future

I can confidently say the game is mo’ than halfway done — which isn’t that impressive, since I’ve been working on this now for o’er 3 years. Other than finishing the o’erworld & shop, fixing the graphical limitations o’ the save screen & localization, implementing user-friendly error messages in case certain files go missing ( a downside to using so many JSON data files ), & sprucing up things here & there, which I’ll inevitably do as I go on ( ¿how much have I updated the graphics to “Blueberry Burroughs” since I 1st created it @ the beginning o’ this project? ), all that’s left is the rest o’ the levels, a final boss ( & possibly a hidden final final boss ), & credits.

O yeah — I’ve also been thinking ’bout replacing the big diamonds with cards, which you will be able to look @ through the options in the o’erworld to read flavor text full o’ references to Boskeopolis Stories. Basically, they’d be like the cards in Simpsons: Hit & Run. I’m still working on the card’s animation frames, so I haven’t e’en started on the options screen yet.

Mind Your Manors

I spent all month working on just this 1 level & still wasn’t sure I’d get it all done, including recording playthroughs o’ the level, by the end o’ October. But I did.

This level idea started out as just some kind o’ vague HalloweenMuertoween-style mansion with this basic wallpaper & floor graphics, but all the layouts I came up with seemed empty & boring. Originally, I had bottomless pits in the mansion, which made no sense.

So then I came up with the idea o’ giving the player a flashlight in this level & challenging them to defeat all the ghosts to beat the level, & the 1st thing I did was prototype the programming for this to see if I could implement it in a way that didn’t feel awful. ’Twas tedious tinkering with pixels to get the rotating flashbeam & flashlight arm to align with the collision lines, but it seems to work all right. Since I knew this gimmick would have a risk o’ being janky, I deliberately made this level laid back & easy ( this also made recording easy & fast ’nough to do in less than an hour, as opposed to, say, “Brier Flier”, which took multiple days ).

Unlike almost everything else in this game, the flashlight collision isn’t just a box, but is 3 lines tested gainst the ghosts’ hitboxes, using some algorithms I found online, as well as some extra algorithms I had to fudge up to handle rotating the lines.

I remember 1 decision I hedged o’er was whether to allow the player to duck & slide down slopes ( in this case, the stairs ). I felt that having the down input make the player both duck & lower the flashlight, making it impossible to do either by itself, would be annoying¹. Originally, I had the camera-up & camera-down imputs move your flashlight, which fixed this problem; but I found that too awkward & feared it might be hard for players to figure out or adjust to & thought adding a message box to mention it would be lame². On a keyboard a’least ( which I still use for testing, e’en though I added controller support probably a year ago ), you have to use the same fingers for jumping & running as changing the camera, which is fine for the camera, since you rarely need to move it, anyway — I considered it a bonus mo’ than anything else. But for moving your flashlight, it’s far more o’ a hassle. ’Ventually, I judged that ducking & sliding wouldn’t be all that useful in this level, so I just cut them out. This had the unfortunate, but not dire, downside that it made the Flashlight Player’s code less clean & concise as, rather than just calling the general player update function, I had to copy parts o’ it with the ducking & sliding code removed. The biggest annoyance for a programmer is code that is very similar, but slightly different, so you have to debate whether to have copypasta ( which can make changing this copied code harder or risk adding bugs if they diverge ) or complicating the code & making it run slower for all with conditions.

I’m embarrassed to say how much time it took just doing the graphics for this level — as is common. All the slight adjustments needed for the staircases transitioning into ceilings & walls bloated the tileset ( which is already rooming with the forest tileset ) so that it almost took up all the tiles I have reserved, when most tilesets take up less than 10% o’ that space. All the lines & ridged shading kept misaligning, so I had to readjust tiles, only for this misalignment to cascade down all the tiles next to that tile, & so on.

Stop & Go Space Station

I actually finished this before “Brier Flier”, but was much mo’ mixed on the quality o’ this 1 & wanted to improve it mo’, ’specially its graphics. However, since then I’ve been able to think o’ any way to improve it & wanted to get this out before October, when I’d rather focus on “Mind Your Manors”.

I almost rejected this level’s gimmick o’ having to stop when the screen turns red every 3 seconds for being annoying & slow-paced, & I still wonder if maybe I should’ve. My thought process, in addition to urging myself to get this game o’er with, was that ’twas an original & memorable ’nough gimmick to be worth not being particularly fun. I also didn’t think I’d be able to think o’ anything to make this gimmick meaningful without making it feel impossible, but I think I was able to avoid that.

I don’t remember why I made the level have branching paths, but it works surprisingly well. Just beating the level is a short path to the end, which is good, since having to stop every few seconds draws e’en a short path out. But if you want the gem score, — which, for once, is much harder than the time score — you need to go all round.

I don’t like the diamond’s placement, but couldn’t think o’ a different place that didn’t feel forced. You can easily see where the diamond is when going round the top without e’en needing to particularly look out for it.

For some reason, @ the last second I switched out the regular space music used in “Lunacy” for elevator music. ¿I guess for variety? I like this song, but not when it keeps getting cut off.

As you can see, I’m still not fond o’ this level. The next level should be much better.

Visit the official website @ boskeopolis-land.com

Read the unreadable source code

Brier Flier

Fun fact: when I 1st recorded this, this level’s name was spelled “Brier Flyer” ’cause I thought “flier” was 1 o’ those weird words that goes gainst the rules o’ English spelling just to mire me & for some reason didn’t look it up. I just found this out as I started typing this & saw my spellcheck yell @ me, just as how it yells @ me that “’nough” isn’t a true word, which is ridiculous. However, due to the way I recorded this video — I didn’t want to have to keep going through the motions @ the beginning, including waiting for long ’nough for viewers to be able to read the goal text, every attempt I made @ this level, so I just spliced 2 separate recordings together during the pause on the goal message screen, when everything’s silent — I was able to fix it in post.

I chose to just show this level off in 1 playthrough, getting just the gem score & the diamond, since the automoving nature o’ this level makes the time score as easy as beating the level normally. It is possible to take too long, since the angles you turn in can make you go faster or slower.

But don’t let the shortness o’ this video imply that it didn’t take me hundreds o’ tries before I could get that gem score. When I set the gem score, I expected it to be lenient, only to find, to my surprise, that the few times I did make it to the end without dying I’d be off by a few gems ( 1 time I was just 100 ₧ off ). This is entirely due to me being a shitty player, though: this level’s gimmick is so simple & fundamental that I don’t feel like there’s any unfairness; it’s just a case o’ are you good ’nough to time your turning or not.

Like “Petrol Pond Place”, I mired o’er this level for mo’ than a year. My original idea was that you’d control an owl; but I couldn’t think o’ anything to do with that that wasn’t a pointless ripoff o’ Donkey Kong Country 2. I then experimented with a normal level with enemies that chase & push you into bramble walls while having bouncy heads for reaching high places. However, for some reason, I was insistent on having this Kafka reference for the goal message, & didn’t find this gimmick much mo’ interesting. Then the idea struck to have a paper plane weaving through thin bramble passages like that minigame in WarioWare, inc., Mega Microgame$!, ’cept with simpler, mo’ straightforward controls ( the WarioWare minigame had mo’ realistic gravity physics that caused you to move mo’ quickly when pointing downward & had slippery turning; in this level, you always go forward the same speed & turning has a static acceleration rate ) & it all fit perfectly. & despite all my frustrating failures @ completing my own level, I still find this level fun.

I e’en like the diamond placement for once. After finding every attempt @ adding a secret branching path to a diamond too trite, I was surprised I’d ne’er tried the obvious trick before: having the level just straight-up continue past the keycane. This works particularly well for this level, since the keycane is in a tight passageway with harder-than-normal controls. I also liked being able to make the spaces within the bramble walls secretly a passage you will ’ventually move through later on. I didn’t like the idea o’ making the player turn back round & go back after getting the diamond or adding a circle back to the keycane ( which would either be too easy & would entice players to just go that path to the diamond or would require double the level design ), so I just added ’nother keycane right after the diamond. It’s not as if there’s any law gainst having multiple keycanes in a level.

Speaking o’ the bramble walls, I hope you like the look o’ all those extra bramble stalks ’hind the walls, ’cause they were tedious to tile together. E’en after all the times I’ve talked ’bout how it’s usually the case, you’d be surprised @ how much less time I spend coming up with the actual gameplay layout o’ the level compared to the time I spend on the aesthetics. & keep in mind, this game isn’t exactly gorgeous — there’s a reason a basic run & shoot action game like Cuphead took mo’ than 7 years to make, & it wasn’t the programming.

If I have any qualms ’bout this level, it’s that the Pufferbees don’t have as much a role as I feel like they should — just a small section where you weave through them. Part o’ me feels like I should’ve had moving Pufferbees to make them different from just functionally a different graphic from the walls, as I experimented earlier in the level; but I feel making the player dodge moving bees with li’l reaction time may be too unfair. Gameplaywise, how it is is best, with the focus being on dodging the brambles, & bee-dodging just a short refresher in the middle; it’s only thematically that I feel the bees should be mo’ present.

I have ’nother level I’m close to completing & I’ve also been ruminating o’er for a while, so hopefully there should be ’nother update soon.

Visit the official website @ boskeopolis-land.com

Read the unreadable source code

The main delay for this level was designer’s block. I knew I wanted a level with sunset harbor graphics, but I wasn’t sure what I wanted to do with such a level. Early on I decided on implementing oil water, which basically works like the water in “Rusty Bucket Bay” in Banjo-Kazooie: you lose oxygen faster & don’t regain your oxygen till you return to land ( as opposed to just leaving water into the air, which only stops it from decreasing, but doesn’t replenish it ). But then I had trouble figuring out what to do with said oil water.

Round that time I also wanted to have pipes you could walk through that maybe went down into the water & kept you oxygenated, but couldn’t figure out how to make it work well. This game uses block-based collision, & whole blocks were too thick for pipe walls. Plus, I wasn’t sure how to make them show you will the oil water still hid everything ’neath.

In the process o’ making this level, I developed numerous sprites, ’bout all o’ which are used in this level: window monsters that fall from their hidden place & roll after you ( also taken from Banjo-Kazooie ), a machine that shoots pikes out o’ either end, Octopigs that hop & shoot oil balls @ you, an iron wall that forces you to swim down & hit a switch to make it lower, a water spout that causes a barrel to rise & fall, & crate platforms & harmful hooks swooping back & forth in a half-circular motion. In my defense, half o’ these are tied to the oil water: while the spout is just fancy paint o’er a rising & falling platform, the pike machine & iron wall are basically ways to challenge your ability to maneuver through oil water & get out before drowning. So they didn’t seem too thrown-in, I brought back the window monsters & pike machine @ the beginning o’ the level into the end o’ the level, too, just with a trickier pattern ( the water spout glorified rising platform & swooping platforms are too generic to need much extra use — there are plenty o’ moving platforms in other levels ). I also planned to add mo’ Octopigs @ the final stretch, but cut that part out as I found it too difficult & stretched out a level that was already going a bit too long. Part o’ me wishes I kept the ladder up to the keycane wherein you have to dodge the shots o’ Octopigs; but I already have ’nough o’ that in “Good Ship Lifestyle”.

I don’t consider this my best level, but I s’pose it could be worse.

As an addendum, I’ve recently created a website dedicated to this game at https://www.boskeopolis-land.com. So far it’s still very simple, but I plan to continue updating it. For example, I hope to create some script that will scrape these posts & create a list o’ links to them all to make them easier to find.