The Mezunian

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

Boskeopolis Land: Let’s Code a Crappy 2D Platformer Like Millions o’ Other People on the Internet & Lose Interest & Give Up Only a Few Months In, Part LII: I Wanna Be Your Vacuum Cleaner

I Wanna Be Your Vacuum Cleaner

Accompanying music

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

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

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

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

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

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

Read this source code that should be vacuumed up
Learn mo’ ’bout this project @

Posted in Boskeopolis Land, Programming

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

Cascade Parade

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

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

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

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

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

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

Learn mo’ ’bout Boskeopolis Land @

Look @ its sloppy source code @

Posted in Boskeopolis Land, Programming

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

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

We have a lot to go o’er…

New Title Screen

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

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

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

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

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


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

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

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

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

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

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

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

Save Files

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

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

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

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

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

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

New O’erworld

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

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

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

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


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

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

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

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

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

New Level Select

It looks nicer & is divided by cycle now.

New Levels

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

Ol’ Levels

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

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

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

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

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

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

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

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

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

Other levels received mo’ minor updates:

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

The Future

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

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

Posted in Boskeopolis Land, Programming

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

Mind Your Manors

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

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

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

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

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

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

Boskeopolis Land “woods” tileset.

Meanwhile, mechanics like the door & the rug monster I just slapped together in 1 day. The door is just a fancy way to force the player to go up to the attic & down to reach the back yard while still allowing them back into the mansion afterward — a necessity to prevent this level from becoming unwinnable, in case there are still ghosts inside. The rug monster I ripped off from Super Castlevania IV after watching a playthrough o’ it, as I felt like this level was a bit too easy & empty. There are so many weird creatures & gotchas you can do in a Muertoween-themed level — I know I also wanted to have a’least 1 painting o’ a farmer who suddenly comes to life & stabs their pitchfork downward when the player comes near — that ’twas a struggle to fight the urge to try implementing all that & to stay focused so I could finish this thing sometime this century.

Since this level is easy & wants you to stop & explore every nook, I made the gem score require collecting all gems… sorta. I also implemented a score system wherein you gain gems for flashing ghosts in quick succession ( the time-score run shows this off ), so you can get a li’l leeway if you’re strategic ’bout defeating ghosts. Howe’er, this is much harder than just collecting all the gems — specially since the hard-to-find gems are in such large bunches that the ghosts would ne’er give you e’en close to ’nough to make up for them.

In hindsight, I think I made the time score too easy. I originally calculated it based on my time going round defeating each ghost as quickly as possible, only to later realize it’s faster to lure ghosts into bunches to defeat them all in quick succession ( which is where I got the idea for the aforementioned gem bonus ). In the time score I recorded, I played sloppily, so I beat the time score by 3 seconds; but you can clearly see that a player who’s actually good could beat that by several seconds.

This level’s music doesn’t come from Kevin MacLeod for once, but from Lobo Loco @ the Free Music Archive.

By the way, the ghosts here are “kappa-obake”, a pun off “kasa-obake”, those umbrella ghosts oft found in Japanese media, such as Super Mario Land 2: 6 Golden Coins. 1 o’ the meanings for the word “kappa” is an ol’ fashioned term for a coat — so these are coat ghosts with a single eye & a tongue, rather than umbrella ghosts. They originated from the “DISTURBED RESIDENCE” episodes o’ Boskeopolis Stories.

Things I forgot to do till after I already recorded: I just noticed while working on this level that the enemy counter icon in the HUD is a Cowpoker from “Playing Railroad” & thought to change it into a ghost icon for this level ( & ventually a chicken icon for “Foul Fowl Farm”, which also has this icon ), but forgot to do it.

What doesn’t count: there’s a glitch with the diamond that causes it to still appear e’en after you already collected it, only to disappear when you get near it. This is probably caused by an optimization I made months ago so that block interaction doesn’t happen ’less you’re near it. Howe’er, this doesn’t seem to happen in many other levels, so I need to figure out how I fixed it in those. Either way, I deliberately didn’t fix it yet since I knew it wouldn’t show up in the video, since I don’t go near there after the 1st run.

Learn mo’ ’bout Boskeopolis Land @

Read Boskeopolis Land’s horrifying code on its GitHub

Posted in Boskeopolis Land, Programming

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

Stop & Go Space Station

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

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

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

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

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

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

Visit the official website @

Read the unreadable source code

Posted in Boskeopolis Land, Programming

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

Brier Flier

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

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

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

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

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

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

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

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

Visit the official website @

Read the unreadable source code

Posted in Boskeopolis Land, Programming

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

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

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

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

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

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

Posted in Boskeopolis Land, Programming

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

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

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

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

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

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

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

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

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

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

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

Source code

Posted in Boskeopolis Land, Programming

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

’Cause everyone loves wind gimmicks.

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

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

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

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

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

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

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

Posted in Boskeopolis Land, Programming

The Problem with Storytelling in Video Games

You can’t completely break an artwork from the media it’s made in any mo’ than you can completely break the abstraction o’ anything from its concrete basis. Artwork literally can’t exist without a medium.

A corollary o’ this is that if you change a work’s medium, then you change the work itself. This is why adaptations are so controversial. For instance, ¿why is The Shining movie with Jack Nicholson that’s inaccurate to King’s original book popularly viewed as superior to the mo’ faithful miniseries? ’Cause movies are different from books: what makes good literature doesn’t necessarily make good film, & reverse.

This applies equally to video games. The problem is, many game developers still haven’t figured this out yet, probably ’cause it’s still a young medium & new media oft stumbled while trying to ape older media as it tries to figure out how to be its own thing. Much o’ video game storytelling is still done through cutscenes &, e’en worse, dialogue boxes, which are just inferior versions o’ movies & literature, respectively.

