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.