Soupy Sewers

@ 1st I had qualms ’bout the sloppy inconsistency o’ the sewer hole monster’s frames, but I’ve come to appreciate it in a Ren & Stimpy kind o’ way. It actually made me curious ’bout the prospect o’ an entire game animated that way.

I actually hadn’t lost interest, but was spending copious time on insignificant twiddling.

I rather radically refactored the block system, levels, & palette system so that they loaded JSON files automatically so that I don’t need to manually add them directly into the code. Unfortunately, due to the weird way RapidJSON handles objects, making it impossible for me to push its objects into other functions, this code is messy as hell. But a’least it’s all isolated & probably won’t need to be touched much. Meanwhile, the creation o’ levels, block types, & palettes is through clean JSON files.

I also finally split the block system into tilesets that vary by map ( ‘cept the added “universal” set which applies to every level ), though I had to simplify blocks so that they just took 16 x 16 graphics ‘stead o’ 4 8 x 8 graphics. The filesize saved through extra reuse o’ graphics wasn’t much, & wasn’t worth the tedium o’ redoing so many blocks.

I also changed the sprites so that I can now see what they are on Tiled maps. Tiled doesn’t allow you to have multiple tilesheets use the same #s, e’en if used for separate layers, & I unthinkingly made the sprites use 0 & onward, which the block types also use, since sprites & blocks use completely different lists. I changed it so that sprites start @ 401 & lengthened the tileset graphic files so that they & the universal tileset graphic add up to 400 blocks in Tiled. Then I just add the sprites tileset last & it handles 400+. I just need to hope that none o’ my tilesets need mo’ than 336 blocks ( 64 being taken for the universal set ).

None o’ this probably made any sense & probably sounds like a hungo’er mess.

Find sloppy source code @ GitHub

Warm Up:

I probably thought o’ the basic concept ’hind this level—survive a certain ’mount o’ time—before I e’en started this particular version o’ the project; but this particular implementation was made just this day. Other ideas I had were staying on ladders & avoiding Bullet-Bill equivalents; but this one looks much better, & is probably less clunky. Though it may sound rather shallow, aesthetics do make mo’ importance than some people give credit, & I feel the fiery theme o’ this level makes it a li’l less lame than just a “keep from dying for 30 seconds” level. Plus, I like having stories ’hind levels—in this case, somehow Autumn has ended up in a furnace & is being baked ’live.

Mo’ surprising, though I had so much trouble in practicing this level that I doubted I’d be able to record a winning run, I was able to do this well on my 1st try. I only missed 1 gem. Though these beams have quite a bit o’ leeway,—their hitboxes are a few pixels smaller than their graphics, & they only hurt you when they’re all the way on—it’s still quite easy to accidentally bump into 1 by a pixel or so when o’er-correcting movement on the conveyor belt. Worse, it can be easy to bump your head when jumping to the right side & fall to your death. I considered leaving mo’ space, but decided I liked the challenge. It’s not as if you need to jump o’er the hole, anyway, ’less you want to get a high gem score. E’en getting the diamond is pitifully easy when one considers that the game saves the diamond e’en if one dies. It’s truly only my anal-retentive obsession with having a good-looking video that made this level hard for me.

I’m still working on 2 cloud levels & have ideas for 2 other factory levels. Hopefully it won’t take too long to have something presentable from them. I also still have “Sawdust Crush” & “Hot Shop” to finish up so I can show those off.

Source code

& now for something completely different: a top-down maze level that blatantly rips off Pac-Man, but without the fancy voice clips o’ someone swearing whenever they die.

Like Pac-Man, there are 4 antagonists that chase you, in this case eyeballs, ’cause ’twas a convenient graphic I had lying round. They can sort o’ be distinguished by their shade—a limitation due to my insistence on 6-color monochrome palettes; however, this isn’t that useful, anyway, due to a twist I added: every 15 seconds, the eyeballs switch roles. So, to use Pac-Man terminology, imagine after 15 seconds Blinky starts acting like Pinky, Pinky starts acting like Inky, & so on. They don’t change their current position or appearance, just their behavior. They continue cycling down the types every 15 seconds, returning to their original type after 1 minute.