Cutscenes aren’t nearly as bad. Theoretically, it’s possible nowadays to make cutscenes that are just as good as real movies if one uses live action or pre-rendered footage. However, in reality, the economics o’ game development has ne’er led to the existence o’ video game cutscenes that look as good as a Pixar film or have the acting & directing quality o’, say, The Godfather1. &, ’course, video games are much pricier than movies, so if the video game doesn’t offer useful gameplay, — if the game’s claim to quality is based entirely on its story — then buyers are still ripping themselves off. Video games don’t just compete with each other; they must also compete with movies & literature, which are just as hungry for time & money. ¿Why waste my scarce money & scarcer time on a game whose claim to fame is cutscenes cluttered in chunky polygons & trite writing when I could better serve my time on earth watching Breaking Bad? ¿Why read the 1000th medieval RPG with hokey, inaccurate “ye olde English” when I could just read Shakespeare & get the authentic thing, which sounds 1000 times better?

But I would rather focus on dialogue boxes, since they’re worse, & worse in ways many have probably not noticed, but as someone who reads literature a’least round 2 hours per day, I have noticed quite blaringly.

The easiest thing would be to point out that many games highly acclaimed for their story don’t compare much with highly acclaimed literature. People who praise the story o’ games like Ocarina of Time or the average Final Fantasy game would probably be shocked if they were to learn that, if these games’ stories were put in book form, they would be laughed out o’ any serious fantasy or science fiction guild. ( You’d think anyone who has watched The Game of Thrones, based on the Song of Ice & Fire series would realize this, since the stark difference in nuance, character, & world-building ’tween that series & the average Zelda or Final Fantasy game is glaring ).

This is likely ’cause, unlike music or art assets, the average game’s written not by professional writers, but whoever they have standing round — usually the narcissistic director ( I’m looking @ you, Other M ) — based on the delusion that anyone can write well. This is on the level o’ logic that any guy with the generic title “game designer” you have lying round can compose Beatles-quality music. Interestingly, 1 o’ the few video games I consider to have literature-level quality writing, Mother 3, was written by an actual published writer.

But e’en if the words written are good, dialogue boxes are still an absolutely terrible way to tell story. It’s striking to me, ’cause e’en I hadn’t noticed it consciously till recently: I’ve always had this inexplicable preference for reading books o’er reading in video games, but couldn’t quite tell why till recently.

The answer is that dialogue boxes suck. They’re tiny windows wherein you can only read a few lines o’ text @ a time, whose movement speed is oft highly constricted, & wherein trying to go back & read text that’s already gone by is either a pain or impossible.

Contrast this with books: what I like ’bout books is that they give you complete control o’er the speed & flow o’ story progression. This is why I still prefer reading to watching TV or movies or e’en watching tutorial videos online. Not only that, but I can read in whatever sequence I want. Most people think o’ reading as just a purely linear, uninterrupted path. This is why so much contemporary literature is terrible — ’cause people don’t know how to read well anymo’. No, the true way to read is to go back & reread sections for clarification or just to comprehend other layers o’ the writing ( which are nonexistent in most modern literature, since, as we’ve established, they’re incompetent ). Just imagine trying to read, for example, a Shakespearean play & understand the plot, the references, the meter, the rhyme, the imagery, the tone, the theme, the use o’ consonants & vowels, & all that when you can only read a few lines @ a time & can only read them once.

This is what makes the medium an important aspect o’ a work’s quality: different mediums are inherently better & worse @ different things than other media. Literature is inherently superior @ giving textual info than video games or movies. E’en if one wanted dynamic, interactive textual content, web pages using JavaScript could do a better job than cumbersome text boxes, if people had the creativity to realize this untapped potential2. This is not to say that video games are inherently inferior to literature. Something that literature absolutely cannot do is offer the kind o’ interactive physics or level design that a classic Mario game has. In fact, “level design” is impossible in literature. Understanding this, it should be no wonder why I have mo’ artistic respect for Mario games that use the medium o’ video games for its strengths gainst the average RPG or Zelda game that just throw together generic puzzles, level design, & the most basic movement you could program just to service bootleg Tolkien told through those gimped dialogue boxes.

Unfortunately, many self-described video game critics still don’t respect video games as a medium for what it does best. ¿How oft do these critics praise games based on shoddy story & hardly talk ’bout level design, control, physics, the general coherence o’ gameplay mechanics, &, least o’ all, the quality o’ the game’s programming beyond noticing flagrant bugs? This is probably ’cause the average game critic is probably a failed creative writer — & it’s here where the ol’ acorn, “A li’l knowledge is mo’ dangerous than no knowledge” returns too true.

This is troublesome, as it’s a bad influence on video games. When you consider how li’l attention the hardworking, brilliant programmers who were able to squeeze games like Super Mario Bros. 3 onto such primitive technology as the NES compared to some jackoff who scribbled out some tripe ’bout a goody-goody hero fighting gainst a grrrr evil villain in a couple minutes & puked it onto Unity, I can’t be surprised game developers nowadays just hack their games together in some bloated engine & demand their customers have o’erpowered computers on a certain operating system with a certain brand o’ controller to run their bloated code with every shortcut taken. Gamers can’t complain ’bout getting shit if they can’t tell what shit is. That video games are, @ their core, code, makes this sentiment ridiculous — but it is true. Just as how ridiculous it is that so much modern literature tries to ape film in the vain hopes o’ getting a movie adaptation, ignoring that tiny li’l problem that literature sucks @ being film just as much as video games suck @ being literature.

Posted in Programming, Video Games