Unreal vs. Unity: Actors & Components, Inheritance & Composition

video games are very complicated pieces of software if you're building a game from scratch you have to solve a really staggering number of problems before you can even get to something playable to figure out if it's fun but luckily these days you can use a game engine that provides off-the-shelf solutions to most of those common problems so you can just focus on building the parts of your game that are new and fun and interesting all of these modern engines are built around this same basic workflow where you implement the interactive elements of your game world by populating that world with game objects built out of reusable components in this video i'd like to examine that common design pattern and see how these three engines approach it slightly differently and then we'll look more closely at unreal system of actors and components and we'll explore a few different ways of putting everything together so let's start with unity you can summarize the gist of unity's architecture pretty simply when you run the editor you're presented with a scene the scene contains a hierarchy of game objects each game object can have any number of components attached to it all the cool stuff like collision sound rendering etc is handled by components game objects don't do anything interesting by themselves you build them into something useful by composing different sets of components to define custom logic you can use the scripting api to write new behavior components which can then be attached to game objects if you have a configuration of game objects and components that you want to reuse you can define a prefab and then instance that prefab around the scene godot has a similar approach but with even more architectural purity godot has nodes which are similar to components instead of using a behavior component to add scripted logic you write a script that extends a particular node type and then you can attach it to a node godot does away with the idea of game objects and prefabs and instead make scenes hierarchically composable every scene has a root node and you can instance one scene into another so you end up with one big node graph so unity and godot both have this advantage of architectural simplicity the engine presents you with a blank slate and once you learn a few basic concepts you're off to the races unreal has a similarly straightforward system there's just more complexity lying beneath it and more complexity built on top of it but we can illustrate a similar example with unreal and it looks pretty familiar actors are equivalent to unity's game objects being built up from a set of components any actor or component type can be extended by creating a blueprint this gives you a means of defining specialized archetypes for your objects a lot prefabs in unity or scenes in godot but it also lets you script custom logic using event graphs which are tightly integrated with the underlying c plus interface for the type you're extending so when it comes to building the objects in your game all three engines follow a similar design pattern each system has the notion of a game world which is the virtual environment the player occupies the game world contains game objects these are the entities that exist in that world these game objects are made up of components which are the individual building blocks that add different pieces of functionality to a game object all three engines use composition to let you build up game objects out of components and all three engines use inheritance to implement the different component types available by default let's take a closer look at the inheritance hierarchy for components in unreal the base component type is called actor component actor components can be registered with an actor they have an activation state to support the notion of being switched on or off and they have their own life cycle and tick functions they're used to add data or functionality to an actor but they don't have a transform within the scene movement components are one example of a component that just adds functionality for example if your actor represents a rocket that's been fired by a player you can use a projectile movement component to handle movement updates scene component represents the specialized class of components that have a spatial representation in the game world scene components can be attached to each other to form parent-child relationships they have properties defining their transform relative to their parent as well as a set of functions for getting or updating their transform in various ways scene component also supports the notion of component velocity and scene components can be visible or hidden if an actor wants to have a transform within the game world it does so by having a root scene component assigned to it you can use raw scene components to define local transforms within your actor for example if you have a mesh that needs to rotate around a specific pivot point you can create a scene component at that pivot point parent the mesh component to it and then rotate the parent scene component examples of scene components include audio component which plays a sound at a specific location or a camera component which defines a particular point of view and then there's primitive component which is a further specialization representing all the scene components that can be rendered in the viewport and collided against that includes mesh components basic collision primitives and lots of other things primitives have properties that define how they interact in collision checks against other primitives as well as events that are fired when those collisions occur if we follow this inheritance hierarchy back we'll end up at object which is the common base class for actor components and actors as well as most other engine types we've seen how actors in unreal are roughly equivalent to game objects and unity but there are some key differences in unity a game object has an identity in that it represents some entity in the scene and then other than that a game object just serves as an empty vessel for components to be attached to in unreal actors can have components registered to them but they also have a mind of their own actors have a set of life cycle methods that allow you to respond to key events as well as a tick function that lets them implement their own per frame logic you can define a new actor type to represent some kind of object in your game world and if there's data or functionality that's intrinsic to that type of game entity you can add it directly to your actor type without wrapping it up in a component in older versions of unreal the actor class was bigger and more monolithic it implemented network replication scene transforms rendering lighting collision movement physics sound and animation if you wanted to make a new kind of game object you'd add a new class into this inheritance hierarchy by extending actor or one of its subclasses and you'd configure the underlying actor properties to make your actor render and behave the way you needed it to most of this actor functionality has since been refactored into component classes starting with unreal engine 3. in ue4 the base actor class is comparatively lightweight but there's still the hierarchy of subclasses that build off of the actor class through inheritance and it is worth noting that every time you create a new actor blueprint you are implicitly extending this inheritance hierarchy and creating a new type even if you're just defining a simple archetype from off-the-shelf components this might be a little jarring coming from unity the fact that there are two separate inheritance hierarchies at play when it comes to game objects so in our earlier example our player has a static mesh component and a box component and it is in fact a kind of actor but it's a specialized type of actor called a pawn and as a pawn blueprint ipso facto it's also a specialized type of pawn called giuseppe so if you want to add some new functionality to your game you can create a new component type or you can create a new actor type if what you're implementing is a single reusable self-contained thing that doesn't relate to game object identity lean toward component if it has to do with what a game object inherently is or if it defines how an aggregation of components interacts as a whole not just the parts or if it's just a one-off thing that wouldn't be reusable in a way that would justify the added complexity lean toward actor sometimes there are valid strategies either way particularly when it comes to more abstract things like functionality for example let's say we wanted a simple first person interaction system if the player looks at an object and presses e we want the object to be able to respond in its own unique script-driven way the classic it's the late 90s and we're all high on oop approach would be to extend actor make an interactable actor subclass with a virtual method and then our interactive game objects could extend interactable actor instead of actor and override that method then when we're running a line trace into the viewport and we hit an actor we can check whether that actor is an interactable actor that's a straightforward approach and it works but the fact that it ties functionality to identity can lead to bottlenecks in our inheritance hierarchy if an actor needs this functionality it has to be an interactable actor it can't extend from any other actor subclass that may be fine but if we had say a type of pawn that needed to be interactable then our design would break down we could get around that problem by defining an interface instead then our actors no matter what type they were could implement that interface and override the function when we hit an actor in our line trace we check whether that actor implements the interactable interface to solve the problem using composition we'd instead create an actor component subclass as an added benefit we could add properties to that class so that our component can have its own state and its behavior can be configurable then our interactive game objects could have components to represent each of the interactions that we want them to support when we hit an actor with our line trace we check whether the actor has any interaction components and a word of advice if you're facing a design choice like this one try to remember that performance is probably not a significant factor as you think it is you should try to make design decisions based on which design is the best fit for your project not based on hunches about which approach will use the fewest cpu cycles so actors are game objects that exist in the world and components are individual pieces of functionality that can be registered to an actor it's also worth pointing out that sometimes you don't need to use either sometimes you have some discrete functionality that you want to encapsulate into a neat little self-contained package to keep things organized but it's not something that needs to be registered or activated or ticked in those cases it's perfectly reasonable to just make a custom object class in the example we just looked at we're running a line trace into the scene every frame that happens in our pawn classes tick function there are a couple of input variables that affect our trace namely how far from the camera we want the trace to extend and whether we want to render debug lines and then we have an output variable the hit result from that trace that we want to store indefinitely instead of cramming those properties into the pawn class i defined a helper object called interaction trace that just extends u object as long as i make sure to use a u property to reference that object i can create an instance at runtime using the new object function and that's all i need to do you can also instantiate you object classes as default sub-objects in the constructor just like you do for components in which case they're loaded alongside the parent object putting everything related to this trace functionality into an object lets me control the default parameters for the trace and override them in defaultgame.ini and it keeps our pawn class from having too many additional responsibilities that turn its public interface into a hot mess but we could have used a component class to represent the trace or we could have foregone using a separate class entirely it's up to you to make the choice that you feel is best for your use case and that's sort of a takeaway here unreal offers you the same basic workflow for constructing game objects that you'd find in an engine like unity but ultimately unreal isn't just a user-friendly tool set it's also a software framework that's wide open for you to leverage in whatever way suits your project and since blueprints are built directly on top of the underlying c plus types and interfaces it's still a good idea to make yourself familiar with basic software design principles and the overall design of the engine even if you mostly stick to blueprints remember though you can use whatever tools and engines you want if somebody makes blanket statements about which tools you absolutely should or should not use without knowing anything about you or what you want to make then they're saying a lot more about themselves than about the tools and technologies they're commenting on so i hope you've found this video helpful and if you're interested to know more about how unreal engine is put together and about that hierarchy of specialized actor classes that we touched on i hope you'll subscribe and stay tuned for the next video in that video we'll walk through how an unreal project gets booted up and initialized starting from the main function and working our way through all the key gameplay classes until we get to the begin play event if you'd like to get early access to that video now or if you just want to support the work that goes into making these videos feel free to have a look at my page on patreon and until next time thanks for watching

