Can gameobjects be classes?

Hi all. Some conceptuakl questions.

In OOP languages i've used before, i'd often instantiate a class directly. For example, i'd create an "Actor" class, and add various graphics and properties under it.

However, i've no idea how to accomplish this in unity. All i can really do is create a gameobject with a script called actor attached to it.

Similarly, i can't figure out any way to create/set properties on such things. I can't simply set the player as alive or dead, i have to use GetComponent to find the actor script on them, and toggle the isAlive flag on that script. It's mostly inconvenient more than anything. Is there any way to create properties and variables on things which aren't scripts?

 

Ya if you want predefined types in the scene use prefabs, with scripts assigned to the object, than get component.

Also remember when making scripts to interact with your game object you can give them a public field of your script type and skip doing a get component since your are referencing the script on the object directly.

Within scripts you can use inheritance as much as you want.

But you can't do it like you would in source or unreal where the actor is defined 100% in code.

 

really? How is that accomplished?

 

Well say you have a script that needs to interact with the player actor, instead of givieing it a public gameObject variable you can give it a public player variable and when you drag the player object onto it, it will automatically get the player object not the game object.

 

You can declare a Monobehaviour type in a variable on a script.

In the scene view, if you have a GameObject with that script-type available, you can drag-and-drop the GameObject onto that field and assign the variable with that GameObject's Monobehaviour reference.

 

You could do this:

Code (CSharp):

1. scriptActor Actor = new scriptActor();

Instead of adding it as a component. But I'm pretty sure it needs to have a monobehavior.

Code (CSharp):

1. public class scriptActor: MonoBehaviour {
2. //Your stuff here...
3. }

 

You can't create MonoBehaviour derivatives with "new".

 

This is as close as u can get(i think). o.o

Code (CSharp):

1. void Start() {
2.      GameObject newObj = new GameObject();
3.      newObj.AddComponent(class);
4.      //etc...
5. }

 

Sometimes it works.

 

No it doesn't.

You should do your initialization in Awake and Start. Your "scripts" can contain other non-MonoBehaviour classes that can be used for data etc. If you serialize these classes then you can set their values in the Inspector.

 

Nanako, it sounds like you haven't heard of Scriptable Objects.

That said, it sounds like you need to stop coding, and go work through some tutorials. You're not going to make fast headway if you treat Unity as if it were not Unity.

 

I'm still not quite getting these two posts. Can someone provide code/pictoral examples?

 

I think this image kinda describes how its done. If I can find the unity video tutorial I'll link it instead.

 

Oh, that's just a variable on a script.

What i was asking is if there's anyway to add such a thing to a gameobject (NOT to add a gameobject to a script)

i guess public references on scripts might let me navigate around references easier though, i'll think and see if i can find an implementation for that.

 

I don't think anyone has pointed out that you can define classes that you instantiate directly. C# is a modern OOP language, not conceptually different from any other. Example:

Code (CSharp):

1. class Food {
2.     public string name;
3.     public int tastiness;
4.     public Log() {
5.         Debug.Log(name + " tastiness is " + tastiness);
6.     }
7. }
8.  
9. // ...meanwhile, somewhere else in the code ...
10. Food apple = new Food();

You just can't instantiate classes which derive from MonoBehaviour this way. They're designed to be instantiated via AddComponent, as others have shown above.

So as a practical matter, if you're relatively new to programming, you probably won't actually define and use from-scratch classes very often... you can go a long way in Unity embracing its component-based architecture (i.e. using MonoBehaviours). But eventually you'll find good use for this.

 

Ya think your problem is your trying to force a component system to act like a system based on inheritance. Best to just learn the unity way instead of forcing it to do what it was not made for.

 

I will second cncpasserby's comment: Unity is all about Component Model programming, where GameObjects are populated with components (scripts essentially), and there may be specific links between different components that allow them to interoperate and share data and function. Additionally, the Unity scene graph maintains (via the transforms) a hierarchical relationship structure between all the GameObjects in your scene, which further affects how they interoperate.

 

what you need to remember when working in Unity is that the gameObjects are exactly that: objects, of the Unity Engine's GameObject class. in order to create an object of type GameObject, you have to use Unity's Object.Instantiate() function because there are lot of background things that have to be done in Unity's engine when a new GameObject is created, and Object.Instantiate() takes care of that. I'm assuming since you mentioned working with OOP before you understand that Object > Component > Behaviour > MonoBehaviour (which is the type which all script components have) and therefore you can just call Instantiate() from inside a MonoBehaviour script.

The important thing to remember about scripts is that they are OOP objects, but in Unity's context, they're components of the prefab that you're dealing with. They have to be attached to something, and they do not encompass the entire being of that object, they are just something that is attached to it, that can do things to it. This is why they're called Behaviours and not objects in Unity's terminology. They don't define objects; they define ways in which objects can behave in the scene.

So for your Actor scenario, you wouldn't instantiate an object of type Actor (or any descendant of it) in the scene directly. You would construct a series of Unity GameObjects, put them together in the Unity heirarchy, put MonoBehaviours on the different parts to make them do what you want, and then select the whole thing and drag it down into the project folder to create a Prefab of that construction. It's really not just one thing, it's a whole relational structure between multiple things. This is how you would go about putting together a player, or an enemy, or whatever else you have in your game scene. You then instantiate prefabs, not classes.

 

This is actually perfectly legal GameObject doesn't inherit from MonoBehaviour (or Component)

Code (csharp):

1.  
2. GameObject newObj = new GameObject();
3. GameObject another = new GameObject("Another GameObject");
4.  

 

i was showing that heirarchy to show why instantiate can be called from a MonoBehaviour script instead of having to write Object.Instantiate()