1/22 - 2/4

Time Summary: 13 hours

Studio Meetings: 4 hours

Camera Movement: 3 hours

Tutorial Text System: 1 hours

Encounter System: 4.5 hours

Dev Log: 1.5 hour

Camera Movement

My first task of the week was to create a camera movement for Project Drift. In a previous rapid prototype I worked on, I had set up bounded camera movements and triggers by hardcoding the cameras bounds into a script, and various triggers that would change these hard coded camera bounds. I was never able to figure out a way to set up 1 polygon collider that would act as a bound for the camera, and make the camera be able to switch between these various desired bounds.

However for Project Drift, I discovered the magic of CineMachines! They do everything I was hoping could and would be done in my Rapid Prototype from last October, and more! It is definetely something I will use in projects going forth, and when I do eventually expand the prototype I made back then, I plan to redu all the camera movement with cinemachines to make expanding the game easier.

Cinemachines!

This is what the set up looks like in hierarchy. Main Camera has a bunch of Virtual Cameras attached to it. Each virtual camera can have what it follows set, which in this case is the player, a polygon collider boundery set which tells the virtual camera the edge of where it should be able to look, and even cool options like damping which tells the camera whether it should always try to have the player directly in the center of the screen (with exceptions to bounds of course) or if the player runs to the right, if the camera should lag behind it and not be able to catch up until the player stops or changes directions. Cinemachines and it's virtual cameras definetely add a little aspect of juice that would be hard to handcode

This is the inspector of the Main camera. Note the Cinemachine Brain attached which does most of the hard work for me. It is also worth mentioning the Cinemachine Brain Controller I created and attached. I made this so that all virtual cameras that have lower priorty and are not selected at the start at deactivated to avoid bugs in the future.

This is an example of a virtual cinemachine. Note that is it set to follow the player, and the Bounding 2D Shape is set to a composite collider incase designers want to change it from a box to a polygon in the future.

Tutorial Text System

Overall this was a pretty straight forward task. I had to first create a trigger that would check if the player entered it, then set the TutorialText to active, then change its text to whatever the trigger's Serialized string TextToShow field said. Using coroutines I was able to add a little aspect of juice by fading this in and out. The only real obstacle I had was adding an option for if they want a background behind the text, in our case most likely just a black background, and if so how to change its size accordingly to the text. This again was fairly straight forward as I just had to access the text's preferred width and height, and set the black background to that size. I did find that it was a little tight to the text when I did that, so I added a range Serialized field float called padding which will thicken the black box the higher that the number is set to.

Encounter System

Creating the encounter system was probably my biggest challenge of the week. The biggest challenge was mostly deciding how I wanted to structure it. I knew this would be used probably every day by designers and so I wanted to make sure it would make sense for them to understand without having to try and understand my code. I also was asked to make a confluence page for the encounter system, so I'll link that below instead of reexplaining how I did everything.

Confluence Page