Man, fuck Zed Shaw; you want a true hardcore way to learn Ruby, you gotta read Why’s (Poignant) guide to Ruby:
No, I didn’t make this up. & for some reason, somebody linked this as a recommended guide on the official Ruby documentation.
The mo’ I learn ’bout Ruby, the mo’ frightened I become.
‘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:
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.
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?
Compare & compare.
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.
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.
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_).
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.
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.
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,”1 ¿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.
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.
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.
A few levels I’m working on:
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 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.
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.
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. 22).
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.
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.
& 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.
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.
Nothing too radical today: mostly just a bunch o’ gimmicks I added in.
Nothing exciting: just merged the SpriteMovement class into the Sprite class, since I found the difference ’tween the 2 too hard to find. Also, SpriteMovement oft had to manipulate a lot o’ Sprite’s stuff, requiring me to make too much public.
Now there’s a li’l checkmark next to levels beaten, as well as the highest gem score & lowest time ’pon beating a level.
The rightward slope’s a bit buggy, but the left slopes work perfectly. They e’en slow you down as you go up slopes & allow you to slide down them by pressing down. All that’s needed, other than fixing the right slopes, is to change Autumn’s graphics ’pon sliding downward & a way to kill enemies ’pon sliding into them.
Sloped ground is split into 2 blocks: “low” & “high.” You can see the pattern here:
As mentioned earlier, the backgrounds only tiled horizontally before. Adding vertical tiling was just as simple as I expected: simply had to pull the horizontal code into a separate method, & then copy that code & replace all the horizontal variables with vertical variables, replacing the graphic-drawing functions with calls to the renderX function, pushing in sy, dy, & h.
I also added in a way to have animated backgrounds—though this is limited. Basically, there’s an extra parameter to the constructor that allows one to change the # o’ frames. In this case, the width given to the constructor is s’posed to be the width o’ a frame, & for the 1st “cycle” o’ the renderX function, ( width_ * current_frame_ ) is added to sx & subtracted from right.
Finally, I added “foregrounds” to the map class, which is just ’nother vector o’ Background objects, ’cept these are drawn ’bove all o’ the blocks & sprites (though not the UI). This & the animated background are used in a new level I’m starting called “The Streets o’ Storms” to make falling rain appear in front o’ everything.
The rain animation isn’t particularly good; but it’s passable for now.
As a bonus, this level has the light-gray background flash white every so oft. This was done by setting the bg_ variable in the palette to 7, which is ’bove the limit, & changing the code that disallows colors ’bove the range to make colors ’bove the range use some custom code. Right now this extra code is hard-coded to use the 3rd & 1st (white) colors for the background, which is fine for now, since it’s just a rare extra used for only 1 level so far. If I need to use this in any other level, I can always change it. I did consider doing some complex thing where the # ’bove the limit determines the 2 colors (7-12 has colors 1 & 1-6, 13-18 has colors 2 & 1-6, & so on…), but for now I’ll stick to the “You Ain’t Gonna Need It” principles. It’s not as if it’d be harder to implement later than it would be to implement it now.
“Sawdust Crush” is a horizontal version o’ the Donkey Kong Country 3 level, “Ripsaw Rage,” but without the stupid bullshit where you can’t scroll too far ’head, which I ne’er liked in autoscrollers1. ¿What’s keeping me back? ¿The great Camera God? The gimmick is entirely programmed in the saw’s sprite code: it sets itself a flag so that it doesn’t fall, constantly moves rightward, & automatically adjusts the camera if its x coordinate ends up lower than the saw’s so that the saw pushes the camera forward if the player lags too far ’hind. This & the way the saw acts solid if the player runs into it prevents the player from letting the saw pass them. Finally, the saw hurts the player ’pon touch & automatically kills the player if it finds that the player has collided into something solid to the right ’pon touch—essentially squishing them ’tween it & a block.
(A li’l detail I noticed: I should probably make it so that the player’s hearts in the UI automatically disappear ’pon death.)
“Windy Woods” is a short demo o’ the wind mechanic, which simply subtracts a certain # from the player’s vx_ every frame, making it hard to move forward & making movement backward go extra quickly. Not hard @ all.
This is like the cannon levels in New Super Mario Bros. 2: Autumn constantly runs forward no matter what the player presses & the player needs to jump o’er any obstacles. In levels with this goal, if the game detects the player colliding with a wall to the right, she’s automatically killed.
’Nother simple 1, though not used in e’en a demo level yet: the player starts with 500₧ & loses 25 every frame or so. If it reaches 0, she dies. Thus, the player must repeatedly collect gems to stay ’live.
This is almost the opposite: if Autumn gets any money @ all, she automatically dies.
There’s also a new enemy that paces left & right & can kill the player just by looking @ it. As this name implies, the goal is to sneak past them without being seen. My only problem is that I can’t figure out how to keep them from looking past solid objects. Right now my main plan is to limit their eyesight to 8 blocks & just ne’er allow the player to be less than 8 blocks in front o’ a guard from ’hind a wall.
I’ll try to focus a li’l mo’ on finishing some levels, though I did also want to make some moving platform sprites, & maybe a bouncy block like the note blocks in Mario games.
There is this odd glitch that pops up sometimes: sometimes immediately ’pon entering a level, one gets the “¡Failed!” screen, but the game treats it as if one beat the level, giving one the checkmark & a high score o’ 0 gems & seconds. I still have no idea why this happens.
It’s been so long (a couple days) that I forgot what I’d accomplished last time I wrote.
’Stead o’ relying on dumb enums, block types now have 2 corresponding lists: “components” & “conditions”—numerous simple pieces that can be combined into complex block behavior. Components affect what the block does, the corresponding conditions affect what must be true for that affect to happen. Take, for instance, a heart block, which 1, heals, & 2, disappears, both on the 2 conditions that they are touched & touched by the hero sprite. Contrast this with a heart block, which is, 1, solid, & 2, heals; but whereas the 1st action happens simply by being touched, the latter only happens ’pon colliding with it from the bottom.
This allows me to reuse simple behavior oft used in different ways—touching a block, solidity, hitting it from below, disappearing ’pon 1 use—without having to copy & paste too much.
Also, as the “Wasabi Woods” screenshot shows, I added a “priority” flag to graphics, which specify which parts o’ blocks should be drawn o’er the player. This is done simply by drawing blocks onto the screen before & after sprites, drawing those without the priority flag 1st & those with it on afterward.
Level names are gotten from some dumb function in the Level class that spits out a string given a certain level ID (which matches the ID that one goes to ’pon selecting a string) based on a super dumb switch statement. Sorry.
’Course, the reason I’d want a level-select screen is that I’ve added 3 mo’ “levels.” I put that word in quotation marks, since none o’ them are truly finished. Technically they’re all beatable, but only Wasabi Woods is a serious level—& e’en it’s missing sprites. It’s probably next to be finished. Meanwhile, “Skyscraper Caper” is halfway done, & “Soupy Sewers” isn’t e’en a real level, but a way I planned to test vertical scrolling for backgrounds, which I haven’t e’en gotten to yet—in fact, that level, ironically, is the only 1 without a background image.
Look @ that amazing cut-off. This’ll ne’er be accepted @ SMW Central.
Speaking o’ which…
As “Wasabi Woods,” shows, multiple background images can be layered. They automatically tile horizontally & can have parallax scrolling o’ multiple speed levels, which “Wasabi Woods” uses for its 2 backgrounds. This was a pain, as I kept getting the math wrong; but after failing to sleep on Christmas Eve night, I was struck by inspiration. Unfortunately, I can’t actually remember what the math flaw was.
Here’s the code:
void Background::render( Graphics& graphics, Camera& camera )
{
if ( texture_ >= 0 && texture_ < Graphics::SpriteSheet::LIMIT )
{
int sl = offset_x_ + ( (int)( camera.x() * scroll_speed_x_ ) % width_ );
int dl = 0;
int right = std::min( width_ - sl, camera.widthPixels() );
int far_right = 0;
SDL_Rect dest = { dl, 0, right, camera.heightPixels() };
SDL_Rect source = { sl, 0, right, camera.heightPixels() };
graphics.renderObject( texture_, source, dest );
while ( far_right < camera.widthPixels() )
{
far_right += right;
dl += right;
right = std::min( width_, camera.widthPixels() - dl );
dest = { dl, 0, right, camera.heightPixels() };
source = { 0, 0, right, camera.heightPixels() };
graphics.renderObject( texture_, source, dest );
}
}
};
The vital issue is the difference ’tween the source & destination, & how these 2 differences affect how things are drawn. The destination determines where the graphic is drawn, the source from where in the graphical file. Thus, we start by looking for how the left size o’ the source, “sx” here, should change. We know for a fact that we want the background to span from the far left side to the far right side, regardless o’ where one is in the level; the question is what part o’ the image is on that far left side. You’ll notice that the 2 right variables have no mention o’ source & destination; & as you’ll notice below, it’s ’cause they both turn out to have the same right values, which is either the end o’ the graphical file (the width o’ the graphical file – where we started, sx), or the end o’ the level width (the width o’ the screen – where we’re starting, which in this case is 0, thus making it just the width o’ the screen), depending on which is smaller. There’s no reason to go past the width o’ the screen, & to draw a wider destination than source width will stretch the graphic, which is hideous. If we hit the latter, then we can stop, since there’s no mo’ that needs to be drawn; but if we hit the former, then we go through this while procedure till we finally do, saving our building right variable in the “far_right”1 variable, while placing the right variable o’ the previous cycle as the current left—logically, we start out where we left off. Obviously we’re drawing just after where we’d drawn before, since we’re building the illusion o’ a continuous backdrop; meanwhile, we always start our source now @ 0; as mentioned, we stop @ either the end o’ the source, @ which point we want to restart @ 0, or we stop @ the end o’ the screen, @ which point we quit. Meanwhile, we get our new right based on the same as before,—either the end o’ the source or the end o’ the screen, depending on which is smaller—& continue the cycle till the far right = the screen width2, @ which point we’ve reached the end o’ the screen.
When I was 1st figuring this out, I drew a graph to help see this—though now it’s probably e’en mo’ incomprehensible than the word vomit I spewed earlier.
@ the top you’ll see my plans for sprite collision detection, & to the left, the edge o’ some dumb haiku.
I still haven’t finished doing this vertically. Hopefully, that won’t be too complicated to add: should just be a copy o’ the horizontal version, just used with y & height variables & an extra loop layer.
A funds total, which shows on the level-select screen & is increased by whatever money you have ’pon beating a level.
Speaking o’ funds, they’ve been changed from just “gems” in the inventory to ₧, which fits better with Boskeopolis’s world & fits better with the video-game parody aspect o’ that world’s currency, & each regular gem gives 100, with a brighter & darker gem added, which give 250 & 500, respectively (thanks to the new block component system, I only had to change a # plugged into the component added to each block). Using these, I revamped the 1st level, increasing the money requirement to 10,000 (I also added an auto-comma function for #s converted into text, which is used in the message that appears in front o’ the 1st level, regardless o’ how one changes the funds requirement).
I also added a nifty li’l detail wherein the ₧ counter in the inventory spins up ’pon gaining ₧, rather than automatically jumping up to its new value, using a technique from Super Mario 64 that this video shows off, wherein one separates the actual funds # & the funds shown on the inventory screen, & have the game check every frame if the funds shown is less than actual funds & have it increase by a small # if so. The 1 difference is that my game doesn’t have the glitches & o’ersights Super Mario 64 does, ’cause I focus mo’ on that anal shit mo’ than actually making mo’ than 1 complete level.
This is the kind o’ useless trinket that keeps me from making real levels. Now, in every level, @ the bottom o’ the UI scrolls random strings o’ text. They’re inspired by the news tickers in SimCity 30003. In fact, the message ’bout Kitty Kibble shortages was taken straight out o’ SimCity 3000.
One can also see that there’s a clock added to the level UI, which counts up in most levels, ending @ 9:59 (which no player should e’er reach, considering how small these levels will be). While this clock is useless in most levels, in “Skyscraper Caper” it counts down & causes the player to fail if it reaches 0.
¡Finally the 1st enemy! This enemy disguises itself as 1 o’ the hydrant blocks you’ve probably seen in other screenshots, only to blink ’wake when the player gets close to it & starts bouncing toward the player, hurting her ’pon touch, ’course.
This is the place where the problems o’ components came ’bout: namely, that any data specific to specific components (such as the Hydrant movement component) can’t be used by other parts, such as the graphics component or other sprite movement components (such as the player’s) ’pon interaction, ’cause the nature o’ the polymorphism that the generic sprite’s ownership o’ these components makes it so that these other things can’t be guaranteed to get a Hydrant component, simply some child o’ the abstract “MovementComponent” pointer.
This is a big deal ’cause the Hydrant sprite has 2 forms: @ 1st, when it’s indistinguishable from a hydrant, & when it’s ’wake & dangerous. To ensure that the enemy only hurts the player when it’s ’wakened, I had to put the damage code in its movement component, which wasn’t too bad; but I can’t get the player to interact with it like a block, ’cause that relies on code in the collision object output by the collision function that runs automatically by interaction in the player’s interaction code, which is different from the enemy’s. I actually tried this with the collision object in the enemy’s interaction function, only for the player to strangely get sucked into the enemy, till I finally realized the vital difference ’tween the player’s collision with the enemy & the enemy’s collision with the player, & how this affects the overlap values. Also, I had to put the hydrant’s graphics code in its movement code, since its graphics also react to its wakening, which makes its graphics component do nothing but decide what graphic file it uses—which could already be done in the constructor o’ the parent SpriteGraphics class, meaning that the HydrantGraphics class is redundant & that the only reason I haven’t replaced it with a regular SpriteGraphics object is that I can’t be bothered & I feel I may want the HydrantGraphics class for later.
It e’en comes with automatic line-changing, as seen, though it doesn’t come with any nifty auto-hyphening or any other way to keep words from awkwardly splaying out halfway onto the next line. There are apparently ways to do that, as some SNES RPGs used that kind o’ technology, but it sounds too complicated to bother with now—’specially when this message box has only been used once so far. Maybe when I’ve completed like 5 levels a’least.
(Note: Hilariously, I only just noticed while looking @ the screenshot I took that the message block dips down into the UI. Oops.)
I mainly want to work on levels & sprites now. Hopefully, I’ll finish “Wasabi Woods” & “Skyscraper Caper” soon. The problem is, most o’ the cool ideas I have require a lot o’ extra coding. For instance, for the “Skyscraper Caper” level I actually wanted have ’nother character, controlled by AI, running through the level, & the idea was that you had to beat her to the end (touching her would probably hurt you). However, I don’t think I have the capabilities to do the kind o’ sophisticated AI that could make ’nother player move through this level full o’ holes without falling off & make it look like natural gameplay.
2 other level ideas that should be mo’ manageable are a level wherein the player has to avoid being seen by guards & a level covered in gold, where touching any o’ the gold causes the player to fail. This latter level will probably be near the end, since it’ll probably be relatively hard.
