Unity Learning Blog #1

This shall be my first blog to document my learning journey I guess... For those that are curious to know... I don't really do this type of thing. But I wanted to try something new. And blog seems to fit that criteria of like little things to do, its simple just typing out and recalling your learning process. Way easier than making videos, though I plan to look into that next time. The purpose of my blogs are Active Recall Keep myself accountable Identifying my gaps And maybe building a small audience base (Hopefully) Most importantly is to get exporsure as well Honestly, one thing that i have always struggled to do is to be consistent. But when it comes to games though, its just different. So, i hope this will be better. To give you all some context, I am currently a college student that still studying but I really have a passion for games andhave always wanted to make them. I do have progamming background, which I hope comes in handy for me. Enough with the yapping. Time to dive into my first blog. Today on Unity, I started on understanding how the engine works. I know how game loops work so Start() and Update() in mono-scirpt behaviour is not really anything new. (Start and Update Loop in my mover) One thing I picked up on is using SerializeField, I realise how useful they were especially when it comes to testing and debugging of games on the go. [Useful] Another thing that I touched on is Input, understanding Input is a massive topic by itself, and one that, I am sure is crucial in my Game Dev journey. From what I can recall there is a New and Old Input system. I still don't really get the difference, but I will be keeping tabs on this to come back to take a look. As of now, I will be using Input.(Something). [Look Into] Another major thing that I stumbled upon is Cinemachine, based on what I have looked up on it. It's basically an All-In-One camera system. It has a multitude of features such as Follow, and Hard look at, making tracking of objects very easy. This is a system that i will have to master when it comes to game dev. [Look Into] Lastly Time.time and Time.deltaTime, these 2 are very important in their own rights. Time.time represents the time in seconds since the game started. It advances based on real-world time, not on the frame rate of the game. Time.deltaTime on the other hand is crucial in making sure that PCs runs the same. Why is this important though? If someone has a PC that is fast, while another one that is slow, let's say one runs on 60 FPS, the other on 30 FPS, the update logic of the game will only be called 60 and 30 times respectively. This will definitely result in the 60 FPS computer lets say, driving faster because it updates its position more. That's where deltaTime comes in, by mutiplying it with deltaTime which provides the time elapsed since the last frame was completed. We can ensure that the change applied over a given time or interval is consistent regardless of the number of frames rendered during that time. [Useful]

Apr 13, 2025 - 13:16
 0
Unity Learning Blog #1

This shall be my first blog to document my learning journey I guess...

For those that are curious to know... I don't really do this type of thing. But I wanted to try something new. And blog seems to fit that criteria of like little things to do, its simple just typing out and recalling your learning process. Way easier than making videos, though I plan to look into that next time.

The purpose of my blogs are

  • Active Recall
  • Keep myself accountable
  • Identifying my gaps
  • And maybe building a small audience base (Hopefully)
  • Most importantly is to get exporsure as well

Honestly, one thing that i have always struggled to do is to be consistent. But when it comes to games though, its just different. So, i hope this will be better.

To give you all some context, I am currently a college student that still studying but I really have a passion for games andhave always wanted to make them. I do have progamming background, which I hope comes in handy for me.

Enough with the yapping. Time to dive into my first blog.

Today on Unity, I started on understanding how the engine works. I know how game loops work so Start() and Update() in mono-scirpt behaviour is not really anything new.

(Start and Update Loop in my mover)
Image description

One thing I picked up on is using SerializeField, I realise how useful they were especially when it comes to testing and debugging of games on the go.
[Useful]

Image description

Another thing that I touched on is Input, understanding Input is a massive topic by itself, and one that, I am sure is crucial in my Game Dev journey. From what I can recall there is a New and Old Input system. I still don't really get the difference, but I will be keeping tabs on this to come back to take a look. As of now, I will be using Input.(Something).
[Look Into]

Another major thing that I stumbled upon is Cinemachine, based on what I have looked up on it. It's basically an All-In-One camera system.
Image description

It has a multitude of features such as Follow, and Hard look at, making tracking of objects very easy. This is a system that i will have to master when it comes to game dev.
[Look Into]

Lastly Time.time and Time.deltaTime, these 2 are very important in their own rights.

Time.time represents the time in seconds since the game started. It advances based on real-world time, not on the frame rate of the game.

Time.deltaTime on the other hand is crucial in making sure that PCs runs the same. Why is this important though?

If someone has a PC that is fast, while another one that is slow, let's say one runs on 60 FPS, the other on 30 FPS, the update logic of the game will only be called 60 and 30 times respectively. This will definitely result in the 60 FPS computer lets say, driving faster because it updates its position more. That's where deltaTime comes in, by mutiplying it with deltaTime which provides the time elapsed since the last frame was completed.
Image description

We can ensure that the change applied over a given time or interval is consistent regardless of the number of frames rendered during that time.
[Useful]