Game design reflections on bunny hero!

last edited 2024-11-22

bunny hero! is a short level-based platformer I made in 2023. I made it because I had a bunny boy partner and he was being all cute suggesting that I should make a game about a bunny, and I decided to actually do it. You can play it here:

bunny hero! download page

Its gameplay is mostly inspired by Super Mario Bros, where you defeat enemies by jumping on them, but can't touch them otherwise. Unlike Super Mario Bros, I gave you 3 hp by default, and levels are completely isolated: instead of an overworld with lives and power ups carried between levels, there's just a level select menu. It also practices "stop locking levels".

Stop locking levels

Originally I planned for the bunny to constantly auto-bounce and not be able to stay on the ground, but I found this was too annoying in practice (it dragged the camera along with it) and took too much control away from the player.

One of my friends said she didn't like the variable-height hold jump that most platformers have, where you jump higher by holding down the button after you leave the ground. This inspired me to try a different approach to jump design, and what I came up with was 3 different kinds of jumps: a basic one, one that goes really high, and one that goes really far forward. Which kind of jump you're doing is determined before you leave the ground. My friend liked this, and I think it was an interesting idea but I'd still prefer to have variable height hold jump.

An implementation flaw with the jump controls is that there are 2 inputs for 3 types: spacebar makes you jump normally, and shift is "superjump" which is either the super high or the super far jump depending on whether you're moving when you press it. This means you often accidentally do the wrong kind of superjump, which is frustrating. I wish I had used 3 buttons.

I think one of the issues with this game was that often you could kind of bait out enemies 1 at a time by moving through a level very slowly, and thus not have to deal with complex situations. I don't know how I would fix this. How does Mario handle it? I don't know; to be honest I've never played it with an analytical mindset.

A more fundamental issue was the lack of momentum. This project convinced me that pure platformers (or Mario-style action platformers) should have momentum. I designed this one without because Hollow Knight doesn't have momentum and I liked that, but Hollow Knight is an action game first and a platformer second. With more emphasis on platforming, it's more important for movement mechanics to have more depth.

Another fundamental issue with this game was the lack of platformer mechanics. There's platforms and enemies, but other staples of the platform genre like moving platforms, temporary platforms, switches, any level element that has any kind of state other than enemies, were absent. Those things can do a lot to make a level more dynamic.

The only powerup I had was a carrot that gives you an extra life, and these also had no state. They were found floating in the air and never moved. So the only thing I could do to not just make them free lives was put them in side paths where you had to go past some extra danger to get to them, but this usually wasn't very interesting; when isolated from the rest of the level, it was usually either obviously worth the risk or obviously not. Okay, sometimes I did place them so that you could only reach them by bouncing on enemies and would miss the chance if you killed the enemies first, that was pretty good. But I only did that twice.

For comparison, in Super Mario Bros, powerups often come from hitting blocks in specific ways, which you may or may not be able to do depending on what power state you have and what other blocks/enemies you've already removed, and once you open them, they move or bounce away from you, and you may have to chase them down. This is a lot more interesting than the way carrots work in bunny hero!.

I actually planned to have moving platforms in the final boss. There'd be a phase where the platforms go up, making it naturally easy to get to the top of the boss, then after you'd done some damage the platforms would stop, then there'd be a phase where they go down, making it extra hard to climb up while being shot at. It was a cool idea, but was too difficult to code for the level of motivation I had at the time.

Speaking of the boss, I gave it homing missiles to be different from the straight projectiles that turrets have shot at you throughout the game. I also gave it lasers that would sweep radially, traveling I think 60 degrees from their starting angle before stopping. The lasers would alternate going clockwise and counterclockwise. But in playtesting I found it was too difficult to keep track of which direction the laser would go next and what it meant for your current situation (if you were on the left side of the arena, clockwise meant up, if you were on the right side, clockwise meant down). It was also too difficult to judge how high/low you had to be to be safe from their sweep. I fixed both these problems by making it so when you see the purple line showing where a laser sweep is going to start, you also see a thinner yellow line showing where it's going to stop.

Another feature that got cut because of waning motivation was a mid-game ability upgrade. When the bunny meets their kitty friend in the treetops, I was gonna also have a butterfly friend there that would accompany the bunny and give them some new ability through their butterfly magic, like a double jump or something.

I think the most fun level design things I did were the parts where you have to use enemies as vehicles. There are armored enemies (which you can jump on safely, but it doesn't kill them) and there's one part where you have to repeatedly bounce on one, essentially using it as a moving platform to get across a spike it, then in a later level you have to use a flying armored enemy as an elevator.

The last lesson I learned from this game was about hitboxes. In this game, everything's hitbox was its bounding box (that is, the smallest box that completely encompasses its sprite). This was a lot bigger than players expected, since your sprite didn't visually take up its entire bounding box; a bullet could count as hitting you while it looked like it was still 10 pixels away. A friend cited this as a major frustration, and while I was done working on the game by then, I definitely learned that lesson for the future. In every other game, hitboxes are smaller than bounding boxes, and it's for a good reason.