Jump to content
  • Advertisement
Sign in to follow this  
wcassella

Unity Unity vs Unreal 4 approach to entity-component pattern

This topic is 1089 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Unity and Unreal engine 4 both have different approaches to the Entity-Component pattern.

 

Unity's approach is a bit closer to the standard definition, where 'GameObjects' are purely a sum of their components. Components are also very fine-grained ('RigidBody' and 'MeshCollider' and totally distinct, for example), and each does very little on its own.

 

Unreal on the other hand, has Components (SceneComponents, specifically) acting more like independent objects which may be placed and moved independently of their owning 'Actor' and the other components it's composed of. Each component also contains a lot more behavior, where a 'StaticMeshComponent' will have rendering, collision, and physics bundled up together. Additionally, the Actor class itself may be subclassed to create specific configurations of components, as well as implementing behavior.

 

Personally, while Unity's approach is a bit more "pure" from an engineering perspective, I've found Unreal's approach a lot more intuitive and pleasant to work with when designing objects (this may be partly due to Unreal having a much better tool experience). However, I haven't had an opportunity to work with Unreal a whole lot yet, so there may be large drawbacks I haven't encountered.

 

Ultimately, I think Unity may be a bit too rigid in its approach (Unity basically shoves everything into "Components", which can feel a bit unnatural at times), but Unreal's approach smells a bit like a holdover from the days of over-using inheritance, which makes me a little wary.

 

What are your thoughts?

Edited by Salty Boyscouts

Share this post


Link to post
Share on other sites
Advertisement

I think Unity's is a step in the right direction, but it's very difficult to make components interact when they are entirely encapsulated.  I find that it's better to have components be pure data, with systems operating over them, potentially multiple components at once, e.g. an IntegrationSystem that integrates velocity into position, but only if both components are present.

Share this post


Link to post
Share on other sites

but Unreal's approach smells a bit like a holdover from the days of over-using inheritance, which makes me a little wary.


While it shouldn't make you 'wary' as such you are correct that the larger classes are a hold over from the pre-UE4 days.
While it does give you easy canned classes to work with it does however present problems as some of those classes don't derive from the right part of the inheritance tree so you couldn't, for example, treat an Actor as a SceneComponent in an interchangeable way which leads to complications both in the code and in the usage pattern and the designer ends up having to remember special rules.

I believe there is effort afoot to convert things like StaticMeshRenderer and the like to proper component systems so that problem goes away (there are a number of classes which share this work flow/looks-like-a-component-but-sint problem) but I've no idea how far along that work is.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!