Channel: Alex Forsythe

Views: 8,143

Rating: 4.994885 out of 5

Keywords:

Id: iQ3c-lrHO7o

Length: 13min 37sec (817 seconds)

Published: Fri Nov 27 2020

Reddit Comments

[u/ATalkingMuffin]

This is an excellent video / comparison. You're spot on about the need you're filling and the execution. Really well done video in overall design (many simplified diagrams) and in specific (not being afraid to include boxes of interfaces / code when trying to compare).

​

PLEASE keep making videos. I think this level of video is missing in most industries / hobbies / topics.

[u/UnrealCoach]

Very refreshing take!

[u/ChronoRealm]

Finally, some good effin tutes. :)

[u/Hiiiiiiia]

I feel that you could make do without the comparison to the other engines.

It's a nice hook, but at the end of the video I was left feeling kind of confused as to why I would need to know these differences when the main focus is unreal.

I really like your approach to give a somewhat high-level overview and provide information that helps with descision-making instead of the usual "here is how to do X".

Overall it's really well done, not just visually, but also technically. Just the right amount of information to not feel overwhelmed but also give a nice overview of the principles at play.

[u/x-dfo]

this was really good! I love videos that actually give a holistic breakdown because everyone else is just 'do this step because I said' PLEASE MORE you don't have enough content for me to patreon YET