The eyeball chasers do act like the Pac-Man ghosts, with 3 out o’ 4 o’ them having AI based on ghost behavior. They target a certain tile & test each possible tile they can move to next to see which is closer to that target tile in terms o’ the distance based on a straight line. The top-left eye follows the player, like Blinky; the top-right aims for the tile 4 blocks in front o’ your player, sort o’¹ like Pinky; & the bottom-right eye aims for the player, ’less it’s 8 blocks nearby, in which case it aims for the bottom left corner, like Clyde. The bottom-left eye is the only exception: rather than the immensely obtuse method² Inky uses, it just aims for a random tile every tile it moves. Though part o’ me kind o’ liked the o’ercomplicated nature o’ Inky’s pattern, it requires knowing Blinky’s pattern; & in my game, it’s actually, I’ve just thought o’ a simple way I could do it, ne’er mind.

Truth told, I feel like I’ve ripped off Pac-Man too much. I wanted to add mo’ eyeballs with my own made-up patterns, since it seems like a fun exercise to try, but I felt that’d make the game too hard. Maybe I’ll change the Clyde equivalent, since its pattern is kind o’ dumb, anyway. 1 idea I had was a sort o’ smarter version o’ Blinky. As Birch notes, due Blinky’s distance check for tiles is simply a straight line that ignores solid blocks, there’s a chance it’ll take a less efficient route if the player is to 1 side o’ it but the quickest route is in the other direction. A smarter algorithm would involve using recursive tile searches throughout the whole maze to see which path that ends with the player takes the fewest tiles.

Other than the eyes shifting types & speeding up after 15 seconds, & the Blinky equivalent speeding up after a minute, these eyes’ AI is actually simpler than the original Pac-Man’s, with no “scatter” behavior, &, ’course, no power-pellet or fleeing behavior. This isn’t truly s’posed to be an exact copy o’ Pac-Man, &, if anything, could use a bit mo’ originality.

I suck @ Pac-Man, & as the video shows, I wasn’t able to beat it, e’en with 4 hearts in the corners o’ the maze. You’ll have to take me by my word that collecting all 669 gems beats the level. I’m thinking o’ having this be a bonus level, since it has a high reward o’ 66,900₧, which is mo’ than 3 times the max collectible in any other level. I thought ’bout making the maze smaller, which may ease the difficulty, but I kind o’ like the huge maze. Maybe I should just make ’nother maze level that’s smaller.

Reminder: this game’s sloppy source code can be found @ Github.

Also, I converted project from Code::Blocks to plain Make, since Code::Blocks has this tendency to crash randomly & I prefer the less cluttered interface o’ using text document programs & folders, rather than having the thin bar on the left all the time & having to scour it for the files I want.

The 1 downside—though, now that I think ’bout it, it’s pretty neat, actually—is that Make causes bizarre glitches sometimes when changing header files quite a lot & making without clearing out all the objects. I was lucky ’nough to get a video:

This isn’t a dire problem, since it can be solved simply by running “make clean” before it happens. It just wastes extra time, since I have to recompile the whole program afterward.

‘Cept I hardly changed the actual code.

What I have done is finally figure out how to sort o’ get Git working, & now have Boskeopolis Land‘s source code on GitHub, so the whole world can see how li’l I know what I’m doing.

I’ve probably been spending mo’ time updating my dumb Wario Land 3 fan site than working on the actual game.

& now there’s a video for “Golden Gear Solid”:

I’ve starkly changed the graphics. For the longest time I couldn’t decide what kind o’ theme I wanted this level to have. @ 1 point I came up with this background made up o’ a bunch o’ Tetris-shaped blocks, but then I came up with the idea o’ making it shadowy black, since people oft associate that with stealth. & since the eyeball guards didn’t really work as silhouettes, I changed them to weird abstract bots, since I thought they seemed mo’ mysterious, ‘specially as silhouettes.

Note that I had to add extra blocks for the diamond & message block, since the originals didn’t work well with this level’s palette.

& now I have a video for “Bough Down”:

I spruced up the graphics, including finally drawing the rope, giving the Pufferbees animation, & adding dark firs in the background. I wanted to do the last 1 to make the background feel a li’l less empty; but now I worry that the graphics may look too crowded, making things hard to see.

Also, I added the fir background to “Wasabi Woods”:

Here’s “Rooftop Rumble”:

I should point out that “Dagny” moves faster than Autumn, but her jumps are much weaker. As you can see, the trick to beating her is exploiting Autumn’s superior jumping abilities.

I also realized I’ve been forgetting to add the source code for the last few updates, so here:

Download Boskeopolis Land source code.

You’ll see that I finally organized everything now, rather than just throwing all the source files together & just throwing all the images into bin/Debug. This begged to happen, since I found out I now have well o’er 200 source files. & this shit isn’t e’en close to done.

