The Friday Tiding #1: Bugged Out
I've decided to try something new.
When it comes to devlogs or updates for the projects I am working on, my attitude has always been "When I have something to report". This isn't a bad attitude to have by any means, but it also means sometimes I can go weeks or even months without talking about any developments at all because I deem the information not worthy of an update.
So my idea here is to throw that mentality in the trash and start making weekly updates for Project Petunia. Regardless of if the news is super interesting, this format should at least make it so there is always news on how this project is doing for those that are interested.
The Bomb
Starting with more bug fixes, everyone's favorite subject. Much of my work this week has been related to cleaning up some issues with the player's movement and the HUD displaying incorrect information. The Bomb Powerup in particular has been a host to all sorts of bugs and strange behavior due to its unusual nature.
The longest standing of these was the player keeping their crouching hitboxes when entering a Blast Jump near a ceiling. I ended up implementing a bunch of checks for the player entering the air from a crouch to try and fix this issue, but this 'fix' ended up being really complicated and fragile. It turns out the solution was to just have my game's engine send out a signal to change the player's hitboxes if they exit a crouch, without checking any conditions to be true. Sometimes you lose track of the simple solutions.
Another issue with Blast Jumping was caused by me giving the player the ability to shorten their standard jump by letting go of the jump button. I changed the Blast Jump after the first demo to activate if the player is crouching, regardless of them pressing the jump button beforehand. This stops the player from having to time a jump in the half second window of the Bomb's explosion. However if you press jump and then release it, you can suddenly cut the vertical velocity of the Blast Jump significantly. This is technically intended behavior carrying over from the standard jump but it feels very wrong.
So I added a new condition that can tell if the player has performed a Blast Jump, and if so ignores the player being able to cut it short. This condition not only fixes the issue, but it will also allow me to add some unique animations and such in the future relating to the Blast Jump.
I have to say, I'm impressed that basically everything to do with the Bomb powerup has had some issue or bug present itself.
Wait Your Turn
The other problem child of my recent efforts has been the HUD; Specifically the player's health display. The health display has a lot of fancy slow fade-ins associated with it, and unfortunately only one of these can play at a time with how my HUD is set up. The problem with one playing at a time is that if a part of the HUD was fading in, it would just stop in the middle of its animation to start the next one.
Thankfully the fix for this was very simple. All I had to do was add a check for an animation currently playing. If one is, then we wait for that animation to finish before we play our next animation. Notice in the GIF below that the health icons all fade in before one is allowed to be faded out.
New Places
It's not all just systems and mechanics however. I have also begun the work on the various levels that will be appearing in Demo 2. A remake of the level River Liver from Demo 1 is already complete, but Demo 2 will have 6 levels in total so plenty of work remains.
I don't plan on spoiling too much about these levels currently, but here are some pictures of these future locations.
Making Enemies
Wow, I ended up having a lot more to talk about than I expected!
Another thing I have been working on for Petunia is new enemies. The first Demo had four enemies, which was fine enough for three levels. For Demo 2 I'm planning on doubling that count though.
The first new enemy to hit the ground running is the Masher. This little thing will stand around until the player gets near them, and then after a short alert period will charge towards the player very quickly. Unlike other moving enemies they will run right off ledges if it means they can get closer to the player. The only thing that will stop their one-directional charge is slamming into a wall. Notably, they are also the first ground based enemy that can't be jumped on.
The second new enemy is known as the Halmen. This imposing figure is big, quick on their feet, and unlike most enemies can take some punishment before they go down. Their gameplan is to relentless walk towards the player, before making good use of their halberd to cleave them to pieces.
Here is the two of them in action. Something else that comes up in this GIF is a change to the Pounce ability.
You'll notice that upon hitting the Halmen, the player is bounced backwards out of their Pounce. Previously the Pounce was an absolute state. If you didn't hit a wall/ground/enemy the Pounce would take you wherever you were destined to go. This is still mostly true but there are now some enemies and gimmicks that can force the player out of it early. In this case it is to the player's benefit, as the Halmen would end up damaging the player if their Pounce were to continue after contacting them.
This scenario is actually why I decided to implement this pushback, as there are some places with the Halmen where the player literally would not be able to get past them due to their height, such as when they are standing at a ledge like the one above. Getting more or less softlocked by some clown standing on a cliff would feel absolutely awful, so I made it so the player can use their Pounce if they have nothing else to attack with here without taking damage.
That being said, this pushback doesn't apply to other enemies outside of the Halmen currently, and some enemies will either trade damage with a Pounce, or just stop it outright. Admittedly some of my placeholder sprites in game might make this not so clear.
So the rule I have come up with is if an enemy looks like you shouldn't be able to jump on them, then generally you won't be able to. And if an enemy looks like they'd be protected from melee attacks entirely (such as being surrounded by a shield or something like that), then they'll end up damaging the Player for attempting a Pounce attack.
Wrapping Up
That's more or less all the major additions and changes I've made recently. This ended up being a mouthful! As I said in the beginning, I am hoping to make this a weekly series for as long as I am not going into spoiler territory with Project Petunia.
If you've read this all the way to the end, thank you. See you next Friday.