Devlog 3: Enemies and Interactions

Here comes the DevLog I was dreading: the enemies. As I’d built a player with jumping movement, if I wanted something similar to that for enemies, I’d have to figure out a way to code their odd movement.

So, I decided I’d have a few different enemy types. First is the “Ground Enemy”. This one doesn’t have animations yet but simply represents an enemy moving back and forth on the ground. This one doesn’t yet experience gravity, but likely will in the future.

Pretty simple. Then the second enemy, I decided to make a kind of sentry. A little box or something similar that sits in the air waiting for you. And once you entered it’s radius, it fires a heap of bullets at you!

A few versions of this are in the works, such as the stationary sentry already shown and a new type that moves around (likely around predefined points). Whether that one will still be a sentry box or rather an actual flying character is still being worked on too.

The third and final current enemy type turned out to not be as bad as I thought to make. Bouncing frog, but evil!

BFBE doesn’t have too much I in the AI department. This little homie just moves forward until it hits a wall. Then it decides to turn around and hop the other way. A feature that is being added is that when a player passes in its radius, the BFBE (bouncing frog but evil, remember…) the frog will decide to turn around, and pursue the player. Making an AI that can directly home in the player is much more difficult.

When I implemented movement, I decided to implement it via Unity’s inbuilt physics system. Rather than translating objects by directly moving them, most of them are done via adding force/velocity in directions. This propels the player/enemies like we’re throwing them. It’s a bit harder to calculate the amount of distance the enemy goes if you add several units of force, versus simply translating them several meters. Thus, it’s still in progress.

But now we get to the player part of this. The health bar, and the ability to defeat enemies.

The health bar was a relatively simple addition, basically just being what I’ve created in previous projects.

For every moment you spend colliding with an enemy, it drops your health a little. Unless they’re spikes, which drops your health to zero immediately. I liked this system as it allows you to take a more damage for not fixing the problem, rather than giving you invincibility frames which just allow you to ignore the problem.

Then once you hit zero, poof. Blood splatter, player gone. Then we reset.

And now we have damage to enemies. There are two different options available at the moment. The first, inspired much by Super Mario and other games, you can stomp on their heads! Gives you a little bounce and rids the world of their existence.

Then the second is the primary theme of the game: lasers.

Use your lasers to absolutely eviscerate all that cross your path.

That’s about it for the main section, now let’s look at feedback.

Feedback Corner

First was an interesting note that I’ve actually thought a little bit about.

The laser, and your ability to fire it infinitely. There are a few ways to deal with this. My original plan before I started actually building the game (and decided that it was a movement ability) was that you could be stationary and holding the button for a few seconds would charge the laser before it fires. That idea fell to the wayside as it wasn’t really as interesting to play. Maybe in a larger and more well-built game, but for simple frog bouncy flying crazy laser game that wasn’t ideal.

The more likely outcome is that excluding any scenes where you must fire your way through a maze/obstacle course kind of thing, your laser overheats after a few seconds of firing. That’s not a bad idea, and it allows me to condense the levels a bit more (rather than making a massive one you can fire yourself through).

The other note was less about the enemies or existing abilities but rather to add a new one. A wall jump. The wall cling was originally unintentional, before I turned it into a feature (Classic developer behaviour). I had several people suggest adding an ability to jump from this position. This honestly makes a lot of sense as the wall cling kind of impedes progress and can be uncomfortable.

So, I made the feature. It’s the beginnings so it might not look as smooth, and the values are not fully fleshed out, but it’s a start!