It’s been a while since I talked ’bout the li’l game-development project, which, believe it or not, I am still working on. For example, I just spent the days trying to fix the mess I caused by stupidly refactoring my inventory code.

In fact, I just fiddled the whole day learning how to parse JSON files through RapidJSON. This allowed me to implement 2 features:

1. Saving, which is automatic, every time you return to the level select screen & collect a diamond. So, basically, anytime any saveable change happens.

   For those curious, the game currently saves total gems, level beaten, gem & time scores, & diamonds. I also plan to implement health upgrades, ’mong others (which is why, as you’ll see, Autumn’s max health is down to 2 now).

   I don’t know if I mentioned the diamonds yet. They’re just big items that act like DK coins in the Donkey Kong Country series. Like in that game, collecting them is permanent once you get it, whether you die or not. It e’en, as I just mentioned, saves immediately afterward, so if the game happened to crash a li’l afterward, you’d still keep it.

   I also changed to title screen to give a menu, allowing for a new save (o’erwrites save file ’pon next save, though not necessarily on using it) & loading. I’m still thinking ’bout how I’m going to implement multiple save files. Ideally, I’d have a menu allowing for as many files saved & opened as one’s file system could hold; but that’d probably require a menu that could access the user’s documents, & I have no idea how I would do that, ’specially in an OS-independent way.

   I started saving with JSON files, which were hilariously telegraphed & easy to edit so that one has perfect scores all round. But for reasons I can’t ’splain, I spent hours fiddling with writing binaries & shockingly found a way to do it & read it back correctly. I e’en found a way to compress booleans so that there are 8 bools in a single byte… for some reason. I don’t know—’twas interesting. ’Course, it still wouldn’t be too hard to edit the save file to get oneself a perfect save file (hint: change all the victory/diamond values to FF, all the gem scores & the total funds to 7F & all the time scores to 00).

   

   As you can see, I’m so great @ this game that I can get o’er 2 billion ₧ in every level—so much that it crowds out into the time scores.

   

   Sadly, this probably won’t become as famous as the “Konami Code.”

   

   E’en mo’ unfortunate: ’cause I’m a stodgy game developer, I fixed the gem-score o’erflow glitch, so that now you can only have a boring 99,999₧ max score.

   I did think ’bout fiddling with encryption; but honestly, it doesn’t matter, anyway.

2. Not particularly important from the player’s perspective, but now the program can directly read the level files spit out by Tiled in runtime, which means I no longer have to copy & paste arrays from JSON files every time I make a change to a level.

But screw that. Let’s talk ’bout the exciting news: video footage o’ “Blueberry Burroughs,” as well as “Wasabi Woods.” & “Frigid Frigates.”

I spruced things up a bit in preparation, which delayed things a bit. In addition to the minor changed, like the diamond, the Bad Apples now allowing you to bounce off them like in a true platformer, & the tacky low-res photo background in the sewer section, I added a fence background. Believe it or not, that required me to rewrite the background code so that it could handle non-repeating backgrounds so the fence wouldn’t repeat vertically.

& then there’s the constellation. 1st, note that it slowly scrolls ’long during the whole level, so that the moon is on the right side @ the beginning o’ the level & on the left by the end, rather than looping constantly as if there were many moons in the sky. It’s touches like these that ensure this game won’t be done ’fore I’m 80.

But worse: the constellation background is actually randomly generated when the level’s loaded. This required me to refactor the “background” class so that it could allow other types, such as this constellation type. Logically, this wasn’t hard, since background had a remarkably simple interface: other classes only interacted with it through the common update & render methods, so making a polymorphic system round them was simple. Now the classes are “MapLayer,” “MapLayerImage” for what was “Background,” & “MapLayerConstellation” for the custom constellation. If anything, the only headache was changing the instances in the Map classes vector to pointers to allow for polymorphism. I gave up on trying to get unique_ptrs to work & just stuck with shared_ptrs. ¿Who cares?

Believe it or not, the hard part o’ the constellation background itself was not the random-generator, which was easy, but figuring out how to get an array o’ tiles splayed ’cross the screen so that they scroll the right way when the camera moves. After a day or so, I figured out some combination o’ code from the block-generation code & the background code worked.

I don’t feel too bad ’bout doing all that for just this background in the 1st level, since the actual hard part will work for any tile-based background I may want to do. (Think o’ it like the block-based layer 2 in Super Mario World.)

