How to properly make multiple enemy types?

Questions & Answers
1

I’ve watched a lot of classes tutorial and seen so many cars being made but I am missing the part wherein you connect the normal class to a monobehaviour class. I’m intermediate at using MonoBehaviour and SO already and I also know how to use normal class as well (by itself) but still can’t figure out how to use normal class into unity.

I hope this problem let me understand things: "Do I have to make 3 monobehaviour scripts here? For each enemy?

203045-3ffa0d3c-25e8-47e7-93c6-3014de15b8a7.png
203045-3ffa0d3c-25e8-47e7-93c6-3014de15b8a7.png467×539 15.6 KB

Like this?
203046-3ffa0d3c-25e8-47e7-93c6-3014de15b8a7.png

2

Firstly,

  • Classes dont need to be suffixed with scripts they are supposed to model things i.e. nouns.
  • You should rarely to never use abbreviations especially non standard ones. skel, means nothing to anyone and in time will mean nothing to you.
  • Living isnt a noun its a verb. That alone should indicate either improper naming or an anti pattern.
  • Also that is probably a better case for an interface rather than inheritance.
  • Class names should also (just as with public members despite Unitys convention) be in PascalCase i.e. Orc, Skeleton etc.

Right now thats over:

Unity uses composition to describe game objects. What a game object is is a product of its state and its behaviours awarded to it by its composed components.

This is sort of a more structural type system (sort of like typescript). Regardless it is at odds with using inheritance for obvious reasons i.e. there is no type difference between two game objects with identical components but there may be a need for them to be treated as different types.

How do you get around that? By either leaning on state. i.e. the state of the configurations of those components determines the type.

Or (my preference) not using unity to design your game/business logic but rather as a layer that sits to the side of it that is specifically used for rendering, audio, physics etc.

What that awards you is the freedom to design your game how ever you want without the prescriptive limitations unity forces on you.

i.e. You could use inheritance to describe your Enemy type relationships if you want, I wouldn’t personally, but you could do that.

This comes with trade offs, i.e. you either have to write custom editor UI logic to hook into that, be burdened with the additional memory overhead or sacrifice some of the integration with the Editor.

For me the latter is next to irrelevant so I am happy to. for the most part ignore editor integration. That is a bigger problem if you are working with artists that need to configure the scene though.

Also you can inherit from something that inherits from Monobehaviour …again I wouldn’t use inheritance for this problem. It sounds like a recipe for spaghetti.

3

There are many different ways to achieve this, C# does not support multiple inheritance so your class has to inherit from monobehaviour or you can make an interface, a class can implement many interfaces, another way is to add your enemy type as a component, this is called the Type Object Pattern and you can get a good demostration in this amazing talk: