The title didn’t explain anything, so here goes.
I’ve followed a tutorial on making a player controller, that can be repurpoused later to make enemy entities. It used an interesting method for making the controller universal - it separated the logic like movement, input system, etc into different components, that were then put in a list in the main entity and updated through it, the idea being, that in other entites you can just pluck out the unnesessary components and put in the ones you need to make a brand new enemy entity.
Later on i realized, that that’s basically just a hierarchy of classes derived from an abstract Entity, that have class-specific parts, like inheriting Player and Enemy classes from that Entity, but with extra steps.
So I wanted to ask wether that first system is just a waste of time and an unnesessary abstraction, or if it has some value over a simple class hierarchy.
It always depends on your use case. If your game has very different behaviors for the characters or very simple ones, you probably should not do the abstraction to get results faster.
If you have a game with lots of characters who share parts of their behaviors or even mimic a real player (a bot), or would make a lot of sense to create such a plug in system.
If you are doing a project just for learning purpose, create the plug in system, because it will make you a better programmer.
Basically what you are describing is the old composition vs. inheritance discussion that comes up again and again. It’s important to understand how the method of using components to build different entities that you describe in the first paragraph is not equivalent to making a base class and derived classes like you describe in the second paragraph. Each approach has implications in terms of flexibility and scalability.
Search google for “composition vs inheritance Unity”. You’ll find tons of discussions and even youtube videos about the topic. They explain in better detail.
Ok, I understand the difference now, thanks. The problem I have is that different components sometimes interact with each other in small ways, for example a Combat component needs to apply knockback to an entity when it’s hit and all the rigidbody interactions are done in the Movement component, it needs a reference to it. I have a failsafe in place for when the component is missing, but doesn’t the fact that they need each other in the first place ruin the encapsulation which was the one of the selling points of the composition model? Or is that an architectural error on my part?
Also besides that, I always wondered wether using other objects’ methods throught references to them is slower than calling the current object’s methods and if that should play a part in this discussion at all.
If there’s any difference at all, it will be too small to worry about.
Try to avoid one component references other component types (if it’s possible). One common way to solve this is to use UnityEvents or just plain C# events, or a messaging system of some kind. There are probably others that I’m not able to think of at the moment. UnityEvents are very easy to implement, though.
Ideally, you would all of your components to mix and match and work independently, but realistically there will always be some tightly-coupled components- for example, if you create a physics-based character controller it will pretty-much always require a rigidbody or something like that. In that case, at least try to make the dependency one-way, i.e. the character controller may require a rigidbody, but the rigidbody knows nothing about the character controller.
The more independent that your components are, the more reusable they will be.