But there’s a much cooler part o’ the video (which, surprisingly, took much less time): what’s being recorded in that video isn’t actually me playing the game. I did play that exact way once, & recorded the inputs every frame &, @ the end, printed those arrays o’ arrays in a file.

The way input is read for the player has been refactored for this. Rather than directly reading the Input class, the player sprite has an InputComponent, which decides how input’s read. For InputComponentPlayer, it’s based off Input’s button presses, like normal; but InputComponentSequence holds the big array I mentioned & feeds it out to the sprite for movement cues, rather than actual button presses.

This, actually, I think is similar to the way the recording & playback o’ inputs for Mario’s movement on the title screen o’ Super Mario World may’ve worked, for those familiar with Lunar Magic & Super Mario World hacking. ’Cept mine’s much mo’ stable, since the sequence is directly tied to the player sprite, which means that whenever the player’s paused, the sequence readout’s paused, too.

There were amusing bugs when I was developing these, mostly caused by an o’ersight I still need to fix: the SpriteSystem creates a new player sprite during every map transition. This is ’cause different maps may have different player sprites, & the sprite system doesn’t bother to check whether the sprite type doesn’t change ’tween maps. This obviously resets all its data, including the sequence readout & recordings. I kludged this simply by making these static.

The 2 glitches were caused by the recording & readout, respectively. @ 1st only the movements for the last map were saved, which I realized without e’en seeing the glitch happen, simply by the smallness o’ the output file. However, the funnier glitch was the readout 1, wherein I saw Autumn get stuck in a loop in the middle map, constantly jumping up & back down the rightmost sewer hole & running left & then back right, seemingly absentmindedly. @ 1st, I was befuddled by how the sequence seemed to go on fore’er. I don’t know why it took me so long to realize that the sequence was simply being recreated ’cause the sprite was, since ’twas caused by the same thing that caused the previous glitch that I fixed so recently.

I do need to see if I can recreate this glitch (should only require making the InputComponent no longer static) so I can record a video o’ it.

There are still some quirks that I can’t truly fix. 1st, since its recording & readout are static, you can only use them once per program run. Trying ’nother level will cause them to continue from after the last level’s end. Also, pausing has no effect on the sequence, which would actually be useful. What I mean is, if you pause while recording, wait any ’mount o’ time, & then unpause, the sequence won’t record the pause @ all: on playback, it’ll act as if the pause ne’er happened @ all & go immediately from before-pause to after-pause. This is ’cause pausing actually isn’t tied to the player sprite @ all, but the LevelState (which makes sense, since it’s not something the sprite’s doing, but a meta command). Lastly, exiting the message that pops up when the message block in “Blueberry Burroughs” is hit requires a human to close it, e’en on sequence-playback. ’Gain, closing messages isn’t controlled by the player sprite, but the created MessageState. In fact, while the message is up, the player sprite isn’t e’en being updated, since it’s back in the paused LevelState. Hence, how the game pauses. ’Gain, though, this doesn’t affect the sequence, since it’s paused during the message as well.

Anyway, this input-recording business isn’t just for fun. As I mentioned earlier, I wanted to have “Rooftop Rumble” actually have a character hopping ’long the rooftops with you in a race toward the end, also being able to hurt you if she touched you. I settled for a ghost that simply floated forward, impervious to the level; but now, I should have no trouble getting an actual moving racer character as I originally envisioned.

I actually expected to have these videos & this article up sooner, if not for a bunch o’ hitches that got in the way—most o’ which took hours to figure out, but were fixed by simple changes (& were, correspondingly, caused by simple o’ersights).

The 1st was figuring out how to record decent video in the 1st place. I spent days recording o’er 2 dozen videos with different video software @ different resolutions. To allow me to configure screen sizes & modes (full-screen vs. windowed) & saving (’cause writing to files causes lag) without having the memory-wasting IDE open I e’en made up some arguments I can put into the console & added code to the game to read these through the main function’s argv array & adjust based on them on startup.

@ 1st, I could get 2 types o’ videos: small recordings that moved smoothly, but I couldn’t figure out how to not be resized blurrily in YouTube, & videos that were sharp, but had flickering all o’er the place. After fiddling with both problems, I found out some vsync flag I put in the renderer @ start-up caused the flickering. Removing it made recording videos work well.

After that & the pointless random constellation, I should’ve recorded the videos; but for some reason, I had the genius idea to refactor the inventory code to split its integrals from the specific window dressing for the level-select & level states (the different UIs o’ those different screens), possibly in preparation for the o’erworld state. I do think the inventory’s cleaner & easier to work with; but damn was this a pain to do.

