Don’t Touch Me, I’m a Real Live Wire
This level’s main gimmick, electric walls that could only be deactivated with switches in ’nother area, forcing the player to race from the switch to the electric walls, was originally going to be a space level, but I felt it would be better to use this mechanic to spice up an attic maze level idea I’d been toying with, since I feel exploring a maze just to find a keycane or collect a certain # o’ gems had already been done ’nough in this game. This gimmick also helps set this level apart from the attic levels in Cool Spot whence this level takes perhaps a bit too much inspiration otherwise.
I’m mixed on the size o’ this level. I insisted on constructing the maze so that all space is used for something, with no large chunks o’ solid wood ( which the Cool Spot levels also do ). While I feel like I did a rather good job o’ that, I do worry that the level might be too big. Then ’gain, a maze needs to be large ’nough to get lost in & have plenty o’ dead ends to offer any challenge, & players who know their way will be able to beat the level within less than a minute. Still, part o’ me can’t help feeling like some pieces — specially the lower left section — feel like filler that exists just to collect gems.
I like the proportions ’tween the pre-1st-wall & after-1st-wall sections, with the early section being much smaller & having fewer dead ends, acting as a subtle training wheels before the boost in trickiness for the 2nd half. This 2nd half immediately starts with 1-way sections down. If you fail to make it to the 2nd electric wall before the switch runs out, you have to go up a longer path round where you went do to fall back down to where the switches are.
If you’re wondering why there’s switch blocks right after the 1st electric wall with switches on either side, this was just a way to force players to reset the switch after the 1st electric wall. E’en with the warning telling you outright that the switches are timed, I can imagine players rushing & forgetting to reset the switch on their own, which will almost guarantee that the switch, which would be getting low just after passing the 1st electric wall, would turn off long before the player gets close to the 2nd electric wall, which felt too much like a frustrating gotcha to let stand.
The time score is so easy I was able to do it 1st try when recording. I intentionally made it less demanding, since players needed to remember the path they needed to take & ne’er take wrong turns to have a chance to make it in time. The gem score was much harder for me & required an embarrassing # o’ tries. As the video shows, this level has the largest gem score o’ any level so far, requiring 40,000₧, which is 400 individual gems. If you pay close attention to the video, you’ll see that there are many gems hidden ’hind the foreground pipes ( 1 o’ the many elements I ripped off from Cool Spot’s attic levels ). Howe’er, there are so many gems in this level, I doubt you need to collect any. I didn’t go too out o’ my way to collect them & e’en flub up collecting the large star formation o’ gems in the top area, falling down a 1-way area before collecting most o’ them. Howe’er, by that point I’d already reached the required 40,000₧.
I was planning on having this released in September, but was delayed by major programming renovations. Graphical layering glitches in this level, specially when someone dies, was the last straw for this game’s unbelievably naïve layering system inspired by Super Mario World under the mistaken belief that code aimed for a 90s game console would work well for modern computer architectures. This scheme used dumb boolean flags on all blocks & sprites & looping o’er all blocks & sprites twice ’tween map backgrounds & foregrounds, 1st blocks & then sprites without priority, & then blocks & then sprites with priority. To draw sprites ’bove the foreground, I resorted to some hacky virtual function that did nothing for the vast majority o’ sprites.
I completely o’erhauled all this, removing all traces o’ “priority” flags. I replaced this with 171 layers o’ lists o’ generic renderable objects, which can render blocks, sprites, or map layers, which are simply all looped o’er every frame. This allows blocks, sprites, & map layers to be on any layer & to be easily moved to any other layer.
To better fit this new mo’ generic system, I also o’erhauled how maps & level files are read: explicit “backgrounds” & “foregrounds” are replaced with generic “layers”, which can be set on any o’ the 17 layers ( tho to make it convenient for me, they default to the default “background” layer & their “layer” can be set to “foreground”, which will put it on the default “foreground” layer ). I also changed the map tile layers to use generic types like “Blocks”, “Texture”, “BlocksTexture”, “Tiles”, & “Fade”, followed by a # that represents which layer it should go on or the strings “BG”, “BG1”, “BG2”, “FG”, “FG1”, “FG2” to simply put it into those default layers so I don’t have to remember their #s. I also changed it so that the BlocksSystem has multiple blocks lists to accommodate this mo’ generic scheme. Since the priority flag is completely ignored now, blocks that should be drawn ’bove the player should be put on a 2nd “Blocks” layer set to “FG”. This new scheme also allows for mo’ opportunities for rendering optimizations. For instance, both block & tile layers ( tile layers are drawn but cannot be interacted with ) can be made textures, wherein they are all combined into a single texture, simplifying them into a single draw call @ the cost o’ not being able to be animated or affected by level events.
There are also some subtler changes I made. For instance, I fixed a glitch that may have seeped into earlier videos wherein the “GAME START” text on the title screen would randomly spread onto 1 or 2 lines. ’Ventually I found out this was caused by a mistake in the look-’head code for the autoline code that would read 1 character beyond the end o’ the list o’ characters, which would be random data. In hindsight, the fact that this clearly involved randomness should’ve clued me in that there was garbage data being read; for some reason, I was stuck for a while on the hypothesis o’ a rounding error in some division or float-to-int conversion. The fact that this only e’er seemed to affect the “GAME START” text & ne’er caused segmentation faults, despite this error technically occurring everywhere there is text, astounds me.
A mo’ noticeable change is that the diamond has been replaced by a spinning card ( I think I also fixed a bug that would cause already-collected cards to still appear when re-entering a level & would only disappear if the player went near them due to optimizations in the block-collision code ), which was a change I had planned for a while, but for some reason had trouble getting the animation right before. Someday I plan on implementing a way to view each level’s card from the o’erworld menu.
Learn mo’ ’bout Boskeopolis Land @ boskeopolis-land.com
Look @ this project’s eldritch code
