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.

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

While looking up webliterature I bychance found an Animal Farm quiz & for some reason tried it real quick. I’m glad I did.

For instance, we start with this excellent math wherein a perfect 7 out o’ 7 transforms into a mere 88%:

I wondered how one could make such a simple math mistake on a computer program till I noticed the average score & saw “of 8”, which indicates that this quiz probably used to have 8 answers & the developer forgot to change the max used for the % calculation for “Your Score” ( which means the code for calculating that is different from what is used for the average score calculation & that the max # is manually put in everywhere, which is to say, bad programming ).

& then we have totally correct answers, like that Snowball represents Vladimir Lenin.

¿Does everyone remember when Stalin chased Lenin out o’ Russia? I can only imagine that Stalin’s attempts to erase Trotsky from history just worked so well that the geniuses who made this quiz forgot he existed.

& then we have the best answers to any multiple-choice question:

You know a quiz is good when 1 o’ its questions has 2 choices for answers: guy & same guy with misspelled name.

I also love how the use o’ the word “who” implies that Karl Marx’s writings & his evil twin ( ¿or is he the good twin? ) “Carl Marxx”’s mind are independent living organisms. I think I saw that in a Red-Scare-era flick, ¡Attack o’ the Living Brain o’ Carl Marxx!. It’s completely true, though: I always have to remember to keep my copy o’ Das Kapital fed & watered every day.