Worse, it introduced a game-crashing error that seemed erratic & all o’er the place. After a while, I was able to pin-point it to spawning most sprites in the 8th Y-position o’ “Wasabi Woods.” I’m not kidding: it just-so-happened to affect that level as I wanted to record it & in such seemingly specific places. While most sprites caused the program to crash immediately while entering the level, including the spiky-fruit that was s’posed to be there, the rope & cracking ice cubes worked fine. The hydrant would only cause a crash ’pon waking up—according to my debugger, caused by a method call in its timer. Most o’ the time my debugger wouldn’t give me any info beyond ?s.

This unpredictable behavior could be caused by a simple error I made, which seemed to have nothing to do with this level or these precise values, but had to do with the code I changed for the refactoring, as I thought it should: in simplifying the inventory code, I pushed out its LevelSelect-specific code into LevelSelect, since it didn’t have much, anyway. But I did still update stuff specific to inventory. In moving stuff round, I put the inventory-updating call @ the end o’ the LevelSelect update method. Unfortunately, this violated a rule I made for myself that I apparently keep forgetting: it went after the code that handled changing game states, which meant that the game was deleting LevelSelectState & initializing LevelState, & then somehow returning to the update method in LevelSelectState & updating an inventory that shouldn’t exist. Logically, the game should’ve crashed whenever I entered a level, but for some reason it only broke ’pon entering 1 specific level with most kinds o’ sprites in the 8th block y-position on the left half o’ the screen.

There was also some crashing & slowdown in the cart & stealth levels, but I fixed that earlier: turned out I was testing block interaction for (& trying to render, though that didn’t cause any slowdown, surprisingly) sprites that weren’t on-screen; & since those levels had a lot o’ sprites, ’twas memory-intensive. Now that’s fixed & the levels work normally.

I’m sick o’ all these programming distractions & will be focusing mo’ on designing actual levels & art for a while:

I think “Soupy Sewers” is done ’nough that I can show it off, so expect a video for that soon, once I clean it up a bit. The level still has quirks—mainly the end, which has a truly lame section. Also, a wacky glitch with an enemy. Maybe that’ll be funny to show off.

I also hope to finally get round to drawing a cart sprite so I can show off “Hot Shop,” which is pretty much done, ’cept for the art, which is still quite rough.

I also have 2 sky levels that are still in alpha stages: 1 has you as an owl who can flutter all round, & will involve navigating a bramble maze; the other is a coin heaven where you have to collect all the gems to win. In that level you ride a moving cloud platform, & the level loops infinitely.

I’ve also been thinking ’bout what to do ’bout a map screen. I have decided, a’least, that it’s going to be a free-moving o’erworld (think like Super Mario 3D World, as opposed to the locked paths o’ Super Mario World or the Donkey Kong Country games). I don’t remember if I mentioned it yet, but 1 idea I had was to have an o’erworld like a Zelda game, but with 2D platformer levels ’stead o’ dungeons; but part o’ me thinks that’ll only add too much complexity for a novice game, & that perhaps I should set that aside for a later project, when I have mo’ experience. Plus, it may get in the way o’ the “Spiral” idea I know I mentioned already.

It’s not so much that I haven’t been working on my stupid project since my last post,–quite contrarily, I’ve been working on it mo’ than mo’ important work–but that I haven’t felt like there was much to show ’bout it. & I think talking ’bout refactoring out sprite movement code into “Movement Components” to separate gravity-based sprite movement from floating sprites & swimming sprites would be as interesting.

But I did make this nifty ice level that I wanted to show off.

1st, we have penguin enemies that move back & forth, slowing to a skid as they turn. I e’en made it so that sliding into them (which still just uses Autumn’s ducking sprite) kills them.

That reminds me: I finally got it so that you hop off enemies when you land on them, ‘stead o’ some flaccid bounce that has no air. This was done by adding some bounce function to the grounded movement component & making it so that holding the jump button down while bouncing can extend it, but it can only be started by other means (landing on enemy heads so far).

Next we have these big ice cubes that fall into water, stay floating on water, & start moving if you get on them. 2 ice cubes hitting each other causes them to turn in opposite directions, & hitting walls causes them to sink into the water.

Also, the water hurts Autumn from its icy coldness.

