OOP approach in unity

I started developing for unity recently. I have been coding for few years and I'm very used to using OOP heavily in my coding. I made a small game engine for myself and designed a game with for android using Java.

However, when I came to unity everything seems different now.
I'm creating a 2D Tile map for a 2D game, the map contains -obviously- tiles. so without thinking I would usually create a class called tile and store instances form this class inside my Map class. This doesn't work in unity, since the tile script has to inherit from MonoBehavior, and I create these tiles randomly at run time using Instantiate function which returns GameObjects, and obviously I don't have a game object called tile. how can I deal with my tiles as classes or as instances ?

another example if that was poorly described
if I designed a character and I want it to collide with objects, how can I deal with them based on "is-a" relationship
if my player hit a monster for example I want to know that, but unity doesn't give u this, it's a collision with a collider that is associated with gameobject which in its turn has a script called monster! and there is no way to know if what I hit is a monster or not!

I hope it's obvious now, so how do you usually deal with this in unity?
what is the rightapproach

 

Not sure if the right aproach, but i'll try

For the second example you could create a an abstract base class called creatures: monobehaviour. She would have a virtual method to check for colisions.

Then create a class monster: creatures - this one goes as a component in tjthe game object.

You could also use interfaces in a similar way.

^^

 

You can totally work in OOP manner.

You can instantiate GameObjects and attach your scripts to them, you can attach your classes to them and reference them using GetComponent

As for the collision issue you can test them by name, or you can give them tags to help you identify them for starters.

then you can use GetComponent again to access the Monster script.

There are just a few transitions to make when learning Unity, seems a bit odd at first.

 

Nearly everything in Unity will be a game object - you add scripts to the game object to make that game object into something unique (for instance, a tile).

So what you would do is create a game object and then drag & drop the tile C# file onto the game object to make the game object a tile.

Then, to reference the tile script on any game object that has a tile script, you do this:

Code (CSharp):

1. // assuming there is an instantiated game object called gObj...
2.  
3. Tile tile = goObj.GetComponent<Tile>();
4.  
5. if (tile != null)
6. {
7.    // The game object had a tile script on it, so it is a tile!
8.    // Call a public function on the tile class or something...
9. }
10. else
11. {
12.    // Not a tile!
13. }

For the monster hit check:

Code (CSharp):

1.  
2. using UnityEngine;
3. using System.Collections;
4.  
5. public class Player
6. {
7.    // Assumes that the player game object has a collider component on it
8.    void OnCollisionEnter (Collision col)
9.    {
10.       if(col.gameObject.GetComponent<BoogieMonster>() != null)
11.       {
12.          // Collided with a Boogie Monster
13.       }
14.       else if (col.gameObject.GetComponent<CookieMonster>() != null)
15.       {
16.          // Collided with a Cookie Monster
17.       }
18.    }
19. }
20.  

 

Instantiate does not return GameObject it is returning UnityEngine.Object.
You can just Instantiate a Tile

Code (csharp):

1.  
2. // drag a gameObject or a prefab, that has the Tile component attached, here
3. public Tile prefabTile;
4.  
5. private void Start()
6. {
7.     Tile instance = (Tile)Instantiate(prefabTile);
8.     instance.DoSomething();
9. }
10.  

 

Thanks a lot everyone I appreciate your time, that was really helpful.
not sure if the confusion is cleared completely I have to keep coding and see but thanks any way

 

I did this Exactly, I know it doesn't return a gameobject and I tried this exactly but it gave me a cast error!

 

In my opinion, it would be best to embrace Component Based Programming since it will enable you to utilize Unity the best way.

I also worked with OOP before, where I would create class nesting like:

Dragon -> Enemy -> MapObject -> Object
Warrior -> Player -> MapObject -> Object
Item -> MapObject -> Object

In Unity you can instead create scripts that have certain behaviours, like AttackBehaviour, MoveBehaviour, PickupBehaviour, etc.

Then you can attach those behaviours onto any entity you have (GameObject). This will allow you to give Item the Attack mechanism just by adding AttackBehaviour to the GameObject, instead moving the Dragon's Attack implementation all the way to MapObject so your Item could use the code, cluttering the class with 2000+ lines of code.

So my best advice would be to look at your ingame objects what are they made of instead what they inherit.

That way:

Dragon -> Enemy -> MapObject -> Object

would become

Dragon:

• AttackBehaviour
• HealthBehaviour
• AIBehaviour
• FlyingBehaviour
• DodgeBehaviour
• FireBreathBehaviour
• RareLootPickupBehaviour
• SummonMinionsBehaviour

Now you can now take FlyingBehaviour and add it to Item and have it fly around the map. While OOP sure is great, Component Based Programming is a lot flexible when making games, especially when you're making prototypes.

 

that sounds great as well but I think It will take a while to get used to it
besides we are making a ROG game which uses nested classes like A LOT!

anyways it's a way to consider, I know unity is meant to be this way, but you have to check your options

indie games usually have resections because of many things , one of them is "low experiance" XD

thanks any way for the info, it's helpful to understand the other approach