Hy! I just wanna ask a simple question .
prior to the unity learning I was asked lots of time to be proficient with OOP.
until now I have made several games from scratch…
I don’t feel much need of OOP as it was imagined…
my Question is can someone list me the uses of OOP in making game.
How OOP is useful in unity?
This is an interesting question. First of all, if you are creating games using Visual Scripting, you may not really need OOP at all. Everything going on behind the scenes is OOP but you don’t get to see it.
Before I get onto OOP, let me put to you a message I put to all my students. You will spend far more time looking at your code than you will running it: writing, testing, debugging, improving performance. You’ll look at your code for hours and hours, trying to figure out why something doesn’t work as it’s supposed to. Programming isn’t about writing code –it’s about fixing the code you’ve written or revisiting to add new function.
The whole point of OOP is that it makes the entirety of coding easier for you. Three examples:
Firstly, you’ve got a bag of goodies, which we call an Object, and it contains data and functions. All these bits relate to one another and, unless you choose to share them, they are private and can’t be overwritten accidentally or used by something else.
So your player Input object gathers input from keyboard, gamepads, touch screens etc, decides how to use it and prepares the data for a separate object that does the moving (perhaps swim, fly or run). If you’ve kept things separate and followed good practices, this approach to design will help you think about your code more clearly and debug more easily. This process is a subset of what we call Abstraction.
Secondly, if you’ve designed a function with a particular interface (i.e. the way of calling it) but you later need to change the internals, keeping the interface the same means that you can rewrite without having to change code outside.
An example might be that you want to add a new type of input device. Your Move object doesn’t need to know that you’ve made this change. It just needs the move data. This process of compartmentalisation is a subset of what we call Encapsulation.
Thirdly, one of your game objects might have multiple objects making it up (appearance, function, collider, animation and so on). All of these are objects. What’s more any one of these objects might have its own parents that define parts of how it works.
Maybe all colliders have some code in common that could sit in their parent, rather than duplicate the code in each collider. Having objects contain objects, and having objects inherit from a parent are part of what we call Object Composition and Inheritance.
There is masses of code behind the scenes that make these different concepts work. But you can only exploit them if you are aware of them and know how to get the best out of them. Maybe you want your NPCs to have some common function. Do they have the same code in each NPC? No, we find another way for them to share code, perhaps through the idea of Inheritance or perhaps through another technique called Dependency Injection.
But, you don’t have to follow these ideas. You can code an entire game in a combination of Start and Update methods - and I’ve seen it done. But it’s harder to write and much harder to debug.
As a final point, small games can be written using any kind of programming and you can get away with it. When you start coding in teams, these concepts of Encapsulation, Abstraction, Object Composition, Inheritance and so on are critical to success. OOP is what we call a paradigm and there are others but Unity’s backbone is OOP and a good understanding of it will help you write better code.