Minty Mines
There’s not much to say ’bout this level, since most o’ the effort when into drawing the graphics. In truth, I was just messing round & happened to finally get mine tiles & liked, & then was finally able to make a halfway decent background ( though I still wish I could figure out how to make good-looking wood or metal cross-bars, like you usually see in mine backgrounds ), so I finished this level idea I’d been fiddling with.
I still find the level feels awkward to play. The main problem is that Autumn’s momentum is strange when she bonks her head on the ceiling, which happens all the time here due to the cramped space & rarely anywhere else, since most other levels are wide open with no ceiling. I feel like Autumn’s horizontal momentum plummets when she bonks her head, & it just doesn’t feel right & causes me to have trouble avoiding enemies that otherwise are laughably easy to avoid. ¿Did Mario games control like that?
So let’s talk ’bout the rest o’ the game ’stead.
Much nothing
Unbelievably, I have had actually still been working on this project here & there since my last update — though not as oft as my manic episodes in December. It’s just that most o’ what I did turned out useless. Most o’ it was just experimenting with refactoring code so that ’twas less messy & janky. Mainly I tried redesigning the sprite code so that it wasn’t an unheavenly mess, ’specially the sprite states ( floating, on-ground, falling, jumping, & such ), since as o’ now most o’ that’s just a bunch o’ flags sitting in the sprite code, which isn’t e’en always consistent ( whether or not code checks for “is_jumping” or “prev_is_jumping” varies ). Due to the way the block components use polymorphism to interact with all sprites, the Sprite class used by all sprites also has many variables used by only a few sprites, which is wasteful. ’Course, there are many sprites that don’t jump @ all; but worse, there are many variables only used by the player, such as climbing code; but ’cause they’re manipulated by block component code that is run by all sprites ( & all have the same interface, due to polymorphism ), it can only manipulate things that the Sprite class has, since as far as it’s concerned, that’s what it gets a reference to, not any particular subclass. I found a much easier, though less elegant solution: simply have player-specific code in some singleton class, like Inventory or EventSystem. ( Though, now that I think ’bout it, that’d cause trouble if I e’er needed Dagny to be able to climb ).
I doubt any o’ this matters much, since wasted memory is probably the least o’ my efficiency problems, & it’s not as if I’ve had any slowdown. For instance, the fact that Sprites use polymorphism @ all, & thus must be held as pointers in the sprite vector rather than as contiguous full objects means that the sprite code probably has plenty o’ cache misses & such, which is probably far worse than the unlikely scenario o’ using too much memory.
Anyway, I was able to create some rather elegant code @ 1 point wherein, for example, the code for jumping was all divided into a separate class where it didn’t get in the way & only existed for a sprite if it actually used it. The problem is, in every alternate version I’ve made, the physics are off — ’specially the collision. & in the battle ’tween code that’s elegant & code that’s right, the code that’s right wins.
Thus, the current project still has the messy, inefficient sprite code.
An e’en worse problem than this not-serious programming issue was simply a designer’s block in terms o’ level design. Ironically, a task I thought would be easy is probably e’en harder than other ideas I had. This game is a simple platformer — so simple that the protagonist doesn’t e’en have an attack other than jumping on enemies. Making a simple platformer that has some creativity, does something new, is immensely difficult ’cause platformers are a well-worn genre. For instance, I try to think o’ interesting enemies to make, only to realize Mario has already done everything. Every idea I come up with, I hear Dougie chime in my head with his nasally voice, “¡Mario did it! ¡Mario did it!”
I’m also still trying to figure out what to do with the o’erworld map. My main idea is to have a Zelda-like game wherein passages lead to the platformer levels ’stead o’ Zelda dungeons, but I feel that may be too much. Mo’ importantly, the variety would be hard to get right. Zelda games usually have a rather limited set o’ themes for o’erworlds; the 1st Zelda game had, what, ¿rocky terrain, forests, a graveyard, rivers, & mountains? This o’erworld needs to have cities, forests, mines, snowy areas, icy areas, factories, deserts, a store, a Pac-Man maze, sewers… Also, the levels are designed like my spiral idea o’ cycling through themes rather than having themes for each “world”, which would only mesh weirdly for a Zeldalike o’erworld. ¿Would the player just go all round the whole o’erworld multiple times, somehow unlocking ’nother part o’ each area on each cycle?
