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




Mean Worm Enemy


This week I’ve worked on implementing a new enemy type to our game. The original idea was that it would look like a worm, but it ended up looking like a mean snake of some sort with very sharp teeth.


It was already planned early on that we would have more types of enemies in order to bring more variation to the gameplay while exploring. And this one, in particular, was to add a bit of a surprise element to our game.

The design was that it would react to a player coming within a certain distance. It would then start digging towards the player, making a rumbling noise in the process. I achieved this by having a variable that would be assigned the moment the player is detected. This variable would contain the current time + a certain delay, which is now assigned as 3.5 seconds.

During these short seconds, the enemy would lock onto the player’s position, but not appear just yet. There’s also another experimental variable that makes it so that when there are 1.5 seconds left until it’s been 3.5 seconds, it would stop locking onto the player’s position. This is because the worm is otherwise nearly impossible to dodge and the player would end up dying a lot.

Once the current time is equal to or greater than the variable we assigned, it will call a Coroutine function that would make the worm move out from the wall and towards the player’s position 1.5 seconds prior. I use Coroutines for this since it’s perfect for the job. It will basically update the function every frame until all of the actions within it has finished. Thus I can have a while loop that checks the distance between the enemy and its target. Within this loop, there’s a MoveTowards() function that will keep moving towards its target until it has reached it. It will then use the very same method to move back into its original position.



The player in comparison to the worm




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


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.


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.