Lastly, unlike some other moving platform sprites that I’m not sure I e’en mentioned programming in yet, these ice cubes don’t keep Autumn’s X position with them, meaning that they can slip past Autumn, forcing the player to sort o’ fiddle with the controls to keep up with the ice cube. A li’l bit o’ challenge that… isn’t truly all that challenge.

Finally, I have smaller ice blocks that begin to shatter once you step on them. I also made them crack ‘pon hitting them from below, & then shatter when hit a 2nd time from below, but didn’t find a place to use them in this level. I’ve been wary ’bout avoiding making levels feel too big or fillery by trying to limit them to only a few, select, quick elements. As I was constructing this level, I worried that it may be too long, but ‘pon testing it I found that the fact that much o’ the level is large plots o’ land for breaks ‘tween water sections & the fact that your slippery movement makes you go faster, the level feels actually quite brisk.

I’m somewhat glad o’ how the graphics in this level turned out–though I fear the background may be a bit too similar to the background to Super Mario Bros. 3‘s ice levels. Then ‘gain, I think a few Kirby games used the same simple pattern. The ice blocks are also inspired by Super Mario Bros. 3, & the main ground is inspired by Kirby’s Adventure, but I think I differentiated them ‘nough. The only similarity ‘tween the grounds is that they both have shiny ice tops: while Kirby’s had rigid triangular shapes, mine has mo’ melty dripping lines. My ice blocks also have mo’ o’ the grungy dirt pixel shading I use for my other graphics (see the city graphics for particular examples) & have a different bevel on the right side.

Look, it’s hard to be particularly different when working in only 16 x 16 pixels. In such a case, these seemingly slight differences make a big difference–‘specially when you consider how oft commercial NES games seemed to ripoff other games. You have no idea how many times I see those Legend of Zelda stairs in other games.

I would talk ’bout a cart level I’d been working on before & a sewer level I’m working on, but I want to draw the cart sprite so the screenshots don’t show a tacky black square for the player for the former, & want to finish the latter, since it’s now mostly long stretches o’ water with few dangers.

I think I’ll focus less on “what I’ve done since last update” & mo’ on particular levels I’ve developed beyond an alpha stage. Which means, don’t expect ‘nother update till next year or so.

I promised to neglect keeping up on these, & I kept my promise.

Most o’ what I’ve done was mo’ design than programming, but it did involve programming in quite a bit o’ custom sprites.

Wasabi Woods

Planned to be the 1st forest level & 2nd level o’erall. For it I created “Bad Apple” enemies, which are basically just Goombas that bop off screen when you jump on them & still have no animation.

A mo’ interesting sprite I use is some spike fruit that start falling if you get near them horizontally & respawn after falling offscreen.

Sawdust Crush

Finished this level. 1 programming quirk: to keep players from being able to jump o’er walls, I had to make the camera go much higher; however, ’cause the camera isn’t s’posed to scroll vertically, I included camera-lock variables to maps which prevents the camera from scrolling past that variable (camera’s y_ variable going greater than the map’s top_limit_).

Desert Dare

A joke level, using mostly graphics I made for some other sprite comic. If your character moves in any way, you lose.

I wanted to program it so that it tested whether the protagonist’s is_moving_ is true, but found it impossible to keep is_moving_ from being set to true a’least once before testing, & found adding a timer to the goal to be cumbersome when there was a simple solution to just test for input presses.

Rooftop Rumble

You may recognize this as “Skyscraper Caper.” I plan to have this be the final city level, I think.

¿Remember when I said I wanted this to be the player racing some other sprite ’stead o’ racing gainst a dumb clock, but found creating a sprite that can jump & run with good timing too complicated? I found a balance, inspired by Super Mario Bros. Deluxe: the player races gainst a ghost who can fly through everything to the goal.

Logically, I should probably check for the ghost to touch the goal block, but I was lazy, & just checked for the ghost to pass an x value that happens to be where I placed the goal.

Speaking o’ laziness, I still haven’t drawn a ghost sprite, & worse, stole 1 directly from Super Mario Bros. Deluxe. Obviously I don’t plan to keep this bit o’ copyright infringement, if it e’er reaches any final form.

Golden Gear Solid

