Oh sorry I didn’t phrase that well then, I meant how quickly you can perform a jump or other action once your dive touches the floor and finishes. With the endlag, once you touch the ground, you just lay there in the dive state for 0.1 seconds before being able to move or anything; whereas before, the dive ended upon touching the floor instantly.
I also prefer more commitment with your jumps, so a definitely agree with you there!
Interesting, also the Ko’d enemies blocking visibility for important stuff never occurred to me, I’m glad you caught on to that cause it probably would’ve taken me a long while before I noticed that.
while horsing around a bit with the latest version i experienced a (admittedly very minor and unimportant (but i felt it only right to mention)) glitch where sometimes the flashing red after getting hit leaves you red for a while after recovering instead of going back to normal. again SUPER unimportant but it is somethin i noticed
Ah gotcha, I was the one getting confused then. >w>
But yeah like you said it’d probably be best to leave the endlag and see how it does, I want the dive to have a little bit of vulnerability so this does the job for now.
Still chipping away at this project whenever I can, but I’ve gotten more busy with work and it’s looking like I’m booked all of this week.
I’ve been making nice progress though regardless. I’ve made my first ever Save/Load system (woo!), and began work on the first level of the game. Hoping I can get at least one section of the level prototype done, and get a new transformation put together, before the next release.
I’ve also been doodling these guys! I’m recycling them from another game idea, but they’re gonna be put in the game as a sort of community of people.
Also if these little nothing progress reports start getting annoying then just let me know, I just figured posting occasionally is better than going silent for a long amount of time.
Good to know. <3
YEAH, I had no idea his name was Bob though! >w> Played the NES game as a kid and played a little again recently, love those bubble dergs.
The main green one is Bub and Bob is the blue one, they’re twins. Bob is shy and quiet one out of the two, so I thought it was him in the sketch. And the twins are technically cursed, but Bub doesn’t mind because people find his cursed dragon-form cute.
Also, you might this find interesting. There was a portly bubble dragon in Bust-A-Move 3 by the name of Debblun.
Heyo, I’ve been super busy lately and it looks like it’s still not going to let up until later this week.
I’m close to having something worth putting together a build for, all I really need to do is make an inflation transformation and a simple enemy to inflict it on the player. Maybe create some better mockups so people know what the new stuff they are looking at are.
I’d also like to make a mini-boss, but I don’t know how much it’ll take to make both that and this inflation transformation. So since it’s been a while already, I’m just going to focus on one thing and try to get something out there.
And here’s another doodle, this one is a sequel to the sketches above, and also a hint to what one of these “acts” in this level is going to be ;3
That took a bit longer than I anticipated. I’ve been busy with work, and half the time when I had some free time I just ended up spending it recovering from work. It’s finally done now though, the bare minimum I wanted to do to feel justify releasing another build!! There’s a couple new things for all of you to mess with, I’ll be very curious to see what everyone thinks of the new level and mechanics! ^w^
Notes
A save system was implemented
A barebones level and act system, as well as “goals”, meaning you can now beat levels
Added a new INFLATION transformation!!
Almost an entire level was built, it’s playable but unfinished
Things like doors, one-way platforms, and screen transitions
Beehives, honey combs, and a new bee enemy were added
The chief and his act exist now
Other bug fixes and stuff that I cannot remember
For placeholders I reused some sprites for the time being.
Also I found out after exporting and uploading this build that I left a debug button in that gives you the inflation transformation when you press space or enter. For playtesting purposes I suggest you use the bee’s and not this button to become inflated, but ultimately you can do whatever you want.
Also there’s going to be a miniboss at the end of the right side, but I haven’t started working on it yet so it’s super basic.
This new level is going to be the first level in the game, so I’m curious to see how well it does at familiarizing the player with the controls and mechanics. I didn’t put a ton of thought or time into it, so it’ll probably need some adjustments.
I’ve tested out the new build and, for the most part, I feel like there’s nothing to say that you probably don’t already know. The gameplay still feels good like the previous build and my only hiccup was realizing how the balloon forms faster movement worked. You blow yourself backwards and moving normally misses with this movement.
Issues
I did find two issues and one of them is gamebreaking. The first issue is that the honeycombs can’t be pushed when your crouching. Because of this, it’s possible to get them stuck permanently in small gaps even when it looks like there’s space to pick them up.
The second issue is that it’s possible to get permanently stuck in narrow spaces when in balloon form. Because the form isn’t on a timer and there’ no exit button, the only option is to refresh the page. Right now, I think this is only possible when playing in the old level and using the debug button.
The one change I would suggest is to make it where beehives eventually respawn and the angered bees despawn/go back. Right now, the bees are really aggressive and will follow you to other screens. Once, I had the initial bees follow me to the area on the left and they just disappeared. I’m assuming they got stuck in the in-between area and couldn’t lock on to me anymore. Also, I think it might be a good idea to add separate bee enemy that ignores the player and follows a set path (like to background flowers or fruit).
The first issue seems to hopefully be easy to fix, I forgot to set some collisions to detect objects, like enemies. So the raycast can’t see the honey comb and push it away.
I think I subconsciously knew this would be an issue, because I felt like I NEEDED to add in one-way platforms before I began working on the inflation transformation. I did not know this would be a problem though, super good to know when designing levels.
Also I was planning on implementing a whole "capacity’ mechanic that a lot of transformations would use, but in this case blowing would release air and deflate you over time. This would be another way for the player to exit the transformation, as well as add more depth to the transformation by adding a little resource management.
The bees were such a pain in the butt to get working, so when I got them to a acceptable spot I was just like “I’m done” and left it there. It is very nice to see what people think of the bees cause my simple mind just thought I can just jump over / move out of the bee’s range, although it’d probably good to have the bees have downtime / docile state. Also that’s honestly a great idea, I never thought of that, might be fun having some obstacles where it’s just buzzing around doing it’s own thing.
So those bugs were really easy to fix. However whenever I was busy squashing them, I found a few more, and came to a devastating realization, a foundational issue.
In this game, you’re body is going to change a lot, right? Yet despite that I continue designing levels and building the game as if that isn’t entirely the case. Every single clipping issue has been related to 1. tight spaces (Usually a one tile gap) 2. crouching, or other actions that change collision sizes drastically.
I can continue squashing these little bugs, but they’re never going to stop coming unless I do something about this foundational issue. When the character and every single other entity can drastically change size at any moment, I need to design my game around that, yet here I am wanting and trying to design it like any other platformer. I don’t want to dumb my game down just to include all the kinky stuff, but I need to think of something clever if I don’t want players constantly softlocking themselves effortlessly.
I’ve got a couple ideas, but I’ll probably need to brainstorm some more since these are just the first things that came to mind.
Potential Solutions
The simplest solution, create rules and simply build the level around it. Like not having any one-tile wide gaps, or making it impossible for an enemy or something to inflict a transformation or force the player into another state while in these tight areas. (I’m not big into this one since it really limits what I can create when I am having to worry about all these things. I want to keep the precision platforming in tact and not have my levels be very open like some other fetish platformers I’ve seen)
Figure out a way for the player character to detect if it is clipping / stuck, and either pushing the player out or, a more fun way to do it, make a stuckage mechanic for when this happens. With the stuck mechanic method is that, the player and transformation will have special sprites and states for when she gets “stuck”. The player will be wedge in between the tight space they are, and have minimal movement, a little movement none the less though. In a horizontal shaft, it pretty much just forces you into a crouch state, where you can slowly squeeze your way through. Vertical shafts would be a little more tricky, but I imagine you’d be able squirm around little bits at a time by jumping or ground-pounding. Also for stuff like the inflation state, if you get too big while stuck, you’ll just pop / deflate and go back to your normal self. With this it’d still be risky and punishing if you get caught in these tight gaps, but it is not GAME ENDING, you won’t be softlocked and completely screwed over.
I prefer the later of these solutions, even if it’d be tougher to implement, especially since stuckage is an actual fetish and would just make sense in this game. Regardless though, I feel like this issue needs to be tackled before progressing any further on this game’s development. It is just too big of a problem to be left alone, and it’ll only make things harder on me later down the road.
The second solution is definitely the better of the two. The simplest method would be to detect when the player is touching opposing surfaces at the same time. But doing just that would case issues with the base form. So, you’d also need to checked for this if the player has changed states (or only check for when the player’s not base form).
