The Mezunian

Die Positivität ist das Opium des Volkes, aber der Spott ist das Opium der Verrückten

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXVIII: Stop & Go Space Station

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

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXVII: Brier Flier

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

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXVI: Petrol Pond Place

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.

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXV: Gravity, Hypocrisy, & the Perils o’ Being in 3D

Gravity, Hypocrisy, & the Perils o’ Being in 3D

I’m surprised this made it past the rejection bin. This started as an idle, silly idea that I planned to procrastinate to the sequel, ’specially due to the rigidity o’ this game engine, thanks to me to being a terrible programmer who was an e’en terribler programer when I started mo’ than 2 years ago. However, I figured out an easy way to do it by just adding some flags to hide all the blocks, make all the sprites invisible, & then just create a background that draws everything seen in this level. This is thanks to the MapLayer class being ridiculously flexible: it’s basically just an update & render virtual method.

This level & associated classes all have “Doom” in their name, but they should truly be called “Wolfenstein3D”, as this level uses the much simpler raycasting method that that game uses, rather than Doom’s mo’ complicated ( & mo’ powerful ) BSP trees. Raycasting works better for this game’s engine, as it works well with grid-based maps, which this game engine uses, whereas Doom’s system is based on lines which can be @ any angle ( & thus can have walls that aren’t all @ 90° angles, as Wolfenstein 3D & this game have ). That’s fine for me, since this is just 1 level & it’s s’sposed to have a retro look. I can tell you that I’d worry ’bout how primitive the 16-pixel block textures ( smaller than Wolfenstein’s, actually, but the size o’ blocks in this Mario-inspired engine ) look stetched out before I worry ’bout perfectly square walls. Since this works well with grid-based maps, I can just use a regular grid-based map & keep their usual behavior. This pseudo-3d gimmick is nothing mo’ than a visual gimmick o’er a normal isometric 2D level — basically just “Maybe I’m a Maze”, but with simpler, slower enemies that you can kill off. The walls are just regular solid blocks, the gems & hearts are the same gem & heart blocks used in all the other levels, & thus I didn’t have to add any new behavior there. Only the hero, enemy, & bullet sprites needed much new behavioral programming, & that was mostly to handle moving in various angles.