I don’t know what theme I plan to have this in yet, but due to its length & difficulty,—every hit is an instant-kill—it’ll probably be near the end. I actually kinda worry that this level might be too frustrating: I fear it might require too much possibly-unintuitive camera finagling or knowing subtle, e’en-mo’-unintuitive, facts o’ how the level’s rules work. There’s 1 point, for instance, wherein one’s safe if one stands still, but if one falls down the next hole while the guard is looking out, one will be caught (as the rules state in the info box @ the beginning, guards can see mo’ high up if you’re in the air, to make it harder to just jump o’er guards). There’s ’nother part where you’re just s’posed to follow some gems into an alcove a let a guard ’bove you pass o’er you, which actually has no difficulty whatsoe’er, which is the goal; but if the player jumps up there, they’ll get caught before they e’en see the guard. They probably wouldn’t e’er get hit ’gain; but it’s still a possibly-frustrating piece o’ accidental trial-&-error. Also, I feel having to ’splain this level’s rules in a word dump @ the beginning probably means this level’s gimmick might be too complicated for it’s own good, ’specially with instant-death fails. It feels like a recipe for “scrappy mecahnic.”

Then ’gain, ¿what’s a good platformer without just 1 “that one level” that everyone dreads having to beat to get back to the fun levels? After all, if Donkey Kong Country 2 can still be a classic with “Windy Well,”¹ ¿why can’t I include my own?

Believe it or not, I figured out how to update the guard sprite so that it can’t see past solid blocks. All I had to do was add a method to the SpriteSystem class to check if there are any blocks within a given set o’ coordinates—the familiar SDL_Rect coordinates, x, y, width, & height. Then there was the problem wherein the guards were blocked by gems, which was solved by saving the block type ID into each block & testing for the block being having certain ID. There’s still a quirk wherein the guards won’t see the player ’less the player’s completely out from ’hind blocks, e’en if only the tip o’ their feet is ’hind blocks, but this gives the player leeway, & it’s not as if being able to jump mo’ than one’s height is realistic, either.

I also added extra camera controls to scroll the camera upward & downward without having to duck or look up, so you can scroll when on the stairs, which makes the stairs section much easier. Having the camera operate on WASD controls feels much mo’ natural than having “A” & “S” arbitrarily be left & right, anyway.

Bough Down

The last level I finished. I plan to have this be the 2nd forest level.

This, has 3 sprites: branches that fall ’pon landing on them, a rope that starts moving horizontally once you grab onto it, & bees. The 1st 2 use a different respawning code that I should probably apply to all non-killed sprites: they respawn, but only if their current & original positions are off-screen (the latter to prevent them from suddenly popping back into view).

The bees actually have 4 forms: the 1st just floats where it’s placed, buzzing round erratically; 1 moves right & left; ’nother moves up & down; & the final flies in a circle. I was surprised how simple the final 1 was to program, thanks to the power o’ simple math (which I didn’t know till recently, since I have no formal trigonometry education).

Technically, I’m not finished. It should be obvious that the “rope” sprite’s art isn’t finished–as in, it’s currently just a black rectangle. But I also thought ’bout extending the final bee section, since I still think it’s a bit too short & too easy.

Level Organization

I don’t know if I mentioned yet the level layout scheme I’m planning. It’s actually an idea I originally planned for a Super Mario World rom hack years ago, which I codenamed “Spiral.” The gimmick is that rather than splitting the game into worlds o’ consistent themes—forest world followed by desert world, & so on—the game cycles through level themes, with each cycle being the equivalent o’ a world. Hence why I have an early-game city level & a late-game city level planned. The main inspiration was the Super Nintendo & Sega Genesis Cool Spot, which had an interesting gimmick wherein it’d cycle through level themes till the middle o’ the game, & then cycle backward from those themes till the end. Thus, the beach theme is used for the 1st & last level, the pier theme is used for the 2nd & penultimate levels, & so on.

The Future

A few levels I’m working on:

Minty Mines

Planned to be the 1st-cycle mine level & the 3rd level o’erall. Only idea I have so far is that I want it to be ’bout finding the key & then returning to the start, where the chest is. I want it to be a bit mo’ like exploration than “Wasabi Woods,” but can’t think o’ much to make it interesting.

The Minus Touch

The 1 where if you collect any gems, you fail. Planned to be an end-game mine level. Still not sure what I want to do with it, in terms o’ actual puzzles, other than that I want the # o’ gems you have to dodge to increase, till the end, where you’re mostly surrounded by gems.

Snow-themed levels

I made this nifty background using a photo I took o’ some line o’ trees a few blocks from my house when it snowed a few weeks ago:

My only worry is that the background might be so detailed—& yet so pixelated, due to my arbitrary color limits—that it might be hard to see things in it, which may detract from gameplay. When I was 1st working on it, I actually also made some trees using ’nother photo, ’bout thought it might be too cluttered. Also, I couldn’t get rid o’ some artifacts round the trees, making them look ugly in front o’ any other background.

