Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How Does Unity Works With C# Classes

Tags:

c#

unity3d

Coming from studying pure C#, I find the scripting in Unity (with C#) to be a bit unintuitive.

For example, it seems the most common way people (beginners?) use scripts in Unity is by creating a "single use" type script and attaching it to the actual Game Object (by clicking and dragging it to a script component). In that way, there seems to be very little use for inheritance. Or perhaps I have it backwards. Should I create the classes/inheritance outside of attaching to Game Objects, and then only attach scripts to Game Objects that reference those outside classes? I'm sure some of you may just say "do whatever you want!" or "do what works" but I don't want to start with poor coding methodology just to end up refactoring it at a later date.

Another thing I'm confused by is class instances in Unity. For whatever reason it seems that I can work with built-in classes like Animator without instantiating it [I almost never see a = new Class(); ] and yet these classes are not static. How does that work? And if I do build my own classes that become referenced by my game objects, do I have to create instances to work with them or is this all being done under the hood by the engine?

And where is the Game Object (the actual item in the editor) in all of this scripting? Is there a class that is made for each Game Object? And, if so, how do I find it and peek at what's going on with it?

like image 630
Snik Avatar asked Aug 06 '14 03:08

Snik


2 Answers

Inheritance is totally relevant in Unity just the way it is in other framework.

Consider you want to implement two types of enemies, they both have some common behaviours (Walking, Attacking) and both have specific behaviours (A can fly but B uses pathfinding to attack). You would design an abstract Enemy class inheriting from MonoBehaviour (btw script inherit from MonoBehaviour which inherit from Behaviour,.., so inheritance is right there) and then each inherits from Enemy.

This is better for maintaining but also for using your enemies. FlyingEnemy and PathEnemy can be stored in a collection of type Enemy allowing you to iterate on it to perform common enemy action (like dying).

Interface is also really useful as you can have a projectile that hit anything in the level. The projectile would check if the hit GameObject contains a IDamageable component and if so, calls for the Damage method of the interface. This allows to hit anything without knowing if it is the Player, and Enemy or a wall. Each implements the interface in their own script and the method just does the relevant action.

Without this, your projectile would have to go though a long list of checks to know whether it is this or that.

like image 108
Everts Avatar answered Sep 28 '22 03:09

Everts


I have made a few games in unity and in my experience inheritance is almost never useful. This is because unity is not made with oop in mind but component oriented programing, ie you make small one-purpose component (script) and paste them together to make your gameobjects.

When you add a script to a gameobject the engine does the new Class(); work for you. This means that each gameobject has an instance of each script that is attached to it. This is true for all script both the ones you make and the ones already in unity like Transform and Animator. This is of course only true for your unity script that inherit from MonoBehaviour since they are the only thing you can add to a gameobject.

The gameobjects you see in the scene hierarchy are instances from the class GameObject. To understand how it work i recomend just reading the documentation but if you want to peek into the game object you need to dissemble it using something like Telrik JustDecompile or Reflector.

like image 25
Imapler Avatar answered Sep 28 '22 02:09

Imapler