For those curious, the gist o’ raycasting is that you calculate a ray for each vertical stripe o’ the screen measuring the distance ’tween the nearest solid block on the grid & the player ( to be mo’ accurate, a point on an invisible line perpendicular to the player & a li’ in front o’ the player to prevent a strange fish-eye perspective ) & using that distance to calculate how tall that line o’ wall should be, with larger distances giving shorter lines & shorter distances giving longer lines, simulating walls shrinking in the distance. ’Course, there’s many other complications, like applying a texture to these lines ( in my case, I just calculate which texture X it should have & just stretch the texture block o’er the height o’ the line, which is mo’ efficient for SDL & GPU than manually calculating each pixel ), creating perspective textures on the floor & ceiling ( it’s a blur to me how I did this, though I do remember that the #s for the ceiling & floor are the same, just using a different offset for different textures ), & adding in “objects”, like the crab enemies, the bullets, the gems, & hearts & cutting out parts that are hidden ’hind walls ( this was actually the hardest part ). Since I have no idea what I’m doing for e’en basic programming, it’s obvious that I relied on learning how to do this nonsense from other sources, with this tutorial as a major influence, as well as Fabien Sanglard’s excellent in-depth study o’ Wolfenstein 3D’s source code, The Black Book of Wolfenstein 3D, which is what inspired this idea in the 1st-place ( though Wolfenstein 3D used so much assembly & so many arcane optimizations that most o’ its code wouldn’t work well for my project ). I did, however, twist the code I copied a lot so that it’s now virtually impossible to recognize, sometimes for petty anal-retentive reasons ( I don’t like free variables that change round a lot ) & some for optimization reasons, due to the difference ’tween low-memory computers that these guides were aimed for & modern computers with their strange GPUs & SDL with its immensely limited GPU control compared to OpenGL.

I ran into many subtle bugs ’long the way, ’cause this 3D-like business, e’en if just a graphical illusion, is far beyond what I’m used to. For instance, I don’t think my high school or my joke o’ a college I went to taught trigonometry, so I was just going off vague memories. ( I still don’t know what sine & cosine do, but I know I remember I used it for calculating angles on the shmup level I still haven’t finished yet, so it makes sense here ). & then I would just rely on trying things out & seeing what happens. The last bug I ran into was when I changed the shooting so that the bullet appeared a block or so in front o’ the player when shooting, so the bullet starts @ a size you’d expect to come from the slingshot & not @ the size o’ the screen ( which would make it look like Autumn is shooting rocks bigger than she is ), only for it to start @ the sides o’ the player when pointing in certain angles ( which makes e’en less sense, visually ). When creating this, I set the bullet to be an offset from the player’s center, which seemed most balanced; turned out, simply changing it to the x & y position ( which is the top left ) made it work exactly as expected. This still makes less sense to me.

For a long time before that, both bullets & the player moved in weird angles. This was less obvious for the player, since you can’t see them; for the longest time, I just thought ’twas just my imprecise angling while playing. I finally realized the cause was that the acceleration & velocity system I use for regular 2D movement doesn’t work with this strange angled movement. For those who don’t already know, almost all sprites move by setting acceleration, which is added to velocity every frame, which gets capped @ a set top speed, & that velocity is added to position. This works great for, say, 2D platformer movement ( & is, in fact, how movement in Mario games works — though they oft have weird acceleration oscillations for reasons I don’t understand ). However, for angled movement, this, with the velocity cap, creates a subtle problem: if your angle is so that you move mo’ on 1 axis than the other, then that axis’s speed will be greater than the other axis. However, due to the speed cap ( which is necessary to keep you from going just zipping through everything ), after the bigger axis reaches the speed cap before the other axis, the other axis keeps gaining speed till it reaches the same cap, which gradually transforms all non-straight angles ( all angles that don’t have the lesser axis as exactly 0 ) to 45°. This, logically, causes the very effect I could see from the beginning: veering parabolas. The level as shown just has constant speed for the player & bullet sprites, which fixes this ( though, an example o’ this game engine’s stupid built-in rigidity, ’cause I have it built into the core sprite class that collision detection relies on the built-in velocity properties to work, I do still have to set velocity, or else do a bunch o’ work creating a new collision detection just for this level ).

The 1 exception to this fix are the crab enemies: they still fall under the ol’ movement glitch, as you can see by their weird sideways movement in the video. I did this on purpose as I prefer this movement for them — it fits their crablike nature perfectly. The only bug with them is why I have crab enemies in a dungeon. The answer: I can’t think o’ an enemy design I like better than them & they have a simple animation that isn’t a headache to depict.

The challenge offered by the crab enemies is interesting to me: since this is a 1st-cycle level, I made this level very easy. The crabs aren’t very fast & you have to basically try to get hurt if you see 1 coming up to you & can’t shoot it down before it touches you. That is if you’re not racing round with strafing ( like in most games with 3D movement, strafing is quicker than just moving forward, which is why I move like a Goldeneye 007 speedrun in the time challenge part o’ the video ); if you are, they can sneak up on you when you can’t see them clearly.

Since this level is so easy, I didn’t feel any qualm with forcing the player to explore the whole maze & collect every gem in the level to get the gem challenge. But man can it take long, & makes me wonder if I should’ve picked a less monotonous song for this level ( “Boskeopolis Underground” had this same problem ). I was not happy when recording this video & actually dying to a crab somehow when halfway through attempting this, making me do it all o’er ’gain.

The time challenge, meanwhile, is easy if you know the strafing trick, ‘cause I didn’t want to force players to figure out such an obtuse trick to complete the game.

Source code

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXIV: Through the Sharp Hawthorn Blow the Winds

’Cause everyone loves wind gimmicks.

Those who have been paying attention to these posts since their earliest entries ( surely nobody ) would recall that I had been working on a level with this gimmick, forest theme, & palette since near the start, but couldn’t be arsed to finish due to other levels shoving it aside. ’Cept for the longest time, ’twas called “Windy Woods”, which was too unbearably cliché for me ( & “Gusty Glade” was already used by Rare ). Sick o’ so many Rareware alliteration names & puns, I stuck with an age-ol’ Shakespeare quote, showing no regard for the fact that this level has no hawthorns, & that such a name would better fit a bramble sky level than a forest level.

Thanks to using such a long name, I finally forced myself to stop being a slob & update the o’erworld inventory & level select screens to accommodate larger level names, which was done through giving the level names in both an extra row. As o’ now, this looks weird to me; hopefully I’ll get used to it ’ventually.

This was also a level, ’long with “The Minus Touch”, that I’d always planned to be 1 o’ the most challenging levels in the game ( though not nearly as challenging as “The Minus Touch” ). This can be seen in the 20-minute video, wherein, for once, I didn’t edit out the deaths @ all, so viewers can see all o’ my many failures ( since I already did the many-deaths cut for “The Minus Touch” ).

Trying to make a difficult level can be difficult itself since it can be hard to tell whether difficulty is legit or cheap. In particular, I worry ’bout the birds & the bouncing spike balls being beginner’s traps, since it’s hard to see them before they strike. But then, ¿isn’t challenging players to have quick reflexes perfectly legitimate? There’s also a spike ball near the start that you can’t see till it’s already falling ( ironically, just after a fake spike ball that doesn’t fall @ all ) — unintentionally, since it doesn’t fit in the camera from so high up. I left it in since it’s extremely unlikely a player will get hit by it since there’s no reason to just stand under it & ’cause I thought ’twas funny to have a spike ball fall after where you’d expect it to fall. The graphics may also be crowded, making it hard to make things out. The limited palette doesn’t help.

In the end, I chock this level up to be a Rareware level ’long the etchings o’ “Lightning Lookout” or, perhaps closer, “Gusty Glade”. Hell, a’least I made sure my wind mechanic stays perfectly consistent throughout the whole level.

Since the level is hard ’nough to beat ( by my low standards a’least ), I didn’t put much stress on the gem & time scores. I filled the level with gems, making its 20,000 ₧ requirement easy to meet if you wait round grabbing most o’ it in all the big caches. As the video shows, you can beat the time score by 6 seconds, which surprised me. I didn’t put much effort into trying to beat the time score when I 1st set it &, as the video shows, I was able to spontaneously figure out a way to easily slip past the bouncing spike fruit. I’ll still keep the time score, though, since it’d be refreshing to have a time score that isn’t as stringent as possible. They’re made for ordinary players, not professional speedrunners.

I’ll note that playing any other level after playing this level too much feels weird, since I’ve found I adjusted to the wind & found Autumn’s newfound lack o’ resistance o’erbearing & would way o’ershoot jumps.

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXIII: Catahoneycombs

I delayed this video ’cause I felt this level may have too much content — &, in particular, too many gimmicks — for just 1 level & considered splitting it into 2 levels, which would conflict with my theme system, since I already had 3 mine levels & no other theme where this level would fit, e’en in a game that already stretched level themes beyond their logical boundaries ( quite a hefty problem for a game revolving round revolving level themes, which needs meaningful level themes for the cycling o’ said level themes to have meaning ).

I mentioned in an earlier post that I prefer to have multiple li’l gimmicks in a level than 1 all-encompassing level gimmick so that the level doesn’t feel too 1-dimensional; however, too many gimmicks either bloat the level too long ( & I feel most games have levels that are too long ) or leave some gimmicks underused, which I fear may happen here, particularly with the sticky floor gimmick. Other than a few places near the beginning that simply show without telling how sticky floors work without risk, the sticky ground is only used in 1 small section in the middle o’ the level challenging you to dodge Pufferbees while traversing sticky floor. This can be ’splained by the fact that I didn’t consider adding this gimmick till late in this level’s development: originally, this level went straight from that 1st platform with a white ant on it to the next.

’Twas mainly this gimmick I planned on cutting out into its own level, while leaving this level as ’twas originally. But in addition to not having ’nother level slot for ’nother beehive level, I came to the conclusion that there probably wasn’t much else to do with the sticky floor gimmick. Plus, I don’t think ’twas a particularly enjoyable gimmick to stretch much longer, either.

’Sides, the other gimmicks in this level aren’t strong ’nough to hold a whole level. The honey bubbles that form this level’s predominant gimmick1 are just floating water, & the honey falls are just vertical lines o’ water with greater downward force. I didn’t e’en bother to eliminate the oxygen mechanic o’ these water blocks, which I considered, but then declined, since I didn’t feel it worth the effort & felt the oxygen element added an extra complexity to these simple gimmicks, ’specially to the honey falls, adding a bit o’ extra challenge to getting all those gems down there. Meanwhile, the white ants are just a new enemy type that could hardly be called a “gimmick”. Also, I considered taking them out, since, as the video was nice ’nough to show, they glitch out sometimes for reasons I still haven’t figured out. It can’t be due to some blocks not spawning messing up their block detection, as the “blocks_work_offscreen” flag is turned on so that the square-formation bees near the beginning are already moving when you get there ( a necessity if you don’t want the 1st jump to be free & you want to ensure the bees are always in sync with each other ).

Recording this level’s video went surprisingly great: I was able to get it all in 1 take. That’s rare & surprising for a level so tricky — with so many tight jumps where it’s easy to just nick a bee or spike — that I’m considering moving this up from the 2nd cycle to the 3rd & putting “Curse o’ th’Ladder-Splayed Caves” in the 2nd cycle ’stead. The only true hitch was the obligatory level error remaining during recording: the white ant that spins off its platform into space.

I was ’specially surprised I got the time score 1st try, since I flubbed up so much, including the part where I miss the initial bee space due to brain flatulence & waited there a whole second like a buffoon. A’least I was able to show that with quick but tiny jumps you can go through the middle section with honey floor & bees without pausing, as I detest when game’s make you stop. Also, I think I miscalculated the gem score: as the video shows, e’en if you don’t collect every gem, it’s still easy to get mo’ than 10,000₧, while the score requirement is only 9,000. I should bump it up to 10,000.

This level’s music, by the way, is not by the elusive public domain composer Kevin MacLeod, who made most o’ these songs I used, but by Lobo Loco & came from my other main repository for free music ( well, Creative Commons, which works fine for me, since my game is on Creative Commons, too ), freemusicarchive.org. None o’ MacLeod’s songs fit a beehive theme particularly well — which you can’t blame him for, since it’s a rare level theme. I thought searching “bees” in Free Music Archive would be a far fetch, ’specially since, unlike MacLeod, that website doesn’t focus on video game themes. So you can imagine my surprise when I heard Lobo Loco’s “Save the Bees” & heard exactly what I wanted. It reminds me a lot o’ the “Flight of the Zinger” song from Diddy’s Kong Quest, used in that game’s beehive levels, which is exactly what I was thinking o’ when imagining what I wanted this level’s song to sound like.

This source code is so bad it gives me hives

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXII: Good Ship Lifestyle

For once the layout & programming took mo’ time than the graphics — probably ’cause much o’ the graphics are reused from other “pirate” themed level. & for once this is actually pirate themed & not a beach or bathtub.

It’s hard for me to get difficulty right ( or I fail to get it right ), since I’m bad @ games, so I can’t tell if I made a level too ridiculous or if I just suck. ¿Does dodging some o’ these anchor bullets require luck or just sharp eyes & reflexes? I considered lengthening the minimum shoot delay, since it seems like the most seemingly unfair hits were when it shot just after shooting, but decided not to, since I figured I was just reacting too slowly.

Anyway, the gem & time scores are lenient & I’m quite sure all o’ the trouble I had gathering the footage for this day’s video was due to sloppy playing. The time video here particularly shows that off, as after near flawless playing through the 1st half I flop round as if my fingers were covered in butter & hesitate as if I developed Alzheimer’s & still make the time score — though right on the last second.

The ladder shafts & the final stair climb are so saturated with anchor bullet sprites that it caused slowdown, so I had to fiddle together some optimization tricks. The 1st 1 I did had nothing to do with sprites, but eased the level’s run load so much that it made up for it: many o’ the tiles are background tiles, & I noticed that none o’ those tiles animated or changed. I’ve realized for a while that drawing all these li’l blocks is probably 1 o’ the most inefficient things this game does, since it calls the SDL_RenderCopyEx function for each block, which valgrind has consistently told me is slow. ( This is what led me to realize many updates ago that loading a small image & tiling it for a background is slower than manually tiling it into a large image & just loading & drawing that large image once per frame ). So I created a branch o’ the background tile code & created ’nother version that @ the beginning creates a texture o’ all the level’s background tiles & just draws the portion o’ that that’s on the screen every frame, turning what could be o’er 200 SDL_RenderCopyEx calls per frame into just 1 per frame.

That seemed to get rid o’ the slowdown. But I still wasn’t sure or satisfied, so I made 1 other quick & easy optimization that was actually relevant to sprites & I should’ve fixed a while ago. When a sprite is killed off, it’s simply erased from the vector o’ sprites. I’ve read on the internet that vector’s erase method shifts all entries after the deleted entry backward to fill the space & still maintain the order o’ entries. Unfortunately, I don’t care ’bout sprite order — it’s arbitrary, anyway, based on whatever order the map reader finds them, which isn’t tied to the order the player is likely to find them. Moreo’er, this is slow — I believe worst-case O(n). So I changed it so that it now just replaces the data o’ the sprite to be deleted with the final sprite’s data & then just pop off the final sprite.

I must confess I didn’t come up with this idea myself, but learned it from this chapter on “Object Pools” o’ the book Game Programming Patterns. In fact, I’ve known ’bout it for years & used it in earlier programs I’ve made, which is why I said I should’ve used it earlier.

As an extra maybe-optimization that didn’t hurt is I set the sprites vector to reserve 50 spots @ the beginning to hopefully avoid going past the size o’ the vector & having to slowly reallocate memory, move the data, & delete the ol’ data. When considering this optimization, I considered changing the vector to a classic C array, since I wasn’t sure if vector e’en allowed you to delete any entry without automatically shifting other entries; but realized it didn’t matter, since the sprites are held as unique pointers, so I could just release the last entry’s data & reset the unique pointer o’ the sprite to be deleted to that data. I decided to stay with vector for the greater size flexibility it gives. I prefer the balance o’ safety & speed I can get by having a vector with a moderate # o’ space reserved so that having to enlarge the vector is unlikely, but still gives me the chance to enlarge the vector if absolutely needed, for some rare outcome that I can’t predict.

’Course, the fact that sprites are held as pointers & not data itself means that this vector can’t take advantage o’ data locality, — which I also, coincidentally, 1st learned ’bout from a chapter o’ Game Programming Patterns — which is also a rather big inefficiency. However, fixing that would take a lot mo’ work — I would basically have to refactor all sprite code so that it uses discriminating unions — which are both racist & socialist, so neither side o’ the political spectrum likes them — ’stead o’ polymorphic sprites. In hindsight, I would’ve preferred using discriminating unions for this & a few other reasons, but it’s too late; so we’re stuck with slow & stupid polymorphic classes. I could think o’ many other optimizations I could make, some big & some so small it’d be a waste o’ time — & some big, but would require me to reprogram large parts o’ the game’s integral code. This isn’t so much “fix all inefficiencies I can think o’”, which would make this project take decades to finish, but “fix inefficiencies that are obvious & ridiculously easy to do”. I’ll save these bigger ideas for the sequel, where I can start from scratch. Now I want to just get this sloppy mess finished & out o’ my sight.

Anyway, these optimizations not only seemed to clear all slowdown in “Good Ship Lifestyle”, they also seemed to fix the slowdown that has been in “Value Valhalla” for probably o’er a year. ( Didn’t fix most o’ the sprites disappearing after a loop, though ). Why this happens, I can’t understand, since this level has neither any background tile layers nor sprites that are deleted.

& I must say, this level’s music is a true banger. This time it isn’t by Kevin McLeod, but by a band called Blue Wave Theory, found on Free Music Archive, released under Creative Commons ( & thus OK for me to use ). It’s surprising how much high quality music you can find for free — which is great for people like me with absolutely no musical talent.

Final Fun Game: Try & find the minor graphical ( technically, level-design ) flaw I made & didn’t notice till after I already recorded the video this time.

Here Is Where the Bad Polymorphic Classes Can Be Found

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXXI: Dark Sahara

I finished this level a while ago — I just forgot to do a video on it till now. I think I was planning to do a bit mo’ graphical polishing. The volcano enemies still don’t look so good, & I just noticed while looking o’er the video that its fireballs sometimes go ’hind the cliffs due to some graphical shenanigans o’ how those cliffs work. Also, I waffled o’er what color I wanted this level to be. @ 1st it was bright yellow; but then I realized a desert being bright yellow @ night didn’t make sense & that I already have plenty o’ yellow in this game.

I’m not so hot on this level. It’s probably way too derivative o’ Doki Doki Panic / US Super Mario Bros. 2. Furthermo’, the bird-riding makes most o’ the level basically an autoscroller & the fireballs the volcano enemies spit out are random. Ironically, it’s ’cause Super Mario Bros. 2’s Pansers, whom this volcano enemy is obviously ripped-off o’, works the same way that I argued that ’twas all right. But I’m still not sure if I just have slow reflexes or if this is just unfair. I actually hope for the former, since I’d rather be bad @ playing video games than designing them.

I also got to steal from myself by taking that bird enemy’s graphics from 1 o’ the sprite comic episodes o’ Boskeopolis Stories. That makes this enemy & their mechanic technically inspired by a comic inspired by a video game. So Boskeopolis Land is the equivalent o’ Street Fighter: The Movie: The Game, or whatever it’s called.

The gem score, like many o’ the recent levels I’ve made, allows a few gems leeway, since getting all the gems is pain ’nough as it is. The time score isn’t much, either, since much o’ this level is autoscroll & gives you li’l control o’er how fast this level goes.

Man, this level sucks. I should’ve stuck with the idea o’ ripping off the bull level from the Rabbit Rampage game, ’stead. A’least nobody cares ’bout that game, so nobody would notice my plagiarism. Hell, e’en the name sucks: I don’t e’en think this level’s environment is saharan.

Downloading this code will infest your computer with malware till you get 999,999,999 points in this game.

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXX

It’s been long since last update, but that was ’cause I for no known reason waited till I got these 4 levels sorted through. Thus this update took long ’cause it’s 4 updates in 1.

Foul Fowl Farm

The 1st mountain level, as the music & background hint. I originally planned to have it be the 2nd mountain level, with “Milky Mountains” as the 1st, but I’ve found this level to be much easier than that level, & it fits better, difficulty-wise, like that. It doesn’t fit as well theme-wise, since it’s strange that a straightforward mountain level would be 2nd & the level that twists the theme a bit comes 1st, but that’s not as important. Plus it’s a bonus to start strange, so the audience doesn’t get bored before the good stuff comes. Always put the best 1st & last & the weakest in the middle; & though I don’t consider “Milky Mountains” to be bad, I consider it on the lower end, & worse than “Foul Fowl Farm”.

This was, indeed, a level that took much mo’ time drawing the graphics than coding it, since the goal gimmick was already mostly coded for “Playing Railroad”. I e’en had to make a program to generate the tiles for the barn roofs, since they comprise to many blocks for me to have the patience to do that manually.

However, it did take mo’ recoding than it appears. 1 lame thing I had to do was make copies o’ all the Pollo no Noko enemies, since the originals respawn after they die — & need to stay that way for “Milky Mountains” to still work right. In this level, that clearly can’t fly, since you could just respawn & killing the same chicken. E’en if my counter was smart ’nough to account for that, which would be mo’ effort than just copying & pasting, it would be annoying for the player to have to remember which chickens they’ve already bopped. Much simpler to just keep bopped chickens bopped.

I also had to create a new slope template, since the 1 I I’d just made for “Stormy Skyscrapers” only accounted for different slope widths, while the barn roof needed a super steep slope 2 blocks high. Since ’twas so different, trying to wrangle the already-existing slope template wouldn’t have been worth it, so I just created a new template.

It seems I was mo’ lenient with the time scores with these levels, since the video o’ my winning attempt to get the time score is full o’ weird flubs. The gem score, however, requires you to get all o’ them, which is fair, since this is a short & easy level.

Frostbite Mines

I was mixed on this. For a while I wanted to make a spiral-shaped level as part o’ my strategy o’ basing level maps ( more o’ less ) on simple shapes; & as simple as this level is, I like how it works. You may notice that a common strategy I play is to sometimes give levels 2 gimmicks when 1’s too modest1, so the level isn’t too pedestrian. In this case, just sliding under spikes & dodging falling snowballs by themselves aren’t compelling ’nough for their own levels; but mixed into 1 level gives the level mo’ depth. It feels mo’ like Donkey Kong Country 2 & less like Donkey Kong Country 3.

However, this & the next ice level I’ll write ’bout uses up all the ice level ideas; & I still wanted to have a snowy mountain level. That’s why I waited till I finished the other ice level to confirm whether I wanted these both. ’Twas during this time that I came to my solution: just move the ice mountain level to the mountain theme. However, this pushes me into deciding ’tween mo’ levels: the ice mountain vs. that dumb level where you just don’t press anything for 30 seconds vs. the volcano level idea vs. ’nother desert level I’m working on ( since all o’ these ’cept the ice mountain could potentially be desert levels ). But that choice is easier.

Technically, I finished this level’s graphics last, since I decided to use the ice-mine blocks I made for “Chillblain Lake” ’stead o’ the regular mine blocks. But the main design was made 2nd. Besides, as I’ll rant ’bout, I neglected to finish the graphics o’ the next 2 levels.

’Cause this is a rather difficult level for this game, this is a 4th-cycle level. It’s easy to be a li’l off on your budging when near spikes or next to the falling snowball to get a li’l too close & taking a hit, & there are no hearts. That said, this is 1 o’ the few short 4th-cycle levels.

I think I intentionally made the time score for this level somewhat lenient, since it’s a rather difficult level, as I usually do. I think the gem score lets you miss ’bout 1 gem ( which, sadly, doesn’t include the 250 bright gem @ the bottom o’ the slope o’er spikes ).

The Amazon Jungle

This is not a jungle level, but what is planned to be the 2nd factory level. The name is based on a 2-part pun based on the warehouse company Amazon that the city near to me, Seattle, has a love-hate relationship with for being a great job-creator for jobs that are miserable to work & a classic novel, The Jungle, known for its gruesome depiction o’ factories, which inspired regulatory acts by the Theodore Roosevelt administration in the US. I fiddled with names that involved the word “warehouse”, including the truly dreadful “Warehouse o’ London”, which makes no sense, since this game obviously takes place in the fictional city o’ Boskeopolis, not a real British city. I finally decided that the current name is mo’ clever than any hokey Rareware alliteration on “Warehouse”.

The level is mainly based round moving trucks carrying what I s’pose are packages. I actually made these sprites a while ago for a city level I rejected; but ’stead o’ having packages on their backs, they had… whatever the backs o’ big trucks are called. I think they were called “Anguri Trucks”, based on the Japanese way o’ saying “angry”, for some reason. They’re basically just Mega Moles from Super Mario World that are a danger if they run into you, but can help you by giving you a moving platform o’er spikes. Not only is it a ripoff o’ that, but making them trucks is clearly inspired by the VIP rom-hack series, which changed the Mega Mole graphics into some obscure truck meme.

I find this level questionable, mainly due to all the parts that slow you down, such as the part where you have to ride the truck & the part where you have to stay ’tween 2 trucks in a long line o’ trucks to slowly make your way to the end. I don’t like autoscrollers, as they make you wait, & waiting is boring. I guess these aren’t too bad, since you don’t have to wait too long ’tween actions for the riding section, & it’s not long, & you have to constantly time your budges forward to keep yourself from falling too far back & hitting the truck ’hind you or going too far forward to hit the truck ’head o’ you, so you’re not just waiting. Plus, one could take the long line section as a satire on traffic jams — an idea I’ll admit I just came up with now. A’least they’re broken off with free platforming sections.

I’m also not sure how to feel ’bout that section that kills you if you stay on the truck as it lets it rise up. I tried to indicate that it’s death by putting a skull in the background there; but that just makes one wonder why it’s e’en there. The obvious answer is as a joke — but it’s still weird. O well: better games got ’way with worse bullshit.

Since this level constrains your movement so much, I know I intentionally made the time score lenient, as seen by my still-winning flubbed-up video. Like “Frostbite Mines”, the gem score lets you miss a few gems, but not many.

I always hate it when I spend so much time trying to make sure the presentation o’ a level is as polished as I can make it before making these presentations & being able to move on, only to realize after already making the video that I didn’t finish everything. ¿How could I forget to put a string on that package that raises you to the top? Actually, I didn’t e’en notice that till I noticed that the package lacked any kind o’ shading & realized that I ne’er got to polishing that sprite @ all: I just drew the simplest design that looked like a package I could & commensed with making it work how I wanted ( as is wise to do: e’en worse is wasting time polishing design for something you later realize doesn’t work & must be tossed aside ), only to forget to do the polishing part.

Chillblain Lake

Though I originally planned to make this a 3rd-cycle ice level, I may make this a 2nd-cycle — or e’en 1st-cycle — level & move “Frigid Frigates” to the 3rd cycle, since I feel like it’s harder than this level. E’en “Ice Box Rock”, which is in the 1st cycle, might be harder than this level.

This level is heavily inspired by Wario Land 3’s “E2 The Frigid Sea” green treasure, wherein you start out with water, giving you access to the chest, but not the key, so you have to go hit a switch to turn the water into solid ice, giving you access to the key, but not the chest, which means you have to go back & hit the switch 1 mo’ time. As arrogant as it feels to say, I feel my design is better than Wario Land 3’s, since there’s less backtracking: in Wario Land 3, you go through the same path twice to the switch, while this level makes you go in a figure 8, with the 1st path to the switch in the water that leads to the chest, & thus blocked off after turning the water to ice, & the path to the key going onward to the switch in ’nother way.

I particularly like the way the 2nd path leads to a cliff o’er the switch. When you 1st reach the switch, you’ll likely see it, ’specially if you grab the tantalizing gems ’bove the switch. But you can’t reach up there ( nor can you reach the very topmost tantalizing gem ). It’s only on the way back to the switch through the other way that the player learns the mystery o’ the cliff too high to reach & can finally nab that too-high gem.

The diamond was originally just in an alcove on the key side o’ the water, sort o’ parallel to the main path in the chest side o’ the water. However, I felt that was still too easy to find. I wanted to involve the water-ice gimmick in some way, so I made it so that you couldn’t quite reach the diamond ’bove the water, but could with the ice. But then I remembered that ice is solid, so you can’t go through it to reach the diamond. So I made a somewhat secret passage ’bove the spikes @ the end o’ the curve upward & made a ladder passage ( which, unlike “Stormy Skyscrapers” & “Foul Fowl Farm”, has a top that you can climb up to, but can’t climb down, making it 1-way ) back up to the curve, since the ice path is still blocked off. My only problem with this is I don’t think this passage is secret ’nough. I pushed it back ’nough so that you couldn’t see the other side o’ the wall with the kind o’ natural camera you’d have when you reach the spikes; but as you jump up the curve on the normal path to the switch, you’re guranteed to see the secret passage opening.

You may notice the sliding under spikes gimmick from “Frostbite Mines” used here, but in a much easier, shorter way. That is ’nother technique I use sometimes: gimmicks reused in later levels in much less prominent ways as either a short tutorial for the real threat, as used here, or mixed with ’nother gimmick as a mo’-challenging twist on the gimmick, as seen in “Crying Lightning” with the fading-in & fading-out cloud platforms from “Cotton Candy Clouds” ( a gimmick that was also taken from Wario Land 3 ) mixed with the chasing lightning cloud enemy for a short bit, challenging the player to time jumps gainst the 2 gimmicks simultaneously ’stead o’ just 1.

Sick o’ the mine blocks used in so many levels already, I made an icy version, mixing the ice tops o’ the ground blocks from “Frigid Frigates” with the mine blocks, which I then decided to add to “Frostbite Mines”. I also changed the also-o’erused rocky mine background ( I’m still not sure if I’ve finished that background or if I’m going to ’ventually try adding wooden frames to it ) to a background totally not heavily based on a Wario Land 3 background from the same level this gimmick was taken from, but I didn’t use that background in “Frostbite Mines”, ’cause I found ’twas too hard to see with that level’s much brighter palette, made brighter by the white fog. I also opened the roof & added sunlight streaming in from the top. I e’en made this level’s name “Chillblain Lake”, ’stead o’ its original name, “Chillblain Caves”, which is mo’ fitting, since this level’s main focus is the lake shifting back & forth from being liquid or solid. All this is a way to try minimizing the mines aspect o’ this level, since it feels weird having half the ice levels be mine levels, too, when we already have 3 mine levels.

Despite all this polish, I realized too late that I ne’er bothered to make the fish enemies have mo’ than 1 animation frame or not look like something I sloppily drew out in a couple seconds, which is what I definitely did. Worse: this isn’t e’en a new enemy, but 1 I made way back for “Soupy Sewers”. Why I still haven’t given that enemy worthwhile graphics is beyond understanding.

However, I did think to make these fish boppable underwater, as the video shows, proving that I took my critique ’bout not being able to hit enemies in water levels being a contributing factor to those levels’ popular hatred in my article ’bout Super Mario Bros. Deluxe to heart for my own game.

I just realized I’ve been forgetting to update the readme, so this readme was publicly revealing planned bugfixes I’d already solved for months.

Posted in Boskeopolis Land, Programming

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part XXXIX ( Stormy Skyscrapers )

Stormy Skyscrapers

It’s a good thing I didn’t promise anything specific, ’cause I ended up completing a completely unmentioned level. ’Cept, if you paid attention, you might have seen clues o’ the idea ’hind this level lurking in the background since my 5th post. I’m surprised I hadn’t shown off mo’: for the longest time I’ve had an unfinished city map with a grayscale palette, a few Hydrant enemies, & a long spike pit with horizontal & vertical moving platforms, with the plan o’ the level being mainly vertical.

None o’ that map made it into the current 1, which I started working on sometime last month, inspired by my playing Super Mario Bros. Deluxe, as I oft do during September, for some reason, & finding ’nother gimmick to steal. In this case, I basically completely ripped off the… ¿teeter-totter platforms? I don’t know what they’re s’posed to be called, but they’re called “weight platforms” in the game’s code. The 1 notable difference is the improved rope graphics, that was a pain to get to work right.

This level is heavily inspired by World 4-3 in Super Mario Bros., which I think is my favorite level in that game. However, the thin mushroom platforms are replaced by skyscrapers. I wanted this level to have a retro platformer feel, which is why it has a grayscale palette: much as mushrooms are sort o’ the natural, normal setting for Mario, urban landscapes are the natural, normal environment for Boskeopolis, — which is a city, after all — which is why it’s the 1st setting o’ each cycle.

The paper plane enemies, which grab you & drag you back to the start if you don’t struggle out o’ them quickly ’nough, are a riff on the randomly generated Bullet Bills. I thought making them drag you backward a bit was a nice way to balance having an extra projectile to dodge while not making it too hard to avoid being killed — while also rewarding you for being a fast button masher for struggling out o’ their grip. Then ’gain, some might find this mo’ annoying, ’specially when there’s an infinite healing heart block in the middle o’ the level. This is s’posed to be a 2nd-cycle level, so it shouldn’t be too difficult. It should be just a notch ’bove the 1st level.

I can’t remember exactly, but programming in the weight platforms probably took the most time out o’ everything, & became a barrier when I stumbled ’pon a bewildering glitch that caused 1 o’ the platforms to not budge, no matter how much I stepped on it ( but did work for the other 1 ), no matter how much I rolled back my code or recompiled it. Finally, I narrowed down the culprit in the silliest way: technically, ’twas caused by changing the map, which was why no amount o’ rolling back code fixed this bug — ’twas a bug that had been round since the start, but hidden till I added a block right ’tween the platforms. To make the platforms work, e’en when 1 is off-screen, I made the actual sprite go all round the limits o’ where the platforms can go till they fall. Thus, the block ’tween them was interacting with them & trying to block them from going downward. The fix was to simply turn off block interaction for that sprite, since they clearly didn’t need it.

I was updating this sprite up to near the end o’ developing this level. As I was demoing collecting gems in the level, trying to determine what I should set the gem score to be, I realized I’d ne’er implemented gaining points when breaking the platforms.

A’least the weight platforms sprite doesn’t seem to have much ugly kludge code, & I actually bothered to comment it properly.

The next boundary I ran into was, surprisingly, the gorilla sprites spawned by the big barrel sprite, an obvious reverse paean to Donkey Kong — the same problem I ran into on for “Ice Box Rock”, but far trickier to fix, since the platforms they walked o’er were sloped. @ 1st I just kept the level with the blocks_work_offscreen flag checked in the hopes that it wouldn’t be too slow, like “Rooftop Rumble”, which also has the option. I e’en tried optimizing the map by making all o’ the building blocks that weren’t the roofs background tiles, since you can’t interact with them, anyway. But, predictably for a much bigger level, there was noticeable slowdown. For, not only did this level have mo’ blocks than “Rooftop Rumble”, it had far mo’ sprites — sprites that all needed to interact with blocks, which was the point o’ making the blocks work offscreen in the 1st place. We’re talking ’bout up to 20 sprites, as opposed to “Rooftop Rumble”, which only has 2 sprites.

Surprisingly, I was able to optimize the handling o’ blocks when offscreen, so that the level seems to work in perfect speed now. ’Twas clear to me that the main problem was that every sprite was testing interaction with every block — 20 sprites times hundreds o’ blocks. The trick was to limit the blocks checked per sprite to only blocks near ’nough to actually be probably candidates. @ 1st I sat round thinking o’ complex patterns o’ dividing maps into screens, only to realize that that wouldn’t help when sprites enter the dividing line ’tween screens, till I tried a much simpler solution.

The way the block list works normally is that non-null blocks are added to the end o’ the list as they’re sequentially scanned from the map array, from top to bottom, left to right. Since empty tiles ( 0 in map data ) are ignored to save memory, & since no maps don’t have large gaps o’ empty tiles, the sequence o’ blocks in the block list have no relevance to their position, as shown below:

The position for each block is held in each block, & thus each sprite needs to test each block to see if they’re colliding.

Visual comparison o’ block data rendered based on position & data as its held in array:

The solution was to change it so that all tiles, including empty tiles, are added to the block list. This creates a consistent pattern ’tween the map & block list, like so:

Doing this, we can calculate where in the map a block will be by its location. We can be sure, for instance, that a block whose index into the block list has a remainder gainst the map width o’ 0 will have 0 as its x position value. Indeed, this is obvious when we remember that the blocks get their position in the 1st place from their position within the map’s block list.

Thus, rather than testing every block for each sprite, we only need to test blocks within a range o’ a block or so ( I picked 3 blocks @ a whim ) ’bove to below & left to right. Thus, the loop changes from

for ( Block& block : blocks )
{
    block.interact( sprite, ... );
}

to

const int first_x = floor( sprite.xPixels() / PIXELS_PER_BLOCK ) - 3;
const int first_y = floor( sprite.yPixels() / PIXELS_PER_BLOCK ) - 3;
const int last_x = ceil ( sprite.rightPixels() / PIXELS_PER_BLOCK ) + 3;
const int last_y = ceil ( sprite.bottomPixels() / PIXELS_PER_BLOCK ) + 3;

for ( int y = first_y; y < last_y; ++y )
{
    for ( int x = first_x; x < last_x; ++x )
    {
        const int n = y * map.widthPixels() + x;
        Block& block = blocks_[ n ];
        block.interact( sprite, ... );
    }
}

When I was 1st testing this out, I actually started by changing the rendering code to this, based on the hero’s position, which, when I figured it out, gave this cool effect where only the blocks right round the hero sprite appeared.

In hindsight, this is an obvious optimization: trading space for time, which is usually beneficial on modern computers with mo’ memory than it has processing power to use optimally. I think I thought adding mo’ blocks to memory was slower ’cause levels with the blocks_work_offscreen flag checked on were slower. But that was ’cause it had to process mo’ blocks, not just ’cause it had to keep them in memory.

This makes me think it might be mo’ efficient to use this kind o’ code with regular levels where only the blocks on screen & just round are live, ’specially since it would be less o’ a memory burden, being a few extra blocks ( probably barely mo’ than a kilobyte o’ extra memory ).

After that, the only snag was a slight bug with that paper airplane sprite: I thought it’d be cheap if you could get hurt by enemies if the paper airplane happened to move you through them, so I made the paper airplane sprite turn off the hero sprite’s ability to interact with sprites while in its grasp. The problem is, that meant the paper airplane sprite itself couldn’t interact with the hero sprite. The solution rather janky, but works: give the paper airplane sprite a pointer to the hero sprite it can keep @ all times &, when it sets the hero sprite to be grabbed, use the hero sprite’s pointer while updating to handle moving the hero & letting go.

In making the girder blocks, I did have to make a flatter slope than I had before. This gave me the ’scuse to finally stop screwing round & clean up the slope blocks, which I’ve mentioned before, were hackily copied & pasted from class to class. So these classes wouldn’t have to waste, like, a couple whole precious bytes out o’ the billions available, I made a single templated class with direction, steepness, & position within its slope ( since flatter slopes require mo’ blocks to form a complete slope ) as template arguments. The great thing ’bout this was that it not only cleaned the code, it made making the new flatter slope blocks ridiculously easy: I just had to quickly calculate some new #s to push into the template, & then it just worked perfectly. Turns out programming’s easier when you don’t do a hacky job o’ it.

Since the graphics are mostly reused, there wasn’t much to do there, & the girder & platform blocks were so simple, they took hardly any time to draw. In fact, I actually drew some fancy bridge blocks that I decided not to use till the very end o’ the level, preferring the plain building graphics ’stead. Using these familiar city graphics to replace the mushroom towers felt like a better parody than using some unfamiliar graphics. Plus, it allowed for layering towers o’er each other, like after the 1st pair o’ weight platforms.

Something I tried to emulate from the original Super Mario Bros. was making it so that while the weight platforms could help in certain ways, including getting gems & the hidden diamond, you wouldn’t have to wait for them to slowly move in order to just beat the level: if you play it right, you can hop straight from platform to platform in this level ( & in World 4-3 o’ Super Mario Bros. ) with minimal delay. Actually, I don’t know what happened, but somehow this level became easier to do quickly, as I easily got 18 seconds on my 1st try in this video, which took many tries before, which was why I set the time limit to 20 seconds. I should maybe change it to 18. However, I want some leeway, as this level can be kind o’ cheap with those randomly generated paper plane enemies.

In the process o’ making some o’ these code changes, I also made some other simple code refactoring. For instance, the same insight that led to turning the slope blocks into a templated class, probably from some C++ books I was reading, led me to realize that the Counter class, used in many places, could be a template.

I also finally got round to adding an autoformatter for text, such as the text that appears in message blocks. Before, to keep them formatted, I had to manually calculate where to put line breaks, as it would naturally just go to the next line when it ran to the end, e’en if ’twas in the middle o’ a word. Now, it runs the text through a function that checks if the letter @ the start o’ each line after the 1st is a space or line break, & if so, it eliminates it, if it’s a different character ( which means it’s a word that spans ’tween lines ), it goes backward till it finds a space & replaces that space with a line break so that the word spanning 2 lines starts @ the next line.

Here is a before & after shot that demonstrates this:

So for this message, the algorithm stops on the 1st letter o’ the 2nd line, sees it’s not a space or newline & goes backward till it reaches the next space, right before the “W” in “will”. It then replaces that space with a newline, causing the next letters, “will” to be printed on the 2nd line, as shown.

It’s probably not the most efficient algorithm, but that’s fine, since it only runs once @ the beginning o’ a level.

I hope to finally get round to other code refactorings, but I have to be conscious o’ my time, ’specially as I grow older & become e’er mo’ senile.

¿& who knows what the future holds?

This code is still sloppy as a hippo & probably won’t compile on your computer.

Posted in Boskeopolis Land, Programming