Camera Movement

This week I’ve been working on our game’s camera. It’s heavily inspired on the camera behaviors of games like Zelda or Metroidvania. It basically follows the player until it hits the boundary of a room where it then stops. If the player enters another room from there, the camera will transition over to the new room and then follow that room’s boundaries.

I created this because once more we in our group have decided to re-design a few things. As we got around to making it more room-based instead of an open world we thought this sort of camera behavior based on room boundaries would be pretty ideal, and cool to have.

I solved this issue by making a new game object which I would name “Room” and gave it a box collider, set as a trigger, which would be the room’s boundaries. The moment the player triggers this collider the room’s script would send the new bounds as well as from which direction the player enters the room to the camera’s script. The moment it receives these new boundaries it would then transition over and align to the new room’s boundaries using a Coroutine function. This function would calculate where to move the camera based on its orthographic size and the information it received from the room object ( the direction & boundaries).

If you tested the game during the playtest session, you might have noticed some bugs with the camera, such as it totally glitching out when you’re rotating mid-transition and attempt to go back. As this camera and level were put together very quickly, we failed to notice this bug before the playtest. A simple solution to it is to lock the player’s movement, making him unable to rotate until the transition is done, which would, in turn, make it simply impossible to quickly turn back and break the camera. It’s not annoying either since the transition would be over very quickly.

 

The green lines are the room’s boundaries. Bad implementation of it but we were pressed for time to get it done for the playtest. The boundaries can be more varied than in just the same sizes.

 

Example showing the camera’s movement & transition

 

 

Powerup!

What:

An artifact I’ve worked on this week is a simple powerup that will act as a “key” in the game. The powerup itself is simple, once you pick it up the type of projectile you launch changes. The color of the projectile is the same as the powerup the player picked up.

A purple powerup *placeholder

These projectiles then serve the purpose for the player to unlock new areas of the game that were previously blocked by obstacles. These obstacles have some sort of indicators telling the player which type of projectile will work on it. E.g. a purple projectile would be able to remove vines which have purple flowers on it.

Purple flowered vines *placeholder

How:

Unity has a very convenient “tag” system which I’ve used for this. The powerup itself is a prefab, but depending on what tag it contains it will change to the corresponding color.

A purple powerup

 

In the player script, it checks whether or not the player collides with the trigger of an object. The script would then check if the collided object has a certain tag and then change a variable letting the script know what projectile is currently active. E.g. if the player collides with an object containing the tag “ppPowerup”, the script would then know that it’s only to launch purple projectiles.

The projectiles themselves would also contain tags. The vines would then have a script using the same method as above, only that it allows one certain type of projectile in order for the condition checking whether to open the path or not to be true.

Why:

For awhile now, my group and I have been contemplating how to make this game more interesting. We’ve played around with a bunch of different ideas, especially regarding what sort of powerup we should implement.

The game is an exploration game and in order for the player to have more of an interesting experience, locked or inaccessible areas are a tempting way to power the player into finding the “key”. In our case, this is the projectile-changing powerup.

Colors were the first idea as it’s simple and relatively easy to convey to the player that something matches. It’s also easier for the player to detect these obstacles as something special as the game itself is very dark and lack many bright colors such as purple.