Devlog #3 - Enemies and Interaction

Content

Since this week's topic was enemies and interaction, I set about adding more enemies (which is to say, players) and more interactions (a health mechanic). There are two more controllable characters on the map (controlled by up as I, down as K, right as  L, left as J, and up as numpad 8, down as numpad 5, right as numpad 6 and left as numpad 4, respectively). Now, instead of disappearing forever when a player is beaten, they will respawn in three seconds if they haven't run out of lives (with the starting defaulted to 3 for the moment, though both the life cap and the starting lives are variable). To handle this behavior, a single player managing game object can be fed information from a player as they are beaten and need to respawn. It then handles where they respawn and how long it takes them to respawn, if they are able to respawn at all.

As you might notice, I made a few cosmetic additions to the game, some seen, others unseen. To help RGB Rumble feel more like a playable game (because at this stage, it basically is, though without a real win condition), I took time to implement movement animations for the first player model. Doing so also allowed me to finalise the colliders for the player. I settled on a solution that changes the size of the collider depending on whether or not the player is moving up or down, or left or right, making it thinner for vertical movement and wider for horizontal movement. Doing so I believe achieves a balance of avoiding visual oddities as well as maintaining smooth and uninterrupted movement.

To account for the new animations, I created a shader to dynamically replace the colours on the player sprite for their red, green and blue counterparts upon changing to a new colour as opposed to what I had planned to do: create whole new sprite sheets and animation sets. This new method surely saved me a lot of time and menial labor, as well as build size. The reason I don't simply recolour the player sprite through changing the colour of the sprite renderer programmatically is that in doing so, the finer shades on the sprite are lost or muddied and I generally lose control over how the palette appears in game.

Feedback

Some parts of some platforms seemed a little thin (just the parts that were the same width as the players) and I think that maybe the different colour buttons could be different shapes or have different symbols to help them stand out more as well.

Biggest points are that the wall collisions are just a bit tight, and it's hard to move freely.

If one of the people is red, and they get killed by the other person, who is blue, they will respawn as red, and the blue person can simply block off their spawn room and effectively instantly win maybe have people start as random colours when they respawn? Or maybe have it so that they are guaranteed to spawn as the colour that defeats the colour they were killed by.

While the part about the platforms seeming a little thin ties into a solution I've proposed for the next observation, the suggestion about helping the buttons stand out is something I have considered, especially in terms of colour blindness accessibility. Putting symbols on the buttons in addition to perhaps providing a hue-shifting filter is something that I might consider later down the line.

I had already intended to solve the issue regarding leaving the respawning player open to easy attack by another player by randomising the points at which a respawning player appears, however this problem did draw attention to something I was not previously aware of; a bug in which a respawned player keeps the colour they had before they were knocked out. It was my intention to reset a player's colour upon their respawn, but it must have slipped my mind to actually implement it.