I also programmed in slippery controls, which go into effect for any map with a slippery_ flag turned on.

I had a few ideas for icy levels, such as an icy cave level & a level full o’ floating ice bergs wherein touching the ice-cold water is instant death. I also thought the levels where your character runs forward regardless o’ what you do would work well with this theme, since it could be ’splained with the icy floor. However, I also wanted to change the death-on-touching-a-wall thing so that you could jump up after upward slopes; but that isn’t in my games physics for slopes yet.

’Nother idea I had was to change snow physics so that it’d be slower & mo’ plodding, as opposed to icy floors, which would be slippery, based on my experience having to walk in snow vs. icy roads while going to the store & such.

Bonus

As an extra, as I was cleaning my room ’cause my fascist mom told me I had to or no mo’ nutty bars after dinner to find some lost library books, I found some ol’ papers I’d made a year or so ago during my lunch break @ work while masturbating to photos o’ sexy cascade mountains & firs. Wait, ¿which did I cross out ’gain?

1st we have some simple sketches o’ how I planned Autumn to move ’bout (Ignore my French verb practice). You can see 2 differences here than what I have so far: Autumn’s proposed ability to punch, & the addition o’ Edgar as ’nother possible character, who has a shorter hop, but can float (so, essentially, Autumn would be like Luigi & Edgar like Peach in Super Mario Bros. 2²).

I probably won’t be implementing any o’ these. Honestly, I like the simplicity o’ the controls currently (which is already hampered by the camera controls), & find the punch is unnecessary, since jumping on enemies is sufficient, & feels mo’ natural than stopping to punch, & keeps gameplay focused. Actually, @ 1 point I planned on not letting you kill enemies @ all, but thought making your character that impotent made it feel a li’l less fun.

As for the different characters, that’d require me to redesign the levels I’ve done to keep them balanced (right now one needs to be able to jump as high as Autumn to reach some platforms). Plus, keeping characters balanced so that none seem useless would be hard. Already it seems as if Edgar would be a superior character in this case—which doesn’t e’en fit within the source material.

Beta Blueberry Burroughs

Here we see the original plan for the 1st level. I should point out that these maps were ne’er drawn to be perfect representations o’ what I wanted, but just quick scribbles o’ ideas.

While none o’ the others were actually technically used as references for levels, since I didn’t find these till a few days ago, this 1 might’ve, since I faintly remember an earlier form o’ this level already being designed in Tiled from a year ago or so—including the ending, which isn’t in this paper plan. This is certainly the closest o’ the paper maps to what I have now: as you can see by the solid wall requiring hops ’long 2 roofs; the short hopping sections o’er spikes using hydrants; the short spike pit ’tween 2 roofs with a ! sign o’er it; & the sewer warp to get from 1 half to a li’l past the other, with a pattern o’ gems hid ’hind it, I already had many o’ the same ideas earlier. The main difference ’tween my current & the final was that neither this paper plan, nor the Tiled map I made a while ago had the hidden gems just left o’ the starting point; that was a recent addition. (Also, in general, I changed a lot o’ the gems round since adding the brighter & darker gems & changing the requirement from 50 gems to 10,000 ₧—round 70 or so gems.)

Extra trivia: I had the name “Blueberry Burroughs” in mind for a while, as well.

Alpha Wasabi Woods

& here we see that the “Wasabi Woods” early map is much different from what I have now—not to mention much rougher. All that’s truly similar is that I always planned for there to be the “Bad Apple” enemies & the falling spiky fruit. I also always planned for there to be a final gauntlet with a long row o’ falling spiky fruit.

There was also an early Tiled map, but ’twas unfinished up to round where the trees appeared—which made sense, since I’d ne’er programmed falling spike fruit before. But as we can see comparing that beginning to this paper map, they differed as well: I apparently planned to have far fewer bottomless pits &, in general, a much easier level. Part o’ me does think the current version might be a bit too hard, actually, so I may moderate it a bit—though not this much.

Alpha Minty Mines

Neither the original nor my current “Minty Mines” are finished, & they share almost nothing. While my current version has a key-&-chest gimmick ripped off from Wario Land 3, the early version seems to have some “collect the stars” gimmick. & while the current version is shaping up to be a mo’ square-shaped circle back to the start, this earlier version is much mo’ horizontal, starting @ the left & going mostly-straight rightward.