- Home /
Are there any Unity demo projects that have an OOP design?
Are there any Unity demo projects that have an OOP design. I would like to start using a more object oriented design in my projects.
I'd really like to see how other people have used it.
Cheers!
Are you looking to do that because you have a specific "need" to learn OOP? Pretty much all Unity projects use OOP (inheriting from $$anonymous$$onoBehaviour, Renderer etc) but I guess you want to see more game play logic in an OOP layer of classes? For my money individual component behaviours are way more powerful and flexible and should be used with class hierarchies where relevant.
I'm also not sure what you mean by OOP projects because it's all OOP. Are you talking about the design pattern?
I guess I've confused myself. Yeah I understand that unity is using oop, but does anyone create there own custom classes that inherit from other custom classes. Like creating a humanoid class and then creating an enemy and player subclasses that inherit from humanoid. then creating an orc subclass of the enemy like on the unity learn section on inheritance.
Yes people do that - but as @robhuhn says, you want to use a component approach because it's more flexible. Deep inheritance architectures are very hard to refactor and should to be avoided if possible.
Answer by robhuhn · Aug 20, 2013 at 09:35 AM
You would use OOP in Unity like in any other OOP environment. But following the component pattern used in unity you might have a slightly different approach when building the architecture.
You would set up an empty game object and all classes attached are components/behaviours. E.g. we have a component LaserGun extends Weapon extends Monobehaviour (MB) and ProjectileGun -> Weapon -> MB
Then we have another tree: Shield -> Armor -> MB and Hull -> Armor -> MB
These components can be attached to a game object Spaceship as needed. So in this case you would create different spaceships just by changing the components, not by extending a base spaceship class - Actually you don't have any spaceship class here.
That's just a very simple example. Of course you also use interfaces, structs and all that if needed.
Hope that will help you.
This answer assumes spaceships don't have any behavior of their own. If they do, and all spaceships share some behavior, you can of course create a base spaceship class and extend that to each spaceship behavior.
Answer by Jamora · Aug 20, 2013 at 09:39 AM
I only checked the stealth tutorial, I don't know about the rest. The stealth tutorial had a good Object Oriented Programming approach. They have their player in three objects ( = classes): health, inventory and movement; enemies have four objects, etc. While strictly speaking only instantiated classes are objects, I consider classes to be objects in their own right, only abstract.
All you need to do to follow the basic OOP guidelines is to think in terms of objects; determine the responsibilities and behavior of an object, then the encapsulate relevant data and functions to that class. It's impossible (or at least quite hard) to not do OOP (in the broadest sense) when working with Unity. If you have one script with a huge Update function that contains all logic, you are not doing OOP. If you have multiple classes with clearly defined behavior and relevant data fields you are doing OOP.
What helped me broaden my horizons, was the realization that objects are actually behavior. Before, I was thinking about objects as a unit: I asked myself, what does this object do on its own. Now I ask myself: how is this object used by other objects? To me, this difference is that of non-OOD vs. OOD.
tr;dr: Object Oriented Programming (in the broadest sense) can't really be avoided when using Unity, you must mean OOD. At least the stealth tutorial has OOD.
Answer by mathmos_ · Aug 20, 2013 at 09:59 AM
I find that using events and the State design patterns can help a lot when making something big and complex in Unity. Maybe consider using those.
Besides that, just remember that Unity is component based, so always try to make each of your components only have a single responsibility. It's usually better to have a lot of small components, that you can reuse, than a few big ones. And try to keep coupling low as well.